14 августа 2020, 02:57

Цитата дня:

Никогда не спорьте с дураком - люди могут не заметить между вами разницы.


Создание и настройка кластера «VMware Fault Tolerance»

Автор STALKER_SLX, 08 января 2020, 21:15

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

Вниз

STALKER_SLX

Доброго времени суток уважаемые форумчане!
Имеется:
1. VMware vSphere 6.7.
2. Два идентичных сервера «HP ProLiant DL360p Gen8»:
- Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz;
- RAM - 64 Gb;
- RAID10 - 4xSSD 400Gb.

Нужно на базе вышеуказанного хозяйства настроить кластер «Fault Tolerance», очень-очень прошу у Вас помощи разобраться в этом «тёмном» для меня вопросе!


ival

FT звучит красиво, но бесполезно. Сразу говорю, я когда-то тоже бредил этой идеей. Реальность же очень плачевна. Почему?
Все просто:


ограничение для Standard в 2 vCPU на VM просто не жизнепригодно для продакшена, Enterprise да, но если у Вас St или Essentials, то это мертворожденный ребенок.

производительность при FT падает, при чем если по глубже покопаться, то найдете много статей по даже у самой vmware про это

ну и конечно не забываем про стоимость лицензии самой VM, вам придется покрывать оба гипервизора

При всем этом, я для себя решил проще реализовать отказоустойчивость на уровне приложения

ival

По HA могу поделиться знаниями, но нужны более конкретные вопросы)) FT повторюсь не стоит свеч.

Уваров А.С.

FT звучит красиво, но бесполезно. Сразу говорю, я когда-то тоже бредил этой идеей. Реальность же очень плачевна. Почему?
В свое время, пару лет назад, когда читал документацию, пришел к такому же выводу, но практического опыта не имел. Проанализировав все за и против выбрали в качестве платформы Hyper-V, реализовав на нем HA, большинство задач этот вариант покрывает.

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

ival

#5
11 января 2020, 00:04 Последнее редактирование: 11 января 2020, 00:18 от ival
В свое время, пару лет назад, когда читал документацию, пришел к такому же выводу, но практического опыта не имел. Проанализировав все за и против выбрали в качестве платформы Hyper-V, реализовав на нем HA, большинство задач этот вариант покрывает.

Как не парадоксально, но да, если позволяют лицензии. В случае отказа вместо перезапуска целой виртуалки со всеми службами просто отвалятся пользовательские сеансы, которые тут же смогут подключиться к другому узлу.
Если честно, то по управления сфера удобнее в качестве ha кластера, ведь консоль управления hyper-v ограниченна в функциях, чтобы дотянуть до функционала понадобиться sc vmm. Плюс у сферы все-таки есть адекватный саппорт. Ну и не знаю как 2019, а 2016 так и не научили пробрасывать внешние устройства в vm. Вообще при моих задачах не принципиально, но я делаю выбор в пользу VMware. Плюс у Dell и VMware есть прекрасное гиперконвергентное решение vxRail из коробки, которое элементарно масштабируется и в принципе оно вылизано. Чего нельзя сказать о MS. Ну это лирика, вообще надо работать с тем что есть)) хотя я все равно интересно зачем коллеге понадобился FT и почему нельзя обойтись обычным HA кластером.

Уваров А.С.

Лирика обычно заканчивается на уровне сметы. После чего все недостатки HV кажутся уже не столь существенными. Да и большинству заказчиков это не надо. Очень часто на переговорах, выслушав требования по доступности в 99,9%, начинаешь приводить примерные суммы, то сразу слышишь в ответ, что ладно, нам лишь бы виртуалка с одного сервера на другой в случае чего переехала.

А те, кому это действительно нужно, те могут позволить себе и VMWare, и SCVMM, и нормальную инфраструктуру под все это.

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

На следующий вопрос: "а что будете делать при аварии?", отвечали "да нам за два(три, четыре и т.д.) года это ваше HA ни разу не понадобилось, разве что пыль продуть, но это мы и ночью сделаем..."

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

STALKER_SLX

ограничение для Standard в 2 vCPU на VM просто не жизнепригодно для продакшена, Enterprise да...

