Webserver (R)evolution mit AWS

Einleitung

Ich betreue nebenher einige Webpräsenzen und überlege mir ständig, wie ich diese, mit möglichst wenig Aufwand und mit möglichst noch weniger Betreuung und Arbeit bei Problemen vernünftig hosten kann. Meinen Weg vom RootServer zu den AWS möchte ich hier mal skizzieren.

Ich denke, das sind auch die grundsätzlichen Anforderungen der meisten Verantwortlichen in diesem Bereich: Rockstable Umgebung, 100% uptime, möglichst kein Stress mit der Umgebung- und das ganze noch neben geringen Kosten. Vorweg: es gibt wohl Dutzende an Varianten, eine Webseite zu hosten, und ich habe hier sicherlich nicht alle aufgezählt. Gerne können Sie mir einen Kommentar schreiben, dann kann ich das gerne updaten.

Variante 1 RootServer

Meine erste Variante war ein recht simpler RootServer eines großen Deutschen Hosters. RootServer sind quasi dedizierte Server, die einem selbst exklusiv zur Verfügung stehen. Das hört sich erstmal super an. Ganz klare positive Seite war die massive Performance, die ich dabei hatte. Es tummelt sich niemand anderes auf der Hardware herum, d. h. ich kann das komplett für mich verwenden. Die Konfiguration (Linux) gestattete sich recht einfach, die entsprechenden Kenntnisse vorausgesetzt (was immer so ist). Auffällig war: die Last der Maschine war verschwindend (man könnte auch sagen verschwenderisch) gering: 98% idle war sicherlich der Normalfall. Und dafür fallen doch recht hohe Kosten an. Das war aber primär ein Luxusproblem bzw. auch noch verschmerzbar, was die Kosten angeht.

Ausschlaggebender Punkt für einen Wechsel weg vom RootServer war der Tag, an dem EINE disk des RAID1 ausgefallen ist. Durch die Redundanz lief alles ohne Probleme weiter, trotzdem musste das gelöst werden. Der Provider hat das dann auch gelöst: aber es wurde nicht einfach die eine defekte Disk getauscht, sondern der komplette Server (die Hardware). Offenbar ist das für den Provider wohl billiger oder Fehlerunanfälliger. Für mich bedeutete das, dass ich von X Webseiten auf einem neuen Server ein Full-Restore einspielen musste. Und dazu hatte ich nicht nochmal Lust. Ich habe mich nach entsprechenden Alternativen umgesehen und bin dann bei VServer gelandet.

Variante 2 VServer

Ein VServer ist ein virtualisierter Teil eines Hardware-Servers, ähnlich VMware. Primär wird hier Virtuozzo und ähnliches eingesetzt. Großer Vorteil hierbei: Die Kosten sind wesentlich geringer und die Optionen bei einem Hardware-Defekt sind wesentlich besser: Der Hoster verschiebt einfach die virtuellen Maschinen auf eine andere Hardware. Dieses Konstrukt lief recht gut. Allerdings hatte ich mit der Zeit immer öfters das Problem, dass die Maschine kurzzeitig ausgelastet war, ohne dass auf meiner virtuellen Maschine etwas passierte. Das äußerte sich darin, dass die Load (“uptime”) in astronomische Höhen stieg (eine Load von 30 oder mehr war immer mal wieder der Fall), ohne dass die CPU irgendwas zu tun hatte (Idle von 99%). Entweder hatte der Provider die Hardware einfach zu stark überprovisioniert oder aber irgendein Skript eines anderen Kunden lief Amok und hat von der Hardware die Leistung gefressen.

Was auch immer der Auslöser war, das Ergebnis waren immer mal wieder Abbrüche auf die Webseite, weil der Apache einfach nicht schnell genug liefern konnte. Das ist natürlich langfristig keine Basis, auf die man (speziell auch schnell wachsende) Webseiten hosten möchte.

Variante 3 AWS Basic

Also nächster Schritt: Ich wollte sowieso mehr mit der AWS von Amazon machen, also ab in die Cloud. Ohne groß Whitepaper zu lesen ist der einfachste Schritt: Eine EC2-Instanz erstellen, Linux booten und DB und WP installieren, als wäre es ein “üblicher” VServer. Das funktioniert natürlich und die Webseite ist schnell up´n running. Aber das ganze Konstrukt hat viele Einschränkungen: EC2-Intanzen können recht “flüchtig” sein, d.h. mal durchbooten oder auch mal weg sein. Außerdem habe ich so keine automatische Skalierung nach oben und auch keine Redundanz.

Also nächster Schritt: Einfach mehrere EC2-Instanzen hochfahren und per Loadbalancer verteilen? Bringt nicht wirklich was, da WordPress ja Daten im Webroot speichert und das damit nicht synchron auf allen Servern verfügbar ist. Für die Datenbank gilt natürlich das selbe. Für einige dieser Einschränkungen bietet die AWS eine Lösung: Amazon Elastic Beanstalk. Das ist ein Framework, dass es ermöglicht, eine Webapplikation, z. B. aus S3, zu deployen. Und das ganze dann auch skalierbar auf mehrere virtuelle Server. Ich finde den EBS eine super Lösung, sehr einfach und trotzdem massiv skalierbar. In diesem Zug muss man allerdings quasi zwingend weg von lokaler SQL-DB und hin zum SQL-Service der AWS. Dieser ist in sich Redundant ausgelegt und man hat ein Service weniger, um den man sich kümmern muss.

Trotzdem hat das ganze einen Haken: Zum Deployment einer Webseite mit “Stand X” ist das eine geniale Geschichte: Zentrale, hochredundante DB, Automatische Sicherung der Webdaten in der hochredundanten S3 und eben per Regeln automatisch-skalierbare und redundante Server. Wirklich gut und macht richtig Spaß. Das eine Problem besteht immer noch: Die Speicherung von Änderungen, z. B. uploads in WordPress, ist so nicht persistent und für alle virtuellen Server erreichbar zu machen. Dazu mehr in Teil 2, dann kommen dann auch einige links zu Whitepaper und Architekturguides.

Im nächsten Artikel:

  • Elastic Beanstalk mit zentraler DB und EFS
  • OpsWorks
  • Container / Docker
  • Docker-Swarm

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

* Die Checkbox für die Zustimmung zur Speicherung ist nach DSGVO zwingend.

Ich akzeptiere