Екі алаңдағы Active Directory қалай жұмыс істейді?

Екі алаңдағы Active Directory алаңдар арасындағы арна үзілгенде жергілікті аутентификацияны тоқтатпай жұмыс істеуге тиіс. Ол үшін әр алаңда жұмысқа жарамды домен контроллері, жергілікті DNS, дұрыс сипатталған сайттар топологиясы және орталыққа тәуелді қосымшалардың алдын ала тексерілген тізімі болуы керек. Орталықтағы бір контроллер мен «филиалдағы кэштелген құпиясөздер» мұндай төзімділікті қамтамасыз етпейді.

WAN арнасының үзілуі каталогты әдетте зақымдамайды. Қауіп бұдан бұрын, клиенттер дұрыс емес контроллерді таңдағанда басталады. Арна қалпына келген соң әкімші жиналған репликация кезегін сақтық көшірме деп ойласа немесе ұзақ уақыт оқшау тұрған DC-ді тексермей желіге қосса, қауіп қайта туындайды. Мен AD DS репликация механизмінен гөрі қате DNS пен виртуалды машина суретін асығыс қалпына келтіруден болған апатты көбірек көрдім.

Әр алаңдағы контроллер істен шығу шекарасын өзгертеді

WAN арнасынсыз жұмысын жалғастыруы тиіс әр алаңға кемінде бір жазылатын домен контроллері мен DNS серверін орналастырыңыз. Сонда жергілікті компьютерлер DC-ді DNS арқылы тауып, Kerberos билеттерін алады, құпиясөзді тексереді, бұрын қолжетімді болған топтық саясаттарды қолданады және орталық қолжетімсіз кезде жергілікті қызметтерге қосылады.

Бір дата-орталықтағы екі контроллер сервердің істен шығуынан қорғайды, бірақ талшықты желінің үзілуінен, маршруттау қатесінен, шеткі жабдықтың бұзылуынан немесе бүкіл алаңның өшуінен қорғамайды. DC санын талқыламас бұрын талапты нақтылаңыз: филиал толық оқшауланғанда қандай операциялар және қанша уақыт орындалуы керек. «Пайдаланушылар Windows жүйесіне кіре алады» деген талап тым жалпылама.

Екінші шағын алаң екі сервердің шығынын көтере алмаса, бір жергілікті DC жиі орынды шешім болады. Бірақ бұл саналы түрде қабылданған жалғыз істен шығу нүктесі: WAN мен сол DC бір уақытта істен шықса, тіркелгі деректерін жаңадан тексеру тоқтайды. Кэштелген кіру жұмыс станцияларындағы әсерді азайтады, алайда файл ресурстары, қосымшалар мен әкімшілік жұмыс үшін контроллерді алмастырмайды. Маңызды алаңға виртуализация түйіндері мен қуат көздері бөлек екі жергілікті DC керек.

Контроллерді виртуалдауға болады, бірақ бір алаңның екі данасын бір хостқа, бір дискілік массивке немесе бір үздіксіз қуат көзіне орналастырмаңыз. Гипервизор ортақ тәуелділіктерді жоймайды. Орналастыру ережелерін бекітіңіз, екі DC-дің бір түйінге қатар көшуіне тыйым салыңыз және уақыт қызметі, DNS пен басқару желісі каталогты қорғауға арналған сол істен шығу жағдайына төтеп беретінін тексеріңіз.

Филиалдағы жазылатын DC ыңғайлы, бірақ ол каталог көшірмесін сақтап, өзгерістерді қабылдайды. Алаңның физикалық қорғанысы әлсіз болса, RODC нұсқасын қарастырыңыз. Басқарылатын құпиясөздерді кэштеу саясаты сервер ұрланғандағы зардапты азайтады, бірақ мұны бөлек жобалау керек: құпиясөзін кэштеуге рұқсат берілмеген пайдаланушы жазылатын DC қолжетімсіз кезде жаңа тексеруден өтпейді. RODC-ді тек «қауіпсіздеу» естілетіні үшін таңдамаңыз.

Бірнеше домені бар орманда жергілікті DC-ге жаһандық каталогты орнатқан дұрыс: ол бүкіл орман бойынша іздеуге және әмбебап топтарға мүшелікті анықтауға қажет. Шағын алаң үшін Universal Group Membership Caching қолдануға болады, бұл репликацияланатын дерек көлемін азайтады, бірақ кэштің уақытында жаңарғанына тәуелділік қосады. Екі алаң болғанда, арна GC репликациясы қолданбалы трафикке нақты кедергі келтіретіндей тар болмаса, мұндай үнем қосымша белгісіздікке тұрмайды.

Тек екінші алаң үшін бөлек домен құрмаңыз. Домен каталог бөлімінің әкімшілік және репликация шекарасын белгілейді, бірақ сол домендегі дұрыс орналастырылған DC-ге қарағанда жақсы автономдылық бермейді. Жаңа домен DNS делегациясын, орман ішіндегі сенім қатынастарын, бөлек саясаттарды, топтарды және қалпына келтіру рәсімдерін қосады. Қалыпты «орталық пен филиал» сұлбасы үшін бір домен мен екі сайтты тексеру және қалпына келтіру оңайырақ.