руководство уже предоставило несколько максимальных лицензий - VMware vSphere 6 Enterprise Plus (CPUs) и VMware vSAN Standard (CPUs) - количество процессоров неограничено (см. картинку во вложении).

Теперь меня поставили перед фактом, что нужно настроить кластер именно на «Fault Tolerance»! Но у меня пока не хватает знаний для этого...

2. Кроме того, забыл упомянуть, что серверы находятся на физически разных площадках, но компания приобрела транспортную сетку (L2), то есть ВСЕ серверы компании по сути находятся в "локальной сети".

STALKER_SLX

производительность при FT падает, при чем если по глубже покопаться, то найдете много статей по даже у самой vmware про это
Если можно - напишите поподробнее об этом (и простыми словами, пожалуйста)

STALKER_SLX

Также после создания нового кластера и добавления в него обеих ESXi-серверов, столкнулся с ошибкой: "HA agent is unreachable".
То есть на одном из ESXi-хостов пишет что-то типа "HA agent master successfully running", а на втором - вместо slave successfully running, вываливается указанная ошибка.
Но при этом мной также был замечен следующий нюанс: если я перевожу ESXi-хост с работающим "HA agent master" в "maintenance mode", то второй ESXi-хост сразу запускает свой "HA agent" в  "master successfully running" и светиться от счастья!

После выведения из "maintenance mode" ситуация повторяется! То есть, если я вывожу из "maintenance mode" первым ESXi1, то его "HA agent" сразу становиться мастером и успешно запускается, а на ESXi2 - вылазит ошибка "HA agent is unreachable"
Если же первым вывожу из "maintenance mode" ESXi2, то его "HA agent" сразу становиться мастером и успешно запускается, а на ESXi1 - вылазит ошибка "HA agent is unreachable"

ival

1. Вы до конца так и не прочитали документацию по лицензированию и возможностям. Скрин который вы отправили означает лишь то, что хост esxi вы сможете запустить со на машине со скольки угодным количеством процессоров. Например на лицензии essentials в сервере максимум может быть 2 cpu. Ft в 6.7 по-моему поддерживает машину максимум с 8 vCPU, то есть если у вас в виртуалке будет 10 vCPU, то ft не заработает на этой машине.
2. Простыми словами, ft должен постоянно поддерживать вторую машину, на втором хосте в таком же состоянии как активная на первом, поэтому любая операция на активной сразу отправляется на вторую машину. То есть сфера делает checkpoint и отправляет дельту на вторую машину. FT на l2 может ещё медленне работать.
3. Я могу посмотреть логи, если вы их сделаете по рыбе https://kb.vmware.com/kb/653 и по рыбе https://kb.vmware.com/s/article/1011641
Но быстрее ответят из саппорта. И быстрый вопрос, перезаводить хосты пробовали в класстер? Ошибки при заводе есть?
4. Вы купили vSAN и vSphere? И продавец Вам не предложил vxrail вместо всего вашего набора сейчас?

ival

#11
12 января 2020, 23:09 Последнее редактирование: 12 января 2020, 23:19 от ival
Лирика обычно заканчивается на уровне сметы. После чего все недостатки HV кажутся уже не столь существенными. Да и большинству заказчиков это не надо. Очень часто на переговорах, выслушав требования по доступности в 99,9%, начинаешь приводить примерные суммы, то сразу слышишь в ответ, что ладно, нам лишь бы виртуалка с одного сервера на другой в случае чего переехала.

А те, кому это действительно нужно, те могут позволить себе и VMWare, и SCVMM, и нормальную инфраструктуру под все это.

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

На следующий вопрос: "а что будете делать при аварии?", отвечали "да нам за два(три, четыре и т.д.) года это ваше HA ни разу не понадобилось, разве что пыль продуть, но это мы и ночью сделаем..."

