Зараз в Україні йде серія регіональних семінарів TechNet , На яких, крім усього іншого демонструються можливості віртуалізації Hyper-V і управління нею за допомогою System Center Virtual Machine Manager 2008 . Але не дивлячись на це, помічаю по вступникам з блогу на e-mail (хто не в курсі - є така фіча тут) і взагалі актуальні питання, що роль віртуалізації в сучасних ІТ в розумінні людей залишається десь на рівні 5летней давності .. . Коли народ запускав невеликі віртуальні машинки «на потестировать» в якихось особистих інтересах і про якесь серйозне застосуванні цих віртуальних машин мови і не йшло.

Але, по-перше, в даний момент віртуалізується , Тобто «Відривається» від фізичної реалізації, все - мережі (VPN), сховища (SAN, iSCSI, Mesh , VHD etc), ОС на серверах і клієнтах, додатки всередині цих ОС, відображення інтерфейсів і даних додатків. А по-друге, за ці 5 років серверна віртуалізація (саме її найчастіше мають на увазі, коли говорять про віртуалізації) зробила серйозний ривок вперед, з'явилися не просто рішення, що займаються емуляцією команд ЦПУ, пам'яті, мережевих і дискових запитів, а серйозні Гіпервізор, що працюють поверх апаратних можливостей, подібні Hyper-V , Що дозволяють «нарізати» і ізолювати один від одного «залізні» ресурси, досягаючи при цьому зростання продуктивності і ущільнення використання апаратних ресурсів.

Тепер віртуальна машина, якщо бути точніше - ОС, яка працює у віртуальному апаратному оточенні - нічим не гірше ОС, що виконується на фізичному хості-сервері, c прямsм зверненні до «заліза», без шару гипервизора. А в деяких моментах - віртуальна ОС навіть краще. Наприклад, завдяки головному принципу віртуалізації - відв'язку від фізичної реалізації в даному випадку «заліза», що реалізовується технологією Hyper-V - ми маємо можливість абсолютно «безкарно» міняти місце-фізичний сервер виконання віртуальної ОС, збільшувати або зменшувати її потреби в апаратних ресурсах, групувати кілька екземплярів віртуальних ОС на одному фізичному сервері, і, що дуже важливо, завдяки однакової «віртуально» середовищі - дуже легко і просто розгортати нові екземпляри ОС з нуля або з використанням шаблону.

Саме про це йде зараз мова, коли говорять про віртуалізації - нема про можливості запустити «ще одну систему», а про можливості завдяки уніфікації вирішити масу проблем з управлінням апаратними та програмними ресурсами, перетворивши сервера, які виконують окремо якийсь серверний продукт в групу серверів, центр обробки даних, які надають організації набір сервісів з гарантованою доступністю і продуктивністю. Управлятися такий центр буде куди легше і простіше. І це як раз завдання System Center Virtual Machine Manager 2008, короткий огляд по можливостям якого «в картинках» я б хотів зробити в цьому пості.

Отже, завдання System Center Virtual Machine Manager 2008 (далі для стислості VMM):

1. Зміна парадигми управління серверами і апаратними ресурсами. Завдяки бібліотеки образів VHD-, ISO-дисків, шаблонів конфігурацій, налаштувань гостьових ОС адміністратори можуть швидко (протягом 15-20 хвилин для локальної мережі) і без безпосереднього втручання розгорнути віртуальну ОС з необхідною конфігурацією. При цьому вибір фізичного сервера, на якому буде виконуватися нова віртуальна ОС, визначається вбудованої в VMM технологією Intelligent Placement (IP), що враховує поточну навантаження на сервер, вимоги майбутньої віртуальної машини, необхідні запаси «міцності» для функціонування фізичної машини і вагові коефіцієнти таких компонентів системи, як процесор, пам'ять, диск, мережа.

Крім того, розгортання може проводитися на віддалені сервера і по повільних каналах зв'язку, що забезпечується механізмом «точок відкату» в VMM при виконанні завдання, яка ділиться на окремі дії і використання технології BITS для передачі того ж образу VHD майбутньої віртуальної ОС по мережі.

Самі шаблони і образи в бібліотеці можу створюватися з уже існуючих віртуальних ОС шляхом виконання в них команди sysprep, копіювання отриманого образу в бібліотеку, і додавання до нього шаблону апаратних параметрів для нової віртуальної машини і налаштувань ОС типу продуктового ключа, імені машини, пароля адміністратора, параметрів додавання в домен для конфігурації конкретного екземпляра ОС, яка буде створена з раніше підготовленого sysprep образу. Створювана з такого шаблону віртуальна ОС автоматично конфігурується і настроюється на місці без адміністратора. Для більш тонкої настройки поведнія ОС в режимі sysprep можна використовувати стандартні утиліти з комплекту AIK або MDT.

