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/

 

Achtung bei EBS-Snapshots vom Windows Root-Volume

Am vergangenen Freitag haben wir einen Disaster-Recovery-Test bei einem unserer Kunden durchgeführt und haben in diesem Zuge  einen schwerwiegenden Fehler im Zusammenhang mit EBS-Snapshots festgestellt.

Im Rahmen des Backup-Plans des Kunden werden nachts automatisiert EBS-Snapshots von allen EBS-Root-Volumes der Windows-Instanzen erstellt, die Instanzen sind währenddessen weiterhin im Betrieb.

Während des Recovery-Tests wollten wir nun mit Hilfe eines EBS-Snapshots das Windows Root-Volume wiederherstellen und mussten feststellen, dass dieser und alle anderen erstellten EBS-Snapshots inkonsistent und unbrauchbar waren.

Nachdem wir Kontakt mit dem AWS Support hatten und einige weitere Tests mit EBS-Snapshots und Windows-/Linux-Instanzen durchgeführt hatten konnten wir folgende Punkte festhalten:

  • Snapshots vom Root-Volume einer Windows-Instanz können aktuell nur im “stopped”-State erstellt werden.
  • Snapshots vom Root-Volume einer Windows-Instanz die im “running”-State erstellt werden, sind inkonsistent und unbrauchbar.
  • Snapshots von zusätzlichen Volumes einer Windows-Instanz sind von dem Problem generell nicht betroffen.
  • Snapshots vom Root-Volume und zusätzlichen Volumes einer Linux-Instanz sind generell auch nicht betroffen.

Eine Ursache für das Problem scheint laut AWS Support der Windows DMA IRQ Pool zu sein, in welchem das Root-Volume registriert und gelockt ist. Dieser Pool wird beim Herunterfahren der Instanz geleert.

Der AWS-Support bearbeitet dieses Problem momentan intern und informiert uns über Neuigkeiten zu diesem Thema.

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 … »

EBS-Volumes mit einem Windows-Script als Snapshot sichern

Um dieses Skript auszuführen, müssen die Bitnami Cloud Tools installiert sein. (siehe diesen Artikel). Anschließend erstellt man im Root Verzeichnis der Bitnami Cloud Tools eine AWS-Backup.bat Datei und fügt dort das folgende Skript ein:

@echo off

CALL "D:\AWS-BI~1\scripts\setenv.bat"
CALL "D:\AWS-BI~1\aws-setenv.bat"

:: Path for your AWS home directory
set AWS_HOME=D:\AWS-BI~1\
:: Hier wird der Endpunkt für die Region EU gesetzt.
set EC2_URL=https://ec2.eu-west-1.amazonaws.com:443

cd "D:\AWS-BitNami"

:: Set today's day of week parameter, German Date with . otherwise /
for /F "tokens=1 delims=. " %%a in ('DATE/T') do set dateDayOfMonth=%%a

:: Create a file with all attached volumes
ec2-describe-volumes|find /i "attached">%AWS_HOME%\Volumes.txt

:: Create a file with old scheduled snapshots using same day of week parameter
ec2-describe-snapshots|find /i "%dateDOW%: Daily Backup for">%AWS_HOME%\SnapshotsDOM.txt

:: Create a file of instances filtering on the instance tag Name
ec2-describe-instances|find /i "TAG"|find /i "Name">%AWS_HOME%\InstanceNames.txt

:: Create snapshots of all attached volumes
for /F "tokens=2,3" %%d IN (%AWS_HOME%\Volumes.txt) do for /F "tokens=3,5" %%a IN (%AWS_HOME%\InstanceNames.txt) do if %%a EQU %%e ec2-create-snapshot %%d -d "%dateDayOfMonth%: Daily Backup for %%b (VolID:%%d InstID:%%e)"

::Delete old Snapshots listet in SnapshotsDOM.txt
for /F "tokens=2" %%i in (%AWS_HOME%\SnapshotsDOM.txt) do ec2-delete-snapshot %%i

pause

Das ganze Skript basiert auf einer Vorlage von Mark Sehmer, ich habe nur ein paar Änderungen durchgeführt, damit es bei mir auch funktioniert.

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.