Diesmal habe ich wieder zwei Schwerpunkt Themen für euch. Einerseits hört Ihr wie ich “fast” nach Las Vegas zur MMS 2012 gereist währe. Und im Anderen stelle ich euch wieder einige neue coole Features von Hyper- V in Windows Server 2012 vor. Zusätzlich habe ich wie immer viele Links auf Posts und Videos und Veranstaltungstipps für euch gesammelt.

Ich wünsche euch beim Zuhören viele Erkenntnisse und soviel Spaß, wie ich beim Zusammentragen der Infos hatte.

Shownotes:

Links und News (ab 1:14)

Updated Links on Windows Server 2012 File Server and SMB 3.0 von Jose Barreto auf seinem Blog Jose’s Briefings, Diagrams and Annotations

Let’s Build a Cloud… With PowerShell! – Part 1: Deployment and Configuration von Yigal Edery auf Private Cloud Architecture Blog

Understanding Microsoft Private Cloud – White paper von Kristian Nese auf Virtualization and some coffee

New Knowledge Base articles for System Center 2012 Virtual Machine Manager auf System Center Virtual Machine Manager Blog

System Center Virtual Machine Manager 2012 Configuration Analyzer von Michel Lüscher auf Server-Talk.eu

Upgrading Hyper-V Cluster Nodes to Windows Server 2012 (Beta) – Part 1, Part 2 and Part 3 von Didier Van Hoye auf Working Hard In IT Blog

Windows Server 8: CSV Cache Benchmark von Thomas Maurer auf seinem Blog

System Center 2012 Unified Installer, 1-2-3 und alles ist installiert! von Michel Lüscher auf Server-Talk.eu

Windows Server 2012 Beta Scale-Out File Server for SQL Server 2012 – Step-by-step Installation von von Jose Barreto auf seinem Blog Jose’s Briefings, Diagrams and Annotations

Prometics 2 for 1 Exam Vouchers Aktion bis 30. Juni. 2012

System Center 2012 – Virtual Machine Manager – Evaluation (VHD)

Video and Audio (ab 12:51)

Edge Show 23 – Monitoring Service Delivery and Automation for the Private Cloud with System Center 2012 mit Symon Periman and Sean Christensen auf Technet Edge

System Center Universe Recordings Now Live On Demand von Travis Wright auf System Center Data Protection Manager Blog

Robert Hedblom: System Center 2012 Data Protection Manager Vortrag von der Nordic Infrastructure Conference

DPM How to Videos von Steven Buchanan auf Buchatech.com

Inside Central 21 – DPM 2012 and MMS warm-up with DPM MVP Mike Resseler

Edge Byte – Windows Server 8 – Hyper-V and Beyond Virtualization – Interview with Jeff Woolsey

Videocast: Hyper-V Replica in Windows Server 2012 Beta auf Hyper-V-Server.de

Schwerpunktpunktthema MMS2012 (ab 18:30)

Hier findet Ihr die Artikel die in diesem Bereich des Podcasts erwähnt worden sind:

MMS 2012 – Day One Keynote wrapup

MMS 2012 – Day 2 Keynote Wrap-up

Download MMS Sessions von Marcel Zehner auf SCSMfaq.ch

Technet Edge Show von MMS

14 new Private Cloud guided labs are available for testing

MMS2012 Virtualization Sessions auf Hyper-V-Server.de

Schwerpunktpunktthema Windows Server 2012 Beta (ab 29:40)

Diesmal erzähle ich einiges über die Neuerungen die sich auf den Failover-Cluster in Windows Server 2012 beziehen. Ich spreche über dinge wie “CSV Caching”, “Cluster Aware Updating”, “VM Priority” und vieles mehr.

Übrigens, es gibt wieder ein Poster zu Hyper-V: Windows Server “8” Beta Hyper-V Component Architecture Poster

Termine (ab 43:52)

Microsoft System Management Summit am 9. Mai in Hanau

Microsoft IT Camp Private Cloud am 10. Mai in Frankfurt

Online Event 24 Hours in a Private Cloud vom 10. bis 11. Mai

Consumerization of IT Jump Start am 15. und 16. Mai

IT-Administrator Training »Windows Server Best Practice am 15. Mai in Hamburg und am 19. Juni in Frankfurt

Hyper-V PowerKurs vom 21. bis 25. Mai in Hallenberg

base-it technews System Center 2012 – the entire suite am 22. Mai in Linz /Österreich

E2E Virtualisation Conference vom 25. bis 27. Mai in Wien / Österreich

Windows Server 2012 Community Roadshow am 29. Mai in Köln, am 19. Juni in Bad Homburg und am 22. Juni in Unterschleißheim

Veranstaltungsreihe Best of Microsoft 2012 am 4. Juni in Köln, am 6. Juni in Hamburg, am 11. Juni in Stuttgart und am 13. Juni in München

TechEd 2012 Northamerica vom 11. bis 14. Juni in Orlando / USA

TechED 2012 Europe vom 25. bis 29. Juni in Amsterdam / Niederlande

Hyper-V Community Treffen am 10. Juli in Düsseldorf

Hyper-V PowerKurs vom 2. bis 6. Juli in Hallenberg

Hyper-V PowerKurs vom 6. bis 10. August in Hallenberg

Ich komme gerade von einer Woche Powerkurs aus dem Süden Deutschlands wieder. Während des Kurses haben wir verschiedene Möglichkeiten und Optionen angesprochen, wie die Aufteilung des Netzwerks am sinnvollsten und am einfachsten gemacht werden kann. Auf zwei der Teilnehmer-Systeme konnte der jeweilige Teilnehmer nur auf eine physische Netzwerkkarte zurückgreifen, und zwar die auf dem Mainboard. Dies hat uns allerdings nicht davon abhalten können, die Systeme mit insgesamt sechs Karten installieren und einrichten zu können. Wie wir das gemacht haben? Mit einer ziemlich coolen Funktion im Windows Server 2012, der Netzwerkvirtualisierung.

Der Aufbau der während des Kurses erstellten Failovercluster wurde nach unseren Best Practises vorgenommen, d.h. es wurden insgesamt sechs Netzwerkkarten benötigt. Der gewünschte Aufbau des Netzwerks sollte wie folgt aussehen:

Da wir nur eine Karte zur Verfügung hatten, haben wir mit Hilfe der Netzwerkvirtualisierung weitere Karten erstellt. Im ersten Schritt wurde per PowerShell-Befehl ein Team erstellt, einziges Mitglied in diesem Team war der eine physisch vorhandene Adapter mit dem Namen “LAN-Adapter”.

Edit: Wie Hannes mit seinem Kommentar korrekt angemerkt hat, ist die Erstellung des Teams an dieser Stelle nicht unbedingt notwendig, die vNICs können auch direkt auf die nicht-geteamte Karte gesetzt werden. Die Erstellung eines Teams hat keine Vor- oder Nachteile, lediglich das man lernt wie die Erstellung per PowerShell funktioniert :)

New-NetLbfoTeam -Name “Team1″ -TeamNicName “Team1″ -TeamMembers LAN-Adapter -TeamingMode SwitchIndependent -LoadBalancingAlgorithm HyperVPort -Confirm:$false

Eine Beschreibung des Befehls mit allen Parametern und einer sehr guten Beschreibung findet ihr im TechNet: Microsoft TechNet: New-NetLbfoTeam

Nachdem wir das Team (mit nur einem Adapter, aber trotzdem nutzbar) erstellt haben, können wir eine Hyper-V Switch erstellen. Diese ist Grundlage für unsere Verbindung der VMs zur Außenwelt, zur Kommunikation des Hosts mit der Außenwelt sowie technische Grundlage für die Erstellung von virtuellen Netzwerkkarten, vNics genannt. Der Befehl lautet

New-VMSwitch “LAN” -MinimumBandwidthMode None -NetAdapterName “Team1″ -AllowManagementOS 1 -Confirm:$false

Hiermit erstellen wir eine neue Switch mit dem Namen “LAN”. Eine mögliche Bandbreitenreservierung aktivieren wir nicht, als Grundlage für diese virtuelle Switch wird “Team”1” genutzt. Hierbei ist es egal, ob es sich um eine physische Karte oder ein Team handelt. Wichtig ist in diesem Fall der Parameter “AllowManagementOS” mit dem Wert 1, dieser macht nichts anderes als wenn ihr im Hyper-V-Manager bei der Erstellung einer virtuellen Switch den Haken bei “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” setzt.

Nachdem die virtuelle Switch vorhanden ist, könnten wir nun sowohl mit unseren VMs und dem dem Host-Betriebssystem eine Kommunikation per Netzwerk aufbauen. Da wir im Host allerdings nur eine einzige Karte haben, müsste entweder die gesamte Kommunikation über diese eine Karte laufen, oder wir erstellen alternativ noch weitere Karten. Dies geschieht mit den folgenden Befehlen:

Add-VMNetworkAdapter -ManagementOS -Name “CSV” -SwitchName “LAN”
Add-VMNetworkAdapter -ManagementOS -Name “Livemigration” -SwitchName “LAN”
Add-VMNetworkAdapter -ManagementOS -Name “iSCSI” -SwitchName “LAN”
Add-VMNetworkAdapter -ManagementOS -Name “iSCSI2″ -SwitchName “LAN”

Nach dem Absetzen dieser Befehle haben wir uns vier weiteren Karten erstellt, die nun auch in der Systemsteuerung auftauchen und wie gewohnt administriert werden können. Die virtuelle Switch (in diesem Beispiel mit dem Namen “LAN”) könnt ihr im Hyper-V-Manager nun sehen, allerdings nicht bearbeiten. Löschen wäre übrigens möglich, falls ihr dies machen möchtest oder müsst.

Fazit: Diese wenigen Befehle reichen aus, um auf einem Host virtuelle Netzwerkkarten anlegen zu können. Die Aussage “Betrieb eines Clusters mit nur einer Netzwerkkarte” ist somit richtig, allerdings nur für Demo- oder Testumgebungen anwendbar. Die Nutzung von einem Team aus mehreren Karten (z.B. zwei oder vier 10GBit/s-Adapter) wäre denkbar, allerdings sollte hier unter anderem die Bandbreitenbeschränkung aufgenommen werden, damit die Versorgung aller vNics mit der benötigten Bandbreite garantiert werden kann.

Wenn alle hier aufgeführten PowerShell-Befehle untereinander in eine .ps1-Datei geschrieben werden, die Ausführung dieses Scripts auf dem PC/Server erlaubt ist und die Hardware-Karte “LAN-Adapter” heißt, könnten sogar mehrere Systeme mit nur einem Klick netzwerktechnisch eingerichtet werden. Coole Sache! :)

Der ein oder andere von Ihnen wird es über Facebook schon mitbekommen haben: Wir stellen aktuell unser Failover Cluster unter Windows Server 2012 von 1 GBit/s auf 10 GBit/s um. Durch diese Umstellung haben wir die Möglichkeit, die vorhandenen Karten als Team einzusetzen und so zum einen eine Erhöhung der Bandbreite bekommen, zum anderen eine Ausfallsicherheit. Die Erhöhung der Bandbreite wird sich positiv auf die Zeiten während einer oder mehreren Livemigrationen bemerkbar machen, da dies deutlich schneller ablaufen wird wie bisher.

Um Ihnen ebenfalls einen Mehrwert bei dieser Umstellung zu geben, werde ich den Vorgang mit diesem Artikel dokumentieren und erklären.

Aktuell sieht unsere Netzwerk-Konfiguration wie folgt aus:

Die Definition der Netzwerke ändert sich nicht, alle Netzwerke bleiben wie bisher auch bestehen. Was sich allerdings ändert ist die Aufteilung der Netzwerk-Adapter in den einzelnen Servern. Aktuell sieht dies in der Systemsteuerung so aus (Zur Info: Der eine Knoten hat 2x 10GBit und 2x 1GBit, der andere hat 2x 10GBit und 4x 1 GBit):

Nach der Umstellung soll das Netzwerk pro Cluster-Knoten die folgende Struktur haben:

Die Adapter “Intel(R) Gigabit 4P X540/I350 rNDC” und “Intel(R) Gigabit 4P X540/I350 rNDC #2” werden zu einem eigenen Team zusammengefasst und stehen mit insgesamt 2 GBit/s für die Kommunikation mit der Domäne, zum Management und für unser Veeam-Backup zur Verfügung. Die Adapter “Intel(R) Ethernet 10G 4P X540/I350 rNDC” und “Intel(R) Ethernet 10G 4P X540/I350 rNDC #2” werden zu einem eigenen Team zusammengefasst, basierend auf diesem Team wird eine Hyper-V Switch erstellt. Diese Switch steht zum einen für die VMs bereit, weiterhin werden basierend auf dieser Switch im Management-OS (das Host-Betriebssystem) virtuelle Netzwerkkarten (vNICs) erstellt. Diese stellen das Netzwerk für iSCSI, iSCSI2, CSV und Livemigration. Die Erstellung und Konfiguration von vNICs ist nur mit dem SCVMM oder per PowerShell möglich. In unserem Fall arbeiten wir mit der PowerShell.

