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