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

Windows Server 2012: DHCP Failover | Булдаков.ru | записки сисадміна

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

  • Будь авторизований комп'ютер, який підключається до мережі має можливість отримати ip-адреса і додаткові налаштування мережі від служби DHCP в будь-який момент часу
  • Після отримання ip-адреси, комп'ютер має можливість продовжити оренду ip-адреси і продовжити використовувати той же ip-адреса

Windows Server 2012 надає новий механізм забезпечення високої доступності для ролі DHCP. Два DHCP-сервера можуть бути налаштовані для забезпечення високої доступності сервісу DHCP через відмовостійкість (failover relationship) (за аналогією з ВІДМОВОСТІЙКО кластером). Відмовостійкість має кілька параметрів, які впливають на поведінку серверів DHCP в разі збою: режим відмовостійкої роботи, області (scopes), захищені відмовостійкої зв'язком. Останні повністю збігаються один з одним у разі налаштування відмовостійкості. Якщо відмовостійкість налаштована, то DHCP сервери реплікують інформацію про орендовані ip-адреси і дополнітульную інформацію про клієнтів між собою, і, таким чином, завжди містять актуальну інформацію про всіх клієнтів в мережі. Якщо один з DHCP серверів стає з якоїсь причини недоступний, то інші DHCP сервери будуть містити актуальну інформацію про клієнтів і зможуть обслуговувати їх запити.

Режим відмовостійкої роботи (Failover Operation). Існує два режими настройки відмовостійкості DHCP для різних топологій впровадження: балансування навантаження (Load Balance) і гаряче резервування (Hot Standby). Балансування навантаження використовується, коли всі налаштовані DHCP сервери обробляють клієнтські запити, при цьому відсоток оброблюваних запитів конкретним сервером налаштовується додатково (Active-Active конфігурація). Гаряче резервування відповідає Active-Passive конфігурації. Необхідно буде вказати, який DHCP сервер буде обробляти клієнтські запити, другий в цей час буде перебувати в резерві. Резервний сервер не займається обслуговуванням клієнтських запитів поки працює перший сервер. При цьому він отримує всі оновлення інформації про оренду адрес від працюючого сервера і зберігає її у своїй базі.

Відмовостійкі DHCP сервера можуть перебувати в різних подсетях і навіть в різних географічних регіонах.

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

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

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

Топологія "зірка" - інший тип топології з декількох сайтів, яка може бути легко налаштована в організації, яка планує впровадження отказоустойчивого DHCP сервісу. В цьому випадку DHCP сервер в центральному сайті буде зберігати копію налаштувань серверів у віддалених сайтах.

Старі механізми забезпечення високої доступності. До поточного моменту DHCP сервер міг забезпечити високу доступність через розміщення на відмов кластерів або через об'єднання областей. Обидва цих рішення мають свої недоліки.

Механізм об'єднання областей реалізується через настройку однакових областей на двох DHCP серверах і налаштуванням діапазонів виключення. 80% ip-адрес використовується першим сервером, 20% - другим. Другий сервер часто налаштовувався реагувати на запити клієнтів з невеликою затримкою. В результаті клієнти працювали в основному з першим сервером. Така конфігурація має дві проблеми. Підмережі часто використовують більше 80% доступних ip-адрес. У таких подсетях механізм об'єднання областей мало ефективний у зв'язку з недоліком вільних адрес в пулі. Друга проблема такої конфігурації пов'язана з неможливістю клієнтом використовувати старі настройки в разі виходу з ладу першого сервера. Так як ip-адреса, отриманий клієнтом від першого сервера, знаходиться в діапазоні виключення на другому сервері, то другий сервер буде змушений видати клієнту нову адресу. Можливості продовжити оренду старого адреси не буде. У разі використання механізму об'єднання областей два DHCP серверу не будуть синхронізувати інформацію про видані адресах.

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

