Первый взгляд на System Center Virtual Machine Manager Technical Preview
Всем доброго времени суток и согревающего пламени от Лорда Огня!
Прошло, наверное, около 100 лет с моего последнего писания на хабре — в силу объективных обстоятельств… Но и они прошли и вот я вернулся! Да и темы есть интересные в достаточном объеме: и появление предварительной версии Windows 10 Technical Preview, и нового Windows Server Technical Preview… Ну и конечно же, System Center тоже ждет обновление — и про свой любимый VMM Technical Preview я расскажу сегодня. Не очень много, кратко — preview — оно и в африке превью, тут пока что многого не расскажешь, но все же…
На что ставить будем?
Ну прежде всего давайте разберемся на что сие чудо-юдо можно нагромоздить, прежде чем проводить какие-либо изыскания и тестирования. Требования возникают следующие:
— Сервер управления VMM (VMM Management Server) — его нужно ставить поверх Windows Server Technical Preview, ссылка на который есть в начале статьи. Также для установки VMM Вам понадобится Windows Assessment and Deployment Kit 8.1 и старше.
— Сервер баз данных для VMM — здесь в исключительном варианте нужно ставить SQL Server 2014 — и не ниже Standard Edition. Его можно поставить как на том же сервере, что и сам сервер VMM, так и на удаленном, выделенном сервере.
— Консоль VMM — ну как минимум ее нужно поставить на том же сервере, что и сервер VMM, а для удобства на любой системе на базе Windows Server Technical Preview, или же Windows 10 Technical Preview — если речь идет про клиентскую Ось.
— Сервера библиотеки VMM — по сути это сетевая файловая шара на любом сервере на базе все того же WS TP.
— Хосты виртуализации Hyper-V — они должны быть все также на базе Windows Server Technical Preview.
— Сервер обновления WSUS — а вот тут история выглядит немножко иначе, если вы хотите добавить сей инфраструктурный компонент, то он должен быть на базе Windows Server 2012 R2 с установленной ролью Windows Server Update Services.
— Сервер мониторинга и отчетности — это по сути Operations Manager TP на базе WS TP. Сервер БД же должен быть либо SQL Server 2012 SP2, либо SQL Server 2014 с функционалом reporting services.
Также напомню вам, что у вас должен быть развернут домен для управления всеми компонентами виртуальной инфраструктуры или же облака, как следствие. И после всех нехитрых телодвижений получаем привычное (уже-еще) окно для ввода реквизитов для доступа к консоли VMM.
Их с нами больше нет
Может быть я утрирую и чрезмерно трагичен — но предлагаю начать с того, чего больше в VMM мы не увидим. И так — вот список:
— App Controller — этот компонент канул в Лету, так как его роль на себя взял Windows Azure Pack, так что у нас на лицо простое избавление от продуктов, дублирующих функционал и унификация механизмов и интерфейсов частного и публичного (привет гибридному) облаков.
— Поддержка VMWare vCenter — теперь поддерживаются только версии 5.5 — остальным всем версиям либо «гуд бай», либо еще рано (я надеюсь — а то ESXi 6.0 тоже скоро выйдет — и хотелось бы уметь с ним работать сразу и без ожиданий)…
— Поддержка Citrix XenServer — все, «финита ля комедия», теперь этот компонент полностью лишился поддержки со стороны VMM. Печаль, но что поделать…
А что в виртуалке самой?
Что же касается гостевых ОС, то тут все достаточно просто: все что было раньше — оно работать будет, без официальной поддержки — поскольку мы говорим про Technical Preview версию продукта. Также добавилась работа с гостями на базе WS TP и W10 TP. С Linux-тусовкой у нас пополнение, а именно:
— CentOS versions 5 и 6
— Red Hat Enterprise Linux versions 5, 6, и 7
— Oracle version 5, 6, и 7
— SUSE Linux Enterprise Server version 11
— Ubuntu versions 12 и 14
Так что здесь все вполне ожидаемо и предсказуемо, без сенсаций — скажем прямо. Да и в принципе, список гостей уже давно всем известен, дело осталось за малым — научиться их встречать и сопровождать в индивидуальном порядке, даже не смотря на ядерно-родственные связи.
Здесь также появился ряд улучшений и особенностей. Давайте их рассмотрим подробнее:
— Целостное именование виртуальных сетевых адаптеров — это прежде всего относится к гостевым ОС. Раньше если у вас внутри ВМ было несколько адаптеров, один из которых, например, смотрит во внешнюю сеть, а другие — во внутреннюю — то для достижения такой цели нужно было поплясать с бубном — привет VB-скрипты или PowerShell. Теперь же при развертывании виртуальных машин 2-го поколения вы можете указать имена для адаптеров как в процессе развертывания, так и в шаблоне ВМ, что в последующем очень сильно облегчает идентификацию сетей.
— Расширение функционала VMM за счет Service Extensions — теперь эти компоненты можно добавлять непосредственно из консоли VMM.
— Создание и применение логических коммутаторов (logical switches) — это позволяет создавать на Windows Server Technical Preview шаблоны виртуальных коммутаторов, а также профили и классификации портов и массово применять их на хосты виртуализации на базе WS TP.
— Конфигурации сетей виртуальных машин — для решения данной задачи вы можете использовать логические сети, сети ВМ, пулы MAC-адресов и пулы IP-адресов как по отдельности так и в сочетаниях различных для настройки параметров сетей для ВМ.
Хранилища
Ну и в завершении, расскажу я про то, что у нас творится с СХД и их инкарнациями.
Что касается блочного типа доступа к хранилищам:
— Вы можете предоставлять хранилища на блочном уровне с помощью механизмов iSCSI и Fiber Channel.
— ВЫ можете, в контексте FC, управлять фабриками и зонами вашей SAN-сети.
Что же касается файлового уровня, то здесь ситуация такая:
— на базе SOFS, масштабируемого файл-сервера, что на базе WS TP — можно создавать как файловые шары для размещения ресурсов, так и пулы хранения (storage pools) — правда последние — это все же блочный уровень доступа.
— Также VMM может предоставлять ресурсы хранилища путем самостоятельного развертывания SOFS, или же путем добавления ресурсов на базе сторонних NAS-устройств.
В целом картина выглядит как-то так. Я лично не могу сказать, что появилось множество новых или же невостребованных функций, но состав движется в верном направлении. Я думаю, что нас еще ждут интересные новинки впереди — и как только их наберется достаточно — мы обязательно про них расскажем. Всем хорошей недели!
Есть у MS такая штука – VirtualMachineManager (VMM или более полно SCVMM). По сути, это управлялка хостами Hyper-V. Аналог vCenterServer от VMware. Так вот, Hyper-V 3.0 вышел совсем недавно, но управлялка пока лишь в статусе беты. Но это не мешает ознакомиться с построением виртуальной инфраструктуры от MS. Итак, приступим.
2. Требования.
Великих требований нет (их всего 3): SCVMM должен быть в домене, требуется наличие SQL и наличие AssessmentandDeploymentKit (ADK). Мануал по развертыванию SCVMM есть у самого MS. Также есть отличная дока здесь. А сами требования отлично расписаны здесь. Особое внимание нужно обратить на то, что в названии сервера SCVMM не должно быть знаков тире, т.е. обозвать сервер, напрмер, VDI-SCVMM нельзя, а вот VDISCVMM – можно. Глупость, но что поделать. Так что мы обзовем сервер HVMANAGER и установим на него и SQL, и ADK, и SCVMM. Предполагается, что домен и хост Hyper-V имеется в наличии (у меня он остался от VDI-инсталляции). Итак, поехали.
3. Установка SQL Server 2012.
Из требований получаем, что нужно при установке выбрать компоненты Database Engine Services и Management Tools – Complete. Да, поддерживается не только SQL 2012, но и предыдущая версия. Но так же стоить отметить, что версия Express не поддерживается.
Теперь установка на скриншотах.
Выбираем установку нового Standalone-сервера:
Здесь отмечаем необходимые компоненты:
Учетные записи (доменные):
Указываем администратора сервера SQL:
Все, SQL сервер установлен. Больше с ним ничего делать не требуется.
4. Установка Assessment and Deployment Kit (ADK).
Качается эта штука отсюда. Причем качается файл в 1.5 МБ, который потом выкачивает из интернета требуемые компоненты. Это очень долго, потому как качать 3 ГБ. Поэтому необходимо перед планируемой инсталляцией запустить файл, и выбрать загрузку куда-нибудь всего софта ADK:
А уже после загрузки, скачать папку с содержимым ADK на будущий сервер SCVMM, и запустить файл установки ADK вновь (потребуется установить лишь DeploymentTools и WindowsPE):
После установки, перезапускаем сервер и приступаем к инсталляции SCVMM 2012SP1Beta.
5. Установка SCVMM 2012 SP1 Beta.
Далее будут одни картинки.
Выбираем что инсталлить:
Указываем SQL сервер (он установлен на сервере SCVMM):
Здесь создается библиотека (каталог) – ничего не меняем:
6. Базовые операции в SCVMM.
Мы установили SCVMM. Теперь добавим хост и, пожалуй, закончим.
Выбираем добавить хост:
Выбираем пункт о том, что хост в домене:
А тут надо добавить алиас учетки, с которой SCVMM будет искать хосты:
Добавляем админа домена под алиасом HVAdmin:
Указываем, что искать:
И оно находит (правда почему-то SCVMM не увидел роли Hyper-V на нашем сервере Hyper-V)… MS, такой MS:
Далее оставляем все по дефолту:
И хост все же добавляется без всяких ребутов:
И вот что мы видим:
Дальше можно играться как угодно J Создавать коммутаторы, добавлять стораджи, конвертировать машины друг в друга итд. Но, VMwarevSphereClient однозначно удобней – дело даже не в привычке, дело именно в «эргономике» для администратора. В vSphereClient’е можно сразу понять, где, например, сети и КАК ими управлять, КАК создать группы портов с VLAN-ами, все наглядно представлено на ЕДИНОМ рабочем поле. Здесь что-то понять сложно, нет простой наглядности. Да, куча информации, но она разбросана, что сводит на нет «единость» консоли управления, ИМХО.
1. Развертываем три виртуальных машины, пару пустых, одну с SQL-сервером, они впоследствии станут нашими звеньями; 2. На SQL-сервер устанавливем базу данных приложения, прописываем пользователей; 3. На сервер приложения раскатываем App-V пакет с приложением магазина, конфигурируем строки подключения к SQL-серверу; 4. На веб-морду устанавливаем веб-странички, конфигурируем веб-приложение для подключения к серверу приложения.
Как вообще происходит развертывание? Первым делом при развертывании Virtual Machine Manager создает виртуальную дискетку, а на дискетку записывает файл ответов и при развертывании виртуальной машины, она читает этот файл ответов, присваивает себе имя, устанавливает параметры сетевого интерфейса и даже включает себя в домен Active Directory. На второй стадии SCVMM устанавливает на виртуальные машины своего агента и службы интеграции, а на третьей уже создает ISO-образ c приложениями, базами данных, другими конфигурационными скриптами, монтирует этот ISO-образ в виртуальный привод и запускает с него установку приложений. Как видите, взаимодействие с виртуальной машиной происходит только с помощью примитивных вещей: виртуальной дискетки и виртуального DVD-диска, ибо установка агента, равно как и установка служб интеграции также является установкой с соответствующего ISO-образа в приводе.
Все так? Так, да не так. Дело в том, что для того, чтобы собрать строку подключения к SQL-серверу, необходимо имя этого SQL-сервера как минимум знать. Для того, чтобы собрать строку подключения к приложению, также нужно знать адрес сервера этого приложения. Между тем, в System Center Virtual Machine Manager 2012 есть три способа задать имя сервера:
1. Задать его просто текстом, например «SQLServer»; 2. Задать его шаблоном с циферками, например «SQLServer##», в этом случае когда будет создаваться первый сервер, SCVMM даст ему имя SQLServer01, второй — SQLServer02 и т.п.; 3. Задать его переменной, например «@SQLServer@», в этом случае администратору перед развертыванием в диалоговое окошко придется вбить «SQLServerForPetShop» или что-то вроде того, что и станет впоследствии именем сервера.
Первый вариант отметаем сразу, потому что мы исходим из того, что сервисов у нас много, а значит много машин с одним и тем же именем, а машины с одним и тем же именем иметь плохо. Второй вариант хорош, но появление цифр в конце исключает детерминированность сервера. Проще говоря, на звене 2 мы не знаем, какую именно цифру SCVMM присвоил звену 1. В самом деле, мы знаем, что там в начале SQLServer, а дальше 01? 05? А может 25? Третий вариант хороший, спору нет, но в этом случае администратору самому, лично приходится заботиться об во-первых, уникальности названий серверов, и о во-вторых, соответствии имен серверов конвенции именования, принятой в организации. В общем, выходит, что все три варианта есть, и все три плохие. Как Microsoft рекомендует выбираться из такого рода ситуации? А никак.
Вот эта картинка с 245 страницы книги Айдана Финна Microsoft Private Cloud Computing издательства Sybex наглядно показывает, что чтобы развернуть сервис, Petshop’а, необходимо посмотреть глазками в верхнюю часть экрана, увидеть надпись MidSvr01 и ручками написать эти слова вниз, в поле lobComputerName.
Причем такое вот переписывание буковок с экрана на этот же экран, видимо, официальная позиция Microsoft, которая повторяется, например, здесь, в блогах на Technet.
То есть еще раз: они предлагают увидеть на экране строчку и вбить ручками эту строчку на этом же экране.
Приемлемо ли это для нас? Ну конечно же нет! Информация возникает лишь в одном месте, необоснованное дублирование информации чревато ошибками, и использовать такой подход мы будем чуть реже, чем никогда в жизни.
Вернемся к нашей песочнице. Предположим, что у нас есть контроллер домена в лесу Active Directory и сервер — член этого домена. Теоретически, этого достаточно при условии возможности масштабирования сервиса, т.е. дублирования этого сервера-члена домена еще, еще, и еще.
Формулируя техническое задание к системе песочницы, мы можем сказать, что система должна содержать контроллер домена Active Directory, не связанного с другими лесами какими-либо, в том числе и доверительными, отношениями, а также система должна содержать в себе сервер, включенный в домен Active Directory, который бы без лишних усилий мог бы быть тиражирован. В этом случае при желании мы можем накатить на сервер Exchange, SQL Server, и многое, многое другое.
Создать контроллер домена Active Directory из SCVMM непросто: контроллер домена не поддается виртуализации приложений App-V, поэтому контроллер домена мы будем устанавливать из командной строки. Есть такая утилитка dcpromo, которая создает хоть домен, хоть лес, хоть даже вселенную, и, скажу я вам, вопреки разнообразным статьям из разряда «Наступил конец dcpromo, да здравствует PowerShell!» dcpromo сохранен в Windows Server 2012, но лишь как средство командной строки. Об этом можно почитать, например, здесь. Обратите внимание на строку:
If you run dcpromo /unattend from a command prompt, you can still perform unattended installations that use Dcpromo.exe
То есть, unattend-инсталляцией можно прекрасно пользоваться и в Windows Server 2012, что, собственно, нам и нужно. Хотя, конечно, PowerShell мы все любим неувядающей любовью, и касабельно новшеств именно в 12 сервере у меня даже есть пара статей. Но совместимости ради мы используем файл ответов, потому что он работает как в 2008R2, так и в 2012. Итак, чтобы поднять контроллер домена Active Directory, мы запустим этот cmd-файл, привязанный к профилю приложений в сервисе песочницы:
Обратите внимание, с самого начала запускается
По той простой причине, что далее у меня неподписанные скрипты PowerShell. Скрипты PowerShell можно и нужно подписывать: от этого зависит ваша безопасность, безопасность вашей организации. О том, как подписывать, уже вроде бы пролетали тут пара топиков, ну а если нет, я с удовольствием опишу этот забавный, но познавательный процесс.
Теперь смотрите, вызывается некий скрипт CreateAnswerFile.ps1, которому как входной параметр дается домен. Вот этот скрипт:
Только опять же, обратите внимание, у меня тут %windir% как C:\windows, вряд ли у вас будет иначе, но всё же я обязан предупредить.
Окей, контроллер домена у нас поднят, это нам по нраву. Но для того, чтобы некий сервер включить в члены этого домена, он должен во-первых, получить адрес этого контроллера домена, во-вторых, получить настройку на своем сетевом интерфейсе: ему в качестве DNS сервера должен быть установлен этот контроллер домена, ну а в-третьих, получить команду на включение в домен. А как нам получить ip адрес DNS-сервера? Ведь по условию задачи, мы находимся в изолированной отовсюду сети и не знаем ничего, даже имени контроллера домена, который разворачивается параллельно с нами.
Есть способ. Помните, что когда-то был развернут SCVMM — гостевой агент? Так вот, во время развертывания этого гостевого агента, внутри него совершенно магическим образом возникает файл настроек с конфигурацией сервиса. Этот файл содержит в себе информацию, во-первых, жутко обрезанную, а во-вторых, доступную лишь учетной записи системы (SYSTEM). Но это, как вы понимаете, файл не спасет, ибо если информация проявилась, то ее уже не уничтожить. Из этого файла, который очень похож на XML, за исключением первых 16 бит, мы извлекаем имя контроллера домена. Да, да, то самое, которое было динамически сгенерировано во время развертывания сервиса. Имея имя, мы можем это имя разрешить в ip адрес, правильно?
Нет, не правильно, потому что у нас нет DNS-сервера, который бы нам ответил, мы попросту не знаем, к кому обращаться. Поэтому мы на помощь призываем старый добрый протокол NetBIOS, который понимает, что такое широковещательный запрос разрешения имени. Иными словами мы, зная имя сервера, кричим громким криком в сеть: «А ну, такой-то и такой-то, отзовись!» И он отвечает: «Вот он я, только не бейте меня пожалуйста!». Мы берем его адрес в качестве DNS-сервера, и далее включаем себя в домен. Mission Accomplished.
Учитывая то, что этот скрипт выполняется каждый раз масштабировании сервиса, мы можем выполнять его бесконечно и таким образом наша песочница превратится в «контроллер домена + (пустой_сервер x N)».
Ну а теперь, пожалуйста, сам скрипт:
Обратите внимание, тут у меня логин/пароль указаны явно. Совершенно очевидно, что вам безопасности ради придется их спрятать. Итак, включив этот скрипт в профиль приложения, и выполнив его при развертывании на N серверах, мы получаем нашу песочницу.
Теперь мы можем нашу песочницу модифицировать как угодно, писать туда программы, удалять оттуда программы, создавать пользователей, удалять, модифицировать схему, атрибуты, делать что нашей душе угодно. Ну а если вдруг ее испортим, то песочницу удалить и в полчаса создать по новой! Или даже две песочницы создать нам не составит труда. Это же просто рай для разработчика и тестировщика! Блог Айди Финна таки рекомендую к прочтению, он там пишет очень прелестные вещи.
Более 5550 заметок о виртуализации, виртуальных машинах VMware, Microsoft и Xen, а также Kubernetes
VM Guru / Articles / Виртуальная инфраструктура под управлением Microsoft Virtual Machine Manager.
Виртуальная инфраструктура под управлением Microsoft Virtual Machine Manager.
Виртуальная инфраструктура под управлением Microsoft Virtual Machine Manager.
Автор: Александр Самойленко Дата: 06/12/2007
Компания Microsoft имеет довольно долгую историю поддержки и продвижения технологий виртуализации. Еще в 2003 году корпорация Microsoft приобрела компанию Connectix, которая занималась разработкой настольной системы виртуализации Virtual PC для платформ Mac OS и Windows. После поглощения Connectix, издание продукта для Windows было несколько переработано и выпущено уже под редакцией Microsoft в 2004 году. На тот момент Virtual PC не сильно уступал платформе VMware Workstation и при должном внимании мог вполне конкурировать с ней. На базе Virtual PC компания Microsoft принялась за разработку серверной платформы Virtual Server 2005, которая была направлена на виртуализацию и консолидацию парка серверов организаций различного масштаба. Сначала существовало два платных издания Virtual Server: Standard и Enterprise, которые, однако, не приобрели большой популярности. К тому же, компания VMware объявила о выходе бесплатной платформы VMware Server, что вынудило компанию Microsoft в апреле 2006 года сделать продукт Virtual Server 2005 бесплатным, оставив лишь издание Enterprise Edition.
Уже тогда становилось ясным, что основной доход производителей средств для виртуализации будет складываться в будущем не из стоимости самих платформ, а из продаж средств для поддержки комплексной виртуальной инфраструктуры, включающей в себя не только серверы виртуализации, но и средства миграции, развертывания, управления и автоматизации операций. Тогда же, в 2006 году, у Microsoft созрел план по созданию новой низкоуровневой платформы виртуализации, получившей название Windows Virtualization, которая будет поставляться вместе с ОС Windows Server. Управляющее ПО (гипервизор) получило кодовое название Viridian, сама же технология виртуализации была переименована позднее в Hyper-V.
Окончательный релиз Windows Virtualization постоянно переносился из-за технических сложностей и на данный момент известно, что он появится во второй половине 2008 года. Сейчас существует Hyper-V Preview, включенный в Windows Server 2008 Release Candidate. До выхода Windows Virtualization компания Microsoft продолжает развивать платформу Virtual Server 2005 R2, к которой недавно был выпущен первый пакет обновлений, включающий в себя поддержку аппаратной виртуализации и «горячего» резервного копирования виртуальных машин средствами служб теневого копирования тома (Volume Shadow Services, VSS). Создание резервных копий виртуальных машин сейчас доступно средствами продукта Data Protection Manager 2007 из семейства System Center.
Основную же ставку в свете продаж средств виртуализации компания Microsoft сейчас делает на недавно выпущенный продукт System Center Virtual Machine Manager (SCVMM) для управления виртуальной инфраструктурой на базе Virtual Server 2005 и, впоследствии, серверами Windows Virtualization.
Обзор возможностей Virtual Machine Manager
Ключевое достоинство Virtual Machine Manager – тесная интеграция с другими решениями Microsoft для управления инфраструктурой Windows-серверов семейства System Center. SCVMM позволяет создать гибкую виртуальную инфраструктуру на основе платформы Virtual Server 2005 R2 и упростить развертывание виртуальных систем из центральной библиотеки шаблонов. Основные возможности SCVMM включают в себя:
Простой подбор серверов-кандидатов на консолидацию
SCVMM позволяет использовать базу данных Operations Manager 2007, в которой собраны данные о производительности физических серверов, и определить наиболее подходящие для виртуализации серверы.
Удобная P2V (Physical to Virtual) и V2V (Virtual to Virtual) миграция
SCVMM имеет встроенные средства миграции (ранее для этих целей использовался Virtual Server Migration Toolkit), использующие службы теневого копирования тома для преобразования физических серверов в виртуальных без их остановки. Кроме того, Virtual Machine Manager позволяет преобразовывать виртуальные машины VMware в формат Virtual Server. В данный момент поддерживаются ОС Windows 2000 Server и Windows Server 2003 в качестве исходных систем для миграции в виртуальную среду.
Intelligent Placement
Virtual Machine Manager обладает возможностью интеллектуально размещать виртуальные серверы на физических компьютерах, используя данные об их рабочих нагрузках. Это позволяет системным администраторам управлять развертыванием виртуальных систем, основываясь на требованиях к их доступности, и создавать сбалансированную виртуальную инфраструктуру. Рейтинг каждого из физических серверов в отношении готовности к развертыванию на них виртуальных систем может быть представлен в виде условных очков, отображаемых звездочками.
SCVMM позволяет использовать командную оболочку PowerShell для написания сценариев автоматизации операций с виртуальными системами. Например, во время процедуры миграции с физического сервера на виртуальный можно получить скрипт PowerShell, просто нажав на кнопку «View Script». В дальнейшем его можно использования для написания сценария потоковой миграции.
Централизованное управление и настройка ресурсов
Консоль администратора Virtual Machine Manager позволяет централизованно управлять всеми аспектами виртуальных систем, а также проводить «горячую» миграцию виртуальных машин с одного физического сервера на другой в случае возросшей нагрузки или необходимости остановки сервера на обслуживание.
SCVMM имеет собственный портал самообслуживания, используя который пользователи, обладающие необходимыми правами, могут сами развернуть виртуальные машины с помощью мастера, не прибегая к услугам системных администраторов.
При этом пользователям могут быть делегированы различные привилегии и назначены квоты на использование ресурсов. Централизованная библиотека шаблонов
Virtual Machine Manager имеет отдельный компонент – централизованную библиотеку шаблонов, которая содержит в себе ISO-образы для установки гостевых систем, готовые к развертыванию виртуальные машины, а также различные сценарии настройки после установки и шаблоны. Библиотека позволяет избежать дублирования «строительных блоков» виртуальной инфраструктуры на различных компьютерах и организовать к ним простой доступ с возможностью поиска элементов.
Централизованный мониторинг и отчетность
Из консоли администратора может производиться централизованный контроль параметров и производительности виртуальной инфраструктуры. SCVMM тесно интегрируется с Operations Manager 2007 и позволяет использовать службы SQL Reporting Services для построения различных отчетов на основе информации, хранящейся в единой базе данных. Централизованный мониторинг виртуальной инфраструктуры может производиться посредством Virtualization Management Pack для Operations Manager 2007.
Поддержка сетей хранения данных SAN
Virtual Machine Manager автоматически обнаруживает существующую инфраструктуру SAN (Storage Area Network) и позволяет настроить передачу тяжеловесных образов виртуальных машин через высокоскоростные линии связи (Fibre Channel или iSCSI), не загружая сеть LAN.
Развертывание Virtual Machine Manager
SCVMM представляет собой многокомпонентное и гибкое решение для развертывания виртуальных инфраструктур различного масштаба. Продукт может применяться как в малых и средних предприятиях для управления несколькими серверами виртуализации, так и в крупных организациях с сотнями виртуальных серверов, где присутствуют другие решения на основе продуктов семейства System Center. Компоненты SCVMM могут быть разнесены по разным физическим компьютерам, управление и обслуживания каждого из которых может быть назначено отдельному человеку. На данный момент виртуальная инфраструктура на базе SCVMM не обладает такими широкими возможностями, как Virtual Infrastructure 3 компании VMware, однако с приходом технологии Hyper-V на базе Windows Server 2008 ситуация, возможно, изменится. Учитывая маркетинговые возможности Microsoft и сеть ее партнерств, а также степень интеграции Virtual Machine Manager с другими инфраструктурными решениями компании, у Microsoft есть все шансы.
Системные требования SCVMM
Компоненты продукта Virtual Machine Manager могут быть развернуты на одном или нескольких управляющих серверах, при этом системные требования зависят от числа управляемых серверов виртуализации. В случае если все компоненты SCVMM развертываются на одном физическом сервере, необходима следующая конфигурация:
Аппаратный компонент
Минимальные требования
Максимальные требования
От 5 до 10 управляемых серверов виртуализации
Процессор
Pentium 4, 2 ГГц
Dual-Core Pentium 4, 3.2 ГГц или выше
Объем оперативной памяти
2 Гб
2 Гб
Жесткий диск
80 Гб
150 Гб
От 11 до 20 управляемых серверов виртуализации
Процессор
Pentium 4, 2.8 ГГц
Dual-Core Pentium 4, 3.2 ГГц или выше
Объем оперативной памяти
2 Гб
4 Гб
Жесткий диск
150 Гб
200 Гб
При разнесении сервера баз данных, управляющего сервера, консоли администратора, портала самообслуживания и библиотеки виртуальных шаблонов на разные физические серверы стоит придерживаться рекомендаций Microsoft для каждого из этих компонентов.
Для управления инфраструктурой до 150-ти физических серверов виртуализации, в качестве управляющего сервера вполне подойдет компьютер с частотой процессора 3 ГГц и четырьмя гигабайтами оперативной памяти (всего поддерживается не более четырехсот физических серверов). При этом стоит заранее спланировать большой объем дискового пространства для сервера баз данных и хранилища виртуальных шаблонов. Для портала самообслуживания и консоли администратора требования невысоки.
Архитектура SCVMM
Как уже было сказано ранее, компоненты Virtual Machine Manager могут быть установлены, как на одном физическом сервере, так и разнесены по нескольким. При этом осуществляется их тесное взаимодействие, как между собой, так и с другими элементами инфраструктуры System Center. Архитектура решения представлена ниже:
К основным компонентам SCVMM относятся:
Virtual Machine Manager Server (управляющий сервер)
Это основной управляющий элемент продукта, который должен быть установлен первым. Он осуществляет взаимодействие всех компонентов решения SCVMM. Manager Server реализует службу, которая исполняет управляющие команды, передает файлы и контролирует взаимодействие с серверами виртуализации, хранилищами виртуальных шаблонов и другими компонентами. На управляемых компьютерах запущены специальные агенты VMM, которые обмениваются информацией с Manager Server посредством механизма Windows Remote Management. Кроме того, Manager Server соединяется с базой данных SQL Server, которая хранит конфигурационную информацию. По умолчанию Manager Server также является библиотекой виртуальных шаблонов.
Virtual Machine Host (сервер виртуализации)
Под этим компонентом понимается непосредственно управляемый сервер виртуализации, на котором установлена платформа Virtual Server 2005 R2 SP1. Хосты могут быть добавлены из консоли администратора. При их добавлении на этих серверах устанавливается сама платформа, а также агенты для взаимодействия с Manager Server.
В виртуальной инфраструктуре может использоваться несколько библиотек, которые добавляются из консоли администратора.
Administrator console (консоль администратора)
Этот графический интерфейс управления виртуальной инфраструктурой, который устанавливается после Manager Server, является основным инструментом системного администратора. При установке консоли устанавливается также оболочка PowerShell, позволяющая управлять виртуальными машинами из командной строки. Если вы хотите использовать возможности Reporting Services, вы должны устанавливать консоль администратора на тот же физический сервер, что и Manager Server.
Self-Service Portal (портал самообслуживания)
Портал самообслуживания представляет собой Web-приложение для самостоятельного развертывания виртуальных машин пользователями. Администратор определяет политики самообслуживания, которые включают в себя правила создания, развертывания и использования виртуальных систем. Взаимодействие портала с управляющим сервером производится по модели сервисно-ориентированных систем WCF (Windows Communication Foundation).
Рекомендации по развертыванию
После установки SCVMM можно приступать к определению подходящих на роль серверов виртуализации компьютеров и, сделав это, можно начинать процесс миграции с физических систем на виртуальные. Необходимо убедиться, что в брандмауэре открыты необходимые порты для взаимодействия различных компонентов Virtual Machine Manager, и они не конфликтуют с портами, используемыми другими приложениями. Ниже представлена таблица используемых различными компонентами SCVMM портов:
Тип соединения
Протокол
Порт по умолчанию
Manager Server с управляемыми компьютерами (для исполнения действий)
WinRM
80
Manager Server с управляемыми компьютерами (для передачи данных)
BITS
443
Консоль администратора с Manager Server
WCF
8100
Портал самообслуживания с Manager Server
WCF
8100
Браузеры пользователей с порталом самообслуживания
HTTP
80
При планировании серверов для библиотек шаблонов нужно размещать их так, чтобы файлы, хранимые на них, передавались на серверы виртуализации с как можно более высокой скоростью. Если используются сети SAN, необходимо, чтобы хосты, использующие библиотеку, размещались на том же устройстве, что и сама библиотека. При развертывании виртуальных машин на серверах виртуализации, надо учитывать типовые и пиковые нагрузки на виртуальные системы, уделяя, в первую очередь, внимание показателю используемой приложениями в гостевых системах оперативной памяти, поскольку ее нехватка наихудшим образом сказывается на быстродействии.
К сожалению на данный момент, платформа Virtual Server не позволяет виртуальным машинам представлять несколько виртуальных процессоров в виртуальных машинах (Virtual SMP), поэтому нужно учитывать этот факт при их развертывании. Для приложений, нуждающихся в высокой доступности, возможно, имеет смысл иметь несколько виртуальных сетевых интерфейсов в виртуальной машине на случай отказа одного из них.
Портал самообслуживания может являться отличным средством при разработке и тестировании приложений для делегирования полномочий развертывания тестовых сред различным участникам группы разработки. Компания Microsoft рекомендует использовать протокол SSL (Secure Socket Layer) для защиты VMRC-соединения (Virtual Machine Remote Control) пользователей с порталом самообслуживания.
Интерфейс управления виртуальной инфраструктурой
Диспетчер управления виртуальной инфраструктурой Virtual Machine Manager ориентирован на организации различного масштаба и может управлять очень большим количеством виртуальных серверов (до нескольких тысяч) из единой консоли администратора. Мощный интерфейс управления из командной строки PowerShell позволяет системным администраторам управлять серверами виртуализации и виртуальными машинами из любой точки и с любого компьютера. Компания Microsoft предоставляет подробное руководство (Virtual Machine Manager Scripting Guide) по использованию PowerShell с SCVMM. Любое действие, производимое в консоли администратора, может быть автоматизировано с помощью сценария PowerShell.
Главное окно консоли администратора SCVMM напоминает собой окна консолей управления других продуктов семейства System Center, и, для уже знакомых с ними пользователей, освоение его интерфейса не представляет особых трудностей. Ниже представлены основные органы управления консоли администратора Virtual Machine Manager.
Группы хост-узлов
Управляемые хосты могут быть объединены в группы, которые могут быть организованы по некоторым логическим категориям (например, «Тестовые машины», «Веб-порталы» и т.п.). Довольно удобно также организовывать группы хостов в соответствии со структурой Active Directory. Естественно, SCVMM полностью поддерживает службу каталога Active Directory.
Использование групп хостов позволяет упростить управление виртуальными серверами и облегчить их мониторинг. Кроме того, группы хостов используются для назначения им определенных политик и свойств. Компания Microsoft рекомендует привязывать каждую группу хостов к одной библиотеке шаблонов, которую используют серверы этой группы. Для редактирования свойств группы нужно выбрать пункт «Host group properties» в группе действий «All Hosts». Для создания новой группы хостов используйте действие «New Host Group».
Представления виртуальных машин
Эта древовидная структура позволяет организовать представления виртуальных машин по требуемым параметрам: статусу (запущена, остановлена и т.п.), владельцу, гостевой операционной системе и прочим. В центральном окне отображается список виртуальных машин по заданному критерию с информацией об их физическом размещении, владельце и рабочей загрузке процессора.
Централизованная библиотека
Элемент управления «Library» позволяет оперировать с хранилищами виртуальных шаблонов. Интерфейс управления библиотеками очень гибок и позволяет удобно организовывать компоненты, хранящиеся в них, а также осуществлять поиск по ним. SCVMM позволяет создавать несколько серверов библиотек, а также поддерживает распределенную архитектуру серверов библиотек, которая очень удобна при развертывании виртуальных машин в географически разделенных филиалах. Для создания нового сервера библиотеки нажмите «Add library server» в группе действий «Virtual Machine Manager».
Контекстно-зависимые действия
Кроме того, из этой группы можно присоединиться к консоли виртуальной машины для операций в гостевой системе.
Активные эскизы
В этом элементе управления представлен снимок экрана гостевой системы для быстрой идентификации необходимого виртуального сервера. Слева от эскиза выводятся свойства виртуальной машины, включающие в себя информацию об ее статусе и используемых ресурсах. На вкладке «Latest job» отображена информация о последнем задании для виртуальной системы.
Заключение
Компании Microsoft удалось создать максимально гибкое и масштабируемое решение Virtual Machine Manager на базе платформы Virtual Server 2005 R2. По своим функциональным возможностям это средство управления виртуальной инфраструктурой занимает одно из первых мест среди подобных решений. Тем не менее, сама архитектура платформы виртуализации уже давно устарела, поскольку Virtual Server требует затрат на поддержание хостовой платформы, что значительно снижает производительность сервера виртуализации.
Большинство ведущих вендоров систем виртуализации, таких как VMware и Citrix (XenSource), ориентируются сейчас на «bare-metal» платформы, устанавливаемые на «голое железо» и имеющие оптимизированную под нужды виртуализации среду, обладающую более высоким быстродействием. Также начинают набирать обороты легковесные внедренные гипервизоры, которые будут в скором времени поставляться вместе с серверами для запуска виртуализации «под ключ».
Virtual Server же не поддерживает виртуального SMP, что отрицательно сказывается на производительности, и теряет на поддержке хостовой платформы. Все эти недостатки, как ожидается, будут ликвидированы во встроенной платформе виртуализации Hyper-V на базе Windows Server 2008. К этому времени Virtual Machine Manager будет позволять управлять гибридной виртуальной инфраструктурой на базе обеих платформ. На сегодняшний день не понятно, готовы ли организации различного масштаба примириться с недостатками Virtual Server и внедрять виртуализацию на его основе, особенно для критически важных серверов в производственной среде, предъявляющих высокие требования к быстродействию.
Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.