Windows 2012 macht Dateifreigaben über SMB 3.0

Windows 2012 macht Dateifreigaben
über SMB 3.0 hochverfügbar
Eine Änderung der Datei- und Speicherdienste und der Einsatz des Protokolls SMB 3.0 (Server Message
Block) führen zu hochverfügbaren Dateidiensten. Damit soll allein diese Verbesserung für viele Anwendungsfälle ausreichen, um sofort die Migration auf die neueste Version des Windows-Serverbetriebssystems
anzugehen. John Savill nimmt die Verbesserungen genau unter die Lupe.
Fragt man die Administratoren, was sie
für das beste Feature bei Windows Server
halten, wird der Bereich der Dateidienste
es wohl nicht unter die Top 5 schaffen.
Doch mit der Vorstellung des Windows
Server 2012 wird sich das ändern. Das
Zusammenspiel der „File and Storage Services“ mit dem SMB Version 3.0 (SMB 3.0; es
wurde von SMB 2.2 zur Version 3 umbenannt) bringt einige erstaunliche Features
ins Spiel. Damit ändert sich die Art und
Weise, wie das Filesharing arbeitet. Dabei
lassen sich auch hochverfügbare Konfigurationen mit wenig Aufwand erstellen.
In diesem Beitrag werden zwei wichtige
Neuerungen der Dateidienste bei einem Failover Clustering gezeigt: das SMB Transparent Failover und das SMB Scale-Out. Dabei
wird auch gezeigt, wie der Systembetreuer
diese Neuerungen einsetzen kann, um eine
Dateidienste-Umgebung für sehr komplexe
Arbeitslasten zu bieten – inklusive Datenbanken auf Basis des Microsoft SQL Servers
und Konfigurationen mit virtuellen Maschinen (VMs) auf der Basis des Hyper-V.
nen Servern im Cluster (sie werden auch als
Nodes oder Knoten bezeichnet) verschieben. Diese Dienste bestehen aus verschiedenen Ressourcen, wie etwa einer IP-Adresse,
einen Netzwerknamen, Speicher und den
aktuellen Dienst – wie etwa Dateiserver,
Printserver, VM, Exchange Server Mailbox
Server und so weiter. Die Dienste können
nach einem vorgegebenen Plan von einem
Knoten zum anderen verschoben werden
oder aber bei einem unerwarteten Ausfall
eines Servers auf einen anderen transferiert
werden. Im letzteren Fall werden die Dienste, die auf dem ausgefallenen Server aktiv
waren unter den verbleibenden – gesunden
– Knoten im Cluster verteilt. In Abbildung 1
Dateidienste in einer Failover
Cluster-Umgebung
Ehe es an die Vorstellung der neuen Funktionalitäten geht, soll zuerst beschrieben
werden, wie die Dateidienste in einer Failover Cluster-Umgebung funktionieren. Damit
lassen sich hochverfügbare Dateiserver –
noch genauer – hochverfügbare Dateifreigaben erstellen. Bei Windows Server 2012
können bis zu 64 Server zu einem Failover
Cluster zusammengespannt werden – bei
der Vorgängerversion Windows Server 2008
Release 2 waren es nur 16 Server in einem
Cluster. Alle 64 Server in dem Cluster müssen allerdings dann auch die Rolle „Failover
Cluster“ installiert haben und dann so konfiguriert sein, dass sie einen gemeinsamen
Satz von Speicher und Diensten teilen.
Dann lassen sich die Dienste, die in einem
Cluster definiert sind, zwischen den einzel-
Bild 1. Das Prinzip eines Failover Cluster, bei dem ein Dienst zwischen den Knoten verschoben werden kann.
1
ist eine Konfiguration mit einem 4-KnotenCluster und einer Dateiserver-Ressource zu
sehen. Der Dateiserver stellt eine einzige
Dateifreigabe zur Verfügung, die alle Inhalte auf einer NTFS-formatierten LUN (Logical
Unit Number) ablegt. Bei der LUN handelt
es sich um einen Blockbereich eines
gemeinsamen Speichers, mit dem sich alle
Knoten des Clusters verbinden können. Der
Dateiserver – und damit auch die Dateifreigabe – ist anfangs online mit dem dritten
Knoten des Clusters verbunden. Dieser
Knoten mountet auch die LUN, die die
Inhalte des Dateiservers beherbergt. Bei
einem beliebigen Fehler zieht der Dateiserver auf den vierten Knoten um, der auch
die LUN mountet, die nötig ist, um die
gemeinsamen Inhalte vorzuhalten. Die LUN
von jedem der Knoten gemountet sein, der
den Dateiserver beherbergt. So kann man
auf die Inhalte zugreifen, denn das NTFS ist
ein „Shared Nothing“-Dateisystem, auf das
immer nur von einem Knoten aus zugegriffen werden kann. Daher muss, wenn ein
Dateiserver zu einem anderen Knoten
umzieht, die LUN ebenfalls zwischen allen
Knoten verschoben werden. Ein Dateiserver
ist somit immer nur bei einem der Knoten
zu einer Zeit online.
Transparenter
SMB-Failover-Vorgang
Das beschriebene Szenario enthält Herausforderungen, denn es geht um eine Dateifreigabe, die zwischen Knoten eines Clusters in geplanten und nicht geplanten
Ausfällen verschoben werden soll. Wenn
eine Applikation auf eine Datei zugreifen
möchte, die auf einer Dateifreigabe liegt,
wird zuerst „Handler“ angelegt. Sie erlauben der Anwendung, auf die Datei zuzugreifen und sie unter Umständen auch zu
sperren, damit keine andere Anwendung
nicht gleichzeitig in diese Datei schreiben
kann und dass es so zu Inkonsistenzen
kommt. Des Weiteren legt der Handler fest,
wie auf die Daten zugegriffen wird und
sogar noch ob Daten auf dem Dateiserver
gepuffert werden können – das hat dann
positive Auswirkungen auf die Performance
des Systems.
Beim Windows Server 2008 Release 2 (und
frühere Versionen des Windows Server)
gehen alle Handler verloren, wenn ein
Dateiserver auf einen anderen Knoten verschoben wird. Üblicherweise ist diese Ein2
schränkung kein allzu großes Problem für
normale Anwender, die zum Beispiel auf
ein Word-Dokument zugreifen möchten.
Doch das sieht beim Zugriff auf einen
Datenbank auf Basis des SQL Servers ganz
anders aus.
Eine zweite Herausforderung ist der Zeitaufwand, den ein Client eines Dateiservers
spendieren muss, um zu erkennen, dass der
gewünschte Dateiserver nicht länger zur
Verfügung steht und dass für die Wiederherstellung der Verbindung einige Schritte
auszuführen sind. Die Werte für den
TCP/IP-Timeout (inklusive des mehrmaligen
Versuchs, doch noch auf die Daten zugreifen zu können) führen typischerweise zu
einer Unterbrechung von 40 Sekunden –
das ist für Server-Applikationen nicht
akzeptabel, wenn sie Daten auf Dateifreigaben ablegen müssen. Denn für diese 40
Sekunden setzen alle Aktivitäten aus, die
mit Ein-/Ausgabe auf der Dateifreigabe zu
tun haben. Diese Situation wird auch als
„Brownout“ – im Gegensatz zum Totalausfall (Blackout) bezeichnet. Diese Problemfelder müssen für das SMB gelöst werden.
Wenn Server-Applikationen wie der SQL
Server oder der Hyper-V auf SMB-Freigaben
zugreifen sollen, dürfen sie die Datei-Handler nicht verlieren oder ungefähr 40 Sekunden mit der Ein-/Ausgabe aussetzen.
Hier setzt das Feature des „SMB Transparent Failover“ ein und behebt diese beiden
Herausforderungen. Es aktiviert die Funktionalität der ununterbrochen verfügbaren
Dateifreigaben für SMB 3.0-Clients, vermeidet den Verlust des Datei-Handlers bei
einem Ausfall und reduziert die Zeit, die
nötig ist, um zu erkennen, dass der Dateiserver auf einen anderen Knoten umgezogen ist – dann gibt es keine „Brownouts“
mehr.
Dateifreigaben verfügbar halten
Das „SMB Transparent Failover“ besteht aus
einige Konfigurationsänderungen sowie
neuen Techniken. Einen Vorteil, den Dateiserver üblicherweise bieten, ist das Puffern
von Daten, die auf den Massenspeicher zu
schreiben sind. Damit bekommen die
Clients schneller die Benachrichtigung, dass
der Schreibvorgang abgeschlossen ist, denn
die Dateiserver puffern den Schreibauftrag –
mit den zu schreibenden Daten – im flüchtigen Speicher, ehe der Schreibvorgang auf
Disk tatsächlich ausgeführt wird. Doch
damit ergibt sich auch ein Problem: Kommt
es beim Dateiserver zu einem Stromausfall
und sind noch nicht alle Daten auf die Festplatte geschrieben, kommt es auch zu
einem Datenverlust.
Es gibt allerdings auch Applikationen, die
das Puffern unterbinden. Sie setzen dazu
beim Anlegen des Datei-Handlers das Attribut „FILE_FLAG_WRITE_THROUGH“. Damit
wird sichergestellt, dass die Anwendung die
Informationen immer sofort auf die Festplatte schreibt. Erst dann kommt die Bestätigung an den Client zurück, die besagt, dass
diese Aktion abgeschlossen ist. Beim „SMB
Transparent Failover“ wird standardmäßig
beim Anlegen eines jeden datei-Handlers
das„FILE_FLAG_WRITE_THROUGH“
gesetzt. Damit wird auf einen flüchtigen
Zwischenspeicher verzichtet. Dadurch gibt
es zwar eine geringe Einschränkung in
Sachen Performance, weil der Cache nicht
mehr verwendet wird. Doch die gewonnen
Datenintegrität erweist sich in der Praxis als
ein gutes Gegengewicht.
Die zweite Änderung, die beim „SMB
Transparent Failover“ ins Spiel kommt, ist
die Art und Weise, wie das Betriebssystem
die datei-Handler verwaltet. Üblicherweise
werden diese Objekte im Speicher auf dem
Dateiserver abgelegt. Wenn nun aber ein
Knoten ausfällt und der Server auf einen
anderen Knoten im Cluster umzieht, gehen
die Handler verloren. Das hat natürlich die
entsprechenden Konsequenzen für die
betroffene Applikation. Daher legt der
„SMB Transparent Failover“ den Zustand
des Handlers nicht nur im Arbeitsspeicher
ab, sondern sichert ihn auch noch in der
„Resume Key Database“ – im Systemverzeichnis auf der Festplatte, auf der die Datei
liegt und auf die sich der Handler bezieht.
Das Ablegen der Handler-Information auf
der Festplatte bewahrt den Zustand des
Handlers, wenn der Dateiserver zwischen
Knoten eines Clusters verschoben wird.
Da aber die Zugriffs- und Schreibzeiten bei
Festplatten um ganze Größenordnungen
langsamer sind als beim Arbeitsspeicher,
verursachen Arbeitslasten, bei denen viele
Metadaten anfallen (wie etwa das Anlegen,
Löschen, Umbenennen, Erweitern, Öffnen
und Schließen von Dateien) zusätzlich EinAusgabelast in der Resume Key Database.
Damit verfügt die Festplatte über weniger
effektiven Ein-/Ausgabedurchsatz als
ansonsten. Aber auch hier gilt: Die Vorteile
durch dieses Konzept machen die Reduzie-
rung der Ein-/Ausgabe-Performance wieder
wett.
Das Reduzieren der
Brownout-Zeiten
Um die zweite Herausforderung zu beherrschen und um die Zeit zu verringern, die
der SMB-Client benötigt, um zu erkennen,
dass die TCP-Verbindung nicht mehr verfügbar ist, muss der Cluster eine Form von
proaktiven Verhalten an den Tag legen. Der
Cluster muss die SMB-Clients informieren,
die sich mit einer Freigabe, die auf einem
Cluster liegt, verbinden, dass sich der Dateiserver auf einen anderen Knoten im Cluster
verschiebt, wenn das eintritt. Auf diese Art
kann sich der SMB-Client schneller erneut
verbinden. Dazu kommt die neue Fähigkeit,
die als „SMB Witness“ bezeichnet wird, ins
Spiel – sie arbeiten vom logischen Kommunikationsprinzip her wie folgt:
SMB-Client:
Ich möchte die Verbindung zu dieser Freigabe auf dem ServerA herstellen.
SMB ServerA:
OK, die Verbindung steht. Diese Freigabe
liegt auf einem Cluster, informiere den
„SMB Witness“-Prozess.
SMB Client Witness:
Sehr schön, bitte teil mir mit, welche Knoten alle im Cluster sind.
SMB ServerA:
Hier ist die Liste mit allen Knoten im Cluster:
ServerA, ServerB, ServerC,. . .
SMB Client Witness:
Hallo ServerB. Ich verbinde mich mit dieser
Freigabe mit der IP-Adresse auf ServerA. Ich
möchte mich bei dir eintragen, damit du mir
mitteilen kannst, wenn etwas Unvorhergesehenes beim ServerA passiert oder wenn
der Dateiserver verschoben wird.
SMB ServerB:
Na klar, ich lasse es dich wissen.
Nach diesem Informationsaustausch wird
der SMB-Client über den „SMB Witness“Prozess immer dann informiert, wenn etwas
mit dem Dateiserver im Cluster passiert.
Dadurch kann der Client viel schneller sich
neu mit dem Dateiserver verbinden, als das
zuvor nur mit Hilfe des TCP Timeouts machbar war. Denn mit der neuen Konfiguration
liegt die Zeit für das Erkennen und Reagieren auf einen derartigen Ausfall zwischen 5
und 7 Sekunden – und nicht mehr im
Bereich von 40 Sekunden. Um das „SMB
Transparent Failover“ zu aktivieren, muss
der Administrator nichts unternehmen.
Wenn er den Failover Cluster Manager, den
Server Manager oder die Powershell verwendet, um eine Freigabe auf einem Dateiserver unter Windows Server 2012 Cluster
zu erzeugen, ist das „SMB Transparent Failover“ standardmäßig für diese Freigabe
aktiviert. Wenn man die Freigabe mit dem
Windows Explorer oder über das Kommando Net Share anlegt, wird der SMB Transparent Failover nicht aktiviert, denn diese Tools
kennen diesen Modus nicht. Clients auf der
Basis von Windows 8 oder Windows Server
2012, die mit SMB 3.0 zurecht kommen,
verwenden dann die Funktionalität des SMB
Witness und werden die Sessions öffnen,
um die Write-Trough-Handler zu nutzen.
Der Administrator kann die Powershell einsetzen, um zu bestätigen, dass dieser Prozess ausgeführt wird. In einer Testumgebung hat der Autor zwei Knoten in einem
Cluster mit einer Dateiserver-Ressource und
einer Freigabe angelegt. Dann erfolgt der
Reconnect von dem Client-System aus und
über ein entsprechend berechtigtes Powershell-Fenster wurde dann das folgende
Kommando auf einem Knoten im Cluster
ausgeführt:
PS C:\> get-smbwitnessclient | select
clientname, fileservernodename,
witnessnodename
clientname fileservernodename witnessnodename
---------- ------------------ --------------savdalwks08 WIN8FC01 WIN8FC02
Wie man sehen kann zeigt die Ausgabe den
Namen des Client-Systems (hier: savdalwks08), den Dateiserver, mit dem sich
der Client verbunden hat (Win8FC01) und
den Knoten, bei dem er für die Benachrichtigung eingetragen ist. (den Witness,
Win8FC02). Eine andere Option ist der Einsatz des Powershell-Cmdlets Get-SmbOpenFile und das Untersuchen der Property ContinuouslyAvailable.
Um eine Liste aller vom Administrator angelegten Freigaben zu bekommen und um
dann zu bestimmen, ob sie für die Hochverfügbarkeit konfiguriert sind, kann man den
folgenden Powershell-Code verwenden:
PS C:\> Get-SmbShare | Where {$_.Scoped -eq "true" -and $_.Special -ne
"True"} | Sort ClusterType | Format-Table
Name, ScopeName, ClusterType, ContinuouslyAvailable, Path
Name ScopeName ClusterType ContinuouslyAvailable Path
---- --------- ----------- --------------------- ---NonCSVData WIN8FSTRAD Traditional
True E:\Shares\NonCSVData
DataCSV WIN8FSSCOUT ScaleOut True
C:\ClusterStorage\Vo...
Scale-Out-Möglichkeiten des SMB
Der Einsatz von Dateiservern in einem Cluster hat sich seit der ersten Einführung nicht
großartig geändert. Nur eine Knoten im
Cluster kann zu einem Zeitpunkt eine
bestimmte NTFS-formatierte LUN mounten
und die Freigaben beherbergen. Dieses
Angebot eines Dienstes von nur einem Knoten kann zu Einschränkungen im Bereich
der Skalierbarkeit und auch zu Verzögerungen führen. Denn die betreffenden LUNs
müssen abgehängt (dismountet), verschoben und erneut gemountet werden, wenn
die Ressource „Dateiserver“ verschoben
wird. Diese Notwendigkeit hat dazu
geführt, dass die Speicherarchitekten zu
einigen nicht optimalen Entwurfsentscheidungen gezwungen waren, wenn sie ihren
Cluster geplant hatten und dabei vermeiden
wollten, dass einzelne Knoten untätig sind.
Angenommen ein Unternehmen möchte
ein NTFS-Volume für den gemeinsamen
Zugriff vorsehen. Doch diese Freigabe soll
hochverfügbar sein. Bei diesem Szenario
sind zumindest zwei Hosts in einem Cluster
nötig. Doch nur einer von ihnen kann die
Freigabe zu einer Zeit bereitstellen. Um eine
derartige Aktiv-Passiv-Situation zu vermeiden, in der ein System sozusagen gar nichts
tut, teilen die Speicher-Admins die LUN auf
und machen zwei daraus. Dann legen sie
zwei NTFS-Volumes an (eines auf jeder LUN)
und erzeugen dann zwei Dateiserver im
Cluster – einen jeden mit einer eigenen Freigabe. Diese Konfiguration erlaubt es dann,
dass jeder Knoten eine Freigabe anbieten
kann und auch die Freigabe des anderen
Knotens in einem Fehlerfall übernehmen
kann. Auf dieser Art arbeiten dann auch
3
beide Knoten – aber der Speicher ist nun
auf eine Art aufgeteilt, die ein Unternehmen nicht unbedingt haben möchte.
Zudem ergibt sich ein weiteres Problem:
Wenn man die Inhalte nicht korrekt verteilt,
bekommt ein Knoten unter Umständen
deutlich mehr Verkehr ab als der andere.
Das führt zu einem unausgewogenen
Design und daraus kommt dann unter
Umständen der Bedarf, viele Daten verschieben zu müssen. Und dieses Beispiel
arbeitet ja nur mit zwei Knoten – angenommen es sind vier Knoten auf diese Weise zu
konfigurieren (siehe Abbildung 2) oder gar
deren acht, gibt es eine Vielzahl von einzelnen LUNs, NTFS-Volumes und Freigaben zu
separieren, allein um alle Knoten im Cluster
beschäftigt zu halten.
Das Grundproblem für diesen Zusatzaufwand ist bei den NTFS-Volumes zu suchen:
Sie können nicht wirklich gemeinsam freigeben werden und können immer nur von
einem Knoten zu einer Zeit benutzt werden.
Beim Windows Server 2008 Release 2 hat
man das bereits teilweise behoben – mit der
Einführung der CSV (Cluster Shared Volumes). Vom Prinzip her befähigen die CSVs
eine einzelne NTFS-formatierte LUN, von
allen Knoten in einem Cluster gleichzeitig
beschrieben und gelesen zu werden.
Dazu stellen einige recht clevere Mechanismen im Hintergrund sicher, dass die
Daten immer konsistent gehalten werden.
Doch die CSVs beim Windows Server 2008
R2 sind nur für den Einsatz mit der Virtualisierungs-Plattform Hyper-V und die zugehörigen VMs (virtuelle Maschinen) konzipiert.
Dabei dürfen die VMs auf Hyper-V-Systemen in einem Cluster laufen, der die CSV
beherbergt.
Beim Windows Server 2012 wird der Einsatz
der CSV erweitert: Sie spielen auch mit
einem neuen Typus von Dateiservern
zusammen du zwar mit dem sogenannten
„SMB Scale-Out“-Dateiserver. Der Typus des
Dateiservers – Scale-Out oder der traditionelle (also das bestehende DateiserverModell) – wird zum Zeitpunkt des Anlegens
des Dateiservers bestimmt. Legt er Administrator einen neuen Dateiserver des Typs
Scale-Out an, muss er die Freigaben auf Verzeichnissen anlegen, die auf Volumes eines
CSV liegen. Beim Windows Server 2012 tragen die NTFS-Volumes die Bezeichnung
„CSVFS“, wenn sich als CSV-aktiviert ange-
legt wurden. Doch das Dateisystem ist nach
wie vor NTFS, doch mit der Änderung des
Labels für das Dateisystem wird die Unterscheidung einfacher: So ist auf den ersten
Blick zu erkennen, ob es sich um CSVDatenträger handelt oder um die gewöhnlichen NTFS-Volumes.
Dabei darf man nicht aus den Augen verlieren, dass ein CSV für alle Knoten im Cluster
gleichzeitig verfügbar ist. Daher wird die
derart angelegte Freigabe nun gleichzeitig
allen Knoten im Cluster angeboten werden
können. Und alle Knoten können dadurch
auf den Inhalt zugreifen. Wenn der Systembetreuer einen Scale-Out-Server anlegt,
muss er keine IP-Adresse explizit angeben –
die IP-Adressen für die Schnittstellen, die für
den Zugriff der Clients auf dem ClusterKnoten konfiguriert sind, finden Verwendung – und alle Knoten bieten den entsprechenden Dienst an.
Eine weitere sehr interessante Funktionalität
in diesem Zusammenhang ist der Einsatz
des „SMB Transparent Failover“, um einen
Client von einem Knoten, der die Funktionalität des Scale-out Dateiservers bietet, an
einen anderen Knoten zu verschieben –
ohne dass dabei eine Unterbrechung des
Zugriffs erfolgt. Angenommen man möchte
einen Knoten in einen Wartungs-Modus
bringen, dann kann man mit dem folgenden Befehl einen bestimmten SMB-Client
von einem Knoten zu einem anderen verschieben. Mit Hilfe der Powershell lässt sich
dieser Befehl leicht für alle Clients ausführen, die mit einem bestimmten Knoten im
Cluster verbunden sind.
Zuerst muss er Administrator den Server
bestimmen, den ein SMB-Client verwendet:
PS C:\> get-smbwitnessclient | select
clientname, fileservernodename, witnessnodename
clientname fileservernodename witnessnodename
---------- ------------------ --------------savdalwks08 WIN8FC01 WIN8FC02
Dann wird der Client auf den anderen Server in der Testumgebung verschoben:
Bild 2. Kompromisse prägen den Einsatz der üblichen geclusterten Dateiserver.
4
PS C:\> Move-SmbWitnessClient -ClientName savdalwks08 -DestinationNode
Win8FC02
Um zu verifizieren, dass dieser Verschiebevorgang auch ausgeführt wurde, wird das
erste Kommando erneut gestartet. Dabei
zeigt sich, dass der Client nun auf den anderen Knoten im Cluster verschoben wurde.
Aber die „Witness“ liegt nach wie vor beim
ursprünglichen Knoten.
PS C:\> get-smbwitnessclient | select
clientname, fileservernodename, witnessnodename
clientname fileservernodename witnessnodename
---------- ------------------ --------------savdalwks08 WIN8FC02 WIN8FC01
Nun stellt sich die Frage, was diese Ausgabe
bedeutet. Hierzu muss man sich erneut die
Abbildung 2 vor Augen führen: Nun kann
der Administrator eine einzige, große LUN
anlegen – mit einem NTFS-Volume gleichzeitig verfügbar für alle vier Knoten. Microsoft unterstützt derzeit bis zu acht Knoten
auf einem SMB Scale-out Dateiserver. Diese
Konstellation reduziert die Verwaltungsaufgaben enorm: Es sind keine zusätzlichen
separaten LUNs anzulegen, keine Freigaben
und keine Probleme mit den IP-Adressen der
einzelnen Dateiserver sind zu beachten.
Deswegen sei die Frage erlaubt: Warum gibt
es den traditionellen Dateiserver-Typus –
wer wird das jemals noch einsetzen?
Die CSV verwenden sehr clevere Mechanismen, um sicherzustellen, dass ein NTFSVolume von allen Knoten in einem Custer
beschrieben und aus ihm gelesen werden
kann, ohne dass es zu Dateninkonsistenzen
kommt. Dabei sind die klügsten Teile für das
Schreiben von Metadaten auf die NTFSVolumes eingesetzt worden – denn das ist
auch der größte Problembereich, wenn
mehrere Knoten gleichzeitig ein NTFS-Volume benutzen. Schon wenn nur zwei Server
gleichzeitig auf Metadaten in einem NTFSVolume scheiben, kann es zu Inkonsistenzen
und Datenverlust kommen. Bei den CSV
wird das Problem gelöst, indem ein „Coordinator Node“ für jede CSV-Disk existiert.
Dieser Knoten mountet die Festplatte lokal
und führt alle Metadaten-Aktionen aus –
auch für alle anderen Knoten des Clusters.
Die anderen Cluster-Knoten senden ihre
Metadata-Schreibaktionen über das ClusterNetzwerk an den Coordinator Node. Die
Standardaktionen im Bereich der Ein-/Ausgabe können die anderen Knoten direkt
ausführen. Das Umleiten der MetadatenAktionen über das Netzwerk führt allerdings
zu einer gewissen Verzögerung. Das ist der
Grund, weswegen die „SMB Scale-Out“Dateiserver für die Schlüssel-Arbeitslasten
eines Servers – wie etwa SQL Server oder
Hyper-V – konzipiert sind. Denn diese
Anwendungen benötigen nur wenige
Metadaten-Aktionen und haben ihren
Fokus auf der reinen Daten-Ein-/Ausgabe.
Vergleicht man die Ein-/Ausgabe-Charakteristika derartiger Server-Arbeitslasten mit
denen von typischen Information Worker,
die zum Beispiel in erster Linie Dokumente
mit Microsoft Office bearbeiten, dann
beträgt der Anteil der Metadaten-Operationen bei den Information Workern 60 bis zu
70 Prozent der gesamte Ein-/Ausgabelast.
Das bedeutet, dass man sehr viele Daten
umleiten muss. Daraus lässt sich aber nicht
ableiten, dass ein SMB Scale-Out-Dateiserver bei einem Einsatz im Umfeld der Information Worker nicht gut funktioniert, doch
das darf man sicher nicht aus den Augen
verlieren. Derzeit lautet zumindest die Empfehlung, dass man die Sale-Out Dateiserver
in erster Linie für Microsoft SQL Server und
Hyper-V verwenden soll.
Es gibt aber noch einen weiteren Grund,
weswegen ein Scale-Out Dateiserver nicht
so gut für das Abspeichern von OfficeDokumenten und anderen Benutzerdaten
geeignet ist. Die Windows-Dateiserver-Plattform wird in vielen Einsatzfällen verwendet
– aufgrund von Funktionalitäten wie den
Kontingenten (Quotas), Datei-Klassifizierungen, Branch Cache und – ab Server 2012
auch wegen der Daten-Deduplizierung.
Aber keine dieser Funktionen ist bei einem
Scale-Out Dateiserver verfügbar. Die typischen Server-Anwendungen benötigen
diese Funktionalitäten dagegen nicht.
soft-Umfeld erreichbar war. Auch wenn das
Scale-Out-Konzept in erster Linie auf Arbeitslasten wie den SQL Server und den Hyper-V
abzielt, so werden noch weitere Szenarien folgen und empfohlen werden. Damit bekommen die Anwender neue Optionen, wenn es
um die Speicherarchitektur und die generelle
IT-Konzeption geht.
John Savill
SMB Transparent Failover
vermeidet Ausfallzeit
Keine Ausfallzeit, lediglich eine geringe Verzögerung bei der Ein-/Ausgabe verspricht das
Konzept des SMB Transparent Failover. In
Abbildung 3 ist die Funktionsweise skizziert,
wie sie beim Einsatz zusammen mit einem
Hyper-V-Host abläuft, der die Daten auf
einem geclusterten Dateiserver (mit zwei
Knoten im Cluster) ablegt: Zuerst läuft alles
normal (Zustand 1), dann erfolgt die „Failover-Operation“ für die Freigabe \\fs1\share,
die zuerst auf dem Knoten A aktiv ist und
nach dem Failover auf dem Knoten B läuft.
Die Verbindungen und die Datei-Handler
werden dann automatisch umgestellt, so dass
diese Freigabe dann auf dem Knoten B liegt
und genauso benutzt werden kann, wie vorher auf dem Knoten A. Für die Anwendung
bedeutet das, dass die Ein-/Ausgabe weiterläuft ohne dass ein Fehler auftritt. Es kommt
während der automatischen Umstellung
lediglich zu einer kurzen Verzögerung bei den
anstehenden Ein-/Ausgabeoperationen.
Nötig für dieses Szenario sind SMB 3.0 als
Protokoll, ein Failover Cluster für die Freigaben (auf Basis von Windows Server 2012)
und die Freigaben selbst müssen für die
„Continuous Availability“ aktiviert sein.
Abschließende Feststellungen
Die Kombination aus Scale-Out Dateiserver
und SMB Transparent Failover (letztere Funktionalität funktioniert sowohl mit dem traditionellen Dateiserver-Konzept wie auch dem
Scale-Out Dateiserver) führt zu einer Dateiserver-Plattform, bei der mehrere Server dieselbe
Freigabe mit denselben Inhalt nutzen können.
Daraus ergibt sich eine höhere Skalierbarkeit
für die Clients und eine Zuverlässigkeit sowie
Ausfallsicherheit, die zuvor nicht im Micro-
Bild 3. Ablauf des Transparent Failovers beim
SMB 3.0, Quelle: Microsoft/SNIA/SNW.
5