Сайтове и репликации в AD

Вече знаем какво е AD. Знаем още, че обектите на AD се пазят в домейн контролера на домейна. Базата на AD се дели на определени дялове. По подразбиране тези дялове са: SCHEMA, CONFIGURATION и DOMAIN. Освен тези задължителните може да има още дялове. Примерно дяла APPLICATION. Това е логическо делене на активната директория. Това логическо делене улеснява после при размяната на базите. Улеснява я с това, че праща не цялата база която може да е много голяма, а само дял и няколко дяла които искаме. И така първи извод: - Репликацията между домейните се осъществява между дяловете от базата. Много е объркващо затова за начало да разгледаме дяловете.

SCHEMA

Дяла “SCHEMA” съдържа описание на обекта в активната директория. Пример: Имаме обект (USER) със следните атрибути и значения. - Телефонен номер (tel:888812812) - Адрес (гр.Козарево, ул.Дунав No.7) - Име, Фамилия и т.н. (Иван Драганов) В схемата се съхранява обекта и свойствата които има. Според указаната схема може да създадем потребител само с указаните значения. Не може да създадем потребите и да си добавим още някакво значение, примерно фен на кой клуб е, защото това значение просто го няма в схемата.

CONFIGURATION

Тук се съхранява техническа информация. Примерно за сървиси.

DOMAIN

Съхранява всичките обекти които създаваме. Примерно създали сме трима потребителя, два компютъра и т.н.

APPLICATION

Това е специален дял. Тези дялове може да са много. В тях се записват определени приложения. Най-простия пример е DNS зоната. Тя се пази тук.

Репликации вътре в сайта

Имаме следната схема. Три домейн контролера (DC1, DC2, DC3) със следните потребители вътре. DC1 - user1:Ivan, тел.11111, факс 22222 DC2 - няма нищо DC3 - няма нищо Между контролерите върви репликация. По подразбиране е един път на 15 секунди. Не наведнъж а подред с интервал от 3 сек. Примерно DC1 реплекира първо на DC2, после на DC3. И така когато създадохме user1, в него се записа параметър USN. По този параметър другите контролери разбират кога е станала промяна. Същата логика както проверка дали има изменение в зоните на DNS, и ако има изменение да се препрати на Secondary DNS сървъра. Така когато направим промяна по user1, ще му се промени USN-а (ще се увеличи с +1), а това ще значи че трябва да се реплекира и по другите DC. Същевременно атрибутите тел, факс също имат USN. Той се мени по същата логика.

САЙТОВЕ

Примерно имаме домейн “DOM.BG”. В този домейн има 100 компютъра в София и 30 в Пловдив. По схемата имаме два DC, единия стои в София, другия в Пловдив. Тъй като са членове на един домейн, компютрите от София периодически ще се връзват към домейна в Пловдив. За да не се случи това делим активната директория на логически сайтове. Пример: Сайт София, съдържа в себе си домейн контролера DC-Sofia Сайт Пловдив, съдържа в себе си домейн контролера DC-Plovdiv. Така потребителите от София, ще ходят на сайта София, а тези от Пловдив ще ходят на сайта на Пловдив. Ако обаче примерно DC-Sofia падне. То тогава потребителите от София ще се вържат към домейн контролера Пловдив. Идва логическия въпрос. А откъде ще знаят кой потребител към кой сайт да се обръща? Компютъра определя към кой домейн контролер да се върже по мапинг по мрежата. Пример: Компютъра от София има IP адрес 10.0.0.33/24. Компютъра от Пловдив има IP адрес 172.31.122.16/24 На ниво активна директория правим подмрежи и казваме, че мрежата 10.0.0.0/24 е за София, а 172.31.122.0/24 е за Пловдив. Така компютъра като влезе в мрежата гледа своето IP в коя подмрежа е. Сравнява го с дефинираните под-мрежи в AD. Ако неговия IP адрес попада в някоя от подмрежите, гледа към кой сайт е тази подмрежа. Така разбрал към кой сайт е, гледа какви DC има в този сайт и се връзва към един от тях. В случай, че този сайт няма работещи DC-та се обръща към друг сайт и към други DC-та.

РЕПЛИКАЦИЯ НА САЙТОВЕ

Имаме три сайта с домейн контролери. 1. София: DC-Sofia 2. Пловдив: DC-Plovdiv 3. Бургас: DC-Burgas Между сайтовете има връзки наречени Site Link. Примерно връзки 1-2, 1-3 и 2-3. Връзка всеки сайт с всеки. Цялата тази връзка се нарича топология на репликацията на активната директория. Във всеки сайт има специален DC, който се нарича BRIDGHEAD сървър. Този сървър отговаря към кого какво да прати и от кого какво да получи. BRIDGHEAD избира линк по който да се проведе репликация. Сайт линка има параметър наречен стойност. Да разгледаме следните линкове със съответните стойности

