Ограничения при управлении хостами ESX из SCVMM

Microsoft позиционирует System Center Virtual Machine Manager 2008 R2 как продукт для централизованного управления инфраструктурой виртуальных машин. Одной из особенностей SCVMM 2008 R2 является возможность работы с хостами VMware ESX. Однако, существует ряд ограничений, о которых должны знать администраторы перед тем, как решиться на подобную интеграцию.

1) Для управления хостами ESX/ESXi вам потребуется VMware vCenter. SCVMM не управляет хостами напрямую, а использует для этого функционал, схожий с тем, который vCenter предоставляет через Web Access.

2) SCVMM поддерживает ESX 3.0/ESXi 3.5 и выше, в том числе ESX/ESXi 4.0 U1, однако все новые функции vSphere - Fault Tolerance, Host Profiles, VMDirect Path, Distributed Switches, Thin Disks, vShield Zones не поддерживаются.

3) Через консоль SCVMM вы не можете создавать и настраивать Resource Pools и кластеры VMware HA и DRS, создавать и настраивать сетевые подключения для Service Console и VMKernel, изменять настройки DPM, настраивать iSCSI, Fibre Channel или NFS, добавлять, расширять и просматривать хранилища.

4) Перед использованием шаблонов машин VMware, вам потребуется импортировать их в библиотеку SCVMM. Customization Specification не поддерживается. Аналогично, для подключения ISO образов требуется также перенести их в библиотеку.

5) При создании новой виртуальной машины из SCVMM, она автоматически создается с Virtual Machine version 7; вы не можете указать/изменить тип сетевой карты и SCSI контроллера. Кроме того, требуется принудительно поменять тип подключения диска с IDE на SCSI, даже если вы используете ESX 4.0.

6) SCVMM имеет собственный журнал событий/операций, с помощью SCVMM вы не можете просматривать Alerts от ESX/vCenter и настраивать задания по расписанию.

7) При переводе хоста ESX в Maintenance Mode с помощью vCenter, в консоли SCVMM информация о состоянии хоста не изменится, однако, ни запустить, ни изменить свойства виртуальных машин вы не сможете.

8) Встроенный Physical Server Convert не позволяет делать P2V миграцию на узлы ESX.

9) Многие функции по управлению VI/vSphere реализуются через плагины к VIC/vSphere Client, поэтому консоль SCVMM их не поддерживает.

Из всего вышеперечисленного складывается ощущение, что SCVMM крайне ограниченно подходит для управления инфраструктурой VMware. С другой стороны, он может пригодиться в случаях, когда вы планируете перевод вашей виртуальной инфраструктуры с одной платформы на другую, например, чтобы иметь возможность мигрировать машины с VMware Infrastructure на Hyper-V, либо, наоборот, чтобы ваши администраторы, привыкшие к SCVMM, могли более плавно адаптироваться к vSphere.

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть II)

Сегодня продолжим наши эксперименты с Hyper-V из командной строки. В предыдущей части я рассказал о настройках на узле Hyper-V. На очереди самое интересное - создание кластера.


Настройка кластера
Для создания кластера введите:
cluster /cluster:<ИМЯ_КЛАСТЕРА> /create /node:<ИМЯ_УЗЛА> /ipaddress:<АДРЕС_КЛАСТЕРА>
, где <ИМЯ_КЛАСТЕРА> - имя, по которому можно будет обращаться к кластеру;
<ИМЯ_УЗЛА> - имя узла, входящего в кластер
<АДРЕС_КЛАСТЕРА> - IP адрес и маска подсети для кластера в полном или сокращенном формате (например 192.168.10.13/24 или 192.168.10.13/255.255.255.0)

Теперь можно полюбоваться на кластер, набрав:
cluster /list

и посмотреть список доступных ресурсов:
cluster res

Как видите в списке отсутствуют дисковые ресурсы, поэтому придется добавлять их вручную. При создании кластера Windows Server 2008 настраивает две группы для размещения ресурсов: Cluster Group и Available Storage. Увидеть доступные группы можно с помощью команды:
cluster group

По-умолчанию, все дисковые ресурсы размещаются в группе Available Storage. Исключение составляет только диск, предназначенный для кворума - он будет помещен в группу Cluster Group. Создадим новый дисковый ресурс:
cluster res "<ИМЯ_РЕСУРСА>" /create /group:"Cluster Group" /type:"Physical Disk"
, где <ИМЯ_РЕСУРСА> - произвольное имя

После создания дискового ресурса требуется сопоставить его с физическим диском. В Windows Server 2003 у ресурса physical disk был параметр Drive, соответствующей букве физического диска. В Windows Server 2008 синтаксис команды изменился, и теперь вместо Drive используется параметр DiskSignature. Для определения DiskSignature нам потребуется воспользоваться Diskpart.

