EBS General Purpose vs. EBS Provisoned IOPS vs. EBS Magnetic

Seit Juni 2014 gibt die neuen EBS General Purpose Drives, die komplett SSD basiert sind. Hier kurz ein Vergleich über die unterschiedlichen EBS Drive Arten:

 

EBS General Purpose (SSD):

  • Preis: in EU: 0,11 USD pro GB / Monat
  • Performance: 3 IOPS pro GB, 30 Minuten Burst bis zu 3000 IOPS, wenn genügend Credits für vorher ungenutzte IOPS vorhanden sind

EBS Provisioned IOPS (SSD):

  • Preis in EU: 0,132 USD pro GB / Monat + 0,072 USD pro IOP pro Monat
  • Performance: exakt die provisionierten IOPS

EBS Magnetic (nur zum Kosten / Performance Vergleich hier aufgeführt)

  • Preis in EU: 0,055 USD pro GB / Monat + 0,055 USD pro 1 Million I/O Anforderungen
  • Performance: 100 IOPS plus kurzfristiger Burst

 

Wenn man nun den Einsatz von EBS Drives für ein Projekt kalkuliert, kann es zu folgender Situation kommen:

Man braucht ein EBS Drive mit 333 GB Grösse und 1000 IOPS … was tun?

Variante 1:

  • EBS Generell mit 333 GB = 3 IOPS pro GB x 333 GB = 999 IOPS mit Burst Möglichkeit für 30 min. auf 3000 IOPS kostet = 333 x 0,11 USD = 36,63 USD pro Monat

Variante 2:

  • EBS Prov IOPS auf 1.000 IOPS mit 333 GB = 1.000 IOPS x 0,072 USD + 333 x 0,138 USD = 117,954 USD pro Monat

 

Was spricht nun für Variante 1 oder Variante 2 ?

Für viele Anwendungsfälle ist “GP2″ (General Purpose SSD) die bessere und günstigere Wahl. Das Bursting ist nur kurzzeitig möglich, also ist Variante a) zwar schneller, aber eben nur vorübergehend; wenn der Workload dazu passt dann ist das auf alle Fälle die bessere Variante.

Warum möchte man manchmal trotzdem PIOPS einsetzen?

  • PIOPS (“io1″) ist so gebaut, dass die Volumes die angeforderte Performance in 99,9% der Zeit auch erreichen (” Provisioned IOPS (SSD) volumes can achieve single-digit millisecond latencies and are designed to deliver the provisioned performance 99.9% of the time”), während es bei GP2 keine solche Garantie gibt. Wenn es wirklich darauf ankommt, z.B. bei produktiven Datenbanken unter hoher Last, dann ist PIOPS (auch trotz höherer Kosten) die bessere Wahl.
  • PIOPS liefert mehr IOPS (4000 gegenüber 3000 max. bei gp2) und kann –da man 30 IOPS/GB anfordern kann– auch schnelle kleine Laufwerke liefern, während man bei gp2 hohe IOPS-Zahlen v.a. über die Größe erreicht (und ansonsten nur im Bursting)

Generell würde ich für den “Normalfall” immer auf gp2 setzen und bei Datenbank-Workloads oder vielen kleinen Files, wo es mir auf Konsistenz im IO ankommt, über io1 nachdenken.

Die “magnetic” Option wird in Zukunft vermutlich rein als Kostensparmaßnahme eingesetzt werden oder für ‘kalte’ Daten.

 

AWS EC2 Performance Probleme und deren Lösung

Datadog beschreibt die wichtigsten AWS EC2 Performance-ProblemeDie Firma Datadog hat ein White Paper zu den Top5-Performance-Problemen bei AWS EC2 veröffentlicht. Das 24-seitige PDF-Dokument erklärt anschaulich, wie man die wichtigsten Probleme erkennt, warum die Probleme auftreten und wie man sie beseitigt.

Das PDF von Datadog finden Sie hier: AWS EC2  Performance Probleme und deren Lösung.

Amazon AWS RDS Performance Test

Hiermal ein Link zu einem sehr guten und ausführlichen Amazon RDS Performance Test, insbesondere zu dem Unterschied zu provisionierten EBS Laufwerken vs normale EBS Laufwerke:

http://blog.celingest.com/en/2013/08/29/benchmarking-rds-provisioned-iops/

 

EC2 Netzwerkbandbreite erhöhen mit “EBS Optimized Instance” Option

Eine z.B. EC2 m1.large Instanz hat eine i/o Performance von “moderate”.  Genaue Aussagen, was das bedeutet, macht Amazon AWS nicht, das hier sollte aber ungefähr hinkommen:

  • High: Theoretical: 1Gbps = 125MB/s; Realistic (source): 750Mbps = 95MB/s
  • Moderate: Theoretical: 250Mbps; Realistic (source, p57): 80Mbps = 10MB/s
  • Low: Theoretical: 100Mbps; Realistic (from my own tests): 10-15Mbps = 1-2MB/s

