SkyCover Infrastructure CD — дистрибутив кластера высокой надежности

Интересно. Я такое же для kvm делал недавно, а какая файлуха на drbd используется?

drbd там поверх lvm, а поверх drbd может быть какая угодно фс. По дефолту используется ext4.

Кстати, с kvm оно должно работать аналогично(в ganeti есть поддержка kvm), но мы не проверяли

По дефолту используется ext4.

Вот меня именно она и интересовала. Ок. Спасибо.

пророчу большое будущее

Линукс ждет большое будущее. И всегда будет ждать.

Тонко и поэтично.

Офигеть, даже название красивое придумали. Редкость для новых дистрибутивов, по-моему.

я гоняю кластер с использованием ganeti и kvm. Если у вас там нет особых xen-специфичных заморочек - тоже должно работать

я гоняю кластер с использованием ganeti и kvm. Если у вас там нет особых xen-специфичных заморочек - тоже должно работать

хеn-заморочки в SCI-CD есть - надо и ядро нужное установить и shed-cred настроить, и в настройке виртуалки после debootstrap всякие hvc и xvda прописать.

Но иначе все придется делать руками, а дистрибутив создан как раз для того, чтобы руками делать поменьше.

Можно добавить и kvm-заморочки, но мы не используем kvm промышленно. С удовольствием примем код и рекомендации.

Ну у меня пока тоже сурового Ъ-энтерпрайза нет на kvm - только готовлю кластер к таковому. Так что пока чётко и внятно посоветовать ничего не могу. Но буду иметь ввиду...

О, на Дебиане. Попробуем.

По дефолту используется ext4

Что? А как же btrfs, которая уже готова для повсеместного применения?

Все просто - на момент релиза 1.0 она еще не «была готова для повсеместного применения» :)

На самом деле, btrfs меня лично интересует, но торопиться с ее использованием я не собираюсь. Впрочем, если кто-то хочет, то что мы, запрещаем что ли? :)

https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial

пошаговое описание

Интересная ссылка. Но результат дается очень трудоемко, а возможности манипуляции довольно средние.

Увы, до сих пор Ganeti остается единственным инструментом, который позволяет изменить размер DRBD-раздела простой командой

gnt-instance grow-disk INSTANCE DISK AMOUNT

Кроме того, Ganeti самостоятельно настраивает LVM и DRBD ресурсы, позволяет делать кластерные пары в системе трех и более узлов, автоматически переносить master или slave часть виртуалки на другой узел и многое другое. Поэтому уровень вхождения в ряды кластеростроителей получается гораздо ниже.

А мы, в SCI-CD, постарались свести к минимуму ручную настройку всех сопутствующих механизмов, которая нужна для построения системы «под ключ».

Я вообще считаю такой подход для строительства виртуальных ДЦ ошибкой. Но хаутушка хороша не результатм а процессом, в котором можно научиться очень многому, так что автор, имхо, молодец. Но вообще, сколько нод можно ввести в такой кластер?

Как учебный материал хаутушка действительно отличная.

Но вообще, сколько нод можно ввести в такой кластер?

Если вопрос про ganeti, то официально рекомендуемый размер - до 40 узлов. Основное достоинство подхода - это очень удачное соотношение стоимость/надежность.

Чтобы добиться лучшей надежности традиционным методом нужна двухузловая СХД, причем че-ньть толковое, а не InforTrend, плюс две блейд-корзины (разделенный бэкплейн в два разных помещения не уберешь). При объемах ДЦ выгоды сильно зависят от задач. А вот для частных нужд малого и среднего бизнеса ganeti обычно будет выгоднее.

Если вопрос про ganeti, то официально рекомендуемый размер - до 40 узлов. Основное достоинство подхода - это очень удачное соотношение стоимость/надежность.

а каким образом производится распределение доступа к кластерной ФС? А то у всех остальных, количество хостов намного ниже (GFS2 - 16 хостов, VMFS - 32)

разве что oVirt/RHEV будет помощнее - 200 хостов в кластере, и это «мягкое» ограничение (в настройках), но там не используется кластерная ФС

Ganeti не предполагает применения кластерной ФС. Для GFS надо запустить DRBD в режиме Primary/Primary, когда возможна конкурентная запись на оба узла и GFS сама обрабатывает коллизии при одновременном доступе к блокам.

В Ganeti DRBD работает в режиме Primary/Secondary и эта конструкция предназначена не для распределения обработки, а для гарантирования фиксированного маленького времени failover (5-10 минут) при аппаратной аварии любого типа и, при этом, без потери данных. (Ну и есть дополнительные бонусы в виде живой миграции между узлами, изменения размера томов «в один клик» и т.п.)

