Um die Möglichkeiten der Cloud voll ausschöpfen zu können, sollte auf einen Server (z.B. EC2 Instanz) kein Zustand gespeichert werden. Verlagert man den Zustand vom Server in Speichersysteme wie zum Beispiel S3, DynamoDB, RDS oder ElastiCache kann man von automatischer Skalierung bei Last oder von erhöhter Ausfallsicherheit in der Cloud profitieren.
Aber was tun, wenn die Blog- oder eCommerce-Software die Grafik- und Video-Dateien direkt auf der Festplatte des Servers speichert und eine Anpassung an der Software zeitaufwändig und unrentabel ist? Mit einem verteilten Speichersystem wie GlusterFS lässt sich dieses Problem umgehen. Das verteilte Speichersytem sorgt dafür, dass Daten zuverlässig auf alle Server verteilt werden.
GlusterFS kann immer dann verwendet werden, wenn Schreibzugriffe auf verschiedene Ordner und Dateien verteilt stattfinden. Im oben genannten Szenario mit einer Blog- oder eCommerce-Software, die Media-Dateien abspeichert kann GlusterFS problemlos verwendet werden. Problematisch wird es allerdings, wenn zum Beispiel die Logdateien verteilt werden sollen. Wenn mehrere Server auf die gleiche Datei in einem GlusterFS-Laufwerk schreiben kommt es zu Problemen mit der Performance. Die technische Dokumentation enthält Details zu Performance und Architektur.
Für ein Testsetup auf Basis von AWS stelle ich gerne mein CloudFormation-Template als Hello World-Beispiel bereit: bitbucket.org/widdix/de.widdix.lab.glusterfs. Das CloudFormation-Template startet zwei EC2-Instanzen in einem eigenen VPC. Änderungen im Ordner /mnt/labvolume werden automatisch zwischen den beiden Servern verteilt. Viel Spaß beim Ausprobieren!