Контроллер қуатын тыныш күндегі процессордың орташа жүктемесімен емес, тексерулердің ең жоғары санымен, LDAP сұрауларымен, DNS жүктемесімен және каталог көлемімен таңдаңыз. Серіктесі техникалық қызмет үшін тоқтағанда бір жергілікті DC бүкіл алаңды жалғыз өзі қызмет көрсете алатынын тексеріңіз. NTDS, журналдар, SYSVOL және диагностика үшін дискіде қор қалдырыңыз: жүйелік томның толуы қашықтан көмек қолжетімсіз сәтте қызметтерді тоқтатуы мүмкін.

Сайттар мен ішкі желілер контроллер таңдауын басқарады

Active Directory Site ұйым құрылымындағы кеңсені емес, сенімді әрі жылдам желілік байланыс аймағын сипаттайды. Әр физикалық алаң үшін бөлек сайт құрып, оған сымды VLAN, Wi-Fi, сервер сегменттері, VPN пулдары және мекенжайлау өзгергеннен кейінгі жаңа диапазондарды қоса алғанда, барлық клиенттік ішкі желілерді тіркеңіз.

DC Locator лайықты контроллерді табу үшін DNS SRV жазбалары мен сайт туралы мәліметті қолданады. Microsoft процесті былай сипаттайды: клиент DNS арқылы DC тізімін алады, олардың қолжетімділігін тексереді, ал Netlogon таңдалған контроллерді кэшке жазады. Клиенттің ішкі желісі Active Directory Sites and Services ішінде болмаса, ол басқа алаңдағы контроллерді алуы мүмкін. WAN жұмыс істеп тұрғанда қате шағын кідіріс болып көрінеді. Арна үзілгенде жергілікті DC дұрыс жұмыс істеп тұрса да, кіру ұзарады, Kerberos қателері мен «домен қолжетімсіз» шағымдары шығады.

Сәйкестікті әкімші консолінен ғана емес, клиент компьютерінен тексеріңіз:

nltest /dsgetsite
nltest /dsgetdc:corp.example /force
Resolve-DnsName _ldap._tcp.Branch-A._sites.dc._msdcs.corp.example -Type SRV

Бірінші пәрмен Branch-A сияқты күтілген сайтты қайтаруға тиіс. Екінші пәрмен нәтижесінен жергілікті DC атауын және KDC, TIMESERV, WRITABLE, қажет болса GC жалаушаларын іздеңіз. Үшінші пәрмен жергілікті контроллердің белгілі бір сайтқа арналған SRV жазбасын көрсетуге тиіс. Сынақ орталық DC-ді қайтарса, оны hosts ішіндегі тұрақты жазбамен емдемеңіз: Subnet объектісін, DNS тіркелуін және желілік қолжетімділікті түзетіңіз.

Ішкі желілерді экспорттауды IP мекенжайларын басқару процесіне қосыңыз. Жиі кездесетін ақау былай басталады: желі инженері VLAN қосады, DHCP мекенжайларды таратып қойған, ал AD тобы бұл туралы оқиғадан кейін біледі. «CIDR, сайт, иесі, мақсаты» деген қарапайым кесте жылына бір рет жаңартылатын әдемі сұлбадан пайдалырақ.

Егер екі физикалық алаңның арасында WAN болса, «қарапайым болсын» деп оларды бір сайтқа біріктірмеңіз. Сайт ішіндегі репликация жақсы байланысты көздейді және серіктестерге өзгеріс туралы белсенді хабарлама жібереді. Сайттар арасындағы репликация трафикті сығады, кесте мен жол құнын ескереді. Қате модель AD-ге арнаны желі тобы күткеннен өзгеше қолданғызады.

Контроллерлердің өздері де дұрыс Site объектілерінде тұруы керек. VM-ді физикалық алаңдар арасында ауыстырғанда, IP өзгерсе де оның AD сервер объектісі автоматты түрде көшпейді. NTDS Settings объектісінің орнын, интерфейс мекенжайын, байланысқан ішкі желіні және SRV тіркелуін салыстырыңыз. Физикалық түрде Branch-A ішінде жұмыс істеп, логикалық түрде HQ ішінде қалған DC KCC-ге жалған карта бойынша байланыс құрғызады.

Бос немесе бірін-бірі жабатын Subnet объектілерін де тексеріңіз. Active Directory ең нақты сәйкестікті таңдайды, сондықтан ұмыт қалған /16 жаңа /24 жазбаларының жоқтығын мекенжайлар өзгергенге дейін жасыруы мүмкін. Тізімді экспорттап, IPAM жүйесімен салыстырыңыз және сайтсыз клиенттер туралы Netlogon оқиғаларын бақылаңыз. Бұл арзан тексеру арна үзілгеннен кейінгі ұзақ зерттеуді болдырмайды.