После запуска Diskpart выберите нужный диск и выполните:
detail disk

В свойствах найдете нужный параметр Disk ID, представляющее собой шестнадцатиразрядное число. Для дальнейшего использования требуется перевести
это число в десятичный формат и затем выполнить команду, подставив в качестве значения параметра DiskSignature:
cluster res "<ИМЯ_РЕСУРСА>" /priv DiskSignature=<ID_ДИСКА>

Кстати о конвертировании - в Powershell есть встроенный преобразователь типов:
[Convert]::ToInt32("<16-РАЗРЯДНОЕ_ЧИСЛО>", 16)

Теперь переведем ресурс в активное состояние.
cluster res "<ИМЯ_РЕСУРСА>" /on

Проделаем аналогичные операции для второго диска:

Теперь требуется указать кластеру, где размещать кворум (в качестве примера, кластер будет работать в режиме Node and Disk Majority):
cluster /quorum:"<ИМЯ_РЕСУРСА>"

Настройка Cluster Shared Volume
Как и в случае с работой из GUI, перед преобразованием диска в CSV, вам потребуется включить поддержку CSV на кластере:
cluster /prop EnableSharedVolumes=1

Запустите Powershell. Добавьте модуль для поддержки работы с кластером:
Import-Module FailoverClusters

Добавление CSV выполняется командой:
Add-ClusterSharedVolume "<ИМЯ_РЕСУРСА>"

Добавление второго узла в кластер
Остались последние штрихи - добавить еще один узел в кластер Hyper-V. Все настройки на втором узле - конфигурация IP, ввод в домен, iSCSI Initiator выполняются аналогичным образом, поэтому я не буду заострять на них внимание.

Когда второй узел будет готов, добавьте его в кластер командой:

На этом настройка кластера завершена. Вам осталось развернуть или скопировать виртуальные машины и запустить их.

За бортом осталось описание создание/добавление виртуальных машин в кластер и работа с ними из командной строки. Не исключено, что этому я посвящу отдельную статью.

Материалы
При подготовке статьи использовались следующие материалы:

1. Q. How can I change a Windows Server 2008 cluster quorum from the command line?

Настройка Hyper-V Server R2 Failover Cluster из командной строки (Часть I)

Готовясь к сертификации по Windows Server 2008, я решил более обстоятельно поработать с SCVMM 2008 R2 и Hyper-V R2. Среди прочих задач захотелось поднять двухузловой отказоустойчивый кластер. Вот только его настройка из оболочки sconfig и оснасток MMC показалась мне довольно тривиальной, поэтому решил выполнить аналогичные операции, используя только лишь командную строку.

Схему организации кластера выбрал самую простую:

Один контроллер домена (W2K8-DCS01), один сервер, выполняющий роль iSCSI Target (W2K8-STR01), два узла Hyper-V Server R2 (W2K8-HYP01 и W2K8-HYP02) с двумя сетевыми адаптерами: один - для доступа к узлам, работы с виртуальными машинами, а также подключения к iSCSI Target'ам, второй - для передачи heartbeat. Кворум предполагается размещать на одном LUN'е (Quorum), презентованном по iSCSI, раздел для хранения виртуальных машин - на втором (Storage).


Первоначальная настройка
Перед тем, как начать собирать кластер, потребуется выполнить настройку сети на сервере Hyper-V.

Закрываем неприглядное окно sconfig'а, на передний план выходит cmd.

Сначала включим несколько дополнительных компонентов (службы кластера, PowerShell и Framework для него):
dism /online /enable-feature /featurename:FailoverCluster-Core
dism /online /enable-feature /featurename:NetFx2-ServerCore
dism /online /enable-feature /featurename:MicrosoftWindowsPowerShell

Они понадобятся нам на более поздних этапах настройки.

Кстати, получить список доступных (активных/неактивных) компонентов можно с помощью команды:
dism /online /get-features

С помощью netsh настроим сетевые подключения. Сначала узнаем имена, которые система назначила сетевым адаптерам:
netsh interface show interface

В моем случае адаптер "Local Area Network" подключен к общей сети, адаптер "Local Area Network 3" к частной (heartbeat). Исходя из первоначального плана, назначаем адреса, маски, DNS, Default Gateway:
netsh interface ipv4 set address "Local Area Connection" static 192.168.10.11 255.255.255.0 192.168.10.254
netsh interface ipv4 set dnsserver "Local Area Connection" static 192.168.10.1 primary
netsh interface ipv4 set address "Local Area Connection 3" static 10.0.0.1 255.255.255.252