Damit die einzelnen Netzwerke sich nicht gegenseitig behindern oder eine Karte den gesamten möglichen Traffic nutzen, wird mit Quality of Service (QoS) gearbeitet. Somit garantieren wir jedem einzelnen Netzwerk eine gewisse Bandbreite.

Nachdem nun der eine Knoten im Failovercluster-Manager mittels Livemigration leer geschoben wurde, wird das System mit Hilfe eines Skripts konfiguriert. Dieses Skript sieht wie folgt aus:

#Abfrage der End-IP-Adresse des Systems
$IP = Read-Host "Bitte geben Sie den vierten und letzten Bereich der IP-Adresse an (z.B. 101 fuer 192.168.210.101)"
 
#ConvergedSwitch-Team erstellen
New-NetLbfoTeam -Name Team01 -TeamMembers "10GbE #1","10GbE #2" -LoadBalancingAlgorithm HyperVPort -TeamingMode Lacp -Confirm:$false
#Management-Team erstellen
New-NetLbfoTeam -Name Team02 -TeamMembers "1GbE #1","1GbE #2" -LoadBalancingAlgorithm TransportPorts -TeamingMode SwitchIndependent -Confirm:$false
 
# Die virtuelle Switch erstellen, keine gemeinsame Verwendung
New-VMSwitch "VM" -MinimumBandwidthMode weight -NetAdapterName "Team01" -AllowManagementOS 0 -Confirm:$false
 
# Standard-Bandbreitenreservierung setzen
Set-VMSwitch "VM" -DefaultFlowMinimumBandwidthWeight 1
 
# Erstellen der virtuellen Netzwerkkarten
Add-VMNetworkAdapter -ManagementOS -Name "Livemigration" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "CSV" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "iSCSI" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "iSCSI2" -SwitchName "VM"
 
# Assign static IP addresses to the virtual network adapters
Set-NetIPInterface -InterfaceAlias "vEthernet (Livemigration)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (Livemigration)" -IPAddress 192.168.214.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (Livemigration)" -ComponentID ms_tcpip6 -Enabled $False
 
Set-NetIPInterface -InterfaceAlias "vEthernet (CSV)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (CSV)" -IPAddress 192.168.215.$IP –verbose
Set-NetAdapterBinding -Name "vEthernet (CSV)" -ComponentID ms_tcpip6 -Enabled $False
 
Set-NetIPInterface -InterfaceAlias "vEthernet (iSCSI)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (iSCSI)" -IPAddress 192.168.212.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_tcpip6 -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_msclient -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_server -Enabled $False
 
Set-NetIPInterface -InterfaceAlias "vEthernet (iSCSI2)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (iSCSI2)" -IPAddress 192.168.213.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_tcpip6 -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_msclient -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_server -Enabled $False
 
# QoS-Konfiguration der vNICs
Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "CSV" -MinimumBandwidthWeight 25 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "iSCSI" -MinimumBandwidthWeight 10 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "iSCSI2" -MinimumBandwidthWeight 10 -verbose
 
# Konfiguration des Management-Teams
Set-NetIPInterface -InterfaceAlias "Team02" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 23 -InterfaceAlias "Team02" -IPAddress 192.168.210.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias "Team02" -ServerAddresses ("192.168.210.2","192.168.210.4")
 
# Show VLanIDs on VMNetWorkAdapters
Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName *

Eine Kopie des Skripts als .txt-Datei finden Sie hier: ConvergedNetwork.txt

Nach der Ausführung des Skripts sieht die Netzwerk-Konfiguration des Hosts ein wenig anders aus:

Sie sehen die beiden Teams. Team01 steht mit insgesamt 20 GBit/s zur Verfügung, Team02 ist das Management-Team mit 2 GBit/s.

Wir haben aktuell zwei Failover Cluster laufen – einen für den Betrieb der virtuellen Server, den anderen zur Bereitstellung der Scale-Out Fileserver-Rolle. Im zweiten Cluster gibt es seit kurzem ein Problem mit dem folgenden Text

Protokoll-Name: System / Ereignis-ID: 1196 / Quelle: Microsoft-Windows-FailoverClustering / Benutzer: System

Ereignisdetails:

Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.
.

Stellen Sie sicher, dass die Netzwerkadapter, die mit den abhängigen IP-Adressressourcen verknüpft sind, für den Zugriff auf mindestens einen verfügbaren DNS-Server konfiguriert wurden.

Im DNS sieht der Eintrag für den Cluster-Namen in Bezug auf den Zeitstempel etwas veraltet aus

Die Lösung habe ich durch folgenden Beitrag bekommen: Microsoft TechNet Forum: Windows Server 2012 Failover Cluster (Hyper-V) Event Id 1196

Oguzhan İlkan BORAN schreibt, dass das Problem durch die Berechtigungen im DNS-Eintrag gelöst werden kann. Dieser sieht in meinem Fall wie folgt aus

Das unbekannte Konto sieht hier direkt auffällig aus, weiterhin fällt auf dass das Cluster-Computer-Objekt keine eigene Berechtigung hält. Dieses habe ich hinzugefügt und mit Vollzugriff ausgestattet

Nach kurzer Zeit hat sich der DNS-Eintrag in meinem Fall wieder aktualisiert und das Failover Cluster erzeugt keine weiteren Fehler mehr

Da ich gerade unseren Failover Cluster unter Windows Server 2012 R2 installiere und wir innerhalb unserer Umgebung auch mit der Replica-Funktion arbeiten möchten, muss die Rolle Hyper-V-Replikatbroker zum Failover Cluster hinzugefügt werden. Normalerweise funktioniert dies relativ einfach über den Menüpunkt Rolle konfigurieren… im Hauptmenü Rollen. In meinem Fall erzeugte dies allerdings einen Fehler, und ich konnte mich daran erinnern, dieses Problem unter Windows Server 2012 auch schon gehabt zu haben. Hier ein Screenshot der Konsole, in der die Rolle hinzugefügt werden kann:

Nach Eintragung von DNS-Name und IP-Adresse wird die Rolle im Cluster erzeugt. Leider konnte sie nach der Erstellung in meinem Fall nicht starten, sondern erzeugte die folgenden Fehlermeldungen:

Protokollname: System / Quelle: Microsoft-Windows-FailoverClustering / Ereignis-ID: 1194

Für die Cluster-Netzwerknamensressource “Replicabroker-Name” war es nicht möglich, das ihr zugeordnete Computerobjekt in der Domäne “domaene.loc” bei Folgendem zu erstellen: Ressource online.

Der zugehörige Fehlercode hat diesen Text: Es ist eine Beschränkungsverletzung aufgetreten.

Wenden Sie sich an den Domänenadministrator, um Folgendes sicherzustellen:
- Die Clusteridentität “Clusterobjekt$” hat die Berechtigung zum Erstellen von Computerobjekten. Alle Computerobjekte werden standardmäßig im selben Container erstellt wie die Clusteridentität “Clusterobjekt$”.
- Das Kontingent für Computerobjekte wurde nicht erreicht.
- Falls ein Computerobjekt vorhanden ist, überprüfen Sie mit dem Tool Active Directory-Benutzer und -Computer, ob die Clusteridentität “Clusterobjekt$” die Berechtigung “Vollzugriff” für das betreffende Computerobjekt hat.

Relativ schnell fiel mir ein, dass ich dieses Problem unter Windows Server 2012 auch schon hatte. Ursache hierfür ist eine fehlende Berechtigung in der Active Directory, ein Objekt anzulegen. Auf unserem DC habe ich zu diesem Zeitpunkt auch kein Objekt gefunden, welches den Namen trägt, den ich während der Einrichtung eingegeben habe. Ich habe an dieser Stelle die folgende Vorgehensweise durchgeführt:

Auf dem DV habe ich in der gewünschten OU ein Computerobjekt mit dem Namen angelegt, den auch der Broker bekommen soll. Nachdem das Objekt erstellt wurde, habe ich es deaktiviert und in den Sicherheitseinstellungen das Cluster-Objekt mit Vollzugriff hinzugefügt. Nachdem ich die Einstellungen gespeichert habe und die Replica-Rolle erneut angelegt, funktioniert die Einrichtung problemlos und die Rolle lässt sich wie gewünscht starten.

Im Erstell-Assistent der Failover Cluster-Rolle wird nun auch direkt die korrekte OU angezeigt, in der sich das vorab erstellte Objekt befindet

Die Erstellung der Rolle läuft nun erfolgreich durch, der Dienst kann genutzt werden.

Heute ist mir bei der Prüfung einer Failover Clusterinstallation ein alter Bekannter wieder untergekommen:

Protokollname: Microsoft-Windows-FailoverClustering/Diagnostic
Quelle:        Microsoft-Windows-FailoverClustering
Datum:         16.12.2013 11:07:41
Ereignis-ID:   2051
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      <hostname>.rachfahl.de
Beschreibung:
[RHS] s_RhsRpcCreateResType: (21)’ because of ‘Startup routine for ResType MSMQ returned 21.’

Die Suche ob dieser Fehler wichtig ist oder nicht, war gar nicht so einfach. Schließlich entdeckte ich diesen Blog Post “MSMQ Errors in the Cluster.log” von Elden Christensen. Elden ist Principal Program Manager im Microsoft Cluster Team und seine Aussagen sind “Gesetz”.

Quintessenz aus dem Artikel ist: Man kann den Fehler ignorieren, oder wenn er stört durch folgende zwei PowerShell Befehle entfernen:

Remove-ClusterResourceType MSMQ
Remove-ClusterResourceType MSMQTriggers

Dieser Artikel behandelt die Installation eines Failover Cluster unter Windows Server 2012 R2, welches zur Ausführung von Hyper-V VMs genutzt wird. Gegenüber den vorherigen Artikeln zur Einrichtung unter Windows Server 2008 R2 und Windows Server 2012 hat sich teilweise etwas geändert, das “Grundrauschen” ist allerdings gleich geblieben. Die größte Änderung liegt darin, dass durch unterschiedliche Techniken die Anzahl der Möglichkeiten enorm gestiegen sind. Dadurch gibt es nicht mehr “die eine” optimale Lösung, es muss nun anhand der jeweiligen Hardware entschieden werden, was die beste Lösung in diesem einen Fall ist. Zusätzlich habe ich an einigen Stellen noch die genutzten PowerShell-Befehle mit aufgeführt. Diese hier beschriebene Konfiguration eignet sich primär bei der Nutzung eines Scale-Out File Servers. Dieser ist bereits eingerichtet und in diesem Artikel wird nicht auf die Einrichtung eingegangen, dies wird komplett im zweiten Teil der Serie gemacht.

Egal was Sie einsetzen möchten, was Sie bereits haben oder wo Sie ansetzen: Sprechen Sie uns an, wir können diese Konfiguration gerne an Ihre Bedürfnisse anpassen.

Die genutzte Hardware

Die Demoumgebung

Die hier genutzte Hardware sind zwei Rechner aus unserem Hyper-V Powerkurs und einem Scale-Out Fileserver unter Windows Server 2012 R2 als SMB3-Ziel. Die Rechner besitzen zwei 1Gbit NICs und vier 10Gbit NICs, 24 GB RAM und eine Quadcore-CPU. Beide Server sind Mitglied der Active Directory powerkurs.local. Der Scale-Out File Server hat jeweils zwei 10Gbit-Ports für SMB3 und zwei 1Gbit-Ports zur Anbindung an die Active Directory pro Knoten.

Ein paar Worte zu der Hardware, den Verbesserungs- und den Sparmöglichkeiten

Diese hier beschriebene Konfiguration entsprecht von den Eckdaten her dem, was wir empfehlen und was wir bereits in Projekten mehrfach erfolgreich eingesetzt haben. Natürlich sollte als Server ein wirklicher Server zum Einsatz kommen, der für den 24/7-Betrieb geeignet ist. Von einer Nutzung von PCs oder Workstations ist natürlich absolut abzuraten, wegen der Verfügbarkeit habe ich diese Systeme aber als Demoumgebung genutzt.

Wir geben Ihnen als Empfehlung zwei 10Gbit-Adapter mit jeweils zwei Ports vor, d.h. jeder Hyper-V Host ist mit 40 Gbit angebunden, hinzu kommen noch zwei oder mehr 1 Gbit-Adapter. Diese Anbindung könnte theoretisch noch erhöht werden auf sechs 10 Gbit-Adapter, prinzipiell spricht hier nichts gegen. Dies bewirkt eine Erhöhung der Gesamtbandbreite, ändert aber nichts an der Performance der einzelnen Adapter. Hier kommen RDMA bzw. SMB Direct-Karten ins Spiel. Mit Hilfe dieser Technik können Sie eine deutliche Steigerung der Performance bei sehr geringer Latenz erreichen. Wenn alle Netzwerk-Komponenten diese Technik beherrschen haben Sie eine enorm hohe Bandbreite zwischen Hyper-V Failover Cluster und Scale-Out File Server. Informationen zu dem Thema gibt es unter anderem im Hyper-V Podcast Folge 35 von meinem Kollegen Carsten Rachfahl.

Wenn Sie nicht den Bedarf von 40 Gbit pro Knoten haben oder die Hardware bereits vorhanden ist, können Sie den Betrieb auch mit einer 10 Gbit DualPort-Karte realisieren. In diesem Fall wären die VMs mit zwei oder mehr 1 Gbit-Karten angebunden, die 20 Gbit ständen dann exklusiv für die Anbindung an den Storage zur Verfügung.