В большинстве общеупотребительных случаев, даже в крупном бизнесе, небольшие простои не создают реальной угрозы для процесса производства и случаются, увы, с неизбежностью, а длительные простои и потеря любых данных - это всегда вред. Ganeti предлагает очень бюджетный вариант защиты.

это похоже на маркетинг, а меня больше интересуют технические детали :) как именно эта конструкция избегает split brain? есть у меня 40 хостов, один из них потерял сеть на 5-10 минут, ВМ с него запустились на другом узле, и что мы получаем?

и кроме того, если нет кластерной ФС, но как именно реализован доступ к имиджам ВМ?

В подразумеваемой тобой конфигурации автоматический рестарт ВМ на другом узле - дело довольно рискованное и так никто не строит.

Если нужна автоматика, то надо более одной физически независимой сетки и третья точка для контроля.

Если этого нет, то админ должен убедиться, что виртуалка с пропавшего узла обратно в сеть не вылезет. Самое простое - послать кого-нибудь выдернуть питание из сервера. При последующем включении автостарта виртуалок на нем не будет.

Split brain не случится в любом случае, поскольку когда будет выпоняться failover на заменяющий узел, то будет переконфигурирован DRBD и роль заменяющего узла сменится на Primary/Slave. И первичным всегда будет считаться тот узел, про который cluster-master-демон знает, что он первичный, поэтому направление восстановительного ресинка всегда очевидно.

если нет кластерной ФС, но как именно реализован доступ к имиджам ВМ?

ВМ всегда приписана к определенным двум узлам кластера. На них размечены LVM-тома и сконфигурирован DRBD. Есть простые команды для:

• смены главного узла
• смены (или восстановления) заменяющего узла
• экспорта образа ВМ по сети на любой другой узел (переносимый формат)
• создания новой машины на любом узле из переносимого образа, который будет получен с любого другого узла.

Вчера на фесте видел live-скринкаст :) Отлично

В подразумеваемой тобой конфигурации автоматический рестарт ВМ на другом узле - дело довольно рискованное и так никто не строит.

Если нужна автоматика, то надо более одной физически независимой сетки и третья точка для контроля.

Если этого нет, то админ должен убедиться, что виртуалка с пропавшего узла обратно в сеть не вылезет. Самое простое - послать кого-нибудь выдернуть питание из сервера. При последующем включении автостарта виртуалок на нем не будет.

понятно, то есть нормального HA кластера мне в данной конфигурации не видать, и SBA не предусмотрено? Спасибо, когнитивный диссонанс разрешился, и похоже ничего революционного я не увижу :)

если позволите резюмирую: данный дистр позволяет развернуть (пары? или группы?) реплицированных хостов без автоматического фейловера, но с возможностью быстро руками поднять запасной хост в случае падения основного, со всеми ВМ на борту.

живая миграция, миграция дисков, LB, HA и прочие радости SVI и IaaS, как я понимаю, тоже не получатся?

Все таки не совсем так:

• Можно развернуть группу из любого (и нечетного) числа узлов.
• Для создания ВМ можно выбрать любую пару узлов и это не навсегда - можно легко перетаскивать.
• Есть автоматические аллокаторы ресурсов для многоузловой конфигурации.
• Готового автоматического файловера, увы, нет. Heartbeat + fencing в помощь. У нас таких задач пока не было, так что и в дистре нет.
• IaaS - это, все-таки, больше красивое слово, чем что-то конкретное.

Ganeti - не универсальное решение, но он хорошо решает определенный круг весьма востребованных проблем.

Спасибо за пояснение, я немного вчитался в сайт и открыл для себя такое понятие как «высокая надежность» что никак не является «высокой доступностью». Понятие вполне разумное, но за десяток лет занятия кластерами ни разу такое не встречал.

Насчет же IaaS я имею ввиду не расплывчатый фреймворк типа openstack а вполне конкретные решение которые все знают и любят типа oVirt/vSphere/Proxmox/etc... именно поэтому я написал не просто IaaS a SVI/IaaS :)

Наверное данное решение вполне подойдет для мелких стендов, но на крупные ДЦ вряд ли

Наверное данное решение вполне подойдет для мелких стендов, но на крупные ДЦ вряд ли

Думаю, это чертовски верное высказывание(разве что «стенд» - неудачное слово, ибо оно и в продакшне работает).

Я считаю что варианты с дрбд - для тех, кому варианты с отказоустойчивой СХД не нужны/недоступны.

