Среди нововведений в Windows Server 8 – и новая версия гипервизора, Hyper-V 3.0, снабженная новыми возможностями. Виртуальные машины в Hyper-V 3.0 будут поддерживать больше 16 виртуальных процессоров, и бОльший объем оперативной памяти.

Судя по информации о возможностях новой версии-конкурента VMware vSphere 5, максимальное количество поддерживаемых виртуальных процессоров вряд ли будет меньше 32.

Также появилась интересная возможность Hyper-V Replica – возможность онлайновой репликации работающей виртуальной машины по сети на другой сервер, даже расположенный в удаленной локации. Все, что для этого требуется – сетевое соединение.

На скриншотах видеодемонстрации видно, что для создания реплики достаточно указать удаленный Hyper-V-сервер, на который будет производиться репликация, и выбрать тип аутентификации – как Windows Integrated, так и по сертификатам (что, возможно, позволит реплицировать виртуальные машины на хост, находящийся в совершенно отдельном лесу Active Directory, без доверенных отношений). Передаваемые по сети данные могут сжиматься. Также, можно выбрать, какие конкретно виртуальные диски нужно реплицировать.

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

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

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

Возможнось Hyper-V Replica не зависит от используемого железа, систем хранения и сетевых подключений, и является чисто программной. Вероятно, Hyper-V Replica схожа с технологией репликации, реализованной программными решениями DoubleTake, рассказ о которых еще предстоит в нашем блоге.

Полностью видео о Windows Server 8 и Hyper-V Replica можно посмотреть здесь, примерно на 37й минуте.

Итак, что же появляется нового в новой версии VMware vSphere 5?

• Основой и платной, и бесплатной версии продукта теперь является один гипервизор – ESXi. VMware делает упор на его небольшой размер и производительность.
• vSphere Auto Deploy – новая модель распространения гипервизоров на железо, и установки патчей. Распространение работает с использованием PXE-Boot, загрузки специально подготовленного образа и файлов ответов с профилем хоста на сервер, и автоматического подключения его к vCenter. Таким образом, можно быстро, по сети, установить группу хостов виртуализации.
• Новая версия виртуальной машины – Virtual Machine version 8, включающая в себя новое виртуальное оборудование – поддержку 3D графики, например для Aero (правда, без использования аппаратного ускорения), и устройства USB 3.0.
• В качестве гостевой операционной системы поддерживается Mac OS X Server 10.6 – правда, к сожалению, не везде, а только на определенном оборудовании Apple Xserve.
• Storage DRS – автоматическое распределение хранения виртуальных машин в зависимости от нагрузки на системы хранения.
• Обновление файловой системы VMFS5 – поддержка LUN-ов больше 2 Тб.
• Поддерживается vMotion поверх сетей с высокими задержками.
• Поддержка до 32 виртуальных процессоров и до 1 Тб памяти на виртуальную машину.
• vSphere Web Client – несмотря на использование гипервизора ESXi, к нему возможен доступ из браузера.
• vCenter Server Virtual Appliance – работа сервера vCenter в качестве виртуальной машины на базе Linux.
• Поддержка виртуальными машинами считывателей смарт-карт.
• Swap to SSD – возможность разместить файл подкачки на дисках SSD, что, из-за их скорости, может сделать привлекательнее и быстрее memory overcommit.

Новое в лицензировании:

• Уменьшилось количество редакций vSphere – исчезла редакция Advanced. Так что остались только Standard, Enterprise и Enterprise Plus. Интересно, что ряд новых возможностей vSphere 5, описанных выше, будет доступен только в самой дорогой vSphere Enterprise Plus.
• Исчез лимит процессорной лицензии на количество ядер – теперь процессорная лицензия покрывает неограниченное количество ядер в одном процессоре. Сделано явно «на вырост», к требованиям прогресса
• Также исчезло лицензионное ограничение на максимальный объем физической памяти на хосте, бывшее в версии 4.
• В лицензирование добавилось понятие vRAM Entitlement – покрываемый объем общей виртуальной оперативной памяти. То есть, в организации лицензированы должны быть не только используемые хостами VMware процессоры, но и объем памяти, занимаемый всеми запущенными виртуальными машинами на всех хостах. Каждая процессорная лицензия уже включает в себя некоторый объем vRAM – например, лицензия Enterprise Plus включает в себя 48 Гб vRAM. Если виртуальные машины превышают включенный в лицензии объем, то необходимо приобретение дополнительных лицензий. Например, если есть два хоста виртуализации, каждый с одним процессором, но на каждом хосте виртуальными машинами используется по 60 Гб оперативной памяти – то две лицензии Enterprise Plus на процессор суммарно дадут объем vRAM только 96 Гб, что не покрывает общий объем в 120 Гб виртуальных машин, и потребуется докупка лицензий.
• Бесплатный гипервизор включает в себя vRAM entitlement только 8 Гб, то есть, бесплатно можно будет запустить виртуальных машин только на 8 Гб оперативной памяти суммарно.
• Проверка на соответствие vRAM Entitlement не является жесткой – только в версиях vSphere Essentials существует жесткое ограничение, не позволяющее превысить vRAM и запустить машин больше, чем лицензировано. В остальных версиях VMware будет ограничиваться срабатыванием Alert-а о том, что инфраструктура не соответствует лицензированию.

Подробнее о новых возможностях гипервизора, и о лицензировании можно прочитать в официальных документах здесь и здесь.

Наибольшим промахом своего предшественника я счел выбор GlusterFS. Для ядра linux существует модуль DRBD (Distributed Replicated Block Device), позволяющий создавать на машинах блочные устройства для репликации их по сети между распределенными узлами, который я и выбрал для решения поставленных целей. Для ОС Solaris, кстати, существует аналогичный DRBD проект Sun StorageTek Availability Suite. Для FreeBSD аналогов не существует, что не удивляет.