Die Installation und Einrichtung des Betriebssystems

Die Einrichtung beginnt mit einer frischen Installation eines Windows Server 2012 R2 in der Datacenter Edition auf beiden Hosts. Nach der Grundinstallation werden die Netzwerkkarten umbenannt und teilweise zu einem Team konfiguriert.

Beide 1Gbit-Adapter werden zu einem Team zusammengefasst, zusätzlich werden zwei 10Gbit-Adapter (jeweils auf einem der beiden Adapter) zu einem Team zusammengefasst. Das 2Gbit-Team wird als Management-Netzwerk genutzt, das 20Gbit-Team wird zur Anbindung der VMs an das Netzwerk genutzt. Insgesamt existieren vier Netzwerke, auf drei der Karten hat der Host eine eigene IP-Adresse. Das VM-Netzwerk wird exklusiv für die virtuellen Computer genutzt.

Die Konfiguration per PowerShell wäre wie folgt:

New-NetLBFOTeam -Name "Management-Team" -TeamNICName "Management-Team" -TeamMembers 1GBit#1, 1GBit#2 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

New-NetLBFOTeam -Name "VM-Team" -TeamNICName "VM-Team" -TeamMembers 10GBit#1, 10GBit#3 -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic -Confirm:$false

Die Karte Management-Team wird mit einer IP-Adresse im Bereich 192.168.209.0/24 konfiguriert. In meinem Fall arbeite ich mit den Systemen Hyperv10 und Hyperv15, daher bekommt Hyperv10 die Adresse 192.168.209.10 und Hyperv15 die Adresse 192.168.209.15. Die Endadresse bleibt in allen Netzen gleich, so kann eine eindeutige Zuordnung erfolgen. Eine gleichmäßige Zuweisung von Adressen sowie eine durchgängige Benamung machen den Betrieb und die Administration an vielen Stellen einfacher. Die Karte VM-Team wird zu diesem Zeitpunkt nicht konfiguriert, sie wird später als Hyper-V Netzwerk genutzt. Bei der Wahl der Adapter wird jeweils ein Adapter pro Hardware-Karte gewählt, dies ermöglicht einen Betrieb auch dann, wenn einer der beiden Hardware-Karten ausfallen würde. Die Bindungen der Karte werden nicht geändert und sehen wie folgt aus:

Die beiden 10Gbit-Adapter, die nicht Mitglied des Teams sind, werden mit einer IP-Adresse aus den Storage-Bereichen versehen. Hierbei achten wir ebenfalls darauf, dass die End-Adresse jeweils identisch ist mit der Adresse im Management-Netz. Nach der korrekten Konfiguration sehen die Eigenschaften der Karten wie folgt aus:

Unter IP-Einstellungen werden keine Änderungen vorgenommen, die Einstellungen der Karte 10GBit#2 (die zweite Storage-Karte) sind bis auf die IP-Adresse identisch.

Die Konfiguration per PowerShell:

Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#2" -IPAddress 192.168.208.10
Set-DnsClientServerAddress -InterfaceAlias "10GBit#2" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias "10GBit#2" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "10GBit#4" -IPAddress 192.168.207.10
Set-DnsClientServerAddress -InterfaceAlias "10GBit#4" -ServerAddresses 192.168.209.1
Set-NetAdapterBinding -Name "10GBit#2" -ComponentID ms_tcpip6 -Enabled $False

Beide Server werden nun auf den aktuellen Patchlevel geupdatet.

Nach der Installation und dem anschließenden Neustart kann die Einrichtung mit der Installation der Hyper-V Rolle fortgesetzt werden.

Über den Server-Manager oder per PowerShell kann nun die Hyper-V Rolle installiert werden. Bei der während der Installation durchgeführten Konfiguration wählen wir keine der Karten für das Hyper-V Netzwerk aus, dies wird im späteren Verlauf manuell konfiguriert. Die Livemigration wird nicht konfiguriert, bei der Wahl der Pfade wird ebenfalls an dieser Stelle keine Änderung vorgenommen. Das System startet nun zwei Mal durch und steht danach wieder zur Verfügung.

Alternativ kann die Installation natürlich auch per PowerShell gemacht werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart

Wenn der Parameter –ComputerName noch mit angegeben wird können sogar alle Server fast gleichzeitig installiert werden:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools –Restart -ComputerName Hyperv10

Die Einrichtung von Hyper-V zur Vorbereitung auf den Betrieb als Failover Cluster-Knoten

Nach der Installation von Hyper-V müssen noch ein paar lokale Einstellungen vorgenommen werden, bevor das Failover Cluster eingerichtet werden kann. Im Hyper-V-Manager werden auf beiden Systemen unter dem Manager für virtuelle Switches eine neue externe Switch erstellt und auf den VM-Team-Adapter gebunden. Achten Sie darauf, den korrekten Adapter auszuwählen.

Wie Sie die virtuelle Switch nennen ist Ihnen überlassen, wichtig ist das sie auf allen Hyper-V Hosts gleich heißt. Achten Sie zusätzlich unbedingt darauf, nicht die gemeinsame Verwendung zu aktivieren. Bei Nutzung der gemeinsamen Verwendung bekommt der Host eine weitere, virtuelle Netzwerkkarte, die nicht benötigt und nicht gewollt ist. Der PowerShell-Befehl hierzu ist:

New-VMSwitch -Name "VM" -NetAdapterName VM -AllowManagementOS 0 -ComputerName Hyperv10

Danach kann Hyperv10 durch den Namen des zweiten Knoten ersetzt werden.

Die Installation und Einrichtung des Failover Cluster

Nachdem nun die Vorbereitungen abgeschlossen sind können wir mit der Installation und Einrichtung des Failover Cluster beginnen.

Die Installation der benötigten Features

Für die Einrichtung eines Failover Cluster wird das Feature Failoverclustering benötigt

Wenn Sie das System lokal administrieren möchten oder müssen sollten Sie die Failovercluster-Verwaltungstools sowie das Failoverclustermodul für Windows PowerShell ebenfalls installieren

Per PowerShell:

Install-WindowsFeature Failover-Clustering –IncludeAllSubFeature –IncludeManagementTools -ComputerName Hyperv10

Die Einrichtung des Failover Cluster

Nach der Installation öffnen Sie den Failovercluster-Manager und beginnen mit dem Menüpunkt Konfiguration überprüfen….

Im Assistenten fügen Sie die Server hinzu, die überprüft werden sollen (Tipp: das lokale System kann mit einem Punkt ( . ) oder “localhost” hinzugefügt werden)

Danach können Sie auswählen, welche Tests durchgeführt werden sollen. Falls dies der erste Durchlauf ist sollten Sie unbedingt alle Tests auswählen, falls Sie nur einen oder mehrere spezielle Tests durchführen möchten (z.B. bei einem erneuten Durchlauf) können Sie diese manuell auswählen.

Es werden nun alle Tests durchgeführt, dies dauert je nach Anzahl der Server.

Nach dem Durchlauf erhalten Sie eine Übersicht der Tests und haben die Möglichkeit, sich den kompletten Bericht anzeigen zu lassen.

Schauen Sie sich unbedingt die Warnungen und Fehler an. Je nach Art der Fehler können diese entweder ignoriert werden oder sie müssen aktiv korrigiert werden. In meinem Fall steckte ein Kabel in einem falschen VLAN, wodurch die folgende Meldung in dem Bericht auftaucht:

Solche Fehler werden meist durch den Assistenten erkannt und angemerkt, eine Behebung vor der Erstellung und Nutzung des Failover Cluster macht deutlich mehr Spaß als die nachträgliche Suche.

Andere Warnungen können ggf. ignoriert werden, z.B. ein fehlender Datenträger oder eine permanente SCSI-3-Reservierung. Da wir mit SMB3-Shares arbeiten sind keine Datenträger im Failover Cluster vorhanden.

Wenn keine Fehler während der Überprüfung auftauchen aktiviert der Assistent direkt die Möglichkeit, den Failover Cluster mit den überprüften Knoten zu erstellen

Während der Erstellung werden wir nach dem Namen des Failover Cluster und der IP-Adresse gefragt, unter der eine Administration möglich ist. Die Frage nach dem Netzwerk erscheint nur, weil keine der Netzwerkkarten ein Gateway eingetragen hat. Sobald ein Gateway vorhanden ist wird automatisch dieses Netzwerk als Zugriffspunkt definiert.

Wir benötigen in unserem Fall eine IP-Adresse im Netzwerk 192.168.209.0/24 und einen eindeutigen Namen

Nach einem Klick auf Weiter wird überprüft, ob Name und IP-Adresse bereits vorhanden bzw. belegt sind, falls dies nicht der Fall ist erscheint eine Übersicht über die getätigten Einstellungen.

Die Option Der gesamte geeignete Speicher soll dem Cluster hinzugefügt werden bewirkt an dieser Stelle keine Änderung, da keine Datenträger hinzugefügt wurden. Wir haben uns angewöhnt diese Option grundsätzlich zu deaktivieren, da wir den Speicher manuell zuweisen wollen. Nach einem Klick auf Weiter wird der Cluster erstellt, danach verbindet sich der Failovercluster-Manager automatisch mit dem gerade erstellten Cluster. In der Zusammenfassung bekommen wir noch einen Hinweis angezeigt, dass kein geeigneter Datenträgerzeuge vorhanden ist. Um diese Einstellungen kümmern wir uns später.

Die Konfiguration des Netzwerks

Die ersten Anpassungen im gerade erstellten Cluster werden im Netzwerk gemacht. Die Netze werden automatisch durchnummeriert, diese Namen ändern wir auf die Funktion des einzelnen Netzwerks.

Um welches Netz es sich handelt können Sie sehen, wenn Sie auf das Netzwerk klicken und im unteren Teil auf den Reiter Netzwerkverbindungen wechseln.

Das Ergebnis sind drei vollständig benannte Netzwerke. Die Eigenschaften der Karten sehen wie folgt aus:

In den Einstellungen für Livemigration muss nun die Reihenfolge der Netzwerke definiert werden, über die eine Livemigration gemacht wird.

Hier werden die beiden Storage-Karten als primäre Karten definiert und in der Reihenfolge nach oben geschoben, falls dies nicht automatisch der Fall ist. Der Adapter Management bleibt ebenfalls aktiviert, wird aber ganz nach unten verschoben.

Als nächstes muss die Metrik der Netzwerke im Failover Cluster definiert werden. Die Metrik bestimmt, über welches Netzwerk die Daten während eines umgeleiteten Modus zwischen den einzelnen Knoten laufen. Diese Einstellung kann ausschließlich per PowerShell ausgelesen und gesetzt werden, eine Administration per GUI ist nicht möglich. Öffnen Sie eine administrative PowerShell oder die PowerShell ISE und nutzen Sie die folgenden Befehle zum Auslesen und manuellen Setzen der Werte.

Get-ClusterNetwork | ft Name, Metric, AutoMetric

Je kleiner die Metrik, desto höher ist die Priorität. Standardmäßig wird in dem oberen Screenshot das Netzwerk Storage2 genutzt, da die Metrik 30240 die kleinste der drei ist. Grundsätzlich ist diese Reihenfolge (Erst Storage2, dann Storage1 und dann Management) in Ordnung, wir möchten aber gerne die Prioritäten manuell auf die folgenden Werte setzen:

Die entsprechenden Befehle dazu sind

(Get-ClusterNetwork "Storage1").Metric = 100
(Get-ClusterNetwork "Storage2").Metric = 101
(Get-ClusterNetwork "Management").Metric = 110

Diese Einstellungen müssen nur auf einem der Knoten gemacht werden, da hier clusterweite Einstellungen verändert und konfiguriert werden.

Die folgende Einstellung muss auf jedem Cluster-Knoten gesetzt werden, da es sich um eine lokale Einstellung handelt. Wechseln Sie in die Netzwerkverbindungen und wählen Sie in der Menüleiste (Falls nicht sichtbar “Alt” drücken) unter Erweitert die Option Erweiterte Einstellungen….

Schieben Sie dort den Adapter Management-Team ganz nach oben.

An dieser Stelle sind wir mit der Konfiguration des Netzwerks lokal und im Cluster fertig.

Die Einrichtung des Datenträgerzeugen / Quorum

Ganz wichtige Änderung unter Windows Server 2012 R2 in Bezug auf das Quorum: Erstellen Sie immer (egal welche Anzahl von Knoten und ob gerade oder ungerade) ein Quorum und weisen Sie dieses auch immer! zu. Das Failover Cluster verwendet dieses Quorum dynamisch, und zwar immer nur dann wenn es eins benötigt. Weitere Informationen und eine Bestätigung seitens Microsoft finden Sie im Technet: What’s New in Failover Clustering in Windows Server 2012 R2.

Da wir bei der Nutzung eines Scale-Out File Server keine CSV-Datenträger in unserem Failover Cluster haben müssen wir eine Dateifreigabe verwenden. Es existieren zu diesem Zeitpunkt drei Freigaben auf dem Scale-Out File Server. Die Freigabe HVQuorum wird für den Hyper-V Failover Cluster genutzt.

