Enterprise Mobility

von Peter Vogl, DrVis Software GmbH, verfasst im Mai 2015

Throwback Thursday: Zu Anfang des neuen Jahres 2017 werfen wir einen Blick zurück auf den Windows Server 2016. Der Artikel wurde ursprünglich auf Sway veröffentlicht.

Windows Server 2016 ist derzeit noch in einem frühen Vorschau-Stadium, aber Microsoft hat auf der letzten Ignite Tagung in Chicago Anfang Mai 2015 und in Blogs schon sehr detaillierte Einblicke in die Entwicklung gegeben. Die Entwicklung von Windows Server 2016 – allgemeine Verfügbarkeit ist erst für 2016 geplant – ist stark geprägt von den Erfahrungen, die Microsoft mit dem Betrieb von Microsoft Azure gewonnen hat. Beim Betrieb von Millionen von virtuellen Maschinen fallen auch kleinste Schwächen und Mängel auf. Diese wertvollen Erfahrungen machen die neue Version besonders interessant.

Ein sich durch alle Neuerungen in Windows Server 2016 ziehender roter Faden sind 2 Aspekte: einmal die Stärkung der Sicherheit auf allen Ebenen und zum zweiten eine drastische Reduktion der durch Konfigurationsänderungen und Aktualisierungen erzwungenen Neustarts.

Natürlich bietet jede Aktualisierung auch eine Vielzahl kleinerer Verbesserungen, die das Leben eines Administrators leichter machen. Was sind aber die herausragenden Neuerungen?

Es sind meiner Meinung nach 4 Punkte:

  • Sicherheit
  • Nanoserver
  • Docker Behälter
  • Speicher-Replika

Jeder dieser Punkte hat auch mit Virtualisierungstechnologien zu tun, ohne die ein heutiger Serverbetrieb nicht mehr vorstellbar ist. Die Hyper-V Technologie von Microsoft ist eine Basis für alle diese Punkte und die Weiterentwicklungen dieser Technologie werden daher im Anschluss an die 4 Punkte besprochen.

Sicherheit

Die Bedrohungen durch Cyber-Angriffe nehmen weltweit in einem beängstigenden Ausmaß zu. Es geht um Geld, es geht um Spionage im großen Stil, es geht auch um Terror. Laut dem bayerischen Landesnachrichtendienst arbeiten alleine in China 900,000 Mitarbeiter in der Auslandsspionage. Die weltweiten Umsätze durch Cyber-Kriminalität übertreffen bereits die mit Rauschgift und Schmuggel erzielten. Die Angriffe werden immer professioneller und ohne Rücksicht auf Kosten und Aufwand nicht selten von regierungsnahen Organisationen vorangetrieben.

Microsoft kann man von allen großen IT Unternehmen am wenigsten vorwerfen, Sicherheit vernachlässigt zu haben. Allerdings sind die heute in Windows Server und Client installierten Sicherheitssysteme immer noch geprägt vom Paradigma der Hardware im eigenen Haus oder am eigenen Schreibtisch, vom Rechenzentrum, das – bildlich und vereinfacht gesprochen – mit Schloss und Riegel gesichert werden kann. Die Herausforderungen, die Sicherheit sowohl im Haus, als auch auf dem Weg in die Cloud und vor allem innerhalb der Cloud zu gewährleisten, sind aber viel größer.

Microsoft hat daher Sicherheit zu einem Schwerpunkt, vielleicht zum wichtigsten Schwerpunkt, in Windows Server 2016 gemacht, und zwar im Zusammenspiel mit der Azure Cloud.

Das Cloud-Computing bringt neue Vertrauens- und Sicherheitsgrenzen mit sich, besonders wenn es um riesige Farmen geht wie in Azure. Der Kunde will nicht dem Dienst-Anbieter vertrauen müssen, der Dienst-Anbieter kann aber auch umgekehrt dem Kunden nicht vertrauen.

