File Replicatie, file server -> Calamiteiten server, DFS?

[Abom]

Ik zal de situatie en wens even in het kort beschrijven.

Binnenkort zal ons serverpark in 2'en gedeeld worden (1 DC en Citrix servers op beide vestigingen).
Nu zou ik graag een SATA-raid based server op de tweede vestiging wil plaatsen. Omdat het hier om een SATA server gaat, wil ik deze alleen in productie nemen wanneer het nodig is. Wat ik wel wil, is dat de server ons uit de brand kan helpen, bij ernstige calamiteiten (dit is ook het idee achter het opsplitsen van het serverpark).

Nu is dus mijn vraag:
Wat is de beste manier van het repliceren van de data van de File & Print server naar de 'calamiteiten server'?

Aantal details:

- Tussen beide vestigingen ligt een 1 gigabit verbinding en dat is meer dan voldoende door het gebruik van thin clients (meeste netwerk belasting vind plaats aan de backend, server <-> server verbindingen dus)
- De FP server is zwaar genoeg voor de gehele omgeving, ik heb geen extra performance nodig van een extra SATA server.
- File server is een cluster met 2 nodes.

---

Mijn idee:

DFS - Gebruik DFS alleen voor het repliceren van de data van de een naar de andere server. Helaas heb ik alleen ervaring met DFS in mijn eigen test omgeving. Is het mogelijk (dmv load evaluators), wel gebruik te maken van DFS verwijzingen, maar voorkomen dat medewerkers actief gaan werken op de 'calamiteiten-server'?

---

Hoe zit het met Robocopy? Is dat een betere optie of kun je dat het beste buiten werktijd schedulen? (Buiten werktijd houd dus in dat je een dag terug moet, dan zou onze backup faciliteit voldoende zekerheid geven).

---

Ik ben al tegen het eerste probleem opgelopen tijdens het opzetten van een test DFS:
Het lijkt erop dat het niet mogelijk is om een 'domain root' aan te maken op een cluster. Het is alleen mogelijk om een 'stand-alone root' aan te maken en deze vervolgens te publiceren in Active Directory.
Stand-alone roots kunnen dus niet gerepliceerd worden.

Eens kijken of het mogelijk is om op beide cluster nodes dezelfde directory als DFS root aan te maken. Wanneer ik het goed begrijp, zorgt DFS er dan voor dat de node die op dat moment die share niet heeft gewoon niet gebruikt wordt.

[ Voor 29% gewijzigd door Abom op 19-04-2004 13:02 ]

[vso]

de root kan niet op meerdere servers bestaan echter het gaat niet om de root maar meer om de shared data,

maar de DFS root zou je al op een zeer klein desktop pc'tje kunnen hosten (die kan je binnen 15 min al weer up and running hebben. (of een hot spare ergens neer zetten)

de uiteindelijke share(s) die host je gewoon op beide locaties, DFS zorgt voor de fault-tollerance d.m.f

de data wordt via je AD replicatie ge-repliceerd dus die 1 GB data lijn is geen overbodige Luxe,

[Abom]

VSO: ik zoek niet echt iets voor faul-tolerance. Eigenlijk heb ik alleen FRS nodig en wel van een machine naar de andere en niet andersom (tenzij handmatig uitgevoerd). Maar volgens MS kun je FRS alleen gebruiken dmv DFS (met uitzondering van SYSVOL).

Het is dus wel mogelijk om DFS in te richten op de losse cluster nodes. Volgens mij is dit zelfs allemaal volgens design. Wanneer er een root link gemaakt wordt op een cluster node en je richt vervolgens de replicatie in, dan komt je FRS-staging directory standaard op je Quorum Disk, zodat replicatie bestanden goed meegenomen worden bij een fail-over.

Alleen ben ik er geen grote fan van om zoiets op mijn quorum disk te laten doen. Ik vind het soieso een beetje teveel 'gehack'. Ik denk dat ik eerst iets beter ga kijken naar robocopy, het grootste nadeel van robocopy is dat de gehele directory structuur nagelopen moet worden, maar dat moet te doen zijn wanneer ik het 2-4 keer per dag laat lopen.

---

Een update:

Ik heb de manier gevonden die ik ga gebruiken, toch DFS. MS zelf geeft ook aan dat een DFS domain root geen cluster resource kan zijn en adviseerd daarom de DFS links direct aan te maken op een cluster nodes.

Zoals VSO al opmerkte: DFS zal dan zorgen dat het blijft werken wanneer de node van de file server failed, wanneer je op alle node(s) de link aan hebt gemaakt en de betreffende logical drive een cluster resource is. In je DFS zie je dus altijd 1 actieve link voor je cluster, namelijk van die node die je logical disk host op dat moment (doordat de logical drive niet beschikbaar is op de andere node(s)).

Vervolgens richt ik de replicatie zo in dat er alleen van de nodes naar de 'calamiteiten server' gerepliceerd kan worden en niet nodes onderling repliceren (omdat de nodes dezelfde schijven ter beschikking hebben).

Over de FRS-Staging directory op de quorum disk, dit is opzich geen probleem aangezien er default een limiet staat op je frs-staging dir, namelijk 660mb (dit kun je aanpassen).

---

Volgende update (lol):

Ik heb het beschreven verhaaltje hierboven opgezet en enkele tests gedaan...het liep al snel fout.

Het aanmaken van dezelfde lokale directory op 2 nodes, de manier die ik hierboven beschreven heb, werkt niet goed met DFS. Om een of andere reden wil hij niet meer repliceren wanneer er een fail-over heeft plaats gevonden op de File Server cluster group.
Microsoft adviseerd dit wel, maar er staat nergens bij dat het mogelijk is om deze opzet goed werkend te krijgen icm een logical disk als cluster resource.

Uiteindelijk is het dus niet goed bruikbaar; DFS op een logical disk van de cluster wat in een Cluster Resource zit.

Ik ben nu naar Robocopy aan het kijken en dat is toch erg interesant. Vanaf versie XP010, is er ook een mogelijkheid om de source directory te monitoren en na x veranderingen en/of x minuten de veranderingen door te sturen naar de destination.

Ik ga hier even verder mee

[ Voor 111% gewijzigd door Abom op 23-04-2004 18:26 ]