Wechseln Sie im Hauptmenü des Failover Cluster unter Weitere Aktionen auf Clusterquorumeinstellungen konfigurieren….

Es öffnet sich ein Assistent, der Sie bei der Einrichtung unterstützt. Nach der Vorbemerkung werden Sie nach der Art der Einrichtung gefragt. Die erste Option Standardquorumkonfiguration verwenden ist in diesem Fall nicht möglich, dies führt dazu das kein Quorum verwendet wird. Wir nutzen daher die zweite Option Quorumzeugen auswählen.

Im nächsten Schritt werden Sie nach der Art des Quorum gefragt, hier wählen Sie die Option Dateifreigabezeuge konfigurieren.

Schreiben oder Kopieren Sie nun den Pfad der Freigabe in den Assistenten.

Bestätigen Sie die Einstellungen und schließen Sie den Assistenten ab.

Nachdem Sie die Einrichtung abgeschlossen haben können Sie sehen, dass an besagtem Ort nun ein Ordner erstellt wurde, in dem eine Textdatei liegt.

Kurze Zeit später erscheint eine zweite Datei

Die Konfiguration ist nun abgeschlossen.

Die Einrichtung von Bandbreitenmanagement für SMB-Traffic

Wenn, wie in unserem Fall, die Livemigration und der Storage-Traffic über eine Leitung laufen, könnte dies ungewünschte Folgen bei vielen gleichzeitigen Livemigrationen haben. Zusätzlich werden Daten zwischen den einzelnen Hosts ebenfalls über diese Netze gesendet (Metric-Konfiguration weiter oben, bei der Storage1 die geringste Metric besitzt. In solch einem Fall können wir ein Bandbreitenmanagement für SMB-Traffic einführen. Die Installation kann auf Wunsch per Server-Manager gemacht werden, die Konfiguration muss allerdings zwingend per PowerShell gemacht werden. Das Feature versteckt sich hinter dem Namen SMB Bandwidth Limit.

Die Installation per PowerShell erfolgt mit dem Befehl

Add-WindowsFeature FS-SMBBW

Nach der Installation erfolgt die Einrichtung per PowerShell. Um die Livemigration auf z.B. 8 Gbit/s zu begrenzen, kann der folgende Befehl angewendet werden

Set-SmbBandwidthLimit -Category LiveMigration -BytesPerSecond 1000MB

Als Kategorie steht neben LiveMigration noch VirtualMachine und Default zur Verfügung.

Die Nutzung von SMB Multi Channel

Wir nutzen in unserem Fall mehrere Wege zu unserem Scale-Out File Server, daher haben wir beim Netzwerk-Design und bei der Einrichtung weiter oben zwei Storage-Karten konfiguriert. Grundsätzliches zum Thema SMB3 hat Carsten unter anderem in diesem Video gezeigt und erklärt: Hyper-V-Server.de: Videocast rund um Hyper-V auf SMB. Damit die Multi Channel-Funktionalität in einem Failover Cluster (egal ob Hyper-V oder Scale-Out File Server) greift, müssen sich die Storage-Karten in unterschiedlichen Subnetzen befinden. Multi Channel in einem Subnetz funktioniert nur bei Konfigurationen, in dem das Failover Cluster-Feature noch nicht installiert ist.

Ich habe aktuell die Anfrage eines unserer Kunden, bei dem eine Änderung der Active Directory von einer .local-Endung auf eine .de-Endung erfolgen soll. Bei der Domäne handelt es sich um eine recht kleine Umgebung ohne weitere Namen oder Vertrauensstellungen usw. Da allerdings zwei Failover Cluster vorhanden sind und ich solch eine Umbenennung noch nie durchgeführt habe wurde der Transfer vorher mit einer Kopie unserer Schulungs-Umgebung powerkurs.local vorgenommen. In die AD powerkurs.local wurde ein Zwei-Knoten Scale-Out File Server und zwei Hyper-V Hosts installiert. Der Scale-Out File Server stellte mehrere SMB3-Shares zur Verfügung, die Hyper-V Hosts führten mehrere VMs aus, die sowohl lokal als auch auf den SMB3-Shares gespeichert waren.

Grundsätzlich gilt: Nur weil diese Art von Transfer technisch möglich ist heißt es nicht, dass dies die empfohlene Vorgehensweise ist. Installieren Sie wenn möglich eine neue Active Directory! Spätere Probleme oder Probleme bei der Umbenennung können natürlich immer auftreten. Die hier beschriebene Vorgehensweise erfolgt auf eigenes Risiko!

Als Vorlage für diesen Vorgang standen mit zwei Blogartikel sowie der TechNet-Eintrag von Microsoft zur Verfügung:

Ricky in Melbourne: How to rename your single active directory domain

Simple Guide : How to Rename Domain Name in Windows Server 2012?

Microsoft TechNet: Managing Active Directory Domain Rename

In dem ersten Artikel wird empfohlen, die Umbenennung auf einem Member-Server durchzuführen, in dem zweiten wird die Umbenennung direkt auf dem AD-Controller vorgenommen. Ich habe mit einem Member-Server angefangen, musste dann aber auf den DC selbst wechseln, da ab einem bestimmten Zeitpunkt keine Verbindung mehr möglich war (Member in alter AD, AD-Controller in neuer AD). Falls Sie auf einem Member-Server beginnen brauchen Sie die Active Directory Domain Services-Rolle und die entsprechenden Management-Tools, eine Einrichtung dieser Rolle ist nicht notwendig.

Erstellen Sie danach auf dem DC eine neue Zone im DNS mit dem Namen der neuen AD. Die vorhandene Zone ist powerkurs.local, die neue Zone ist powerkurs.de.

Bei der neuen Zone handelt es sich um eine primäre Zone, die in der AD gespeichert wird

Die Replikation erfolgt zu allen DNS Servern in diesem Forest

Vergeben Sie nun den Namen der neuen Zone, in meinem Fall powerkurs.de

Bei den dynamischen Updates dürfen nur sichere Aktualisierungen innerhalb der AD gemacht werden

Danach bekommen Sie noch eine Zusammenfassung und die Erstellung kann beginnen. Im nächsten Schritt kann die Umbenennung der AD beginnen. Öffnen Sie eine administrative cmd (entweder auf dem Server, auf dem Sie die Rolle installiert haben oder direkt auf einem DC) und wechseln Sie in das Verzeichnis, an dem die Datei erstellt werden soll. Ich wähle hier C:\system. Führen Sie nun den Befehl

rendom /list

aus und öffnen Sie danach die Datei domainlist.xml in einem Texteditor.

Ersetzen Sie nun in dieser Datei den Namen der alten Domäne mit dem Namen der neuen und den alten NetBiosName mit dem neuen (falls sich dieser ändert, in meinem Fall bleibt er gleich).

Speichern Sie die Datei ab und führen Sie in der noch geöffneten Eingabeaufforderung den Befehl

rendom /showforest

aus.

Laden Sie die Datei mit dem Befehl

rendom /upload

hoch.

Nun bereiten Sie den Umbenennungs-Vorgang mit dem Befehl

rendom /prepare

vor.

Letztendlich ausführen können Sie den Vorgang mit dem Befehl

rendom /execute

Auf Ihrem AD-Controller sehen Sie nun, dass das Systen neu startet.

Wenn Sie sich nun nach dem Neustart an dem Server anmelden möchten per RDP, erhalten Sie eine Warnung bzgl. des Zertifikats.

An diese Stelle musste ich nun auf den DC selbst springen, da eine Ausführung der folgenden Befehle auf meinem Member-Server nicht mehr möglich war. Starten Sie mit dem Ausführen von

gpfixup /olddns:powerkurs.local /newdns:powerkurs.de

Die Ausführung zur Änderung des NetBiosNamen bringt in meinem Fall einen Fehler, da sich dieser Name nicht ändert

gpfixup /oldnb:powerkurs /newnb:powerkurs

Mit den Befehlen

netdom computername dc01.powerkurs.local /add:dc01.powerkurs.de

und

netdom computername dc01.powerkurs.local /makeprimary:dc01.powerkurs.de

fügen Sie einen neuen Namen hinzu und setzen diesen danach primär.

Nach einem erneuten Neustart sehen Sie, dass sich der Name der VM nun geändert hat

Innerhalb der VM hat sich der Name der Domäne nun auch geändert

An dieser Stelle habe ich nun den Server, auf dem ich die rendom-Befehle ausgeführt habe, neugestartet. Das System war nach dem Neustart Mitglied der powerkurs.de-Domäne. Die Ausführung von

rendom /clean

hat aber trotzdem nicht funktioniert, als Ausgabe habe ich eine Fehlermeldung erhalten

Ich habe nun an dieser Stelle die Dateien, die sich auf dem lokalen Server unter C:\system befanden, auf den AD-Controller kopiert und den Befehl

rendom /clean

dort erneut ausgeführt. Dieses Mal lief der Vorgang erfolgreich durch.

Nun habe ich im DNS die Zone powerkurs.local gelöscht.

Nun habe ich alle Server, die Mitglied der AD sind, durchgebootet. Nach dem Neustart der Scale-Out File Server-Knoten bot sich im Manager die folgende Ansicht:

Das Failover Cluster ist erfolgreich gestartet, der Name und die IP-Adresse ist online und der Storage kann ebenfalls gemountet werden.

Einzig die Dateiserver-Rolle war nicht gestartet. Dies könnte aber daran liegen, dass ich diese vor Beginn der Umbauarbeiten manuell gestoppt habe.

Ein manueller Start war erfolgreich, danach waren die Freigaben auch wieder erreichbar.

Ich habe nun überprüft ob sich alle VMs starten lassen und Zugriff auf Ihre Dateien bekommen, dies war der Fall. Alle Test-VMs auf dem SOFS sowie den VMs auf den lokalen SSDs ließen sich problemlos starten und nutzen.

Zum Abschluss stehen noch ein paar weitere Aktionen an, welche die Übernahme dann noch etwas runder machen:

• Überprüfung auf korrekte Eintragung aller Netzwerkkarten im DNS-Server
• Anpassung der RDP-Zertifikate zur Vermeidung der Warnungen bei einer Verbindung
• Schwenk der unterschiedlichen Rollen, Datenträger usw. im Failover Cluster
• Falls vorher vorhanden: Neu-Erstellung des Hyper-V Failover Cluster
• Durchsuchen der Eventlogs nach möglichen Fehlern oder Problemen
• Anmeldung an allen Systemen zur Überprüfung auf korrekte Verbindung zur AD, ggf. mit einem neuen Benutzer
• Falls mehrere DCs vorhanden sind sollten Sie die Replikation zwischen den Systemen prüfen

Ich möchte noch einmal darauf hinweisen, dass diese Art des “Umzugs” nicht der bevorzugte Weg ist und wir, wenn möglich, eine Neu/Parallel-Installation bevorzugen.

Wir haben in letzter Zeit einige Erfahrungen beim Aufbau und Betrieb von diversen Scale-Out File Server Failover Clustern sammeln können. Ich habe im Mai letzten Jahres bereits einen Artikel über die Best Practises beim Aufbau eines Scale-Out File Server beschrieben (Unsere Best Practise-Erfahrungen – Teil 2 – Die Installation und Einrichtung eines Scale-Out Fileserver unter Windows Server 2012 R2), hier kommen nun noch einmal ein paar Dinge hinzu. Wir haben die folgenden Informationen teilweise direkt von Microsoft erhalten, teilweise sind es Erfahrungen die wir in Projekten gesammelt haben und manchmal ist es eine Mischung aus beidem.

Die SAS MPIO Policy

Wenn Sie einen Scale-Out File Server mit JBODs betreiben, sollten diese redundant per SAS angebunden sein. Damit die unterschiedlichen Wege zu den einzelnen Datenträgern nicht jeweils einen Datenträger pro Verbindung anzeigen, ist die Installation und Aktivierung von MPIO für SAS Pflicht. Wenn Sie Festplatten in Ihren JBODs verbaut haben (d.h. drehende Speichermedien, keine SSDs ausschließlich) sollten Sie die MPIO-Policy für SAS umstellen. Mit dem PowerShell-Befehl

Get-MSDSMGlobalDefaultLoadBalancePolicy

können Sie den aktuellen Status abrufen. Dieser steht bei einer Konfiguration, an der keine Änderungen vorgenommen wurden, auf None. Dies sollte umkonfiguriert werden, da es teilweise bei der Nutzung der automatischen Einstellung (None bedeutet, dass die Standard-Policy genutzt wird, in den allermeisten Fällen RoundRobin) zu erheblichen Performance-Einbrüchen kommt. Setzen Sie die Policy auf jedem Server (mit der RTM-Version von Windows Server 2012 R2 war dies noch eine clusterweite Einstellung, dies hat sich geändert) um auf den Wert FOO (FailOverOnly). Der komplette Befehl hierzu lautet

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy FOO

Überprüfen Sie die Einstellung erneut mit dem Befehl weiter oben.

Verwenden Sie immer die aktuellsten Treiber und Firmware-Stände

Wir haben festgestellt, das neuere Firmware-Stände von SAS HBAs, SSDs oder Enclosures sowie aktuellere Treiber enormen Einfluss auf den Betrieb und die Performance haben. Dies liegt vermutlich daran, dass die Komponenten noch nicht allzu lange verfügbar sind und daher noch Optimierungen und Anpassungen vorgenommen werden, die deutlichen Einfluss haben. Überprüfen Sie in regelmäßigen Abständen, ob es neue Treiber/Firmware/Software für Ihre Umgebung gibt. Dies gilt besonders für die Firmware der SSDs, falls Sie einen getierten Storage betreiben.

Achten Sie auf die Performance-Einstellungen Ihrer Server

In den meisten BIOS-Einstellungen von Hardware-Systemen gibt es die Möglichkeit, die Performance-Einstellungen der Hardware (insbesondere die der CPU) über Profile zu konfigurieren. Achten Sie darauf, dass Ihre Scale-Out File Server Hosts auf “Full Performance”, “Maximum Performance” oder wie der Hersteller Ihres Servers es auch immer nennt, betreiben. In einem Fall hat sich diese Einstellung bei Hosts (vermutlich durch ein BIOS-Update) auf einen Mixed-Mode zurückgestellt. Das Ergebnis war eine deutliche Erhöhung der Zeit, die für nächtlich Aufgaben benötigt wurden. Achten Sie sehr genau auf diese Einstellung, hier geht es im schlimmsten Fall um eine Erhöhung der Zeit um 250%. Bei eigentlich fünf Stunden macht sich diese Einstellung schon deutlich bemerkbar.

Deaktivieren Sie TRIM auf Ihren Systemen

Wenn Sie neben Festplatten noch SSDs oder ausschließlich SSDs in Ihrem Storage Cluster nutzen, sollten Sie die “TRIM und Unmap”-Funktion deaktivieren. In diesem Dokument, welches sich leider nur sehr schwer finden lässt, wird beschrieben, dass die Performance bei aktiver “TRIM und Unmap”-Nutzung sinken kann.

Deaktivieren können Sie die Funktion mit dem Befehl

fsutil behavior set disabledeletenotify 1

Nach dem Setzen der Einstellung (auf jedem SOFS Cluster-Knoten) müssen die Server neugestartet werden. Teilweise wird diese Funktion direkt in den SSDs bereit deaktiviert, je nach Firmware-Version. Seagate hat vor kurzem Version 006 der SSD-Firmware (für unsere SSDs z.B.) veröffentlicht, hier ist TRIM von Haus aus deaktiviert. SanDisk hat mit der Version 326 ebenfalls eine Firmware veröffentlicht, in der TRIM deaktiviert ist.

Installieren Sie benötigte Hotfixes

Microsoft hat ein Hotfix veröffentlicht, welches eine neue Version der TCPIP.sys einspielt. Ein Kunde hatte das Problem, das vereinzelt Bluescreens in der Umgebung aufgetreten sind mit der Meldung

UNEXPECTED_KERNEL_MODE_TRAP (7f)

Der Hotfix ist hier zu finden: Crash on Windows 8.1 or Windows Server 2012 R2 when a WPF driver calls the FwpsConstructIpHeaderForTransportPacket0 function

Wir stoßen bei unserer Arbeit immer wieder auf die Situation, dass der Kunde bereits ein Hyper-V Failover Cluster und einen Scale-Out Files Server im Einsatz hat und diese beiden Systeme jetzt über den Virtual Machine Manager 2012 R2 verwalten möchte. Daher habe ich mich mit der Frage beschäftigt, welche Voraussetzungen  notwendig sind, um einen bereits existierenden Scale-Out File Server (SOFS) im Virtual Machine Manager 2012 R2 hinzuzufügen und was dabei zu beachten ist.

Hier die Voraussetzungen, die bei uns in der Labor- und Produktivumgebung notwendig waren.

1. Wir benötigen einen Domain Account der als RunAsAccount im Virtual Machine Manager 2012 R2 angelegt wird – er heißt z.b. SVMM-Admin. Es reichen hierfür die normalen Domain-Benutzer Berechtigungen im Active Directory aus.
   
2. Dieser SCVMM-Admin darf nicht mit dem Service Account für den “System Center Virtual Machine Manager” Dienst identisch sein.
   
3. Der SCVMM-Admin muss auf allen Hyper-V Hosts und auf allen Scale-Out File Server Knoten lokaler Administrator sein.
   
4. Mit dem RunAsAccount des SCVMM-Admin muss das Hyper-V Failovercluster in den Virtual Machine Manager 2012 R2 hinzugefügt werden.
   
5. Bei den SOFS-Freigaben müssen alle Hyper-V Hosts + das Hyper-V Clusterkonto einzeln (Gruppenberechtigungen funktionieren an dieser Stelle nicht) mit Vollzugriffsrechten berechtigt sein und auch der SCVMM-Admin benötigt Vollzugriffsrechte auf die SOFS-Freigaben.
   
6. Die SMB Netze des Scale-Out File Servers sollten sie nicht in den DNS eintragen, da es sonst im Virtual Machine Manager 2012 R2 zu Problemen mit der Namesauflösung kommt.
   

Sind diese Voraussetzungen alle gegeben, können wir das Scale-Out File Server Cluster im Virtual Machine Manager 2012 R2 hinzufügen.

Dies kann über “Add Resources” oder aber  unter “Fabric” “Storage” Rechtsklick “Add Storage Devices” erfolgen.

Hier wählen wir “Windows-based file Server” aus

An dieser Stelle wird der FQDN des Scale-Out File Server Clusters eingegeben und der RunAsAccount ausgewählt, mit dem auch der Hyper-V Failover Cluster in den SCVMM hinzugefügt worden ist. In unsrem Fall der SCVMM-Admin.

Für den Pool müssen wir eine Storage Classification angeben – diese können wir unter “Create classification” erstellen.

Es werden nur SOFS-Freigaben vom Virtual Machine Manager 2012 R2 verwaltet, wenn diese beim Hinzufügen auch ausgewählt werden. ACHTUNG!!! beim Entfernen des SOFS aus dem Virtual Machine Manager 2012 R2 – löscht der VMM bei allen verwalteten SOFS-Freigaben die Freigabe. Wenn dies nicht gewünscht ist, muss in den Eigenschaften jeder verwalteten SOFS-Freigabe der Hacken bei

entfernt werden.

Umgekehrt gilt, wenn Sie am SOFS weitere Applikationsfreigaben anlegen, werden diese nicht automatisch vom Virtual Machine Manager 2012 R2 verwaltet. Sondern erst, wenn in den Eigenschaften der Freigabe der Hacken bei “File share managed by Virtual Machine Manager” gesetzt wird. Erst dann kann diese SOFS-Freigabe auch dem Hyper-V Failover Cluster und jedem anderen Hyper-V Host zugeordnet werden.
Hier können Sie überprüfen welche SOFS-Freigabe durch den Virtual Machine Manager 2012 R2 verwaltet wird.

Jetzt kann den Hyper-V Hosts das Storage zugewiesen werden.
Handelt es sich hierbei um ein Hyper-V Failover Cluster, erfolgt dies in den Eigenschaften des Failover Clusters.
Bei den einzelnen Cluster Hosts ist die Möglichkeit unter Storage den File Share hinzu zufügen ausgegraut

Wir wählen also in den Hyper-V Failovercluster Eigenschaften “File Share Storage” aus und fügen die gewünschten SOFS-Freigaben hinzu. Es werden an dieser Stelle nur die SOFS-Freigaben angezeigt, die auch durch den VMM verwaltet werden!

Soll einem einzelnen Hyper-V Host die SOFS-Freigabe zur Verfügung gestellt werden, so rufen Sie die Eigenschaften am Hyper-V Host auf und wählen “Storage” aus.

Hier kann über “Add” “Add File Share” aufgerufen werden. Jetzt kann rechts der Freigabe Pfad ausgewählt werden, mit “OK” bestätigen und schon steht auch diesem Hyper-V Host der Speicherplatz zur Verfügung – Voraussetzung hierfür ist, dass dieser Hyper-V Host im SBM Netz ist.

Wenn alles erfolgreich war, werden in den Hyper-V Failover Cluster Properties unter File Share Storage die Fileshares angezeigt

und auch an jedem Hyper-V Cluster Knoten unter Properties\Storage – File Shares.

Hier noch als Ergänzung die Powershell Befehle, mit denen eine SOFS-Freigabe als verwaltete Freigabe im Virtual Machine Manager 2012 R2 hinzugefügt werden kann.

$FileServer = Get-SCStorageFileServer -Name “FileServer01.Contoso.com”
$FileShare = Get-SCStorageFileShare -Name “FileShare01″
Set-SCStorageFileServer -StorageFileServer $FileServer -AddStorageFileShareToManagement $FileShare

Und wenn SOFS-Freigaben im Virtual Machine Manager nicht mehr verwaltet werden sollen, dann können folgende Powershell Kommandos abgesetzt werden.

$FileServer = Get-SCStorageFileServer -Name “FileServer01.Contoso.com”
$FileShare = Get-SCStorageFileShare -Name “FileShare01″
Set-SCStorageFileServer -StorageFileServer $FileServer -RemoveStorageFileShareFromManagement $FileShare

Quelle: Set-SCStorageFileServer

Am letzten Tag der Microsoft Ignite Konferenz im Mai 2015 in Chicago sah ich eine Session mit Rob Hindman und Ben Armstrong über “Rolling Cluster Upgrade” in Windows Server 2016 (Upgrading Your Private Cloud to Windows Server 2012 R2 and Beyond!). Im Anschluss an den Vortrag habe ich die Chance beim Schopfe gepackt und Rob Hindman über das Feature interviewt.

Leider machte mir der Sound Schwierigkeiten, das Interview ist hoffentlich trotzdem interessant.

In der Folge 10 des Hyper-V Amigos Showcast sprechen Didier und ich über einige Neuerungen im Windows Server 2016 Failover Cluster. Es ist ein Preview auf seinen Vortrag von der kommenden Cloud & Datacenter Conference Germany auf der Didier über das Thema sprechen wird.

Natürlich lassen wir es uns auch nicht nehmen über die Konferenz und deren Sprecher Lineup zu berichten. Und zum Schluss erzählen wir von unser gemeinsames Videoerlebnis am Grand Canyon.

Ich hoffe ihr habt Spaß beim Zuschauen.

Hier sind noch die im Showcast erwähnten Links:

• Recording of Didiers Session at the Technical Summit 2014: Improvements in Failover Cluster 2012 R2
• Cloud & Datacenter Conference Germany
• Didier and my Grand Canon Video: Hyper-V Amigos Chat at the Grand Canyon

Diesen Sommer gibt es noch zwei IT Camps mit Bernhard Frank und mir zum Thema Virtualisierung mit Windows Server 2016. Wenn Ihr also an den neuen Möglichkeiten in Hyper-V, Failoverclustering und Software Defined Storage in Windows Server 2016 interessiert seid, dann habt ihr hiermit die einmalige Möglichkeit an einem kostenlosen Hands-on Workshop teilzunehmen. Wer nicht weiß was ein IT Camp ist sollte sich das Video mit mir anschauen.

Wer kurzentschlossen ist und noch teilnehmen möchte findet die Anmeldelinks zu den beiden Camps in Nürnberg und Köln weiter unten.

Kommt vorbei Bernhard und ich freuen uns und wir sind euch sicher es lohnt sich auf jeden Fall.

Links zur Anmeldung:

• IT Camp Microsoft IT Camp Modernisierung des Rechenzentrums – Virtualisierung & Storage am 2. Juni in Nürnberg
• IT Camp Microsoft IT Camp Modernisierung des Rechenzentrums – Virtualisierung & Storage am 23. Juni in Köln

Es gibt mehrere Wege und Möglichkeiten, Hyper-V zu betreiben. Die einfachste Variante ist natürlich die Nutzung der Bordmittel, nämlich den Hyper-V Manager oder auch alternativ den Failover Cluster Manager, je nach dem ob ein Failover Cluster zum Einsatz kommt. Je nach Größe und Umgebung kommt teilweise auch der System Center Virtual Machine Manager zum Einsatz, ebenfalls ein Produkt aus dem Hause Microsoft. Mit diesem Artikel möchte ich eine weitere Möglichkeit der Administration vorstellen: Den 5nine Manager. Die Firma 5nine bietet neben den hauseigenen Microsoft-Tools noch eine weitere Möglichkeit, einen oder mehrere Hosts zu administrieren.

Die unterschiedlichen Editionen

Den 5nine Manager gibt es in drei unterschiedlichen Versionen: Einmal als freie Variante, dann “nur” den Manager und in der größten Variante den Manager zusammen in einem AntiVirus-Paket. Jede Version hat gewisse Merkmale und natürlich auch einen gewissen Preis. Eine sehr gute Übersicht über die unterschiedlichen Versionen bietet die folgende Gegenüberstellung, bei dem direkt die Funktionen des Hyper-V Manager verglichen werden:

Die Anwendungszwecke

Es gibt direkt mehrere Fälle, bei denen die Nutzung des 5nine Manager Sinn macht. Mir gefällt sehr gut, dass ich über eine Konsole direkt mehrere Versionen von Hyper-V administrieren kann. Somit ist das Management von Hosts mit Windows Server 2012 R2 und Windows Server 2012 direkt möglich, ohne das ich die Konsole oder das Programm wechseln muss. Bei dem Betrieb einer gemischten Umgebung ist dies ein großer Mehrwert, erst ab Windows Server 2016 wird Microsoft diese Änderung ebenfalls übernehmen und eine Multi-Version-Administration mit dem Hyper-V Manager ermöglichen.

Ein weiterer Vorteil ist die Möglichkeit, dass ich einen Standalone-Host genau so steuern und konfigurieren kann wie einen Failover Cluster. Der 5nine Manager kann beide Systeme bzw. Konfigurationen gleichzeitig in einer Konsole ansteuern, ich muss nicht zwischen zwei Konsolen wechseln. Dies ist bei vielen Kunden aktuell ein großer Kritikpunkt, viele wünschen sich hier eine zentrale Management-Konsole.

Der meiner Meinung nach größte Vorteil des 5nine Manager liegt darin, dass ich ihn auch auf einem Windows Server Core bzw. Hyper-V Server einsetzen kann. Natürlich kann ich auch ein Remote-Management machen, allerdings nicht immer. Bei der Nutzung von einem Root-Server in einem RZ habe ich evtl. nur genau diesen einen Server. Brauche ich durch die Virtualisierung von Linux-VMs keine Windows Server-Lizenz, reicht mir ein kostenloser Hyper-V Server. Diesen kann ich ohne eine grafische Oberfläche nur sehr eingeschränkt nutzen, allerdings kann ich hier den 5nine Manager nutzen, da sich dieser problemlos installieren lässt.

Vielleicht sehen Sie in diesem Artikel oder in der Liste weiter oben noch weitere Dinge, die Ihnen direkt positiv auffallen und die Ihnen einen Mehrwert bieten.

Die Installation

Die Installation des 5nine Manager gestaltet sich sehr einfach. Auf dem Test-System habe ich einen Windows Server 2012 R2 in der Core-Variante installiert, dies ist der Nutzung von einem Hyper-V Server sehr ähnlich. Nach dem Download der Setup-Datei starte ich die Installation per Eingabeaufforderung. Die Installation verläuft recht einfach, es wird letztendlich nur nach dem Ort der Installation, nach einer möglichen Lizenz und nach der Art der Datenbank gefragt. Als Datenbank nutze ich eine lokale Lite-Installation, in einer größeren Umgebung könnte hier ein voller SQL Server genutzt werden. Anbei die Installation in Screenshots:

Nach der Installation öffnet sich automatisch der Manager und zeigt die Standard-Seite an.

Der 5nine Manager im Überblick

Nach dem ersten Start verbindet sich der Manager direkt mit sich selbst, wenn er auf einem Hyper-V Host gestartet wurde. Ich habe die Installation auf einem unserer Schulungs-Rechner aus dem Hyper-V Powerkurs installiert. Ein Klick auf den Server selbst in der linken Seitenleiste öffnet eine generelle Übersicht auf das System.

Die einzelnen Reiter bieten eine sehr gute Übersicht über die unterschiedlichen Funktionen und Möglichkeiten. Unter Hyper-V Manager können die VMs administriert werden, dazu später mehr. Grundsätzliche Einstellungen, wie z.B. das Netzwerk, können hier ebenfalls direkt konfiguriert werden. Positiv fällt auf, das alle durchgeführten Optionen und deren Verlauf im unteren Bereich angezeigt werden. Dies ist ähnlich wie die Jobs in den System Center-Produkten.

Die 5nine Manager Einstellungen

In den Einstellungen des Programm selbst kann ich diverse Voreinstellungen vornehmen sowie eine Benachrichtigungsfunktion aktivieren.

Die Host-Einstellungen

In den Hyper-V Einstellungen von einem Host kann ich die gleichen Einstellungen wie im Hyper-V Manager vornehmen, allerdings ist das Menü ein bisschen anders aufgebaut.

Die Erstellung einer neuen VM

Die Erstellung einer neuen VM kann natürlich ebenfalls direkt aus dem Manager heraus durchgeführt werden, hierzu kann über das Kontextmenü auf dem Host selbst oder über das Menü Edit der entsprechende Menüpunkt ausgewählt werden.

Über den Punkt Create New VM… kann nicht nur eine neue VM aus einer ISO-Datei erstellt werden, sondern es können auch vorhandene VMs oder Templates genutzt werden.

Erstelle ich eine neue VM, muss ich natürlich den Namen und den Speicherort der VM auswählen. Wird die untere Option aktiviert, wird für diese VM ein eigener Ordner angelegt und sämtliche Dateien werden in diesem Ordner zusammengefasst. Da dies das von mir gewünschte Verhalten ist, wähle ich die untere Option an.

Nun kann ich die Edition der VM auswählen, dies ist im Vergleich zum Hyper-V Manager nicht anders.

Die Prozessor-Einstellungen sind nun die ersten Einstellungen, die sich gravierend unterscheiden, hier sind deutlich mehr Einstellungen und Konfigurationen möglich. Ich kann hier zum einen die Menge der virtuellen CPUs setzen, zum anderen können weitere sinnvolle Optionen wie z.B. die Kompatibilität gesetzt werden. Eine direkte Reservierung oder Beschränkung von Ressourcen kann hier ebenfalls gemacht werden.

Im nächsten Fenster kann die Einstellung des Arbeitsspeichers der VM gemacht werden. An dieser Stelle kann nicht nur der dynamische RAM aktiviert werden, zusätzlich können direkt die Minimal- und Maximal-Werte konfiguriert werden.

Nach einem Klick auf Weiter kann das Netzwerk der VM konfiguriert werden. Ich mag hier, dass z.B. direkt eine statische MAC-Adresse definiert werden kann und das direkt ein VLAN-Tag eingestellt werden kann.

Im Bereich Advanced können noch weitere Einstellungen vorgenommen werden:

Nach dem Netzwerk muss noch die Boot-Festplatte definiert werden. Hier habe ich im 5nine Manager den Vorteil, dass direkt aus dem Assistent heraus die Art der VHDX eingestellt werden kann. In den erweiterten Features kann zusätzlich ein QoS für die virtuelle Festplatte sowie ein Sharing konfiguriert werden.

Nun muss noch die Quelle für das Betriebssystem konfiguriert werden, dies kann eine ISO-Datei oder die Installation per Netzwerk sein.

Nun bekomme ich noch eine Übersicht über meine getätigten Einstellungen, bei Bedarf kann ich die VM direkt starten lassen.

Die Arbeit mit virtuellen Maschinen

Die Administration von virtuellen Systemen ist vermutlich deutlich häufiger der Fall als die Installation von einem oder mehreren neuen VMs. Der Klick auf eine VM direkt zeigt einige interessante Details über die VM sowie die Einstellungen innerhalb der VM. Ich kann z.B. direkt die ID der VM einsehen, ohne dies über Umwege heraus zu finden. Die Menge an Speicherplatz, die mein virtuellen System benötigt, wird ebenfalls direkt in der Übersicht angezeigt.

Wenn ich in der oberen Leiste auf den Reiter “Monitor” wechsel, bekomme ich eine Übersicht über den Ressourcen-Verbrauch der VM. Hier kann ich Fehler, Probleme oder Info-Meldungen einsehen, weiterhin wird mir ein Graph über die Nutzung von CPU, Speicher, Netzwerk und Festplatten-I/O angezeigt.

Clonen einer VM

Mit dieser Funktion kann ich eine bestehende VM duplizieren. Dies macht zum Beispiel dann Sinn, wenn ich an einem Offline-Clone etwas testen möchte, z.B. die Installation von Updates. Nachdem ich im Kontextmenü der VM die Option Clone ausgewählt habe, erscheint ein kleiner Assistent, der mich durch den Vorgang begleitet.

Ist der Clone-Vorgang gestartet (welcher übrigens unter Windows Server 2012 R2 online gemacht werden kann), sehe ich im unteren Bereich den Fortschritt der Aktion.

Wird der Vorgang erfolgreich abgeschlossen, erscheint die zweite VM in der VM-Übersicht.

Administration eines Hyper-V Failover Cluster

Neben der Administration von Single Hosts kann der 5nine Manager natürlich auch für ein Hyper-V Failover Cluster genutzt werden. Hierzu muss das Cluster über den Manager hinzugefügt werden.

Nach einer kurzen Überprüfung auf den Namen und die Verfügbarkeit wird das Failover Cluster angezeigt.

Importiere ich nun mehrere VMs in das Failover Cluster, meldet der Manager sofort diverse Warnungen und Fehler. In meinem Fall ist dies ein Problem mit der Heratbeat-Kommunikation (bedingt durch die Installation der VMs, der Dienst im Inneren der VM war noch nicht erreichbar) und veraltete Versionen der Integrationsdienste.

Ich kann nun hier ebenfalls ganze Hosts in den Wartungsmodus versetzen, die entsprechenden VMs werden dann automatisch auf einen anderen Host migriert.

Die Nutzung der Optimizer-Funktionalität

Bei der Nutzung von einem Failover Cluster möchte man vielleicht die Last auf die unterschiedlichen Hosts gleichmäßig ausbalancieren. Die Funktion ist auch unter dem Namen “Dynamic Optimization” im Virtual Machine Manager bekannt, hier ist sie ebenfalls enthalten. Nach der Grundinstallation gibt es erst einmal keine Regeln, die aktiv sind.

Anlegen kann man Regeln über Add, es öffnet sich ein kleiner Assistent, der durch den Vorgang begleitet. Wie man erkennen kann, ist diese Funktionalität nicht nur auf ein Failover Cluster beschränkt, sondern kann auch zwischen unterschiedlichen Hosts genutzt werden. In diesem Fall wird nicht nur die VM, sondern auch der Storage der VM umgelegt.

Nun kann ich für jeden Server in der gerade erstellten Gruppe die Grenzwerte konfigurieren.

Bei Bedarf könnten VMs aus dieser Dynamik ausgeschlossen werden.

Nach Erstellung der Regel ist diese im 5nine Manager sichtbar inkl. der aktuellen Belastung für CPU, RAM und Storage

Starte ich nun in einer VM ein Benchmark-Programm, ist dies sofort im Manager sichtbar.

Fazit

Der 5nine Manager gefällt mir sehr gut. Er vereint die Möglichkeiten des Hyper-V Manager sowie des Failover Cluster Manager in einer Konsole, zusätzlich kann ich noch einige Funktionen zusätzlich nutzen, die in den Bordmitteln nicht enthalten ist. Als einen sehr großen Vorteil sehe ich die Nutzung des Programms auf einem Hyper-V Server, der ohne eine volle Desktop-Umgebung daher kommt. Die Konsole lässt sich sowohl lokal als auch remote nutzen, daher kann ich das Programm auch auf meiner Workstation installieren und mich mit meiner Hypervisor-Landschaft verbinden.

Der Windows Server 2016 bringt eine Menge Neuerungen mit sich. Eine, die aktuell viel Beachtung findet und vielfältiges Interesse weckt ist der Nano Server. Bei dieser Art der Installation handelt es sich quasi um eine Weiterentwicklung der „Core Server“.

Vorteile: Durch eine Reduzierung des Betriebssystems um nicht benötigte Rollen, Funktionen, Programme, Treiber und weitere Dateien wird das System selbst sehr schlank, die Angriffsfläche sinkt, der benötigte Speicherplatz wird geringer, weiterhin sinkt der Bedarf von Windows Updates, was die Zahl der Reboots insgesamt verringert.

Man kann einen Nano Server allerdings nicht direkt bei der Installation auswählen, sondern muss ein eigenes Image kompilieren. Während dessen Erstellung müssen die Rollen, Funktionen und Treiber ausgewählt werden, die man im weiteren Verlauf benötigt. Werden keine Treiber ausgewählt, sind auch keine enthalten und das System lässt sich in Folge gar nicht erst starten.

Eine Nano Server Installation kann nicht nachträglich um Rollen, Funktionen oder Updates erweitert werden, all dies passiert ausschließlich bei der Erstellung. Dies bedeutet auch, dass bei einem Update keine einzelnen Windows-Pakete eingespielt werden, sondern dass das gesamte Betriebssystem im Hintergrund ausgetauscht wird. Dieser Artikel beschreibt, wie solch ein System erstellt wird, welche Anforderungen durch eine nicht vorhandene GUI entstehen und wie solch ein System administriert werden kann.

Die Erstellung

Grundsätzlich verwende ich als Vorlage für diese Beschreibung einen Blogpost aus dem TechNet: Step-By-Step: Deploying Nano Server Found in Windows Server 2016 TP5.

Wir beginnen mit dem Image des Windows Server 2016. Dieses Image wird auf dem Rechner, den wir zur Erstellung nutzen, gemountet. In dem Image befindet sich ein Ordner mit dem Namen NanoServer. Diesen kopieren wir auf unsere lokale Festplatte in einen Ordner, den wir zur Erstellung nutzen.

Nun müssen wir das PowerShell-Modul aktivieren, um die entsprechenden CmdLets nutzen zu können. Wie man in dem Screenshot erkennen kann, nutze ich das Verzeichnis F:\Tools, daher lautet der Befehl in meinem Fall

Import-Module .\NanoServer\NanoServerImageGenerator\NanoServerImageGenerator.psd1

Nun können wir eine neue VHD-Datei erstellen, die unsere gewünschten Einstellungen enthält. Hier gibt es einige Parameter und Einstellungen, die gesetzt werden können. Schauen wir uns den Befehl mal an, danach besprechen wir die einzelnen Einstellungen:

$Password=’MeinSicheresKennwort’
$SecurePassword=(ConvertTo-Securestring –asplaintext –force $Password)
New-NanoServerImage -AdministratorPassword $SecurePassword -DeploymentType Guest -Edition Standard -TargetPath F:\Tools\NanoServer13.vhdx -Clustering -Compute -ComputerName NanoServer13 -DomainName powerkurs.local -EnableRemoteManagementPort -InterfaceNameOrIndex Ethernet -Ipv4Address 192.168.208.213 -Ipv4Dns 192.168.209.2 -Ipv4SubnetMask 255.255.254.0 -MediaPath G:\

Als ersten müssen wir unser Kennwort umwandeln, damit es während der Erstellung genutzt werden kann. Danach können wir die Erstellung der VHDX-Datei starten.

Der grafische Editor

Es gibt auch eine Möglichkeit, die Erstellung und die einzelnen Parameter in einem kleinen GUI-Fenster zu machen. Das grafische Interface kann mit dem Befehl

Show-Command New-NanoServerImage

aufgerufen werden. Hier können alle benötigten Einstellungen vorgenommen werden, danach kann der Befehl entweder direkt ausgeführt oder kopiert werden. Wird direkt ein Kennwort vergeben, funktioniert dies nicht, da es im Plaintext vorliegt. Wird das Kennwort einfach weggelassen, wird bei der Erstellung nach einem Kennwort für das neue System gefragt.

Die einzelnen Optionen

Bei der Erstellung kann bzw. muss ausgewählt werden, wie das System betrieben wird.

DeploymentType

Grundsätzlich wird unterschieden zwischen dem Betrieb auf einer Hardware und dem Betrieb als VM. Es kann zwischen den beiden Optionen Guest oder Host gewählt werden.

Edition

Diese Option definiert, in welcher Edition das Windows Betriebssystem installiert wird. Zur Auswahl steht (wie in den grafischen Varianten auch) Standard oder Datacenter.

TargetPath

Hier muss die Zieldatei angegeben werden, die bei der Erstellung angelegt und mit Daten gefüllt wird. Definieren Sie hier einen aussagekräftigen Namen, um die Datei später identifizieren zu können.

ComputerName

Wie der Name vermuten lässt, wird hier der Name des Windows OS definiert.

DomainName

Der Name der Domain, in die der neue Server kommt. Wird die Erstellung auf einem System gemacht, das Mitglied der gleichen AD ist, wird automatisch ein neues Konto in der AD angelegt.

EnableRemoteManagementPort

Mit dieser Option wird ein Management per WinRM ermöglicht. So kann das System direkt „von außen“ gesteuert und kontrolliert werden.

InterfaceNameOrIndex

Diese Option kann die Netzwerkkarte(n) in der VM oder auf der Hardware steuern. Mit einem Adapter ist der Name meist „Ethernet“. Wird diese Option genutzt, müssen die folgenden Parameter auf definiert werden…

Ipv4Address

Die IPv4-Adresse, die das System bekommen soll. Bei Bedarf kann zusätzlich auch IPv6 definiert werden, falls im Einsatz.

Ipv4SubnetMask

Die Subnetzmaske. Nicht mehr, nicht weniger :)

