Я пытаюсь понять, как различные поставщики виртуализации (в частности, Amazon EC2, но также VMware и Xen) позволяют поставщикам программного обеспечения предоставлять реальное решение высокой доступности в среде, где виртуализированы серверы.
В частности, если я запускаю какое-либо приложение высокой доступности (обмен, базы данных и т. Д.), Мне нужно убедиться, что мои избыточные виртуальные «серверы» не расположены на одном физическом сервере.
Используя собственные решения виртуализации (VMware, Xen и т. Д.), Я могу подготовить соответствующие ресурсы, а также проверить виртуальное -> физическое расположение. Однако я мог случайно «перенести» на то же физическое оборудование.
С EC2 у меня даже нет возможности во время подготовки выбирать разные физические серверы. Поскольку их кластерные вычислительные инстансы представляют собой 1 виртуальный сервер на физический сервер, это, кажется, единственный способ гарантировать, что у меня нет ложного ощущения избыточности.
Любые идеи или мысли были бы полезны. Что делают другие с этой проблемой? Если бы поставщики предоставили API, в котором я мог бы получить что-то столь же простое, как уникальный физический идентификатор системы, я бы, по крайней мере, знал, возникнет ли у меня проблема.
-Тим
Я могу говорить только с VMWare. Если вы используете DRS, вы можете создавать правила, которые будут либо размещать машины в одном физическом ящике, либо хранить их в отдельных физических ящиках. Даже если вы случайно переместитесь в ящик с другой машиной, он сразу же отключится.
Если вы используете управляемое размещенное решение, вам просто нужно узнать, о чем говорится в вашем контракте. В этой ситуации вы не управляете машинами, вы покупаете услугу. Узнайте, что вы покупаете. Если в пакете, который вы покупаете, указано, что нет единой точки отказа, тогда все, что вы можете сделать, это предположить, что они держат ваши виртуальные машины на другом оборудовании. Если они этого не сделают, и он потерпит неудачу, надеюсь, в вашем контракте сказано, что вы получите немного денег обратно, бесплатный месяц или что-то в этом роде.
Если вы не можете управлять системами, зачем им предоставлять вам доступ, чтобы узнать, на какой физической машине находятся ваши виртуальные машины? Вы ничего не можете с этим поделать. И даже если бы вы могли убедиться, что они не находятся на одном физическом хосте, как вы, например, определите, что в SAN есть двойные структуры?
В случае хостингового решения от надежного поставщика просто обратите внимание на то, что вы купили.
редактировать - Из EC2 страница: если вы покупаете машины в одном регионе, вы получаете 99,95% времени безотказной работы. Вы можете покупать машины в разных зонах доступности, чтобы повысить надежность.
Довольно часто они работают на общем устройстве хранения (SAN или аналогичном), и все физические хосты подключаются к нему. Таким образом, два сервера, на которых может работать виртуальная машина, имеют подключения к общему хранилищу с использованием кластерной файловой системы. Когда один из серверов выходит из строя, другому приказывают начать работу - и он забирает файлы из хранилища, чтобы не было прерывания.
Трудно перенести данные для гостя 30 ГБ с одного сервера на другой, если один из серверов вышел из строя.
Само общее хранилище часто настраивается таким образом, чтобы его полностью дублировать, диски RAID и резервные переключатели Fibre Channel / iScsi.