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 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.
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) zwischenzuspeichern (“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
Diese und weitere Themen werden u.a. in unseren Kursen zum Thema “Windows Server 2012 R2” behandelt, z.B. in diesen:
Windows Server 2012 R2 - Konfiguration, Verwaltung und Wartung
Windows Server 2012 R2 - Power-Woche Administration
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.
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
Weitere Informationen zum Thema Windows Server 2012 R2 finden Sie auch unter http://www.ppedv.de/R2
Die aktuelle Version von Microsofts Server-Betriebssystem ist derzeit Windows Server 2012 R2. Einige Neuerungen habe ich bereits aus der Kursveranstaltung „Windows Server 2012 – Konfiguration, Verwaltung und Wartung“ kennengelernt und möchte euch kurz über die Veränderungen informieren. Die Neuerungen im Detail kommen später im Blogeintrag von Haiko Hertes.
Neuerungen
Gegenüber seinem Vorgänger hat sich einiges verändert. 1. Microsoft stellte die neue Serverversion gleichzeitig mit Windows 8.1 vor.
2. Die Aktualisierung von der Vorgängerversion auf Windows Server 2012 R2 ist nicht kostenlos. Unternehmen müssen die neue Serverversion lizenzieren und bekommen diese Version mit Software Assurance-Vertrag umsonst. Mit Software Assurance erhalten Kunden Zugang zu den neuesten Microsoft-Produktversionen und können die aktuellste Technologie sofort bei Verfügbarkeit oder zu einem beliebigen späteren Zeitpunkt einsetzen. Der Kunde hat auch das Recht, die lizenzierte Software in der aktuellsten oder in einer früheren Version zu nutzen.
3. Eine weitere Neuerung ist das System Center 2012 R2, das mit Windows Server 2012 R2 zeitgleich erschienen ist.
4. Zu den Neuerungen gehört auch das Hyper-V 2012 R2. Microsoft hat den Zugriff auf den virtuellen Server (auf Basis von Remote Desktop Protocol (RDP)) verbessert. Per Remotedesktop kann man sich direkt mit einer virtuellen Maschine verbinden, selbst wenn diese keine zugehörige Client-Software geladen hat. (im Detail: Die RDP-Sitzungen laufen in Windows Server 2012 R2 über den Host, eine direkte RDP-Verbindung zum virtuellen Server ist nicht mehr notwendig.)
5. In der neuen Version kann man die virtuellen Festplatten (VHDX) im laufenden Betrieb vergrößern und verkleinern (siehe Abbildung1).
Abbildung1: Assistent zum Bearbeiten virtueller Festplatten
Ein weiterer Punkt ist die Ausfallsicherheit beim VHDX-Format. Die VHDX-Dateien besitzen eine Log-Datei. Log-Dateien sind das Zugriffsprotokoll eines Webservers. Sie bestehen gewöhnlich aus ganz vielen Zeilen, von denen jede genau einen Zugriff wiedergibt. Wenn der Server ausfällt und kein sauberes Herunterfahren möglich war, ist mit Hilfe dieser Protokolldatei die Wiederherstellung der VHDX möglich. Dieses Protokoll bezieht sich allerdings nur auf die Metadaten der VHDX-Datei. Das Erzeugen einer VHDX-Datei ist über den Server Manager machbar. PowerShell beim Hyper-V 3 kann mit diesen Dateitypen auch umgehen (Hinweis: Es gibt Befehle, die beim Hyper-V 3 in der zugehörigen Bibliothek vorliegen. Der Admin muss dazu keine externen PowerShell-Module mehr herunterladen und sie separat importieren).
6. Eine weitere Neuerung im Hyper-V 2012 R2-Bereich ist das Verschieben von virtuellen Servern zwischen Hyper-V-Host im laufenden Betrieb – die Live Migration. Diese ermöglicht das Übertragen von virtuellen Servern im laufenden Betrieb, zum Beispiel für Wartungsarbeiten des Hyper-V-Hosts. Bei dieser Übertragung kopiert Hyper-V nicht nur die virtuellen Festplatten zwischen den Hosts, sondern auch den Inhalt des Arbeitsspeichers. Das heißt, die Anwender bekommen von der Übertragung nichts mit und der virtuelle Server steht während der Übertragung weiter zur Verfügung (siehe Abbildung2).
Abbildung2: Die Live Migration
In Windows Server 2012 verbessert Microsoft einige Schwächen der Live-Migration aus. Eine Schwäche der Übertragung in Windows Server 2008 R2 war bisher zum Beispiel die fehlende Möglichkeit, mehrere virtuelle Server auf einmal zu verschieben. Das kostet unnötig Zeit. In Windows Server 2012 können Unternehmen mehrere Server gleichzeitig übertragen. Die maximale Anzahl lässt sich auf jedem Host einstellen.
Im Detail: Live Migration ist jetzt für 10 Gigabits-Netzwerke optimiert und kann in sehr schnellen Netzwerken mit Remote Direct Memory Access (RDMA) sehr schnell die Inhalte des Arbeitsspeichers zwischen den Hosts verschieben. Die neue Live Migration ist kompatibel zu Windows Server 2012, sodass sich virtuelle Server zwischen Hosts mit Windows Server 2012 und Windows Server 2012 R2 verschieben lassen.
Bei Windows Server 2012 R2 Hyper-V hat die Live Migration an Geschwindigkeit zugelegt. Microsoft-Angaben zufolge kann bei Verwendung von 3 RDMA–Karten in beiden Hosts ein Transfer mit maximaler PCIv3-Geschwindigkeit respektive 16 Gigabyte pro Sekunde erfolgen. Davon profitiert auch die clusterfähige Aktualisierung zur Einspielung von Patches auf Clusterkonten. Benötigt dieser Vorgang bei Windows Server 2012 vielfach noch rund 12 Stunden, sinkt der Zeitbedarf schon durch die Datenkompression auf 3,5 Stunden. Mit RDMA ist gar nur noch eine Stunde erforderlich.
7. Eine weitere Neuerung ist, dass im laufenden Betrieb der Virtuelle Server sich importieren und kopieren lässt. Windows Server 2012 R2 berücksichtigt dabei auch Snapshots (also Prüfpunkte oder Checkpoints, wie wir im Kurs auch schon gehört haben). Vor dem Export muss man den virtuellen Server nicht mehr herunterfahren oder Snapshots löschen. Virtuelle Server kann man jetzt in Windows Server R2 im laufenden Betrieb exportieren und kopieren.
8. Die Aufhebung der bisherigen Beschränkungen der Copy & Paste-Funktion zwischen Host und Client auf Textinformationen gehört auch zu den Neuerungen. Mit Windows Server 2012 R2 Hyper-V kann man Dateien mittels Drag&Drop einfach kopieren.
9. Weitere Neuerungen sind die VMs (Virtuelle Maschine) – Generation 2. Dieser neue VM-Typ verzichtet auf die Komplettnachbildung eines physischen PCs. Detailliert: Emulierte/nachgebildete Geräte kennt Gen2-VM nicht, da er ohne PCI-Bus und ohne BIOS auskommt. Gen2-VM nutzt UEFI-Firmware (Unified Extensible Firmware Interface). Das ermöglicht, virtuelle SCSI-Festplatten und Netzwerkadapter zu booten und Secure-Boot zu verwenden, was für mehr Flexibilität und Sicherheit sorgt.
10. Hyper-V-Replikalässt bei Windows Server 2012 R2 die Erweiterung um zusätzliche Standorte zu. Hyper-V-Replika erlaubt jetzt auch die Replikation auf einen dritten Host. Windows Server 2012 beherrschte hier nur zwei Hosts.
11. Die neue Funktion Storage Quality of Service wurde in Windows Server 2012 R2 integriert. Admins können jetzt den Datendurchsatz für virtuelle Server steuern (siehe Abbildung 3 – Minimum/Maximum).
Abbildung3: Datendurchsatz für virtuelle Server steuern
Fazit: Windows Server 2012 bietet viele Neuerungen, vor allem im Bereich Hyper-V. Unternehmen und Kunden sollten sich eine Aktualisierung überlegen und die Vorteile von den Verbesserungen in Windows Server 2012 R2 nutzen.
Quellen: http://www.tecchannel.de/server/windows/2040714/microsoft_betriebssystem_windows_server_2012_r2_bringt_viele_neue_features/index.html
http://www.channelpartner.de/channelcenter/windows/2607817/index.html