Kategorie: Windows Server

Windows Server und System Center Technical Previews stehen bereit

Veröffentlicht 4. Oktober 2014

Seit dem 01. Oktober stehen nun neben der Technical Preview von Windows 10 auch die Previews für den kommenden Windows Server sowie für System Center bereit:

In 5 großen Bereichen soll es Änderungen beim Windows Server geben:

Infrastructure Upgrades
Networking
Storage
Remote Desktop
Identity and Access Management

Dies ist einem Blog-Artikel vom “Microsoft Server and Cloud Plattform Team” zu entnehmen.

Ein finaler Name für den neuen Windows Server steht noch nicht fest, aber ich vermute, dass er “Windows Server 2015” heißen wird. Über Details werde ich zeitnah berichten.

Den Download der Preview erhält man über die MSDN oder das Evaluation Center.

Schreibe einen Kommentar...

Windows Server 2012 R2: Storage Pools mit SSD-Tiering

Veröffentlicht 13. August 2014

EDIT: Ich habe wie versprochen die Benchmark-Ergebnisse als Tabelle am Ende des Artikels eingefügt!

Seit dem Windows Server 2012 beherrschen die Microsoft-Server-Systeme die Möglichkeit, so genannte “Storage Pools” (Speicherpools) zu bilden. Dabei handelt es sich um einen Zusammenschluss verschiedener lokal angebundener oder als LUN eingebundener Datenträger, z.B. via SAS, SATA oder auch USB. Bei den LUNs stehen iSCSI und FiberChannel zur Verfügung.

Die grundsätzliche Idee ist hier, eine Art Storage abzubilden, quasi eine “Storage-Virtualisierung”. Aus einem gebildeten Storage-Pool können anschließend logische Laufwerke, sogenannte “Speicherplätze” (Storage Spaces), gebildet werden. Dabei kann die Organisation des Speichers gewählt werden. Zur Verfügung stehen “Simple” (eine Art RAID0, keine Datensicherheit, aber eine Erhöhung des Durchsatzes durch die gleichzeitige Nutzung aller beteiligter Festplatten), “Mirror” (Eine Art RAID1 mit einfacher oder doppelter Spiegelung der Blöcke um ein Erhalten der Daten auch bei Ausfall einer Festplatte sicherzustellen) und “Parity” (Funktioniert wie RAID5; Paritätsdaten, die ein Wiederherstellen der Daten bei Ausfall einer Festplatte möglich machen, werden über alle beteiligten Datenträger verteilt). Dabei spielen Größe, Hersteller, Bus-Typ und co. der Festplatten nahezu keine Rolle – ein Faktor, der die Storage Pools deutlich von klassischen RAID-Controllern unterscheidet.

Ein weiterer Faktor, der Storage-Pools von üblichen “lokalen” Speichertechnologien abgrenzt ist die Möglichkeit, nachträglich Festplatten hinzuzufügen oder durch größere auszutauschen, um den zur Verfügung stehenden Speicherplatz zu erhöhen.

Seit dem zweiten Release des Server 2012 wird diese Technologie noch erweitert: Der Windows Server 2012 R2 beherrscht das sogenannte “SSD-Tiering” (Speicherebenen). Hierbei werden klassische HDDs und SSDs gemeinsam in einem Pool genutzt und die häufig gelesenen Daten auf die SSD verschoben, die seltener genutzten Daten bleiben auf der HDD. Alternativ kann man SSDs auch als Write-Back-Cache einsetzen.

(Eine Anleitung, wie das genau eingerichtet werden kann, werde ich in kürze ebenfalls veröffentlichen.)

Diese Möglichkeit – sowie Speicherpools insgesamt – sind in meinen Augen vor allem für kleinere und mittlere IT-Landschaften interessant, in denen keine “ausgewachsenen” SANs zum Einsatz kommen (können). Daher war für mich interessant, wie gut diese Technologie funktioniert und welche Geschwindigkeits-Vorteile hierbei erzielt werden können. Daher habe ich diverse Test-Messungen unternommen, welche ich nun hier auswerten möchte. Zum Einsatz kam ein Fujitsu-Siemens-Server mit einem 4-Kern-Xeon-Prozessor und 8GB RAM, dazu 2 SATA-Festplatten von Western Digital und 2 SATA-SSDs von Crucial, jeweils mit etwa 250GB Speicher.