Ipv4Dns

Der DNS-Server oder die Server, die genutzt werden sollen

MediaPath

Dies ist eine ziemlich wichtige Option, hier wird auf den Windows Server 2016 Datenträger verwiesen (Nicht das Nano-Verzeichnis und auch nicht die ISO, sondern auf den Inhalt der DVD/der ISO-Datei).

Weitere Parameter

Neben den oben bereits beschriebenen Optionen muss während der Image-Erstellung auch definiert werden, wozu das System genutzt werden soll. Dies wird über Parameter wie z.B. -Compute gemacht. -Compute wird benötigt, wenn der Nano Server virtuelle Maschinen hosten soll, sprich das System wird als Hyper-V Host genutzt. Häufig zum Einsatz kommen wird wahrscheinlich auch -Clustering, dies ermöglicht eine Nutzung des Nano Server als Failover Cluster Node. Wird ein Scale-Out File Server benötigt, muss z.B. -Storage angegeben werden. Dies ist natürlich noch nicht alles, es gibt noch ein paar mehr Möglichkeiten und Optionen, schauen Sie einfach mal nach.

Die erste Anmeldung

Nach der Erstellung einer neuen VM (Generation 2, Netzwerk-Anbindung, 1024 MB RAM) und der Anbindung meiner gerade erstellten VHDX-Datei startet das System relativ schnell und zeigt mir einen simplen Logon-Screen.