Ein großes Problem bzgl. Sicherheit ist die verbreitete Gewohnheit, uneingeschränkte und zeitlich unbegrenzte Administrator-Rechte zu vergeben. Vor einigen Jahren war das nicht oder zumindest nur schwerlich anders möglich, heute führt es dazu, dass ein erfolgreicher Angriff auf ein einzelnes System ausreichen kann, um ein ganzes Rechenzentrum zu kapern. Es ist daher wichtig, stets davon auszugehen, dass Einbrüche passieren, weil Passwörter gestohlen werden oder ein Mitarbeiter absichtlich Schaden anrichten möchte. Das gilt für den Endkunden genauso wie für den Cloud-Anbieter.

  1. Wie schützt man sich vor serverseitigen Angriffen auf Prozesse (das können virtuelle Maschinen oder Applikationen sein), die auf dem Server laufen?
  2. Wie schützt man diese Prozesse, wenn Sie vom Internet aus erreichbar sind, vor direktem Angriff?
  3. Wie entdeckt man Angriffe und Angriffsversuche in einer großen und komplexen IT-Landschaft?

Microsoft hat Strategien entwickelt, diese Probleme proaktiv zu adressieren und Lösungen anzubieten. Lösungen, die selbstverständlich nicht nur auf Windows Server 2016 beschränkt ist (was nicht hilfreich wäre) und vor allem von Microsoft selbst bereits in Azure angewendet werden.

Für das erste Problem hat Microsoft eine Art von separaten Mini-Betriebssystem entwickelt, das zusammen mit der Hyper-V Rolle am Server-Host installiert wird und einen separaten Address-Raum einnimmt. Microsoft spricht von einer Vertrauens-Ebene, die zwischen Hardware und den Prozessen eingezogen wird und die von außen nicht zugänglich ist. In dieser Ebene läuft ein Schlüssel-Verwaltungsdienst, der virtueller Sicherheitsmodus genannt wird (VSM) und jede Aktivität und jede virtuelle Maschine, die auf dem Server läuft, mit seinem Zertifikat validiert. Zusätzlich erlaubt dieser Dienst die Verschlüsselung der Daten innerhalb jeder virtuellen Maschine, weil er sich wie ein virtueller TPM-Chip verhält. Wird das Server-Betriebssystem kompromittiert, passt der Schlüssel im VSM nicht mehr, wird die virtuelle Maschine auf einen anderen Wirts-Server verschoben, gilt das gleiche.

Obwohl nicht zwingend erforderlich, empfiehlt Microsoft daher, in Zukunft nur mehr Server mit einem TPM-Chip zu kaufen, die in Notebooks heute schon zum Standard geworden sind.

Man kann nun sagen, das ist ja alles schön und gut, aber wie kann ich mich als Kunde von Microsoft Azure darauf verlassen, dass Microsoft diese Sicherheitsmaßnahmen auch genauso implementiert hat? Dazu führt Microsoft die vielen strengen Zertifizierungen an, die in der nebenstehenden Abbildung gezeigt sind.

Aktuelle Zertifizierungen der Microsoft Rechenzentren

Aktuelle Zertifizierungen der Microsoft Rechenzentren

Für den zweiten Problemkreis ist die Verschlüsselung wirkungslos. Wenn jemand gültige Administrator-Rechte erlangt hat, werden die Daten für ihn entschlüsselt. Dafür hat Microsoft eine sehr interessante neue Applikation entwickelt, nämlich die Möglichkeit, über ein Selbst-Service-Portal zeitlich befristete und umfänglich beschränkte Administrator-Rechte zu erlangen (just in time, just enough admin). Dies erfordert nicht notwendigerweise ein aufwändiges Genehmigungsverfahren, sondern kann z. B. über eine weitere Authentifizierung per Smartcard oder Telefon oder Handy erfolgen. Schütze Dich vor Dir selbst (bzw. vor dem, der Dein Passwort geklaut hat), könnte man das nennen. Microsoft nennt diese Technologie Privileged Access Management, die auch in Azure zur Verfügung stehen wird.