Арна құны жолды, ал кесте уақыт терезесін таңдайды

Site Link KCC-ге қандай сайттар репликация жасай алатынын, олардың салыстырмалы құнын және байланыс қашан қолжетімді екенін хабарлайды. Құн мегабитті, кідірісті немесе оператор бағасын өлшемейді. Бұл өлшемсіз салмақ, AD жиынтық құны ең төмен бағытты таңдайды.

Бір арнасы бар екі алаң үшін екі сайтты қамтитын бір IP site link жеткілікті. Оған түсінікті атау беріңіз, тәулік бойы қолжетімді етіп қалдырыңыз және өзгерістердің рұқсат етілген кідірісіне сай аралықты таңдаңыз. Қазіргі жеке желілерде тарихи 180 минутты себепсіз қалдырғаннан гөрі 15 минуттан бастап, жүктемені өлшеген дұрыс. Microsoft сайттар арасындағы репликацияның әдепкі аралығы 180 минут екенін көрсетеді және оны ReplicationFrequencyInMinutes арқылы өзгертуге мүмкіндік береді.

Негізгі MPLS пен резервтік VPN болса, сол екі физикалық арнаны бір жұп сайт арасындағы екі site link ретінде көрсетуге тырыспаңыз. AD контроллерлер арасындағы IP қолжетімділікті көреді, ал бағытты желі таңдайды. Үш немесе одан көп сайт арқылы әртүрлі логикалық жолдар болғанда AD арна құндары пайдалы болады. MPLS-тен VPN-ге ауысуды маршрутизаторлар немесе SD-WAN орындап, қажет порттар мен атауларды шешу мүмкіндігін сақтауы керек.

Үш немесе одан көп алаң болса, site link bridging параметрін тексеріңіз. Әдепкіде AD IP site links байланыстарын транзитивті деп қабылдап, құны сәйкес келсе аралық сайт арқылы жол құра алады. Бұл желі барлық қосылған сайттар арасында трафикті шынымен бағыттағанда ғана дұрыс. Филиалдар бір-бірімен тікелей байланыспайтын hub-and-spoke желісінде желілік деңгейде hub арқылы транзитті қамтамасыз етіңіз немесе автоматты bridging функциясын өшіріп, қажет көпірлерді анық көрсетіңіз.

Кесте рұқсат етілген 15 минуттық блоктардан тыс уақытта сайттар арасындағы репликацияға тыйым салады. Ол рұқсат етілген терезеде өткізу жолағын шектемейді және үлкен кезек терезе жабылғанша жіберілетініне кепілдік бермейді. Жұмыс уақытында репликацияны тоқтату тар арналарда әлі де танымал, бірақ көбіне қате: құпиясөздер, тіркелгі бұғаттары және қауіпсіздік топтарындағы өзгерістер алаңдар арасында кеш тарайды. Репликацияны үнемі рұқсат етіп, лайық аралық орнатып, арнадағы басымдықты желілік QoS арқылы басқарған қауіпсіз әрі түсінікті.

Арнаны қайталанатын пәрменмен құруға болады:

New-ADReplicationSiteLink -Name "HQ-Branch-A" `
  -SitesIncluded "HQ","Branch-A" `
  -Cost 100 `
  -ReplicationFrequencyInMinutes 15 `
  -InterSiteTransportProtocol IP

Өзгерістен кейін консольде объектінің бар болуына қарап шешім шығармаңыз. Жасалған connection objects пен нақты нәтижені тексеріңіз:

repadmin /showrepl * /csv
repadmin /replsummary
dcdiag /test:replications /e /v

repadmin /replsummary ішінде largest delta, қате саны және сәтсіз әрекет пайызын қараңыз. Кесте немесе топология жаңа репликацияға жол бермей тұрғанда қате саны нөл болғанымен, өсіп келе жатқан largest delta жүйенің дұрыс екенін дәлелдемейді. Тұрақты бақылау үшін TCP портының қолжетімділігін ғана емес, әр naming context бойынша соңғы сәтті алмасу уақытын жинаңыз.

Арна үзілгенде әр алаң өз көшірмесімен жұмысын жалғастырады

WAN үзілгеннен кейін контроллерлер арнайы автономды режимге өтпейді. Әр жазылатын DC өз каталог көшірмесіндегі жергілікті өзгерістерді қабылдап, Kerberos билеттерін беріп, LDAP сұрауларына жауап береді. Жіберілмеген өзгерістер байланыс қалпына келгенше кезекте тұрады.

DNS пен сайттар дұрыс бапталса, филиалдағы компьютер пайдаланушыны жергілікті DC арқылы доменге кіргізеді. Жергілікті файл сервері немесе қосымша да жергілікті DNS пен DC-ді қолданып, деректер, лицензия немесе маршрут жағынан орталыққа тәуелді болмаса, пайдаланушы оған қосылады. AD қолжетімді болып тұрса да, орталық дерекқорға тәуелді бизнес қызметі тоқтауы мүмкін. Сондықтан оқшаулау сынағы қолданбаның бүкіл жолын қамтуы керек.

