• Главная
  • Карта сайта
Не найдено

ITband.ru »Повністю віртуальна інфраструктура на Hyper-V

  1. Проблема №2.

У цій невеликій статті хотілося б розповісти про свій досвід використання віртуалізації інфраструктури на базі Hyper-V зі складу Windows Server 2008 R2 У цій невеликій статті хотілося б розповісти про свій досвід використання віртуалізації інфраструктури на базі Hyper-V зі складу Windows Server 2008 R2. Стаття буде також може бути застосована і до Windows Server 2008 (R1). А якщо конкретно, то хотілося б розповісти про проблему повної віртуалізації інфраструктури. Під повною віртуальної інфраструктурою я маю на увазі середу, де Hyper-V розгорнуто в конфігурації Failover Cluster і всі сервери, включаючи контролери доменів, віртуалізується.

Щоб було зрозуміліше, розглянемо наступну інфраструктуру. Є група хостів з Windows Server 2008 R2. Ви з цих хостів зібрали кластер і хочете перенести всю вашу серверну інфраструктуру з фізичного стану в віртуальне. Але постає дилема. Серед фізичних серверів, які ви хочете перенести в середу віртуалізації, є контролери доменів. Тут ви згадуєте, що кластер залежить від служби каталогів і виходить, що вам не можна створювати взаємозалежність: кластер віртуалізації від служби каталогів і навпаки.

Взагалі дана проблема не нова. Але я жодного разу не зустрічав опис вирішення даної проблеми, тому все-таки надумав поділитися своїм досвідом. Можливо дане рішення вже десь описано і просто-напросто я не правильно або неуважно шукав.

Рішення.

Failover-кластеру без служби каталогів дуже погано. Хоча б з тієї причини, що служба каталогів використовується для аутентифікації вузлів в кластері.

Повернемося до нашої інфраструктурі. Ми все-таки розгорнули кластер Hyper-V, перенесли всі сервери, в тому числі і контролери доменів, у віртуальне середовище. Фізичні сервери або задіяли як вузли кластера, або повністю вивели з експлуатації. Віртуальні машини розмістили на Cluster Shared Volume (CSV), щоб задіяти чудову функцію Live Migration.

Вийшло таке:

В один прекрасний момент вимикається електрика, а разом з ним через деякий час вимикаються ваші фізичні хости і віртуальні машини.

Включають електрику, хости Hyper-V починають грузиться, а ось віртуальні машини не стартують. Це відбувається з наступних причин. Віртуальні машини є ресурсами кластера, служба ClusterSvc повинна, відповідно до залежністю ресурсів, по черзі їх підняти (перевести в online-режим). Але служба кластерів сама залежить від служби каталогів, контролери доменів якої є ресурсами кластера. Виходить замкнуте коло.

Є традиційні способи вирішення даної проблеми:

Використовувати хоча б один фізичний сервер для контролерів доменів. Погодьтеся, що при поточній продуктивності серверів, не зовсім доцільно витратити на контролер доменів 5-10 тис. Доларів (з подальшою утилізацією раз в 3-5 років). Для інфраструктур, що характеризують себе як централізовані і середні за розмірами, хотілося б максимально утилізувати обчислювальні ресурси, абстрагуватися від апаратного забезпечення, і все це зробити з мінімальними витратами. Децентралізовані інфраструктури можуть такої проблеми не відчувати.

Використовувати хост Hyper-V як контролер доменів. Тобто, розгортаємо роль ADDS на одному з вузлів Hyper-V. Це вже краще, ніж перший випадок, але все ж є деякі проблеми:

Проблема безпеки і проблема делегування повноважень. Якщо розгорнути RWDC на Hyper-V хості, то важко буде обмежити адміністратора середовища віртуалізації від можливості впливати на службу каталогів. Відразу скажу, що тут можна довго сперечатися на цю тему, оскільки можна сказати, що якщо є фізичний доступ до хосту, то без проблем можна отримати доступ до віртуальних машин. І це вірно. Тому залишу тему безпеки за рамками цієї статті. Візьмемо за віру, що проблема з безпекою все ж є в цьому випадку. Також можна встановити RODC і це вирішить деякі проблеми з безпекою, але виникають інші проблеми. Update: трохи пізніше накопав, що RODC не підтримує на вузлах кластера. http://support.microsoft.com/kb/281662/en-us

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

