вложенная виртуализация.

[maxx]

Назрел вопрос, либо даже скорее рассуждение. Никто не задумывался установить биллинг в некое вычислительное облако. Суть заключается в построении отказоустойчивого кластера, для виртуальных машин, разнесенных (вплоть до географически) на разные хост-машины. Что бы при вылете любой из них, работоспособность сохранялась. Процесс обратный общепринятой вируализации, вместо то что бы на 1 хосте хранить несколько серверов, нужно на нескольких хостах хранить 1 сервер. fault tolerance от вмваре не подходит по одной причине, он включается только в случае отказа самой виртуалки. Ели же внутри виртуалки упадет какой либо процесс, кластер будет продолжать работать и думать что все хорошо. Есть у кого-то, какие идеи?

[Cell]

Я думал )))
Все реально, в случае установки двух тазов рядом друг с другом. В случае "вплоть до географически" - это фантастика. В таких кластерах очень важно обеспечить бесперебойную связь между серверами. Если связь нарушена - кластера больше нет )))

[h1vs2]

1) vmware vsa - максимум 3 хоста
2) vmware vsan - от 3-х хостов по схеме 2n+1 - на данный момент в бете и непонятно

Это из все в одном.

Классический вариант это отдельно сторейдж от вычислительных нод.

Например надо сделать две географически разнесенных площадки в кластере

1) Для этого нужно active-active кластер сторейджей :
   а) Железные решение NetApp, HP LeftHand и тд
   б) Платные решения  - Starwind, Open-e и тд
   в) Попробовать завести что-то opensource и халявное(оно или не работает, или работает так, что лучше бы не работало) : drbd, glusterfs со всякими костылями и тд
2) Собственно кластер вычислительных нод - на том же vmware(с костылями типа hearbreat для vcenter), proxmox и тд и тп

Разносим половину железа на один сайт, половину а другой. Соединяем все по iSCSI и получаем отказоустойчивый кластер.

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


P.S. Сами так ничего пока и не построили, активно изучаем тему. И потому да, согласен, пиздеть -  не мешки ворочать Но все таки разного рода тестирование привели меня к таким умозаключениям.
  

[sov]

Необязательно-же делать именно кластер? Для целей биллинга достаточно синхронизировать базу данных основного и резервного биллинговых серваков.

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

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

[h1vs2]

Необязательно-же делать именно кластер? Для целей биллинга достаточно синхронизировать базу данных основного и резервного биллинговых серваков.

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

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

Я думал речь идет о всем железном парке. А то что Вы описали решается намного более гуманным и не костыльным методом. Смотрите HAproxy, например :
http://mysql.wingtiplabs.com/documentation/hap225xe/fail-over-mysql-with-haproxy

[sov]

Я думал речь идет о всем железном парке. А то что Вы описали решается намного более гуманным и не костыльным методом. Смотрите HAproxy, например :
httр://mysql.wingtiplabs.com/documentation/hap225xe/fail-over-mysql-with-haproxy

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

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

[maxx]

Я думал )))
 В случае "вплоть до географически" - это фантастика

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

Если связь нарушена - кластера больше нет

то это есть штатный режим работы кластера, для того он и строится.
Мне просто нужно понять идею, как оно будет работать в случае если отваливается 1 хост. Для себя я нарыл либо хай авиалейбл, от вмваре, но там получется что нужен сторадж, и это узкое место. А фаулт толеранс  я уже писал почему не подходит. Все точто предлагают тут в топике не всисывается в ту концепцию как я это вижу. Тут предлагают дулибование резервирование, тоесть создание копий сервера и переключение между ними. Я же вижу это как ОДИН сервер, который хоститься одновременно на нескольких машинах и вс луче выхода из строя железа, нагрузка просто перекладывается на оставшиеся.

[Cell]

то это есть штатный режим работы кластера, для того он и строится.

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

[maxx]

то это есть штатный режим работы кластера, для того он и строится.

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

ну мне казалось что если нода А умерла по причине того что на ней сгорел блок питания или на тех. площадке А случился пожар, и сгорел ОДФ то линка как такового нету. А все должно продолжать работать.То есть по сути неважно почему пропал линк.Я не прав?

[stix]

и еще контроллер нод в придачу.