Ich kann mich nun direkt mit meinem Domain-Anmeldedaten einloggen (Achtung, ggf. englisches Tastatur-Layout).

Die Konfiguration als Failover Cluster

Nachdem ich beide NanoServer-VMs erfolgreich gestartet habe, können wir z.B. mit der Einrichtung als Failover Cluster beginnen.

Der Test meldet in meiner Konfiguration natürlich, dass nur ein Adapter verfügbar ist…

Nun kann das Failover Cluster erstellt werden.

Nun würde eine weitere Einrichtung erfolgen: Storage-Anbindung, korrekte Benennung der einzelnen Ressourcen, Netzwerke usw…

Nachdem auch ich immer wieder vor der Frage stehe, welche Patche sind denn bei welchem Betriebssystem für die Hyper-V und Failover Cluster Umgebungen notwendig, habe ich mir heute mal die Arbeit gemacht und die verschiedenen Links zusammen gesucht, so dass auch Ihr in Zukunft alles auf einer Seite finden könnt.

Windows Server 2012 R2

• Failover-Cluster und Hyper-V Failover Cluster: – “Recommanded hotfixes and updates for Windows Server 2012 R2 based failover clusters”
• Hyper-V:  – “Recommended hotfixes, updates, and known solutions for Windows Server 2012 R2 Hyper-V environments”
• Files Services:  – “List of currently available hotfixes for the File Services technologies in Windows Server 2012 and in Windows Server 2012 R2”
• Hyper-V Netzwerk Virtualisierung:  – “Recommended hotfixes, updates, and known solutions for Windows Server 2012 R2 Hyper-V Network Virtualization (HNV) environments” unter diesem Link finden sich auch Patchlisten für den VMM 2012 R2 und dem VMM 2012

