Кластерная самба

[abbra]

В Мельбурне проходит восьмая конференция Linux.conf.au. Как всегда, на конференции по сути подводятся итоги прошедшего года и разработчики рассказывают о своих достижениях. Andrew Tridgell, автор Samba и rsync, сегодня демонстрировал то, чем мы занимались целый год в рамках SOFS (Scale-Out File Services, коммерческое решение от IBM) и что доступно под названием "Кластерная Самба" под лицензией GNU GPL.

Видео доклада: http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-178.ogg (OGG Theora).
Сайт проекта: http://ctdb.samba.org/

Не обошлось и без шуток, как обычно: на этот раз Ронни Сальберг, автор Wireshark и один из авторов алгоритмов, лежащих в основе кластерной Самбы, в качестве демонстрации концепций "активного-пассивного" и "активного-активного" кластеров предложил рассмотреть рок-концерт, на котором выступают одновременно с одной и той же песней Guns'n'Roses и ZZTop. При этом в режиме "активный-пассивный" Билли Гиббонс исполняет песню на сцене, а Аксл Роуз в полном ожидании "заморожен" за сценой седативными веществами. В момент, когда Билли вдруг перестает играть из-за, скажем, проблем с желудком после "вчерашнего", Аксл должен выскочить и доиграть ровно с оборванной ноты. Однако, в "активном-пассивном" варианте всегда есть теоретическая возможность того, что находящийся в пассивном состоянии узел кластера на самом деле не работает (уборщица вырвала шваброй провод FC-контроллера) -- в случае с концертом Аксл мог просто уехать на другую площадку, чтобы не терять время пока Билли и так "зажигает".

В варианте "активный-активный" они оба исполняют одну и ту же песню на сцене и при "отпаде" Билли все, что нужно сделать Акслу -- это переключить внимание зрителя на себя. Вероятность его неработоспособности отсутствует -- ведь он тут же, уже исполняет эту песню. В кластерной самбе это делается следующим образом: если вдруг один из узлов кластера перестал работать, то один из демонов CTDB, запущенных на всех узлах, заметит отсутствие коллеги, перехватит его адрес на себя и пошлет вместо него клиенту подменный пакет TCP ACK (подтверждение прихода от клиента пакета, который тот не посылал) с неверным номером последовательности протокола TCP, но теми же исходными адресом и портом, которые были в общении клиента с почившим уже сервером -- информация о всех соединениях в кластере доступна всем демонам CTDB. В ответ на такой ACK любой TCP-клиент пошлет свой ACK, но уже с правильным номером последовательности на тот адрес и порт, которые были у "почившего". Поскольку этот адрес уже принадлежит другой, работающей машине, то пакет "ударится" в порт, который на этой машине не открыт (он был открыт на "почившем"), TCP-стек работающей машины пошлет TCP reset, а клиент CIFS выполнит переподсоединение с уже работающим сервером (адрес-то не поменялся, несмотря на то, что сменился сам сервер) и работа приложения продолжится.

Вся эта машинерия нужна для того, чтобы вынудить зрителя обратить внимание на того исполнителя, который подменил выбывшего из строя Билла, поскольку в случае TCP-стека если не приходят к клиенту сообщения (и он сам их не посылает), то соединение закроется через некоторое время. В традиционной ситуации CIFS-клиент ждет около 45 секунд, если на его запрос не пришел ответ (на уровне CIFS), но время ожидания варьируется и может достигать на уровне IPv4 двух часов -- во всяком случае, это время keepalive по умолчанию в ядре Linux. То есть, посылая подменный ACK мы провоцируем клиента на ответные действия (посылка пакета по адресу, где заведомо не отвечают по старому порту) и тем самым сводим время простоя при падении одного из узлов, с которыми работал клиент, до нескольких секунд.

Конечно, от приложения тоже требуется определенная логика -- оно должно уметь восстанавливаться при "выпадении" сети. Впрочем, такое требование присутствует и в качестве рекомендаций в MSDN для приложений под Windows, и в книгах по программированию для POSIX-совместимых систем.

Comments

[strangestone.livejournal.com]

Вот только он Аксл Роуз :)

[abbra]

Ага :-)
Я не "фоннат" :-)

[aceler.livejournal.com]

Я так понимаю, Samba под Linux работает лучше Smb под Windows? :)

[abbra]

По отношению к какому формальному параметру "лучше"? Производительность? Да, с 2003 года мы стабильно быстрее реализаций от Microsoft в работе с файлами. По функциональности? Нет, есть области, где мы впереди, есть -- где они лучше, есть и такие, где у нас вообще не реализованы существующие уже давно возможности Microsoft Windows.

