Optimaal NDS-ontwerp voor WAN structuur?

[mr_a]

Deze post plaats ik hier omdat dit een vaak voorkomend ontwerp-issue is, en ik graag wil weten hoe collega tweakers het aanpakken. Ik heb zelf een aantal jaar ervaring als beheerder, en heb gedurende deze periode bij meerdere klanten verschillende ontwerpen gezien, waar ik er hier twee uit ligt omdat ik ze 'goed' vindt.

De basisprincipes van partitie- & replica-ontwerp 'volgens Novell' zijn in beide vertegenwoordigd, maar de uitwerking is iets anders. Aan beide opties kleven voor en nadelen, en ik kan maar niet verzinnen welke nou de 'betere' is. Als jullie hier dus ideëen over hebben, dan hou ik me aanbevolen!

Partitieontwerp:

Het partitieontwerp voorziet in 1 partitie per locatie. Dus iedere WAN link is een partition boundary.

code:

T ---  O                            <- partitie1
     |
     + --- OU1 voor centrale vestiging.  <- partitie2
     |   
     + --- OU2 voor andere locatie2, 1    <- partitie3
     |
    enz.                             enz

Replicastructuur:

Voor de replicastructuur hierbinnen zijn er meerder mogelijkheden. Basisprincipe is 'plaats de data waar zij nodig is', dat wil zeggen dat het merendeel van de replicaservers zich op de locatie waar de partitie voor aangemaakt is moeten bevinden.

Optie 1: centrale structuur

De centrale omgeving heeft de volledige replicaring van de Organization partitie, en in ieder geval de of een Master of een RW replica van alle locatie-partities. De netwerken van de locaties hebben elk de volledige replicaring, min dus 1 replica, die centraal staat.

Voordelen:
- Snelle synchronisatie tussen alle partities omdat van alle partities tenminste één replica server op het centrale LAN zit. Dus ook snelle access tot resources in andere partities, tree-walking is snel.

Nadelen:
- Synchronisatie van iedere partitie van WAN locaties gaat traag vanwege de WAN link in de replica ring.
- Ontstaan van Inconsistenties bij problemen WAN verbinding.


Optie 2: decentrale structuur

De centrale omgeving heeft Master replica's van hoofdpartitie.
WAN locaties hebben de complete replicaring van de WAN partitie lokaal
Centraal bevindt zich 1 R/O replica uit de replicaring van de WAN.

Voordeel:
betere en snellere NDS synchronisatie op de locatie waar de data moet zijn. Dus minder mogelijkheden tot fouten en inconsistentie.

Nadeel:
Centrale omgeving hebben onvoldoende mogelijkheid resources snel te 'pinpointen', dit is een issue bij tree walking, wat nu veel trager gaat.


Dus nu, kom maar op met je kritiek/op-/aanmerkingen & aanvullingen!!


edit: niet goed gepost, nu wel goed. trouwens de topictitle is getrunceerd, het laatste woord moet uiteraard zijn 'structuur'.

[Predator]

titel changed on request

[mr_a]

Op donderdag 30 mei 2002 19:52 schreef Predator het volgende:
titel changed on request

Dank! Biertje krijg je virtueel, hier, proost!

[Verwijderd]

Op woensdag 29 mei 2002 22:13 schreef mr_a het volgende:
Ik heb zelf een aantal jaar ervaring als beheerder, en heb gedurende deze periode bij meerdere klanten verschillende ontwerpen gezien, waar ik er hier twee uit ligt omdat ik ze 'goed' vindt.

Voor elk type bedrijf is een andere structuur goed. Er is geen template wat je overal kan gebruiken.

Centraal bevindt zich 1 R/O replica uit de replicaring van de WAN.

Novell zegt zelf over Read-Only Replicas: Niet doen! Zeker in dit geval waar het beheer waarschijnlijk centraal gebeurt levert dit mucho problemo op.

Het nadeel aan je ontwerp is dat als je ZEN gebruikt je alle applicatie objecten naar alle vestigingen moet kopieren en bijwerken. Dat is monikkenwerk, ook met de kopieertools die voorhanden zijn. Naar mijn idee is het beter om vestigingen te groeperen in Regio's oid. En dan per regio een partitie te maken en die voorzien van ZEN objecten.

[mr_a]

Op vrijdag 31 mei 2002 10:23 schreef Bagger het volgende:

[..]

Voor elk type bedrijf is een andere structuur goed. Er is geen template wat je overal kan gebruiken.
[..]

dat is waarheid

Novell zegt zelf over Read-Only Replicas: Niet doen! Zeker in dit geval waar het beheer waarschijnlijk centraal gebeurt levert dit mucho problemo op.

Juist ja, dat kan ik me op zich wel voorstellen. Zo zinnig zijn ze ook niet, IMO. Ik ben een beetje uitgegaan van decentraal beheer. Dat heb ik tot nu toe gezien. Als er inderdaad altijd centraal beheerd wordt werkt dit waarschijnlijk slecht, dat ben ik met je eens.

Het nadeel aan je ontwerp is dat als je ZEN gebruikt je alle applicatie objecten naar alle vestigingen moet kopieren en bijwerken. Dat is monikkenwerk, ook met de kopieertools die voorhanden zijn. Naar mijn idee is het beter om vestigingen te groeperen in Regio's oid. En dan per regio een partitie te maken en die voorzien van ZEN objecten.

Bij mijn huidige klant hebben we een aantal belangrijke applicatieobjecten centraal staan, verwijzend naar files op lokale servers.
Dit werkt over het algemeen prima maar wel heel erg traag! Eindgebruikers die een centraal applicatieobject gebruiken moeten eerst 5 minuten wachten voordat de nal er is, en daarna is het nog niet snel. Dus dit is niet heel fijn.
Van de partitie waar deze applicatieobjecten staan hebben we read only replica's op de locaties. Dat blijkt inderdaad vrij zinloos, maar waarom precies? Nu hebben we een aantal locaties een RW replica van deze partitie gegeven, mucho better. Maar waar een RO replica dan wel voor geschikt is..

Je idee van regio's is denk ik alleen verstandig als de WAN structuur ook zo is. Bij ons hebben we een stervormig netwerk, dus ik weet niet of dat zinnig is...

$0.02

[Verwijderd]

Zet alles wat door alle vestigingen gebruikt wordt hoog in de tree. Hierbij denk ik aan SLP, DNS, DHCP, ZEN apps. / policies etc. Maak daarvan een partitie en zet overal R/W replica's neer. Dus alle centrale dingen dankzij replica op lokatie. Maak ook een container package met een search policy om het zoeken te bepereken, dus versnellen.

Applicatie objecten die iets opstarten op de lokale pc, kunnen centraal staan. Objecten die naar een server verwijzen moet je per vestiging doen, of op iedere vestiging dezelfde driveletter mappen naar de lokale server en het app. object de app. vanaf die driveletter laten starten.

Read-Only kun je gebruiken voor (LDAP) queries zoals e-guide.