У бібліотеках також можуть тимчасово зберігатися і робочі екземпляри віртуальні ОС (у вимкненому стані), вони не є в такому випадку шаблонами, бібліотека використовується як сховище при нестачі дискового простору для даної віртуальної ОС або як проміжний пункт зберігання при передачі віртуальної ОС з одного віддаленого сервера на іншій.

Також можливо делегування різних прав на виконання тих чи інших адміністративних дій з управління VMM і керованими їм віртуальними машинами користувачам, наприклад, по групах фізичних хостів. Такі адміністратори зможуть створювати віртуальні машини, конфігурувати параметри фізичних хостів і т.п. тільки в рамках відведеної їм групи. Ця функціональність поширюється не тільки на створення «локальних» адміністраторів, а й на надання можливості створення віртуальних ОС користувачам через спеціальний веб-інтерфейс. Можливе надання користувачам права створювати певну кількість віртуальних ОС (підтримується квотування як на рівні користувача, так і на рівні групи) з певного шаблону (різні шаблони можуть мати різну вагу для квоти).

При цьому, якщо в шаблоні визначені установки майбутньої ОС, то користувач отримає вже сконфігурованих, доданий в домен екземпляр віртуальної ОС, зможе користуватися його ресурсами і навіть бути його локальним адміністратором (також конфігурується при делегуванні). Місце розташування створюваної віртуальної ОС користувач визначити не може, на відміну від адміністратора, для якого вибір найбільш підходящого хоста пропонується, VMM завдяки технології Intelligent Placement самостійно визначає найбільш підходящий для конкретної конфігурації фізичний хост і розміщує віртуальну ОС там.

Користувачі можуть керувати створення екземпляра через веб-інтерфейс, підключатися до них через консоль (забезпечує засобами Hyper-V) або, як це можливо і в звичайних системах, через віддалений робочий стіл, якщо він включений в даній конфігурації ОС. Також користувачам може бути надано доступ до бібліотек в режимі запису, тобто вони зможуть не тільки створювати нові екземпляри віртуальних ОС з шаблонів в бібліотеці, а й зберігати свої віртуальні ОС в разі, наприклад, брак квоти, або при необхідності звільнення ресурсів для інших примірників.

До управління серверами можна також віднести цікаву можливість VMM з конвертування ОС, що виконується на фізичному сервері, в віртуальну ОС (P2V). При цьому система продовжує функціонувати, поки з неї знімається її віртуальна копія і поміщається на один з серверів. Адміністратору за допомогою майстра досить тільки погодитися з майбутньою апаратної конфігурацією для віртуальної ОС (за замовчуванням береться така ж, як і на фізичній машині), вказати, дані з яких саме розділів копійованого фізичного сервера необхідно смігріровать, який саме сервер для запуску віртуальної копії буде використовуватися (визначається за допомогою все тієї ж технології інтелектуального розміщення IP), і «прив'язати» мережеві інтерфейси в майбутньої віртуальної ОС до мережних інтерфейсів, доступним на розміщує сервер е. Далі система все це зробить сама. На питання «Як це робиться без зупину копируемой машини?» Наведу простий факт - резервне копіювання Windows Server 2008 виконується в файл VHD формату, а решта, думаю, додумаєте самі ... :)

2. VMM забезпечує оптимізацію ресурсів і продуктивності як фізичних хостів, так і додатків, що виконуються у віртуальних ОС. Для цього використовуються можливості Management Packs (MP) від System Center Operations Manager 2008 (SCOM) і засоби взаємодії між VMM і SCOM. Дана технологія проходить в VMM як Performance and Resource Optimization (PRO) tips. Фактично, SCOM контролює фізичні сервера, віртуальні ОС і додатки в них, і, використовуючи інформацію зі спеціальних MP, передає команди у вигляді пропозицій для адміністратора або у вигляді обов'язкових відразу до виконання для самого VMM. За замовчуванням мається MP тільки з простим сценарієм - не вистачає ресурсів фізичного сервера - команда для VMM перенести частину віртуальних машин на інші фізичні сервера (які визначаються все тим же всюдисущим IP). Фактично, PRO - це і є механізм забезпечення того, на що спрямована віртуалізація - гарантованої SLA доступності сервісів, що надаються датацентом з максимальною утилізацією всіх доступних ресурсів. Крім того, SCOM дозволяє адміністраторам візуально оцінити працездатність всіх компонент віртуального датацентру за допомогою діаграми.

3. І, нарешті, перенесення віртуальних ОС між фізичними серверами. Чому останнім, а не першим? Та тому що перенесення ОС - всього лише інструмент вирішення описаних вище завдань, а не самоціль. Перенесення може виконуватися адміністратором, може бути автоматичним завдяки PRO - але в будь-якому випадку, кінцева мета такої дії - забезпечення більшої доступності та продуктивності сервісу, компонентом якого є переноситься віртуальна ОС.

