кластеро-строение + vmware

[alexp]

Господа-коллеги!
Отстал от жизни, подскажите, какие сейчас есть правильные варианты в кластеро-строении так сказать для целей кластеризации OES?
Условно: есть два физических сервера OES, на одном файлы+ftp (много файлов, ftp ооочень нужен) на другом POA от групвайза. Очень надо минимизировать простои при обновлении всяких линуксов, OES ов, firmware и тд.
Сперва было желание поднять пару хостов vmware, пробросить туда через VMDirectpath I/O LUNы с СХД и запилить там ноды для кластера. (в документации по OES даже картинка есть с настройками)
Но тут вылезают разные ограничения, пугают, что нельзя мешать в кластере физические и виртуальные сервера, снапшотов опять-таки делать не получится, VMDirectpath I/O может только один адаптер пробросить к виртуалке, второй нужен для vmware, для доступа к datastore.
Вообщем как-бы получается или мучиться с физическим железом (что технологически неудобно, даже сервер заменить достаточно трудоемко), или уходить полностью в виртуализацию (тут с производительностью непонятки, да и все эти гигабайты надо на vmfs переносить).

Вопрос: подскажите, как нынче модно и правильно делать кластера?

[URRY]

Виртуализация наверное благо , но в данном случае лишнее. используй стандартный кластер NCS и будет счастье.
все естественно ИМХО

[Radik]

Попробуйте использовать raw device mapping в среде vmware. У нас так работае кластер NW с файловым ресурсом.

[Иван Левшин aka Ivan L.]

Есть штатный кластер в VMware - можно использовать его. Но он денег стоит Стандартного NCS хватит за глаза (в OES число узлов "забесплатно" увеличили). Вообще говоря, я бы совсем ушел в виртуалки - если следовать рекомендациям (в идеале "один сервис - один сервер"), получится дорого, да и часть ресурсов будет просто неэффективно простаивать. КПД от железа с виртуализацией больше. Но обязательно надо четко планировать архитектуру и особенности решения. Там тоже погремушек хватает - кластер на "физике" строить проще. Касаемо смешивания виртуалок и физики - вообще говоря, стандартным требованием для кластера является полная идентичность как железа, так и софта (в т.ч. по версиям). В случае с таким образом смешанным кластером выполнить его довольно трудно - порой просто нереально. Вообще говоря, сам лично видел чудеса в кластере NW, происходившие оттого, что прошивки HBA обновили хаотично и они были разными на трех узлах.

[URRY]

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

[Константин Ошмян]

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

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

Но Иван, конечно, скажет более авторитетно

[Иван Левшин aka Ivan L.]

Иван это специально не выяснял - говорю по презентации, где в "New Features" была заявлены "бесплатно +2 узла". Если честно - учитывая, что NCS есть Fault Tolerance чистой воды и LB там нет, я не вижу особого смысла в более чем двух узлах в кластере. Из моей практики - двух узлов достаточно в 99% случаев. Оставшийся 1 - ну, это когда заказчику деньги девать некуда
Для LB есть SuSE Cluster, который со STONITH и прочими приседаниями. На мой вкус - NCS лучше просто потому, что он проще, у него нет этой замороченности HA (и микрософтного кластера, который, опять же - на мой вкус, "элегантно стянут" с классического линуксового НА). LB для файловых операциях не сказать, чтобы и нужен, его профиль - распределенные вычисления. Да и то нужна поддержка со стороны приложений - они должны уметь работать в LB. При этом, допустим, у Exchange есть LB - если сравнить с GW, то GW ресурсов требует намного меньше, работает быстрее и т.д. В общем и целом - LB там есть, смысла в нем, на мой взгляд - нет. За пределами вычислительных датацентров типа МГУ я вообще не понимаю, зачем надобен функционал LB. FT отлично справляется даже с двумя узлами - добавление третьего и далее узлов не настолько повышает готовность системы, насколько это ее усложняет. Все это субъективно, конечно, на истину в последней инстанции я не претендую.

Что еще вспомнил по изначальной теме: если отдать в NCS, работающий в VMware, физику (RAW) - придется отдавать целиком массив, никакие другие машины до момента, пока активен узел, которому предоставлен такой доступ, до него не достучатся. Это может быть очень и очень неудобно - да и настраивается оно (как минимум - настраивалось в 5.0) нетривиально. В общем - путей несколько, надо просто внимательно и аккуратно проработать каждый из них и решить, что же, собственно, именно для Вас будет наиболее оптимальным вариантом.