Однако, в меньших масштабах можно получить большинство тех же фишек и на drbd. При меньших финансовых затратах.

честно говоря, drbd как локальное решение, меня очень мало привлекает (я его использую только когда пишу автоматизацию DR, нацеленную на реплицируемые СХД в реальном мире, чтоб репликацию эмулировать). репликация дисков асинхронно, через WAN это уже интереснее, но вряд ли подойдет для виртуализации в каких либо серьезных масштабах.

мой локальный ДЦ это RHEV, с отдельно стоящим сервером отдающим iscsi+nfs, и даже это не продакшен, а просто бюджетный вариант, для разработки - в продакшене все намного серьезнее. drbd как способ объединить локальные диски хостов в общий для всех LUN, имхо не комильфо, особенно когда хостов сотни, для такого годится разве что гластер

тут просто куча восторгов по поводу решения, и я сначала не врубился где эта особая уличная магия, а оказалось что тут нет ни HA, ни, соответственно SBA, отсюда и мое заключение выше

Ну почему же, HA здесь есть(может, не в том виде, что Вы хотите), а что такое SBA - поясните, пожалуйста.

А вот чего тут точно нет - так это особой уличной магии :)

drbd как способ объединить локальные диски хостов в общий для всех LUN, имхо не комильфо, особенно когда хостов сотни, для такого годится разве что гластер

с помощью drbd невозможно объединить локальные диски сотни хостов в общий для всех LUN. drbd работает только с двумя хостами, и вся логика работы такого кластера отталкивается от того, что каждый волюм доступен только на двух нодах, со всеми вытекающими.

Ну почему же, HA здесь есть(может, не в том виде, что Вы хотите), а что такое SBA - поясните, пожалуйста.

HA - процесс автоматизированный, тут же ясно сказано что это не высокая _доступность_ а высокая _надежность_ (гляньте на оффсайт), что означает маленький локальный DR-чик а не HA. DR между двума локалхостами - штука не особо нужная, потому что защищает только от падения локалхоста, и то не автоматически, как кластер HA, при этом от падения всего ДЦ оно не защищает.

SBA - split brain avoidance, стандартная часть любого HA

с помощью drbd невозможно объединить локальные диски сотни хостов в общий для всех LUN. drbd работает только с двумя хостами, и вся логика работы такого кластера отталкивается от того, что каждый волюм доступен только на двух нодах, со всеми вытекающими.

емнип, там все таки можно больше чем два клона, но не буду спорить, это не так важно. важно то что помимо того, что данная конструкция это не кластер а скорее что то типа локального DR, и HA тут нет, управление такой конструкцией возможно только в маленьких размерах.

Тут нет проблемы с SBA. Максимум, что можно получить (от довольно бестолкового обращения с кластером) - это два одновременно работающих в сети клона ВМ. Но их дисковые системы в этот момент будут разделены на независимые половинки и не смогут друг друга испортить.

SBA - это не часть HA, а архитектурная проблема, которая появляется, когда для того, чтобы реализовать HA дают одновременный доступ к одному сетевому LUN для двух узлов (например, с сетевого хранилища по iSCSI). В DRBD можно устроить похожую ситуацию, если включить его в Primary/Primary.

Но Ganeti не использует Primary/Primary даже при живой миграции (он разделяет DRBD на половинки, потом мигрирует, а потом собирает обратно).

А что касается автоматического HA, то «из коробки» его нет, но это не фатально. Если кому-то реально и предметно нужен - давайте общаться.

Тут нет проблемы с SBA. Максимум, что можно получить (от довольно бестолкового обращения с кластером) - это два одновременно работающих в сети клона ВМ. Но их дисковые системы в этот момент будут разделены на независимые половинки и не смогут друг друга испортить.

как это «половинки»? если у меня две машины пытаются использовать один виртуальный диск, в лучшем случае диск перемонтируется в r/o, а в худшем будет поврежден. если обе ВМ работают с диском который расположен в реплицируемом томе drbd то испортить его могут так же как если бы он был на общем хранилище, или я чего-то не понимаю? вы меня простите, я не троллю, мне реально интересно понять

SBA - это не часть HA, а архитектурная проблема, которая появляется, когда для того, чтобы реализовать HA дают одновременный доступ к одному сетевому LUN для двух узлов (например, с сетевого хранилища по iSCSI).

не совсем, SBA нужен и при реплицируемом хранилище, a/a или a/p - не важно. иначе будут конфликты или потеря данных

В drbd каждая половинка может быть объявлена как Primary и как Secondary.

Если она Primary, то drbd дает к ней доступ как к блочному устройству. Вся запись в него реплицируется на вторую половинку.