Проблема з ліцензуванням. Звичайно, з ліцензуванням проблем тут немає, але ось у вас проблеми з'являться. Якщо хост Hyper-V виконує будь-яку роль крім віртуалізації, то ви втрачаєте можливості в повній мірі покрити хостовой ліцензією запущені екземпляри віртуальних машин. Наприклад, у випадку з Standard-ліцензією взагалі втрачаєте можливості використовувати хостовую ліцензію для ліцензування однієї запущеної віртуальної машини, а у випадку з Enterprise - однієї. Тобто з Enterprise-ліцензією можете ліцензувати запуск не 4х віртуальних машин, а тільки трьох.

В оригіналі це звучить так:

* Якщо працює максимальна кількість примірників, екземпляр у фізичному операційному середовищі можна використовувати лише для запуску програмного забезпечення віртуалізації пристроїв, забезпечення служб віртуалізації пристроїв або для запуску програмного забезпечення для керування операційними середовищами і їх обслуговування на ліцензованому сервері.

А тепер, як я вирішував цю проблему.

Якщо є взаємозалежність кластера від служби каталогів і служби каталогів від кластера, то потрібно цю залежність прибрати. Ви просто не робите віртуальні машини (з контролерами доменів) ресурсами кластера. А якщо зробили це раніше, то видаляєте відповідні ресурси з кластера і, при необхідності, переносите файли віртуальних машин на локальні диски сервера.

Тим самим ви вирішуєте проблему взаємозалежності. Тепер контролери доменів живуть у віртуальних машинах і ці віртуальні машини не є ресурсами кластера. При відключенні електрики все прекрасно стартує.

Правда в цьому випадку ми прив'язуємо контролер домену до конкретного хосту і він (контролер домена) не може бути переміщений на інший хост за допомогою Quick Migration або Live Migration (хоча може бути переміщений іншими способами). Але це не біда. Висока доступність контролерів доменів досягається зовсім іншим способом - надмірністю. На необхідну кількість контролерів доменів можуть вплинути багато факторів, тут ми їх обговорювати не будемо.

Деякі рекомендації (і навіть вимоги):

  1. Створюйте віртуальні машини з контролерами доменів на дисках, які не є кластерними ресурсами. Це можуть бути як локальні диски (DAS), так і диски з СГД.
  2. Режим запуску віртуальних машин: Always Automatically Turn On The Virtual Machine або Automatically Turn On The Virtual Machine If It Was Running When The Physical Server Was Stopped
  3. Для служби кластерів (ClusterSvc) необхідно провести налаштування відновлення. Ті, що на вкладці «Відновлення» властивостей служби ClusterSvc оснащення Services.msc. Для всіх збоїв необхідно вказати перезапуск служби. Не можу сказати які саме значення для «Перезапуск служб через:» вам підійдуть, необхідно підбирати їх індивідуально. Я використовував 3 хвилини.
  4. Скоротіть інтервал відображення меню відновлення. Налаштувати можна за допомогою аплету «Система» панелі управленія.На насправді я злукавив, коли трохи вище сказав, що все прекрасно стартує. Не зовсім. Може виникнути додаткова проблема.

Проблема №2.

Справа в тому, що є ще одна взаємозалежність: служба каталогів від DNS і DNS від служби каталогів.

Виникає вона з наступних причин. Контролер домену, при старті, намагається справити реплікацію своїх контекстів іменування (це за умови, що контролер в лісі не один): поки не зробить реплікацію, не виконуватиме свої функції. Служба DNS, бажаючи при старті працювати з найактуальнішими даними, відкладає завантаження інтегрованих в AD зон, до моменту, коли служба каталогів реплицирует дані і сповістить про це службу DNS. Реплікація AD, як відомо, залежить від DNS: контролер домену намагається отримати IP-адреси своїх партнерів по реплікації за допомогою DNS. А DNS в цей час не працює, оскільки чекає AD. AD чекає DNS, DNS чекає AD. У свою чергу від DNS також залежить кластер і аутентифікація. Через якийсь час служба каталогів все-таки дасть добро службі DNS і та завантажить зони. Цей timeout залежить від кількості розділів, які обслуговує контролер доменів і приблизно становить 20 хвилин для 5 розділів (для контролерів з 2008 R2 я спостерігав набагато меншу затримку - 5 хвилин).