Für den dritten Problemkreis hat Microsoft eine Reihe von Werkzeugen entwickelt, um Bedrohungen in großen Netzwerken erkennen und klassifizieren zu können. Mittels maschinellen Lernens und den gigantischen Datenmengen in Azure hat Microsoft Verfahren wie das Operational Insights Security Pack entwickelt, das ungewöhnliche Aktivitäten in einem Netzwerk sehr rasch erkennen kann, auch wenn die Details unbekannt sind. Allerdings – die Qualität dieser Werkzeuge hängt letztlich an den Menschen, die die Analyse-Daten vorgesetzt bekommen und entscheiden, was zu tun ist.

Nanoserver

Schon in Windows Server 2008 hat Microsoft mit Server Core eine Servervariante ohne den riesigen Überbau einer graphischen Bedienoberfläche angeboten. Idee war: weniger Angriffsfläche durch Begrenzung auf die benötigen Dienste, weniger Platzbedarf, weniger Neustarts, weil weniger Aktualisierungen erforderlich sind. Diese Variante war kein großer Erfolg. Es war schwer, Gerätetreiber zu installieren, die Aktualisierungen waren mühsam, der Platzbedarf war kaum geringer als in der normalen Variante. In Windows Server 2012 hat daher Microsoft die Möglichkeit geschaffen, dynamisch zwischen Server Core und der vollen Benutzeroberfläche hin- und herwechseln zu können; d. h. z. B. Installation mit Oberfläche, dann Wechsel in den Server Core Modus. Das war definitiv eine Verbesserung, aber gleichzeitig hatte Microsoft mit dem Servermanager die Möglichkeit geschaffen, nicht benötigte Komponenten loszuwerden oder gar nicht erst zu installieren, sodass der Vorteil wieder begrenzt war.

Vorläufiger Vergleich der Windows Server Varianten (Ignite 2015)

Vorläufiger Vergleich der Windows Server Varianten (Ignite 2015)

Mit Nanoserver hat Microsoft den ursprünglichen Gedanken entschlossen und innovativ umgesetzt: mit dem Nanoserver schrumpft das Betriebssystem auf unter 1 GB (Microsoft spricht von 1/20 der Größe von Server Core), trotzdem ist die Installation und Konfiguration sehr bequem: die Bedienoberfläche liegt nämlich nicht im System, sondern außerhalb vor dem System. De facto kann man sich am Nanoserver selbst gar nicht lokal anmelden. Nanoserver erlaubt die Installation der wichtigsten Rollen wie Hyper-V, Failover-Clustering, Netzwerk, Fileserver. Der Nanoserver kann natürlich auch skriptbasiert installiert und konfiguriert werden.

Docker Behälter

Docker ist ein erfolgreiches Open-Source Projekt, das ursprünglich für Linux entwickelt wurde. Microsoft hat dieses Projekt zusammen und in Kooperation mit der Docker-Entwickler-Gemeinde auf Windows portiert und ins neue Windows Server 2016 integriert.

Worum geht es? Es geht um eine neue Virtualisierungsebene, die zwischen Applikationsvirtualisierung (App-V in Windows genannt) und Betriebssystem-Virtualisierung (Hyper-V) liegt. Klingt kompliziert? Ein Beispiel: Sie wollen eine kleine Applikation auf Windows Server installieren, die nach außen einen Dienst zur Verfügung stellt. Leider ist die Applikation so geschrieben, dass man Sie im Betriebssystem nur einmal starten kann und Sie haben keine Möglichkeit, dies zu ändern. Sie wollen diese Applikation mit unterschiedlichen Parametern tausendmal verfügbar machen. Wie machen Sie das? Sie wollen sicher keine tausend virtuelle Server installieren. Diese Problemstellung ist wie geschaffen für Docker. Sie stecken die Applikation in einen sog. Behälter und die jeweils unterschiedlichen Daten in einen anderen Behälter (der vielleicht nur einige Bytes groß ist). Diesen winzigen zweiten Behälter kopieren Sie tausendmal. Schon laufen auf einem Server 1000 Varianten der Applikation und jede verhält sich so, wie wenn sie in einem eigenen Server laufen würde.

