В Мельбурне проходит восьмая конференция 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-совместимых систем.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