В качестве ОС было решено использовать SUSE Linux Enterprise Server 11 + дополнение High Availability Extention. SUSE поддерживается компанией Novell, включает в себя удобные утилиты конфигурирования и регулярно обновляется. А дополнение SLES-HA представляет собой набор ПО, организующего кластерные отношения между узлами, основанное на связке проектов Linux-HA и ClusterLabs. Другими словами – cluster membership service, графические утилиты настройки этих сервисов, утилиты для поддержки кластерных файловых систем и прочее. Хочу отметить что графические утилиты в ОС Linux по-прежнему остаются сыроваты, имеют очень ограниченный функционал и могут вызвать проблемы несовместимости. Пользоваться ими лучше аккуратно.

Итак, вышеописанное программное обеспечение было установлено на оба узла, поверх RAID-массивов. По значительному разделу было выделено под drbd-устройства, располагающиеся поверх логических томов LVM, позволяющих в будущем удобно менять размеры виртуальных машин. Загрузчик GRUB настроен на запуск по умолчанию ядра с поддержкой Xen. Все 4 сетевых интерфейса было решено агрегировать с помощью технологии linux bonding в 5 режиме адаптивной передачи нагрузки. В сети предприятия активно используются VLAN’ы, потому трафик на выходе кластера должен быть тэггированым по протоколу 802.1q, поддержка которого осуществляется модулем ядра Linux. Каждая виртуальная машина с помощью моста подключается к нужному VLAN’у. При выходе из строя 3 из 4 сетевых интерфейсов, вся система продолжает работать, но на скорости до 1 гигабита =)

С настройками DRBD все достаточно просто, единственное – рекомендовано не использовать внутренние meta-диски, особенно если в будущем понадобиться менять размеры устройств.

Теперь все готово для настройки самого кластера, которую можно разделить на 2 этапа: настройка основных компонент (OpenAIS + Pacemaker) и настройка ресурс-агентов кластера, непосредственно управляющих нашими сервисами.

При настройке OpenAIS и Pacemaker нужно учитывать что в 2х-узловой конфигурации не нужно использовать quorum.

Для нашего случая, в котором кластер следит за виртуальными машинами, для каждой из них необходимо настроить следующие ресурсы:

1. управляющие устройствами DRBD (один примитивный и один master/slave)
2. управляюший монтированием файловой системы
3. управляющий доменом Xen

После чего объединить их в группы и задать параметры order и colocation, объясняющие кластеру в какой последовательности запускать ресурсы.

На этом настройка кластера заканчивается. Используя продукты VMWare или Citrix осуществить эту задачу конечно легче и удобней, тк о многих вещах просто не приходится задумываться, но вместе с лицензией на ПО вам придется приобрести внешнюю СХД. Ни в ESX ни в XenServer нет поддержки репликации разделов между узлами, не смотря на то что построены они на базе того же ядра Linux с использованием утилит, разработанных в рамках проекта GNU.

PS. Недавно, на конференции «Russian Open Source Forum 2010», IT-директор АВТОВАЗа рассказывал про организацию инфраструктуры их головного офиса – все сервисы предоставлены почти таким же кластером, только с внешней СХД и другим дитстрибутивом GNU/Linux.

Dynamic Memory – это обновление к гипервизору Windows Server 2008 R2 Hyper-V, позволяющее динамически распределять всю оперативную память сервера между виртуальными машинами в зависимости от их загрузки. Возможно, виртуализация Hyper-V после этого станет еще интереснее.

RemoteFX – это обновление к Remote Desktop для Windows Server 2008 R2, входящее также и в клиент Remote Desktop для Windows 7. Предполагается, что RemoteFX позволит значительно ускорить отображение сложного контента, такого, как Silverlight, Flash, в терминальных сессиях.

А также – появилось важное обновление для виртуализации XP Mode в Windows 7. Теперь XP Mode не требует для запуска поддержку виртуализации на процессоре – так что он станет доступнее для клиентов.

На семинаре будут рассмотрены решения на базе Windows Server 2008 R2, Exchange Server 2010, и платформа для объединённых коммуникаций на базе Office Communications Server 2007 R2. В рамках семинара будет рассказано о продуктах для обеспечения информационной безопасности компании GFI.

Программа семинара ориентирована как на руководителей ИТ-подразделений, так и на технических специалистов и системных администраторов. Также семинар будет интересен для владельцев, руководителей организаций и предприятий, топ-менеджеров, принимающих решения о стратегическом развитии компании. На данном семинаре вы узнаете о новых возможностях каждого из продуктов, узнаете, как с помощью того или иного решения можно сократить затраты на ИТ-инфраструктуру, обеспечить надёжность и отказоустойчивость информационной системы, повысить производительность труда пользователей, и тем самым обеспечить конкурентные преимущества для вашего бизнеса.

Количество мест ограничено!

Для участия в семинаре требуется регистрация: http://www.lankey.ru/?id=1072#reg

Информация о семинаре на сайте Microsoft: http://www.microsoft.com/rus/events/detail.mspx?eventid=1032445810

Информация о семинаре на сайте GFI: http://www.gfi.ru/getnews.php?newsid=50

Информация о семинаре на сайте LanKey: http://www.lankey.ru/?id=1072

Компоненты интеграции предназначены для обоих версий платформы Hyper-V – как для первой версии, входящей в состав Windows Server 2008, так и для второй, входящей в состав Windows Server 2008 R2. Эти компоненты включают в себя:

• драйвер синтетической сетевой карты
• драйвер синтетического адаптера SCSI
• драйвер блочного устройства VSC – поддержка синтетического адаптера IDE для увеличения быстродействия при загрузке

