Hinweis: Bei meinen Recherchen zu dem Thema habe ich festgestellt, dass dieses Problem scheinbar auch bei Exchange 2010 auftritt!
Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer
“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”
Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:
Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”
Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.
Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.
Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.
Danach funktioniert das nächtliche Backup wieder ohne Probleme:
In Windows 8 und 8.1 zeigt der Taskmanager standardmäßig neben der Last auf CPU und RAM auch die Disk-Performance an:
Dies ist sehr praktisch, weil man hier u.a. die Latenz sowie die Last in Prozenten und die tatsächlichen Raten sehen kann.
Bei einem Windows Server 2012 bzw. 2012 R2 wird das standardmäßig nicht angezeigt:
Wenn man nun auch hier die Disk-Performance sehen möchte, dann kann man dies aktivieren.
ACHTUNG: Das Aktivieren des Disk-Performance-Counters auf einem Server hat Auswirkungen auf die I/O-Performance der Festplatte (wie stark ist allerdings mit Sicherheit situationsabhängig)
Das Aktivieren ist recht einfach und funktioniert über einen simplen Aufruf in einer Kommandozeile mit Administratoren-Rechten:
Für Suchmaschinen und co.: Der Aufruf lautet
diskperf –Y
Sobald man das Kommando ausgeführt hat und den Taskmanager (neu)startet, sind auch auf dem Server die Disk-Daten zu sehen:
Wenn man im SCVMM 2012 R2 (gilt auch für “R1”) eine VM mit Hilfe einer VM-Vorlage (engl. “Template”) erzeugt, dann bekommt diese neue VM (und zwar unabhängig von dem bereits vorhandenen Betriebssystem in der eingesetzten VHD) alle Regionaleinstellungen auf “en-US”, dazu gehören u.a.:
Tastaturlayout
User-Locale
System-Locale
UILanguage
Die einzige Einstellung bezüglich der Region lässt sich für die Zeitzone einrichten:
Selbst wenn man mit Hilfe einer eigenen Antwortdatei andere Werte setzt, werden diese weitgehend ignoriert, da am Ende in der resultierenden Antwortdatei (Eigene Inhalte + im SCVMM gesetzte Einstellungen + SCVMM-Defaults) die SCVMM-Defaults am weitesten oben stehen und daher Vorrang bekommen.
Dieses Verhalten ist bei Microsoft bekannt und in dem folgenden KB-Artikel beschrieben:
Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.
Für eine Minimal-Konfiguration werden benötigt:
Ein Domänencontroller
Zwei weitere Server als Mitglied der Domäne
Zentraler Speicher
Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).
Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.
Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).
Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.
Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:
Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:
Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:
In den ersten Schritten sind die künftigen Knoten auszuwählen:
Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…
Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):
In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!
Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:
Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)
Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!
Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!
Seit dem Windows Server 2012 ist ein Software iSCSI Target mit an Board, welches früher separat beschafft und nachinstalliert werden musst. Dieses kann z.B. wunderbar für die Einrichtung eines Failover-Clusters verwendet werden, oder auch für Datensicherung “off-site”. Die Einrichtung des Targets und eines Initiators möchte ich hier beschreiben:
Das iSCSI-Target
Zu erst einmal muss das iSCSI Target auf einem Windows Server installiert werden. Dies geschieht am besten über den Server-Manager und dort über “Verwalten” / “Rollen und Features hinzufügen”. Dort ist dann in der Liste der Features der “iSCSI-Zielserver” auszuwählen:
Ist dies erledigt, können (ebenfalls über den Servermanager) iSCSI-Disks und –Targets eingerichtet werden. Dies geschieht im Bereich “Datei-/Speicherdienste”. Dort kann man einfach “Starten Sie den Assistenten für neue virtuelle iSCSI-Datenträger…” auswählen:
Auf der ersten Seite des Assistenten ist zu wählen, wo die für die iSCSI-Disk verwendete VHDX-Datei abgelegt werden soll. Man kann entweder nur das Laufwerk wählen, dann wird dort ein neuer Ordner “iSCSIVirtualDisk” angelegt, oder man wählt einen eigenen Pfad:
Auf der nächsten Seite ist einfach nur der Name der künftigen Disk festzulegen:
Im dritten Schritt kann man wählen, ob die iSCSI-VHDX eine Datei “Fester Größe”, eine “Dynamisch erweiterbare” oder eine “Differenzierende” ist. Dynamisch erweiterbar spart dabei erstmal Speicherplatz, da die Datei mit den darin abgelegten Daten mit wächst. Dafür ist hier ein kleines Delay “vorprogrammiert”, weil eben immer wieder neu Speicherplatz angefordert werden muss, wenn die Datei wachsen soll. Für Testumgebungen oder wenn der Speicherplatz sehr knapp ist kann man das aber dennoch verwenden:
In den nächsten Beiden Schritten kann nun gewählt werden, ob ein vorhandenes iSCSI-Target verwendet oder ein neues angelegt werden soll:
In meinem Fall habe ich ein neues Target erstellt.
Nun müssen zulässige Server für den Zugriff ausgewählt werden, die so genannten “Initiatoren”. Dies geschieht durch einen Klick auf “Hinzufügen”:
Die Initiatoren werden für gewöhnlich über einen sogenannten IQN identifiziert. Dieser kann ab Windows 8 und Server 2012 direkt vom Server abgefragt werden (obere Option). Hat man bereits einen IQN abgefragt, so steht dieser dann bei der mittleren Option für weitere Targets zur Verfügung. Als dritte Option kann man das Ziel über DNS, IP oder durch händische Eingabe des IQN bestimmen:
Ich werde hier von einem anderen WS2012R2 zugreifen, daher kann ich die obere Variante wählen:
Wenn das iSCSI-Target später für einen Failover-Cluster genutzt werden soll, dann müssen alle künftigen Knoten eingetragen werden:
Optional kann nun noch CHAP, das “Challenging Handshake Protocol” aktiviert werden, um etwas mehr Sicherheit zu bekommen:
Zum Schluss gibt es noch eine Zusammenfassung:
Sind die Targets eingerichtet, so tauchen diese dann künftig im Servermanager auf:
Der iSCSI-Initiator
Für den Server- oder Clientseitigen Zugriff auf das eingerichtete iSCSI-Target wird der iSCSI-Initiator verwendet, welcher standardmäßig bei den moderneren Client- und Serverbetriebssystemen dabei ist:
Beim ersten Start kommt eine Abfrage bezüglich des Dienstes. Diese muss mit “Ja” beantwortet werden. Danach können Ziele eingerichtet werden, in dem die Adresse oder der Hostname des Target-Servers in das oberste Feld eingetragen wird und dann auf “Schnell verbinden” geklickt wird:
Wenn das Zielsystem sauber kontaktiert werden konnte, dann sollte man nun die eingerichteten Targets sehen können:
Entweder man klickt hier direkt auf “Verbinden” oder erst einmal auf “Fertig” (dann kann man später noch Multipath aktivieren).
Nun sollten die Ziele in etwa so aufgelistet sein:
Wenn man nun eines auswählt und auf “Verbinden” klickt, kann die Verbindung (unter Nutzung von Multipfad) hergestellt werden:
Am Ende sollten die Targets so im Initiator auftauchen:
Nun kann über [WIN]+[X] die Datenträgerverwaltung geöffnet werden:
Dort tauchen die Laufwerke nun auf und können partitioniert und formatiert werden. Das wäre es dann auch schon gewesen…
