In unseren ersten 12 Monaten haben wir eine simple, aber effektive Infrastuktur für unsere Web-Services aufgebaut, um kompletten Ausfällen vorzubeugen. Das Resultat: 99.999% Uptime. Und so sieht das aus:
In meiner noch kurzen IT-Laufbahn habe ich eines gelernt: Ohne Stress schläft man besser. Als Betreiber von (Web-)Services pocht da aber immer die eine kleine Frage im Hinterkopf: Was wäre wenn? Es kann so viel passieren: Stromausfälle, DDoS-Attacken, ein kaputtes Filesystem oder eine oder mehrere Harddisks, die ausfallen. Nun, letzteres soll ja in der Cloud selten passieren. Meine Erfahrung: Das passiert in der Cloud noch viel öfter als einem lieb ist – so zumindest meine Erfahrung mit mehreren grossen Playern auf dem Markt. Deshalb ist eines unserer wichtigsten Ziele eine hohe Uptime.
In den ersten Monaten mussten wir einige kleine Rückschläge in Kauf nehmen. Wir konnten nicht jedes Szenario von Anfang an abdecken, und in einigen Fällen mussten wir erstmal «die schlechte Erfahrung» machen und daraus lernen. 2015 verzeichneten wir zwei Ausfälle von 15 und 10 Minuten. Anfangs dieses Jahres hatten wir einen Teilausfall, da wir uns zuerst für die Schweizer Infrastruktur für einen weniger zuverlässigen Hoster entschieden haben (gleichzeitig einer der teuersten – sei’s drum).
Simpel, aber effektiv
Nun, sind wir ein Betrieb mit zwei Festangestellten. Eine Infrastruktur-Lösung sollte also simpel sein, und trotzdem möglichst viele Exodus-Szenarien verkraften können. Mit dem Umzug in die Schweiz haben wir den nächsten wichtigen Schritt getan. Seit Februar 2016 läuft unsere Managed-Infrastruktur mit heute rund neunzig WordPress Installationen in zwei Rechenzentren. So bleiben die Websites unserer Kunden auch online, wenn eines der beiden Rechenzentren einen kompletten Strom- oder Netzwerk-Ausfall hat. Technisch sieht das so aus:
Unsere Server sind auf zwei Rechenzentren verteilt. Ein Teil ist in Genf, der Rest steht in Attinghausen. Moment mal? Ist das nicht irgend so ein Kaff? Richtig – doch in dem beschaulichen Dorf wurde ein ehemaliger Militärbunker zu einem Hochsicherheits-Rechenzentrum umgebaut.
Die Technik dahinter
Jetzt wird’s spannend – zumindest für technisch interessierte. Wie läuft so ein Request ab?
- Jemand ruft comotive.ch auf. Nun wird ein DNS-Failover-CNAME abgefragt, der jeder Person alle 60 Sekunden eine andere Loadbalancer IP liefert. Im normalen Tagesbetrieb laufen immer zwei Loadbalancer. Der DNS-Provider hat zwei Funktionen. Das Loadbalancing und den Failover. Letzteres wird erreicht, indem der DNS-Provider von bis zu zehn Check-Servern fast alle 2-3 Sekunden nachfragt: «Bist du noch online?». Die Loadbalancer sagen dann: «Ja», «Nein», oder gar nichts – was auch kein gutes Zeichen ist. Sobald gar nichts oder ein «Nein» kommt, wird die IP deaktiviert.
- Der Loadbalancer nimmt nun den Request in Empfang. Alle Assets (CSS, JS, Fonts, Bilder) werden direkt von den nginx-Servern mit PageSpeed Modul ausgeliefert. Lediglich PHP-Requests sind komplexer und werden an eine Webserver-Farm weitergegeben. Die Loadbalancer haben noch ein paar Jobs mehr, aber dazu müsste ich mal einen eigenen Blog-Post schreiben.
- Der Loadbalancer hat also ein Set von mindestens zwei Webserver, die PHP-Requests verarbeiten. Hier setzt ein weiterer Failover an. Gibt ein Webserver keine oder ein ungültige Antwort, wird sofort der nächste Server gefragt – ohne dass man erst eine Fehlermeldung sieht. Die Anfrage dauert einfach eine halbe Sekunde länger. Eine weisse Seite kommt nur, wenn kein Webserver mehr antworten kann. Durch Trennung der Rechenzentren und die Tatsache, dass jeder Webserver autonom Requests beantworten kann, dürfte dieser Fall nie (oder nur in schweren Notfällen) eintreten. Der Fall trat effektiv in den letzten 15 Monaten nur zwei mal ein.
- Die Webserver sind in ständiger Kommunikation, um Datenbank- und Cache-Services abzugleichen. Auch diese sind im Failover so konfiguriert, dass sie weiterlaufen, wenn ein Service (oder der ganze Server) den Geist aufgibt. Sobald ein Dienst wieder verfügbar ist, werden erst Daten abgeglichen, bevor der Webserver wieder in die Liste der aktiven Server aufgenommen wird.
«Kann ja jeder sagen, oder?»
Ich behaupte mal: Das kann nicht jeder sagen. Wie auch immer – was nützt das in der Theorie, wenn es in der Praxis nicht funktioniert? Keine Angst: Szenarien, die wir simulieren können, spielen wir regelmässig durch. Und zwar in der Nacht oder am frühen morgen, wenn unser Traffic am geringsten ist. Die meisten Massnahmen greifen ohne Ausfall – der DNS Failover braucht maximal eine Minute, bis der fehlerhafte Server keine Anfragen mehr bekommt. Ein Szenario konnten wir bisher noch nicht richtig testen – dazu weiter unten mehr.
«Macht ihr denn keine Wartungsarbeiten?»
Sicher, ungefähr einmal pro Monat, in dringenden Fällen sofort. Das merkt keiner, weil wir jeden Server einzeln ausser Betrieb nehmen. Seit Februar 2016 erfüllen wir Bundes- und Bankenstandards, einige von uns vorher entwickelte Installationen laufen noch bei anderen Schweizer Hostern. Zum Vergleich: Wir mieten auch (gezwungenermassen) teure Managed Server, die monatlich doppelt so viel kosten wie unsere gesamte Cloud-Infrastruktur. Selbst einfache Wartungsarbeiten, von denen man auf unserer Infrastruktur nichts merkt, werden dort oft tagsüber durchgeführt.Diese Wartungsarbeiten verursachten bei einem unserer Kunden 2015 mehr als zwanzig «geplante Ausfälle», die länger als 15 Minuten dauerten. Das wollen wir unseren Kunden, die teilweise geschäftskritische Websites und Online-Shops betreiben, nicht zumuten.
Doch was ist mit DDoS?
Aktuell eines der grössten Risiken sind DDoS-Attacken. Mehrere Server/Bots/Computer, die gleichzeitig so viele Anfragen an einen oder mehrere Server schicken, um sie hilflos zu überlasten. Dagegen haben wir für kleine und grössere Attacken mehrere Vorkehrungen getroffen. Ich glaube, jeder Hoster hat Angst vor dem Szenario – die folgenden Bullets enthalten daher bewusst nur «schwammige» Informationen.
- Kleine Attacken, die das RZ nicht abwehren kann/muss, werden mit einer Kombination aus automatischen IPTables und einer Memcached basierten Software-Firewall gefiltert.
- Der Betreiber unseres RZ kann mittlere bis grosse Attacken bereits abwehren, bevor sie unsere Server erreichen.
- Für grössere Attacken, die die Rechenzentren nur teilweise oder gar nicht abwehren können, sind wir ebenfalls (in der Theorie) vorbereitet. Hier können wir den Traffic der angegriffenen Webseite umleiten, was alle anderen Kunden schützt. Durch einen Geo-Filter ist es möglich, die angegriffene Seite z.B. nur noch für (alle oder bestimmte) Schweizer Netzwerke trotzdem zur Verfügung zu stellen.
Tja, und alle Massnahmen sollten innert einer bis fünf Minuten aktiv werden. Punkt 1 trifft täglich meist mehr als hundert mal ein und wirkt innert etwa fünf Sekunden. Während dieser fünf Sekunden macht sich keine Einschränkung in der Geschwindigkeit bemerkbar. Der Fall 2 ist auch schon eingetreten, dank schnellem Eingreifen unseres Cloud-Providers griffen die Massnahmen hier bisher immer in weniger als einer Minute.
Tja und Punkt 3 ist so eine Sache: Wir haben einen Plan, der in der Theorie und in Simulationen klappt – eine so grosse Attacke zu simulieren ist mit unseren Mitteln technisch nicht möglich und auch nicht legal. Zu hoffen bleibt, dass wir Stufe 3 nie erleben werden.