1-ви линк (1-2) има стойност 20 2-ри линк (1-3) има стойност 30 3-ти линк (2-3) има стойност 5 Така репликацията избира път който сумарно е с най-малка стойност. Да видим репликацията между сайт 1 до сайт 3. Има два възможни маршрута. 1-3 имащ стойност 30 и 1-2, 2-3 имащ сумарна стойност 25. 25 е по-малка стойност това значи че репликацията ще се проведе по втория маршрут. Ако се сещаме за правилото, че репликацията вътре в сайта между контролерите се прави на всеки 15 секунди по подразбиране плюс 3 секунди, тука репликацията между сайтовете се прави на всеки 3 часа по подразбиране. В зависимост от потребностите администратора може да променя това време, както и предното разбира се. За отдалечени сайтове с бавни връзки където репликацията трае дълго време, може да се прави един път на 12 часа. Всичко е от ситуацията. Репликацията се прави по два протокола. RPC и SMTP. Втория също се ползва при електронната поща. Разликата между двата протокола е, че RPC прави синхронна репликация, а SMTP асинхронна. Синхронна репликация е когато примерно DC1 пита DC2 и чака отговор. Докато не получи този отговор репликации към друг DC не прави. Асинхронната прави запитване към много DC контролери и постепенно получава отговори. Най-често се ползва синхронна репликация по протокол RPC. Стига теория малко практика. Схемата ще е следната:

Теоретично идеята трябва да е следната. Двете мрежи 192.168.1.0 и 192.168.10.0 да са клас С. Тъй като CORE в момента не е рутер то ще импровизираме. За да вижда TLan-DC-02 първия домейн контролер, ще му променим маската така, че да включва и мрежата на TLan-DC-01. От горе казаното да променим IP-то на TLan-DC-02. Трябва да стане IP=192.168.10.2; Mask=255.255.0.0 ; GW=192.168.10.1; DNS=192.168.1.2. Разбира се маската трябва да се промени на TLan-DC-01 и на CORE. Така контролерите на двата домейна ще са в един клас мрежа на мрежово ниво и ще се виждат. На ниво AD ще създадем две под мрежи. Клиентите ще различават тези под-мрежи и ще се връзват в зависимост от под-мрежата. Да започнем с TLan-DC-02.

Това са му мрежовите настройки.

Така трябва да изглежда крайния резултат. Да инсталираме ролята AD.

Ролята е инсталирана Да я активираме

Добавяме домейн контролера към съществуващ домейн. Указваме името на домейна. Натискам бутона Change… за продължение.

Въвеждаме име и парола на домейн администратора.

Тъй като нямаме дефинирани сайтове в AD, то предлага да се вържем към подразбиращия се Defaulg-First-State-Name. Това е сайта който се създаде по подразбиране, когато дефинирахме TLan-DC-01.

Нека на този DC също да се инсталира DNS сървър. Тъй като този DC ще бъде в отделен сайт, то добра практика е всеки сайт да си има собствен DNS сървър.

Когато се създаде първия DC, можеше да се създаде диск и от него тук да инсталираме. Ние ще изберем друг път за инсталация.

Избираме съществуващ DC.

След проверката дали може да се инсталира не установи фатални грешки. Може да продължим с инсталацията на ролята.

Това показва, че SID на контролера на домейн е идентичен с този на вашия клиент. Тази грешка може да се появи при Vultr, тъй като могат да бъдат създадени случаи със същия SID. Това е така защото клонирах машините, а не направих чисти инсталации. Ще трябва да генерираме нов SID чрез нулиране на текущия на клиентския компютър. Можем да направим това, като използваме инструмента sysprep, който ще нулира някои елементи на системата. Отваряме Command Prompt. C:\Windows\system32>Sysprep\sysprep.exe. Отваря се следния прозорец:

Изберете както е указано на снимката.

Изчакайте процеса да завърши. Това ще доведе до рестарт на машината. Също така ще се нулират някои от неща във Windows. Ще се наложи наново да се настроят.

След рестарта първия екран за настройка. Не го променяме.

Приемаме лицензното споразумение.

Дефинираме парола за локалния администратор. След зареждане на системата, се вижда, че е променено името на компютъра и мрежата.

Да ги поправим.

Трябва да се получи горния екран. Това се постигна като смених името на компютъра, мрежовите настройки и го рестартирах.

