Работа с домейн контролери само за четене (RODC) (част 1), Windows OS Hub

Добър пример за цикличния характер на ИТ развитието е нова функция в Windows Server 2008, наречена Read Only Domain Controller или RODC. В крайна сметка тази технология се появи за първи път преди много време, но през последните 10 години практически не се използва.
Windows NT беше първата сървърна операционна система от Microsoft. Подобно на съвременните операционни системи Windows Server, Windows NT напълно поддържа домейн технология. Една разлика беше фактът, че само един домейн контролер на домейн можеше да се записва. Този домейн контролер, наречен първичен домейн контролер или PDC, беше единственият домейн контролер, в който администраторът можеше да прави промени. След това PDC разпространява актуализациите към други домейн контролери в домейна. Тези домейн контролери се наричаха резервни домейн контролери (BDC) и информацията за тях се актуализираше само когато основният домейн контролер беше актуализиран, те бяха само за четене за домейн клиенти.
И въпреки че този модел на домейн беше напълно функционален, той имаше и значителни недостатъци. По-специално, проблеми с основния домейн контролер могат да парализират целия домейн. Както знаете, Microsoft направи значителни промени в модела на домейна, който са внедрили в новата си Windows 2000 Server OS. Windows 2000 Server въведе две нови технологии за контролери на домейни, като и двете все още се използват днес: Active Directory и моделът с множество главни устройства.
И въпреки че ролята на PDC все още беше запазена, останалите контролери на домейни в конфигурацията с множество главни устройства бяханаличен за запис. Това означаваше, че администратор може да прави промени на всеки домейн контролер и тези промени в крайна сметка ще бъдат разпространени като актуализации на всички други домейн контролери в мрежата.
Мулти-главният модел след това беше пренесен както в Windows Server 2003, така и в Windows Server 2008. Въпреки това Windows Server 2008 въведе възможността за създаване на домейн контролери само за четене. 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, но значително намалява натоварването на предмостния сървър, т.к. те получават само входящ трафик за репликация.
RODC също могат да помогнат за подобряване на сигурността, като попречат на персонала на клоновете да прави промени в базата данни на Active Directory. В допълнение към RODC не се прехвърля информация за всички потребители на домейна и техните акаунти. Това означава, че ако някой открадне RODC сървъра, той няма да може да използва информацията, получена чрез разбиване на потребителски пароли.