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

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

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

Не забудьте взять таблетку реальности по пути.

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

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

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

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

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

Это да.

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

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

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

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

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

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

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

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

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