Вступ
У Windows Server 2008, Microsoft вирішила повернути функцію, яку ми не бачили з часів Windows NT: це технологія контролерів домену, доступних тільки для читання. У цій статті я розповім про технологію Read Only Domain Controllers і її переваги. Я раніше не раз згадував про цю технологію в своїх статтях, наприклад в статті про використання утиліти adprep в Windows 2008.
Хорошим прикладом циклічного характеру розвитку IT технологій є нова функція Windows Server 2008, яка називається Read Only Domain Controller, або RODC. Адже ця технологія вперше з'явилася вже давно, однак протягом останніх 10 років практично не застосовувалася.
Windows NT була першою серверної ОС від Microsoft. Як і сучасні операційні системи Windows Server, Windows NT повністю підтримувала технологію доменів. Одним відмінністю був той факт, що тільки один контролер домену в кожному домені був доступний для запису. Цей контролер домену, званий Primary Domain Controller або PDC, був єдиним контролером домену, в який адміністратор міг вносити зміни. Основний контролер домену потім передавав поновлення на інші контролери домену в домені. Ці контролери домену називалися резервними контролерами домену (backup domain controllers або BDC), і інформація на них оновлювалася тільки при оновленні основного контролера домену, для клієнтів домену вони були доступні тільки на читання.
І хоча ця доменна модель була повністю працездатною, у неї були і суттєві недоліки. Зокрема, проблеми з основним контролером домену могли паралізувати роботу всього домену цілком. Як ви знаєте, Microsoft внесла значні зміни в доменну модель, яку вони впровадили в свою нову серверну ОС Windows 2000 Server. У Windows 2000 Server з'явилися дві нові технології для контролерів доменів, і обидва цих нововведення використовуються і до цього дня: це Active Directory і модель з декількома основними контролерами (multi master модель).
І хоча роль PDC все ще зберігалася, інші контролери домену в мульти-мастерной конфігурації були доступними на запис. Це означало, що адміністратор може внести зміни на будь-якому контролері домена, і ці зміни у вигляді оновлень в кінцевому підсумку будуть поширені на всі інші контролери домену в мережі.
Потім мульти-мастерная модель була збережена і в Windows Server 2003 і в Windows Server 2008. Однак, в Windows Server 2008 з'явилася можливість створювати контролери домену тільки для читання (Read Only Domain Controllers). RODC - це контролер домену, інформація в якому не може бути змінена безпосередньо навіть адміністраторами. Єдиний спосіб поновлення цих контролерів домену - застосувати зміни на PDC, а потім ці зміни повинні бути поширені (реплікуються) на RODC. Нічого не нагадує?
Як ви бачите, RODC, є не чим іншим, як пережитком часів Windows NT. Безумовно, Microsoft не повернула б технологію RODC, якби не побачила б в їх застосуванні суттєвих переваг.
Перш ніж приступити до пояснення того, чому Microsoft вирішила знову повернутися до RODC, дозвольте мені пояснити, чому використання RODC не є обов'язковою умовою роботи з доменами Active Directory в 2008 Server. Якщо ви хочете, щоб кожен контролер домену в вашому лісі був доступний для запису, ви, безумовно, може зробити це.
Я хочу коротко згадати, що незважаючи на те, що RODC, дуже схожі на резервні контролери домену (BDC) в NT, вони зазнали ряд змін. Є кілька речей, які є новинками в технології RODC, і я хочу про них розповісти.
Отже, чому Microsoft вирішила повернути RODC? Це пов'язано з проблемами підтримки філіальної мережі (підрозділів і філій). Офіси філій традиційно досить важко супроводжувати і підтримувати через їх віддаленості і особливостей зв'язку між головним офісом і філією.
Традиційно застосовувалося кілька різних способів управління філіями, але кожен з них мав свої власні переваги і недоліки. Одним з найбільш поширених способів організації філіальної мережі є установка всіх серверів в головному офісі, і надання доступу до них користувачів філії через глобальну мережу (WAN).
Звичайно, найбільш очевидним недоліком такого методу є те, що якщо канал WAN нестабільний або відвалився, то користувачі, які знаходяться у філії, не в змозі нормально працювати, тому що вони повністю відрізані від всіх ресурсів центрального офісу. Навіть якщо мережеве з'єднання з головним офісом стабільно, часто продуктивність WAN з'єднання може бути невисока через навантаження на канал або безпосередньо швидкості з'єднання
Іншим поширеним варіантом при роботі з віддаленими філіями є підхід, який передбачає установку принаймні одного контролера домену на філію. Часто, цей контролер домену також виступає в якості сервера DNS і сервера глобального каталогу. Таким чином, навіть якщо WAN підключення розривається, то користувачі у філії, по крайней мере, мають можливість увійти в мережу. Залежно від характеру роботи організації, в філіальні підрозділи можуть встановлювати й інші сервера.
Хоча це рішення, як правило, працює досить непогано, і у нього є ряд недоліків. Основним недоліком є вартість. Розміщення серверів в філіях вимагає від підприємства вкладати гроші в серверне обладнання та ліцензії на програмне забезпечення. Істотно збільшуються також витрати на підтримку. Організація повинна визначити, чи потрібен у філії штат власних ІТ-фахівців, або в разі неполадок, вона готова чекати поки ІТ-персонал з центрального офісу добереться до філії.
Ще один нюансом при установці власних серверів у філії, є питання безпеки. У моєму досвіді нерідкі випадки, при яких сервера, які розташовані за межами центрально датацентру, залишалися банально без нагляду. Часто сервера просто закривають в шафі на ключ!
Як я згадував раніше, WAN з'єднання часто бувають повільним і ненадійним. В цьому криється ще одна проблема з розміщенням серверів у філії. Трафік реплікації контролерів домену може істотно завантажити таке з'єднання
Ось це якраз той випадок, коли можна використовувати RODC. Розміщення RODC в філія не позбавляє зовсім від трафіку реплікації Active Directory, але істотно знижує навантаження на bridgehead сервера, тому що вони отримують тільки вхідний трафік реплікації.
RODC можуть також сприяти підвищенню безпеки, адже персонал в офісі філії не зможе внести зміни в базу даних Active Directory. Крім того, ніякої інформації про всіх користувачів домену та їх учетке, не передаються на RODC. Це означає, що якщо хтось вкрав сервер RODC, він не зможе скористатися інформацією, отриманою в результаті злому паролів користувачів.
У наступних статтях цієї серії, ми обговоримо процес планування і розгортання контролерів домену, доступних тільки для читання.
Посилання на всі матеріали цієї серії:
Робота з контролерами домену Read-Only (RODC) (частина 1)
Робота з Read Only Domain Controller (частина 2)
Робота з Read Only Domain Controller (частина 3)
