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

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

Мне нужно реализовать для ассоциации три виртуальные машины для управления доменом и два других ПО, которые будут использовать базы данных. Конечно, у них нет большого бюджета, но я пытаюсь с их бюджетом реализовать что-то стабильное и доступное в случае сбоя оборудования.

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

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

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

Надеюсь, этот случай кого-то заинтересует, спасибо!

решение1

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

Приложение, которое существует только как одна виртуальная машина, не будет функционировать, если вычислительный узел выйдет из строя. Рассмотрите несколько вариантов:

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

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

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

  • 3 физических хоста — это, как правило, минимальный размер кластера. Два могут быть возможны, но это затрудняет кворум.
  • Хранилище без общего доступа — более простое хранилище, поскольку каждый хост может использовать локальное хранилище. Тогда HA находится в балансировщике нагрузки или репликации базы данных. Или, возможно, с живой миграцией виртуальной машины без общего доступа.
  • Один традиционный выделенный массив хранения — это относительно простой способ предоставления общего хранилища. Их избыточность внутренняя, два контроллера и несколько дисков. Репликация на другой массив возможна, но вы хотели снизить расходы.
  • Hyper-Converged, объединяющий локальное хранилище на многих узлах для создания пула хранения, не масштабируется хорошо до небольшой среды из 2 узлов. Однако это хорошо, когда у вас есть избыточное хранилище на многих вычислительных узлах.

Связанный контент