abbra: (Default)
[personal profile] 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-совместимых систем.

Date: 2015-01-27 06:29 pm (UTC)
From: [identity profile] rosopaha.livejournal.com
Здравствуйте!
Хотел бы попробовать кластерную самбу вот в какой ситуации: кластер из двух узлов, слабое звено связь между ними. Клиенты группы 1 к узлу 1, клиенты группы 2 к узлу 2. Рвется связь и каждый узел кластера пошел в свою сторону - возникает коллизия. Для моей специфичной задачи, было бы неплохо, при восстановлении связи в кластере передавать управление данными в слой программного обеспечения более высокого уровня, которое решает коллизию, например на узле 1, оперируя при это не файлами, а данными, которые в них хранятся, при опираясь на изменения в узле 2, а затем узел 1 объявляется мастером кластера и его версия совместной работы принимается узлом 2. И поехали снова вместе.
Можно ли такое сделать?

Profile

abbra: (Default)
abbra

April 2016

S M T W T F S
     12
3456789
1011121314 1516
17181920212223
24252627282930

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 18th, 2017 04:59 am
Powered by Dreamwidth Studios