DFS contra Cluster -> Hochverfügbarkeit von Dateien

[Shao-Lee 11]

Hallo Mitstreiter !

 

Nehmen wir folgendes Szenario:

Ich habe eine Server-Farm bestehend aus 2 DC's (Win2k3) und einem File-Server (Win2k3) als

Mitgliedsserver (Raid-System).

 

Auf diesem File-Server liegen 200 GB an Daten, welche für die an der Domäne angemeldeten

User hochverfügbar sein müssen (Backbone = GigaBit).

Fällt das Raid-System aus, steht der Betrieb.

 

Nun meine Idee für eine Notlösung im Falle des WorstCase:

Win2k3 bietet von Haus aus ja den DFS-Dienst an, mit welchem ich Serververzeichnisse

auf anderen Maschinen innnerhalb des Netzwerkes abbilden (replizieren) kann.

Theoretisch könnte ich hergehen und in einen meiner DC's eine entsprechende HD

reinhängen und DFS für den FileServer in der Art konfigurieren, dass er alle Files auf

diese eine HD im DC repliziert.

Die User sehen nur den Laufwerksbuchstaben und bekommen im Grunde nicht mit,

wenn das eine oder andere System ausfällt (bis auf die deutlichen Geschwindigkeitseinbußen,

welcher ein Ausfall des Raid-Systems mit sich bringen würde).

 

Vorteile / Nachteile dieser Lösung:

a.) Das System verursacht ordentlich Traffic - sollte aber mit GigaBit-NW kein Problem

darstellen

b.) DFS orientiert sich an der Schreibgeschwindigkeit der HD im DC, wodurch möglicher-

weise auch das Raid-System im laufenden Betrieb sehr langsam wird (?)

c.) Kostengünstige Lösung für Aufrechterhaltung des Betriebes im Falle eines WorstCase

 

Was haltet ihr von dieser grundsätzlichen Idee und welchen entscheidenden Vorteil würde

demgegenüber ein Cluster-System für den File-Server mit sich bringen ?

Nachteil der Cluster-Lösung: Sehr hohe Investitionskosten.

 

Für Eure Beiträge möchte ich mich bereits im Vorfeld herzlich bedanken.

 

Grüssle,

Shao-Lee

[R.Ralle 10]

Hi,

 

Also, ich glaube, dass du alles gesagt hast.

 

 

ich sage, dass ein sauberes DFS die bessere lösung für en Fileserver ist!

 

Ralph

[klausk 10]

Nachteile der DFS-Lösung:

- Anwender arbeiten mal mit den Daten vom Filserver, mal mit den Daten vom DC -> das kann zu Konflikten führen, wenn die gleiche Datei an beiden Stellen geändert wird.

- Die Replikation braucht Zeit, das kann zu Verwirrung bei Anwendern führen, wenn z.B. Daten gelöscht werden diese aber noch angezeigt werden, bis sie auf der 2 Platte auch gelöscht sind.

- Bei großen Datenmengen/hohe Anzahl an Dateien neigt DFS zu Fehlern

 

Welche Verfügbarkeit muss denn garantiert werden?

[Shao-Lee 11]

Hallo zusammen - Herzlichen Dank für Eure Antworten.

 

Ja, dass stimmt - braucht einige Zeit, bis die Replikation abgeschlossen ist.

Man kann zwar den Replikationszyklus zeitlich stark herunterschrauben (Replikation

innerhalb 2 Sek.), aber es braucht eben Zeit (und da orientiert sich DFS am schwächsten

Glied der Kette... )

 

Ziel ist eine 100%-Verfügbarkeit, die auch finanzierbar ist.

 

Wenn die Daten nur von einer einzigen Datenquelle zur Verfügung gestellt werden

(wenn auch Raid-System), und diese Quelle steht aufgrund eines Hardware-Defekts,

kann sich aufgrund der technischen Komplexität dieses Systems eine Reparatur über

2 bis 5 Tagen hinziehen.

Das Backup (Files) auf Tape könnte zwar kurzfristig auf den DC eingesspielt werden,

aber das kosten Zeit und ist nur eine Übergangslösung für den WorstCase.

 

Das DFS erschien uns der richtige Ansatz (zusätzlich zum Backup versteht sich) -

aber die angesprochenen Nachteile sprechen auch für sich.

 

Ein Cluster wäre sicherlich die Optimale Strategie für eine "Hochverfügbarkeit", hat aber