Без RDP может быть скучно, поэтому включим и его:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /AR 0

И разрешим подсоединятся старым RDP клиентам:
Cscript.exe "C:\Windows\System32\Scregedit.wsf" /CS 0

Хотя, мне больше нравится удаленно управлять сервером с помощью WinRM.

Перед присоединением сервера к домену, изменим его имя на что-то более благозвучное:
netdom renamecomputer %computername% /newname <НОВОЕ_ИМЯ_СЕРВЕРА>

Перезагрузим сервер:
shutdown -r -t 00

Добавим сервер в домен:
netdom join %computername% /domain:<ИМЯ_ДОМЕНА> /userd:<УЧЕТНАЯ_ЗАПИСЬ> /passwordd:<ПАРОЛЬ>

и снова перезагрузим сервер.

Подключение дисков
Перед созданием кластера нам понадобится настроить iSCSI Initiator чтобы получить доступ к презентованным дискам. Сделать это можно в несколько щелчков мыши, запустив графическую настройку iscsicpl.exe.

Однако, мы не ищем легких путей, поэтому будем настраивать все из командной строки. :)

По-умолчанию служба iSCSI Initiator выключена, поэтому для начала запустим ее:
net start msiscsi

А чтобы не повторять эту операцию каждый раз при загрузке сервера вручную настроим ее на автоматический старт:
sc config msiscsi start= auto

На очереди сама консольная утилита - iscsicli. С ее помощью и настроим iSCSI Initiator на узле. Подключимся к iSCSI Target серверу:
iscsicli qaddtargetportal <ИМЯ_СЕРВЕРА>
, где <ИМЯ_СЕРВЕРА> - имя или IP адрес iSCSI хранилища.

Посмотрим на список доступных целей:
iscsicli listtargets

Подключимся к обоим целям:
iscsicli qlogintarget <IQN>
, где <IQN> - IQN целей, к которым требуется подключиться

а также сделаем так, чтобы они автоматически подключались после перезагрузки сервера:
iscsicli persistentlogintarget <IQN> t * * * * * * * * * * * * * * * 0

Разбиение дисков
Теперь потребуется создать отформатировать разделы на подключенных дисках. Сделать это можно с помощью консольной утилиты Diskpart.

Запустим Diskpart и посмотрим на подключенные диски:
list disk

Выберем первый диск, создадим и отформатируем на нем раздел под кворум:
select disk 1
create partition primary
format fs=ntfs label="Quorum" quick

аналогичные операции выполним для второго диска под хранилище виртуальных машин:
select disk 2
create partition primary
format fs=ntfs label="Storage" quick

Заключение
На этом первая часть завершена. В следующий раз я опишу процесс настройки самого кластера и подключения второго узла. До встречи!

Материалы
При подготовке статьи использовались следующие материалы:

1. Сделай сам: стенд с решениями для виртуализации — настройка узлов кластера для использования общего хранилища

Домашний сервер All-In-1 в качестве тестового полигона

Сегодняшнее повествование будет несколько отличаться от привычных вам статей на VM Press. Не будет в нем примеров настройки или описания какой-либо технологии или продукта. Вместо этого я расскажу о своем домашнем виртуальном сервере.


Помню, как год назад был рад, когда, наконец, задушил свою жабу и собрал отдельный тестовый полигон. Потому как бы не был хорош мой настольный компьютер с VMware Workstation 6.5, но душа желала чего-то большого и производительного. Этим чем-то стал самосборный сервер:

• четырехъядерный процессор Intel Core 2 Quad Q6600;
• мат.плата Asus P5BV-E (с двумя гигабитными сетевыми адаптерами Broadcom BCM 5721 и интегрированным SATA контроллером ICH7R);
• память 8 Gb DDR-II 800Mhz;
• дискретный 8-канальный SATA/SAS Raid-контроллер Intel SRCSASRB с 256Mb кэш памяти;
• три жестких диска SATA - WD 1001FALS 7200RPM 32Mb.

Все это было собрано в хорошем корпусе с качественным БП, довольно тихим куллером и вентиляторами.

Неплохая, как мне тогда показалась конфигурация, ибо раскошеливаться на S771 процессор/FBDIMM память/и соответствующую мат.плату было выше моих финансовых возможностей, радовала меня первые полгода. :)

На сервер был поставлен ESXi 3.5 U3. Подбирались комплектующие как раз исходя из требований совместимости (спасибо Tim'у Jacobs'у за его статью). Другие решения виртуализации я также рассматривал (VMware Server 2.0, Windows Server 2008 + Hyper-V/Hyper-V Server R1, Citrix Xen Server 5.0), но все они по тем или иным причинам не подошли. Решающими для меня стала поддержка Memory Overcommit и наиболее удобная, на мой взгляд, работа с шаблонами виртуальных машин через vCenter. На ESXi были подняты две служебные машины - Windows Server 2003 в качестве контроллера домена и сервера VMware vCenter 2.5 U3 и Windows Server 2008 - файловый сервер.

