To the clouds and back…
… oder wie Cloud-Computing kleinen Webseiten über Lastspitzen hilft.
Gestern hat Ehrensenf unser Webprojekt RapidLetter vorgestellt. Wortopia wurde dort auch schon einmal vorgestellt – mit dem Ergebnis dass der Server im Nu nicht mehr ansprechbar war. Sowas ist nicht nur nervig, sondern deprimiert potenzielle Besuchern, die wahrscheinlich nie wieder vorbeikommen werden.
Es wäre also schön, wenn man bei Bedarf einfach von seinem kleinen VServer zu einem dicken Vielkerner mit ausreichend RAM wechseln könnte. Daher habe ich schon vor einiger Zeit ein Ubuntu AMIs (ein Image) für Amazon EC2 vorbereitet, welches hauptsächlich aus einem Apache und ein paar Extensions besteht. Dieser Aufbau hat sich jetzt bewert: Jeder der knapp 600 konnte ohne Probleme eigen Briefe generieren. Keine Downtime, keine langsamen Seiten, kein 500-er Fehler.
Die Idee dahinter ist, dass die Datenbank ruhig weiter auf dem ursprünglichen Server liegen bleiben kann, solange die Cloud-Instanz von extern auf sie zugreifen kann. Da die meiste Arbeit bei durchschnittlichen Webseiten hauptsächlich beim HTTP-Server liegt, lässt auf diese Weise in begrenzten Maßen schnell und günstig skalieren.
Wer sich auch auf den nächsten Peak einrichten will, hier eine grobe Anleitung:
Vorbereitung:
- Einen AWS-Account anlegen. Dafür brauchst du eine gültige Kreditkarte.
- Ein einfaches Image eines beliebigen Linux-Betriebssystems bei Amazon starten (Ich bevorzuge Ubuntu oder Debian). Wichtig: Zone “Europe” auswählen – AMIs lassen sich nicht zwischen verschiedenen Zonen verschieben.
- Apache und PHP (und evtl. Extensions) installieren.
- Die Configs möglichst so einrichten, wie sie auch auf dem “normalen” Server eingestellt sind.
- Wenn du keine Lust auf dauerndes Public-Key-Mitrumschleppen hat (nämlich genau der fehlt immer wenn es kritisch wird), kannst du mit passwd ein Rootpasswort festlegen. Das ist zwar nicht ganz soooo sicher, aber bei ausreichender Passwortstärke durchaus akzeptabel.
- Jetzt wird es kompliziert: das Image muss gebundled werden, das heißt es wird ein Image der Instanz erzeugt und auf Amazon S3 gepseichert. Das ist ein wenig frickelig, aber mit der richtigen Anleitung durchaus machbar.
- Die Instanz noch nicht herunterfahren! Erst sollte das neue Image getestet werden – es wäre nicht das erste mal, das es beim Bundlen Probleme gibt.
- Jetzt die Instanz herunterfahren und auf die paar Cent bei der nächsten Kreditkartenabrechnung warten.
- Richte deinen normalen Datenbank-Server so ein, dass er Zugriffe von externen Hosts zulässt. Achte auf ein sichers Passwort und gewähre nur einem eingeschränkten Datenbankbenutzer dieses Recht.
- Öffne den passenden Port in den IPTables. Du kannst dann die Datenbank mit einer GUI wie HeidiSQL testen.
Am Tag X stellst du nun fest, das xyz auf deine Seite linkt und die Zugriffe nach oben schnellen. Nun heißt es schnell sein:
- Das AMI mit einer möglichst großen Instanz starten.
- Kopiere alle Dateien deiner Webseite. Passe die Einstellungen der Datenbank auf die Adresse der Datenbank (die ja immer noch auf deinem normalen Server liegt) an. Setze sie passenden Dateiberechtigungen und teste Alles einmal kurz durch.
- Ermittle aus der externe Adresse der Instanz die IP und trage sie bei deinem Domain-Hoster anstelle deines normalen A-Records ein.
- Freue dich, dass du auf einmal ein vielfaches deiner normalen Besucher hast.