Виртуальные машины высокой доступности

Физический кластер делает ваше виртуальное оборудование высокодоступным, то есть сбои физического сервера не влияют на какую-либо конкретную виртуальную машину. Однако сама виртуальная машина все еще может выйти из строя (например, сбой ОС, кто-то отключил виртуальный сервер и т. Д.), Поэтому служба, работающая поверх виртуальной машины, может все же выйти из строя в какой-то момент (хотя это менее вероятно, чем было бы. быть для той же службы, работающей на отдельном физическом оборудовании). Чтобы снизить этот риск, вы создаете кластерную службу, чтобы она не пострадала даже в случае сбоя виртуального сервера. Конечно, вы могли бы достичь более или менее тех же результатов, если бы построили кластерную службу непосредственно на физических серверах.

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

Однако не забывайте принимать таблетки реальности по пути.

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

Этот второй момент очень важен; Я видел приложение «пять девяток», управляемое крупным системным интегратором, которое было отключено почти день из-за сложности технологии, используемой для обеспечения его высокой доступности. Для повседневной оперативной доступности технология пометила все, но когда что-то пошло не так с конфигурацией, люди из вышеупомянутой компании как следует застряли.

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

Я выйду из своей мыльницы ;-)

Требуется ли для этого создание виртуального отказоустойчивого кластера поверх физического или в этом нет необходимости?

Да.

Сначала вам нужно создать систему высокой доступности (для SQL, для ОС и т. Д.). Это означает, что у вас должно быть более одного физического или виртуального компьютера, и вы должны использовать программное обеспечение, способное поддерживать высокую доступность.

Как только это будет сделано, вы можете использовать систему виртуализации высокой доступности, которая «только» защитит вас от сбоев оборудования.

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

Я думаю, вы поняли суть представлений о снижении доступности. Функциональность Hyper-v и VMware HA не обеспечивает HA для гостей, а только HA службы виртуализации. В зависимости от требований доступности гостевых служб вам также потребуется высокая доступность на гостевом уровне (и в зависимости от задействованной технологии может означать кластеризацию). Вам необходимо оценить каждую услугу на предмет того, как обеспечить необходимое время безотказной работы. Например, SQL-сервер может использовать зеркальное отображение транзакций или кластеризацию серверов. Во многих случаях дополнительные накладные расходы и проблемы при кластеризации виртуальных сервисов перевешивают предоставляемые преимущества, и это может означать, что вместо этого услуга оказывается на выделенном оборудовании. (выбор на сервере sql на некоторое время). SQL-сервер обычно является потенциальным кандидатом на то, чтобы остаться физическим из-за возможности высокой загрузки сети, ввода-вывода, ЦП и памяти, а также потребности в избыточности.

Ответ в зависимости от обстоятельств.

Решения для кластеризации обычно не ограничиваются прикладным уровнем. Традиционно граф зависимости кластера будет включать такие вещи, как,

1. Проверка доступности сети / IP
2. Доступность хранилища / общего объема.

Выполнение некоторых из этих проверок внутри виртуальной машины ужасно сложно. Например, В кластерах Windows 2003 требуется диск кворума, на котором используется блокировка SCSI, чтобы гарантировать, что он является владельцем ресурсов. При сбоях он также отправляет «ядовитые пакеты» для получения этой блокировки. Все эти функции практически невозможно реализовать без RDM для LUN.

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

Так что в случае кластеров Microsoft Windows 2003 (и мне пришлось виртуализировать, я бы использовал ваш «дочерний» подход).

Идеальное место для стремления -

• VMware HA для обнаружения сбоев оборудования.
• мониторинг приложений vSphere

С последующим,

• VMware HA
• Приложение только монитор (без зависимости от оборудования)
• Убедитесь, что анти-сродство включено для парных виртуальных машин, чтобы DRS, HA никогда не перезагружали узлы на одних и тех же хостах!

в заключение

• Дочерняя кластеризация

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

Если вы хотите избежать КАЖДОГО SPOF, вам придется нелегко.

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

Однажды я посетил курс по NAS-системе, где нам сказали, что NASA идет этим путем - каждая деталь существует в трех разных вариантах. Только если хотя бы два из них имеют одинаковый результат, результат нормальный. Кроме того, все должно быть дублировано (в каждой из трех частей).

Конечно, перед полетом все трое должны показать одинаковый результат.