[Cell]

Я не прав?

В самую точку )
Когда линк пропал и нода А работает сама по себе а нода Б работает сама по себе - это уже два разных компа а не две ноды одного кластера и данные на них разные и не заменят они уже друг друга в случае восстановления связи т.к. не засинхронизируются по причине что не будут понимать какая из нод "более правильная" а какая "не очень правильная" и это решение должен принимать человек ))) вот здесь и начинается самое веселье )))

[maxx]

Я не прав?

В самую точку )
Когда линк пропал и нода А работает сама по себе а нода Б работает сама по себе - это уже два разных компа а не две ноды одного кластера и данные на них разные и не заменят они уже друг друга в случае восстановления связи т.к. не засинхронизируются по причине что не будут понимать какая из нод "более правильная" а какая "не очень правильная" и это решение должен принимать человек ))) вот здесь и начинается самое веселье )))

Вы говорите о каком-то конкретном решении или это как у меня только рассуждения? Просто насколько я читал, фаулт толеранс работает след образом. Есть два хоста, параллельно включенные в мир. Хост А - основной, хост Б резервный. Между ними отдельный гиговый линк по которому гипервизор А сливает копии процессорных операций гипервизору Б. По нему же хертбитом отслеживается жизнь гипервизора А. В случае если гипревизор А перестает отвечать, то гипервизор Б включается в работу и становится гипервизором А. Когда вышеший из строя хост включается в работу, он синхронизируется сам с гипревизором (теперь уже А), и становится резервным. Это решение от Вмваре. Однако там есть ограничения. 1 ядро на виртуальную машину и отслеживается только жизнеспосодность самой виртуалки а не того что крутиться в ней. То есть, если на виртуалке основного хоста, порашится база, ее копия покрашится и на хосте Б. Я собирал данное решение на стенде, все работает в 2 клика, как бы ничего сложного нету. НО! это не то как я себе это вижу. Это не создание облака. Меня же интересует облако распределеных вычислений. То есть единая виртуальная машина которая РАСПРЕДЕЛЯЕТ нагрузку по нескольким физическим серверам. Не дублирование, не реплицирование, не копирование. Это все будет сделанно между двумя облаками на логическом уровне. Тоесть как я вижу себе конечную схему. 4 хоста, разделенные на два независимых облака. в облаке 1 (А1-Б1) крутиться биллинг, в облако 2(А2-Б2) сливаются копии, в случает полного выхода из строя 1 облака, днс скриптом перекидывает всю работу на резервное облако. Географически это имеет вид немного другой. на первой техплошадке стоят хосты А1 и А2 на второй Б1 и Б2. как-то так. Но почитав посомтрев, я таки прихожу к выводу что хай авиалебл более экономически выгоден, но тут упираемся в сторадж.
П,С, дабы предупредить вопросы зачем козе баян, объясняю, есть идея создания датацентра для хостинга биллингов нескольких провайдеров. Вот пока пытаемся определиться с концепцией.

[stix]

идея создания датацентра для хостинга биллингов нескольких провайдеров. Вот пока пытаемся определиться с концепцией.

архитектура биллинга не позволит вам кластеризовать ряд вещей.

[elite]

бред! (с)

[h1vs2]

Мне просто нужно понять идею, как оно будет работать в случае если отваливается 1 хост. Для себя я нарыл либо хай авиалейбл, от вмваре, но там получется что нужен сторадж, и это узкое место. А фаулт толеранс  я уже писал почему не подходит. Все точто предлагают тут в топике не всисывается в ту концепцию как я это вижу. Тут предлагают дулибование резервирование, тоесть создание копий сервера и переключение между ними. Я же вижу это как ОДИН сервер, который хоститься одновременно на нескольких машинах и вс луче выхода из строя железа, нагрузка просто перекладывается на оставшиеся.

Я же вам написал, если не хотите, чтобы надо был сторейдж - смотрите в сторону vmware VSA, и VSAN - но тут куча своих граблей.

Ваша задача решается двумя сторейджами в актив-актив кластере, на разных техплощадках + 2 фермы вычислительных нод на разных техплощадках, тоже в нем же - кластере, средствами чего душа пожелает - хоть вмваре, хоть ксенсервер, хоть проксмокс.