AD DS Replikace (AD Replications)

AD databáze je tvořena párticemi, které se dokáží nezávisle replikovat. Konkrétně jde o části Schema, a Configuration, které se vždy replikují na úrovni lesa, Domain, která se replikuje na úrovni konkrétní domény a Application, která se replikuje dle předem definovaných pravidel. Dále bychom něměli zapomenout na Globální katalog (GC), který se replikuje v rámci celého lesa, ale jen mezi ostatními GC.

Jak funguje AD DS replikace.

Jak funguje AD DS replikace.

AD databáze je typu multimaster, a tedy i samotná repikace využívá tzv. multimaster model, který umožňuje nezávisle replikovat oddělené částí AD databáze, a tedy každý DC je schopný přijmout aktualizace pro které je autoritativní.

AD Replikace využívá:

• multimaster replikace – každý DC je schopný přijmout aktualizace, pro které je autoritativní
• pull replikace – cílový DC si předem zažádá pouze o změny a snižuje se tak nárok na síťovou komunikaci
• store-and-forward replikace – DC dokáží pro optimalizaci replikace využívat nastavení subnet, kde v každém subnetu je zvolen pouze jeden DC (Bridgehead server), který je odpovědný za replikaci s jiným Bridgehead serverem jiného subnet. Tak je zajištěno, že replikace neprobíhá chaoticky mezi všemi DC, ale vždy v rámci jednoho subnetu a pomocí Bridgehead serverů v rámci subnet sítí.

Změny v AD které způsobí vzájemnou replikaci:

• vytvoření AD objektu (nový uživatel atd.)
• změna AD objektu a jeho atributů (telefonní číslo, oddělení)
• přesunutí objektu na jiné umístění v rámci AD (změna OU)
• vymazání objektu

Vymazání objektu jako jediné má odlišný průběh od ostatních změn. Pokud vymažete jakýkoliv objekt v rámci AD je mu přiřazen lifetime, standardně 180dní, který se následně replikuje na ostatní DC. Jakmile pak tento lifetime vyprší, je teprve objekt trvale z AD databáze vymazán.

U Serveru 2008 R2 je doba díky doménovému koši již 360 dní. 180dní doménový koš + 180dní AD

Jak funguje AD DS replikace v rámci jedné sítě

• jakmile jsou na jenom DC aplikovány změny, automaticky kontaktuje ostatní DC, aby si od něho změny stáhly
• pro běžné změny DC kontaktuje ostatní DC až po uplynutí 15 min.
• pro změny typu zabezpečení DC kontaktuje ostatní DC okamžitě (změna hesla)
• replikace v rámci jedné sítě je nekomprimována, jelikož se předpokláda rychlá linka mezi DC

Řešení replikačních konfliktů

Typy konfliktů

Existují tři typy konfliktů:

• současně se změní stejný atribut objektu na dvou DC
• přidání nebo změna objektu na jednom DC, pokud je na jiném DC smazán celý kontejner objektů ve stejném okamžiku
• přidání objektu se stejným jménem zároveň na dvou DC

Řešení konflitků

Z důvodů nebezpečí vzniku konfliktu byly zavedeny tzv. Global unique stamps, které při každé změně, která by měla být replikována, vytvoří „razítko“ stamp, které obsahuje číslo verze Version number, čas aplikování změny Timestamp a jedinečné GUID serveru, který změnu vytvořil.
Konflikty jsou pak řešeny, že vždy vyhraje položka s novějším číslem razítka – stamp

Replikační topologie je definice cest, které určují, jaká data se budou replikovat s jakými DC. O výslednou replikační topologii se stará služba KCC, která je spuštěna na kažém z DC. Při jakékoliv změně, která má za následek změnu v replikaci (přidání DC), propočítá možnosti a definuje, jaké DC a jaká data se budou vzájemně replikovat. Standardně v single site prostředí (použita pouze jedna subnet) se všechny DC replikují vzájemně.

Na našem obrázku pak vidítě prostředí dvou domén a jednoho lesa, kde byla automaticky vytvořena replikační topologie na základe AD partic (AD Partitions), kde část Schema a Configuration je replikována v rámci celého lesa, část domain je replikována v rámci jednotlivých domén a Globální katalog (GC) je replikován mezi ostatními GC v rámci lesa.