Варианты резервирования VMware Virtual Center/vCenter

Введение

VMware Virtual Center (теперь он называется vCenter) — важная часть пакета виртуальной инфраструктуры VMware. Если вы используете VMware Virtual Infrastructure Suite, вполне вероятно, что вы используете Virtual Center/vCenter для ВСЕГО, что связано с управлением вашей виртуальной инфраструктурой. У многих из нас есть Virtual Center, SQL Server и сервер лицензий VMware, работающие на одном сервере. Мы используем VC для администрирования наших гостевых виртуальных машин, проверки производительности, настройки высокой доступности, балансировки нагрузки и многого другого. Но что, если виртуальный центр выйдет из строя? Что произойдет с вашей виртуальной инфраструктурой и всеми важными гостевыми виртуальными машинами? Давайте выясним, что произойдет, а затем, что вы можете сделать, чтобы обеспечить максимальную доступность VC.

Что произойдет, если виртуальный центр выйдет из строя?

Если вы спросите VMware (особенно торгового представителя), что произойдет, если Virtual Center выйдет из строя, вы получите короткий ответ: «Ничего». Технически это правда, и это ответ, который надеется услышать большинство администраторов. Тем не менее, это гораздо больше, чем это, как вы можете себе представить. Я имею в виду, вы используете VC для всего, что связано с администрированием VI, верно? Что ж, если его больше нет, вы, конечно, не можете делать «вещи», которые делали раньше. Итак, на самом деле «что-то» происходит, когда VC падает.

Помимо невозможности выполнять все ваши обычные задачи VC, когда VC не работает, большинство администраторов VMware обеспокоены тем, будут ли их кластеры высокой доступности и балансировки нагрузки (с использованием VMHA и DRS) функционировать, если VC выйдет из строя. Я могу сказать вам, что VMHA, и DRS продолжат функционировать, если VC выйдет из строя.

При использовании VMHA агент размещается на каждом из хостов ESX, входящих в состав кластера. Это делается для того, чтобы каждый хост в кластере мог взаимодействовать с другими хостами, чтобы поддерживать информацию о состоянии и знать, когда один из хостов в кластере ESX выходит из строя. Если сервер VC выйдет из строя, система высокой доступности будет продолжать работать в обычном режиме. Единственное предостережение заключается в том, что информация о доступности ресурсов, используемая для определения хоста ESX для запуска гостевых ВМ в случае сбоя хоста ESX, будет основываться на информации, доступной до сбоя VC.

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

Таким образом, Virtual Center не является единственной точкой отказа для расширенных функций виртуальной инфраструктуры VMware.

Предполагая, что ваш сервер лицензий установлен на том же хосте, что и сервер Virtual Center, и этот хост не работает, вы не можете выдавать новые лицензии для новых хостов или новых функций. Однако все лицензированные функции Virtual Center продолжают работать, включая расширенные функции, такие как VMotion и DRS. Все лицензионные функции ESX Server будут работать в течение 14 дней (даже при перезагрузке). По истечении льготного периода некоторые функции сервера ESX, такие как включение хоста ESX, больше не работают.

Но самое главное, что даже без сервера лицензий и Виртуального центра все хосты и гости ESX продолжают функционировать в течение 14 дней.

Какие есть варианты резервирования VMware Virtual Center?

Допустим, вы беспокоитесь о том, что произойдет, если ваш сервер Virtual Center выйдет из строя. Какие у вас есть варианты повысить его надежность и, возможно, предложить какую-то избыточность/отказоустойчивость?

1. Установите второй сервер Virtual Center и используйте его в качестве «горячего резерва».

Самое главное, вы не можете запускать ДВА сервера Virtual Center одновременно, используя одну и ту же серверную базу данных SQL или Oracle. Virtual Center не поддерживает кластер (по крайней мере, в версии 3.5, но, по слухам, он будет доступен в следующем выпуске).

Что я предлагаю здесь, так это:

• Обеспечьте доступность своих данных SQL или Oracle, либо скопировав/реплицировав их на другой сервер базы данных, используя кластеризацию, либо просто разместив базу данных на другом сервере, отличном от сервера VC (сервер, который не вышел из строя).
• Установите второй сервер Virtual Center на другом хосте (возможно, даже на виртуальной машине), создав новый системный DSN и указав его на существующую базу данных.
• Выключите второй сервер Virtual Center.
• Если первичный сервер выходит из строя, вы можете включить вторичный сервер VC.

Другим вариантом этого может быть просто преобразование P2V основного VC-сервера, а затем выключение этого клонированного VC-сервера. В случае сбоя основного физического сервера VC вы можете включить его клонированную и виртуализированную версию.

2. Запустите Virtual Center внутри гостевой виртуальной машины и поместите виртуальную машину в кластер VMHA.

Предполагая, что у вас уже есть как минимум 2 хоста ESX, работающих в кластере VMHA, почему бы просто не запустить Virtual Center в кластере как виртуальную машину. Вы должны установить SQL и сервер лицензий локально в Virtual Center VC. Если хост ESX, на котором работала виртуальная машина VC, выйдет из строя, VMHA включит виртуальную машину VC на другом хосте ESX, и VC продолжит работу.

На мой взгляд, это гораздо лучший вариант, чем вариант 1, потому что вам не нужно иметь два хоста (и один из них выключен), а также вам не нужно беспокоиться о копировании/реплицировании ваших данных VC. Если вы уже используете VMHA для своих критически важных производственных машин, запустить в нем Virtual Center не составит труда.

3. NeverFail для виртуального центра

Если вы ищете действительно высокодоступный вариант для Virtual Center, единственным вариантом, предназначенным для этой задачи, является NeverFail для VMware Virtual Center. С помощью этого стороннего продукта ваше программное обеспечение Virtual Center, база данных SQL на сервере VC и сервер лицензий будут реплицированы на другой сервер. Если ваш основной сервер VC выйдет из строя, NeverFail для VirtualCenter немедленно переведет резервный сервер в оперативный режим. Помимо автоматического аварийного переключения, NeverFail для VC обеспечивает автоматическое восстановление после отказа.

Какова моя рекомендация?

Хотя нет единого ответа, который бы соответствовал потребностям каждой компании, моя рекомендация для тех, кто хочет обеспечить более высокую доступность своего сервера Virtual Center, я бы сначала рекомендовал вариант № 2, описанный выше. Сделав VC гостевой виртуальной машиной, она будет автоматически перезапущена в случае сбоя хоста ESX, на котором она работает. Для очень высокой доступности VC я рекомендую вариант № 3 — NeverFail для VMware. Однако теперь, когда вы знаете, что HA, DRS и лицензированный сервер продолжают функционировать при выходе из строя VC, никакие критически важные части VMware не перестают функционировать при выходе из строя VC, возможно, вариант № 4 является излишним.