Если она Secondary, то drbd не дает к ней доступа с локального хоста и эта половинка работает только на запись репликационных данных, принимаемых от ее удаленной пары. (Хотя, если дисковая система удаленной пары погибнет, то удаленный хост начнет обращаться к ней и с запросами на чтение).

В режиме Primary/Secondary split brain невозможен.

В режиме Primary/Primary предоставляется одновременный доступ. Официально этот режим рекомендован только для софта типа GFS, который самостоятельно отвечает за консистентность.

В «рукодельной» конфигурации xen+drbd, если нужна возможность живой миграции, то drbd тоже надо включать в Primary/Primary. В этом случае админ сам отвечает за то, что не допустит одновременного запуска виртуалки на двух узлах. Иначе файловая система, естественно покоробится - будет split brain.

Возможен другой способ - я его описал в предыдущем сообщении. Но руками так никто не делает, потому что долго и лениво - живая миграция превратится в «неживую» :) А с Ganeti - это одна команда gnt-instance migrate, остальное все сделает искусственный разум.

Можно предположить третий вариант - когда узел отключается от сети и на резервном активируется копия виртуалки. Но в этом случае копия активируется в режиме с одной половинкой и со второй половинкой взаимодействовать откажется, даже если она вернется в сеть.

Но если она все-таки вернется, то Ganeti все правильно поресинкает в нужном направлении (для архитектуры Ganeti это тривиальная задача).

Поэтому SB не будет.

Вдогонку: DRBD работает не как iSCSI LUN. Т.е., тут нет единой точки входа к которой могут конкурентно обращаться два хоста.

DRBD - это дисковый том, который создан в двух экземплярах (т.е. одновременно на двух хостах), и эти копии тома (= половинки) синкаются.

У каждого хоста получается своя индивидуальная локальная точка входа, и активный хост просто физически не пустит «левые» данные на свою копию, которую он считает первичной.

ага, теперь уже понятнее. при фейловере первый узел блокируется, и репликация останавливается, до вмешательства админа. То есть фейловер тотальный, (как в neverfail или в нетаповских метрокластерах), и все что можно сделать это запустить синк руками, в обратном направлении, так?

HA - процесс автоматизированный

Совсем не обязательно. Высокая доступность - термин достаточно общий, и автоматизированный/не автоматизированный failover - это всего лишь один маленький аспект, не влияющий на доступность(скажем, надо нам простой ограничить 10 минутами, и нам не важно, кнопку кто-то нажмет или она сама отработает), да и к тому же автоматический фейловер здесь тоже можно организовать, просто мы ориентируемся на небольшие бюджетные кластеры, где правильная организация автоматического фейловера увеличит расходы заметно, и поэтому вряд ли будет востребовано.

важно то что помимо того, что данная конструкция это не кластер

Кластер - тоже очень общий термин, и под него подходит и наша система. Причем кластеры вовсе и без HA бывают.

HA тут нет

есть

управление такой конструкцией возможно только в маленьких размерах.

Абсолютно верно.

ага, теперь уже понятнее. при фейловере первый узел блокируется, и репликация останавливается, до вмешательства админа. и все что можно сделать это запустить синк руками, в обратном направлении, так?

На самом деле, здесь по разному может быть, в зависимости от ситуации(у нас в вики расписаны процедуры в зависимости от ситуации). В каких-то случаях после включения упавшей ноды даже не придется ничего делать, в большинстве случаев - дать одну команду verify-disks, которая и сделает все синки в нужных направлениях сама.

Совсем не обязательно. Высокая доступность - термин достаточно общий, и автоматизированный/не автоматизированный failover - это всего лишь один маленький аспект, не влияющий на доступность(скажем, надо нам простой ограничить 10 минутами, и нам не важно, кнопку кто-то нажмет или она сама отработает), да и к тому же автоматический фейловер здесь тоже можно организовать, просто мы ориентируемся на небольшие бюджетные кластеры, где правильная организация автоматического фейловера увеличит расходы заметно, и поэтому вряд ли будет востребовано.

Высокая доступность, это минимальный даунтайм, даже когда рядом нет админа, иначе и возможность сделать бекап/рестор можно назвать высокой доступностью. Автоматический фейловер тут ключевой компонент.

Кластер - тоже очень общий термин, и под него подходит и наша система. Причем кластеры вовсе и без HA бывают.

бывают, но в данном случае, так как это не HA, система не подпадает под определение HA кластера, а под все остальные определения (HPC например) тем более

есть

