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
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-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