Windows Server 2012

• Failover-Cluster:   – “Recommended hotfixes and updates for Windows Server 2012-based failover clusters“
• Hyper-V:  – “Hyper-V: Update List for Windows Server 2012”
• System Center Virtual Machine Manager: – “Recommended hotfixes for Microsoft System Center 2012 Virtual Machine Manager”

Windows Server 2008 R2 SP1

• Failover-Cluster:   – “Recommended hotfixes and updates for Windows Server 2008 R2 SP1 Failover Clusters”
• Failover-Cluster: – “Windows Server 2008 R2 SP1: List of Failover Cluster Packages Updates (after SP1)”
• Hyper-V: – “List of Hyper-V Packages Updated After the Release of Windows Server 2008 R2 Service Pack 1 (SP1)”

Windows Server 2008 R2

• Failover-Cluster: – “Windows Server 2008 R2 Cluster: List of Hotfixes”
• Hyper-V:  – “Hyper-V 2008 R2: Update List”

Windows Server 2008

• Failover-Cluster: – “Windows Server 2008 R2 Cluster: List of Hotfixes”
• Hyper-V:  – “Hyper-V: Update List for Windows Server 2008”

Diesmal habe ich wieder zwei Schwerpunkt Themen für euch. Einerseits hört Ihr wie ich “fast” nach Las Vegas zur MMS 2012 gereist währe. Und im Anderen stelle ich euch wieder einige neue coole Features von Hyper- V in Windows Server 2012 vor. Zusätzlich habe ich wie immer viele Links auf Posts und Videos und Veranstaltungstipps für euch gesammelt.

Ich wünsche euch beim Zuhören viele Erkenntnisse und soviel Spaß, wie ich beim Zusammentragen der Infos hatte.

Shownotes:

Links und News (ab 1:14)

Updated Links on Windows Server 2012 File Server and SMB 3.0 von Jose Barreto auf seinem Blog Jose’s Briefings, Diagrams and Annotations

Let’s Build a Cloud… With PowerShell! – Part 1: Deployment and Configuration von Yigal Edery auf Private Cloud Architecture Blog

Understanding Microsoft Private Cloud – White paper von Kristian Nese auf Virtualization and some coffee

New Knowledge Base articles for System Center 2012 Virtual Machine Manager auf System Center Virtual Machine Manager Blog

System Center Virtual Machine Manager 2012 Configuration Analyzer von Michel Lüscher auf Server-Talk.eu

Upgrading Hyper-V Cluster Nodes to Windows Server 2012 (Beta) – Part 1, Part 2 and Part 3 von Didier Van Hoye auf Working Hard In IT Blog

Windows Server 8: CSV Cache Benchmark von Thomas Maurer auf seinem Blog

System Center 2012 Unified Installer, 1-2-3 und alles ist installiert! von Michel Lüscher auf Server-Talk.eu

Windows Server 2012 Beta Scale-Out File Server for SQL Server 2012 – Step-by-step Installation von von Jose Barreto auf seinem Blog Jose’s Briefings, Diagrams and Annotations

Prometics 2 for 1 Exam Vouchers Aktion bis 30. Juni. 2012

System Center 2012 – Virtual Machine Manager – Evaluation (VHD)

Video and Audio (ab 12:51)

Edge Show 23 – Monitoring Service Delivery and Automation for the Private Cloud with System Center 2012 mit Symon Periman and Sean Christensen auf Technet Edge

System Center Universe Recordings Now Live On Demand von Travis Wright auf System Center Data Protection Manager Blog

Robert Hedblom: System Center 2012 Data Protection Manager Vortrag von der Nordic Infrastructure Conference

DPM How to Videos von Steven Buchanan auf Buchatech.com

Inside Central 21 – DPM 2012 and MMS warm-up with DPM MVP Mike Resseler

Edge Byte – Windows Server 8 – Hyper-V and Beyond Virtualization – Interview with Jeff Woolsey

Videocast: Hyper-V Replica in Windows Server 2012 Beta auf Hyper-V-Server.de

Schwerpunktpunktthema MMS2012 (ab 18:30)

Hier findet Ihr die Artikel die in diesem Bereich des Podcasts erwähnt worden sind:

MMS 2012 – Day One Keynote wrapup

MMS 2012 – Day 2 Keynote Wrap-up

Download MMS Sessions von Marcel Zehner auf SCSMfaq.ch

Technet Edge Show von MMS

14 new Private Cloud guided labs are available for testing

MMS2012 Virtualization Sessions auf Hyper-V-Server.de

Schwerpunktpunktthema Windows Server 2012 Beta (ab 29:40)

Diesmal erzähle ich einiges über die Neuerungen die sich auf den Failover-Cluster in Windows Server 2012 beziehen. Ich spreche über dinge wie “CSV Caching”, “Cluster Aware Updating”, “VM Priority” und vieles mehr.

Übrigens, es gibt wieder ein Poster zu Hyper-V: Windows Server “8” Beta Hyper-V Component Architecture Poster

Termine (ab 43:52)

Microsoft System Management Summit am 9. Mai in Hanau

Microsoft IT Camp Private Cloud am 10. Mai in Frankfurt

Online Event 24 Hours in a Private Cloud vom 10. bis 11. Mai

Consumerization of IT Jump Start am 15. und 16. Mai

IT-Administrator Training »Windows Server Best Practice am 15. Mai in Hamburg und am 19. Juni in Frankfurt

Hyper-V PowerKurs vom 21. bis 25. Mai in Hallenberg

base-it technews System Center 2012 – the entire suite am 22. Mai in Linz /Österreich

E2E Virtualisation Conference vom 25. bis 27. Mai in Wien / Österreich

Windows Server 2012 Community Roadshow am 29. Mai in Köln, am 19. Juni in Bad Homburg und am 22. Juni in Unterschleißheim

Veranstaltungsreihe Best of Microsoft 2012 am 4. Juni in Köln, am 6. Juni in Hamburg, am 11. Juni in Stuttgart und am 13. Juni in München

TechEd 2012 Northamerica vom 11. bis 14. Juni in Orlando / USA

TechED 2012 Europe vom 25. bis 29. Juni in Amsterdam / Niederlande

Hyper-V Community Treffen am 10. Juli in Düsseldorf

Hyper-V PowerKurs vom 2. bis 6. Juli in Hallenberg

Hyper-V PowerKurs vom 6. bis 10. August in Hallenberg

Ich komme gerade von einer Woche Powerkurs aus dem Süden Deutschlands wieder. Während des Kurses haben wir verschiedene Möglichkeiten und Optionen angesprochen, wie die Aufteilung des Netzwerks am sinnvollsten und am einfachsten gemacht werden kann. Auf zwei der Teilnehmer-Systeme konnte der jeweilige Teilnehmer nur auf eine physische Netzwerkkarte zurückgreifen, und zwar die auf dem Mainboard. Dies hat uns allerdings nicht davon abhalten können, die Systeme mit insgesamt sechs Karten installieren und einrichten zu können. Wie wir das gemacht haben? Mit einer ziemlich coolen Funktion im Windows Server 2012, der Netzwerkvirtualisierung.