Қолжетімді DC жоқ компьютер бұрын кірген пайдаланушыны кэштелген тіркелгі деректері арқылы кіргізе алады. Microsoft шектеуді анық айтады: мұндай кіру жергілікті жұмыс үстелін ашады, бірақ домендік тексеруді қажет ететін ресурстарға қолжетімділік бермейді. Windows әдетте он бірегей пайдаланушы туралы деректі сақтайды, ал Interactive logon: Number of previous logons to cache саясаты бұл санды өзгерте алады. Компьютер DC-ге қосылғанша кэш жаңа құпиясөзді алмайды.

Бұл жағымсыз, бірақ заңды жағдай туғызады. Пайдаланушы арна үзілер алдында орталық қызмет арқылы құпиясөзін ауыстырды, ал филиалдағы жұмыс станциясы жаңа құпиясөзбен сәтті кіріп үлгермеді. Автономды кіруде ескі құпиясөз жұмыс істеуі мүмкін, ал байланыс келген соң серверлік ресурс жаңасын талап етеді. Қызметкерлерге осы айырманы айтпай, «AD офлайн жұмыс істейді» деуге болмайды.

Екі алаңдағы өзгерістер бұғатталмайды. Әкімшілер объектінің әртүрлі атрибуттарын бір уақытта өзгертсе, AD оларды көбіне атрибут метадеректері арқылы біріктіреді. Екеуі бір атрибутты өзгертсе, нұсқа саны үлкені жеңеді, ал нұсқалар тең болса уақыт пен бастапқы DC идентификаторы есепке алынады. Бұл бірлесіп өңдеу емес, қайшылықты шешу механизмі. Оқшаулау кезінде нәтиже қолжетімділікке әсер етсе, топтарды, GPO мен тіркелгілерді қатар өзгертпеңіз.

Құпиясөз өзгерісі қалыпты репликация кідірісіне қарағанда жақсырақ өңделеді: қате құпиясөз алған контроллер соңғы өзгерісті тексеру үшін PDC Emulator рөлінің иесіне жүгіне алады. Бірақ алаңдар арасындағы арна үзілгенде бұл жол қолжетімсіз. PDC Emulator орталық DC-ді әр кіру үшін міндетті етпейді, дегенмен жаңа құпиясөздер мен кейбір әкімшілік әрекеттер өзгеріс жасалған орынға тәуелді болады.

Бұрын берілген Kerberos билеті арна үзілсе немесе басқа алаңда тіркелгі бұғатталса да мерзімі біткенше жарамды. Сондықтан оқиғаның алғашқы сағаттарында қолжетімділік кейінгі уақытқа қарағанда тұрақты көрінуі мүмкін. Билеттерді тек арнайы сынақ компьютерінде тазалап, klist get арқылы жаңасын сұраңыз. Әйтпесе жергілікті KDC қолжетімділігін емес, ескі билеттің жұмысын өлшейсіз.

Тіркелгіні бұғаттау мен пайдаланушыны өшіру де үзілген арна арқылы бірден ортақ болмайды. Жергілікті DC деректің өзіндегі нұсқасына сүйенеді. Оқшаулау кезінде қауіпсіздік тобына әрекет қайда орындалғанын, қандай DC бұл туралы білетінін және бұрын берілген билеттермен қандай ресурстар әлі қолжетімді екенін хабарлаңыз. Байланыс келген соң репликация каталогты теңестіреді, бірақ шектеу екінші алаңға жетпеген уақытты қайтара алмайды.

Оқшаулаудың нәтижесін DNS, жаһандық каталог пен қосымшалар анықтайды

AD-мен біріктірілген аймағы бар жергілікті DNS әр автономды алаңға керек, өйткені клиенттер мен контроллерлер каталог қызметтерін DNS арқылы табады. Домендік компьютер интерфейстерінде жалпыға қолжетімді немесе провайдер DNS мекенжайларын көрсету SRV іздеуін бұзады. Сыртқы сұрауларды корпоративтік DNS серверлерінде бағыттаңыз, ал клиенттерге домен аймағын білетін DNS серверлерін ғана беріңіз.

DNS орнатылған DC-де жергілікті және қашықтағы мекенжайлардың әртүрлі ретін қолдануға болады, бірақ әр нұсқаның салдары бар. Microsoft қашықтағы DNS-ті бірінші қоятын контроллер WAN-ға көбірек тәуелді екенін, ал өзін бірінші қоятын контроллер аймақ репликациясының өзектілігіне тәуелді екенін айтады. Екі алаңда мен бірінші орынға жергілікті AD DNS, бар болса екінші орынға тағы бір жергілікті DNS, соңына қашықтағы корпоративтік DNS қоямын. Параметр өзгерген соң кэшті тазалап, жазбаларды тіркеп, қызмет бәрін өзі түзетті деп күтпей, аймақты тексеремін.

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
dcdiag /test:dns /e /v