Das Konzept von Docker Behältern lässt sich auch am einfachsten an einem kleinen Beispiel zeigen. Sie wollen 20 Windows Server installieren. Sie sollen sich nur durch den Servernamen, ein Administrator-Konto und eine primäre IP-Adresse unterscheiden. In der Welt der Docker-Behälter geht das so: Sie erzeugen 21 Behälter: der erste Behälter ist eine schreibgeschützte Kopie des Betriebssystems (bzw. ein Link dazu, er benötigt also keinen Platz). In den zweiten Behälter legen Sie die Änderung für den ersten Server, in den dritten die Änderungen des zweiten Servers usw. Dann schließen Sie jeweils den ersten Behälter (der das Betriebssystem enthält) mit je einem der anderen Behälter zu einem neuen schreibgeschützten Behälter zusammen. Damit haben Sie 20 Über-Behälter, deren Größe nur durch die jeweiligen Änderungen bestimmt ist. In unserem Beispiel beanspruchen diese Über-Behälter daher jeweils nur wenige Bytes Platz. Jeder dieser Über-Behälter stellt ein lauffähiges, konfiguriertes Betriebssystem dar, das sich wie ein virtueller Server verhält. Alle Änderungen, also Schreibprozesse im laufenden Betrieb, werden in jeweils neue Behälter geschrieben (das sind also weitere 20), aber wenn Sie diese Änderungen nicht aufheben wollen, können Sie diese Änderungen letztlich wieder verwerfen.

Das Prinzip der Docker- Behälter. Links eine Ablage schreibgeschütz ter Bestandteile, aus denen zusammen mit einem beschreibbaren Behälter in der Mitte rechts ein lauffähiges System zusammengeste llt wird, das sich wie ein eigener virtueller Server darstellt.

Das Prinzip der Docker-Behälter. Links eine Ablage schreibgeschützter Bestandteile, aus denen
zusammen mit einem beschreibbaren Behälter in der Mitte rechts ein lauffähiges System zusammengestellt wird, das sich wie ein eigener virtueller Server darstellt.

Dieses Konzept erinnert ein wenig an die Haltepunkte (checkpoints) im Hyper-V Manager, nur sind die Docker-Behälter offensichtlich nicht nur platzsparender, sondern viel flexibler einsetzbar. Für Entwickler bieten sich durch die Docker-Behälter sehr gute Möglichkeiten, vollkommen reproduzierbare Tests mit verschiedenen Teilen von Applikationen durchzuführen. Die bereits ausgetesteten Teile kommen in schreibgeschützte Behälter, die man dann zusammen mit den nicht schreibgeschützten und zu überprüfenden Teilen als lauffähige virtuelle Maschine testen kann.

Derzeit gibt es noch keine Benutzeroberfläche für Behälter, die Erzeugung der Behälter und das Zusammenführen in virtuelle Server läuft über diverse Kommandozeilen-Befehle. Dies wird sich im Laufe der Zeit sicher ändern.

Speicher-Replika

Diese neue Entwicklung erlaubt die synchrone oder asynchrone Replikation von Partitionen (genauer: volumes). Diese Technologie ist nicht dateibasiert wie DFS (distributed file system), sondern kann nur ganze Partitionen als Block replizieren. Die Replikation ist sowohl zwischen Cluster, als auch zwischen Partitionen auf ein und demselben Server, als auch zwischen Partitionen auf verschiedenen Servern möglich. Im Weiteren gehe ich von der letzten Situation aus, Replikation zwischen Server A und B.

Schema der synchronen Speicherreplikation.

Schema der synchronen Speicherreplikation

Die synchrone Replikation hat Ähnlichkeiten mit einem software-basierten RAID 1, nur dass Sie eben über Server und sogar über Rechenzentren hinweg einsetzbar ist. Das Verfahren erfordert das Anlegen einer Log-Datei sowohl am Server A als auch am Server B. Ist die Replikation eingeschaltet, läuft ein Schreibprozess auf die Partition am Server A wie folgt ab: Der Block wird in die A-Log Datei geschrieben -> der Block wird in die B-Log Datei geschrieben -> der Block wird aus dem A-Log in die A-Platte geschrieben und aus dem B-Log in die B-Platte geschrieben -> nur wenn beides erfolgreich war, erhält der Nutzer wieder eine Eingabeaufforderung als Zeichen der erfolgreichen Durchführung des Schreibbefehls.