Причем были это не магазины с ларьками, а достаточно крупные производственные предприятия.
История из жизни. Кластер из двух хостов сферы. На хостах развёрнута АТС, но не обычная а UC на 600 абонентов, Avaya Aura. Drs разделил ресурсы по полам, т.е. оба хоста заняты примерно на 1/2. Остальные мощности просто простаивают. Esxi установлен на sd карты. На одном из хостов сдыхает sd карта с /boot. Хост живёт до первой перезагрузки, это не кретично, есть же второй хост, он примет машины. Плюс у Avaya есть HA на уровне приложения для части сервисов. Поэтому ремонт откладывается, со словами в течении недели как появится время. Проходит неделя и на втором хосте тоже вылетает sd. А вот это уже критично, например - сгорает трансформатор на здании и минут через 40 мои хосты выключаются и больше не загружаются. Поэтому в течении дня, по очереди переустановлены esxi на новые sd и перезаведены в кластер. Пользователи спокойно работают, ни кто не заметил проблемы, телефония и дополнительные сервисы работают в штатном. Вот плюс дополнительных простаивающих мощьностей. А знаете какой минус? С экономили и не закупили третий хост. Ни кто же не думал что сдешки сдохнут друг за другом. Не закупили дополнительные сдешки, чтобы собрать подобие raid1, хотя цена то копеешная даже в рамках вендорских сдешок. Мораль такова, что экономия на ИТ в наше время заканчивается плачевно для бизнеса. Не зря же придумали RPO и RTO. Они как раз и дают людям понять за чем им столько платить, 99,999 люди не особо могут представить, а вот когда им объясняешь про rpo и rto люди начинают понимать

Уваров А.С.

#12
12 января 2020, 23:25 Последнее редактирование: 12 января 2020, 23:28 от Уваров А.С.
Мораль такова, что экономия на ИТ в наше время заканчивается плачевно для бизнеса.
К сожалению, многие понимают это только после того, как набьют шишек.

Кстати, одни из заказчиков, разобравших по собственному почину HA, приехали как-то ко мне домой в три часа ночи. До этого еще два часа пробивали адрес по общим знакомым (телефон у меня ночью на беззвуке). Выяснилось, что была авария на линии электроснабжения, а батереи в ИБП не держали, их собирались менять, но через пару месяцев... В общем легла нода с критичным приложением, причем там тоже была ситуация "живет до очередной перезагрузки".

В итоге к утру мы все запустили, HA восстановили, даже новое железо под это дело прикупили.

STALKER_SLX

Забыл упомянуть ещё одну важную деталь - скорость сети между площадками была всего лишь 100 Мб/с (те, кто принимал такое решение явно не читали требований VMware к сети). После долгих мучений руководство таки приняло решение переместить один сервер (ноду) к другому, то есть они (сервера) сейчас воткнуты в один Гигабитный свич. После такого переезда указанная мной выше ошибка ИСЧЕЗЛА!

Но осталась еще одна - Proactive HA (см. скриншот), которая гласит: «No response because no Proactive HA provider is enabled on the cluster.»

Начал я изучать еще более внимательно официальную документацию от VMware и увидел вот тут:
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.avail.doc/GUID-57929CF0-DA9B-407A-BF2E-E7B72708D825.html

одну важную строчку: «Use a 10-Gbit logging network for FT and verify that the network is low latency. A dedicated FT network is highly recommended.»



В связи с чем у меня вопрос: 10 Гбит - это жёсткое требование для того, чтобы запустить Fault Tolerance или это следует воспринимать как рекомендацию?!

ival

о осталась еще одна - Proactive HA (см. скриншот), которая гласит: «No response because no Proactive HA provider is enabled on the cluster.»
Настройки DRS покажите. Proactive HA и DRS тесно связаны.

В связи с чем у меня вопрос: 10 Гбит - это жёсткое требование для того, чтобы запустить Fault Tolerance или это следует воспринимать как рекомендацию?!
Жесткое требование не 10gB а LOW LATENCY. Вы должны понимать что любое слово cluster HA очень требовательно к латентности сети. Я лично не тестировал сферу на задержках более 20 мс, но есть опыт тестирования кластера exchange на латентности более 80 мс и потерях в 20% узлы с ума сходить начинают. Я выше вам описал в общих чертах как работает FT, подумайте сколько по 100 мб будет передаваться дельта, там минимум 1 гБ нужно транспорта для адекватной работы



salex

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

Вверх