ISCSI Failover. Fragen
Hallo und frohes neues Jahr an alle...
Ich habe in meinem Lab erfolgreich ein Hyper-V Cluster mit iSCSI Storage und MPIO eingerichtet.
2 Hyper-V Nodes und 1 File-Server(iSCSI Target)
Alles über 2*2 10Gbit Leitungen. Funtz prima...
Wenn ein Hyper-V Node ausfällt, ist ja soweit klar was dann passiert. Der zweite Server übernimmt..
Was ABER wenn mein File-Server ausfällt??? Wie kann ich den Clustern, also hochverfügbar machen, failover...
Hab schon bisschen was über Shared Storage gelesen, blick aber nicht wirklich durch.
Hat wer eine Idee oder Anhaltspunkte für mich??
Ich habe in meinem Lab erfolgreich ein Hyper-V Cluster mit iSCSI Storage und MPIO eingerichtet.
2 Hyper-V Nodes und 1 File-Server(iSCSI Target)
Alles über 2*2 10Gbit Leitungen. Funtz prima...
Wenn ein Hyper-V Node ausfällt, ist ja soweit klar was dann passiert. Der zweite Server übernimmt..
Was ABER wenn mein File-Server ausfällt??? Wie kann ich den Clustern, also hochverfügbar machen, failover...
Hab schon bisschen was über Shared Storage gelesen, blick aber nicht wirklich durch.
Hat wer eine Idee oder Anhaltspunkte für mich??
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1693289185
Url: https://administrator.de/contentid/1693289185
Ausgedruckt am: 21.11.2024 um 18:11 Uhr
31 Kommentare
Neuester Kommentar
Hallo,
Varianten gibt es viele, je nach Bedarf.
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/ ...
Varianten gibt es viele, je nach Bedarf.
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/ ...
Ist das PDF auf das ganz am Anfang verwiesen wird.
https://www.heinlein-support.de/schulung/ceph-grundlagen
oder Direkt
https://download.heinlein-akademie.de/?type=info&id=368
kannst auch mal nach Storage Virtualisierung suchen
gibt aber noch genügend andere Alternativen
https://www.heinlein-support.de/schulung/ceph-grundlagen
oder Direkt
https://download.heinlein-akademie.de/?type=info&id=368
kannst auch mal nach Storage Virtualisierung suchen
gibt aber noch genügend andere Alternativen
Moin,
ich meine ein Scale-Out Fileserver löst dein Problem.
Ein bisschen Lesestoff für den morgigen Feiertag: Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016
Gruß,
Dani
ich meine ein Scale-Out Fileserver löst dein Problem.
Ein bisschen Lesestoff für den morgigen Feiertag: Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016
Gruß,
Dani
Zitat von @Ueba3ba:
Eigentlich ganz einfach. Also müsste ja eine Spiegelung der beiden File-Server aufeinander stattfinden.
Wie realisiere ich das den nun. Ich frag ganz einfach nur nach Stichwoten und/oder Anhaltspunkten.
Wie realisiere ich das den nun. Ich frag ganz einfach nur nach Stichwoten und/oder Anhaltspunkten.
WSFC, S2D, SOFS
Zitat von @Dani:
Moin,
ich meine ein Scale-Out Fileserver löst dein Problem.
Ein bisschen Lesestoff für den morgigen Feiertag: Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016
Gruß,
Dani
Moin,
ich meine ein Scale-Out Fileserver löst dein Problem.
Ein bisschen Lesestoff für den morgigen Feiertag: Installation und Konfiguration von einem Hyper-V Failover Cluster mit Windows Server 2016
Gruß,
Dani
Bisschen OT: Der 6. Januar ist nur in drei Bundesländern in Deutschland ein gesetzlicher Feiertag: Bayern. Baden-Württemberg. Sachsen-Anhalt.
Bei der Umgebung ist die Lösung mit 2 Flash Synologys glaube ich am günstigsten und sehr schnell umgesetzt.
Zitat von @Ex0r2k16:
Bei der Umgebung ist die Lösung mit 2 Flash Synologys glaube ich am günstigsten und sehr schnell umgesetzt.
Bei der Umgebung ist die Lösung mit 2 Flash Synologys glaube ich am günstigsten und sehr schnell umgesetzt.
Moin,
denke ich auch.
Hier dann noch eine Anleitung
https://kb.synology.com/de-de/DSM/tutorial/How_to_create_a_high_availabi ...
Ein Problem hast du aber dann trotzdem noch: Splitbrain.
Bleiben wir mal bei dem Synology-Beispiel: du hast zwei Hosts und zwei NAS/ SANs in getrennten Räumen. Im Normalfall sehen sich alle Geräte. Nun bricht dir (durch einen Bagger) das Kabel zwischen beiden Räumen weg, sodass theoretisch in beiden Räumen der Host ond das NAS autark sind. Beide Seiten denken nun, sie seien die Einzig überlebenden....
SPäter, wenn du das Kabel ersetzt/ repariert hast, hast du unterschiedliche Stände: auf welchem NAS sind die Daten nun richtiger?
Hier hat aber Synology zumindest ein KB-Artikel zu:
https://kb.synology.com/de-de/DSM/tutorial/What_should_I_do_if_there_is_ ...
Also in der Theorie kann man ne ganze Menge machen aber in der Praxis muss man grade für kleinere Umgebungen ja auch mal die Kirche im Dorf lassen. Wir haben z.B. zwei NetApp, Aktiv-Passiv gespiegelt. Bricht die eine weg kommt der Admin und ändert die IP der anderen und es geht erstmal wieder. Das schöne dran ist das es sich in vielen Umgebungen zu vertretbaren Kosten umsetzen läßt, das müsste auch in Windows only gehen.
Zusätzlich kommt dann noch die Hardware-seitige Redundanz in SAN Geräten was Netzteile, HBA, und DP SAS angeht. Das hast du natürlich bei einem Windows System so erstmal nicht.
Zusätzlich kommt dann noch die Hardware-seitige Redundanz in SAN Geräten was Netzteile, HBA, und DP SAS angeht. Das hast du natürlich bei einem Windows System so erstmal nicht.
@bloodstix
@Ex0r2k16
@em-pie
@ukulele-7
Gruß,
Dani
Bisschen OT: Der 6. Januar ist nur in drei Bundesländern in Deutschland ein gesetzlicher Feiertag: Bayern. Baden-Württemberg. Sachsen-Anhalt.
ich weiß. @Ex0r2k16
Bei der Umgebung ist die Lösung mit 2 Flash Synologys glaube ich am günstigsten und sehr schnell umgesetzt.
Allgemein gesehen hast du Recht. Allerdings hängt es wie so oft von vielen Faktoren ab. Was man keinenfalls außer Acht lassen sollte, ist das verwedente Protokoll (in diesen Fall iSCSI), die damit verbundenen Umschaltzeiten in Kombination der hochverfügbaren Hardware sowie die Applikationen in der VM. Da kann es schnell passieren, dass der Hardware Failover erfolgreich war, aber die Applikation in der VM streikt weil die Umschaltzeit zu hoch war. Warum meint ihr wurde Fibre Channel erfunden?!@em-pie
Ein Problem hast du aber dann trotzdem noch: Splitbrain.
Das Problem hast du mehr oder weniger aber immer, egal wie die Lösung heißt. Dafür gibt es entsprechende Techniken, Maßnahmen und Abläufe um dies zu vermeiden.@ukulele-7
ir haben z.B. zwei NetApp, Aktiv-Passiv gespiegelt. Bricht die eine weg kommt der Admin und ändert die IP der anderen und es geht erstmal wieder. Das schöne dran ist das es sich in vielen Umgebungen zu vertretbaren Kosten umsetzen läßt, das müsste auch in Windows only gehen.
Das hat meiner Ansicht nach und der Definition von HA nicht mehr viel zu tun. Zumal wer Netapp Systeme mit Clustered ONTAP einsetzt, eigentlich auch Clusters (ich meine damit nicht Metrocluster) nutzt, damit die SVM ohne große Anpassungen auf einem anderen Node wieder gestartete werden können ohne (größere) Anpassungen. Zusätzlich kommt dann noch die Hardware-seitige Redundanz in SAN Geräten was Netzteile, HBA, und DP SAS angeht. Das hast du natürlich bei einem Windows System so erstmal nicht.
Warum nicht? Die Redundanz erfolgt doch je nach Ausbau der Server Hardware nicht durch das Betriebssytem. Das beste Beispiel ist hier Nutanix.Gruß,
Dani
Zitat von @Dani:
@em-pie
@em-pie
Ein Problem hast du aber dann trotzdem noch: Splitbrain.
Das Problem hast du mehr oder weniger aber immer, egal wie die Lösung heißt. Dafür gibt es entsprechende Techniken, Maßnahmen und Abläufe um dies zu vermeiden.Stimme ich dir zu. Ich wollte damit auch nur zum Ausdruck bringen, dass er sich dazu entsprechende Gedanken machen sollte/ müsste.
Weshalb? (Ich frage des Interesses wegen.)
Zitat von @Dani:
@ukulele-7
ONTAP habe ich nicht, sind nur zwei E2828.@ukulele-7
ir haben z.B. zwei NetApp, Aktiv-Passiv gespiegelt. Bricht die eine weg kommt der Admin und ändert die IP der anderen und es geht erstmal wieder. Das schöne dran ist das es sich in vielen Umgebungen zu vertretbaren Kosten umsetzen läßt, das müsste auch in Windows only gehen.
Das hat meiner Ansicht nach und der Definition von HA nicht mehr viel zu tun. Zumal wer Netapp Systeme mit Clustered ONTAP einsetzt, eigentlich auch Clusters (ich meine damit nicht Metrocluster) nutzt, damit die SVM ohne große Anpassungen auf einem anderen Node wieder gestartete werden können ohne (größere) Anpassungen.Stimmt, so gesehen ist es kein HA. Aber wenn man genau ließt steht am Anfang auch was von iSCSI-Failover und der darf auch manuell ausgelöst werden
Zusätzlich kommt dann noch die Hardware-seitige Redundanz in SAN Geräten was Netzteile, HBA, und DP SAS angeht. Das hast du natürlich bei einem Windows System so erstmal nicht.
Warum nicht? Die Redundanz erfolgt doch je nach Ausbau der Server Hardware nicht durch das Betriebssytem. Das beste Beispiel ist hier Nutanix.Zitat von @Dani:
@Ex0r2k16
@Ex0r2k16
Bei der Umgebung ist die Lösung mit 2 Flash Synologys glaube ich am günstigsten und sehr schnell umgesetzt.
Allgemein gesehen hast du Recht. Allerdings hängt es wie so oft von vielen Faktoren ab. Was man keinenfalls außer Acht lassen sollte, ist das verwedente Protokoll (in diesen Fall iSCSI), die damit verbundenen Umschaltzeiten in Kombination der hochverfügbaren Hardware sowie die Applikationen in der VM. Da kann es schnell passieren, dass der Hardware Failover erfolgreich war, aber die Applikation in der VM streikt weil die Umschaltzeit zu hoch war. Warum meint ihr wurde Fibre Channel erfunden?!Du hast natürlich Recht, aber ich habe mich ja nicht aufs Protokoll bzw. den Anschluss festgelegt. Bei Fibre Channel biste allerdings wohl eh wieder bei nem "richtigen" Shared Storage. Es gibt übrigens sogar bei Synology inzwischen FC. Aber gut. Der TE will ja eine 100%ige MS Lösung. Baut MS auch SANs? :D
lustigerweise hatte ich mal ne AX4 von EMC im Einsatz da war definitiv ein einfaches Windows XP die basis für deren Betriebssystem.
Aber ich hatte mal von ner Firma ein Angebot für eine Storage Cluster zu Hyper-V. Basis Storge Space und infiniBand
Zitat von @Ueba3ba:
Genau! ich verwende iSCSI. Ich habe zwar noch einige FC HBA's und einen Cisco 8GB FC Switch. Kenne mich aber noch nicht mit FC aus und benötige dafür ja dann auch ein Storage das an einen File-Server via FC angebunden wird. Richtig?
Stimmt, so gesehen ist es kein HA. Aber wenn man genau ließt steht am Anfang auch was von iSCSI-Failover und der darf auch manuell ausgelöst werden
Genau! ich verwende iSCSI. Ich habe zwar noch einige FC HBA's und einen Cisco 8GB FC Switch. Kenne mich aber noch nicht mit FC aus und benötige dafür ja dann auch ein Storage das an einen File-Server via FC angebunden wird. Richtig?
ISCSI hat bei einer so kleinen Umgebung für mich eher nur Nachteile. Warum eigentlich ISCSI? Stehen Server und Storage in einem Raum? Anyway. Ich glaube du hast da was falsch verstanden. Es gibt bei Shared SAN immer 2 Controller, an diese jeweils ein Pfad zum Host führt. Ein Host hat also immer 2 Pfade zum gesamten (!) Storage System. Wie dieser Pfad aussieht, kannst du selber bestimmen. Das kann FC oder ein DAC Kabel sein oder sogar meinetwegen Ethernet für ISCSI, was ich aber nicht nehmen würde. An den Controller kann man noch mehrere Host HBAs und auch SAN Erweiterungen anschließen. Die Erweiterung variert je nach Hersteller etwas aber im Prinzip kochen da alle die gleiche Suppe. Zumindest in der Größenordnung. Aber so 5t€ musste schon hinlegen für ein Konzept ohne FC Switch.
Achso noch zum Ausfall Szenario. Dass das ganze SAN ausfällt ist unwahrscheinlich, da es ja 2 Controller in dem Gehäuse gibt und 2 Netzteile etc. Von daher ist das die Variante mit den geringsten Kopfschmerzen. Da wird auch keine IP Änderung nötig da sich das ganze ja auf Storage Ebene abspielt und eben nicht auf TCP/IP aufbaut. Hat auch den Vorteil, dass kein Ethernet Switch dir in den Storage Traffic rein pfuscht.
Zitat von @Ueba3ba:
Manuel heißt also die IP von Hand ändern bei einem Storage Ausfall?
Wäre noch akzeptabel.
Das muss nicht grundsätzlich so sein aber man kann das so machen (wie gesagt bei mir ist das mit den beiden gespiegelten NetApps so geregelt). HA, also hoch verfügbar, ist es ja erst wenn das ganze nahtlos läuft. Das macht das ganze natürlich durchaus kompliziert, kostet i.d.R. viel mehr und es tauchen neue Probleme auf wie z.B. @em-pie das beschrieben hat.Manuel heißt also die IP von Hand ändern bei einem Storage Ausfall?
Wäre noch akzeptabel.
Ich kann leider keine Erfahrungen zu echtem HA Storage beitragen, bei uns erfolgt bei Ausfall der Haupt-SAN ein manueller Failover in Form von IP-Änderung, einfach aus Kostengründen. Die Haupt-SAN ist insich in vielerlei Hinsicht redundant (HBA, DP SAS, dual PSU) aber als eine Box an einem Standort theoretisch immer ein single point of failure. Brennt die ab habe ich die Spiegelung im Nebengebäude.
Moin,
HA / Verfügbarkeit ist ein Thema was recht komplex werden kann.
(Hast du nur eine Nexus oder auch ne zweite im VPC? Der dritte Server/Filer ist dein Shared Storage für das Cluster?)
Sobald dur nur einen StorageController hast steht das Konstrukt zwangsläufig bei Ausfall jenes.
Aber reicht dir z.B ein kleines SAN mit redundantem Controller oder würde man hier direkt über einen Synchronen Spiegel mit zwei SANs nachdenken müssen? Splitbrain und Zeugen nicht vergessen.
Am oberen Ende steht dann noch die Verfügbarkeit des Dienstes. Was wenn die Applikation (ERP, CRM, Filer, DC, DHCP etc .) ein Problem hat?
Finde den Single Point of Failure
Ich finde das immer wieder ein sehr interessantes Thema
Die perfekte Lösung gibt es IMHO nicht.
Gruß
HA / Verfügbarkeit ist ein Thema was recht komplex werden kann.
(Hast du nur eine Nexus oder auch ne zweite im VPC? Der dritte Server/Filer ist dein Shared Storage für das Cluster?)
Sobald dur nur einen StorageController hast steht das Konstrukt zwangsläufig bei Ausfall jenes.
Aber reicht dir z.B ein kleines SAN mit redundantem Controller oder würde man hier direkt über einen Synchronen Spiegel mit zwei SANs nachdenken müssen? Splitbrain und Zeugen nicht vergessen.
Am oberen Ende steht dann noch die Verfügbarkeit des Dienstes. Was wenn die Applikation (ERP, CRM, Filer, DC, DHCP etc .) ein Problem hat?
Finde den Single Point of Failure
Ich finde das immer wieder ein sehr interessantes Thema
Die perfekte Lösung gibt es IMHO nicht.
Zitat von @Ueba3ba:
Mir fehlt dazu eben noch ein Storage Gehäuse mit einem Controller um mit FC zu arbeiten. Richtig
Wie ist das gemeint? Die Nexus UP kann FC. Klar, die Server benötigen auch ne FC Karte.Mir fehlt dazu eben noch ein Storage Gehäuse mit einem Controller um mit FC zu arbeiten. Richtig
Gruß
Hä warum denn immer FC? Du benötigst nicht zwingend FC für ein vernünftiges SAN. Das geht auch alles über spezielle SAS Kabel die vom Host SAS HBA direkt in den Controller wandern. Da darf halt nur das Kabel nich zu lang werden. Siehe hier:
https://www.dell.com/support/manuals/de-de/storage-scv3000/scv3000-scv30 ...
Das ist deutlich günstiger, benötigt keinen FC Switch, gibts oft fürn Apple und Ei gebraucht in der Bucht. Maximal Ausbau wären hier 4 Hosts.
https://www.dell.com/support/manuals/de-de/storage-scv3000/scv3000-scv30 ...
Das ist deutlich günstiger, benötigt keinen FC Switch, gibts oft fürn Apple und Ei gebraucht in der Bucht. Maximal Ausbau wären hier 4 Hosts.
Zitat von @Ueba3ba:
Es soll ein zweites SAN werden mit Mirroring.
Erst mal. Ist ja erst mal nur fürs Home-LAB.
Nach diesem Vortrag "https://www.youtube.com/watch?v=09BQEILxdug" wird ja ein 3er SAN empfohlen.
Splitbrain lese ich eben zum ersten mal. Noch kein Plan was das ist. Zeuge(Quorum) ist klar.
Dann hast du meinen Kommentar nicht gelesen Es soll ein zweites SAN werden mit Mirroring.
Erst mal. Ist ja erst mal nur fürs Home-LAB.
Nach diesem Vortrag "https://www.youtube.com/watch?v=09BQEILxdug" wird ja ein 3er SAN empfohlen.
Splitbrain und Zeugen nicht vergessen.
Splitbrain lese ich eben zum ersten mal. Noch kein Plan was das ist. Zeuge(Quorum) ist klar.
ISCSI Failover. Fragen
Am oberen Ende steht dann noch die Verfügbarkeit des Dienstes. Was wenn die Applikation (ERP, CRM, Filer, DC, DHCP etc .) ein Problem hat?
Hab ich mir noch keine richtigen Gedanken drübergemacht. Erst mal muss das ganze Konstrukt bei mir im LAB laufen. Dann wird weiter gedacht und umgesetzt. Ich gehe da einen Schritt nach dem anderen.
Sonst wird mir das bisschen zu viel.
Wie ist das gemeint? Die Nexus UP kann FC. Klar, die Server benötigen auch ne FC Karte.
Exakt. FC werde ich mich noch mit beschäftigen, sobald ich das erst mal ohne hinbekomme.FC Switch und HBA's sind schon vorhanden.
Hier kann im schlimmsten Fall ein Switch und ein HBA ausfallen (egal welcher), und das STorage ist immer noch online.
Beim Quorum gibt es verschiedene Ansätze: IP-Quorum müssen nur von beiden Storages erreichbar sein. Ist dein Quorum auf einem dritten Storage, dann ist es wie SAN1 oder 2 anzubinden...
Je nach SAN-Hersteller müssten noch dedizierte Verbindungen zwischen SAN1 und SAN 2 hergestellt werden, damit die sich unabhängig vom Nutzdatentraffic synchronisieren/ spiegeln können.
Nach dem ich den oben verlinkten Beitrag sah, schaut mein Plan so aus:
2 JBOD's besorgen und einen weiteren File-Server.
...
Lass den Quatsch mit JBODs2 JBOD's besorgen und einen weiteren File-Server.
...
JBOD = Just a Bunch of Disks Link
du hast dadurch keinerlei Ausfallsicherheit innerhalb eines Storage. Ich würde hier ein passendes RAID anlegen.
Wenn es sehr performant sein soll: RAID 10 aus mindestens 4 Disks
Wenn es etwas träger sein darf, RAID 5 oder RAID 6, wobei ich ein Freund von Distributed Arrays bin (kann aber nicht jeder Hersteller)
Und einen Windows-File-Server als Datenbasis zu nutzen... vielleicht bin ich da zu konservativ, aber da steckt mir persönlich zu viel Unsicherheit drin - mag aber auch an mangelnder Erfahrung liegen, da wir bisweilen immer klassische SANs (HPE, IBM, ...) unten drunter haben.
Hallo!
Auch wenn die Anfrage schon etwas her ist - ich will trotzdem noch etwas dazu schreiben.
Wenn ich Deine Anforderung richtig verstehe, dann möchtest Du Deine Fileserver hochverfügbar machen. Dafür stehen Dir mit MS mehrere völlig unterschiedliche Ansätze zur Verfügung.
Da wäre zum 1. eine klassischer aktive/passive Cluster mit Shared Storage: Du hast einen gemeinsamen Datenspeicher - gewöhnlich per iSCSI angebunden (natürlich ist auch FC möglich) - und zwei (oder mehr) Fileservernodes, welche nach außen über das Clustercomputerkonto mit einem Namen/einer IP angesprochen werden. Ein Node ist immer Owner des des shared Storage. Fällt dieser aus, dann muss sowohl der Storageowner als auch der Cluster für die Fileservices umschalten. Das dauert eine gewisse Zeit und kann - je nach Timeout - auch zum Absturz einer Applikation führen.
Variante 2 beinhaltet ein Storagecluster: Jeder Node hat "seinen" Datenspeicher, der über die Storageclusterdienste synchronisiert wird - es kann also ein Node mit seinem Speicher ausfallen, der andere steht komplett zur Verfügung. Vor- und Nachteil ist die doppelte Datenhaltung und ein Muß für ein schnelles Netzwerk für die synchrone Datenreplikation. Es entfällt die Umschaltzeit. Das Scenario ist als "aktiv/aktiv" bekannt.
Ein völlig anderer Lösungsansatz bietet DFS mit DFS-Replikation. Wie im Scenario 2 sind die Daten mehrfach vorhanden. Der Zugriff erfolgt über DFS-Namespace und die Replikation über die DFS-Replikation. Das kann sogar Standortübergreifend passieren durch Remotedifferentialkomprimierung. Das ist aber eine asynchrone Replizierung, will heißen, wenn Person 1 am Standort 1 auf Server 1 etwas ändert, kann gleichzeitig am Standort 2 Person2 auf Server 2 etwas ändern (beim Fileservercluster ist die Datei dann gesperrt) und es "gewinnt" der, der zuletzt auf "speichern" klickt. Außerdem sind nicht alle Änderungen sofort am 2. Standort (bzw bei einem Standort auf dem 2. Server) sichtbar
Auch wenn die Anfrage schon etwas her ist - ich will trotzdem noch etwas dazu schreiben.
Wenn ich Deine Anforderung richtig verstehe, dann möchtest Du Deine Fileserver hochverfügbar machen. Dafür stehen Dir mit MS mehrere völlig unterschiedliche Ansätze zur Verfügung.
Da wäre zum 1. eine klassischer aktive/passive Cluster mit Shared Storage: Du hast einen gemeinsamen Datenspeicher - gewöhnlich per iSCSI angebunden (natürlich ist auch FC möglich) - und zwei (oder mehr) Fileservernodes, welche nach außen über das Clustercomputerkonto mit einem Namen/einer IP angesprochen werden. Ein Node ist immer Owner des des shared Storage. Fällt dieser aus, dann muss sowohl der Storageowner als auch der Cluster für die Fileservices umschalten. Das dauert eine gewisse Zeit und kann - je nach Timeout - auch zum Absturz einer Applikation führen.
Variante 2 beinhaltet ein Storagecluster: Jeder Node hat "seinen" Datenspeicher, der über die Storageclusterdienste synchronisiert wird - es kann also ein Node mit seinem Speicher ausfallen, der andere steht komplett zur Verfügung. Vor- und Nachteil ist die doppelte Datenhaltung und ein Muß für ein schnelles Netzwerk für die synchrone Datenreplikation. Es entfällt die Umschaltzeit. Das Scenario ist als "aktiv/aktiv" bekannt.
Ein völlig anderer Lösungsansatz bietet DFS mit DFS-Replikation. Wie im Scenario 2 sind die Daten mehrfach vorhanden. Der Zugriff erfolgt über DFS-Namespace und die Replikation über die DFS-Replikation. Das kann sogar Standortübergreifend passieren durch Remotedifferentialkomprimierung. Das ist aber eine asynchrone Replizierung, will heißen, wenn Person 1 am Standort 1 auf Server 1 etwas ändert, kann gleichzeitig am Standort 2 Person2 auf Server 2 etwas ändern (beim Fileservercluster ist die Datei dann gesperrt) und es "gewinnt" der, der zuletzt auf "speichern" klickt. Außerdem sind nicht alle Änderungen sofort am 2. Standort (bzw bei einem Standort auf dem 2. Server) sichtbar