[aceler.livejournal.com]

По производительности по меньшей мере.

[abbra]

Кластерный вариант (SOFS) дает в реальной нагрузке 1.7Гб/с консолидированного устойчивого потока на одном из имеющихся внедрений. Эти 13.5Гбит/с сильно прогружают дисковую подсистему, поэтому хорошая подсистема хранения обязательна. Насколько нам известно, ни одно другое решение на CIFS такой нагрузкой не обладает, везде существенно меньше.

[vm-lj.livejournal.com]

>> хорошая подсистема хранения обязательна

Правильно я понимаю, что для того, чтобы все это взлетело, нужен shared storage?

[abbra]

Нужна распределенная файловая система.

[vm-lj.livejournal.com]

Например? GFS?

[abbra]

Да. Посмотрите комментарии в http://abbra.livejournal.com/80754.html, я там уже упоминал существующие проблемы распределенных FS и на основании чего нужно делать выбор.

[vm-lj.livejournal.com]

Я правильно понимаю, что в распр. FS лежат сами данные?

Т.е. GFS держит "13.5Гбит/с"? Или в том конкретном случае (http://abbra.livejournal.com/113563.html?thread=528283#t528283) какая-то другая (какая)?

Поверх какого железа она (эта файловая система) живет?

[abbra]

В том конкретном случае -- GPFS, коммерческая распределенная файловая система от IBM. Сами данные лежат в ней, да. Держит под нагрузкой она значительно больше, это через CIFS можно получить 13.5Гбит/с в том конкретном случае, нативный клиент (которого под Windows нет, потому и весь наш проект имеет смысл) дает под Linux/AIX кумулятивно немного побольше.

Живет она поверх разного железа на разных архитектурах (x86_32, x86_64, ppc64, s390).

Заглянул в Википедию, чтобы "послать" туда на http://en.wikipedia.org/wiki/GPFS, оказалось, что наш http://en.wikipedia.org/wiki/Scale-out_File_Services там тоже уже есть. :-)

[vm-lj.livejournal.com]

Спасибо :)

вот-вот!!!

[zzfi.livejournal.com]

