Tags: Amazon EC2, Storage, Hardware
Bevor man sich daran macht, virtuelle Maschinen auf AWS einzurichten, sollte man sich einen Überblick über die Kaufoptionen und Instanztypen verschaffen. Darüber hinaus bietet Amazon die Auswahl zwischen mehreren Hypervisoren. Schließlich ist für den Lebenszyklus einer Instanz der gewählte Speicher wichtig.
Bei den EC2-Instanzen unterstützt AWS neben dem On-Demand-Modell auch Kaufoptionen, die es bei kaum einem der anderen Dienste gibt. Dazu zählen Reserved, Scheduled, Spot, Dedicated Instance und Dedicated Host. Einzelheiten dazu liefert die Dokumentation.
Über 100 Instanztypen in 5 Gruppen
Das für die Cloud typische Prinzip Pay As You Go liegt aber allen Modellen zugrunde. Wie behandeln hier nur On-Demand-Instanzen. Derzeit bietet AWS über 100 verschiedene Instanz-Typen, gruppiert in die 5 Familien Allgemeine Zwecke, Für Datenverarbeitung optimiert, RAM-optimiert, Accelerated Computing (GPU optimiert) und Speicher-optimiert.
Sie weisen jeweils ein dominierendes Attribut auf, um das beste Preis-/Leistungs-Verhältnis für bestimmte Anwendungen zu erzielen. Dazu gehören zum Beispiel der CPU-Typ des Hosts nebst verfügbarer Zahl virtueller Kerne, die Größe des RAM, die Netzwerkbandbreite, die Nutzbarkeit von GPUs (etwa mit nVidia Tesla) oder die verfügbaren Typen des Instanzspeichers und dessen maximale Größe/Performance.
Die On-Demand-Preise bewegen sich je nach Region zwischen 0,0067 USD pro Stunde für eine Linux-basierte t2.nano-Instanz mit 1 vCPU und 512MB RAM bis zu 32,066 USD pro Stunde für eine Windows-SQL-Server-Enterprise-basierte r4.16xlarge-Instanz mit 64 vCPUs und 488 GB RAM (beide Beispiele gelten für Frankfurt).
AWS-Hypervisor
Auf den physischen Hosts läuft derzeit noch ein von AWS modifizierter Xen-Hypervisor in verschiedenen Iterationsstufen, heute meist im HVM-Modus (statt früher paravirtualisiert). Somit teilen sich Anwender den Host mit Instanzen anderer AWS-Kunden, wobei der Hypervisor für die Abschottung zwischen ihnen sorgt, so wie bei jeder anderen Virtualisierungslösung auch.
Wie obige Abbildung aus Brendan Greggs Blog zeigt, verwenden die derzeit meisten Amazon Machine Images (AMIs) die Ausbaustufe Xen AWS 2017 mit Support für SR-IOV (net UND store), die nahezu native Performance für CPU/Memory, Network I/O, Local Storage, Remote Storage, Interrupts, Timer und Motherboard bietet.
Allerdings arbeitet AWS aktuell an einem neuen Nitro-Hypervisor auf KVM-Basis, der wohl mittelfristig auf allen Systemen zum Einsatz kommen wird. Derzeit ist er aber nur experimentell verfügbar, genau wie der zusammen mit VMware entwickelte Bare-Metal-Typ mit C5-Instanzen.
Dies muss aber den Einsteiger nicht kümmern, wenn sie den Free-AWS-Tier mit 750 Stunden EC2 nutzen, weil dieser ohnehin nur den Typ t2micro mit 1 vCPU und 1 GB RAM umfasst.
Storage-Anbindung und Instance-Lifecycle
AWS unterscheidet zusätzlich zwischen Instanzen, deren virtuelle Festplatten auf Elastic Block Volumes (EBS) liegen oder die das so genannte Instance Storage verwenden. Bei Letzterem handelt es sich um ein direkt angeschlossenes Block-Device-Storage, dessen Inhalt nicht persistent ist.
EBS hingegen entspricht beim Vergleich mit einem physischen Rechenzentrum etwa einer via SAN bereitgestellten LUN, so dass ein EBS-Volume immer über das Netzwerk an die Instanz angebunden ist. Dies verursacht je nach Leistungsfähigkeit der Netzwerkanbindung gewisse Latenzen, sorgt aber auf der anderen Seite für Persistenz.
Ein EBS-Volume bleibt stets mit dem Account verknüpft und lässt sich nach dem Terminieren einer Instanz behalten und bei Bedarf (z. B. bei Daten-Volumes) an eine andere Instanz binden. Es kann aber auch nach einer horizontalen Skalierung durch Ändern des Instanztyps als Boot-Volume weiterverwendet werden.
Der Vorteil bei EBS besteht also darin, dass sich der Nutzer nicht um die Verfügbarkeit der EBS-Volumes kümmern muss, da AWS diese innerhalb der Availability Zone automatisch repliziert. Die kleineren, etwa die im Free-Tier berechtigten Instanzen wie t2micro unterstützten ausschließlich EBS-Volumes.
Der Lebenszyklus einer Instanz ist unmittelbar an dem Typ des angebundenen Storage gekoppelt, wie die obige Abbildung zeigt.
Der gesamte Instanz-Lifecycle von der Erstellung einer Instanz auf Basis einer Vorlage (AMI = Amazon Machine Image) bis zu deren Terminierung lässt sich in der AWS Management Console steuern.
Täglich Know-how für IT-Pros mit unserem Newsletter
Seine Themenschwerpunkte sind Virtualisierung und Cloud Computing, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zertifizierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas ist außerdem zertifizierter AWS Solutions Architect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Administrator.
Thomas führt aktuell jeden zweiten Montag einen 4-tägigen Grundlagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Informationen und Anmeldung über sein AWS-Blog.
Verwandte Beiträge
- Virtuelle Maschine für Synology VMM erstellen
- Festplatten auf SSD klonen mit kostenlosen Tools von Samsung und SanDisk
- Anleitung: Festplatte in Xbox One durch SSD ersetzen
- Hardware für Storage Spaces Direct auswählen und validieren
- Controller, Cache, Laufwerkstypen: Speicher für Storage Spaces Direct planen
Weitere Links