Відмовостійкі DHCP сервера можуть перебувати в різних подсетях і навіть в різних географічних регіонах.
Топології впровадження. Використання двох режимів роботи відмовостійких DHCP серверів дозволяє охопити величезну кількість топологій впровадження. Найпростіша з них, коли два сервера в режимі балансування навантаження або гарячого резервування обслуговують набір підмереж, що знаходяться в одному сайті.
Складніша топологія впровадження відмовостійких DHCP серверів в різних сайтах показана нижче. Сайти Hyderabad і Redmond мають локальні DHCP сервери, які обслуговують клієнтські запити в своєму сайті. Для забезпечення високої доступності сервісу DHCP можна налаштувати відмовостійкість DHCP в режимі гарячого резервування. Одна відмовостійка конфігурація буде містити всі мережі та області в сайті Hyderabad. Локальний DHCP сервер буде виступати в якості активного сервера, сервер в сайті Redmond буде знаходитися в резерві. Друга відмовостійка конфігурація буде містити всі мережі та області в сайті Redmond. Локальний DHCP сервер буде виступати в якості активного сервера, сервер в сайті Hyderabad буде знаходитися в резерві.
Ця конструкція з двох DHCP серверів, що резервують один одного через два набори відмовостійких конфігурацій, може бути поширена на більшу кількість сайтів. Можна використовувати кільцеву топологію з декількох сайтів, де сервер в кожному сайті, будучи активним сервером для свого сайту, буде так само зберігати копію налаштувань сервера з іншого сайту.
Топологія "зірка" - інший тип топології з декількох сайтів, яка може бути легко налаштована в організації, яка планує впровадження отказоустойчивого DHCP сервісу. В цьому випадку DHCP сервер в центральному сайті буде зберігати копію налаштувань серверів у віддалених сайтах.
Старі механізми забезпечення високої доступності. До поточного моменту DHCP сервер міг забезпечити високу доступність через розміщення на відмов кластерів або через об'єднання областей. Обидва цих рішення мають свої недоліки.
При використанні відмов кластеру база даних сервера DHCP повинна знаходитися в сховище, доступному обом вузлів кластера. DHCP сервери, запущені на кожному вузлі кластера працюють з однією базою даних, яка перебуває в загальному сховищі. Так як в такому випадку загальне сховище є єдиною точкою відмови, то необхідно впровадження рішення для резервування сховища. Це збільшує складність і вартість такого рішення.
Поведінка балансування навантаження в разі збою. Коли відмовостійка конфігурація області знаходиться в робочому стані, алгоритм хешування спрацьовує для кожного клієнтського запиту. У разі переривання зв'язку між серверами алгоритм хешування перестає використовуватися для обслуговування запитів клієнтів. Сервер починає відповідати всім клієнтам, працюючи в звичайному режимі, забезпечуючи, таким чином, доступність сервісу.
Інтервал автоматичного перемикання. Сервер, який втрачає канал зв'язку з партнером переходить в режим перерваного зв'язку. Втрата зв'язку може бути пов'язана з проблемами в мережі або з виключенням сервера-партнера. Так як сервер не має можливості виявити причину втрати зв'язку, то він буде перебувати в режимі перерваного зв'язку до тих пір, поки адміністратор вручну не встановиться, що сервер-партнер не працює. Крім цього, є можливість автоматично вказати, що партнер не працює, яка заснована на тимчасовому інтервалі. Цей настроюється параметр називається інтервалом автоматичного перемикання. За замовчуванням становить 10 хвилин.
Доброго дня
Дякую за публікується матеріал, постійно почитував.
у нас виникло питання про гаряче резервування (Hot Standby).
Можна ткнути носом, як це налаштовується в разі в різними сайтами і як клієнти будуть в разі падіння основного лізти на резервний?
Цікавить питання, що додатково потрібно докрутити (в теорії) на всьому мережевому обладнанні між майданчиками (у разі жорсткої фільтрації).