Zuerst habe ich die Festplatten einzeln getestet, um Vergleichswerte zu haben:

Hier ist natürlich zu erkennen, dass die SSD (rechts) deutlich schneller als die HDD (links) ist – und zwar in allen Disziplinen.

Weiterhin habe ich den Server-eigenen LSI RAID-Controller getestet (jeweils im RAID0, links 2x HDD, rechts 2x SSD):

Beim Lesen schafft der Controller sogar etwa doppelt so schnelle Werte – beim Schreiben brechen die Werte dafür dann recht ordentlich ein, der Betrieb ist also langsamer als eine einzelne Platte!

Und nun im direkten Vergleich ein Betrieb via Storage-Pool im “Simple”-Modus (links) und im “Mirror”-Modus (rechts):

Hier sieht man zunächst (CrystalDiskMark) etwa folgende Ergebnisse:

– Im Simple-Modus erreicht der Pool fast die Lese-Raten des RAID0 aus 2x SSD am Controller, übertrifft die Schreibraten aber deutlich

– Auch bei den wahlfreien Zugriffen sind durchweg bessere Werte zu sehen als beim RAID0 oder den einzelnen Platten

– Beim Mirror-Modus sind die Leseraten in etwa so wie beim Simple-Modus, beim Schreiben dafür aber nur etwa halb so hoch

– Insgesamt ist der Mirror-Modus aber besser als die beiden SSDs im RAID0 des Controllers

Wenn man nun aber noch HD Tach mit betrachtet, dann sieht man recht deutlich, dass die hohen Raten nur anfänglich erreicht werden (nämlich bis zu der Stelle, an der zwischen denn SSDs und den HDDs gewechselt wird, hier etwa bei der Hälfte. Dennoch sind die Daten im “HDD-Bereich” recht gut!

Ich denke diese Ergebnisse zeigen, dass die Technologie zu hohen Geschwindigkeiten fähig ist, die selbst mit (zumindest einfacheren) RAID-Controllern nicht erreicht werden. ~~Ich werde zeitnah noch eine tabellarische Gegenüberstellung der Werte ausarbeiten.~~

So, hier nun noch die Benchmarks in einer tabellarischen Übersicht zusammengefasst (Klick zum Vergrößern):

Zusammenfassend kann man hier nun also sehen:

In den lesenden Disziplinen ist ein “echtes” RAID0 mittels RAID-Controller und den beiden SSDs am schnellsten
In den schreibenden Disziplinen ist der Storage-Pool mit einem Simple-Laufwerk am LSI-Controller am besten – dabei auch deutlich schneller als das controllereigene RAID0 von LSI und HP mit den SSDs
Der direkte Vergleich zwischen den Storage-Pools am HP-Controller und am LSI-Controller geht erstaunlicherweise zu Gunsten des LSI-Controllers aus und dies auch durchweg, obwohl der LSI-Controller (im Gegensatz zum HP-Controller) über keinen eigenen Cache verfügt (mit aktiviertem BBWC würde der HP-Controller wohl beim Schreiben noch deutlich besser werden)
Geht es um Datenredundanz (hier also RAID1 o.ä.), dann ist der Storage-Pool im Mirror-Modus mit der Kombination HDD plus SSD am besten!
Ein Storage-Pool mit 2 HDDs im Mirror-Mode ist fast genau so gut (oder genau so schlecht) wie die RAID1-Implementierung des HP- oder des LSI-Controllers

Schreibe einen Kommentar...

PowerShell: Anmelde-Konto der Windows-Dienste überprüfen

Veröffentlicht 5. August 2014

Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:

Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.

Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.

Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:

Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:

Was bleibt nun also? Eine Abfrage mittels WMI!

Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:

Will man statt den “internen” (teil kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:

Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName

Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

Schreibe einen Kommentar...

Windows Server 2012 R2: Netzwerk-Profil mit PowerShell von “Öffentlich” auf “Privat” ändern

Veröffentlicht 4. August 2014

Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln:

Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage:

Auch mit Hilfe der Windows PowerShell kann man dies sehen…

… und ändern!

Mit Hilfe des Aufrufs

Set-NetConnectionProfile –InterfaceIndex # –NetworkCategory Private

wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen:

3 Comments

WDS und SCCM oder 2x WDS parallel betreiben / Probleme mit PXE lösen

Veröffentlicht 17. Juli 2014

Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:

Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.

Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).

Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:

Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):

Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!

Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:

Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:

Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.

Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!