Драйвер мыши для графической оболочки Linux в комплект не входит.

Обращаем внимание, что для большинства виртуальных машин Linux доступно использование только одного виртуального процессора. Полноценная поддержка Hyper-V в ядре начинается с ядра версии 2.6.32.

Технология Fault Tolerance, появившаяся в новой версии системы виртуализации VMWare vSphere, позволяет защитить виртуальную машину от сбоя физического хоста, даже не прерывая работы виртуальной машины. Все, что происходит в виртуальной машине, все процессорные инструкции, реплицируются на второй узел. И даже в случае сбоя первого узла – например, если пропало электропитание – виртуальная машина продолжит работать, сетевые соединения клиентов не будут разорваны, а приложения на сервере продолжат выполняться – клиенты и не заметят, что был сбой. Именно этим Fault Tolerance отличается, например, от High Availability – в случае с HA при сбое физического сервера виртуальные машины будут перезапущены на других узлах – при этом даунтайм составит время, необходимое для запуска виртуальных машин и загрузки операционной системы и приложений. В случае с Fault Tolerance даунтайма не будет.

Мы записали видео, демонстрирующее работу технологии Fault Tolerance:

Сегодня я решил рассказать как настроить кластер VMware, а также показать, как работают технологии VMware HA, Fault Tolerance и VMotion. Вкратце расскажу про каждую из этих технологий.

VMware VMotion

VMotion – это технология, которая позволяет переместить виртуальную машину с одного физического сервера на другой, не прерывая её работы. Зачем это нужно? Ну во-первых с помощью этой технологии можно непрерывая работы сервисов выключить сервер на обслуживание, предварительно переместив виртуальные машины на другие сервера. Во-вторых VMotion используется технологией DRS (Dynamic Resource Scheduler) для распределения виртуальных машин по физическим серверам в целях выравнивания нагрузки. Также есть технлогия Storage VMotion, которая позволяет без прерывания работы виртуальной машины переместить её виртуальный жесткий диск с одного дискового хранилища на другое. Технология Storage VMotion также может быть использована, для того чтобы отключить дисковый массив на обслуживание, например добавить жесткие диски, или перестроить RAID массив.

VMware HA

VMware HA – это технология, которая обеспечивает высокую доступность виртуальных машин. По сути сервер управления осуществляет мониторинг доступности виртуальных машин и хостов. Если хост  перестал отвечать, то сервер управления перезапускает работавшие на нём виртуальные машины на другом хосте. Для виртуальной машины это аналогично нажатию кнопки «Reset» на сервере. Т.е. в случае выхода из строя физического сервера, через несколько минут виртуальные машины автоматически запускаются на оставшихся серверах.

Fault Tolerance

Fault Tolerance – это технология отказоустойчивости, которая обеспечивает доступность виртуальных машин 24/7. По сути одна и та же виртуальная машина работает на двух серверах одновременно, а точнее даже сказать, что на одном хосте работает активная машина, а на втором работает её пассивная копия. Между активной и пассивной копией происходит односторонняя репликация процессорных инструкций. И в случае, если отказывает хост, на котором работает активная копия виртуальной машины, мгновенно активируется пассивная копия. При этом переключение оказывается прозрачным для пользователей и служб. В отличие от технологии VMware HA, перезагрузки виртуальной машины не происходит. Технология Fault Tolerance имеет ряд ограничений, например виртуальная машина должна использовать только один процессор, да и сам список совместимых процессоров достаточно ограничен, но об этом ниже.

Конфигурация тестового стенда

Для начала, немного расскажу, что представляет собой мой тестовый стенд. Тестовый стенд представляет собой 2 рабочих станции: 1-я имеет процессор Core2Quad Q6600 с 8 ГБ оперативной памяти и RAID 0 из 4 жестких дисков SATA по 500ГБ (на базе контроллера 3ware 9650SE), 2-я имеет процессор Core i7 920, 12 ГБ памяти и RAID 0 из 4-х дисков SATA по 500 ГБ на встроенном контроллере. На первой рабочей станции установлен VMware ESX 4, на второй установлен Windows 7 x64 и VMware Workstation 7. Внутри VMware Workstation создано 3 виртуальных машины: VMware ESX 4, Windows 2003 R2 + vCenter Server и Windows Storage Server 2008 + iSCSI Target. Физические сервера подключены к гигабитному свитчу, встроенному в Wi-Fi роутер. Управление системой я осуществляю через ноутбук, который по RDP подключается к серверу vCenter. Кстати, чтобы запустить ESX внутри VMware Workstation 6.5, нужно в файл конфигурации виртуальной машины добавить 2 строчки: monitor_control.vt32 = «TRUE» и monitor_control.restrict_backdoor = «TRUE». Внутри VMware ESX, который установлен внутри VMware Workstation можно запускать только 32-х битные системы.

Настройка кластера VMware HA