VMM підтримує кілька типів перенесення віртуальних ОС між фізичними серверами, на яких вони виконуються:

Доступний в середовищі Hyper-V з використанням кластеризації Quick Migration, який забезпечує високу доступність примірника віртуальної ОС, оскільки така ОС виконується в рамках вузлів кластера, і перенесення відбувається шляхом збереження стану віртуальної ОС на одному вузлі на загальний диск кластера (SAN) і відновлення цього стану на другому вузлі. Зауважте, оскільки ми маємо справу з однією фізичною диском, на розділі якого знаходиться VHD-файл віртуальної ОС, і з'єднання з яким просто «передається» від сервера до сервера. Час недоступності ресурсів віртуальної ОС при такому перенесенні дорівнюватиме часу запису стану + час читання стану + накладні витрати кластера на монтування диска і запуск процесів на новому вузлі і зазвичай не перевищує 20-30 секунд в залежності від обсягу ОЗУ віртуальної ОС. Про реалізацію кластерної міграції без VMM, тільки засобами Windows Server 2008 / Hyper-V і iSCSI, я вже писав раніше .

SAN Migration, при якому VMM бере на себе завдання з управління LUN вашої SAN-середовища (FiberChannel, iSCSI, InfiniBand). LUN представляє для кінцевого сервера окремий розділ диска на загальному мережевому сховище, до якого за допомогою тієї чи іншої технології підключений сервер. LUN'и монтуються, як розділи на фізичних серверах (простіше кажучи - сервер їх вважає своїми «локальними» фізичними дисками), і в таких розділах зберігаються необхідні VHD-файли, що представляють диски віртуальних ОС. VMM підтримує роботу з однієї віртуальної ОС для одного LUN. При SAN Migration, на вихідному фізичному сервері VMM зберігає стан віртуальної ОС той же LUN ​​SAN-сховища, де знаходяться і її VHD-диски і після повністю відключає LUN від сервера-джерела і підключає LUN до сервера, на якому далі буде виконуватися віртуальна ОС при допомоги відповідних команд SAN. На сервері-одержувачі після підключення LUN монтується розділ, з нього зчитується стан віртуальної ОС і вона запускається.

Фактично, це той же процес, що і з Quick Migration, але відрізняється тим, що загальні диски кластера - це один і той же LUN, але доступний одночасно багатьом вузлам кластера, а в SAN Migration LUN передається від одного фізичного сервера іншому в одноосібне управління . Крім того, на відміну від вузлів кластера, при SAN-перенесення сервера можуть мати різні конфігурації і це вимагає модернізації конфігурації. Це займає деякий час (залежне від реалізації SAN), тому швидкість SAN-перенесення становить близько 1,5-2 хвилини. Такий режим дозволяє ефективно управляти LUN корпоративної SAN, оскільки за перенесення відповідає VMM і, переносячи LUN разом з розміщеною там віртуальної ОС, фактично, знімає з адміністратора питання по прямому управлінню SAN.

І Network Migration, при якому стан і сам VHD-файл копіюються між серверами по мережі. Оскільки VHD-файли можуть мати розміри десятків і сотень гігабайт, то швидкість такого перенесення буде дорівнює швидкості копіювання даних по мережі з урахуванням використання BITS. В такому випадку в роботі системи можуть брати участь різні сервера, які не мають дорогого SAN і загального сховища або є географічно розподіленими.

VMM автоматично визначає режим можливого перенесення віртуальної ОС між поточним сервером і цей аспект також є критерієм для роботи IP. Адміністратору тільки залишається визначити, який режим перенесення для нього найбільш прийнятний. Також IP дає рекомендації та інформацію про те, чому саме такий режі був обраний і що, наприклад, перешкоджає виконанню SAN Migration. До речі, дуже часто це можуть бути смотрірованние в віртуальну ОС як DVD iso-образи, що знаходяться на локальних дисках (нема на LUN) сервера і інші локальні ресурси сервера, доступні в віртуальної ОС. Тоді така ОС буде мігрувати c допомогою Network-перенесення навіть на явно вказаний LUN сервера-одержувача, і при такому перенесенні будуть копіюватися по мережі не тільки стан і VHD-файли, але і ті файли, які були змонтовані в ОС.

Власне, ось такі ось основні завдання реашает і такі можливості має поточна версія System Center Virtual Machine Manager 2008. Його застосування дозволяє організаціям ефективно управляти апаратними ресурсами для максимального виконання завдань організації та гарантувати високу доступність сервісів при загальному зниженні навантаження на системних адміністраторів, що відповідають за супровід серверів.

Ви можете підписатися на наш Telegram-канал для отримання найбільш цікавої інформації