Da für die synchrone Replikation eine kurze Latenzzeit erforderlich ist, macht der Einsatz von langsamen Wechsel-Laufwerken wie USB-Sticks keinen Sinn und wird nichtunterstützt. Außerdem müssen die Platten auf A und B dieselben Hardware-Eigenschaften haben, aber nicht gleich groß sein.

Zusätzlich kann man die Speicher-Replikation asynchron durchführen. In dem Fall entfällt das Warten auf Rückmeldung des erfolgreichen Schreibprozesses in die B-Log Datei, d.h. die Latenzzeiten können größer sein, aber man erhält auch nur im Nachhinein die Möglichkeit, den Erfolg des Schreibprozesses zu kontrollieren.

Die Voraussetzung für die Nutzung der Technologie ist, dass alle beteiligten Server in einer Windows Domäne sind, damit die Kerberos-Authentifizierung funktioniert. Außerdem müssen alle beteiligte Server die Datacenter Edition von Windows Server installiert haben.

Eine naheliegende Frage ist, welche Vorteile die Speicher-Replikation gegenüber der Hyper-V Replikation bietet. Erstere ist offenkundig viel flexibler, weil beliebige Daten repliziert werden können und nicht nur vhd/x-Dateien. Aus eigener Erfahrung möchte ich auf einen weiteren Nachteil der Hyper-V Replikation hinweisen. Wenn Sie 20 TB Daten in einer virtuellen Festplatte liegen haben, so ist das vom Dateisystem aus gesehen eine einzige Datei. Wenn auch nur ein Bit dieser Datei durch irgendeinen Fehler umgedreht wird, sind ihre 20 TB nicht mehr lesbar und Sie verlieren alle Daten.

Neuerungen in Hyper-V Virtualisierung

Mit den Neuerungen in Hyper-V reagiert Microsoft sowohl auf das Misstrauen vieler Kunden gegenüber der Cloud als auch auf die stark zunehmenden Angriffe auf Rechenzentren durch eine drastische Verbesserung der Sicherungstechnologien, die wir schon im ersten Punkt allgemein angesprochen haben. Diese neuen Sicherheitstechnologien schlagen sich besonders in Änderungen der Hyper-V Technologie nieder, die hier zusammen mit den anderen Verbesserungen der Microsoft Virtualisierungsplattform besprochen werden.

Verschlüsselung

Virtuelle Windows Server (VM) können in Windows Server 2016 mittels eines virtuellen TPM-Chips auf 2 Arten geschützt werden. Erstens kann man dadurch Bitlocker in der VM aktivieren und somit alle Daten innerhalb der VM verschlüsseln. Zusätzlich kann man eine VM zur geschützten VM erklären. Dann ist sie auch nur auf dem vorgesehenen Wirtsserver lauffähig und kann nicht auf einen anderen Wirt kopiert oder übertragen werden.

Bessere Isolation

Eine sehr einleuchtende Neuerung, die sich aus den Erfahrungen Microsofts mit Azure ergibt, ist die verbesserte Isolation der VMs gegeneinander, um zu verhindern, dass einzelne VMs bzw. ihre Festplatten einen Hyper-V Server mehr oder weniger unkontrolliert lahmlegen. Man kann nunmehr auch die Bandbreite, die einer virtuellen Festplatte zur Verfügung steht, begrenzen, Microsoft spricht von distributed storage quality of service.

Höhere Elastizität

