{
  "Statement": [
   {
     "Effect": "Allow",
     "Action": [
       "elasticbeanstalk:*",
       "ec2:*",
       "elasticloadbalancing:*",
       "autoscaling:*",
       "cloudwatch:*",
       "s3:*",
       "sns:*",
       "cloudformation:*",
       "rds:*",
       "iam:ListInstanceProfiles",
       "iam:AddRoleToInstanceProfile",
       "iam:PassRole"
     ],
     "Resource": "*"
   }
  ]
}

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.

Da CloudFront aber aktuell nur gzip-Kompression über HTTP1.0 unterstützt und der IIS7.5 standardmäßig nur über HTTP1.1 gzip-komprimierten Content verteilt, muss eine kleine Anpassung am IIS vorgenommen werden.

Die Änderung muss in der folgenden Datei vorgenommen werden:

C:\Windows\System32\inetsrv\Config\applicationHost.conf

Die Parameter

noCompressionForHttp10="false" noCompressionForProxies="false"

müssen in folgendem Abschnitt ergänzt werden (ca. Zeile 268):

Nach der Änderung:

Anschließend muss der IIS neugestartet werden mit iisreset :

Der IIS7.5 liefert nun die Daten gzip-komprimiert über HTTP1.0 und HTTP1.1 aus, so das CloudFront die komprimierten Daten weiter verteilen kann.

Das Training entspricht diesen Inhalten und Spezifikationen http://aws.amazon.com/de/training/architect/ und bereitet auf die neue Amazon AWS Zertifizierungsprüfung vor http://aws.amazon.com/de/certification/.

Eine Online-Anmeldung finden Sie hier http://www.eventbrite.de/event/6689712109/es2/?rank=1

oder klassisch über Fax mit diesem PDF: Amazon AWS -Architecture-Training-Anmeldung

Da viele Web-Anwendungen noch rein Dateisystem-basiert arbeiten (z.B. Adobe Media Server) ist man versucht, das Problem der Anbindung von S3 an eine EC2-Instanz einfach über einen S3 Laufwerks-Mapper zu lösen. Insbesondere im Linux Umfeld gibt es da seit Jahren das Tool S3FS ( https://code.google.com/p/s3fs/wiki/FuseOverAmazon) was aber folgende Probleme hat:

• es ist erstes bei einem Einsatz mit vielen kleinen Dateien nicht wirklich stabil
• es hat keine Cluster-Unterstützung
• die Order-Adressierung im S3 Bucket ist nicht mehr kompatibel zu Amazon S3 in der AWS Console und anderen Tools wie CloudBerry … mit der Folger das solche Ordner als 0 Bytes Dateien dargestellt werden. (das scheint jetzt wohl aber gerade mit der Version 1.68 behoben zu sein …)

Aus diesem Grunde haben wir bereits vor längerer Zeit entschieden S3FS nicht einzusetzen und eigentlich generell auf S3-Laufwerks-Mapper zu verzichten.

Im Rahmen eines größeren Consulting Projektes für die Berliner Philharmoniker haben wir uns doch noch mal intensiv mit Thema S3 Laufwerks-Mapping beschäftigt, da mit YAS3FS (Yet Another S3-backed File System) eine Alternative zu S3FS existiert. Wir sind gerade dabei YAS3F zu testen und konnten auch bereits einen fiesen Fehler unter hoher Last entdecken, der dann vom Programmierer Danilo Poccia extrem schnell behoben wurde, wow!

YAS3F ist bermerkenswert weil:

• For maximum speed all data read from S3 is cached locally on the node, in memory or on disk, depending of the file size.
• Clusterfähigkeit: SNS notifications are used to update other nodes in the cluster that something has changed on S3 and they need to invalidate their cache
• Unterstützung von IAM Roles
• und viele andere tolle Sachen: https://github.com/danilop/yas3fs

Es gibt zahlreiche Anbieter für Monitoring-Tools als SaaS (Software-as-a-Service). Wir haben uns da zahlreiche angeschaut. Unsere Wahl fiel letztendlich auf Monitis (Tochterunternehmen von GFI), CopperEgg war auch in der engeren Wahl.

Die Gründe für den Einsatz von Monitis waren:

• angemessenes Preismodell (nicht wie bei anderen 10 US$ pro Cloud-Server!)
• Monitoring Ressourcen können individuell zusammengebucht werden
• Übersichtliche Dashboards auf HTML5 Basis
• Benachrichtigung (auch in Deutschland) über SMS und VoiceCalls.

Mehr Infos zu Monitis finden Sie hier: www.monitis.com

• 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.