AWS-Blog.de

Infos rund um das Thema Amazon Web Services von den tecRacer Cloud Experten

ElasticBeanstalk IAM Rechte

Mai 22nd, 2013 Posted in Allgemein, ElasticBeanstalk

Leider scheint die Permission Policy ElasticBeansTalkFullAccess in IAM nicht da zu tun, was man erwartet …. offenbar hat AWS an IAM etwas geändert, was sie in ihre Standard-Routinen für Beanstalk nicht eingebaut haben, die letzten drei Rechte müssen manuell hinzugefügt werden, damit wirklich volle Rechte gegeben sind:

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

Achtung bei EBS-Snapshots vom Windows Root-Volume

Mai 21st, 2013 Posted in Backup, EBS, Windows

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

Mai 21st, 2013 Posted in CloudFront, Windows

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.

Amazon AWS Architektur Training 18.- 20. Juni

Mai 16th, 2013 Posted in Allgemein

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

Mai 16th, 2013 Posted in Allgemein

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

Mai 10th, 2013 Posted in S3

2 Kommentare »

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

April 25th, 2013 Posted in Allgemein

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!

Cloud Monitoring

April 12th, 2013 Posted in Allgemein

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

März 15th, 2013 Posted in Allgemein, EC2

http://whichinstance.com/

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

März 10th, 2013 Posted in EBS, EC2

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

März 8th, 2013 Posted in Allgemein, Route53

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.

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

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

März 8th, 2013 Posted in EC2

Immer wieder gut zum Überblick:

EC2-Intanztypen

Technik hinter Amazon Redshift

März 8th, 2013 Posted in Allgemein

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 …

März 8th, 2013 Posted in Allgemein

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

März 8th, 2013 Posted in Allgemein

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

Februar 21st, 2013 Posted in RDS

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

Februar 15th, 2013 Posted in Allgemein

Heute mal in eigener Sache:

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

Amazon AWS AZs (Availability Zones)

Februar 4th, 2013 Posted in Allgemein

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)

Januar 29th, 2013 Posted in Video-Streaming

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

Mehr Infos hier: http://aws.amazon.com/elastictranscoder/faqs/

CloudFront Caching

Januar 28th, 2013 Posted in CloudFront

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 …

© 2013 AWS-Blog.de

Wordpress Theme By Pro WP Themes