Mit Infrastructure as a Service (IaaS) öffnet Microsoft die Windows-Azure-Rechenzentren auch für IT Professionals und ermöglicht neue Szenarien. Zu den Neuerungen gehören Persistent Virtual Machines und Virtual Private Networks. So lassen sich Windows- wie Linux-Server in der Azure-Cloud betreiben.
von Heike Ritter, TecChannel
Bis zum sogenannten "Spring Release" war Windows Azure primär Microsofts Cloud Plattform für Entwickler. Mit Plattform as a Service (PaaS) stellt Windows Azure eine Umgebung zur Verfügung, auf der Anwendungen bereitgestellt und nach Bedarf skaliert werden können. Zur Erstellung Azure-basierter Anwendungen stehen verschiedene Entwicklungs- und Management-Umgebungen (Visual Studio, Eclipse…) und Programmiertechnologien (.NET, Java, PHP, Node.js, Python, …) mit entsprechenden APIs zur Verfügung. Um die darunter liegenden Schichten wie Betriebssystem, Virtualisierung, Server, Speicher oder Netzwerk kümmert sich Microsoft in den eigenen, weltweit verteilten Rechenzentren.
Daniel Melanchton hat auf dem Microsoft TechSummit Cloud 2011 einen Vortrag darüber gehalten, wie und mit welcher Strategie Microsoft die eigenen Rechenzentren betreibt und verwaltet.
Persistent Virtual Machines und Virtual Private Networks sind Neuerungen in Windows Azure, die Administratoren neue Szenarien erlauben, wie folgender Beitrag eingehend erläutert.
Windows Azure Virtual Machines
Mit Windows Azure können Sie persistente virtuelle Maschinen (VMs) ausführen, welche entweder über die Vorlagengallery oder auch durch eigene angepasste Vorlagen erstellt werden. Auch das Verschieben von bestehenden Betriebssystem- (OS) sowie Daten-VHDs, aus der eigenen Infrastruktur ist möglich, und dabei behalten Sie die volle Kontrolle über Ihre virtuellen Systeme.
Windows sowie Linux Server, BackOffice Anwendungen wie SharePoint Server, SQL Server oder auch der Verzeichnisdienst Active Directory können in der Azure Cloud betrieben werden. Sie können Ihre Anwendungen sowie Ihre Infrastruktur in die Cloud migrieren oder erweitern, ohne vorhandenen Code zu ändern.
Aber was genau bedeutet persistent? Dazu vorab ein paar Hintergrundinformationen: Bereits seit 2010, mit der Einführung von Windows Azure gibt es zustandslose virtuelle Maschinen, welche den Namen stateless VM Role haben und angepasste VMs sind, die nach Windows Azure via CSUpload.exe hochgeladen werden. Ebenfalls sind Web- und Workerrollen, auf denen Ihre eigenentwickelten Azure-Anwendungen ausgeführt werden, virtuelle Maschinen.
Via RDP (Remote Desktop Protocol) kann auf den Desktop der Maschine zugegriffen, jegliche Art von Anpassungen über die Oberfläche gemacht oder zusätzliche Komponenten und Anwendungen installiert werden, aber Achtung: davon wird dringend abgeraten, denn bei einem Re-Imaging oder erneuter Bereitstellung der VM, aufgrund eines Fehlers, gehen sämtliche manuell vorgenommenen Änderungen verloren. Deshalb müssen immer mindestens zwei Instanzen definiert sein, damit Microsoft die SLA von 99,95 gewährleisten kann, wenn bei einem Re-Imaging oder erneutem Bereitstellen einer Instanz, Ihre Anwendung in der anderen weiter ausgeführt wird.
Microsoft stellt in den Rechenzentren sicher, dass die Instanzen auf separaten Servern, separaten Racks, mit separater Stromversorgung und separaten Routern betrieben werden, damit auch bei einem Hardwarefehler oder Stromausfall Ihre Anwendung weiter ausgeführt wird und erreichbar ist. Wenn Sie eine Anwendung auf Windows Azure bereitstellen, wählen Sie bei der Bereitstellung die Größe der VM und die Anzahl der Instanzen, die für das Ausführen der Anwendung benötigt werden, sowie zusätzliche Ports und weitere Einstellungen. Diese Werte werden in eine Definitionsdatei gespeichert anhand dieser Windows Azure die passenden VMs im Rechenzentrum bereitstellt, IIS, Firewall und Zertifikate konfiguriert und Ihren Anwendungscode installiert. Zuletzt werden die VMs an einen Load Balancer gehangen und die Anwendung so mit einer Public IP Adresse übers Internet erreichbar gemacht.
Sollte ein Fehler auftreten, beispielsweise im OS oder der Hardware wird dies von den Windows-Azure-Monitoring-Komponenten erkannt und diese VM wird aus dem Umlauf genommen. Es wird eine neue VM hochgefahren und die gleiche Prozedur wie oben beschrieben findet erneut statt. Die Änderungen, die Sie möglicherweise an der Virtuellen Maschine via RDP vorgenommen haben, werden hierbei nicht berücksichtigt und gehen somit verloren. Es gibt keinen Mechanismus, der die Anpassungen mitprotokolliert, speichert und später wieder einspielt. Aus genau diesem Grund, wird deswegen davon abgeraten, manuelle Einstellungen an diesen VMs vorzunehmen oder Daten darauf abzulegen und stattdessen Windows Azure Disks, Windows Azure Blob Storage oder zum Beispiel in SQL Azure zu nutzen. Der Vorteil dieses Dienstes besteht darin, dass sich Microsoft um jegliche Updates und Wartungen der Systeme kümmert und Sie um Ihre Anwendung.
Persistent Virtual Machines
Die Laufwerke von persistenten Maschinen, OS und Daten-VHDs, werden im Windows Azure Storage System gesichert, welches auch von anderen Windows Azure Diensten genutzt wird. Die Daten sind dort auf drei unterschiedliche Disks im Storage System gespeichert und dreifach repliziert. Sollte eine Disk ausfallen, wird zu einer der anderen zwei Disks gewechselt - ohne jegliche Unterbrechung, ohne Neustartanforderung der VM. Standardmäßig werden die Daten in ein anderes Microsoft Rechenzentrum gesichert, welches mindestens 800 km entfernt ist.
Das Windows Azure Storage System ist ausfallsicher gebaut und durch eine asynchrone Geo-Replikation sind die Daten auch dann noch vorhanden, wenn z.B. durch einer Naturkatastrophe eine ganze Region ausfällt. Diese Geo-Replikation kann auch abgeschaltet werden, falls es hier beispielsweise datenschutzrechtliche Auflagen zu erfüllen gibt.
Virtuelle Maschinen erstellen
Im Windows Azure Portal kann aus verschiedenen Vorlagen (Images genannt) eine neue VM erstellt werden. Die Vorlagengallery beinhaltet derzeit Windows und Linux Server, sowie vorbereitete SQL oder SharePoint Server.
Nach wenigen Klicks ist die VM fertiggestellt und steht zur weiteren Konfiguration zur Verfügung. Auch können Sie Ihre eigenen, angepassten Vorlagen erstellen und in die Vorlagengallery bringen. Eine Vorlage unterscheidet sich von einem Produktivsystem darin, dass keine maschinenspezifischen Einstellungen, wie beispielsweise Computername enthalten sind. Vorlagen eines Windows Servers erstellen Sie, indem Sie sich via RDP auf die Maschine verbinden und das Kommandozeilen Tool sysprep, welches sich in dem Ordner %windir%\system32\sysprep befindet, verwenden, um maschinenspezifische Einstellungen zu entfernen. Es öffnet sich ein Fenster, bei welchem Sie die Option Enter System Out-of-Box Experience (OOBE) und Shutdown auswählen.
Nachdem der Standardisierungsprozess durchgelaufen ist, fährt das System runter und schaltet die Maschine ab. Auch im Portal wird diese nach ein paar Minuten als gestoppt angezeigt und dann kann die Schaltfläche Capture zur Fertigstellung angeklickt werden.
Im nächsten Schritt noch einen Vorlagennamen eingeben und das Häkchen bei I have sysprepped the virtual machine. Durch dieses Häkchen bestätigen Sie, dass Sie wissen, was Sie da machen
Danach ist die neue Vorlage nicht mehr unter VM Instances sondern unter Images sichtbar und in der Vorlagengallery verfügbar, um neue Virtuelle Maschinen auf Basis dieser zu erstellen.
Eigene Linux Vorlagen erstellen
Für Linux Distributionen stehen Ihnen ebenfalls ein paar nützliche Werkzeuge zur Verfügung, um angepasste Vorlagen für Ihre Imagegallery zu erstellen. An dieser Stelle sei das einfache Erstellen und Anpassen eines Suse Images mit der Webseite http://susestudio.com/ erwähnt.
Sie können sich dort mit einer bereits vorhandenen Online-ID wie beispielweise von Facebook, Yahoo, Twitter und Google anmelden. Danach geht’s gleich los mit Create new appliance um ein Basissystem, die Architektur und einen Namen auszuwählen (derzeit nur 32 Bit in Windows Azure möglich). Nach dem Klick auf Create Appliance haben Sie über weitere Registerkarten am rechten oberen Rand zusätzliche Konfigurationsmöglichkeiten.
So können Sie beispielsweise nach zusätzlicher Software suchen, welche dann in das Image mit aufgenommen wird und über "Configuration" können Sie Einstellungen zu Tastatur-, Firewall, Benutzern und vieles mehr vorab vornehmen.
Susestudio kann das fertige Image sogar direkt in Ihren Windows Azure Storage Account hochladen, wenn Sie vorher die entsprechenden Anmeldeinformationen hinterlegt haben. Um dies einzurichten, benötigen Sie die Profile Settings, welche Sie als Datei direkt vom Windows Azure Portal heruntergeladen können. Damit navigieren Sie zu Ihrem Account auf Susestudio, wählen Linked Accounts, laden die Settings Datei bei Windows Azure hoch und wählen den gewünschten Storage Service. Das Hochladen geht zu guter Letzt über Build und wenn Sie vorher Ihren Windows-Azure-Account verknüpft haben, steht auch das Upload-Format Windows Azure zur Auswahl bereit.
Vorhanden virtuelle Maschinen nach Windows Azure bringen
Auch können eigene VHDs in die Windows Azure Cloud verschoben werden, ohne dass diese irgendwie vorher konvertiert werden müssen - es bleibt das gleiche Format, welches auch bei einem On-Premise Hyper-V Server verwendet wird. Das Kommandozeilentool CSUpload.exe wird genau dazu verwenden, um VHD Dateien (Windows und Linux) nach Windows Azure und Dienstzertifikate für Remotedesktopverbindungen hochzuladen. Mehr Informationen zu CSUpload.exe gibt es in diesem MSDN Artikel.
Nachdem die eigene VHD Dateien in das Azure Portal geladen wurde, kann dort über Virtual Machines, Images, Create Image aus dieser VHD, eine Vorlage für die Imagegallery erstellt werden.
Nicht nur in die Cloud, sondern auch aus den Windows Azure Rechenzentren können VHDs wieder zurück in das eigene Rechenzentrum verschoben werden. Damit adressiert Microsoft das Thema "Vendor Lock-In" und erlaubt eine flexible Wahl bezüglich Software, Service Provider, Deployment und Workload.
Foto: Heike Ritter / Microsoft
Es gibt also kein Re-Imaging und bei einem Fehler wird eine der zwei synchronisierten Disks angehangen - alle Änderungen an der virtuellen Maschine bleiben erhalten. Dies bringt viele neue Möglichkeiten mit sich. Zum einen können Konfigurationsänderungen an dem Betriebssystem selbst vorgenommen werden und zum anderen kann auch jegliche Software in der VM betrieben werden (hier sollten die Lizenzfragen mit dem Softwareanbieter vorher geklärt werden) und jetzt in der Cloud laufen, ohne dass diese vorher umgeschrieben oder gar neu geschrieben werden muss.
Es gibt viele Anwendungen, die lokale Konfigurationsänderungen vornehmen, wie SharePoint Server, der bei der Installation Änderungen an der Registry oder am IIS vornimmt.
Zwar gibt es mit Office 365 und SharePoint Online bereits SharePoint in der Cloud, dennoch kann es gute Gründe für einen anderen Betrieb geben. SharePoint steht als Software as a Service (SaaS) in einer Multitenant Umgebung in der Cloud bereits zur Verfügung und ist für viele Anwender vollkommen ausreichend. Andere Organisationen wiederum haben bestimmte Anforderungen an die eine oder andere Anpassungsmöglichkeit von SharePoint, was mit SaaS nicht immer möglich ist. Beispielweise ist der Zugriff auf die Zentraladministration nicht komplett gegeben und manche On-Top Lösungen von Partnern können nicht implementiert werden.
Windows Azure Virtual Network
Vor dem Spring Release von Windows Azure existierte bereits eine Auswahl an Möglichkeiten, um Ihre IT Umgebung mit der Public Cloud zu verbinden. Sie konnten SQL Data Sync verwenden um Datenbanken zu synchronisieren, Service Bus für Konnektivität auf Anwendungsebene und Windows Azure Connect für eine sichere Maschine-to-Maschine Verbindung auf IP Ebene.
Foto: Heike Ritter / Microsoft
Jetzt, mit Windows Azure Virtual Network, hat Microsoft die Cross-Premises Verbindungsmöglichkeiten so erweitert, das Sie Standort zu Standort (Site-to-Site VPN) Verbindungen erstellen können, ganz so als würden Sie einen weiteren Firmenstandort an Ihr Unternehmensnetzwerk anschließen.
Damit können Sie logisch isolierte Umgebungen in Windows Azure erstellen, um Ressourcen in einem Adressbereich zu platzieren und diese, durch einen sicheren IPsec VPN Tunnel, als logische Erweiterung mit Ihres Firmennetzwerks verbinden. Dabei steuern Sie Ihre Netzwerktopologie selber, einschließlich der Konfiguration von eigenen IP4-Adressen, Routingtabellen und Sicherheitsrichtlinien und können so die Kapazität Ihres Rechenzentrums auf sichere Weise skalieren.
Ein virtuelles privates Netzwerk in Windows Azure erstellen
Beim Erstellen eines virtuellen Netzwerks, geben Sie einen privaten Adressbereich im CIDR Format 10.0.0.0/8, 172.16.0.0/12, oder 192.168.0.0/16 an, den DNS Server der zur Namensauflösung der Maschinen benutzt werden soll und können zusätzlich logische Subnetze erstellen.
Virtuelle Maschinen die innerhalb dieses VNET oder eines der Subnetze gestartet werden, wird automatisch eine IP Adresse aus dem von Ihnen angegebenen Adressbereich zugewiesen. Selbstverständlich sind die VNETs logisch voneinander isoliert, sodass Ihre privaten IP Adressen nicht mit anderen Kunden kollidieren, auch wenn diese dieselben verwenden. Sie weiter aufgefordert eine Affinity Group auszuwählen beziehungsweise zu erstellen, was eine Möglichkeit ist, Windows Azure Dienste physikalisch zusammen in einem Rechenzentrum zu gruppieren, um die Performance zu erhöhen. Nur ein virtuelles Netzwerk kann einer Affinity Group zugewiesen werden.
Einen VPN-Tunnel zum eigenen Netzwerk erstellen
Sobald Sie ein VNET erstellt haben, können Sie dieses auf sichere Weise mit Ihrem On-Premise Netzwerk zu verbinden, woraufhin für Sie automatisch ein VPN Gateway in Windows Azure bereitgestellt wird.
Foto: Heike Ritter / Microsoft
Alles was Sie dann noch tun müssen, ist das VPN Gateway auf Ihrer Seite zu konfigurieren um den Tunnel fertigzustellen. Dazu laden Sie sich sowohl den gemeinsamen Schlüssel Shared Key sowie das VPN Device Config Script aus dem Portal herunter und konfigurieren damit Ihren eigenen VPN Router in Ihrem lokalen Netzwerk. Es stehen Konfigurationsdateien für die gängigsten VPN Geräte zur Verfügung.
Das VPN Gateway Ihres lokalen Netzwerks muss folgende Anforderungen erfüllen:
-
über eine öffentliche IP Adresse verfügen
-
das IKEv1 Protokoll unterstützen
-
eine IPsec Vertrauensstellung im Tunnelmodus aufbauen können
-
Netzwerkadressübersetzung mit NAT-T
-
Unterstützung der AES 128-bit Verschlüsselung, SHA-1 Hashfunktion und Diffie-Hellman (PFS, Perfect Forward Secrecy) im Modus "Group 2?
-
Pakete fragmentieren, bevor diese mit VPN IP-Headern eingekapselt werden
Mit den Neuerungen des Spring Release, können virtuelle Maschinen in Windows Azure Ihrer On-Premises Domäne beitreten, Sie können eine sichere Verbindung zwischen Cloud-basierten Anwendungen und einer beliebigen Art von lokalem System (wie Mainframes oder Unix-Systeme) herstellen und Teile Ihrer Infrastruktur und Anwendungen in der Public Cloud und andere Teile in Ihrem lokalen Rechenzentrum ausführen.
So kann eine klassische Rich-Client Anwendung Daten in Windows Azure Storage speichern, Apps auf mobilen Endgeräten über Windows Azure Nachrichten untereinander austauschen, eine lokal betriebene SQL Server Datenbank sich ganz oder in Teilen mit einer Cloud Datenbank synchronisieren, eine in Windows Azure betriebene Webanwendung über den Service Bus ein lokal ausgeführtes Backend-System aufrufen. Viele weitere Hybrid-Szenarien sind denkbar.
Dieser Artikel stammt von unserer Schwesterpublikation TecChannel. (kv)