AWS bietet zahlreiche Speicherdienste vom populären Objektspeicher S3, über skalierbaren NAS-Speicher in Form von Elastic File System bis hin zu klassischen Block-Speicher, der im Kontext virtueller Maschinen (EC2) virtuelle Festplatten für Betriebssystem und Daten bereitstellt. Verwendet man hierzu Elastic Block Store Volumes (EBS), bieten sich im Zusammenhang mit EC2 interessante Workflows, die on premise so nicht möglich wären.

Historisch unterstützen virtuelle Maschinen unter AWS zwei Typen virtueller Festplatten, nämlich nicht persistenten „Instance Storage“ und über das Netzwerk verbundene Elastic Block Store Volumes, die man sich im Vergleich zum On-Premise-Data-Center als SAN, bzw. Logical Unit Numbers (LUNs) vorstellen kann, mit SAN-typischen Eigenschaften wie Latenz und Durchsatz/Bandbreite. Dafür bieten sie den unschätzbaren Vorteil der Persistenz, der es überhaupt erst ermöglicht, virtuelle Maschinen in der Cloud stoppen und bei Bedarf neu starten zu können.

Der zweite Block-Gerät-Typ „Instance Storage“ (auch „Ephemeral Storage“ genannt) stammt noch aus der Pre-VPC-Ära, als die AWS-Cloud noch keine logisch isolierten virtuellen Netzwerke bot und VM-Workload stets mit öffentlichen IP-Adressen direkt auf der AWS-Elastic-Compute-Cloud ausgeführt wurden. Da jeder Neustart einer VM (gilt nicht für Reboot bei EBS-gestützten Instanzen) unweigerlich zu einer Platzierung auf einem anderen Host führt, kann ein direkter Durchgriff auf Host-Storage logischerweise nicht persistent sein. Nicht so bei den moderneren EBS-Volumes, auf die wir uns daher im Folgenden konzentrieren.

EBS Performance

Die Tatsache, dass EBS-Volumes stets über das Netzwerk an die jeweilige VM angebunden sind muss Anwender hinsichtlich der zu erwartenden Latenz und Speicherbandbreite nicht schrecken. AWS bietet inzwischen Volume-Typen von bis zu 16 TB und falls gewünscht und in Verbindung mit dem richtigen EC2-Instance-Typ, etwa beim EBS-Typ „IO1“, einer konsistenten Basisleistung von bis zu 50 IOPS/GB und einem Maximum von 64000 IOPS pro Volume, was bereits einem gut konfigurierten SAN im eigenen Datencenter entspräche. Mit dem Typ „Standard-SSD-Volume“ (gp2) erreicht EBS immer noch bis zu 16000 IOPS, Erstere mit einem maximalen Durchsatz von bis zu 1000 MB/s, Letztere bis zu 250 MB/s.

Neben diesem beiden SSD-basierten Typen gibt es noch zwei magnetgische Platten-Typen, nämlich „Durchsatz-optimierte HDDs“ (Throughput Optimized – st1) mit einem Durchsatz von 500 MB/s und Cold-HDDs mit einem maximalen Durchsatz von maximal 250 MB/s. Theoretisch ließe sich die IOPS-Leistung von Gastsystem aus mittels Striping noch erhöhen (abhängig vom Instance-Typ sind bis zu 40 Volumes möglich), allerdings deckelt AWS die maximal zulässige IOPS-Leistung pro Instance auf 80000 IOPS und einen maximal möglichen Durchsatz von 1750 MB/s, was immer noch beachtlich ist.

Bekanntlich ist das dominierende Attribut bei SSDs die IOPS-Leistung und bei HDDs der Durchsatz, wobei es für Beide präferierte Workloads, bzw. Use-Cases gibt. Trotzdem sind EBS-Volumes stets exklusiv an die Instanz gebunden; der Aufbau eines Shared-Storage, bzw. einer Shared-Disk-Architektur z. B. für hochverfügbare Datenbanken oder Fileserver ist hiermit nicht möglich. Hierfür sieht AWS ja gerade das Amazon Elastic Filesystem (FHS) auf Basis von NFS sowie das neue Amazon FSx for Windows Fileserver vor.

EBS in der Praxis

Doch zurück zu EBS in Praxis. Die meisten Anwender kommen zu ersten Mal mit EBS im Zusammenhang mit dem Launchen einer EC2-Intance in Berührung. Der zugehörige Assistent legt sofern man nicht eingreift per Default ein SSD-Volume von Typ „gp2“ als Boot-Volume für das Betriebssystem an. Wer möchte kann den Volume-Typ gleich an entsprechender Stelle durch einen Anderen ersetzen, z. B. ein magnetisches Volume. Interessanterweise bietet der entsprechende Dialog hierzu nur drei der entsprechenden Volume-Typen an. Der Typ „Cold-HDD“ fehlt hier, was aber lediglich daran liegt, dass Dieser es nicht erlaubt, Betriebssysteme zu booten.

Der Dialog offenbart außerdem, aus welchem Snapshot das Boot-Volume stammt, denn bekanntlich provisioniert man in der Cloud im Allgemeinen und AWS im Besonderen virtuelle Maschinen niemals „from scratch“ sondern stets aus einer Vorlage, die hier Amazon Machine Image (AMI) heißt, d. h. im den betreffenden Snapshot/Volume sind das Gastsystem inklusive etwaiger Lizenz (MS Windows) bereits enthalten.

Verschlüsselung und Snapshots

Das zugehörige AMI enthält nicht nur die Snapshot-ID und die Start-Berechtigung für dieses AMI, sondern auch den zugehörigen Mountpunkt im Gastsystem. Erstellt man eine neue Instanz, wie wir in diesem Beispiel aus einen öffentlichen Basis-AMI von AWS, kann demzufolge das aus dem angegebenen Snapshot erstellte Boot-Volume auch nicht direkt verschlüsselt werden, was man in der letzten Spalte der Volume-Liste erkennt, sondern nur indirekt über den Workarounds eines eigenen privaten Images. Direkt an dieser Stelle (im EC2-Launch-Assistenten und nicht im „Volumes“-Menü) verschlüsseln lässt sich nämlich ein Volume nur dann, wenn es nicht aus einem Snapshot, bzw. einem verschlüsselten Snapshot erstellt wird, also nur für etwaige an dieser Stelle zusätzlich der Instanz hinzuzufügende „neue“ Nicht-Boot-Volumes handelt, im Gegensatz zum Anhängen vorhandener Volumes aus eine vorhanden, ggf. verschlüsselten Snapshot.

Hängen wir also unserer Beispiel-Instanz drei weitere Volumes mit sämtlichen oben genannten Volume-Typen an (um diese z. B. später exemplarisch auf einen performanteren Typ hochstufen oder on-the-fly vergrößern zu können), zeigt der zugehörige Dialog auch die übrigens Volume-Typen an. Hier taucht dann auch der bisher vermisste Typ Cold-HDD auf.

Hin und Her

Im nächsten Teil schauen wir uns an, wie einfach man in der Cloud z.B. HDD-Typen ändern, das Volume selbst vergrößern oder virtuelle Maschinen indirekt über ihre Volumes/Snapshots z. B. in anderen Availabilty Zones  umziehen oder gar individuelle AMIs in andere Regionen kopieren kann. Auf dieser Weise lässt sich z. B. auch eine regionsübergreifende HA-Architektur mit (virtuellen) Web-Servern mittels DNS-Failover realisieren; allesamt Szenarien und Workflows, die in der klassischen Server-Virtualisierung oder gar on premise gar nicht möglich wären. Dies demonstriert eindrucksvoll die Mächtigkeit von Cloud-VMs, auch wenn der wahre Benefit von Cloud Computing sich heute eher mit serverlosen Workloads und Managend Services erschließt.