Backup von S3 Content

Wir haben zunehmend Applikationen, die ihre Assets direkt auf S3 speichern und nicht mehr auf irgendwelchen File-Shares.

Braucht man denn da nun noch ein Backup dieser Daten, denn S3 ist ja multi-redundant, d.h. ein physikalischer Datenverlust ist nahezu ausgeschlossen … ?

Ja, man braucht ein Backup, denn auch User löschen versehentlich Daten oder die Applikation könnte einen Bug haben und versehentlich Daten löschen oder überschreiben.

Da die Datenmengen unserer betreuten Applikationen auf S3 recht hoch sind, macht ein stündliches oder nächtliches Script, welches die Daten auf einen anderen S3 Bucket synchronisiert/kopiert, nicht wirklich viel Freude.

Aktuell fahren wir da folgende Ansätze für ein Backup-Konzept von S3-Daten:

Versionierung:

Auf dem entsprechendem S3 Bucket wird Versionierung aktiviert. Dadurch wird beim Überschreiben einer Datei automatisch die alte Version versioniert. Auch beim Löschen einer Datei wird die gelöschte Datei versioniert. Aus diesen versionierten Daten kann man dann jederzeit über entsprechendes Scripting einen gewünschten Status der S3 Daten wider herstellen.

Zusätzlich kann man dann eine entsprechende Lifecycle Rule auf dem S3 Bucket definieren, die älterne Versionen löscht, die älter sind als X Tage. Leider kann man hier nicht definieren, dass man einfach nur die letzen X Versionen haben möchte …

Cross-Region-Replication (existiert seit dem 25.3.2015):

Zusätzlich zu der breits dargestellten Versionierung kann man nun definieren, dass die Inhalte eines S3 Buckets in einen anderen Bucket in einer anderen Region repliziert werden sollen. Dann hat man zum einen noch eine stets aktuelle Sicherung seines Ist-Datenzustands in einer anderen AWS-Region (just in case of ..) und man muss sich bei einem Überschreiben oder versehentlichen Löschen der Daten nicht mit dem Thema Herstellen aus einer Versionierung beschäftigen …

 

AWS Cloudwatch Logs mit Windows-Instanzen

Ich hatte ja schon in diesem Artikel über den neuen AWS Service Cloudwatch Logs berichtet …