как всё же с поддержкой MS-DFS в linux? поставил последнюю samba (кажись 3.2) и по прежнему не вижу глубже одного каталога. :((((
коннект идет по cifs

Re: вот-вот!!!

[abbra]

cifs.ko? Какая версия? Поддержка dfs в cifs.ko появилась в 1.53, реально работающей стала в 1.56. Плюс требуется некоторая настройка согласно fs/cifs/README.

Enabling DFS support (used to access shares transparently in an MS-DFS global name space) requires that CONFIG_CIFS_EXPERIMENTAL be enabled. In addition, DFS support for target shares which are specified as UNC
names which begin with host names (rather than IP addresses) requires a user space helper (such as cifs.upcall) to be present in order to translate host names to ip address, and the user space helper must also be configured in the file /etc/request-key.conf

Re: вот-вот!!!

[zzfi.livejournal.com]

Спасибо за ответ!

проверил на RHEL 5.2 - скачал ядро с cifs 1.56RH (так и показывает /sys/module/cifs/version)
увы, по прежнему не вижу глубже одно уровня.
сервер: "NOS: Windows Server 2003 R2 5.2 Capability: 0x1f3fd"

Re: вот-вот!!!

[zzfi.livejournal.com]

да, если включить /proc/fs/cifs/traceSMB

то в логе:
Jan 29 16:54:46 Piran kernel: CIFS VFS: dns_resolve_server_name_to_ip: unable to resolve: spbfs02.internal. corp
Jan 29 16:54:46 Piran kernel: CIFS VFS: compose_mount_options: Failed to resolve server part of \\spbfs02.i nternal.corp\INST to IP: -11

на:
$ ls -l /mnt/O/INST/
ls: /mnt/O/INST/: Resource temporarily unavailable

и конечно:
$ host spbfs02.internal.corp
spbfs02.internal.corp has address 192.168.32.40

Re: вот-вот!!!

[abbra]

Так а userspace настроили, как в README?

Re: вот-вот!!!

[zzfi.livejournal.com]

Увы:
ls: reading directory /smb/work/INST/: Object is remote

это была последняя попытка :)
я уволился с того места!

Re: вот-вот!!!

[abbra]

:)
Тем не менее, надо бы довести до ума. Если в этот раз MS выполнит свои обещания и все-таки пришлет MSDN, я доделаю.

[ugenk.livejournal.com]

как бы не отгрябать проблем с сетью?
если машина выпадает из сети, то gratitious arp она не посылает - и взять ее же ip будет проблематично. вообщем-то свитч, в который включены (?) сервера с вероятностью в 50% почистит свою мак-таблицу (вероятность равна 100%, если отвалился порт), но вот следующий свитч об этом врятли узнает.
или я пропустил какой-то момент?

[abbra]

Для начала -- кака машина отвалилась? Узел кластера или клиент?
Если узел кластера, то при следующей проверке (несколько секунд спустя) ctdbd на остальных узлах обнаружит, что один отвалился и первый обнаруживший это заберет его IP на себя, поскольку все они знают IP публичных интерфейсов кластера.

Если клиент отвалился, то нам проще -- CIFS возлагает вопрос хранения состояния на клиента.

[ugenk.livejournal.com]

обожди, я видимо чего-то не понимаю
у нас есть кластер, и у каждой из его нод разный ip. так?

[abbra]

У нас есть кластер и набор публичных IP. Эти IP распределяются между работающими узлами кластера так, что по этим IP-адресам всегда отвечают службы. Если кто-то "вылетает", этот узел помечается неработающим и его IP забирает другой узел.

Поэтому клиенты всегда могут расчитывать на то, что им всегда будет доступен нужный ресурс, даже если у него сменится IP, но при этом имя cifs-сервера останется тем же. При первом соединении с этим "сервером" по имени адрес берется round-robin-ом из DNS.

[ugenk.livejournal.com]

а при получении клиентом tcp-ack'а с неправильным номером последовательности пересоединение происходит опять же по DNS или по CIFS-имени?
Если да - то где гарантия, что в раунд-робине не попадется нерабочий сервер.

Если нет, и пересоединение происходит по IP - то тогда и возникает проблема, о которой я говорю.
Еще раз ее опишу:
Сервер умер, gratitious arp не послал. Т.е. свитчи в пределах LAN/VLAN не знаю о том, что наш сервер умер и траффик для него не нужно посылать на старое место. И при этом, если новый сервер попробует прислать arp о том, что мол x.x.x.x - это теперь я, то любой нормальный свитч это проигнорирует. Возможно даже выключит порт :)
Понимаешь суть проблемы? (если она конечно всё-таки есть, и я правильно понял картину происходящего)

[abbra]

При приходе неправильного tcp-ack клиент ответит нам ack с верным номером последовательности на старый IP, с которым он думает, что соединен. Поскольку этот IP сейчас принадлежит нашему серверу, который и послал неправильный ack, то от него и пройдет клиенту ответ сброса соединения, а клиентский стек CIFS автоматически перевосстановит сессию CIFS (это его такое нормальное поведение). То есть, для клиента в этом случае ничего не меняется -- как работал он с сервером по IP(1), так и продолжит работать с сервером по IP(1), вот только сам сервер физически сменится, но это уже не проблемы клиента, поскольку сервера у нас (с точки зрения служб и информации о соединениях) одинаковые.

В раунд-робине всегда работающие сервера, потому что _все_ IP адреса кластера всегда работают. Допустим, у нас три узла кластера: A - IP(1), B - IP(2), C - IP(3). Если узел A выйдет из строя, то B/C перехватят его IP(1). Пусть это будет B, тогда у него будет два публичных адреса кластера: IP(2) и IP(1). То есть, адреса по-прежнему доступны. Если следом из строя выйдет B, то его адреса перехватит C, у него будет три адреса. Теперь гибель С приведет к гибели всего кластера, но пока у нас есть работающие узлы, все IP будут доступны клиентам.

При миграции IP-адреса происходит посылка ARPOP_REQUEST (это твой gratitious arp) и ARPOP_REPLY (мы отвечаем широковещательно сами себе). После этого мы посылаем tickle ack клиенту по описанной выше процедуре. Все это работает, в том числе и у заказчиков.

Можешь посмотреть демо вот тут: http://samba.org/~tridge/ctdb_movies/node_reset.html и тут: http://samba.org/~tridge/ctdb_movies/node_disable.html

[afina07h.livejournal.com]

Доброе утро! Кто в курсе, как узнать ip адрес (http://proverim.net/ipinfo.php) посетителя форума, если я сама на этом форуме обычный пользователь??

P.S. Заранее благодарю за ответы.

Re: Немного вопросов..

[abbra]

Задайте эти вопросы в samba-technical -at- samba.org. Я последний год в связи со сменой работы отошел от CTDB.