Schreibe einen Kommentar...

Windows Server 2012 R2: Datei nach Dedeplizierung nur noch 0 Byte groß

Veröffentlicht 2. Juli 2014

In einem früheren Artikel habe ich beschrieben, wie man auf einem Windows Server 2012 die Datendeduplizierung (Data-Deduplication) konfiguriert und nutzt. Dort war in einem einfachen Beispiel zu sehen, dass die Datei nach der Deduplizierung noch genau 4KB belegt hat, also die verwendete Blockgröße (“Größe der Zuordnungseinheit”

Das liegt daran, weil die nach der Deduplizierung die verwendeten Chunks nicht mehr beim betroffenen File liegen. Die Datei ist also tatsächlich 0 Byte groß – belegt aber eigentlich an einer anderen Stelle Speicherplatz.

Mit Hilfe des PowerShell-Cmdlets “Measure-DedupFileMetadata” lässt sich die tatsächlich belegte SPeichermenge ermitteln:

Hier belegt die SizeOnDisk nur noch die zu erwartenden 4KB…

Die eigentlichen Chunks liegen im Ordner “System Volume Information”, an dessen Inhalt man aber nicht ohne Weiteres herankommt.

Schreibe einen Kommentar...

BranchCache mit Windows Server 2012 R2 und Windows 8.1

Veröffentlicht 5. Mai 2014

BranchCache, eine Technologie die mit dem Windows Server 2008 R2 und Windows 7 eingeführt wurde, ermöglicht es, den Datenverkehr auf WAN-Strecken und die damit einhergehende Wartezeit bei der Übertragung zu reduzieren. Es geht darum, den lesenden Zugriff von einem Unternehmens-Standort (hier als “Filiale” bezeichnet) auf Daten in einem anderen Standort (hier als “Firmensitz” bezeichnet) zwischen zu speichern (“caching”).

Grundsätzlich stehen zwei verschiedene Modi zur Verfügung:

Hosted Cache (“Gehosteter Cache”)
Distributed Cache (“Verteilter Cache”)

Beim Hosted Cache übernimmt ein Server in der Filiale die Aufgabe des Caches. Er speichert die Daten entsprechend zwischen. Beim Distributed Cache wird auf einen dedizierten Server verzichtet – die Clients der Filiale übernehmen das Caching. Vorteil des Distributed Cachings ist also der Verzicht auf zusätzliche Hardware und den damit verbundenen Verwaltungsaufwand. Allerdings entsteht der Nachteil, dass das Endgerät, welches die Daten in seinem Cache hält, zum benötigten Zeitpunkt nicht online ist und somit der Cache nicht genutzt werden kann.

Es existieren mittlerweile zwei verschiedene Versionen:

V1 steht bereits ab Windows Server 2008 R2 und Windows 7 zur Verfügung
V2 steht erst ab Windows Server 2012 und Windows 8 zur Verfügung

Der Ablauf beim Distributed Cache ist (etwas vereinfacht) der folgende:

Client1 in der Filiale soll ein File auf einem Dateiserver am Firmensitz öffnen; durch eine GPO ist er für BranchCache und den Modus “Distributed Cache” konfiguriert. Beim Dateiserver fragt er nicht die Datei selber sondern deren Hash (eine Art Fingerabdruck, die das File in seiner aktuellen Version identifiziert) an.
Der Dateiserver überträgt den Hash zum Client1 (Der Hash wurde vom Dateiserver generiert, dieser ist ebenfalls durch eine GPO entsprechend konfiguriert)
Client1 fragt per Broadcast in seinem Subnetz an, ob andere Clients das File in ihrem Cache haben, welches durch den Hash identifiziert wird; im Beispiel gehen wir nun davon aus, dass keiner der anderen Clients dieses File bisher geöffnet hat
Client1 fragt nun noch einmal beim Dateiserver an; dieses Mal jedoch direkt nach der Datei statt nach deren Hash
Die Datei wird zum Client1 übertragen und dort geöffnet
Wenn nun auch Client2 in der Filiale diese Datei öffnen will, dann beginnt der Prozess wieder “von neuem”: Client2 fragt beim Dateiserver den Hash für das File an
Der Dateiserver überträgt den Hash an Client2
Client2 fragt per Broadcast in seinem Subnetz nach dem Hash
Client1 meldet sich, da dieser das File in seinem Cache hat (Voraussetzung ist, dass sich das File zwischenzeitlich auf dem Dateiserver nicht geändert hat, denn dann hätte es einen anderen Hash!); Die Datei wird nun aus dem Cache von Client1 zum Client2 übertragen; dieser kann das File nun öffnen (und er hält es fortan auch in seinem Cache vor!)

Dabei haben also folgende Übertragungen stattgefunden:

2x Abfrage des Hashes über WAN
1x Übertragung des Files über WAN
1x Übertragung des Files über LAN

Eingespart wurde also die zweite Übertragung des Files über WAN; stattdessen kommt die Übertragung der Hashes hinzu, die aber im Verhältnis deutlich kleiner sind

BranchCache ist also insbesondere sinnvoll bei:

Unternehmen mit verschiedenen Standorten
Häufigen lesenden Zugriffen auf sich selten ändernde Dateien über das gesamte Unternehmensnetzwerk

Die Edition des Server-Betriebssystems spielt bei einem Server 2012 R2 keine Rolle, bei den Clients muss unter Windows 8.1 die Enterprise-Edition eingesetzt werden. (Unter Server 2008 R2 muss der Caching-Server mindestens die Enterprise-Edition verwenden, für den Dateiserver spielt die Edition keine Rolle; Windows 7 Clients müssen mindestens die Enterprise-Edition verwenden.)

Im Folgenden möchte ich den Aufbau einer einfachen BranchCache-Umgebung darstellen. Dabei gibt es einen Server, SRV1, der neben der Aufgabe des Domänen-Controllers auch gleichzeitig die Aufgabe des Dateiserver übernimmt. Die beiden Clients WIN8-1 und WIN8-2 werden dann den Zugriff auf eine Datei des Dateiservers durchführen.

Auf SRV1 wird über den Servermanager / “Verwalten” / “Rollen und Features hinzufügen” ein Rollendienst hinzugefügt:

Unterhalb der Rolle “Datei-/Speicherdienste” findet sich “BranchCache für Netzwerkdateien”:

Nach der Installation dieses Rollendienstes kann nun an jeder Freigabe, bei der dies gewünscht ist, BranchCache aktiviert werden. Dies geschieht in den Eigenschaften der “Erweiterten Freigabe” über den Button “Zwischenspeichern”:

Als nächstes müssen nun zwei Gruppenrichtlinien konfiguriert werden:

CPR_BranchCache_Content ist für den Fileserver gedacht und wird sinnvollerweise über die Sicherheitsfilter nur auf diese angewendet
CPR_BranchCache_Clients ist für die Clients gedacht und kann z.B. per WMI-Filter dynamisch auf diese wirken

Innerhalb der Content-Policy wird zum einen die Hash-Veröffentlichung aktiviert und zum anderen die Version festgelegt. Man kann hier zwischen “Nur V1”, “V1 und V2” oder “Nur V2” wählen:

Der relevante Pfad innerhalb der GPO lautet “Computerkonfiguration” / “Richtlinien” / “Administrative Vorlagen” / “Netzwerk” / “LanMan-Server”

Innerhalb der Client-Policy sind etwas mehr Einstellungen vorzunehmen:

Hier muss BranchCache aktiviert werden, der Modus “Verteilter Cache” festgelegt werden und optional können die maximale Speicherbelegung, das maximale Alter und weitere Dinge konfiguriert werden. Aus Demo-Zwecken werde ich außerdem in der Einstellung “BranchCache für Netzwerkdateien konfigurieren” die minimale Latenz von 80ms auf 0ms herabsetzen und somit das Nutzen des Caches auch in einem schnellen Netzwerk erzwingen:

Sinnvollerweise wird nun auf dem Server und den Clients ein gpupdate durchgeführt, um nicht erst auf das Verarbeiten der GPOs warten zu müssen:

Nun kann man auf den Clients noch einmal die Branchcache-Konfiguration überprüfen. Dies geschieht mit Hilfe des Aufrufes

netsh branchcache show status all

Sollte dann in etwa so aussehen:

Nun kann mittels Leistungsüberwachung getestet werden, ob die Konfiguration funktioniert. Dazu sind die entsprechenden Indikatoren hinzuzufügen:

Sinnvollerweise schaltet man nun die Leistungsüberwachung auf “Bericht” um (drittes Symbol in der Leiste oben von links gezählt).

Der Benutzer “Franz Iskaner” öffnet nun von WIN8-1 aus ein Dokument auf dem Dateiserver:

Eine Eigenart des integrierten PDF-Readers auf WIndows 8 ist, dass dieser das Dokument nur in Teilen öffnet und beim Lesen dann entsprechend die Inhalte nachlädt. Daher wurde nun also nicht das gesamte Dokument mit ca. 13MB sondern nur ein Teil davon vom Server abgerufen (ich habe die ersten hundert Seiten von ca. 2000 durchgeblättert):

Auf WIN8-2 öffnet nun “Karl Auer” das selbe Dokument, die Leistungsüberwachung ist geöffnet und zeigt nun folgende Werte auf WIN8-2:

(WIN8-1 hatte zwischenzeitlich weitere Teile des Dokumentes abgerufen, weshalb WIN8-2 etwas mehr vom Cache abrufen konnte als WIN8-1 im oberen Screenshot vom Server abgerufen hatte)

Ein Teil des Dokumentes kommt hier (das aber insbesondere wegen des PDF-Readers) immer noch vom Server – nämlich der Teil, der nicht im Cache auf WIN8-1 liegt, weil er dort bisher nicht geöffnet wurde.

Die Funktionsfähigkeit der BranchCache-Konfiguration ist damit aber gezeigt.

An dieser Stelle sei nochmal darauf hingewiesen, das BranchCache nur LESEND funktioniert – beim Schreiben wird direkt auf den Server geschrieben und nicht in den Cache!

Weitere Informationen zum Thema Branchcache finden sich im Microsoft Technet:

http://technet.microsoft.com/de-de/library/hh831696.aspx

Schreibe einen Kommentar...

Windows Server 2012 R2: Automatische Sperre verhindern

Veröffentlicht 23. April 2014

Im Gegensatz zu seinen Vorgängern sperrt der Windows Server 2012 R2 seine Oberfläche nach 10 Minuten Inaktivität. Dies ist aus Sicherheitsgründen sicherlich nützlich, oft aber einfach nur störend, z.B. wenn man einen Prozess längere Zeit beobachten will oder vor allem in Test- und Demoumgebungen.

Selbstverständlich lässt sich dieses Verhalten abschalten, allerdings etwas versteckt.

Das Ganze geschieht über die Energieeinstellungen und dort in den jeweiligen Energiesparplaneinstellungen:

Systemsteuerung / Hardware / Energieoptionen (oder direkt im Startmenü “Energieoptionen” eingeben. Dort werden als erstes die Energiesparplaneinstellungen des aktuellen Energiesparplanes geöffnet.

Hier muss dann über “Erweiterte Energieeinstellungen ändern” die GUI für die Energieoptionen geöffnet werden.

Allerdings hat die notwendige Option einen eher unerwarteten Namen:

Das was hier an der deutschen Oberfläche als “Bildschirm ausschalten nach” bezeichnet wird, betrifft auch das Sperren der Sitzung. Standardmäßig sind hier 10 Minuten eingetragen. Ein Herabsetzen auf den Wert “0” deaktiviert diese Funktion komplett.

Schreibe einen Kommentar...

Windows Server 2012 (R2): Disk-Performance im Taskmanager anzeigen

Veröffentlicht 17. März 2014

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:

Das Abschalten ist nun eher trivial:

diskperf –N

Schreibe einen Kommentar...

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Veröffentlicht 11. März 2014

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!

Schreibe einen Kommentar...