einen eklatanten Nachteil: sie erfordert eine hohe Investition in eine neue Maschine -

und wir bekämen "Beiwerk", welches wir nicht wirklich brauchen, da es sich

a.) um reine Files handelt (eben diese 200 GB)

b.) keine riesen Datenbank gehandelt werden muss (worauf ein Cluster ja ausgelegt ist)

 

....und eine Kompromißlösung zwischen DFS und Cluster gibt es meines Wissens nicht, oder ?

 

Grüssle,

Shao-Lee

[Stefan H. 10]

Sehr interessantes Thema, deswegen will ich mal meine Überlegungen dazu in die Runde werfen.

 

Es glaube auch, dass das DFS mit der Replikation in diesem Fall genug Möglichkeiten bieten würde. Zumindest theoretisch.

 

Allerdings wird ein Einsatz in der Praxis durch die schon angesprochenen Probleme (Verwirrung der User, da man keine Kontrolle hat, welcher User auf dem Fileserver und welcher auf dem DC arbeitet) sehr schwierig.

 

Deswegen mein, zugegeben etwas exotischer und vielleicht auch praxisfremder Ansatz. Es handelt sich aber nur um theoretische Überlegungen, bei der ich vielleicht den einen oder anderen Punkt vergesse:

 

Verbinde die User nicht direkt auf die Freigabe des DFS, sondern auf die des Fileserver. Damit ist sicher gestellt, das die User immer auf dem Fileserver arbeiten. Trotzdem DFS mit Replikation konfigurieren.

- damit hast du im Falle des Ausfalls des Fileservers immer ein zweites lauffähiges System, nämlich den DC.

- Die User müssten beim Ausfall des Fileservers dann nur noch ein Script ausführen, was die Freigabe des DC einbindet. Evtl. das Logon-Script ändern, und einfach ab- und wieder anmelden. Noch weiter gedacth, das Logon-Script so ändern, das es beim ausführen prüft, ob der Fileserver verfügbar ist. Ist das nicht der Fall, wird automatisch der DC eingebunden…

 

mfg

Stefan

[klausk 10]

...Ziel ist eine 100%-Verfügbarkeit, die auch finanzierbar ist...

Nenn mal eine realistische akzeptierte Verfügbarkeit. :rolleyes: Sind sonst alle weiteren Komponenten des Netzwerkes redundant aufgebaut? Nicht nur das RAID kann ausfallen...

[Shao-Lee 11]

Hallo Klaus !

Du hast recht - es gibt keine 100%-Verfügbarkeit. Letztendlich kann der Strom ausfallen

(durch einen Leitungsdefekt) - sowas nenne ich dann "höhere Gewalt".

 

Nein, die anderen Komponenten (bis auf die Tatsache, dass zwei DC's ihre Arbeit ver-

richten) sind ebenfalls nicht redundant aufgebaut. Ein Ausfall eines der übrigen Systeme

ist auch eher verschmerzbar (für kurze Zeit kein Zugriff auf eMails / Intranet).

Wichtig: die User müssen sich anmelden können und Verbindung zum Fileserver erhalten.

 

Der Hase liegt somit in diesem besagten File-Server "im Pfeffer".

 

Für einen Entwicklungsprozess müssen diese Daten einfach zur Verfügung stehen.

Die Tape-Sicherung brauche ich, um nach einem Crash und dem ggf. neu aufgesetzten

Raid-System wieder die Daten einzuspielen (könnte mit einer Image-Lösung beschleunigt

werden).

Da das Raid-System schon einige Jahre am laufen ist, beschäftige ich mich mit der Frage,

was wäre, wenn das Raid-System durch einen Hardware-Defekt einen Totalausfall hat

und ggf. Ersetzt werden muss. Dann ist "Schicht im Schacht".

 

@Stefan:

Sehr guter Ansatzpunkt ! Dadurch liese sich theoretisch eine eklatante Schwäche des DFS

ausschaulten *überleg*

 

Danke für Eure konstruktiven Diskussionsbeiträge :-)

 

Shao-Lee

[lefg 276]

Hallo,

 

DFS ist doch nicht zur Hochverfügbarkeit gedacht und auch nicht geeignet; oder? Ich habe da meine Zweifel. Ist Hochverfügbarkeit ohne Cluster wirklich machbar? Ich kann mich an einer GAU bei einem Telekommunikationsanbieter in Schleswig-Holstein erinnern. Bei dem lag alles still(und das nicht nur 10 Minuten). Erst danach haben die sich externen Beratung und Support von aussen geholt und etwas funktionieredes bauen lassen. Sie hatten wohl nicht die richtigen Leute und der Chef soll auch nicht einfach gewesen sein.

 

