[2003] AD synchronisatie

[perryodk]

Ik heb over bovenstaand plaatje een paar vragen namelijk:

• Zelf weet ik dat er tussen de root en child1 de AD database word gesynchroniseerd maar als die synchronisatie voltooid is krijgt child2 dan ook alle gegevens van child1 via, dus vanaf de root? Kunnnen alle gebruikers van child1 na de synchronisatie ook op de locatie van child2 inloggen?
• Hoe groot zijn de data blokken die iedere 15min worden verstuurd? Worden alleen de wijzigingen gesynchroniseerd? En blijven er data blokken verstuurt worden iedere 15min totdat de wijzigingen zijn gesynchroniseerd? Bv 2mb moet gesynchroniseerd worden dat zou dus 1 uur duren ?

Dit wil ik graag weten ivm met de hardware die moet worden aangeschaft. Op een DC zouden max 500 gebruikers kunnen en dan zou je als minimum een P3 500MHz en 512mb RAM kunnen gebruiken. Maar als we over het hele domein praten: ongeveer 5000 gebruikers moet je een iets krachtiger server aanschaffen . En ook omdat we willen weten wat voor datalijn er tussen de dc's moet komen kwa capaciteit.

Zelf heb ik al wat gezocht op GoT maar nog niet echt veel of dit onderwerp gevonden.

---

edit:

In het plaatje hierboven is er dus 1 DC per domein, maar wat als deze uitvalt ? Kan de gebruiker en de computer zich dan ook aanmelden op de forest root (zijn daar alle gebruikers gegevens aanwezig)? Zo ja, dat zou dan betekenen dat de forest root alle gegevens heeft. Verspreid de forest root ook weer alle gegevens naar alle andere DC's? Dus dan zou iedere DC/Forest Root gelijk aan elkaar zijn ? Dus allemaal even zware servers.

[ Voor 16% gewijzigd door perryodk op 12-10-2005 14:12 ]

[ShellGhost]

Als het goed is wordt child1 en 2 simultaan gesynched.
Dus kan je ook inloggen op bv child2 met een account.

Vraag 2: geen idee.

Voor de server, zeker de DC heb je wel een leuke bak nodig, aangezien die als root moet gaan werken.
Wanneer je een p3 500 met 512 gebruikt ga je problemen krijgen qua performance.
Dus dat is niet aan te raden.
Voor de datalijnen is onder andere je budget een limiet.

[Verwijderd]

Leesvoer:
http://www.microsoft.com/...ivedirectory/default.mspx

_{maar die had je natuurlijk zelf ook al gevonden, want de MS site is natuurlijk je eerste stop voor informatie}

[perryodk]

ShellGhost schreef op woensdag 12 oktober 2005 @ 13:27:
Voor de server, zeker de DC heb je wel een leuke bak nodig, aangezien die als root moet gaan werken.
Wanneer je een p3 500 met 512 gebruikt ga je problemen krijgen qua performance.
Dus dat is niet aan te raden.

Dat snap, maar er komt als het goed is ook andere apparatuur als het goed is 2 servers (DC1 en DC2+backup DC) met daarin 2 processoren, 8GB ram en veel schijfruimte . Dus de hardware komt wel goed .

[Question Mark]

ShellGhost schreef op woensdag 12 oktober 2005 @ 13:27:
Voor de server, zeker de DC heb je wel een leuke bak nodig, aangezien die als root moet gaan werken.
Wanneer je een p3 500 met 512 gebruikt ga je problemen krijgen qua performance.
Dus dat is niet aan te raden.

Onzin, alle DC's op mijn werk zijn ML370's (P3 733 met 512 MB geheugen) in een forest met 3 domeinen en ongeveer 6000 objecten in het forest. Deze machines staan de hele dag uit hun neus te eten...

In de Sizing Guidelines for Windows 2000 Domain Controller and Global Catalog Server staat ook vermeld dan een single P3 500 met 512 MB memory tussen de 20 en 30 logons kan verwerken per seconde. MS meldt in de guide dat het aantal logons bekeken moet worden in een interval van 10 minuten. Als ik dit doorreken, dan kom ik op 15.000 logons. Da's ruim meer dan de 5000 medewerkers die in jullie netwerkomgeving aanwezig zijn.

perryodk schreef op woensdag 12 oktober 2005 @ 13:22:
Op een DC zouden max 500 gebruikers kunnen en dan zou je als minimum een P3 500MHz en 512mb RAM kunnen gebruiken. Maar als we over het hele domein praten: ongeveer 5000 gebruikers moet je een iets krachtiger server aanschaffen

Hangt van de situatie af. Zitten die 5000 users verdeelt over 10 sites, met op elke site één DC. Dan heeft elke DC slechts 500 logons te verwerken en dan voldoet in principe een P3. Zitten deze 5000 users op dezelfde site, dan neem ik aan dat er meer dan 1 DC geplaatst wordt. Je kunt ivm redundantie sowieso beter meerdere (kleinere) DC's plaatsen dan één zware.

[ Voor 40% gewijzigd door Question Mark op 12-10-2005 14:32 ]

[perryodk]

