Назад | Перейти на главную страницу

Отказоустойчивость государственной службы в кластере

Я начинаю с кластеризации физических серверов и планирую установку гиперконвергентной oVirt с тремя узлами.

В настоящее время я развертываю все свои приложения и сайты на VPS и облачных экземплярах, предоставляемых API. У меня есть некоторый опыт работы с HA, но для каждого проекта в конечном итоге существует единственный балансировщик нагрузки или веб-сервер, на который указывается доменное имя.

Я понимаю, что кластер oVirt настроен так, что каждый узел доступен по полному доменному имени, будь то через VPN или общедоступные имена.

Но как мне запустить несколько публичных виртуальных хостов из кластера, когда любую виртуальную машину можно переместить практически на любой хост? Должен ли я указывать все IP-адреса хоста как отдельные записи DNS A и полагаться на аварийное переключение браузера? Кажется странным. Или мне следует расширить весь кластер с помощью отдельного брандмауэра / маршрутизатора, который действует как точка входа для всех TLD? И снова это становится единственной точкой отказа и дополнительным ящиком для колорита. Или может быть обязательно скрипт обновления зоны?

Возможно, я упускаю что-то совершенно очевидное; все советы очень ценятся. Спасибо!

oVirt виртуализирует оборудование, предоставляя экземпляры виртуальных машин. Эти виртуальные машины можно загрузить на другом физическом хосте.

Логические виртуальные сети обычно отличаются от физической сети. И ВМ web3 сохраняет свой IP-адрес при переносе с ovirt1 к ovirt2. Эти физические узлы не доступны для конечных пользователей.

Однако виртуальные машины oVirt далеко не полностью учитывают высокую доступность.

Каково ваше целевое время восстановления? Если часы - успеете заняться серьезным ремонтом. Меньше становится все сложнее и дороже.

Рассмотрите дизайн приложения. Как поступают входящие запросы и в какой экземпляр? Можно ли сбалансировать нагрузку на несколько экземпляров? Требуется ли высокая доступность для самого балансировщика нагрузки? Есть ли в его базе данных решение для репликации?

Помните, что кластеры сложно сделать быстро и безопасно. Критерии перезапуска виртуальной машины oVirt HA нетривиальны. Аварийное восстановление всегда необходимо учитывать, в том числе для сценария (надеюсь, маловероятного), когда мозг разделяет кластер и ваши данные повреждены. Когда приложению не требуется, чтобы одна виртуальная машина оставалась доступной, высокая доступность виртуальной машины становится менее важной.

Говоря о аварийном восстановлении, подумайте, входят ли в область действия несколько сайтов. Что характерно для кластеров, oVirt имеет несколько шаблонов DR. Растяните активный / активный и разделите кластер активный / пассивный. Проектные решения здесь влияют на проблемные области и время восстановления. Например, пассивная установка может быть почти полностью изолирована с точки зрения хранилища и сети уровня 2. Отлично, проблемы на основном сайте сложно распространить туда. Представьте себе регион в общедоступном облаке. Но переключение - это ручной процесс, который может включать обновления DNS.