Gruß

Edgar

[Shao-Lee 11]

Hi Edgar !

 

...und genau dafür ist DFS (Hochverfügbarkeit & Clustering von Dateien) im Win2k3Server aber

tatsächlich ausgelegt !

 

Quelle:

http://www1.microsoft.at/includes/Image.aspx?type=1&ID=6126

 

Shao-Lee

[lefg 276]

Weiterhin verbessert DFS die Skalierbarkeit, einerseits durch das vereinfachte Hinzufügen von Dateiservern, andererseits durch den Lastenausgleich zwischen Servern. Der Dateizugriff durch einen Benutzer wird hierbei nicht unterbrochen. Windows Server 2003 erhöht die Zuverlässigkeit von DFS durch die Möglichkeit, auf einem Server mehrere DFS-Stammverzeichnisse zu Verfügung zu stellen. Dies bedeutet, dass DFS nun für Hochverfügbarkeit und Lastenausgleich geclustert werden kann.

Muss dafür nicht erst ein Cluster vorhanden sein?

[carlito 10]

Nein, die anderen Komponenten (bis auf die Tatsache, dass zwei DC's ihre Arbeit ver-

richten) sind ebenfalls nicht redundant aufgebaut. Ein Ausfall eines der übrigen Systeme

ist auch eher verschmerzbar (für kurze Zeit kein Zugriff auf eMails / Intranet).

 

Na ja, und wenn die aktiven Netzwerkkomponenten ausfallen?

[Shao-Lee 11]

*am-Kopf-kratz* ;)

-Sorry- ... stimmt; klingt irgendwie logisch ("wer lesen kann, ist klar im Vorteil").

 

Also - ich habe jetzt nochmals ausgibig im Internet recherchiert zum Thema "DFS".

DFS hört sich theoretisch sehr wertvoll an, praktisch scheint es jedoch das eine bzw.

andere Problem zu verursachen.

DFS haben wir bereits im Einsatz und läuft zumindest als Dienst für gemappte Quellen

einwandfrei.

 

DFS als Ersatz für einen Cluster (rein für replizierende Daten / Files) klingt einfach zu

verlockend :D

Zumindest wenn aber die User durch das DFS auf getrennten Systemen arbeiten, ist

dieser Dienst unbrauchbar und macht Probleme (da gibt es zwischenzeitlich zahlreiche

Beiträge im Internet).

Stefan hat einen guten Ansatz geliefert - das müsste man mal in der Praxis testen.

 

Fazit:

-> Ein Cluster vom File-Server wäre eine sauber Lösung

-> DFS ist nicht unproblematisch / ob für Hochverfügbarkeit ausgerichtet -> eher fraglich

 

Wäre abschließend zu klären, ob eine alternative, brauchbare Lösung (auch von 3.

Herstellern) gibt ?

 

@carlito:

Heutzutage sollte ein Switch doch deutlich schneller zu beschaffen sein, als ein Raid-System ;)

...und mit einem gewissen Restrisiko müssen wohl wir alle leben.

 

So long,

Shao-Lee

[carlito 10]

Heutzutage sollte ein Switch doch deutlich schneller zu beschaffen sein, als ein Raid-System ;)

 

Klar, ich wollte nur darauf aufmerksam machen, das wenn nahezu 100% Verfügbarkeit verlangt wird, noch so viele Cluster Server nichts bringen, wenn die Infrastruktur - sprich ein simpler Switch - ausfällt.

 

...und mit einem gewissen Restrisiko müssen wohl wir alle leben.

 

No risk, no fun! ;)

[lefg 276]

Wollen wir es ein wenig auf die Spitze treiben? :D

 

Denken wir mal an Multihoming. Jeder Client hat mit mindestens zwei Interfaces die Füße in zwei Netzen oder an verschiedenen Knoten eines Netzes.

 

Bei Clustern bauen wir noch ein wenig mehr dazu. Da macht denn der Ausfall eines Swtches nichts.

[carlito 10]

Denken wir mal an Multihoming. Jeder Client hat mit mindestens zwei Interfaces die Füße in zwei Netzen oder an verschiedenen Knoten eines Netzes.

 

Das wäre ein Idee. Zwei NICs in jeden Server und diese an unterschiedliche Switches/Router angeschlossen...