次の方法で共有

Serie: Eigene Anwendungen auf Microsoft Azure - Teil 2: Virtual Machines

  • [アーティクル]

Microsoft Azure bietet zur Ausführung eigener Anwendungen in der Public Cloud vier Optionen: Virtual Machines, Cloud Services, Websites und Mobile Services. Diese Blog-Serie gibt Hinweise zur Entscheidung für die zu einem konkreten Vorhaben beste Alternative, Die Serie ist unterteilt in 7 Teile:

Dieser Teil geht auf Virtual Machines ein. Virtual Machines sind die Ausführungsoption, die wohl die meisten Personen vor Augen haben, die über die Ausführung Ihrer Anwendung in der Cloud nachdenken. Sie stellen das Infrastructure-as-a-Service-Angebot (IaaS) auf Microsoft Azure dar.

Virtual Machines erlauben den Betrieb selbst erstellter oder von Microsoft bereitgestellter virtueller Maschinen auf Microsoft Azure. Diese werden minutengenau abgerechnet. Zur Bereitstellung einer Virtual Machine ist letztlich nur die Festlegung eines VM-Image (hier werden Standard-Hyper-V-Images eingesetzt), auf deren Basis der Bootvorgang ablaufen soll, sowie ein paar wenige Konfigurationsparameter erforderlich:

  • VM-Größe
  • Administrator-Kennung
  • DNS-Name
  • Azure Subscription
  • Die Region des Rechenzentrums, in dem die VM ausgeführt werden soll

Auf die dann in Azure ausgeführten Virtual Machines haben Nutzer vollen Adminstrator-Zugang. Sie können sich z.B. per Remote Desktop auf eine VM einwählen und die Maschine ihren Wünschen entsprechend konfigurieren. Die in den virtuellen Maschinen eingesetzten Festplattenlaufwerke werden im Blob Storage persistiert. Virtual Machines eignen sich deshalb ideal für eine schnelle Migration einer bestehenden On-premise-Anwendung in die Cloud. Prinzipiell können die VMs der lokalen Umgebung in die Cloud übertragen oder quasi 1:1 in der Cloud nachgebaut werden.

Durch die Persistierung der VM-Disks im Blob Storage bleiben – im Gegensatz zu den nicht-persistenten Images der Cloud Services – alle Inhalte erhalten, sollte eine virtuelle Maschine einem Re-Image unterzogen werden (z.B. bei Hardware-Ausfall). Für die Inhalte gelten die gleichen Regeln für Failover (3-fach-Speicherung aller Inhalte, optionale Geo-Replikation in ein entferntes Rechenzentrum) wie für alle anderen Inhalte des Blob Storage. Da von Microsoft Azure Standard-VHDs genutzt werden, können sowohl bestehende VMs aus einer lokalen Hyper-V-Umgebung in die Cloud migriert und als Virtual Machine ausgeführt, als auch der umgekehrte Weg beschritten werden: VHDs können aus Microsoft Azure heruntergeladen und in einer entsprechenden Hyper-V-Umgebung lokal ausgeführt werden.

Als Gast-Betriebssysteme für Virtual Machines werden sowohl verschiedene Windows Server Varianten als auch ausgewählte Linux-Distributionen unterstützt. Ebenfalls unterstützt werden einige Serveranwendungen wie SQL Server, SharePoint Server, BizTalk Server und Active Directory. Durch Kooperation mit Oracle werden auch Anwendungen aus dem Oracle-Technologieportfolio (WebLogic, Java, Oracle DB, …) unterstützt. Es ist möglich, neue Images in einer lokalen Hyper-V-Umgebung zu erzeugen, nach Windwos Azure zu laden und von den Images neue Virtual Machines zu booten. Daneben können auch bereits vorgefertigte mit entsprechender Serversoftware bestückte Images aus einer Gallery (siehe Abb 1) ausgewählt und gestartet werden.

image

Abb 1: Virtual Machine Gallery

Damit ist es möglich, wichtige Teile der Serverumgebungen eines eigenen Rechenzentrums ohne Änderung nach Microsoft Azure zu migrieren. Die minutengenaue Abrechnung macht dieses Ausführungsmodell auch für die Bereitstellung von Test- oder Demo-Umgebungen interessant, wo Infrastruktur nur temporär benötigt wird.
Wie die anderen Ausführungsmodelle können auch Virtual Machines in Kombination mit anderen Azure Services genutzt werden. So kann eine in einer VM ausgeführte Anwendung beispielsweise problemlos Microsoft Azure Storage oder SQL Database nutzen. Besonders interessant ist die Kombination mit dem Virtual Network: Durch die Möglichkeit ein lokale und Cloud-basierte VMs umspannendes virtuelles Netzwerk mit gemeinsamen Ipv4-Adressraum und entsprechenden Routing Tabellen einzurichten, können virtuelle Maschinen flexibel zwischen der Cloud und einem lokalen Rechenzentrum hin- und hergeschoben werden ohne dass dies aus Netzwerksicht Auswirkungen auf die anderen VMs hat.

Die hohe Flexibilität der Virtual Machines kommt allerdings zu dem Preis, dass ein signifikanter Teil der Infrastruktur im Verantwortungsbereich des Nutzers verbleibt, d.h. er muss sich um das Setup und die Wartung der VM-Images kümmern (Patches und Upgrades einspielen).

Gründe für die Wahl von Virtual Machines als Ausführungsumgebung können deshalb sein:

  • Linux wird als Gast-OS für die eigene Anwendung benötigt
  • Es werden administrativer Zugriff und entsprechende Konfigurationsmöglichkeiten benötigt

Gründe für die Wahl einer der anderen Ausführungsoptionen (Cloud Services, Websites oder Mobile Services)  können entsprechend sein:

  • Das Management der Infrastruktur soll vollständig von Azure übernommen werden.
  • Maßnahmen für Failover und High-Availability sollen von Azure automatisiert durchgeführt werden.

Fazit

Die Microsoft Azure Dokumentation enthält einen tabellarischen Überblick über die Möglichkeiten der einzelnen Ausführungsoptionen. Als Fazit kann gezogen werden:

  • Virtual Machines sollten nur dann verwendet werden, wenn es entscheidende Gründe hierfür gibt (es wird ein Feature benötigt, das nur Virtual Machines bieten, z.B. Linux als Gast-OS)
  • Wann immer möglich, sollten die anderen Ausführungsoptionen validiert und ggf. verwendet werden. Sie bieten deutliche (Kosten-)Vorteile im automatisierten Management der Umgebung.

Weitere Informationen

Informationen zu Virtual Machines

Informationen zur allgemeinen Entscheidung für ein Ausführungsmodell