Hangt van de situatie af. Zitten die 5000 users verdeelt over 10 sites, met op elke site één DC. Dan heeft elke DC slechts 500 logons te verwerken en dan voldoet in principe een P3. Zitten deze 5000 users op dezelfde site, dan neem ik aan dat er meer dan 1 DC geplaatst wordt. Je kunt ivm redundantie sowieso beter meerdere (kleinere) DC's plaatsen dan één zware.

Het kunnen ook wat minder gebruikers zijn maar er zijn in ieder geval 37 vestigingen (dus 37 sites), het plan is nu om per site 2 computers te gebruiken, en op de computers dmw vmware esx meerdere virituele systemen te draaien. Vandaar de redelijk zware specificaties. DC1 op comp1 en DC2 comp2 (2 DC's voor redunantie). Exchange server, ftp en vpn moet ook allemaal geintegreerd worden.

[ Voor 7% gewijzigd door perryodk op 12-10-2005 14:39 ]

[Question Mark]

perryodk schreef op woensdag 12 oktober 2005 @ 14:35:
[...]


Het kunnen ook wat minder gebruikers zijn maar er zijn in ieder geval 37 vestigingen (dus 37 sites), het plan is nu om per site 2 computers te gebruiken, en op de computers dmw vmware esx meerdere virituele systemen te draaien. DC1 op comp1 en DC2 comp2 (2 DC's voor redunantie). Exchange server, ftp en vpn moet ook allemaal geintegreerd worden.

Maak voor de gein eens een overzichtje van verwachte licentiekosten
Wat is de redenatie eigenlijk achter twee keer ESX op elke site. Dit kost je 74x een ESX licentie. Waarom niet gewoon op elke site één DC (Global Catalog of gebruik maken van Universal Group Caching). Dan heb je ook die zware systemen niet nodig...

Valt deze uit, dan worden de users wel door een DC op een andere site gevalideerd.

[ Voor 10% gewijzigd door Question Mark op 12-10-2005 14:48 ]

[perryodk]

Question Mark schreef op woensdag 12 oktober 2005 @ 14:41:
[...]
Waarom niet gewoon op elke site één DC (Global Catalog of gebruik maken van Universal Group Caching). Dan heb je ook die zware systemen niet nodig...

Valt deze uit, dan worden de users wel door een DC op een andere site gevalideerd.

Dat is nou juist de vraag waar wij hier nog mee zitten, wat willen wij liever?:

• Zwaardere internetlijn om als datapijp te gebruiken, om alles over en heen te kopieren en dus iedere DC gelijk aan de andere en dus veel internetverkeer en netwerkverkeer en belasting.
• 2 DC's op iedere locatie voor de redunantie en geen gegevens enz uitwisselen tussen de site's. Wat veel netwerkbelasting en verkeer bespaart.

[ Voor 5% gewijzigd door perryodk op 12-10-2005 15:09 ]

[perryodk]

We zijn er inmiddels uit, bedankt voor de reacties

[Question Mark]

perryodk schreef op woensdag 12 oktober 2005 @ 15:00:
[...]
• 2 DC's op iedere locatie voor de redunantie en geen gegevens enz uitwisselen tussen de site's. Wat veel netwerkbelasting en verkeer bespaart.
[/list]

Je zegt wel dat jullie eruit zijn, maar aan bovenstaande te zien denk ik dat er nog enkele begrippen niet geheel duidelijk zijn. 't zou zonde zijn als jullie voor een architectuur kiezen, welke later niet de juiste blijkt te zijn (no offence overigens).

Het maakt nl. niet uit hoeveel DC's in een site geplaatst worden. Staan deze sites in hetzelfde forest, dan zal er altijd intersite replicatie plaatsvinden. Tenminste als er GC's in elke site staan, in W2K3 is er nog de optie tot Universal Group Caching.

Afhankelijk van je AD-layout, site-layout, snelheid van verbinding en het aantal users op een site, wordt de beslissing genomen voor het implenteren van Group Caching of het plaatsen van een GC in de site. En geloof me, als je dit goed wilt doen, dan kost het maken van een dergelijk architectuurplaatje enige tijd. Daarom verbaast het me ook dat je nu ineen keer meld dat al je vragen beantwoord zijn

Ga je van elke site een seperaat domain maken, dan ga je ook nog eens problemen krijgen als users toegang moeten krijgen tot resources in een ander domain. Met 37 verschillende domainen loopt je validatiepad nl. ontzettend beroerd. Je zult om validatie te versnellen dan al gauw gebruik moeten maken van een shortcut-trust. En da's ook niet eenvoudig te onderhouden met 37 domeinen.

Mijn advies op architectuurgebied:

Als er geen politieke redenen zijn om netwerken gescheiden te houden gewoon uitgaan van één enkel domein, één DC op elke site en deze Global Catalog maken. Afhankelijk van de verschillende lijnsnelheden de replicatie-tijden van de site-links aanpassen (langzame verbinding, bv maar één keer per uur laten repliceren).

De hoeveelheid netwerkverkeer bij AD-replicatie stelt nl. echt niet zoveel voor. De initiele replicatie is het grootst (deze kan bij W2K3 zelfs nog van een backup uitgevoerd worden). Voor de rest worden alleen de gewijzigde object-attributen gerepliceerd, niet eens de gewijzigde objecten.