Der Aufbau der während des Kurses erstellten Failovercluster wurde nach unseren Best Practises vorgenommen, d.h. es wurden insgesamt sechs Netzwerkkarten benötigt. Der gewünschte Aufbau des Netzwerks sollte wie folgt aussehen:

Da wir nur eine Karte zur Verfügung hatten, haben wir mit Hilfe der Netzwerkvirtualisierung weitere Karten erstellt. Im ersten Schritt wurde per PowerShell-Befehl ein Team erstellt, einziges Mitglied in diesem Team war der eine physisch vorhandene Adapter mit dem Namen “LAN-Adapter”.

Edit: Wie Hannes mit seinem Kommentar korrekt angemerkt hat, ist die Erstellung des Teams an dieser Stelle nicht unbedingt notwendig, die vNICs können auch direkt auf die nicht-geteamte Karte gesetzt werden. Die Erstellung eines Teams hat keine Vor- oder Nachteile, lediglich das man lernt wie die Erstellung per PowerShell funktioniert :)

New-NetLbfoTeam -Name „Team1“ -TeamNicName „Team1“ -TeamMembers LAN-Adapter -TeamingMode SwitchIndependent -LoadBalancingAlgorithm HyperVPort -Confirm:$false

Eine Beschreibung des Befehls mit allen Parametern und einer sehr guten Beschreibung findet ihr im TechNet: Microsoft TechNet: New-NetLbfoTeam

Nachdem wir das Team (mit nur einem Adapter, aber trotzdem nutzbar) erstellt haben, können wir eine Hyper-V Switch erstellen. Diese ist Grundlage für unsere Verbindung der VMs zur Außenwelt, zur Kommunikation des Hosts mit der Außenwelt sowie technische Grundlage für die Erstellung von virtuellen Netzwerkkarten, vNics genannt. Der Befehl lautet

New-VMSwitch „LAN“ -MinimumBandwidthMode None -NetAdapterName „Team1“ -AllowManagementOS 1 -Confirm:$false

Hiermit erstellen wir eine neue Switch mit dem Namen “LAN”. Eine mögliche Bandbreitenreservierung aktivieren wir nicht, als Grundlage für diese virtuelle Switch wird “Team“1” genutzt. Hierbei ist es egal, ob es sich um eine physische Karte oder ein Team handelt. Wichtig ist in diesem Fall der Parameter “AllowManagementOS” mit dem Wert 1, dieser macht nichts anderes als wenn ihr im Hyper-V-Manager bei der Erstellung einer virtuellen Switch den Haken bei “Gemeinsames Verwenden dieses Netzwerkadapters für das Verwaltungsbetriebssystem zulassen” setzt.

Nachdem die virtuelle Switch vorhanden ist, könnten wir nun sowohl mit unseren VMs und dem dem Host-Betriebssystem eine Kommunikation per Netzwerk aufbauen. Da wir im Host allerdings nur eine einzige Karte haben, müsste entweder die gesamte Kommunikation über diese eine Karte laufen, oder wir erstellen alternativ noch weitere Karten. Dies geschieht mit den folgenden Befehlen:

Add-VMNetworkAdapter -ManagementOS -Name „CSV“ -SwitchName „LAN“
Add-VMNetworkAdapter -ManagementOS -Name „Livemigration“ -SwitchName „LAN“
Add-VMNetworkAdapter -ManagementOS -Name „iSCSI“ -SwitchName „LAN“
Add-VMNetworkAdapter -ManagementOS -Name „iSCSI2“ -SwitchName „LAN“

Nach dem Absetzen dieser Befehle haben wir uns vier weiteren Karten erstellt, die nun auch in der Systemsteuerung auftauchen und wie gewohnt administriert werden können. Die virtuelle Switch (in diesem Beispiel mit dem Namen “LAN”) könnt ihr im Hyper-V-Manager nun sehen, allerdings nicht bearbeiten. Löschen wäre übrigens möglich, falls ihr dies machen möchtest oder müsst.

Fazit: Diese wenigen Befehle reichen aus, um auf einem Host virtuelle Netzwerkkarten anlegen zu können. Die Aussage “Betrieb eines Clusters mit nur einer Netzwerkkarte” ist somit richtig, allerdings nur für Demo- oder Testumgebungen anwendbar. Die Nutzung von einem Team aus mehreren Karten (z.B. zwei oder vier 10GBit/s-Adapter) wäre denkbar, allerdings sollte hier unter anderem die Bandbreitenbeschränkung aufgenommen werden, damit die Versorgung aller vNics mit der benötigten Bandbreite garantiert werden kann.

Wenn alle hier aufgeführten PowerShell-Befehle untereinander in eine .ps1-Datei geschrieben werden, die Ausführung dieses Scripts auf dem PC/Server erlaubt ist und die Hardware-Karte “LAN-Adapter” heißt, könnten sogar mehrere Systeme mit nur einem Klick netzwerktechnisch eingerichtet werden. Coole Sache! :)

Der ein oder andere von Ihnen wird es über Facebook schon mitbekommen haben: Wir stellen aktuell unser Failover Cluster unter Windows Server 2012 von 1 GBit/s auf 10 GBit/s um. Durch diese Umstellung haben wir die Möglichkeit, die vorhandenen Karten als Team einzusetzen und so zum einen eine Erhöhung der Bandbreite bekommen, zum anderen eine Ausfallsicherheit. Die Erhöhung der Bandbreite wird sich positiv auf die Zeiten während einer oder mehreren Livemigrationen bemerkbar machen, da dies deutlich schneller ablaufen wird wie bisher.

Um Ihnen ebenfalls einen Mehrwert bei dieser Umstellung zu geben, werde ich den Vorgang mit diesem Artikel dokumentieren und erklären.

Aktuell sieht unsere Netzwerk-Konfiguration wie folgt aus:

Die Definition der Netzwerke ändert sich nicht, alle Netzwerke bleiben wie bisher auch bestehen. Was sich allerdings ändert ist die Aufteilung der Netzwerk-Adapter in den einzelnen Servern. Aktuell sieht dies in der Systemsteuerung so aus (Zur Info: Der eine Knoten hat 2x 10GBit und 2x 1GBit, der andere hat 2x 10GBit und 4x 1 GBit):

Nach der Umstellung soll das Netzwerk pro Cluster-Knoten die folgende Struktur haben:

Die Adapter “Intel(R) Gigabit 4P X540/I350 rNDC” und “Intel(R) Gigabit 4P X540/I350 rNDC #2” werden zu einem eigenen Team zusammengefasst und stehen mit insgesamt 2 GBit/s für die Kommunikation mit der Domäne, zum Management und für unser Veeam-Backup zur Verfügung. Die Adapter “Intel(R) Ethernet 10G 4P X540/I350 rNDC” und “Intel(R) Ethernet 10G 4P X540/I350 rNDC #2” werden zu einem eigenen Team zusammengefasst, basierend auf diesem Team wird eine Hyper-V Switch erstellt. Diese Switch steht zum einen für die VMs bereit, weiterhin werden basierend auf dieser Switch im Management-OS (das Host-Betriebssystem) virtuelle Netzwerkkarten (vNICs) erstellt. Diese stellen das Netzwerk für iSCSI, iSCSI2, CSV und Livemigration. Die Erstellung und Konfiguration von vNICs ist nur mit dem SCVMM oder per PowerShell möglich. In unserem Fall arbeiten wir mit der PowerShell.

Damit die einzelnen Netzwerke sich nicht gegenseitig behindern oder eine Karte den gesamten möglichen Traffic nutzen, wird mit Quality of Service (QoS) gearbeitet. Somit garantieren wir jedem einzelnen Netzwerk eine gewisse Bandbreite.

Nachdem nun der eine Knoten im Failovercluster-Manager mittels Livemigration leer geschoben wurde, wird das System mit Hilfe eines Skripts konfiguriert. Dieses Skript sieht wie folgt aus:

#Abfrage der End-IP-Adresse des Systems
$IP = Read-Host "Bitte geben Sie den vierten und letzten Bereich der IP-Adresse an (z.B. 101 fuer 192.168.210.101)"

#ConvergedSwitch-Team erstellen
New-NetLbfoTeam -Name Team01 -TeamMembers "10GbE #1","10GbE #2" -LoadBalancingAlgorithm HyperVPort -TeamingMode Lacp -Confirm:$false
#Management-Team erstellen
New-NetLbfoTeam -Name Team02 -TeamMembers "1GbE #1","1GbE #2" -LoadBalancingAlgorithm TransportPorts -TeamingMode SwitchIndependent -Confirm:$false

# Die virtuelle Switch erstellen, keine gemeinsame Verwendung
New-VMSwitch "VM" -MinimumBandwidthMode weight -NetAdapterName "Team01" -AllowManagementOS 0 -Confirm:$false

# Standard-Bandbreitenreservierung setzen
Set-VMSwitch "VM" -DefaultFlowMinimumBandwidthWeight 1

# Erstellen der virtuellen Netzwerkkarten
Add-VMNetworkAdapter -ManagementOS -Name "Livemigration" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "CSV" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "iSCSI" -SwitchName "VM"
Add-VMNetworkAdapter -ManagementOS -Name "iSCSI2" -SwitchName "VM"

# Assign static IP addresses to the virtual network adapters
Set-NetIPInterface -InterfaceAlias "vEthernet (Livemigration)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (Livemigration)" -IPAddress 192.168.214.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (Livemigration)" -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias "vEthernet (CSV)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (CSV)" -IPAddress 192.168.215.$IP –verbose
Set-NetAdapterBinding -Name "vEthernet (CSV)" -ComponentID ms_tcpip6 -Enabled $False

Set-NetIPInterface -InterfaceAlias "vEthernet (iSCSI)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (iSCSI)" -IPAddress 192.168.212.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_tcpip6 -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_msclient -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI)" -ComponentID ms_server -Enabled $False

Set-NetIPInterface -InterfaceAlias "vEthernet (iSCSI2)" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 24 -InterfaceAlias "vEthernet (iSCSI2)" -IPAddress 192.168.213.$IP -verbose
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_tcpip6 -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_msclient -Enabled $False
Set-NetAdapterBinding -Name "vEthernet (iSCSI2)" -ComponentID ms_server -Enabled $False

# QoS-Konfiguration der vNICs
Set-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -MinimumBandwidthWeight 20 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "CSV" -MinimumBandwidthWeight 25 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "iSCSI" -MinimumBandwidthWeight 10 -verbose
Set-VMNetworkAdapter -ManagementOS -Name "iSCSI2" -MinimumBandwidthWeight 10 -verbose

# Konfiguration des Management-Teams
Set-NetIPInterface -InterfaceAlias "Team02" -dhcp Disabled -verbose
New-NetIPAddress -AddressFamily IPv4 -PrefixLength 23 -InterfaceAlias "Team02" -IPAddress 192.168.210.$IP -verbose
Set-DnsClientServerAddress -InterfaceAlias "Team02" -ServerAddresses ("192.168.210.2","192.168.210.4")

# Show VLanIDs on VMNetWorkAdapters
Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName *

Eine Kopie des Skripts als .txt-Datei finden Sie hier: ConvergedNetwork.txt

Nach der Ausführung des Skripts sieht die Netzwerk-Konfiguration des Hosts ein wenig anders aus:

Sie sehen die beiden Teams. Team01 steht mit insgesamt 20 GBit/s zur Verfügung, Team02 ist das Management-Team mit 2 GBit/s.

Wir haben aktuell zwei Failover Cluster laufen – einen für den Betrieb der virtuellen Server, den anderen zur Bereitstellung der Scale-Out Fileserver-Rolle. Im zweiten Cluster gibt es seit kurzem ein Problem mit dem folgenden Text

Protokoll-Name: System / Ereignis-ID: 1196 / Quelle: Microsoft-Windows-FailoverClustering / Benutzer: System

Ereignisdetails:

Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.
.

Stellen Sie sicher, dass die Netzwerkadapter, die mit den abhängigen IP-Adressressourcen verknüpft sind, für den Zugriff auf mindestens einen verfügbaren DNS-Server konfiguriert wurden.

Im DNS sieht der Eintrag für den Cluster-Namen in Bezug auf den Zeitstempel etwas veraltet aus

Die Lösung habe ich durch folgenden Beitrag bekommen: Microsoft TechNet Forum: Windows Server 2012 Failover Cluster (Hyper-V) Event Id 1196

Oguzhan İlkan BORAN schreibt, dass das Problem durch die Berechtigungen im DNS-Eintrag gelöst werden kann. Dieser sieht in meinem Fall wie folgt aus

Das unbekannte Konto sieht hier direkt auffällig aus, weiterhin fällt auf dass das Cluster-Computer-Objekt keine eigene Berechtigung hält. Dieses habe ich hinzugefügt und mit Vollzugriff ausgestattet

Nach kurzer Zeit hat sich der DNS-Eintrag in meinem Fall wieder aktualisiert und das Failover Cluster erzeugt keine weiteren Fehler mehr