Теперь собственно о том, как настроить кластер. Запускаем vSphere Client и подключаемся к серверу vCenter. Сначала нужно создать ЦОД, нажимаем правой кнопкой по корню консоли и выбираем New Datacenter, ну и называем его как-нибудь интуитивно понятно. У меня один называется Moscow, второй Piter, в соответствии с нашими офисами. Затем нужно создать кластер, для чего нажимаем правой кнопкой по нашему датацентру и выбираем New Cluster, затем нажимаем несколько раз далее, далее и финиш, оставив всё по умолчанию. Теперь в кластер нужно включить хосты, т.е. наши физические сервера (в моём случае один из них виртуальный), нажимаем правой кнопкой по кластеру и выбираем Add Host, указываем имя или IP адрес хоста и логин и пароль на доступ (root/*****). После этого на хостах будет сконфигурирован агент vCenter и хосты начнут управляться через сервер vCenter.

Прежде, чем включать HA, нужно учесть одну вещь: работоспособность VMware HA зависит от работоспособности службы DNS. Т.е. все хосты и сервер vCenter должны разрешать имена друг друга, причем как короткие, так и FQDN. Т.е. вам нужно либо правильно настроить DNS, либо на всех хостах и сервере vCenter прописать правильные соответствия имён и IP-адресов в hosts-файл. Так что вот некоторая полезная информация:

hosts файл в Windows – C:\windows\system32\drivers\etc\hosts
hosts файл в Linux (на сервере ESX) – \etc\hosts
список DNS серверов в Linux – /etc/Resolv.conf

А вообще, если у кого-то возникнут проблемы с включением HA, то читать тут: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003735

Также нужно правильно настроить сетевые модули и интерфейсы хостов. Для работы VMotion и Fault Tolerance, нужно, чтобы модули VMkernel всех хостов были объединены в одну сеть. Вообще рекомендуется эти модули включать в отдельный виртуальный свитч, который подключен к раздельным сетевым интерфейсам физического хоста. Но у меня в тестовой среде нет  особого изобилия интерфейсов, поэтому модули VMkernel объединены в один свитч с обычной сетью. Также в свойствах модуля VMkernel должен быть разрешён VMotion.

Теперь можно включать VMware HA. Для включения HA, в консоли vSphere Clinet, подключенной к серверу vCenter нажимаем правой кнопкой по нашему кластеру и выбираем Edit Settings и ставим галку Turn On VMware HA, нажимаем OK. После этого все хосты, включенные в кластер, будут сконфигурированы для работы HA и Fault Tolerance.

В принципе всё готово. Напомню, что для работы HA и VMotion, жёсткие диски виртуальных машин должны располагаться на общих хранилищах (iSCSI, FC, NFS). Я использовал iSCSI на базе Windows Storage Server 2008. Далее я развернул виртуальную машину и установил внутри неё Windows Server 2003 R2, где я создал общую папку Share.

Запускаем VMotion

Чтобы переместить виртуальную машину с одного физического хоста на другой, нужно нажать правой кнопкой по виртуальной машине и выбрать Migrate. Затем указать, что мы хотим сменить хост или дисковое хранилище. Если мы мигрируем хост, то далее нужно будет указать на какой хост мы собираемся мигрировать машину. При выборе хоста, vCenter проверяет совместимость старого и нового хоста. Так, например в моём случае, ввиду различия процессоров на моих рабочих станциях (архитектуры Nehalem и Core), запустить VMotion с первого раза не получилось, мне было выдано, что хосты не совместимы (разные версии SSE).

Но эта проблема оказалась решаема. Нужно скрыть различающиеся биты идентификатора процессора от виртуальной машины. Для этого записываем различающиеся биты и регистр. В моём случае это CPU Level 1, регистр «ecx», различающиеся биты: —- —- *–* *— —- —-, чтобы их скрыть от виртуальной машины, нужно Выключить виртуальную машину, затем зайти в её свойства, перейти на вкладку Options, выбрать Advanced>CPUID MASK и нажать Advanced. Теперь нужно на место различающихся регистров вписать «0″, что означает «скрыть». Попытавшись выполнить миграцию ещё раз, я снова получил ошибку, но теперь уже из-за различий в регистре «edx». Это различие скорее всего вызвано тем, что ESX сервер на втором хосте работает внутри виртуальной машины, и ему недоступна 64 битная адресация памяти и VT. Со второй ошибкой поступаем точно также, как и с первой. Выписываем регистры и скрываем их от виртуальной операционной системы внутри виртуальной машины. В моём случае пришлось скрыть следующие регистры:

После этого VMotion заработал.

Работа VMotion

Как работает VMotion можно посмотреть на видео:

Работа VMware HA

Я также записал, как работает VMware HA, что тоже можно увидеть на видео ниже:

Настройка Fault Tolerance

Fault Tolerance включается очень просто. Нажимаем кнопкой по виртуальной машине, выбираем Fault Tolerance > Turn On Fault Tolerance.

После этого происходит создание пассивной копии виртуальной машины на втором хосте.  На скриншоте ниже видно, что у виртуальной машины теперь два хоста: основной – vsphere4 и вторичный – vmwareesx4.

К сожалению попытка включить виртуальную машину в режиме Fault Tolerance не увенчалась успехом ввиду того, что FT вообще не поддерживается на данных процессорах.

Это ограничение уже никак не обойти, и нужно использовать совместимые процессоры. Ниже привожу таблицу совместимости процессоров для использования Fault Tolerance:

Так, что на моей тестовой системе, заснять видео, как работает Fault Tolerance не получится. Но, как только мне выделят совместимые сервера у нас в офисе, я обязательно выложу видео, как работает Fault Tolerance.

Одним из модулей, устанавливаемых вместе с vCenter Server, является VMware vCenter Orchestrator. Также не буду углубляться в его возможности, скажу только, что это мощное средство управления жизненным циклом ЦОД. vCenter Orchestrator представляет собой среду разработки и автоматизации процессов управления виртуальной инфраструктурой. vCenter Orchestrator уже содрежит библиотеку шаблонов управления виртуальными машинами, хостами, хранилищами, сетями и т.д. Например, Orchestrator позволяет выполнить задачи по миграции виртуальных машин, на основании определённых условий, или, например, запланировать еженедельное создание снапшотов по расписанию. Ну и т.д, в общем возможности очень мощные и ограничены только фантазией)

Установка vCenter Server

И так, перейдём к процессу установки. Дистрибутив vCenter скачивается с сайта vmware, он представляет собой .iso образ объёмом примерно 1,5 ГБ. Текущая версия может быть развёрнута на Windows XP, 2003 и 2008 (не должны быть контроллерами домена). Собственно сама установка не представляет собой ничего сложного, и заключается в стандартном «Далее», «Далее» … Советую сразу установить и vCenter Server и vSphere Client и Update Manger, чтобы потом к данному диску не возвращаться.

В процессе установки будут установлены следующие приложения и службы: vCenter Server, vCenter Orchestrator, ADAM, SQL Server 2005 Express, Tomcat (вебсервер). В принципе сразу после установки vCenter Server, уже работает и к нему можно подключаться при помощи vSphere Client, авторизовавшись под учётной записью локального администратора сервера.

Но вот vCenter Orchestrator ещё нужно настроить.

Настройка vCenter Orchestrator.

1) Запускаем службу сервера настройки VMware vCenter Orchestrator Configuration. Это делаем либо через оснастку Services.msc, либо через консоль cmd:

net start VMOConfiguration

2) Заходим в WEB-конфигуратор: Пуск\Программы\VMware\VMware vCenter Orchestrator Configuration, (или браузером http://localhost:8282). При запросе логина и пароля вводим vmware/vmware. После входа увидим окно:

3) Конфигурируем меню General. В меню General переходим на вкладку Change Password и меняем пароль.

4) Конфигурируем меню Network.  По сути здесь просто надо выбрать IP-адрес на одном из интерфейсов и нажать Apply.

5) Конфигурируем меню LDAP. Если у вас большой ЦОД, да ещё и филиалы по всему миру, то наверняка управлять виртуальной инфраструктурой будет большая группа системных администраторов, которым нужно будет делигировать различные полномочия. В таком случае рекомендуется использовать ActiveDirectory (также можно использовать Open Ldap, Novel eDirectory, Sun Java System Directory Server). Но я бы не стал усложнять инфраструктуру, если управлять виртуальной инфраструктурой будет пара системных администраторов. И посему, я хочу чтобы управляющий сервер был надёжен и полностью независим от других серверов и служб.
Я решил консолидировать сервер управления VMware vCenter Server и VMware vCenter Orchestrator на одной виртуальной машине. Поскольку vCenter не может быть установлен на контроллер домена, а внешнюю службу каталогов я использовать не хотел единственное, что осталось это использовать ADAM. Один экземпляр ADAM был установлен при установке vCenter Server и им же и используется, называется он VMwareVCMSDS и слушает на 389 порту, в нём создан Application Partition: DC=virtualcenter,DC=vmware,DC=int. Не знаю можно ли было использовать этот же экземпляр ADAM для хранения учетных записей и групп Orchestrator, но я решил оставить его в покое и создать новый.

Устанавливаем новый экземпляр ADAM.

Нажимаем Пуск\Программы\ADAM\Create an ADAM instance, затем выбираем A unique instance, имя пишем какое хотим, например ADAM-VCO, нажимаем далее, по умолчанию предлагаются порты 50000 для LDAP и 50001 для secure LDAP, так и оставляем, далее на странице Aplication Directory Partition выбираем Yes, create an application directory partition и пишем: DC=vco,DC=vmware,DC=int (вы вправе использовать любой другой домен).

Затем нажимаем ещё несколько раз далее, на вкладке Importing Ldif files выбираем Import the selected ldif files и выбираем, как на рисунке ниже:

Затем несколько раз нажимаем Далее, Далее и finish.

Создаём пользователей и группы.

Экземпляр ADAM-VCO создан, но в нём нет ни пользователей ни групп. Подключаемся к этому экземпляру при помощи ADSIEdit, Пуск\Программы\ADAM\ADAM ADSI Edit. В меню Action жмём Connect to…, порт меняем на 50000, выбираем Distignushed name (DN) и пишем там DC=vco,DC=vmware,DC=int. Подключаемся, нажимаем правой кнопкой мыши по  DC=vco,DC=vmware,DC=int, выбираем New > Object…, выбираем organizationalUnit, пишем имя Users.

Создаём пользователя: жмём правой кнопокой по толькочто созданному OU, выбираем New > Object…, выбираем User, пишем имя vmware, жмём  OK. Затем нажимаем правой кнопкой по созданному пользователю и выбираем Reset password, и вводим пароль.

Создаём группу: жмём правой кнопокой по толькочто созданному OU, выбираем New > Object…, выбираем Group, пишем имя vCOAdmins, в поле groupType пишем 2147483646, что означает, что это будет группа безопасности, содержащая аккаунты.

Добавляем пользователя vmware в группу vCOAdmins: нажимаем правой кнопкой мыши по группе vCOAdmins, выбираем Properties, находим атрибут member, нажимаем Edit, затем нажимаем Add Adam Account… и вводим «CN=vmware,OU=Users,DC=vco,DC=vmware,DC=int«, жмём OK, OK, OK.

Добавляем пользователя vmware в группу Administrators:  нажимаем правой кнопкой мыши по группе Roles\Administrators, выбираем Properties, находим атрибут member, нажимаем Edit, затем нажимаем Add Adam Account… и вводим «CN=vmware,OU=Users,DC=vco,DC=vmware,DC=int», жмём OK, OK, OK.

Настраиваем  LDAP в VMware vCenter orchestrator configurator. Настраиваем, как на картинке ниже и нажимаем Apply:

Казалось бы, что всё хорошо и работает, но если перейти на вкладку Test Login и вбить нашего пользователя vmware и нажать Test Login, то получим ошибку, что пользователь не найден:

Проотестировав на полном Active Directory, эмпирическим путём было выяснено, что vCenter Orchestrator ищет  пользователя по атрибуту sAMAccountName. Если мы ещё раз посмотрим атрибуты пользователя vmware через ADSI Edit, то увидим, что в ADAM данный атрибут у пользователя отсутствует (рис слева):

Возникает резонный вопрос: Как этот атрибут добавить? Ну с одной стороны ответ простой: зарегистрировать оснастку редактирования схемы regsvr32 schmmgmt.dll, запустить mmc.exe и добавить оснастку ADAM Schema.msc. Затем создать новый атрибут sAMAccountName:

Затем добавить этот атрибут к классу securityPrincipal. Класс User в свою очередь связан с классом scurityPrincipal. Т.е. атрибут sAMAccountName также появится и у объектов типа User. Соотвественно далее, открываем свойства пользователя vmware при помощи ADSI Edit и присваиваем атрибуту sAMAccountName значение vmware. Теперь всё должно было заработать, но почему-то всёравно не заработало. Orchestrator по прежнему не находил пользователя. Я ещё раз проверил все атрибуты, но ошибок не нашёл. В общем я не знаю где я допустил ошибку или чего-то не учёл (кто знает, где я ошибся, пишите в коментарии).

Расширяем схему ADAM до Windows 2003.

Но я нашёл немножко обходной путь и просто расширил  схему ADAM до схемы Windows 2003, запускаем Пуск\Программы\ADAM\ADAM Tools Command Prompt, и выполняем:

ldifde -i -s localhost -c CN=Configuration,DC=X #ConfigurationNamingContext -f MS-AdamSchemaW2k3.ldf

Теперь снова запускаем VMware vCenter Orchestrator Configuration переходим на вкладку  Test login и вбиваем нашего пользователя vmware и нажимаем Test Login. Убеждаемся, что теперь ошибок нет и тест нормально проходит:

6)  Конфигурируем меню Database.  Orchestrator поддерживает Oracle, SQL Server, MySql и PostgreSQL. Но, если вы заметили, то при установке vCenter Server был установлен Microsoft SQL Server 2005 Express, был создан экземпляр SQLEXP_VIM, и была создана база данных VIM_VCDB. Опять же повторюсь, что если у вас не огромный цод из 1000 серверов, то ненужно напрасно усложнять инфраструктуру. Таким образом, я предлагаю использовать существующий SQL Server для хранения БД Orchestrator.

Настраиваем порты SQL Server-а.

После установки SQL Server не слушает на порту 1433, чтобы это поправить запускаем Пуск\Программы\Microsoft SQL Server 2005\SQL Server Configuration Manager, раскрываем SQL Server 2005 Network Configuration>Protocols for SQLEXP_VIM, открываем свойства TCP/IP, переходим на вкладку IP Address и в разделе IP ALL пишем TCP Port 1433, как показано на рисунке:

Создаём новую БД.

Создавать ещё один экземпляр нет надобности. Для того, чтобы можно было создань новую БД и назначить разрешения, нужно скачать и установить  Microsoft SQL Server Management Studio Express. Запускаем Запускаем Пуск\Программы\Microsoft SQL Server 2005\Microsoft SQL Server Management Studio Express.

Настраиваем аутентификацию SQL Server. Для начала нужно включить SQL Server ауентификацию, т.к. по умолчанию настроена только проверка подлинности Windows. Нажимаем правой кнопокой мыши по экземпляру в моём случае это VCENTER\SQLEXP_VIM, выбираем Properties, переходим в раздел Security и выбираем SQL Server and Windows Authentication mode.

Создаём базу данных. Затем нажимаем правой кнопкой мыши по Databases и выбираем New Databse, пишем имя VIM_VCODB, нажимаем OK. Далее переходим в VCENTER\SQLEXP_VIM\Security, нажимаем правой кнопокй по Logins и выбираем New Login. Пишем логин vmware, вводим пароль, снимаем все галки с политик пароля, внизу выбираем БД поумолчанию VIM_VCODB, язык по умолчанию English. В разделе Server Roles выбираем sysadmin. В разделе User Mapping отмечаем БД VIM_VCODB, нажимаем OK.

Настраиваем  Database в VMware vCenter orchestrator configurator. Настраиваем, как на картинке ниже и нажимаем Apply.

В первый раз будет выдана ошибка, что подключение к базе успешно, но база не наполнена. Нужно будет вверху нажать Install Database, а затем ещё раз нажать Apply. После этого должно быть выдано, что база данных успешно настроена.

7) В разделе Server Certificatе нажимаете Issue Self Signed Certificate. Заполняете все поля на своё усмоетрение, в поле Common Name,  лучше указать имя вашего сервера.

 В разделе License указываете свои данные и лицензионный ключ.

9) В разделе Plugins указываем имя пользователя и пароль, который входит в группу vCOAdmins, тот которого мы указывали в разделе LDAP (в моём случае это пользователь vmware).

10) Настраиваем раздел vCenter 4.  Нажимаем SSL Certificates, и добавляем сертификат из папки C:\Documents and Settings\All Users\Application Data\VMware\VMWare Virtual Center\SSL\rui.crt и нажимаем Import.
Возвращаемся в раздел vCenter 4, переходим на вкладку New Virtual Center Host. Указываем имя хоста vCenter, порт 443, ставим галку Secure channel, путь /sdk. Выбираем share unique session, и дважды указываем User name и Password, которые имеют административные права на сервер vCenter. В моём случае это локальный Administrator. Нажимаем Apply и затем Restart the vCO configuration server.

11) И последнее, переходим в раздел  Startup Options, нажимаем Install vCO server as service и нажимаем Start service.

Проверяем установку.

Пуск\Программы\VMware\vCenter Orchestrator Client, вводим логин/пароль нашего пользователя vmware (из экземпляра ADAM):

Если всё работает, то загрузится окно Orchestrator-а:

Итого.

В итоге мы получили полностью самостоятельный и изолированый центр управления VMware vCenter Server и VMware Orchestrator. Этот сервер является виртуальной машиной, и его работоспособность не зависит ни от корпоративно службы каталогов ни от корпоративных серверов баз данных. Я могу пренести эту виртуальную машину на любой хост и управлять виртуальной инфраструктурой.

Я более года пользовался Microsft Hyper-V  на своём домашнем сервере, и в принципе всем он меня удовлетворял, работал надёжно и без сбоев. Но всё же в предверии выхода Windows Server 2008 R2, перед апгрейдом решил попробовать VMware vSphere 4, всё-таки лидер рынка виртуализации. С первого раза вставать на мой домашний компьютер (ASUS P5E-VM HDMI\8GB RAM\Intel Q6600\3WARE 3650SE – RAID 10), VMware ESX отказался, не нашёл ни жёстких дисков, ни сетевых карт. Слава богу компания 3WARE сама написала драйверы для VMware http://www.3ware.com/kb/article.aspx?id=15548. Но вот сетевушки пришлось купить: Intel PRO/1000 PT Gigabit Adapter. В общем, в итоге ESX сервер установился и заработал.

Теперь собвственно встала задача развернуть виртуальные машины. Все образы операционных систем и куча всякого другого софта у меня была только на внешнем USB жестком диске.  И тут возникла проблема: VMware не предоставляет никаких средств доступа к USB накопителям! Через vSphere Client можно подмонтировать .iso образы с рабочей станции или размещённые на vmfs-хранилище, а также использовать физический CD-ROM сервера или рабочей станции, с которой запущен vSphere клиент.

Но для меня ни один из этих вариантов не являлся приемлемым. Я конечно мог подключить USB HDD к своему ноутбуку и подмонтировать .iso-шники к нему, но во-первых производить установку по Wi-Fi очень долго, во-вторых это ограничивает возможность удалённой работы, т.к., например ставить Windows Server 2008 r2 c DVD, через Интернет вообще не реально!

В общем всем известно, что VMware ESX 4 основан на Linux RedHat (что бы там не говорили про тонкий гипервизор и отсутсвие ОС), который, кстати, съедает памяти не меньше Windows Server 2008. Такчто задача заключалсь в том, чтобы подружить Linux и USB жесткий диск с файловой системой NTFS, а затем предоставить доступ к нему для VMware.

Сразу скажу, что я не являюсь специалистотм по Linux/Unix системам, и практически никогда с ними не работал, так что не надо меня сильно ругать! Ну не люблю я чёрные «готичные» текстовые экраны, где надо помнить кучи команд, где нет интуитивно понятного интерфейса и нет Vista Aero)

Открываем SSH

Сидеть за сервером неудобно, поидее у него вообще нет ни клавиатуры, ни мыши, ни монитора, поэтому первым делом открываем SSH, чтобы получить удалённый доступ к консоли. Для этого в главном окне vSphere Client переходим на вкладку Configuration, нажимаем слева внизу Security Profile, а затем справа вверху Properties. Там нужно будет отметить галку SSH Server.

Теперь к консоли VMware можно будет подключаться при помощи PuTTY по SSH. Казалось бы всё хорошо, но оказывается по умолчанию пользователю root запрещён вход по SSH. Чтобы разрешить пользователю root входить по SSH, нужно переконфигурировать демон SSH:
Логинимся на сервер VMware локально и редактируем файл /etc/ssh/sshd_config. В Linux есть страшный и ужасный редактор под названием VIM, который, для большей очевидности, запускаеся командой vi, в общем, чтобы отредактировать файл пишем:

vi /etc/ssh/sshd_config

В редакторе один раз нажимаем PageDown и находим строчку:
PermitRootLogin no
Нажимаем кнопку Ins, редактор переходит в режим редактирования, стираем no, пишем yes. Затем нажимаем ESC, нажимаем <Shift>+<:>, и пишем wq (это значит записать и выйти).
Теперь нужно либо перезагрузить сервер, либо перезапустить службу sshd:
[root@VMwareESX4 ~]# service sshd restart

Теперь вы можете подключаться к VMware через PuTTY, под учетной записью root.

Включаем поддержку NTFS

Включаем поддержку NTFS в VMware ESX 4, а точнее в Linux. По умолчанию Linux c NTFS не работает. Но немного погуглив, я нашёл драйверы, которые позволяют использовтаь NTFS в Linux. Например fuse-ntfs-3g. Для него требуется скачать 2 пакета:
fuse-2.6.3-1.el5.rf.x86_64.rpm
fuse-ntfs-3g-1.2310-1.el5.rf.x86_64.rpm
Все указанные в этой статье пакеты можно найти на www.rpmfind.net, ну или в www.google.ru)

Ещё у вас может возникнуть вопрос, каким образом эти пакеты запихнуть в VMware. Делается это так: Скачиваете пакеты и копируете их в какую-нибудь папку, например distr, затем в консоли vSphere Client переходите на вкладку Configuration, слева нажимаете Storage, справа выбираете VMFS раздел, нажимаете по нему правой кнопкой и выбираете Browse Datastore.

В Datastore Browser нажимаете кнопку Upload, выбираете Upload Folder, и закачиваете папку distr с пакетами на сервер.

Затем подключаетесь при помощи PuTTY к серверу VMware по SSH и устанавливаете пакеты:
Папку которую вы заливали при помощи Datastore Browser можно найти в консоли тут: /vmfs/volumes/VMFSpartition/distr, переходите в эту папку и ставите пакеты:

cd /vmfs/volumes/VMFSpartition/distr
rpm -i fuse-2.6.3-1.el5.rf.x86_64.rpm
rpm -i fuse-ntfs-3g-1.2310-1.el5.rf.x86_64.rpm

Монтируем USB HDD

Теперь монтируем наш USB жёсткий диск с файловой системой NTFS. Создаём папку монтирования:

mkdir /vmimages/usbhdd

И монтируем в неё наш жесткий диск:

mount -t ntfs-3g /dev/sda1 /vmimages/usbhdd

mount – команда монтирования; -t ntfs-3g задаёт тип файловой системы NTFS (драйвер которой мы поставили выше); /dev/sda – это устройство, которое мы монтируем, в моём случае жесткий диск висел именно на нём, в вашем случае может быть по другому, например sdb, sdc и т.д., возможно придется поискать; цифра 1 задаёт номер раздела на диске (1,2,3,4 – основные, 5,6,… – в Extended Partition).

Почему монтировали именно в папку /vmimages/usbhdd? Потомучто из консоли vSphere Client при загрузке образа в CD-ROM, выбрать .iso-шники можно токлько из папки /vmimages.

Монтируем .iso-шник в виртуальную машину через vSphere Client

Выбираете Connect to ISO image on a datastore…

Заходим в папку vmimages и видим там созданную нами папку usbhdd:

Входим в папку usbhdd и «вуаля», видим содержимое нашего USB-жесткого диска:

Выполняем резервное копирование виртуальных машин

Кроме того, что мы получили возможность монтировать .iso образы с USB HDD, теперь мы можем копировать виртуальные машины, причем как из VMware на USB жесткий диск, так и наоборот. Естественно виртуальные машины предварительно нужно остановить.

Устанавливаем Midnight Commander

Кстати, не знаю как вам, а мне не удобно строчить кучу команд в консоле, поэтому я решил установить файловый менеджер Midnight Commander:
Скачиваете пакет mc-4.6.2-3.pre1.fc9.x86_64.rpm, брать тамже на www.rpmfind.net, закачиваете его в VMware ESX, описанным выше способом, и устанавливаете:

rpm -i mc-4.6.2-3.pre1.fc9.x86_64.rpm

Теперь в консоле SSH будет работать веселее, набираем команду mc и наслаждаемся:

Кстати, для нормального отображения Midnight Commander в консоли PuTTY, нужно выбрать кодировку UTF-8. Нажимаем правой кнопкой по заголовку окна PuTTY, выбираем Change Settings, раскрываем раздел Window, переходим в Translation и справа выбираем UTF-8.

Устанавливаем SAMBA

Осталось только одно неудобство, которого не было в Hyper-V. Да я теперь могу с лёгкостью монтировать .iso-шники и ставить ОС, Office и т.д., но как быть с кучей софта, который распространяется не в .iso? Как этому софту в любой удобный для меня момент попадать с USB HDD внутрь виртуальной машины? В Hyper-V я мог просто расшарить папку с диском, а потом с виртуалок заходить на сервер \\hyper-v\usbhdd и получать доступ к софту.

Чтобы реализовать тоже самое на VMware пришлось установить сервер SAMBA. Но это оказалось сделать не так уж и просто. VMware использует очень обрезанную версию Linux RedHat, и кроме того все пакеты которые там стоят имеют очень старую версию. И почему ещё я не люблю Linux, так это из-за этой зависимости пакетов. Пытаешься установить один .rpm, который для своей установки требует 5 других, каждый из которых требует 5 ещё каких-то пакетов и т.д., какая-то цепная реакция), некторые из пакетов вообще требуют одновременной установки. В общем даю список пакетов, которые мне пришлось поставить, чтобы установить сервер SAMBA:

rpm -i –nodeps –force cups-libs-1.2.4-11.8.el5.x86_64.rpm
rpm -i –nodeps –force popt-1.13-4.fc10.x86_64.rpm
rpm -i –nodeps –force samba-common-3.0.33-0.fc8.x86_64.rpm
rpm -i –nodeps –force samba-3.0.33-0.fc8.x86_64.rpm

В общем-то сборник какой-то мути получился и наверняка можно было сделать всё иначе, но честно-говоря мне надоело разбираться с пакетами. И я стал использовать ключи –force и –nodeps (что наверное в общем-то не очень рекомендуется). Но тем не менее сервер samba установился и заработал.

Настройка:
Теперь у нас есть midnight commander и всё стало проще, запускаем mc, переходим в папку \etc\samba\, находим там файл smb.conf, нажимаем F4 и редактируем:

[Global]
security = user
passdb backend = tdbsam
encrypt password = yes
smb passwd file = /etc/samba/smbpasswd
domain master = no
domain logons = no

[share]
comment = root
path = /
browseable = yes
writable = yes

В 3-х словах: в этом файле мы указали путь к файлу паролей пользователей сервера samba – smbpasswd, создали общую папку «share», которая ссылается на корень раздела VMware. Т.е. по сути открыли доступ ко всем системным файлам!!, а аткже подмонтированным разделам, напр. нашему USB диску - /vmimages/usbhdd, а также разделу с виртуальными машинами - /vmfs/volumes/VMFSPartition.

Теперь нужно создать файл с паролями samba, его можно проимпортировать из системы, выполнив:

cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

Теперь нужно задать пароль для пользователей samba, мне нужен был доступ только для root, поэтому выполнил команду:

smbpasswd -a root

Как я думал, что всё готово. Но нет. Оказывается протокол SMB (порт TCP-139), был закрыт на файерволле VMware ESX. Открываем его следующей командой:

esxcfg-firewall –openPort 139,tcp,in,Samba

Если SAMBA сервер не запуститься автоматически, то запустить его можно выполнив команду: smbd

Ну в общем-то всё, открываем, заходим и используем:

Конечно можно сделать автоматическое монтирование внешнего HDD, подредактировав файл fstab, как наверное можно настроить автозапуск smbd, но мне это было не нужно (или лень возиться). Т.к. я всегда могу запустить нужные мне команды через SSH.

Вродебы всё!

PS: Я делал все эксперементы на тестовой машине, которую не жалко; Не повторяйте это в продуктивной среде!