Neben den neuen Agenten für Cloudwatch Logs ist auch im AWS Standard Windows Service EC2Config das neue Cloudwatch Logs standardmässig integriert. Allerdings nur mit der neuesten Version 2.2.5, die man hier herunterladen kann um damit vorhandene Windows EC2-Instanzen upzudaten. Neue EC2-Windows Instanzen bekommen diese Version schon jetzt ausgerollt. (EC2Config-Service: http://aws.amazon.com/developertools/5562082477397515).

CloudwatchLogs-EC2-Config1

Amazon Windows EC2Config Service

(mehr …)

Neuer Service: AWS Cloudwatch Logs

Gestern wurden zahlreiche neue AWS Services zum Thema Mobile vorgestellt … aber irgendwie ist bisher der neue AWS Cloudwatch Log Service dabei ein wenig untergegangen …

AWS Cloudwatch ist bisher als Statistik-Dienst bekannt, der entsprechende Daten von fast allen AWS Ressourcen automatisch sammelt und für 14 Tage speichert und dafür ein Alerting-System als auch grafische Analysetools anbietet.

Cloudwatch Logs wurde gestern vorgestellt und ist bereits für die Virginia Region verfügbar. AWS bietet für Cloudwatch Logs Agenten (Windows, Ubuntu, Amazon Linux) an, die man innerhalb von z.B. EC2-Instanzen installiert. Diese Agenten schicken dann automatisiert definierte Log-Dateien (Apache Logs, etc.) nach AWS Cloudwatch Logs.

In Cloudwatch Logs können diese Log-Dateien nun unlimitiert lange gespeichert werden und es können Alarm-Trigger auf die Inhalte der Log-Dateien definiert werden, so dass man z.B. benachrichtigt wird, wenn in einer Log-Datei eine bestimmte Anzahl von Fehlern überschritten wird.

 

CloudWatch Management Console

Die Preisgestaltung ist wie bei AWS üblich wie immer günstig:

Amazon CloudWatch Logs (Virginia Region)

  • $0.50 per GB ingested
  • $0.03 per GB archived per month

 

Mit AWS Cloudwatch Logs macht nun AWS eigentlich Unternehmen wie Splunk, Loggly direkte Konkurrenz … und ich denke, das aktuelle Featureset von Cloudwatch Logs ist erst der Anfang …

Verschlüsselung von Daten auf AWS S3

Datenverschlüsselung auf AWS S3  symmkryptDas Thema Datensicherheit und damit auch Verschlüsselung ist bei unseren deutschen Amazon Web Services Kunden eigentlich ein Dauerthema. Amazon AWS trägt diesem Bedürfnis zunehmend mehr Rechnung und hat gerade gestern wieder eine entsprechende Erweiterung der S3 Dienste veröffentlicht.

Hier nun eine Übersicht, über die von Amazon Web Services angebotenen Verschlüsselungsoptionen für Ihre Daten auf S3:

(mehr …)

DragonDisk – S3 Manager mit CommandLine für Windows/Linux

Da wir im Rahmen unseres Amazon AWS Managed Hosting Services Kunden mit Windows und Linux Umgebungen betreuen, suchen wir stets nach Tools, die auf beiden Betriebssystem optimal laufen … Für den automatisierten Upload auf S3 hatten wir bisher unter Linux S3cmd und unter Windows S3Sync (http://sprightlysoft.com/S3Sync/) verwendet.

Wir haben uns nun DragonDisk näher angesehen und sind recht begeistert von diesem Tool. Es unterstützt viele Betriebssysteme und hat eine CommandLine (wichtig für den Batch-Betrieb über Scheduler) und über eine Sync-Funktionalität. DragonDisk ist kostenlos und ist OpenSource. http://www.dragondisk.com/

Prima ist auch, das DragonDisk von Haus aus eine clientseitige Verschlüsselung anbietet, damit ist man in heutigen Zeiten auch „NSA“-sicher.

 

 

 

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

 

 

Amazon AWS Storage Gateway ideal für Unternehmen mit VMWare ESXi

Das Amazon AWS Storage Gateway ist für Unternehmen gedacht, die bereits VMWare ESXi im Einsatz haben und Daten automatisiert in der Cloud sichern wollen oder Volumes direkt in die Cloud auslagen wollen.

Amazon AWS stellt ein VMWare Image bereit, dies benötigt weitere lokale Festplatten in der VM und stellt eine Verbindung zu Amazon AWS her.

Das Amazon AWS Storage Gateway bietet dann im Zusammenspiel mit der bereitgestellten VM zwei unterschiedlichen Anwendungs-Szenarien:

  • Gateway-Stored Volumes
  • Gateway-Cached Volumes

Szenario 1: Gateway-Stored Volumes:

  • Die lokale Datenspeicherung erfolgt in VMWare-Volumens, dazu kommt ein lokales Upload-Buffer VMWare-Volumens
  • Das Amazon AWS Storage Gateway sort dann für eine automatische Synchronisation der lokalen Volumes mit Amazon AWS und Speicherung unter S3 als EBS-Volume-Snapshot
  • Dadurch liegt stets ein komplettes Backup des lokalen VMWare Volumes auf Amazon AWS S3 vor

Szenario 2: Gateway-Cached Volumes:

  • Die Daten der lokalen VMWare Volumes werden stets direkt in Amazon AWS S3 gespeichert. Das Volume dort kann bis zu 32 TB gross sein.
  • Für den schnellen Zugriff werden ca. 20% des Datenvolumens lokal auf einem VMWare Volume gecached, dazu kommt ein Upload-Buffer VMWare-Volume.
  • Somit werden stets alle Daten auf S3 direkt gespeichert, für einen lokalen schnellen Zugriff sorgt das Cache-Volume.