Eine weitere Verbesserung ist das Verhalten eines Clusters bzw. der Cluster-Komponenten im Falle eines kurzfristigen Ausfalls einzelner Bauteile. Bisher haben solche Ausfälle, auch wenn Sie nur Sekunden gedauert haben, in der Regel zu einem Absturz von VMs geführt. In Windows Server 2016 verhalten sich Cluster-Komponenten wesentlich robuster und nehmen ihren Betrieb automatisch wieder auf, wenn die Netzwerkverbindungen wieder funktionieren. Es gibt sogar eine Art automatischen Quarantäne-Modus für Komponenten, die ungewöhnlich häufig ausfallen.

Einfachere Replikation

Wenn Sie Hyper-V Replikation einsetzen, haben Sie sicher schon erfahren, wie mühsam es ist, in eine bestehende Replikation weitere virtuelle Platten zu integrieren. Bislang mussten Sie die Replikation aufheben, alles neu konfigurieren und von vorne anfangen. Das ist in Windows Server 2016 zum Glück nicht mehr erforderlich, sie können zusätzliche virtuelle Festplatten sehr komfortabel in eine laufende Replikation einbinden. Für die neue virtuelle Platte beginnt dann eine initiale Replikation, während die anderen Replikationen weiterlaufen.

Konfigurationsänderungen im laufenden Betrieb

Als Hyper-V in Windows Server 2008 eingeführt wurde, war jede kleinste Konfigurationsänderung einer VM nur im ausgeschalteten Zustand möglich. Das hat sich in Windows Server 2012 schon gebessert, aber es galt immer noch: Mehr Speicher? Herunterfahren, konfigurieren, wieder starten. Zusätzliche Netzwerkverbindung? Herunterfahren, konfigurieren, wieder starten. Beide Probleme sind nunmehr behoben, diese Änderungen sind im laufenden Betrieb möglich.

Dynamische Cluster-Updates

Erstaunlich ist auch der Upgrade-Prozess eines Windows Server 2012 R2 Clusters auf Windows Server 2016. Auch dieser Vorgang ist im laufenden Betrieb unterbrechungsfrei möglich. Sollten doch Probleme auftreten, kann man den Aktualisierungsprozess im laufenden Betrieb wieder zurücknehmen.

Haltepunkte für den produktiven Betrieb

Haltepunkte (checkpoints oder früher snapshots genannt) sind eine hervorragende und beliebte Möglichkeit, den Zustand eines virtuellen Servers vor einer Änderung zu sichern, sodass man im Notfall wieder zu der vorherigen Version zurückkehren kann. Allerdings hat Microsoft immer davor gewarnt, diese Haltepunkte im produktiven Betrieb einzusetzen. Das Problem bestand vor allem bei Datenbanken wie SQL oder Exchange, die mit der Technologie eines eingefrorenen und später wiederbelebten Betriebssystems nicht kompatibel sind. Wenn Sie einen früheren Haltepunkt wieder einspielen, passt die Zeit der letzten Änderungen und die momentane Zeit nicht zusammen, was zu einer Korruption der Datenbanken führen kann.

In Windows Server 2016 gibt es nun außer den alten Haltepunkten auch produktive Haltepunkte (production checkpoints). In dieser Technologie werden VMs nicht einfach eingefroren, sondern es wird die normale VSS (volume shadow copy service) Datensicherungs-Technologie benutzt, sodass die Wiederherstellung einer früheren Version einer VM eine kontrollierte Systemwiederherstellung ist, die von SQL und Exchange verstanden wird.

Durchgriff zu Gast-Powershell

Unter diesem merkwürdigen Begriff (powershell direct) verbirgt sich eine erleichterte Verwaltung bei Vorhandensein sehr vieler virtueller Server. Man kann nämlich nunmehr in der Powershell eines Hyper-V Wirt-Servers Powershell cmdlets absetzen, die direkt im Gast-Server ausgeführt werden, ohne dass man sich anmelden bzw. immer wieder eine remote-powershell Sitzung erzeugen muss. Man kann damit viele VMs von der Powershell aus sehr komfortabel einrichten und konfigurieren. Es gibt noch eine Vielzahl kleinerer Änderungen und Verbesserungen, aber die wichtigsten Punkte dürften hier aufgeführt sein.