IP мекенжайы бойынша сәтті ping ештеңені дерлік дәлелдемейді. AD репликациясына серіктестердің GUID-based атауларын шешу, RPC Endpoint Mapper, динамикалық RPC ауқымы, LDAP, Kerberos, SMB және DNS керек. 53 пен 389 порттарын өткізіп, RPC-ді бөгейтін сүзгі жұмыс істеп тұрған каталог көрінісін және тұрақты репликация кезегін қалдырады. Ережелерді Windows Server құжаттамасындағы порттар жиынтығымен салыстырып, екі бағытта DC арасындағы нақты сеансты тексеріңіз.

Бірнеше домені бар орманда жаһандық каталог пайдаланушының кіруіне және бүкіл орман бойынша іздеу жасайтын қосымшаларға әсер етеді. Жергілікті GC болмаса, қарапайым DC қолжетімді болып тұрса да WAN үзілгенде пайдаланушы кіре алмай қалуы мүмкін. Кей жағдайда Domain Admins мүшелеріне берілетін ерекшелік төзімділік жоспары бола алмайды. Жергілікті GC орнатыңыз немесе Universal Group Membership Caching функциясын саналы түрде баптап, нақты тіркелгілермен сынаңыз.

Орталық LDAP серверін тікелей көрсететін, домен атауының орнына IP қолданатын, орталық сертификаттау орталығын немесе NPS-ті қажет ететін, басқа сайттағы SYSVOL жолын сұрайтын не орталық дерекқорға синхронды өтініш жіберетін қосымшаларды бөлек түгендеңіз. AD сайттарын баптау нашар жазылған қосымшаны басқа серверге бағыттамайды. Әр қызмет үшін DC іздеу тәсілін, DNS тәуелділіктерін, GC талабын, қызметтік тіркелгіні және Kerberos билетінің мерзімі біткендегі әрекетін жазыңыз.

Қосымшаның LDAP оқу және жазу талаптарын ажыратыңыз. Каталогтың жергілікті көшірмесі көптеген объектіні оқуға мүмкіндік береді, бірақ қосымша жазуды алдын ала таңдалған серверге жіберуі, FSMO иесін талап етуі немесе RODC өзгерте алмайтын атрибуттарды қолдануы мүмкін. Оқшаулау кезінде сынақ объектісін нақты құру, өзгерту және жою әрекеттерін орындаңыз. Пайдаланушыны сәтті іздеу тек оқу жолын дәлелдейді.

Топтық саясат AD объектісі мен SYSVOL ішіндегі файлдардан тұрады. DFSR кешігіп немесе тоқтап тұрғанда NTDS replication дұрыс жұмыс істеуі мүмкін. Сонда басқару консолі GPO-ны көрсетеді, бірақ шаблондар мен скрипттер жоқ болғандықтан клиент оны оқымайды. GPO нұсқаларын, SYSVOL ортақ ресурсының күйін және екі DC-дегі DFS Replication оқиғаларын, әсіресе ұзақ кезектен немесе контроллер қалпына келгеннен кейін салыстырыңыз.

Репликация сақтық көшірмені де, шешім кворумын да алмастырмайды

Репликация каталогтың қолжетімділігін сақтайды, бірақ әкімші қатесін барлық контроллерге тез таратады. Ұйымдық бөлімді жою, қате GPO, қызмет құпиясөзін ауыстыру немесе бұзылған DNS жазбасы «резервтік DC-де» оқшауланып қалмайды. Екінші контроллер тағы бір белсенді көшірмені сақтайды, ал сақтық көшірме рәсім бойынша қайтаруға болатын күйді сақтайды.

Кемінде бірнеше DC-дің жүйелік күйін қорғап, қалпына келтіруді сынаңыз. Көшірмелерді ортақ массивтен, сақтық көшірме тіркелгісінен және физикалық алаңнан бөлек сақтаңыз. Microsoft кемінде бір контроллерді сақтық көшірмеге енгізуді және көшірме жасын tombstone lifetime шегінен асырмауды ұсынады. Мен бұған қатаңырақ талап қосамын: тексерілген DSRM құпиясөзі, белгілі қалпына келу уақыты және оқшаулау кезінде қолжетімді тасымалдағышы жоқ көшірме тек есепте бар.

Гипервизор суретін күнделікті кері қайтару батырмасы ретінде қолданбаңыз. Қазіргі виртуалданған DC жарамды қалпына келтіруді VM-Generation ID арқылы танып, USN rollback жағдайынан қорғанады, бірақ бұл кез келген snapshot-ты орманның келісілген сақтық көшірмесіне айналдырмайды. Қолдауы бар жүйелік күй көшірмесі мен жазылған қалпына келтіру реті сенімді бастапқы күйді анықтайды.