Маханізм відмовостійкості DHCP усуває недоліки обох рішень і значно спрощує процес розгортання. Крім цього він підтримується у всіх версіях Windows Server 2012, що дозволяє побудувати недороге поломок рішення для сервісу DHCP.

Як працює режим балансування навантаження. Кожен DHCP сервер при отриманні запиту клієнта обчислює хеш MAC-адреси клієнта, використовуючи алгоритм хешування, описаний в RFC3074 . Кожен сервер отримує значення хеша в діапазоні від 1 до 256. Якщо розподіл навантаження між вузлами виставлено в 50:50, то клієнтський запит, содержаший MAC-адресу хеш якого буде в інтервалі від 1 до 128 буде оброблений першим сервером, якщо хеш буде в інтервалі від 129 до 256, то запит буде оброблятися другим сервером. Це дає гарантію, що на запит клієнта відповість тільки один сервер. Якщо розподіл навантаження буде іншим, розподіл значень хеш між серверами зміниться пропорційно. Таким чином, адміністратор не бере участі в налаштуванні розподілу MAC-адрес між серверами.

Обробка ip-адрес при використанні режиму балансування навантаження. Вільні ip-адреси в кожній відмовостійкої області будуть поширюватися в тій же пропорції що і балансування навантаження. Наприклад, у нас є відмовостійка область 10.10.10.0/24 з діапазоном доступних адрес 10.10.10.1 - 10.10.10.250. Припустимо, що адреси з .10.10.1 по 10.10.10.50 видані в оренду, а починаючи з 10.10.10.51 вільні. У цій ситуації адреси з 10.10.10.51 по 10.10.10.150 будуть використовуватися першим сервером, а з 10.10.10.151 по 10.10.10.250 другим, відповідаючи таким чином розподілу навантаження 50:50. Таким чином, клієнт з MAC-адресою, хеш якого буде в діапазоні, закріпленому за першим сервером, отримає ip-адреса починаючи з 10.10.10.51.

Як видно з цього прикладу, коли налаштована відмовостійкість для області, два сервера видаватимуть ip-адреси з різних частин доступного діапазону адрес, на відміну від ситуації з одним сервером, який буде використовувати весь доступний діапазон ip-адрес.

Коли клієнти запитують адреси, вільні адреси з пулу одного сервера можуть закінчуватися швидше ніж вільні адреси з пулу другого сервера. Щоб гарантувати відповідність пропорції доступних ip-адрес, основний (primary) сервер кожні п'ять хвилин перевіряє розподіл вільних ip-адрес між двома серверами і займається перерозподілом доступних ip-адрес між серверами. Це називається періодичної перебалансировке пулу вільних ip-адрес.

Кількість вільних ip-адрес на кожному сервері відмовостійкої області можна подивитися через статистику області. Поля Addresses Available (this Server's Pool) і Addresses Available (Partner Pool) показують кількість вільних ip-адрес доступних відповідного серверу. Вікно статистики можна відкрити з контекстного меню області, вибравши Display Statistics, або використовуючи командлет Get-DhcpServerv4ScopeStatistics з ключем -failover. У статистиці доступні два додаткових поля - Addresses granted (this Server's Pool) і Addresses granted (Partner Pool), що вказують кількість зарезервованих адрес.

