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.

IIS7.5 – gzip-Kompression für CloudFront aktivieren

Amazons CloudFront ist ein guter Service um beispielsweise die Ladezeiten seiner Internetpräsenz weltweit zu verbessern. Um die Ladezeiten weiter zu optimieren lohnt es sich auch über CloudFront die IIS-seitige gzip-Kompression zu nutzen.

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.

mehr … »

Amazon AWS Architektur Training 18.- 20. Juni

Vom 18. bis 20. Juni bieten wir ein 3 tägiges Amazon AWS Architektur Training an.

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

AWS Accounts Limits erhöhen

Amazon AWS hat per default einige Account Limits eingebaut, die man aber auf Anfrage erhöhen kann. Hier eine aktueller Überblick über die Limits mit einem Link zu einem entsprechenden Antrag. (Quelle: http://www.bashton.com/blog/2012/aws-limits/)

Description Default Limit Increase request form
EC2 Instances 20 per region Request form
Elastic IPs (Classic) 5 region Request form
Elastic IPs (VPC) 5 per region Request form
EBS Volumes (standard) 5000 volumes or 20TiB in aggregate Request form
EBS Volumes (provisioned IOPS) 10000 provisioned IOPS or 20TiB in aggregate Request form
ELB SSL certificates 10 Request form
VPCs 5 per region Request form
Subnets 20 per VPC Request form
VPN Gateways 5 per region Request form
Customer Gateways 50 per region Request form
Route tables per VPC 10 Request form
Network ACLS per VPC 10 Request form
Network per ACL 20 Request form
VPC Security Groups 50 Request form
Rules per VPC Security Group 50 Request form
Route 53 Zones (Domains) 100 Request form
Route 53 Record Sets 10000 per zone Request form
RDS Instances 20, 10 for MSSQL/Oracle Request form
CloudFront Bandwidth 1Gbps per edge node Request form
CloudFront Requests 1000 per second per edge node Request form
CloudFront Object Size 20GB Fixed
CloudFront CNAME aliases 10 per distribution Request form
IAM Users 5000 Request form
IAM Groups 100 Request form
IAM Groups per User 10 Request form
SimpleDB Domains 250 Request form
CloudFormation Stacks per region 20 Request form

S3-Laufwerksmapping unter Linux mit YAS3F

Amazon S3 hat ein reines HTTP basiertes API. Somit braucht man in der Regel entsprechende Tools oder eine eigene API-Programmierung, um S3 an seine Webapplikation anzubinden.

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

 

 

AWS Summit Berlin am 2. Mai 2013

tecRacer ist offizieller Sponsor auf dem AWS Summit 2013 in Berlin und ist mit einem eigenen Stand vertreten. Sie finden uns im 2. Obergeschoss. Wir freuen uns auf Ihren Besuch!

AWSSummit

Cloud Monitoring

Als Amazon AWS Managed Service Provider monitoren wir natürlich die entsprechen AWS Ressourcen unserer Kunden hinsichtlich Verfügbarkeit und Auslastung. Zunächst haben wir mit OnPremise Tools wie Paessler PRTG bzw. Zabbix gearbeitet. Diese Tools haben uns aber hinsichtlich Dashboard-Übersichtlichkeit bzw. Agentenfunktionalität nicht auf Dauer überzeugt.

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

 

Gelungene Visualisierung der Kostenvorteile von Reserved Instances

http://whichinstance.com/

Amazon EC2 Instance Types Cost Grapher - Google Chrome_2013-03-15_21-25-08

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.

Amazon AWS Route53 mit Latency based Routing und DNS Failover

Für einen Kunden haben wir weltweit verteilte Content-Video Server aufgesetzt. Dabei sollen dessen User den Content aus der nächstgelegenen AWS Region bekommen. Dies kann man super mit Route53 und Latency based Routing umsetzen. Dabei ist der Root-Content-Server in der EU-Region (irland.*.com) beheimatet und ist redundant ausgelegt (ELB mit 2 EC2-Instanzen in unterschiedlichen Availability-Zonen). Die Server in Tokyo und Virginia sind nicht redundant ausgelegt, allerdings nutzen wir hier das neue DNS-Failover System von Route53. Wenn der Healtcheck (alle 60 Sekunden) fehlschlägt, so werden Tokyo bzw. Virginia nach Irland auf DNS Ebene umgelenkt.

Über content.*.com wird dann einheitlich der Content abgerufen und ihm Rahmen von Latency based Routing automatisch die nächste AWS Region dem Enduser zugeordnet.

Route53-1

Healthcheck für die AWS Regionen mit Single-Servern:

Route53-2

Und warum nutzen wir nicht CloudFront … den ContentDelivery Service von Amazon AWS, um den Content in den Regionen über Edges lokal zur Verfügung zu stellen? Haben wir bereits ausprobiert und gemacht. Das Problem ist, das die Enduser wahllos auf den 2,4 TB Video Content zugreifen und somit das Caching nicht immer greift, was sich in sehr hohen Cache Misses niederschlägt. Und dann müssen die Enduser warten, bis der Content erst wieder aus der EU nach z.B. Tokyo geliefert wird (hohe Latenzzeiten)… aus diesem Grunde haben wir entschieden, den kompletten Content direkt in die Region der Enduser zu bringen.

Aktualisiertes EC2 Instanztypen Chart

Immer wieder gut zum Überblick:

EC2-Instanztypen

EC2-Intanztypen

Technik hinter Amazon Redshift

Amazon Redshift ist ja der neue Datawarehouse on Demand Service von Amazon AWS. Scheinbar basiert dieser Service auf der Technik von Paraccel, an der Amazon auch eine Beteiligung hält.

http://www.crn.com/news/cloud/231001166/amazon-gives-big-data-big-boost-with-paraccel-investment.htm

http://www.paraccel.com/technology/paraccel-analytic-platform.php

http://www.zdnet.com/amazon-redshift-paraccel-in-costly-appliances-out-7000008111/

Schnell ist niemals schnell genug …

Im Rahmen eines Kundenprojektes haben wir 9 EBS-Snapshots mit zusammen 2,4 TB an Daten von der Region EU nach Virginia und nach Tokyo kopiert. Dies geht ja über die neue Funktion Copy-Snapshot. Leider kann man aktuell immer noch 5 auf einmal kopieren …

Der Kopierjob nach Virginia war nach ca. 10 Stunden fertig, der Kopierjob nach Tokyo nach ca. 20 bis 25 Stunden. Eigentlich für die Summe an Daten nicht schlecht, aber auch 10 h können lang sein … ;-) Amazon AWS hat übrigens letztens gerade erste die Preise für Datentransfer innerhalb von AWS Regionen auf 0,02 US$ pro GB gesenkt, somit kostet der Transfer von 2,4 TB ca. 48 US$.