FSMO рөлдері кластер емес және WAN жоғалғанда автоматты түрде ауыспайды. Күнделікті кірудің көбі рөл иесінсіз жалғасады. Бірақ кей объектілерді құру, сұлба мен домен операциялары, жергілікті пул таусылғаннан кейін RID беру және жаңа құпиясөздерді жедел өңдеу нақты рөлге тәуелді болуы мүмкін. Қысқа үзілісте рөлдерді филиалға тартып алмаңыз: бұрынғы иесі оралғанда қажетсіз әрі қауіпті кері көшіру рәсімі пайда болады.

Active Directory Recycle Bin функциясы жоюға дейін қосылған болса, байқаусыз жойылған объектілердің көп атрибутын сақтап қайтарады. Ол авторитетті қалпына келтіру керек жағдайларды азайтады, бірақ бұзылған атрибуттардан, қате GPO-дан, қолға түскен әкімшілік тіркелгілерден немесе бүкіл орманның жоғалуынан қорғамайды. Оны саналы түрде қосып, қалпына келтіру құқығын дұрыс бөліңіз және жүйелік күй көшірмесін бәрібір сақтаңыз.

Апатқа дейін бизнес қай шектен кейін алаңды жай ғана ажыраған емес, жоғалған деп есептейтінін анықтаңыз. Рөлді seizure арқылы алу бұрынғы иесі желіге бастапқы күйінде оралмайтыны расталғаннан кейін ғана жасалады. Шек қызыл панельден туған үрейге емес, RID қорына, күтілетін өзгерістерге және жөндеу уақытына сүйенуі керек.

Үзіліс кезінде өзгерістерді жазып, сау каталогты жөндемеңіз

Арна үзілгені расталғанда алдымен желі апатын DC ақауынан ажыратыңыз. Жергілікті DNS, уақыт, AD DS және DNS қызметтерін, жергілікті аутентификацияны және SYSVOL қолжетімділігін тексеріңіз. Содан кейін әр каталог бөлімі бойынша соңғы сәтті репликация уақытын белгілеңіз. Мәжбүрлі репликацияны қайта-қайта іске қоспаңыз: ол жоқ маршруттан өте алмайды және журналды қосалқы қателермен толтырады.

Оқиғаның жұмыс журналында өріс аз болуы мүмкін, бірақ олар дәл толтырылуы керек:

1. басталу уақыты және зардап шеккен желілік префикстер;
2. қолжетімді DC-лер мен FSMO иелері;
3. әр жақтағы әкімшілік өзгерістер;
4. артықшылығы жоғары және қызметтік тіркелгілердің құпиясөз өзгерістері;
5. арна қалпына келген уақыт және репликацияны тексеру нәтижелері.

Бизнес көтере алса, жоспарлы каталог өзгерістеріне бір жақты ғана жауапты етіңіз. Екінші жақта тек апаттық әрекеттерге рұқсат беріп, бұрынғы және жаңа мәнді жазыңыз. AD-ге математикалық біріктіру үшін мұндай тәртіп керек емес. Бұл адамдарға жеке-жеке дұрыс, бірақ бір-біріне сәйкес келмейтін екі конфигурация жасамау үшін қажет.

1988 немесе 2042 оқиғасын тез жою үшін strict replication consistency қорғанысын өшірмеңіз. Бұл оқиғалар lingering objects немесе тым ұзақ оқшаулауды көрсетуі мүмкін. Ескірген объектілерді қабылдауға рұқсат беру ақауды жасырып, таратады. Алдымен оқшаулау ұзақтығын орманның нақты tombstone lifetime мәнімен салыстырыңыз:

(Get-ADObject `
  "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Properties tombstoneLifetime).tombstoneLifetime

Қазіргі ормандарда әдепкі мән жиі 180 күн, бірақ Windows Server жаңартуы каталогта бұрын орнатылған параметрді өзгертпейді. Басқа біреудің нұсқаулығынан алынған сан DC-ді қайта қосу шешіміне жарамайды. Мәнді өз каталогыңыздан алып, соңғы сәтті кіріс репликациясымен салыстырыңыз.

Параметрлерді өзгертпес бұрын екі жақтағы диагностика нәтижесін сақтаңыз. Оқиға уақыты, қате коды, source DC, destination DC және naming context DNS, RPC, қолжетімділік, уақыт айырмасы мен ескірген объект қателерін ажыратуға көмектеседі. Мониторингтегі қызыл белгішенің скриншоты мұны істей алмайды. Басқа ауысымның көмегі керек болса, бастапқы repadmin файлдарын және Directory Service, DNS Server, System, DFS Replication журналдарын беріңіз.

Арнаны бір Sync all батырмасымен емес, бақылаумен қайтарыңыз

Маршрут қалпына келген соң алдымен DC арасындағы DNS пен уақытты, содан кейін бір күтілген серіктестік бойынша қалыпты репликацияны тексеріңіз. Бүкіл орманға repadmin /syncall пәрменін бірден жіберсеңіз, бір түсінікті қате ондаған жазбаға айналады, ал үлкен backlog қолданбалы трафиктен бұрын арнаны толтыруы мүмкін.

Қауіпсіз қайтару реті:

1. A, SRV және GUID-based CNAME жазбалары екі бағытта шешілетінін растаңыз;
2. уақыт айырмасын және RPC қолжетімділігін тексеріңіз;
3. екі алаңдағы DC-лерде repadmin /showrepl іске қосыңыз;
4. күтілген дереккөзден бір бөлімнің репликациясын бастаңыз;
5. сәтті аяқталғаннан кейін барлық naming contexts пен SYSVOL үшін DFSR кезегін тексеріңіз.

Нақты іске қосу үшін repadmin /replicate <DestinationDC> <SourceDC> <NamingContext> пайдаланыңыз. Нәтижеде Sync from source: ... completed successfully жолы болуы керек. Содан кейін repadmin /replsummary азайып жатқан largest delta, нөл қате және соңғы сәтті әрекеттерді көрсетуі тиіс. Домен бөлімімен шектелмеңіз: Configuration мен Schema бүкіл орманға ортақ, DomainDnsZones және ForestDnsZones DNS-ке әсер етеді, ал SYSVOL NTDS replication емес, DFSR арқылы жүреді.

Бірнеше күндік үзілістен кейінгі үлкен backlog connection object жоюды немесе DC-ді қайта көтеруді талап етпейді. Қалыпты репликацияға уақыт беріп, өткізу жылдамдығы мен қателерді бақылаңыз, қажет болса AD трафигін QoS саясатымен уақытша қорғаңыз. Көп қолмен жасалған байланыс процесті сенімді түрде сирек жылдамдатады, бірақ KCC жұмысына кедергі жасап, келесі апатқа дейін шығу тегі ұмытылатын конфигурация қалдырады.

Бизнес жолын тексеру үшін арнайы OU ішінде сынақ тобын құру сияқты шағын әрі қайтарылатын өзгеріс жасап, оның екінші DC-де пайда болуын қадағалаңыз:

Get-ADReplicationAttributeMetadata `
  -Object "CN=AD-WAN-Test,OU=Service Tests,DC=corp,DC=example" `
  -Server "dc-branch-a.corp.example" |
  Select-Object AttributeName,Version,LastOriginatingChangeTime,OriginatingServer

Метадерек атрибут нұсқасын қай DC және қашан жасағанын көрсетеді. Бұл басқа контроллерге қосылған болуы мүмкін консольден объектіні көруден сенімдірек. Сынақтан кейін объектіні қалыпты жолмен жойып, жою әрекетінің де репликацияланғанын тексеріңіз.

Қайтаруды жаңа пайдаланушының кіруін, құпиясөз өзгерісін, жергілікті ресурсқа қолжетімділікті, GPO қолданылуын және қосымшаның жергілікті DC-ге сұрауын тексерумен аяқтаңыз. GSE.kz екі алаңға серверлік платформа мен интеграцияны жобаласа, қабылдау сынағына бір виртуалды DC-ді өшіруді ғана емес, WAN арнасын физикалық үзуді де қосқан жөн. Каталог сұлба бекітілгеннен кейін емес, бақыланған істен шығудан кейін төзімді деп есептеледі.

Жоғалған контроллерді қайта құрған әдетте қауіпсіз

Бір DC жоғалып, доменде сау контроллер қалса, ескі суретті қалпына келтіргеннен гөрі жоғалған DC метадеректерін тазалап, жаңа сервер құрып, қалыпты репликацияны іске қосқан қауіпсіздеу. Microsoft та мұндай жағдайлардың көбіне жаңа DC немесе авторитетті емес қалпына келтіруді ұсынады: каталогтың жұмыс көшірмесі сенімді бастапқы күй болып қалады, ал қалпына келген контроллер өзгерістерді серіктестерден алады.

Жоюдан бұрын сервердің қайтып келмейтініне көз жеткізіп, FSMO рөлдерін, Global Catalog, DNS аймақтарын, DHCP параметрлерін, сертификаттарды және LDAP endpoint тікелей көрсетілген қосымшаларды тексеріңіз. DC рөл ұстап тұрса және оны қолайлы мерзімде қалпына келтіру мүмкін болмаса, рөлді жұмыс істеп тұрған DC-ге seizure арқылы беріңіз. Бұрынғы иесін қайта орнатпай немесе дұрыс төмендетпей ешқашан қоспаңыз.

Жүйелік күйді авторитетті емес қалпына келтіру контроллердің өзін қайтару керек, ал басқа DC-лерде дұрыс каталог бар жағдайға сай келеді. Авторитетті қалпына келтіру репликацияланған көшірмелерден басым болуы тиіс таңдалған объектілерге немесе SYSVOL-ға арналған және бөлек рәсімді талап етеді. Орманды қалпына келтіру қолжетімді DC-лердің ешқайсысына сенуге болмайтын, мысалы кең тараған логикалық зақым жағдайында қолданылады. Бұл үш операция әртүрлі апатқа арналған, оларды араластыру қауіпті.

Ұзақ уақыт ажыратылған DC үшін бөлек шешім керек. Ол tombstone lifetime мерзімінен ұзақ репликация жасамаған болса, «бес минутқа қосып, қарап шығуға» болмайды. Microsoft қауіпті анық түсіндіреді: garbage collection өткеннен кейін жойылған объектілер басқа көшірмелерден жоғалуы, ал оқшау DC оларды lingering objects ретінде сақтауы мүмкін. 2042 оқиғасы каталогты қорғау үшін кіріс репликациясын бұғаттайды. Әдетте серверді қайта орнатқан дұрыс; lingering objects тазалауын белгілі жақсы DC арқылы тексерілген рәсіммен ғана жасаңыз.

Метадеректерді тазалау Domain Controllers контейнерінен бір жолды жоюмен бітпейді. Сервер және NTDS Settings объектілерін, DNS A, CNAME және SRV жазбаларын, site link topology мүшелігін, DFSR сілтемелерін, DHCP параметрлерін және мониторинг жазбаларын тексеріңіз. Қолдауы бар forced removal мен metadata cleanup рәсімін қолданып, содан кейін тірі DC-лер жоғалған GUID-пен репликация жасауға тырыспайтынын растаңыз.

Бүкіл алаң жоғалса, алдымен аман қалған жақта желі, DNS және уақыт негізін қалпына келтіріңіз. Содан кейін forest recovery керек пе, әлде сау көшірмеден жаңа DC-лерді орналастыру жеткілікті ме, соны шешіңіз. Forest recovery орманның түбірлік доменіндегі бір DC-дің сенімді сақтық көшірмесінен басталып, қалпына келген ортаны оқшаулайды және домендерді белгіленген ретпен қайтарады. Мұны түнгі ауысымда ойдан шығару мүмкін емес, сондықтан қадамдар, тасымалдағыштар, DSRM құпиясөздері мен жауаптылар апатқа дейін дайын болуы керек.

Оқшаулау сынағы нақты үзіліске дейін жауап береді

Желі, DNS, виртуализация немесе қосымшаларда ірі өзгеріс болғаннан кейін алаңдар арасындағы маршрутты әдейі өшіріп, архитектураны тексеріңіз. Сынақ ескі Kerberos билеттері аяқталып, орталыққа сұраулар көрінетіндей ұзақ болуы керек. ICMP-ді бес минутқа бұғаттау инженердің шыдамын ғана тексереді.

Сынаққа дейін repadmin /replsummary, dcdiag /e, dcdiag /test:dns /e бастапқы нәтижелерін және DFSR күйін сақтаңыз. Қалыпты тіркелгіні, жаңа тіркелгіні, құпиясөзін жақында ауыстырған пайдаланушыны және қызметтік операцияны дайындаңыз. Оқшаулау кезінде бұрын қолданылған және жаңа компьютерде кіруді, жергілікті ресурстарға қолжетімділікті, klist арқылы билет жасауды, GPO қолданылуын және кемінде бір маңызды қосымшаны тексеріңіз.

Теріс сценарийді бөлек тексеріңіз: WAN үзілген кезде жергілікті DC-ді тоқтатыңыз. Қай компьютер кэшпен кіретінін, қандай қызмет бірден тоқтайтынын және кезекші ауысым кэштелген кіруді домендік аутентификациядан ажырата алатынын көресіз. Жергілікті DC қайтқан соң Kerberos тексерісінен бұрын уақыт синхрондалғанын растаңыз.

Қабылдау өлшемдері нақты болуы керек: клиенттер жергілікті сайтты таңдайды, жергілікті аутентификация өтеді, DNS домендік жазбаларға жауап береді, қосымшалар белгіленген операцияларды орындайды, арна қайтқан соң репликация кезегі қысқарады, барлық бөлім мен SYSVOL қатесіз теңеседі. Әр тармаққа рұқсат етілген уақытты көрсетіңіз. «Жүйе қалыпты жұмыс істейді» деген тұжырым ақауды жабуға көмектеспейді.

Мониторинг пайдаланушылар шағымданғанға дейін ескертуі тиіс. Әр серіктес пен бөлім бойынша соңғы сәтті репликацияның жасын, Directory Service 1311, 1925, 1988, 2042 оқиғаларын, DNS 2087 және 2088 оқиғаларын, DFSR күйін және NTDS пен SYSVOL томдарындағы бос орынды жинаңыз. Сервердің өзінің қолжетімділігін бөлек қосыңыз: контроллер ping сұрауына жауап беріп, бір ай бойы DNS бөлімін алмауы мүмкін.

Екі алаңның жұмыс сұлбасы қарапайым әрі оқиғасыз көрінеді: жергілікті DC мен DNS, ішкі желілердің толық картасы, үнемі қолжетімді site link, GC туралы анық шешім, тәуелсіз сақтық көшірмелер және жаттықтырылған қайтару реті. Мұндағы тыныштық жақсы белгі. Сынақ кезінде команда қай құпиясөз жұмыс істеуі керек және ескі DC-ді қосуға бола ма деп дауласып жатса, архитектура үзіліске әлі дайын емес.