У статистиці доступні два додаткових поля - Addresses granted (this Server's Pool) і Addresses granted (Partner Pool), що вказують кількість зарезервованих адрес

Поведінка балансування навантаження в разі збою. Коли відмовостійка конфігурація області знаходиться в робочому стані, алгоритм хешування спрацьовує для кожного клієнтського запиту. У разі переривання зв'язку між серверами алгоритм хешування перестає використовуватися для обслуговування запитів клієнтів. Сервер починає відповідати всім клієнтам, працюючи в звичайному режимі, забезпечуючи, таким чином, доступність сервісу.

Коли відмовостійка конфігурація області знаходиться в робочому стані, сервер так само може обслуговувати повторні запити клієнта, які повинен (на підставі алгоритму хешування) обробляти другий сервер. Сервер визначає, що це повторний запит на підставі поля sec в DHCP-запиті клієнта. згідно RFC2131 поле sec показує кількість секунд минули з того моменту, як клієнт надіслав запит на отримання ip-адреси або на продовження оренди. Якщо sec більше шести секунд, то DHCP сервер відповість клієнтові, навіть якщо хеш MAC-адреси клієнта не входить в діапазон обслуговуються сервером хеш. Ідея цього підходу полягає в тому, що потрібно відповідати на запити клієнтів навіть в тому випадку, якщо сервер, який повинен відповісти на запит клієнта не доступний, і при цьому будь-яких помилок в роботі відмовостійкої конфігурації області не показується (це може бути пов'язано з затримкою в 30 секунд, яка виникає перш ніж перший сервер виявляє, що другий сервер недоступний).

Maximum Client Lead Time (MCLT). Протокол відмовостійкості DHCP містить параметр Maximum Client Lead Time (MCLT), який задає тимчасовий період оренди ip-адреси для нового клієнта. Цей параметр так само визначає час, протягом якого DHCP сервер, що працює в режимі відмовостійкості, чекатиме відновлення каналу зв'язку з партнером. Після цього, якщо партнер буде перебувати в неробочому стані, управління розподілом ip-адрес перейде повністю під контроль першого сервера. MCLT не може дорівнювати нулю, і за замовчуванням становить одну годину.

Відсоток зарезервованих адрес. При налаштуванні відмовостійкості DHCP в режимі гарячого резервування адміністратор може вказати відсоток діапазону адрес в області для резервного сервера. Кількість адрес, відповідне вказаною відсотку буде закріплено за резервним сервером. Резервний сервер буде їх використовувати для обслуговування запитів клієнтів в разі, якщо основний сервер стане недоступний і до того моменту, коли контроль над усім діапазоном перейде резервному сервера. Резервний сервер візьме контроль над діапазоном адрес області тільки після того, як основний сервер буде недоступний протягом інтервалу часу зазначеного в MCLT. Якщо адміністратор встановить цей параметр в нуль, то резервний сервер не зможе обслуговувати запити клієнтів, поки не отримає контроль над усім діапазоном адрес. За замовчуванням відсоток зарезервованих адрес - 5%.

Інтервал автоматичного перемикання. Сервер, який втрачає канал зв'язку з партнером переходить в режим перерваного зв'язку. Втрата зв'язку може бути пов'язана з проблемами в мережі або з виключенням сервера-партнера. Так як сервер не має можливості виявити причину втрати зв'язку, то він буде перебувати в режимі перерваного зв'язку до тих пір, поки адміністратор вручну не встановиться, що сервер-партнер не працює. Крім цього, є можливість автоматично вказати, що партнер не працює, яка заснована на тимчасовому інтервалі. Цей настроюється параметр називається інтервалом автоматичного перемикання. За замовчуванням становить 10 хвилин.

Аутентифікація повідомлень протоколу відмовостійкості DHCP. Windows Server 2012 для аутентифікації повідомлень протоколу відмовостійкості DHCP реалізує криптографічний стандарт SHA-2. За замовчуванням використовується SHA-256. Для настройки аутентифікації повідомлень майстер настройки відмовостійкості DHCP запропонує ввести загальний секрет. У продовженні процесу настройки відмовостійкості майстер поширить загальний секрет на кожен сервер, який буде працювати в режимі відмовостійкості.

Вихідні матеріали:
Ensuring High Availability of DHCP using Windows Server 2012 DHCP Failover
DHCP Failover Load Balance Mode
Understand and Troubleshoot DHCP Failover in Windows Server "8" Beta

Провайдеры:
  • 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 Гбит / сек... 
    Читать полностью