Diese Bandbreite wird nun auch noch mit Zugriffen auf EBS-Volumes geteilt.

Heute habe ich gelernt, dass man für kleines Geld die Bandbreite erhöhen kann, in dem man z.B. die m1.large-Instanz auf EBS-Optimized umschaltet. Dies kostet bei der m1.large Instanz einen Aufpreis von $0.025 pro Stunden.

EBS-optimierte Instancen liefern einen dedizierten Durchsatz zwischen Amazon EC2 und Amazon EBS mit Optionen zwischen 500 MBit/s und 1000 MBit/s je nach verwendetem Instance-Typ.  Diese funktioniert auch mit Standard EBS-Volumes! Dadurch wird dann das normale “moderate” Interface entsprechend entlastet.

neue High-Speed Amazon AWS EBS Volumes

Amazon AWS EBS-Volumes sind seit Jahren die Grundlage für persistente Laufwerke bei EC2 Instanzen. Performance bei EBS-Volumes oder vergleichbaren Storage-Devices misst man in IOPS (Input/Output Operations Per Second).

Amazon EBS-Volumes schaffen im Durchschnitt ungefähr 100 IOPS. Normale PC Festplatten mit 7.200 RPM schaffen ungefähr 75 – 100 IOPS, PC Festplatten mit 15.000 RPM liegen ungefähr bei 175 bis 210 IOS. Somit sind EBS-Volumes gut geeignet für Boot-Volumes und Anwendungen mit einem moderaten I/O Bedarf. Die Performance von EBS-Volumes kann man durch Striping (RAID 0) erhöhen (so wird das übrigens unter der Haube bei Amazon RDS gemacht, den Amazon RDS sind im Prinzip gemanagte EC2 Instanzen mit einer SQL-Datenbank und Verwendung von gestripeten EBS-Volumes …)

Ab sofort stellt Amazon AWS zusätzlich “Provisioned IOPS for EBS Volumes” zur Verfügung. Dies sind spezielle EBS-Volumes, bei denen man die IOPS-Anzahl die man benötigt, entsprechend definiert. Im Augenblick werden bis zu 1.000 IOPS (für 16K Blöcke) angeboten. Wenn diese neuen EBS-Volumes dann noch zusätzlich mit RAID 0 gestriped werden, kann man mehrere tausend IOPS für ein logisches Laufwerk erzielen. Somit sind diese neuen High-Speed EBS-Volumes super geeignet für jegliche Form von Datenbanken … (die Frage, wann denn die Amazon RDS Instanzen selbst diese neuen High-Speed EBS-Volumes nutzen können bleibt noch offen … aber so wie ich inzwischen Amazon AWS kenne, wird das nicht mehr lange dauern …).

mehr … »

Grösse der Bootpartition einer EBS-basierten Windows EC2-Instanz ändern

Die verfügbaren EBS-basierten Windows AMIs haben alle i.d.R. nur eine 30 GB große Bootpartition. Auf dieser sind nur noch wenige GB frei. Hier ein kurzer Leitfaden, wie man die Bootpartition (Laufwerk C) einer EBS-basierten Windows EC2-Instanz vergößert (alle Tätigkeiten werden dabei in der AWS Management Console ausgeführt):

  1. Erstellen Sie eine neue Windows 2008 EC2 Instanz, diese wird eine 30 GB Bootpartition als Laufwerk C: haben.
  2. Nach dem diese Instanz von AWS entsprechend gestartet wurde und alle Status Checks durchgeführt wurden, stoppen Sie diese EC2-Instanz wieder.
  3. Wechseln Sie in den Bereich EBS Volumes, selektieren Sie das entsprechende EBS-Volume und deattachen Sie das Volume von der dazugehörigen EC2-Instanz und warten Sie, bitte der State =”available” ist”.
  4. Selektieren die das entsprechende EBS-Volume und erstellen Sie darauf einen SnapShot. Schauen Sie unter EBS / Snapshots bis dieses fertig ist (Status = completed).
  5. Erstellen Sie im Bereich EBS / Volumes (create Volume) ein neues 50 GB Volume basieren auf dem erstellten Snapshot. (Wichtig ist dabei, das das alte und das neue EBS Volume in der gleichen Availability Zone ist!). Warten Sie bis die Status checks durchgelaufen sind.
  6. Attachen Sie nun das neue EBS-Volume mit 50 GB an die existierende EC2 Instanz. Wichtig ist dabei, dass Sie unter Device /dev/sda1 angeben!
  7. Starten Sie Ihre EC2-Instanz und melden Sie sich als Windows-Administrator über RDP an.
  8. Gehen Sie dann in Windows Server-Manager auf Disk-Management. Die zusätzlichen 30 GB werden Ihnen dort bereits angezeigt, jetzt müssen Sie nur noch die bestehende C: Partition entsprechend erweitern.