Наново да се опитаме да дефинираме домейн контролера. Първите стъпки няма да ги показваме, а ще продължим от мястото където даде грешка. След като пуснахме инсталацията, този път премина успешно.

Предлага да рестартираме машината за да влязат промените в сила. Ако изчакате и не правите нищо системата сама ще се рестартира.

След рестарта първия екран. Вече няма локален администратор. Влизаме с домейн администратора.

Вече е в домейна. Да се прехвърлим на TLan-DC-01.

Вижда се, че имаме два домейн контролера. Значи всички записи в активната директория са създадени за TLan-DC-02. Сега да се занимаем със сайтовете.

Както се вижда на снимката, Sites съдържа три под-групи. - Inter-Site Transports: Тука ще видим на по-късен етап Site link - Subnets: Тука ще се дефинират под-мрежите. - Default-First-Site-Name: Това е първия дефиниран сайт. Ако се сещате той се получи по-подразбиране при инсталиране на TLan-DC-01 Да преименуваме съществуващия сайт.

Избираме сайта и натискаме бутона F2.

Нека да се казва Main. Виждаме, че съдържа в себе си двата домейн контролера. Съответно контролерите съдържат в себе си NTDS-Settings. Това в същност са обектите на репликация. Да създадем нов сайт.

Новия сайт ще се казва Far. Избираме и Saitelink. В случая не сме дефинирали никакви линкове, затова избираме DEFAULTIPSITELINK.

Сега малко предварителна подготовка, преди да конфигурираме двата сайта.

SaitLink, както знаем работи с два протокола. Единия е RPC, в случая дефиниран като IP и втори SMTP. Работим с RPC (IP) и в него има дефиниран един SaitLink по подразбиране DEFAULTIPSITELINK. Нека да отворим да видим какво има в SaitLink

Показва кои сайтове ще се репликират. Виждаме тежестта на линка, в случая е 100. Виждаме на колко време да се репликират (180 минути). Ако се сещате в началото пояснявахме как правим три линка с различна тежест. Как сървъра си избира пътя на репликацията в зависимост от стойността на линка. Ето от тук може да се дефинира всичко това. В горната картинка имаме два сайта, затова и линка е един. Ако имаше повече сайтове то стъпките са следните. - Създаваме линк. - В линка описваме между кои сайтове ще е връзката - Указваме тежестта на връзката - Указваме на колко време да се репликира. - Използвайки Change Schedule…, може да укажем в кой интервал от време да протече репликацията, в кои дни и т.н. След този увод да редактираме текущия сайт-линк.

Внимавайте, Replicate every: трябва да е кратно на 15 минути.

Съответно да преименуваме сайт-линка с разбираемо име. Тежестта на връзката е 10. Ще се репликира на 30 мин. Сега да преместим втория домейн контролер в новия сайт.

Просто влачим с мишката TLAN-DC-02 до новия сайт Far, в папка Servers.

Вече имаме два домейн контролера разнесени в два сайта. Остана да направим под-мрежите.

ОК за продължение.

Дефинираме и втората подмрежа 192.168.10.0/24 с принадлежащия и сайт Far.

Това е крайния резултат. Ако се сещате, в началото казахме в зависимост от под-мрежата клиента ще се връзва към сайта в който принадлежи. Да тестваме това. Влизаме с клиентска машина. Първоначално мрежовите и настройка ще са: IP: 192.168.0.50 Mask: 255.255.255.0 DNS: 192.168.0.2 Машината разбира се трябва да е член на домейна TLan.Net. Да тестваме сега към кой сайт се e вързала. За целта отваряме един Command Prompt.

C:\Windows\system32>hostname Win81-E-x86 C:\Windows\system32>nltest /server:Win81-E-x86.tlan.net /dsgetsite Main The command completed successfully

Виждаме, че сме се вързали към сайта Main. Така и трябва да бъде. Под-мрежата която дефинирахме за сайта е 192.168.0.0/24. Сега да сменим мрежовите настройки на компютъра. Рестартираме се и пробваме да влезем в домейна Новите настройки са: IP: 192.168.10.50 Mask: 255.255.255.0 DNS: 192.168.10.2 Да тестваме сега към кой сайт се вързал.

C:\Windows\system32>hostname Win81-E-x86 C:\Windows\system32>nltest /server:Win81-E-x86.tlan.net /dsgetsite Far The command completed successfully

Върза се към новия сайт. Всичко е точно. И сега ако създадем потребител в сайта Main, то той ще се появи в сайта Far след 30 мин. Това беше времето за репликация което указахме. Това e всичко за сега. Както винаги за повече информация през търсачките.