Сами виртуальные машины (служебные, а потом и тестовые) ютились на одном единственном 640Гб жестком диске. Три терабайтных жестких диска были объединены в массив RAID 5 силами Intel SRCSASRB, затем разбиты на два LUN'а по терабайту (условно для software и media) и проброшены внутрь ВМ при помощи RDM. Не то, чтобы я не доверял файловой системе VMFS, но при возникновении какой-либо внештатной ситуации мне хотелось быстро и просто получить доступ к моим данным. Да, и я очень удивился скорости записи контроллера на диски в режиме Write Through (~14 Mb/sec), так, что пару раз хотел заехать молотком по несчастной железке, благо, режим Write Back, оказалось, можно включить без батарейки (которая позже все же была куплена, во избежание). И еще эта диагностика контроллером всех дисков в случае простоя, которая вымораживала меня на протяжении двух недель, пока не удосужился прочитать инструкцию и отключить.

Кроме того, на виртуальном сервере был настроен NFS и для ESXi расшарена папка с ISO образами для подключения через консоль Infrastructure Client.

При такой организации, служебные виртуальные машины и сам ESXi отъедали 1.5-2Гб от оперативной памяти и совсем немного мегагерц от процессора, оставляя для экспериментов достаточные вычислительные ресурсы. Однако, как я уже сказал, доволен я был этим сервером полгода.

Во-первых, о том, чтобы обстоятельно протестировать другие гипервизоры (Hyper-V, Xen Server) пришлось забыть. Кхм, скажем так - даже кратковременное отсутствие виртуальной машины, на которой хранился весь мой софт, музыка, фильмы, делало меня очень грустным.

Во-вторых, примерно в это же время я начал задумываться о том, что с Windows Server 2003 в тестовой среде пора закругляться, и пора начинать плотнее общаться с 2008 сервером. И если Windows Server 2003 места на диске много не занимала и памяти виртуальным машинам можно было поменьше отводить, то с 2008 все было намного печальнее.

В-третьих, возник вопрос об удаленном доступе к серверу и виртуальным машинам. Долгое время я ограничивался простой публикацией RDP на одной из виртуальных машин с установленной консолью Infrastructure Client. Надо сказать, что работать так с виртуальными машинами - удовольствие сомнительное, консоль ощутимо притормаживала, что при открытии в RDP сессии, что при более изощренном доступе через TS Remote Apps, что при TS Gateway. Чуть позже начал использовать возможность подключения к виртуальной машине по протоколу VNC - даже внутри RDP сессии управление стало намного приятнее. Один недостаток - приходилось вручную править .vmx файл настроек и запоминать порты для подключения.

И все это происходило на фоне моей постоянной и неуемной страсти к покупке новых железок. Я всерьез начал прикидывать во что мне обойдется апгрейд на платформу Intel S1366 с Xeon E5520 и 16 Гб памяти. Останавливало меня от этого шага только отсутствие вменяемых корпусов, в которых бы разместилась полноразмерная серверная E-ATX плата. Короче, голос разума победил.

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

Поэтому в ожидании подарков от Деда Мороза решил обновиться до ESXi 4.0. 640 Гб диск был заменен на 1 Тб, а сам ESXi был установлен на flash накопитель (что чертовски удобно). Все виртуальные машины переставлены заново.

Из-за требований vCenter 4.0 не может быть установлен на контроллере домена. Поэтому пришлось установить его на Windows 2008 Server R2. И вот тут возникла одна неприятная особенность - при установке драйвера для виртуальной видеокарты из комплекта VMware Tools машина начинала периодически зависать. Поиск в Google быстро решил проблему.

А через несколько дней стал доступен Update 1, который позволил нормально создавать машины Windows Server 2008 R2 и Windows 7 из шаблона и подготавливать их с помощью Customization Specification. Надо ли говорить, что благодаря поддержке Thin Provisioning из GUI я смог легко уменьшить место занимаемое виртуальными машинами, не мучаясь теперь с командной строкой и ssh. Стоит отметить и негативную сторону данного события - я начал забывать параметры команды vmkfstools. :)

Что касается рациональности потраченных средств - я знаю, что можно было собрать сервер подешевле и с raid контроллером явно вышел перебор; с другой стороны, наверное, я достиг того возраста, когда меня интересуют такие вот игрушки.

На этой позитивной ноте я заканчиваю свой рассказ. Надеюсь, что он был не слишком утомителен.