Vorhin habe ich dann die Kopierjobs von Virginia nach Oregon und Sao Paulo angestossen … mal schauen wie lange das dauert.

CW-Interview mit Amazon AWS Chief Information Security Officer (CISO) Stephen Schmidt

Sehr gutes Interview in der Computerwoche mit dem Amazon AWS Chief Information Security Officer (CISO) Stephen Schmidt.

http://www.computerwoche.de/a/wir-setzen-keine-slas-auf-die-nur-gut-aussehen,2531542

Amazon AWS RDS und MySQL mit MyISAM Tabellen

Amazon RDS für MySQL läuft gut und performant. Allerdings gibt es hier und da noch Anwendungen (z.B. xtCommerce), die ausschließlich MyISAM Tabellen und nicht InnoDB Tabellen nutzen.

Leider sind die Default Einstellungen von Amazon RDS für MySQL überhaupt nicht für MyISAM optimiert, mit der Folge, dass die Performance der Datenbank schlecht ist. Wenn man dieses Problem erkannt hat, lässt sich sehr schnell Abhilfe schaffen:

Default-DB-Parameter in der entsprechenden DB-ParameterGroup wie folgt ändern:

  • query_cache_size to 167772160 (163 MB)
  • myisam_sort_buffer_size to 167772160 (163 MB)
  • key_buffer_size to 1077721600 ( 1 GB)