20 хвилин для кого-то можуть бути цілком припустимі, а для кого-то немає. Спробуємо вирішити цю проблему.

способи:

  1. Використовувати в якості DNS сервера сервер з іншого майданчика. Швидше за все, в цьому випадку у вас не повинно виникнути і першої проблеми.
  2. Встановити додатковий фізичний сервер з роллю DNS. Цей сервер буде обслуговувати вторинну зону для _msdcs кореневого домена і доменну зону локального домену (головне завдання вирішити DSAGUID партнера по реплікації в FQDN і FQDN в IP-адреса) Цей спосіб звичайно не підходить. Ми повернулися знову до проблеми з фізичним сервером. У цьому випадку простіше відразу розгорнути фізичний контролер доменів.
  3. Встановити роль DNS на хості Hyper-V? Можна, але отримуємо ті ж проблеми, що і обговорювалися трохи вище.
  4. Відключити початкову реплікацію. Це робиться установкою значення Repl Perform Initial Synchronizations в 0 для ключа:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ Parameters. Можна, але не рекомендується. Не рекомендується хоча б з тієї причини, що таким чином відбувається спроба вирішити проблему з існуванням в лісі (або домені) кількох FSMO. Краще такий спосіб не використовувати.

Використовувати не інтегровані в AD зони (повністю або частково). Знаєте так, які переваги дає зберігання зон в AD? Якщо вам ці переваги не потрібні, то можете використовувати і цей спосіб.

Зробити так, щоб ім'я партнера по реплікації дозволялося без участі DNS-сервера. Як це можна зробити? Способів багато. Додатково варто сказати, що, починаючи з Windows Server 2003 SP1, з'явилася функція name resolution fallback, на той випадок якщо не вдасться вирішити DSAGUID контролера домену. Ланцюжок наступна: GUID -> FQDN -> NETBIOS-ім'я. Тобто, якщо не вдається вирішити CNAME GUID, то відбувається спроба дозволити FQDN, якщо і це не вдається зробити, то відбувається спроба отримати IP по NETBIOS-імені.

Тому проблему можна вирішити:

  • Використанням HOSTS-файлу. В хост файл можна внести запис про партнера по реплікації. Можна додати як GUID._msdcs. <Імя_корневого_домена>, так і FQDN:

<IP-адреса партнера по реплікації> <DSA GUID> ._ mcdcs. <Ім'я кореневого домену>
<IP-адреса партнера по реплікації> <FQDN партнера по реплікації>

  • Використанням файлу LMHOST. Внести в файл відповідний запис NETBIOS.
  • Використанням WINS-сервера. Напевно, найкращий спосіб.
  • Використанням NETBIOS-широкомовлення для дозволу імені. Якщо контролери доменів в одному широкомовному домені і Netbios-over-TCPIP не натиснута кнопка вимкнення (включений за замовчуванням), то з проблемою №2 ви взагалі не повинні зіткнутися.

Вносячи записи в файли HOSTS і LMHOSTS, необхідно віддавати собі звіт в тому, що такі зміни незабаром вами забудуться, і, при виникненні проблем з дозволом імен, ви витратите додатковий час на пошук причини. Тому ретельно документуйте вносяться зміни. Те ж саме стосується локального зміни реєстру: краще робити зміни централізовано, наприклад, з використанням групових політик, а інакше решт не знайдете.

Сподіваюся, що представлені в цій статті рекомендації, допоможуть вам.

Як встановити Hyper-V кластер: http://lmgtfy.com/?q=how+to+install+hyper-v+cluster

Про первісної реплікації: http://support.microsoft.com/kb/305476/en-us

Про проблему завантаження DNS-зон: http://support.microsoft.com/kb/2001093/en-us

LMHOSTS: http://support.microsoft.com/kb/101927/en-us

Єфімов Геннадій, MCP

Встановити роль DNS на хості Hyper-V?
Знаєте так, які переваги дає зберігання зон в AD?
Як це можна зробити?
Com/?
Новости
Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью