single.php
< Beitrag von Daniel Meinhold

Cloud-Infrastrukturen mit Amazon Web Services II: virtuelle Server (EC2)

In Teil 1 dieser Blog-Serie haben wir uns dem Thema „virtuelle Netzinfrastruktur“ bei Amazon Web Services gewidmet. Dies ist die Grundlage für das Bereitstellen virtueller, x86-basierter Server bei AWS. Der zugehörige Dienst nennt sich bei Amazon Elastic Compute Cloud (Amazon EC2). AWS EC2 ist damit ein Kerndienst aus dem Bereich Infrastructure as a Service.

Auswahl: Betriebssystem und Ressourcen

Virtuelle Server auf Basis einer x86-Plattform werden bei AWS als Instanzen bezeichnet; vergleichbar mit virtuellen Maschinen bei Produkten zur Server-Virtualisierung wie VMware vSphere oder Microsoft Hyper-V. Dabei sind im Wesentlichen nur 2 Aspekte interessant: Betriebssystem und Ressourcen (CPU, RAM, HD etc.).

Für den ersten Aspekt wählt man bei AWS anhand von Vorlagen – im AWS Jargon als Amazon Machine Image (AMI) bezeichnet – das benötigte Betriebssystem aus. Aktuell (19.12.2016) werden die folgenden Betriebssysteme unterstützt:

  • Amazon Linux
  • Ubuntu
  • Windows Server
  • Red Hat Enterprise Linux
  • SUSE Linux Enterprise Server
  • Fedora
  • Debian
  • CentOS
  • Gentoo Linux
  • Oracle Linux
  • FreeBSD

Neben den geläufigeren Betriebssystemen findet man hier auch Amazon Linux, das hauseigene Linux-Derivat für EC2. Das Bereitstellen eigener Vorlagen, sofern kein bestehendes AMI als Vorlage dient, ist ebenfalls möglich. Dabei ist der Prozess weniger komfortabel als beispielsweise bei VMware vSphere (u. a. kein virtuelles KVM).

CPU, RAM, I/O oder Hardware-Beschleunigung

Für die Wahl der Ressourcen hat man bei AWS eine große Auswahl anhand des vorgesehenen Einsatzgebiets: CPU-, RAM- oder I/O-lastig oder spezielle Performance-Anforderungen. Dazu passend gibt es bei AWS derzeit folgende Auswahl von sogenannten Instanz-Typen:

 Instanz-Typ Anwendungsbereiche Abkürzung
 Allgemeine Zwecke (General Purpose)  u. a. Test, Entwicklung, Web Server, Applikationsserver, kleine und mittelgroße Datenbanken, SAP Back-End, MS SharePoint  T2, M3, M4
 Compute-optimiert (CPU)  u. a. Batch-Verarbeitung, Transcoding, Simulationen, Analysen, High Performance Computing  C4, C3
 Memory-optimiert (RAM)  In-Memory-Datenbanken, große Datenbanken, Data Mining, Big Data, SAP BW, SAP S/4HANA  X1, R4, R3
 Storage-optimiert (I/O, Density)  NoSQL-Datenbanken, Data Warehousing, Hadoop  I2, D2
Hardware-beschleunigt (GPU, FPGAs) GPU-Datenverarbeitung, Machine Learning, Rendering, Analysen, Videocodierung und Echtzeitverarbeitung, Big-Data-Suche, Genomforschung P2, G2, F1

Innerhalb des Instanz-Typs kann man die passende virtuelle Hardware-Ausstattung auswählen, die sich per T-Shirt-Sizing zwischen nano und mehrfach XL bewegt. Bei den Compute- und Memory-optimierten Instanz-Typen hat man beispielsweise die Wahl zwischen 2 und 128 vCPUs und 3,75 bis 1952 GB RAM. Eine dynamische Anpassung der Ressourcen zur Laufzeit (ohne Downtime) ist hingegen nicht möglich.

Zusammengefasst ist somit jede Instanz über folgendes Kürzel identifizierbar: <Instanz-Typ><Generation>.<Größe>

Beispiel: t2.medium für eine Instanz mit 2 vCPUs und 4 GB RAM

Virtueller blockbasierter Speicher

Neben CPU, RAM und verschiedenen Optionen der Hardware-Beschleunigung hat man die Wahl des passenden blockbasierten Speichers. Bei AWS nennt sich dieser Speicher Elastic Block Storage (EBS). Zur Auswahl steht SSD- oder HDD-basierter Speicher in verschiedenen Kapazitäts- und Performance-Klassen. U. a. aktuell je Volume bis 20.000 IOPS, 16 TB und 500 MB/s Durchsatz. Jede blockbasierte „Cloud-Festplatte“ kann klassisch per RAID je nach Anforderungen an Performance und Verfügbarkeit auf Betriebssystemebene angepasst werden. Zusätzlich können die Volumes je nach Instanz-Typ verschlüsselt erstellt werden.

Für EBS können zudem Point-In-Time (PIT) Snapshots erstellt werden. Da diese jedoch nur crash-konsistent und nicht applikationskonsistent sind, werden je nach Anwendungsfall applikationsspezifische Werkzeuge oder eine anders gestaltete Backup-Architektur benötigt.

Neben dem blockbasierten Speicher hat man weitere Optionen für die Speicherung der Daten: objektbasiert (z. B. Dokumente, Fotos) in Form des AWS Simple Storage Service (S3) oder dateibasiert in Form eines NFS Shares mittels AWS Elastic File System (EFS). Diese werden im nächsten Blog-Artikel erörtert.

Hat man die eigene virtuelle Maschine bzw. Instanz den Anforderungen entsprechend konfiguriert, kann man dieses AMI abspeichern und für zukünftige Systeme nutzen. Auch eine Weitergabe bzw. Freigabe ist möglich. So stehen je nach Region über 20.000 vorkonfigurierte Systeme zur Wahl. Wie in jedem Marketplace sollte auch hier der Herausgeber geprüft werden. Sofern man AMIs teilen möchte, sollte man unbedingt die zugehörigen Richtlinien (Public AMI Publishing: Hardening and Clean Up) beachten.

Netzwerkintegration

Die Instanz selber wird dann in der Regel im zuvor selbst definierten Netzbereich (Virtual Private Cloud, VPC) innerhalb eines Subnetzes bereitgestellt.

Zu beachten: 1 Subnetz entspricht einem Rechenzentrum bzw. einer Availability Zone (AZ). Werden höhere Anforderungen an die Verfügbarkeit gefordert, müssen diese anderweitig umgesetzt werden. Weitere Details zur virtuellen Netzinfrastruktur finden sich im vorherigen Blog-Artikel.

Für spezielle Anwendungsfälle, wie z. B. NoSQL Cluster, kann zudem die Gruppierung von Instanzen über sogenannte Placement Groups sinnvoll sein, um eine möglichst geringe Verzögerung und maximale Bandbreite zu erzielen.

Statische und dynamische Paketfilter

Im Rahmen eines Defense-in-depth-Ansatzes empfiehlt sich neben dem Einsatz von Amazons Network ACLs, also einem simplen statischen Paketfilter, die Konfiguration von sogenannten Security Groups. Hierbei handelt es sich um dynamische Paketfilter (inkl. stateful inspection), welche auch den Zustand der Verbindung berücksichtigen. Dieser muss für jede Instanz bei der Bereitstellung ausgewählt werden. Per Default ist hierbei eingehender Traffic verboten und ausgehender Traffic erlaubt. Das Regelwerk sollte entsprechend des Sicherheitskonzepts angepasst werden. Zudem können verschiedene Instanzen auch eine gemeinsame Security Group verwenden. Siehe auch nachfolgende Abbildung:

 

EC2 - AWS-Netzdiagramm inkl. Nutzung von statischen und dynamischen Paketfiltern

AWS Network ACLs und Security Groups

Abschließend können je nach Szenario noch Performance Monitoring mittels Amazon CloudWatch als auch Auditing via Amazon CloudTrail hinzugefügt werden. Der Umfang der Überwachung bestimmt hierbei dann den entsprechenden Mehrpreis.

Preismodelle: On-Demand, Reserved und Spot Instances

EC2-Instanzen können anhand folgender Preismodelle gebucht werden:

  • On-Demand
  • Reserved Instances (RI)
  • Spot-Instances

Bei On-Demand erfolgt die Abrechnung ohne Vorabkosten oder Verpflichtungen je angefangene Stunde. Dies ist die schnellste und teuerste Variante. Geeignet u. a. für Tests, Proof of Concepts oder andere kurzfristige Einsätze.

Im Unterschied dazu erfolgt bei Reserved Instances eine Verpflichtung z. B. für 1 oder 3 Jahre und ggfs. der Festlegung bestimmter Parameter (Instanz-Typen, Anzahl, Availability Zone etc.). Dafür wird man mit einem Rabatt von bis zu 75 % im Vergleich zu On-Demand-Instanzen belohnt. Geeignet für vorhersagbare Grundkapazitäten bzw. planbare Reserven bei niedrigsten Kosten.

Für spezielle Einsatzwecke gibt es noch Spot-Instanzen. Hierbei kann auf  EC2-Kapazitäten (u. a. Instanz-Typ, Anzahl) geboten werden. Stehen Ressourcen zum max. gebotenen Preis zur Verfügung, werden diese gestartet; bei Überschreiten des gebotenen Preises jedoch ebenso ohne Ankündigung gestoppt. Verfügt man über den passenden Anwendungsfall, z. B. aus den Bereichen Big Data & Analyse oder Simulationen, ist dies die günstigste Art an EC2-Rechenkapazität zu gelangen. Davon ausgenommen sind u. a. die obligatorischen Kosten für Traffic und Datenspeicher.

EC2 - Tabelle mit Kostenverlauf bei AWS Spot-Instanzen

Beispiel: Kostenverlauf bei AWS Spot-Instanzen

Verfügbarkeiten beachten: SLA für EC2 und EBS

Sofern man erhöhte Verfügbarkeitsanforderungen hat, sollte man auch den zu EC2 und EBS zugehörigen SLA berücksichtigen: https://aws.amazon.com/de/ec2/sla/. Es wird eine monatliche Verfügbarkeit von 99,95 % der EC2- und EBS-Dienste innerhalb einer Region angestrebt (~ 22 Minuten Ausfallzeit je Monat). Im Umkehrschluss bedeutet dies auch, dass ein RZ bzw. eine Availability Zone jederzeit ausfallen kann, ohne dass der SLA dies abdeckt. Die Architektur der Anwendung bzw. der Umgebung sollte entsprechend fehlertolerant geplant und umgesetzt werden.

Zusammenfassung und Ausblick

Amazon Elastic Compute Cloud (EC2) ermöglicht das schnelle Bereitstellen von virtuellen x86-Systemen für alle gängigen Betriebssysteme. Die Auswahl der virtuellen Hardware-Ausstattung ist dabei durchaus vorzeigbar: bis zu 128 vCPUs und fast 2 TB RAM, 16 TB Speicher/Volume und Hardware-Beschleunigung in Form von GPUs oder FPGAs. Server-Vorlagen (AMIs), Snapshots und einfach hinzufügendes Performance Monitoring und Auditing vervollständigen das Angebot.

Bei der technischen Planung ist insbesondere das Thema Verfügbarkeit ein Wesentliches, da hier bestehende On-Premises-Architekturen nicht 1:1 umzusetzen sind (z. B. Stretched Cluster mit L2 Mobility).

Die Abrechnung kann anhand von 3 verschiedenen Preismodellen den Anforderungen entsprechend gewählt werden. Inwiefern es bei einer stundengenauen Abrechnung bleibt, wird der Markt entscheiden.

Mit Serverless Computing in Form von AWS Lambda steht zudem eine weitere interessante Option zur Verfügung, wobei nur noch die Ausführungszeit und der verbrauchte Arbeitsspeicher der durchgeführten Funktion (z. B. E-Mail versenden bei Änderung eines Tabelleninhalts) von Interesse sind.

Der nächste Blog-Beitrag wird sich mit dem Thema Storage (u. a. S3 und Glacier) befassen.

Folgen
X

Folgen

E-mail : *
Kategorie: Cloud | Schlagwörter: , | Kommentare: 0

Beitrag kommentieren

CAPTCHA * Time limit is exhausted. Please reload CAPTCHA.