tecRacer ist nun Amazon AWS Advanced Consulting Partner

Heute mal in eigener Sache:

Seit gestern ist tecRacer von Amazon Web Services zum Advanced Consulting Partner ernannt wurden.

AWS_Logo_Advanced_Consulting_Partner

 

Amazon AWS AZs (Availability Zones)

Availability Zones sind eigene Amazon AWS Data Center in einer Region, die von einander unabhängig sind (eigener Strom, eigenes Internet und ca. 10 km von einander entfernt).

In der EU Region gibt es AZ 1a, 1b und 1c.

Oft kommt von den Kunden die Frage, welches AZ man nehmen soll … AZ 1a ist doch bestimmt am stärksten ausgelastet, da ja die meisten einfach 1a nehmen würden …?

Hier die überraschende aber logische Antwort: 1A kann für jeden AWS Account in Wirklichkeit ein anderes AZ sein. Amazon AWS wollte nämlich genau das verhindern, dass alle dann in 1a landen … deswegen hat jeder AWS Account sein eigenes Mapping, d.h. was bei AWS Account Nr. 1 AZ 1a ist, ist vielleicht bei AWS Account Nr. 2 AZ 1b.

 

Neuer AWS-Service: Amazon Elastic Transcoder (Video-Konvertierung)

Seit heute gibt es (für mich völlig überraschend) einen brandneuen Video-Konvertierungs-Service in der Amazon Cloud.

Dieser Service kann Videos von einem S3-Bucket automatisiert von vielen Eingangsformaten (flv,3gp, mp4, etc.) nach MP4 basierend auf unterschiedlichsten Profiles konvertieren und dabei auch ein Thumbnail erzeugen. Der Preis wird pro Video-Minute berechnet:

  • Standard Definition – SD (Resolution of less than 720p) $0.017 per minute in EU Region
  • High Definition – HD (Resolution of 720p or above) $0.034 per minute in EU Region

CloudFront Caching

CloudFront ermöglichkeit das weltweite verteilte lokale Caching, damit auf Daten in S3-Buckets oder von Custom HTTP Origins (externe URLs soder Elastic Load Balancer) schneller zugegriffen werden kann.

CloudFront Daten werden standardmäßig 24h in den lokalen Edges gecached. Übersteuern kann man diese, wenn man entsprechende HTTP-Header setzt.

Gerade bei S3-Daten ist wichtig, das jede S3-Datei den HTTP-Header “Cache-Control” = “max-age=Wert in Sekunden” bekommt. Besonders gemein ist, dass man bei den Behaviors der Cloudfron-Distribution

beim Object Caching “customize” einstellen kann und man dann eine Minimum TTL definieren kann. Man schliesst dann folgerichtig (auch beim Lesen der ?-Hilfe), das damit ein fehlender Cache-Control Header bei S3-Dateien gesetzt wird. Nein, es wird nur ein vorhandener überschrieben … also immer auf “use Origin Cache Headers” lassen und dann bei den S3-Dateien die Cache-Header richtig setzten. Kann man mit Tools wie Cloudberry auch einfach für ganz viele Dateien machen …

 

IAM User Rechte einschränken

In vielen Unternehmen müssen Mitarbeiter selbst bei geringsten Beschaffungen sich eine Unterschrift von ihrem Chef holen … in der Amazon Cloud hingegen kann ein Mitarbeiter oft viele tausend Euro auf Knopfdruck ausgeben … sofern man dieses nicht explizit über Rechte in IAM unterbindet.

Viele Unternehmen definieren für Ihre Admins eine IAM-Gruppe “Operators”, die dann mit Rechten aus dem Policy Template “Power User Access” versehen wird. Dadurch haben Mitglieder dieser Gruppe dann Rechte auf alle Module aber nicht auf IAM.

Wenn diese Operators aber in EC2 z.B. keine Reserved Instances kaufen dürfen, dann muss dieses noch durch weitere Policies unterbunden werden. Hier ein Beispiel, wie man den Kauf von EC2 Reserved Instances unterbindet:

1. Für die Gruppe Operators eine weitere Policy hinzufügen:

mehr … »