Кластер - несколько вопросов

[NiTr0]

Появилось желание поднять вместо зоопарка серверов кластер с виртуализацией (скорее всего Xen). Однако - возник вопрос по организации ФС для хранения собссно образов ОСей.
Пока что рассматриваю следующие варианты (промышленные SAN - исключил ввиду их цены):
1) DRBD, на slave сервере - доступ каким-то извратом к мастеру (NFS или что-то типа того), при падении мастера - монтировать зеркало; либо - работа master-master: выглядит сложно и хлипко, притом - совсем алогично
2) Выделенный NAS с NFS (или чем-то подобным), остальные (вычислительные) ноды - бездисковые: выглядит просто и логично, но ненадежно - падение наса = падение кластера; да и плодить сервера неохота, нагрузка будет не такая уж и большая; хотя - с другой стороны, на NAS можно и SQL базу поднять в dom0, т.к. ИМХО для SQL на VM будут большие накладные расходы на виртуализацию
2а) Модифицированный вариант 2) - NAS+нода кластера в одном флаконе (для более эффективного использования ресурсов сервера), все остальное - так же: преимущества/недостатки те же
3) RAID1 из разделов с образами, объединенных по ATAoE/iSCSI. Выглядит вполне логично, на первый взгляд - надежно, и быстрее чем п.1 (т.к. запросы чтения будут распределяться по серверам). Однако - что будет при сбое записи на один из винтов, мне представить трудно - скорее всего рэйд развалится

Собссно пока склоняюсь либо к 2/2а, либо к 3 варианту (в зависимости от того, как поступим с SQL сервером/серверами). Интересует мнение людей, сталкивавшихся с сабжем.

Собссно вопросы - не упустил ли я еще какой-то из очевидных вариантов? И работал ли кто с ATAoE, как оно по стабильности (по найденым единичным отзывам в инете - вроде как вполне ничего)?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Alex_hha]

Сделай raid10. При сбое одного винта в raid1 ничего не будет

[Gerk]

А чем Вам не подходит RAID10 сам по себе или + DRBD? причём DRBD рекомендовано для того случая,
когда 5 минут downtime >= штраф больше чем месячная зарплата админа, или есть возможность распихать ноды по разным серверным.

[NiTr0]

Сделай raid10. При сбое одного винта в raid1 ничего не будет

Вопрос не в том, как это реализовать на одной машине - а в том, как сделать надежное хранилище, доступное с разных нод на чтение-запись, и в то же время с минимальной веротностью падения (с резервированием).
RAID1 из 2х программных SAN/NAS - заманчиво, только что будет, если на одной из нод кластера отвалится один из "дисков", а на другой рэйд1 продолжит функционировать - для меня пока что остается загадкой... Думается, ничего хорошего в такой ситуации не выйдет.

А чем Вам не подходит RAID10 сам по себе или + DRBD? причём DRBD рекомендовано для того случая,
когда 5 минут downtime >= штраф больше чем месячная зарплата админа, или есть возможность распихать ноды по разным серверным.

Я не представляю, как DRBD будет работать при записи на раздел на обеих нодах - не возникнет ли split-brain, и что делать потом при возникновении split-brain - часть данных будет акутальной на одном разделе, часть - на другом Разве что синхронизировать только файлы образов виртуальных машин - ведь в один момент времени запись в файл возможна только с одной ноды, до тех пор, пока виртуальная машина не мигрирует с данной ноды на другую...

[paix]

Появилось желание поднять вместо зоопарка серверов кластер с виртуализацией (скорее всего Xen). Однако - возник вопрос по организации ФС для хранения собссно образов ОСей.
Пока что рассматриваю следующие варианты (промышленные SAN - исключил ввиду их цены):

я бы посоветовал ориентироваться на kvm.
а если нужно запускать линух на линухе - то вообще openvz возьмите,

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

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

резервирование в простейшем случае осуществляется при помощи бекапов.
например, в openvz через vzdump снапшоты делаются очень быстро, и разворачиваются
на соседнем сервере за минуты.

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

рост архитектуры будет осуществляться путем добавления новых
серверов виртуализации, либо доавления новых пар HA серверов
(DRBD master - slave)

[NiTr0]

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

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

Насчет отказоустойчивости - хочется ее совместить с балансировкой нагрузки. Хотя бы потому, что ноды все равно не будут загружены виртуалками на 100%. И ессно на свежесобранный кластер в первую очередь будут перемещены не жизненно важные сервисы (чтобы минимизировать последствия возможных крашей при отладке). Тем более, что из жизненно важных - только корпоративная БД и биллинг...

Хранилище буду таки делать отдельно (скорее всего совмещу сервера БД с NAS - т.к. сильно большие накладные расходы на виртуализацию БД будут ИМХО), присматриваюсь к HaNFS для доступа к хранилищу (кстати никто с ней не сталкивался?).

P.S. Спасибо всем за ответы, архитектура будущего кластура уже более-менее вырисовывается.

[NiTr0]

Итак, поднял в качестве эксперимента CRM Ganeti - довольно симпатичная по части настройки/управления (до того пробовал OpenQRM и Pacemaker - первый не устроил некой извращенностью логики и ограниченностью функционала, второй - сложностью). Хотя есть много, кхм, особенностей работы (как собссно Ganeti, так и KVM).
Нашел для нее вебку ganeti-manager (в стадии глубокой альфа, но функции монтиоринга выполняет, а большего от нее не сильно и нужно) - для наглядного мониторинга состояния нод кластера.

[_kirill_]

У меня стоит аналогичная задача. Думаю повесить на отдельный сервер рэид массив 5-ого уровня + NFS или iSCSI, скорее всего NFS, т.к. он умеет работать по UDP. Также выбор пал на XEN, и на ос CentOS.

