Если бы мне пришлось настроить физические серверы для запуска критически важного для бизнеса веб-сайта, я бы полностью обеспечил избыточность в этой среде. Я бы старался не допускать единой точки отказа и запускал как минимум два сервера каждой роли (два веб-сервера, два сервера баз данных и т. Д.). Даже если бы я решил добавить уровень виртуализации к этим серверам, я бы все равно стремился к избыточности (и в этом случае также обеспечил бы, например, распределение баз данных на разных хостах).
Однако я не уверен, применим ли такой образ мышления к предложениям облачных серверов, например, на основе openstack. Во-первых, я всегда мог запустить два веб-сервера и два сервера баз данных, но как узнать, что два моих сервера баз данных не работают на одних и тех же физических хостах? Во-вторых, я не понимаю, как с открытым стеком работают виртуальные машины. Привязана ли одна виртуальная машина к конкретному хосту или существует физический аппаратный пул, в который виртуальные машины перемещаются?
Должен ли я рассматривать облачные серверы с открытым стеком как еще один вариант VPS / VM? Должен ли я планировать облачные серверы с открытым стеком так же, как я планирую с физическими или старыми виртуальными серверами
Если вам нужна избыточность, вам все равно нужно ее спланировать. Облачные провайдеры (независимо от платформы) по-прежнему имеют перебои в работе как на уровне хоста, так и на уровне центра обработки данных.
Обычно существует пул хостов, и вы не можете сказать, какая виртуальная машина куда идет. Если хост умирает, у вас небольшой сбой, пока виртуальная машина перемещается и перезагружается. Многие провайдеры позволяют вам устанавливать правила анти-сродства на ваших машинах, чтобы гарантировать, что вы не разместите все свои веб-серверы на одном хосте. Более крупные позволяют размещать их в разных географических регионах, чтобы они продолжали работать даже в случае сбоя на уровне центра обработки данных.
Openstack упрощает им перемещение виртуальных машин между хостами, поэтому отказ хоста обычно приводит к меньшему времени простоя, но не устраняет сбои. Если вам нужна высокая доступность, вам все равно нужно это спланировать.