http://en.wikipedia.org/wiki/High-availability_cluster HA clustering remedies this situation by detecting hardware/software faults, and immediately restarting the application on another system without requiring administrative intervention, a process known as failover.

спорить не о чем, если даже на оффсайте решение не названо высокодоступным, а высоконадежным, что совсем не одно и то же. Скриншот приложить? :)

На самом деле, здесь по разному может быть, в зависимости от ситуации(у нас в вики расписаны процедуры в зависимости от ситуации). В каких-то случаях после включения упавшей ноды даже не придется ничего делать, в большинстве случаев - дать одну команду verify-disks, которая и сделает все синки в нужных направлениях сама.

а как эта команда узнает какое направление нужное? есть дополнительная метадата, или паксос?

а как эта команда узнает какое направление нужное? есть дополнительная метадата, или паксос?

Кластер-мастер имет записи о том, на каких двух узлах лежит виртуалка и какой из сейчас активный. Узлы сами ничего не делают - именно на кластер-мастер дает и команды на синк и на запуск виртуалок.

Соответственно, направление синка будет всегда с активного на неактивный узел.

(Кластер-мастер имеет резервные, неактивные дубликаты на нескольких узлах, так что его простая авария погубить не сможет).

о, это уже знакомые понятия :) а этот кластер мастер, это что - демон? кусок метадаты, а-ля кворум?

Это демон плюс файлы с данными в /var/, в которых хранится описание всего кластера, параметров старта виртуалок, их дисков, сети.

Мастер ходит к узлам и дает им команды плюс поверяет состояние и консистентность.

При изменении параметров кластера содержимое копируется на другие узлы, помеченные как master-candidate.

отлично, спасибо за терпение :)

Высокая доступность, это минимальный даунтайм, даже когда рядом нет админа, иначе и возможность сделать бекап/рестор можно назвать высокой доступностью. Автоматический фейловер тут ключевой компонент.

По трезвому размышлению склонен с Вами в целом согласиться :)

Плохо:
/etc/modprobe.d/drbd

должно быть:
/etc/modprobe.d/drbd.conf


Плохо:
/etc/apt/sources.list пустой.
Тыкните туда зеркала яндекса хотя бы.

должно быть:
/etc/modprobe.d/drbd.conf

Спасибо за наводку, упустили где-то.

/etc/apt/sources.list пустой.

Ни разу не сталкивались. Как воспроизвести?

Ни разу не сталкивались. Как воспроизвести?

Тупо установкой. Вернее, он не пустой, а там только один репозиторий - дисковый, вместо сетевых. Попробуйте на виртуалку установить, скорее всего встанет так же.

Кстати, что показалось странным - при установке не спрашивает IP адреса других нод. Было бы удобнее, если бы спрашивал и делал все настройки сам :)

Вернее, он не пустой, а там только один репозиторий - дисковый, вместо сетевых. Попробуйте на виртуалку установить, скорее всего встанет так же.

Так и задумано. Суть в том, что не предусматривается каких-то сумасшедших манипуляций с нодами(для которых не хватит локальных пакетов) до установки сервисной виртуалки, а после установки виртуалки ноды настраиваются на approx на этой виртуалки.

Впрочем, раз уж поступил запрос, мы обдумаем его и, возможно, внесем изменения.

Кстати, что показалось странным - при установке не спрашивает IP адреса других нод.

Ну в данном случае без разницы где сделать эти настройки - в инсталлере либо позже в sci.conf. Тем более ноды устанавливается две, и задавать дважды настройки для двух нод - неудобно. А в sci.conf нужно прописывать только один раз.

Было бы удобнее, если бы спрашивал и делал все настройки сам :)

Разумеется. Но как вторая нода узнает свои настройки от первой при установке - вопрос :) Особенно если топология сети хитрая. Так что увеличение степени автоматизации настроек сети пока что не планируется.

имя файла в modprobe.d исправили, еще раз спасибо.

по поводу sources.list - как я уже сказал, такова задумка - после установки сервисной виртуалки подключаются сетевые репо через approx(автоматом), а до установки сервисной виртуалки вряд ли понадобится что-то ставить из сети, все необходимое есть на ISO. Впрочем, опять же, руками никто не мешает прописать это.

имя файла в modprobe.d исправили, еще раз спасибо.

Нзчт :) Переезжайте на квм и будете шикарными!

Мы используем xen в sci-cd потому, что это у нас накатанное промышленное решение. Ну, и не только у нас.

У kvm действительно довольно много интересных фич, но о его широком применении в корпоративном продакшине я никогда не слышал (тут я только за себя говорю и интересуюсь).