![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Кластерная самба
В Мельбурне проходит восьмая конференция 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-совместимых систем.
Видео доклада: 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-совместимых систем.
no subject
no subject
no subject
no subject
no subject
Правильно я понимаю, что для того, чтобы все это взлетело, нужен shared storage?
no subject
no subject
no subject
no subject
Т.е. GFS держит "13.5Гбит/с"? Или в том конкретном случае (http://abbra.livejournal.com/113563.html?thread=528283#t528283) какая-то другая (какая)?
Поверх какого железа она (эта файловая система) живет?
no subject
Живет она поверх разного железа на разных архитектурах (x86_32, x86_64, ppc64, s390).
Заглянул в Википедию, чтобы "послать" туда на http://en.wikipedia.org/wiki/GPFS, оказалось, что наш http://en.wikipedia.org/wiki/Scale-out_File_Services там тоже уже есть. :-)
no subject
вот-вот!!!
коннект идет по cifs
Re: вот-вот!!!
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: вот-вот!!!
проверил на RHEL 5.2 - скачал ядро с cifs 1.56RH (так и показывает /sys/module/cifs/version)
увы, по прежнему не вижу глубже одно уровня.
сервер: "NOS: Windows Server 2003 R2 5.2 Capability: 0x1f3fd"
Re: вот-вот!!!
то в логе:
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: вот-вот!!!
Re: вот-вот!!!
ls: reading directory /smb/work/INST/: Object is remote
это была последняя попытка :)
я уволился с того места!
Re: вот-вот!!!
Тем не менее, надо бы довести до ума. Если в этот раз MS выполнит свои обещания и все-таки пришлет MSDN, я доделаю.