[NiTr0]

ИМХО - DRBD массив + HaNFS на 2 (или более - еще не читал о возможностях DRBD) нодах. Думается, оптимальное решение будет...

[Guest_kirill]

ИМХО - DRBD массив + HaNFS на 2 (или более - еще не читал о возможностях DRBD) нодах. Думается, оптимальное решение будет...

У нас часто свет вырубается, начальство упсы покупать не хочет, думаю в таких условиях DRBD лучше не использовать, потом со SPLITBRAIN`ом мучаться...

[NiTr0]

Насколько я понял из беглого чтения DRBD доки, это - редкое явление, и происходит сплит-брэйн только при длительном отсутствии (единицы секунд) связи между серверами (т.е. - сервера друг друга не видят, и каждый считает, что сосед умер - следовательно нужно быть мастером).
Хотя, если нет требования высокой надежности для кластера - вполне можно обойтись и одной нодой-NAS.

[Alex_hha]

начальство упсы покупать не хочет

и кластер - не своместимые понятия

[NiTr0]

не своместимые понятия

Ну если под кластером имеется ввиду некая ферма бездисковых нод, на которых крутятся виртуалки, и основная задача которой - не обеспечить надежность, а уменьшить кол-во/стоимость железа за счет "упаковки" на одну мощную машину кучки нетребовательных образов - то тогда кластер и без упсов сможет работать...
Другое дело - а стоит ли экономить на упсах? Ведь какой-то Powercom KIN-2000 спокойно тянет стойку из 7-10 машин, а при наличии прямых рук и 4х автомобильных аккумов типа 6СТ-100 - о проблемах с отключением света можно забыть, стойка будет до 12 часов на этих аккумах пыхтеть весело...
Но тут уже начальству виднее... Хотя - после первого же падения чего-то вроде бухгалтерии или корпоративной БД, думаю, мнение начальства сразу же изменится

[paix]

не своместимые понятия

Ну если под кластером имеется ввиду некая ферма бездисковых нод, на которых крутятся виртуалки, и основная задача которой - не обеспечить надежность, а уменьшить кол-во/стоимость железа за счет "упаковки" на одну мощную машину кучки нетребовательных образов - то тогда кластер и без упсов сможет работать...

это называется консолидация ресурсов, а не кластер.
делать упсы из акумов - не админская работа.

[m0ps]

для того, что б не возникал split-brain нужно задействовать stonith (http://www.linux-ha.org/STONITH)

я летом изучал данный вопрос и проводил тестирования (самому скоро придется подымать HA SAN)

подход к СХД таков:
DRBD (master/master) на двух нодах с поднятым на них iSCSI таргетом (экспортируем не блочное устройство а файл, который лежит на разделе с кластерной фс - gfs либо ocfs). Heartbeat управляет общим ip таргета, и что б обезопаситься от ситуации с split-brain используем stonith (в бюджетном варианте через нуль-модемный кабель).

[m0ps]

тут (http://communities.vmware.com/docs/DOC-10964) есть пример (правда без stonith)

[paix]

ну вот на кой вам сдался master-master ?
сделайте master-slave и забудьте про этот секс.

[m0ps]

ну вот на кой вам сдался master-master ?
сделайте master-slave и забудьте про этот секс.

не всегда master/slave позволяет реализовать необходимое. ярчайший пример - СХД для VMware ESX(i)

[_kirill_]

ну вот на кой вам сдался master-master ?
сделайте master-slave и забудьте про этот секс.

когда мастер вырубается, слэйв нода при этом read-only?? Если да, то за чем оно(master-slave) нужно?

[NiTr0]

когда мастер вырубается, слэйв нода при этом read-only??

Нет, слэйв нода при этом становится мастером. Если я правильно понял доку (давненько читал)

[paix]

ну вот на кой вам сдался master-master ?
сделайте master-slave и забудьте про этот секс.

не всегда master/slave позволяет реализовать необходимое. ярчайший пример - СХД для VMware ESX(i)

конкретней можно описать пример?

primary\slave - это классическая формула построения highavailability серверов.
Я тестировал на примере heartbeart + drbd и баз данных. Простое и прозрачное решение.
Если данные более критичные - то покупаете san\nas и завязываете ноды на этот сторедж.

[m0ps]

конкретней можно описать пример?

да я вроде на этом форуме уже писал об этом...
ладно, повторюсь:

к примеру есть хост с vmware esx, нужно обеспечить отказоустойчивость СХД для него. если поднять drbd кластер как master/slave для обеспечения отказоустойчивости iSCSI таргета, то при выходе из строя master ноды датастор отваливается от esx-a на несколько минут (до 10), хотя фактически таргет недоступен всего пару секунд (пока он запустится на slave ноде). в случае если кластер master/master время отсутствия iSCSI таргета менее секунды (т.к. на обоих нодах он всегда запущен) и esx этого не замечает.
если копнуть в гугле по теме drbd esx - то можно найти кучу подтверждений моих слов.


и еще один плюс master/master - можно настроить какое-то подобие LB SAN для ESX(i) кластера

[paix]

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

сама технология master-slave работает отлично на самых разнообразных системах.
Мастер-мастер верный путь к геморою, в большинстве случаев. И оверхеад на накладные ресурсы.

Более простые решения = более хорошие решения.

[m0ps]

все равно не понимаю проблемы.

потому что не сталкивался...

а я вот не понимаю где геморрой с master/master. я проблем никаких не наблюдал...

[paix]

все равно не понимаю проблемы.

потому что не сталкивался...

с vmware на шаред сторадже - не сталкивался.

а я вот не понимаю где геморрой с master/master. я проблем никаких не наблюдал...

ну ну, попробуйка водрузи, например, oracle на master/master storage...;/
master\slave - простое и стабильное решение.