По 4-узловому кластеру - уточню и отпишусь.

[alexp]

Третий узел насколько я помню, нужен для адекватного голосования в случае нарушений связности, т.к. три это адекватнее
Удивляет вот что:
https://www.novell.com/documentation/oe ... l_mixtures

Mixtures or Subsets of All of the Above#
In Figure 3-4, the NCS cluster combines physical nodes with a virtual node from a VMware host. All nodes are running the same version of the OES operating system

Т.е. я правильно понимаю, в доке написано, что можно смешать ноды на физическом сервере и ноды на VM? Дичь какая то, или все так стало продвинуто, что пофиг?

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

[Иван Левшин aka Ivan L.]

В NCS третий узел - ровно такой же, как и первые два. Вы путаете с HA и производными (тем же MS) - там оно нужно, причем один узел занимается ровно синхронизацией и связностью. NCS работает совсем-совсем не так: связность и синхронизация обеспечивается через сеть (причем не выделенную, в отличие, опять же, от HA - там настоятельно рекомендуется физически выделенный сегмент, в NCS все прекрасно бегает по общей сети вместе с данными) посредством Hearthbeat (с настраиваемым интервалом), а также через специальный раздел в хранилке (SBD, Split Brain Detection). С точки зрения классической ФС это даже не раздел - это некий "огород" размером даже в 10-20 Мб (сейчас нарезают много больше, многотерабайтные хранилки либо вообще не умеют там мелко нарезать, либо ацки коряво используют такой маленький объем. Смешно, но если в современной EMC нарезать 10 метров - работать он будет медленнее, чем соседний гиговый. По крайней мере, мне так объяснили ). В SBD каждый из узлов прописывать с определенным интервалом свою метрику - общий смысл ее в том, что "я тут, я живой". Иными словами - тот же Hearthbeat, на в хранилке. Так вот оно и работает - одновременно пишет в хранилку и шлет HB-пакеты. Все процессом управляет т.н. "мастер"-узел - он выбирается самим NCS автоматически, это такой же точно узел, он делает все то же самое, что и остальные - но до кучи еще и за здоровьем кластера следит. Если он в определенный момент не обнаруживает запись от узла в хранилке либо не получает от него HB-пакет, он тут выписывает "ядовитую пилюлю" (poison pill) этому узлу. Выглядит это, кстати, как вполне себе kernel panic (в NW сервер просто вываливался в дебаггер), что, мягко говоря, сильно пугает недостаточно опытных админов Они тут же во все лопатки начинают искать несуществующую проблему - таким образом сразу видно нерадивых, не читающих до конца документацию. В свою очередь, прочие узлы следят за мастером и с удовольствием прибивают и его, если он вдруг становится "потеряшкой". Делается именно так, чтобы моментально вывести узел из эксплуатации - это самая быстрая операция, штатная выгрузка сервиса времени занимает многократно больше. Так что ничего военного тут нет. Основной смысл такой поспешности - максимально снизить риск повреждения данных в хранилке (оставшиеся узлы автоматически начинают "поднимать" упавший ресурс. Если тратить время на штатное выключение сервиса (может занимать до минут) - может получиться так, что один и тот же LUN будет смонтирован на двух узлах. NSS, конечно, штука исключительно умная - но, во-первых, от "неизбежных на море случайностей" никто не застрахован (даже NSS), во-вторых - POSIX не имеет таких средств защиты, а их (POSIX-ресурсы) тоже можно завести в кластере.
К чему столько букв я написал? К тому, чтобы было понятно, почему NCS не нужно обязательно три узла Простейший кластер NCS вообще состоит из одного узла Это не по феншую - но работает точно.

Касаемо смешивания виртуальных и физических узлов - это заработает, но лично я своим заказчикам советую выбрать что-то одно. Ничего хуже, чем кластер с разношерстными узлами, быть не может. Очень несмешные ситуации возникают - даже несмотря на то, что NCS и NSS палкой не убьешь, то, от чего они зависят, начинает выкидывать коленца. Вообще говоря, смешанные кластера рекомендуется использовать только во время миграции - либо с версию на версию ОС (NW+OES), либо при переезде с физики в виртуалки или наоборот.

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

[Константин Ошмян]

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

Решил уточнить этот момент, верно ли отложилось в памяти. Да, всё верно.

Документация по OES2015sp1 говорит:

Open Enterprise Server 2015 SP1 includes support for a two-node Novell Cluster Services cluster.

The full Novell Cluster Services product (available through a separate purchase) is a multinode clustering product that [...] can include up to 32 servers.

Откуда же взялись 4? О вот из этого промоушена:

When you upgrade or deploy a new Open Enterprise Server 2015 Cluster Services setup, you will receive 4 additional cluster nodes at no extra cost if you purchase maintenance on those additional nodes at list price.
This promotion is applicable only if all the nodes in your cluster are running Open Enterprise Server 2015.
This promotion is for VLA/MLA customers only.

[Андрей Добров]

Господа-коллеги!
Отстал от жизни, подскажите, какие сейчас есть правильные варианты в кластеро-строении так сказать для целей кластеризации OES?
Условно: есть два физических сервера OES, на одном файлы+ftp (много файлов, ftp ооочень нужен) на другом POA от групвайза. Очень надо минимизировать простои при обновлении всяких линуксов, OES ов, firmware и тд.
Сперва было желание поднять пару хостов vmware, пробросить туда через VMDirectpath I/O LUNы с СХД и запилить там ноды для кластера. (в документации по OES даже картинка есть с настройками)
Но тут вылезают разные ограничения, пугают, что нельзя мешать в кластере физические и виртуальные сервера, снапшотов опять-таки делать не получится, VMDirectpath I/O может только один адаптер пробросить к виртуалке, второй нужен для vmware, для доступа к datastore.
Вообщем как-бы получается или мучиться с физическим железом (что технологически неудобно, даже сервер заменить достаточно трудоемко), или уходить полностью в виртуализацию (тут с производительностью непонятки, да и все эти гигабайты надо на vmfs переносить).

Вопрос: подскажите, как нынче модно и правильно делать кластера?

Что-то странное в этой в конструкции.... До VMware или физических серверов - кластер был спасением, но очень дорогим.
Если имеем vSphere и больше чем один хост, то на VMware можно сделать/настроить автоматическую миграцию между хостами при выходе/отказе одного из хостов.
Конечно есть условие
- наличие лицензии на VMware позволяющей делать эту функцию
- изначально приличную хранилку, т.к. отказ оной губителен для всей инфраструктуры.

P.S. Данную функцию можно использовать и как автоматическую балансировку загрузки между хостами.

[Иван Левшин aka Ivan L.]

И то, и другое - суть кластер. Разница в функционале и сложности решения - и в деньгах, конечно же.

[Ковалев Артем]

Господа-коллеги!
Отстал от жизни, подскажите, какие сейчас есть правильные варианты в кластеро-строении так сказать для целей кластеризации OES?
Условно: есть два физических сервера OES, на одном файлы+ftp (много файлов, ftp ооочень нужен) на другом POA от групвайза. Очень надо минимизировать простои при обновлении всяких линуксов, OES ов, firmware и тд.
Сперва было желание поднять пару хостов vmware, пробросить туда через VMDirectpath I/O LUNы с СХД и запилить там ноды для кластера. (в документации по OES даже картинка есть с настройками)
Но тут вылезают разные ограничения, пугают, что нельзя мешать в кластере физические и виртуальные сервера, снапшотов опять-таки делать не получится, VMDirectpath I/O может только один адаптер пробросить к виртуалке, второй нужен для vmware, для доступа к datastore.
Вообщем как-бы получается или мучиться с физическим железом (что технологически неудобно, даже сервер заменить достаточно трудоемко), или уходить полностью в виртуализацию (тут с производительностью непонятки, да и все эти гигабайты надо на vmfs переносить).

Вопрос: подскажите, как нынче модно и правильно делать кластера?

Что-то странное в этой в конструкции.... До VMware или физических серверов - кластер был спасением, но очень дорогим.
Если имеем vSphere и больше чем один хост, то на VMware можно сделать/настроить автоматическую миграцию между хостами при выходе/отказе одного из хостов.
Конечно есть условие
- наличие лицензии на VMware позволяющей делать эту функцию
- изначально приличную хранилку, т.к. отказ оной губителен для всей инфраструктуры.

P.S. Данную функцию можно использовать и как автоматическую балансировку загрузки между хостами.

Можно. Но если у вас кластер OES (не важно, физический или виртуальный), то обновление его узлов - дело 20 минут в любой рабочий полдень. А если не кластер, то обновить этот хост часто можно только 1 января с 01:00 до 03:15 и никогда более потому как строго 24х7.