Herzlich willkommen zur Hochverfügbarkeit in der Public Cloud. Bevor wir mit dem Thema starten, ganz kurz ein paar Worte zu mir, aber nicht allzu viel Dauerwerbung. Ich bin Marc Achsnich, Head of Cloud der synaigy, Teil der Strategieberatung der TIMETOACT GROUP. Uns gibt es seit 14 Jahren. Wir sind mit dem Schwerpunkt E-Commerce und Cloud unterwegs und versuchen dort, ganzheitliche Lösungen aufzubauen, einfach eine gemeinsame Vision zu ermöglichen. Die synaigy ist Teil einer Gruppengesellschaft. Das heißt, wir sind in Summe 1400 Mann, 500 dauert vielleicht noch einen Monat oder so. Und letztendlich mit 22 Standorten in der Dachregion vertreten und zählen zu den führenden IT-Dienstleistern. Aber worum geht es heute? Und zwar generell die Hochverfügbarkeit. Diese wird innerhalb der letzten Zeit immer wichtiger oder immer mehr ein größerer Faktor. Und die Hochverfügbarkeit an sich beschreibt einfach nur in erster Linie die Möglichkeit, dass einzelne Teilkomponenten einer Anwendung ausfallen können, ohne dass es eine wirkliche Auswirkung auf deine Anwendung an sich haben wird. Die Frage ist: Wer braucht diesen Spaß? Und da gibt es generell zwei Themen. Der eine Part ist, dass du einfach ein Business hast, das zu jeder Zeit seine die Infrastruktur bedeutet. Das heißt, egal zu welcher Zeit irgendeine Auswahl passiert, es hat einen direkten Einfluss auf deine Infrastruktur. 

Dies bedeutet im übertragenen Sinn, ist das ein Bereich, wo wir von E-Commerce beispielsweise sprechen, die einfach 24/7 verkaufen müssen und da zählt einfach jede Minute, ist einfach ein Umsatz, der entgeht. Der zweite Bereich, und das ist einer, der jetzt auch immer spannender wird, ist einfach der, wo jemand dir vorschreibt, dass das sein muss. Da gibt es die gesetzlichen Vorgaben, da gibt es vertragliche Vorgaben und wir sind da sehr häufig dann im Bereich von Bankenwesen, von Versicherungen oder generell Kritisanwendungen. Innerhalb der Public Cloud gibt es einen relativ dankbaren Weg, das zu erreichen und das ist Kubernetes. Ich kenne jetzt nicht euren technischen Background, von daher ein paar ganz kleine Basic Facts dazu. Es gibt drei Features, die einfach für die Hochverfügbarkeit sehr, sehr gut und effizient sind. Der erste Part ist die horizontale Skalierung. Das bedeutet im übertragenen Sinn, dass es möglich ist, dass deine Teilkomponente von deiner Anwendung nicht einmal existiert, sondern zwei, drei, vier, fünf mal. Und wenn dann zwei Komponenten davon kaputt sind, existieren halt noch weitere, sodass dann deine Anwendung in diesem Bereich weiter seine Antworten geben kann. Ergänzend dazu gibt es die Lastverteilung. Das bedeutet, dass diese fünf Anwendungen einfach einfach zu gleichem Maßen einfach nur mit Anfragen bedient werden. 

In Konsequenz davon heißt es dann auch, dass jede einzelne Komponente weniger Auslastung hat und ein ruhigeres Leben hat. Abschließend kann Kubernetes gewissermaßen Selbstheilung durchführen. Am Ende so gut, wie man es ihm beibringt. Das heißt, man kann am Ende ein Skript schreiben, man kann definieren, was muss benötigt sein, damit diese Teilkomponente in ein gesunder Zustand ist oder als Defekt zählt. Und für den Fall, dass das Kubernetes erkennt, dass einfach eine Komponente instabil wird, wird es eigenmächtig eine neue Teilkomponente erzeugen und dafür sorgen, dass sie ohne Last in dem Sinne hochfahren kann, Cash-Warming durchführt und erst dann, wenn es feststellt, dass diese Komponente ansprechbar ist, die Defekte austauschen und so dann mehr oder weniger einen leichten Selbstheilungsprozess anleiten. Innerhalb von der OVH ist das relativ einfach möglich. Es gibt den OVH-Manager, da kann man sich das innerhalb von wenigen Minuten zusammenklicken und das ist besonders schön daran, weil auf dieser Basis ist dann letztendlich das Fachwissen, was man dafür braucht, nicht besonders tief und es steht in mehreren Regionen verfügbar. Ergänzend dazu gibt es neben den Standardplanen bald – ich weiß nicht, ob es gerade schon announced wurde – auf jeden Fall gibt es bald einen Premiumplan, der dann einfach noch mehr Resilienz fördert. 

Das heißt, es ist einfach möglich, dass dann durch das Wechseln auf den Premiumplan die Verfügbarkeit von 99. 5 auf 99. 8 oder welcher Bereich das auch wird. Der ist mir zumindest noch nicht bekannt, aber dadurch kann man einfach durch das Wechsel der Komponente, gibt es dann beispielsweise in der Control Plane irgendwelche Redundanzen noch, die dazu geschaffen werden, dass dann einfach dieser Betrieb stabiler wird. Das Kubernetes kann sehr flexibel gestaltet werden. Man kann es auswählen im Bereich von Hochverfügbarkeit. Das heißt, es entscheidet selber, wann … Jetzt darf es nicht brennen und ihr dürft nicht mehr raus. Auf jeden Fall im Bereich der flexiblen Sicherheit ist es so, dass man einfach definieren kann: Möchte ich immer dann, wenn ein Sicherheitspatch kommt, dafür sorgen, dass er ASAP eingespielt wird? Möchte ich meine Wartungsfenster selber definieren? In dem Bereich besteht die Möglichkeit, sich flexibel zu gestalten. Das Cluster kann in einem privaten Netz angelegt werden oder es kann komplett öffentlich sein. Das heißt, abhängig davon, welche Einstellung man auswählt, wird dann automatisch ein Gateway angelegt, ein öffentliches Internet Interface mit anzulegen. Und man hat, glaube ich, fast alle Instanzen der OVH haben Zugriff. Das heißt, es ist möglich, GPU-Instanzen auszuwählen, falls man eine AI-lastige Infrastruktur haben möchte. 

Man kann Testumgebungen aufbauen, wo dann einfach günstige D-oder C-Instanzen, also kleine CPU-lastige, ausgewählt wird. Und da gibt es einen großen Blumenstrauß, den man auswählen kann und das ist skalierbar bis zu 100 Nodes. Und im Bereich der Hochverfügbarkeit finde ich besonders charmant, dass es ein Feature gibt, das nennt sich Anti-Node Affinity. Hier kann man per, mehr oder weniger, Anhaken definieren, dass die Nodes auf mehrere OVH-physischen Servern verteilt werden. Das heißt, im Fall eines Ausfalls seitens OVH ist es am Ende nicht euer Problem, weil ihr eure Infrastruktur über mehrere physische Server der OVH verteilt habt. Und es ist nicht so, dass ein Server ausfällt, aber da habt ihr alle eure Aktien drauf gesetzt und dann funktioniert die Skalierung auch nicht mehr. Und das letzte schöne Feature ist, dass alles das, was man über die UI macht, kann man auch einfach in Terraform-Skripten. Das heißt, die Fehlertoleranz kann sinken, die Reproduktion kann steigen und das, was man im einen Standort macht, kann man dann per Skript einfach woanders noch mal machen. Und ich habe hierfür auch schon zu lange erzählt, weil in der Zeit ist das Cluster schon initialisiert worden. Ich habe auf der rechten Seite versucht, mich daran zu halten, aber das Abschließen der Tür hat mich, glaube ich, aus der Fassung gebracht. 

Ja, also S3 gibt es auch ganz normal bei der OVH. Tatsächlich, muss ich sagen, hatten wir noch nie einen wirklichen Speicherleak jetzt in den Jahren. Wir sind seit vier oder fünf Jahren da und Speicher war bei uns nie ein Problem. Generell lässt sich, glaube ich, sagen, dass man nicht auf den lokalen VM-Storage setzen soll. Das ist einfach ein kostenloses Gimmick, dass man irgendwo hinlegt, sondern dass man einfach auf den Block-Storage setzt. Und da hatten wir tatsächlich noch nie irgendwelche Probleme und sorgen halt eher dafür, dass wir den Storage an sich einfach regelmäßig backuppen und sichern. Eine Möglichkeit, die bestehen würde, wäre, dass da, also ganz am Ende in dem Spoilern gibt es dann irgendwann ein 3AZ, wo dann einfach auch der Speicher in dem Sinne über drei verteilt wird. Das wäre ein Fall, wo man einfach mehr Resilienz schaffen kann. Oder es gibt so Möglichkeiten, aber da kommt man dann in einen Bereich, wo man aus der gemanagten OVH-Umgebung rausgehen muss, also aus dem gemanagten Kubernetes-OVH rausgehen muss. Es gibt ja auch so eine Art Enterprise-Storage von der OVH. Das ist dann der NetApp beispielsweise oder DHAnas. Über den Bereich kriegt man dann einfach auch noch wirklich resilienten Bereich, aber bleibt unterm Strich. Wir hatten letztendlich nie, ich kenne tatsächlich auch noch nicht mal die Verfügbarkeitszone von dem Logs-Storage, aber wir hatten noch nie dort irgendeinen Leak gehabt. 

Ja, Wir haben jetzt halt mit so einem hochverfügbarkeitssystem, mit allem der Storage-Arten, denke ich, wie steht denn das mit Synchronisation zwischen den Verfügbarkeitszonen? Ist das quasi in Echtzeit oder? 

Es kommt drauf an. Also das 3AZ, das lebt halt in seiner eigenen Magie. Das heißt, da muss man sich diesen ganzen Spaß nicht kümmern. Wenn man hochverfügbarkeit über mehrere Standorte verteilen möchte, dann kommt das einfach stark auf die Latenz drauf an. Das heißt, je nachdem, welche Rechenzentren man da auswählt, ist es durchaus möglich zu sagen, man setzt auf komplette Aktiv-Aktiv-Synchronisierung und baut sich dann beispielsweise ein eigenes MySQL-Cluster auf, der jetzt dann beispielsweise als Berkona-oder Galera-Cluster existiert, dann einfach zwei physische Knoten aufzubauen. Dafür brauchst du aber auch die richtigen Standorte dafür. Das heißt, was kannst du irgendwie bis vier Millisekunden oder so durchaus hinbekommen. Da drüber sollte man eher Richtung Aktiv-Passiv-Szenario nachdenken und sagen, es gibt einfach deinen physischen Hauptknoten, der repliziert sich mit einem zweiten Server und dieser sorgt dafür, dass eigentlich der Hauptstandort die ganze Zeit die Antworten gibt und nur dann, wenn alles brennt, dann habe ich den Stand von vor zwei Millisekunden und kann dann darauf schwenken. 

Du hattest vorhin gesagt, dass es in mehreren Regionen verfügbar ist, das Managed Kubernetes. Kann man denn auch sozusagen einen Kovernetis-Cluster über mehrere Regionen, der in zwei Regionen läuft? Also kommt man ein bisschen auf den Banking und Payment und da spricht man ja immer sozusagen von der Geowinundanz, die mittlerweile eben die ein paar hundert Kilometer sein muss eigentlich, ist das auch schon möglich? 

Es kommt drauf an. Vielleicht beantwortet sich die Frage so in drei Slides. Vielleicht. Genau, ich mache mal weiter. Also generell ganz kurz die Basis von Kubernetes ist: Es gibt ein … Also alles startet bei OVH mit dem V-Rack. Das ist so einer dieser USPs davon. Das heißt, du hast einfach ein komplett virtuelles Netzwerk, welches du über all die Universen von der OVH kannst. Das heißt, du kannst Services aus der Public Cloud nehmen, Services aus der Private Cloud, Services aus der bare-Metal-Welt und die sind alle in dem gleichen virtuellen Netzwerk. Deswegen ist es dann beispielsweise auch durchaus möglich zu sagen, ich kombiniere meinen Kubernetes dann doch mit dem HANAS oder so, weil die am Ende alle in der gleichen Welt miteinander spielen können. Darauf aufgesetzt würde dann die Kubernetes-Schicht beginnen, die dann eine Control Plane hat und eine Data Plane, in dem man dann seine Notes konfigurieren kann. Die Control Plane ist etwas, auf das man einfach keinen Zugriff hat. Die ist im Bereich der OVH. Die sorgen dafür, dass sie verfügbar ist und man hat nur einen Zugriff auf die Node Pools, die man konfiguriert. Was gleichermaßen das Stretchen über Clustern erschwierigen wird. Aber dazu nachher. Diese Cluster kann man innerhalb von einem Projekt auch mehrmals replizieren. 

Das heißt, in diesem Fall könnte man beispielsweise davon ausgehen, dass es einfach ein Produktions-Kovernetis gibt, ein Testkouvernetis, ein Abnahme-Kovernetis et cetera, alle mit unterschiedlichen Node Pools, sodass man dann Größenordnung, sodass man einfach jetzt nicht zu viel Kosten raus schmeißen muss. Und da drüber gibt es die OVH-Load Balancer, die dann einfach für den Zugriff von außen in die Kubernetes-Feld sorgen und die Skalierung oder die Lastverteilung dann auf die einzelnen die Computerinstanzen steuern. Über das DNS wird dann am Ende die Welt nach außen über der Domain erreichbar. Die Frage ist, und das hatten wir gerade schon ein bisschen gespoilert, damit kriegt man 99,5% hin. Das mag in vielen Cases okay sein, manchmal reicht es aber einfach nicht, mit den ersten Zeitpunkten, die wir genannt hatten. Wobei auch zu sagen ist, ich dachte, wir haben jetzt das Managed-Kubernetes auch in der 99,5-Variante seit gut fünf Jahren in Einsatz und nicht einmal, sondern bestimmt zehnmal oder so. Und wir hatten in den Jahren einen Ausfall, aber das lag halt nicht an Kubernetes. Da war irgendwas in der Netzwerksteuerung komplett kaputt, aber ansonsten läuft das einfach vor sich hin. Also da habe ich durchaus ein Vertrauen drin. Haben wir uns dann noch ein paar Alternativen dazu überlegt. 

Das heißt, es gibt Möglichkeiten, wie man von 99,5 auf 99,8,99, muss man sicher dann selber rechnen oder konfigurieren, hochgehen kann und da gibt es drei Möglichkeiten. Die eine ist Multi-Reason-Setup. Das ist das, was du gerade angesprochen hast. Das bedeutet, man hat eine Control Plane, die einfach in mehreren Regionen verfügbar ist und dadrunter Node Pools, die dann entweder in dem einen AZ sind, in einem zweiten AZ und man kann dann auf dieser Basis seine Infrastruktur so gestalten, dass die nicht nur sich auf einen Standort konzentrieren, sondern komplett gleich verteilt oder wie man es halt konfiguriert, innerhalb von dieser übergreifenden Kubernetes-Welt hausiert. So was gibt es auch bei der OVH. Die zweite Variante ist die Active-Active-Cluster. Das heißt, man sucht sich einfach zwei Standorte aus, deployed da seine Anwendung hin und lässt einen Load Balancer auf die beiden Welten zu und lässt sie einfach gleich verteilen. Das heißt, die Anfrage kommt an und entweder geht er beispielsweise nach Straßburg oder nach Limburg und je nachdem, welche gerade weniger Auslastung hat, kriegt die Anfrage. In diesem Fall muss man einfach stark darauf achten, dass man einfach kein Problem mit Synchronisierung hat, weil letztendlich beide Standorte einfach schreiben können. 

Je nachdem, wie man jetzt seine Anwendung gestaltet hat, ist es halt manchmal einfacher, manchmal schwieriger, gerade dann, wenn einfach auch innerhalb von Kubernetes Änderungen persistiert werden sollen oder dort auch, wie so eine Redis liegen soll, die dann auf einmal nicht nur ein Cache ist, sondern auch ein Persistence Cache, weil da Nummernkreise drin generiert werden und dann auf einmal das angeschlossene ERP auf einmal sagt: Diese Nummer kenne ich schon, aber dabei hat das andere Rechenzentrum gerade erstellt. Das sind dann Gedanken über die man sich halt kümmern muss. Das heißt, da ist es einfach ratsam, solche Sachen aus dem Co-Dentis rauszuziehen, beispielsweise in so einem Galera Cluster reinzusetzen, dort die Persistierung reinzupacken, die dann einfach dafür schnell genug sind, dann bei zwei, drei, vier Millisekunden dann ihr Datenbestand synchron zu halten. Da drüber wird es wirklich schwierig. Der dritte Anwendungsfall ist ein Active-Passive-Cluster. Das heißt, man versucht sich, die Vorteile von zwei Clusterseiten zu Nutze zu machen, aber eigentlich konzentriert man sich so lange auf einen Standort, bis dieser einfach nicht mehr vorhanden ist und nur in dem Fall wechselt man auf den zweiten. Hat in dem Sinn den Vorteil, weil man sich einfach viele Latenzen einsparen kann, weil man einfach immer nur beispielsweise hier in Linnburg ist, aber im Fall der Fälle ist man halt in ein paar Millisekunden dann doch wieder am Leben, weil der zweite Standort dann am Ende sich schnell genug wieder hochskaliert und betriebsfähig machen kann. 

Ja? 

Dazu eine Nachfrage: Das Sie sind bei Active Passive? Das wäre an sich mit einem kompletten Hot-Stand-Buy? 

Das ist ein Hot-Stand-Buy. Genau. Heißt, hier ist es grafisch dargestellt. Jetzt ist es auf der anderen Seite. 

Hat man da gute Reaktionszeiten, die wir stellen? Geht es dann über DNS Dass er dann feststellt, automatisch den Error macht. 

Das schauen wir uns gleich an. Also ich hatte kurzfristig Sorge, dass ich innerhalb von 15 Minuten mit diesem Slot durch bin, aber mittlerweile nicht mehr. Genau, also bei diesem Active-Passive-Part ist es einfach wichtig, dass man weiß, welche Standorte man hat und wie die kombinierbar sind. Wir haben jetzt bei der synaigy irgendwann angefangen vor langer, langer Zeit, dass man überlegt, uns erreicht hat: Wie kann das jetzt einfach sein? Welche Standorte kann man kombinieren? Und dann kamen wir auf den Gedanken: Lass uns doch einfach ausprobieren. Und dann haben wir angefangen, jeden Standort mit jedem Standort zu messen und dabei ist diese wunderschöne Matrix entstanden, die man nicht so richtig lesen kann. Aber man sieht, Richtung Mitte sind die schnell, Richtung Außen sind sie langsam. Und auf der Basis kann man überlegen: Wo soll mein Primärstandort sein und was ist dann ein guter Sekundärstandort? Weil ich schon dachte, dass man das nicht lesen kann, habe ich ein paar rausgesucht. Und genau, letztendlich die einfachste Entscheidung, wenn man in Frankfurt ist, sollte man nach Straßburg gehen, weil man da in der Regel bei vier Millisekunden oder drunter unterwegs sein kann. Wenn man sein Hauptbusiness beispielsweise eher in Paris hat, oder in Frankreich, dann gibt es halt entweder das 3AZ in Paris oder dann spielt man halt in der Regel mit Grave Line oder Robé, weil man dann von zwei Millisekunden spricht und das ist am Ende schon sehr schnell, wenn man davon ausgeht, dass innerhalb eines Rechenzentrums ist man im Bereich von einem Millisekunde oder so etwas da drunter. 

Und für unsere Kollegen aus der UK würde dann London mit Grave Line auch sehr gut harmonieren. Diese Tabelle hier ist auch kein Geheimnis für mich. Das heißt, wenn ihr sie haben wollt, könnt ihr euer Handy rauszocken und da ein Foto von machen oder mich nachher drauf ansprechen, dann könnt ihr sie auch haben. Ich sehe schon, ich warte. Doch. 

Ja, Ansonsten kannst du auch hier hinkommen, wenn du das von da fotografieren willst. Vielen Dank. Ihr landet da auf der Landing Page, könnt da irgendwelche Daten eintragen oder die richtigen, auf jeden Fall direkt danach gibt es dann in der PDF wo genau dieses Bild, in Hochauflösung da ist. Genau, auf jeden Fall die Frage ist, wenn man das jetzt haben möchte, wie sieht das dann in Summe aus? 

Das hier ist jetzt die Darstellung von dem Cluster, was ich gerade gezeigt habe. 

Das müsste jetzt ganz leicht an manipuliert werden. Das heißt, wir haben aktuell V-Rack, das Manage Kubernetes, einen Load Balancer und einen DNS. Und in dem Fall von uns würde ich vor dem Load Balancer noch einen Load Balancer setzen. Und zwar aus dem Grund, weil der Public Load Balancer ist einfach ein Part, der sich einfach nur sein eigenes Kubernetes Cluster kümmern möchte. Und in der Variante, die ich skizzieren möchte, haben wir davor einen, der dann in dem Szenario gleich beispielsweise in Grave Lines liegt, weil dort auch noch eine sehr hohe Verfügbarkeit garantiert wird und dann einfach unabhängig ist. Und der wird dann angesprochen, das sehen wir jetzt, der hat dann einfach Zugang zu den zwei Load Balancern und prüft auf der Basis einfach, gehe ich zu dem linken oder gehe ich zu dem Rechten. Genau, das heißt, hier wird beispielsweise das Kubernetes kaputtgehen, der Load Balancer kriegt keine Anfrage mehr von seinem Standort Frankfurt und würde dann auf der Basis … Warte mal. Funktioniert das? Es funktioniert. Wird dann auf der Basis den … Ich bin ein Grafikott geworden. Genau. Wird auf der Basis dann in den anderen Standort schwingen. So viel dazu. Wenn ihr jetzt wissen wollt, wie das dann wirklich funktionieren kann. 

Das habe ich, glaube ich, hier bereitgestellt und weil ich nicht wusste, ob ich Internet habe, habe ich es aufgenommen. Und zwar, hier sieht man auf der linken Seite … 

Die rechte Seite ist wirklich gut, hier sieht man auf der linken Seite den klassischen OVH-Laut, den klassischen OVH-Manager. 

Auf der rechten Seite ist halt Lens. Da passiert auch relativ wenig tatsächlich gleich. Das heißt, ich starte mal das Video und versuche jetzt mal, Asynchronen dazu zu zeigen. 

Also man sieht hier, wir haben ein, alles startet wie gesagt mit dem Private Network. Wir haben ein Netzwerk erstellt, welches in Deutschland und in Frankreich liegt, in DE Linnburg, SGB Straßburg und haben dann zwei Kubernetes-Lautbalancer aufgebaut, die dann jeweils hier auch in den einzelnen Ländern verfügbar sind und sich dieses gemeinsame Netzwerk teilen. Beide haben einen eigenen Load Balancer, wo man Listener und Pools einstellen muss. Im Listener, sagen wir, wird hinterher eine kleine Webanwendung. Das heißt, ich brauche den Port 80 und definiere im Bereich des Pools einen Member-Bereich, wo dann der gesamte Node-Pool aus dem einen Cluster hinzugeefügt wird. 

Ab diesem Zeitpunkt wäre dieses eine Cluster schon möglich zu laufen, aber halt nur mit 99,5. 

Das hier ist der Load Balancer, der sich in der Hierarchie auf der Beermetal-Seite einortet. Ist dann einer, es gibt halt unterschiedliche die Load Balancer, die heißen alle Load Balancer hier. Und da ist es wichtig, dass man quasi auch mehrere … Also das ist jetzt die IP von dem Public Load Balancer in der einzeln stände und dort kann man eine Konfiguration eingeben, dass es einen Backup und einen Primärstandort gibt und das Schamante hieran ist – das musste ich ganz schnell reden –, dass man gerade da gesehen hat, dass es eine Kategorie gibt, das heißt „First. 

Das heißt, der überlegt nicht, ob er links oder rechts gehen soll, sondern pusht seinen Traffic immer zu dem Hauptstandort, bis es den nicht mehr gibt. Dieser prüft alle 30 Sekunden einfach: Ist mein Standort noch erreichbar oder ist er nicht erreichbar? 

Das würden wir jetzt hier sehen. Das ist der Standort. De, wie man so schön sieht, eine wunderschöne Hello World-Seite. Und das, was jetzt auf der rechten Seite passiert, das ist, dass ich den Nord weg haue und auf der Basis dann einfach symbolisiere, dass das Cluster nicht da ist. 

Wir können auch noch mal über Storage reden, versprochen. Genau, aber spät. 

Guck noch mal auf den Zettel. 

Genau, also. 

Jetzt kommen wir zu Storage. Auf jeden Fall nett überbrückt, habe ich den weg Habe ich den gedraint und das heißt, der Traffic ist nicht da und es braucht jetzt ganze 30 Sekunden, bis er festgestellt hat, dass sein Standort nicht da ist und ab jetzt gleich ist der dann in SGB oder ich habe schon schwer zu lang gesprochen, der versucht, er wieder zurückzuschwenken. 

Ich überlege Ja, auf jeden Fall 30 Sekunden macht er das ungefähr. 

Das ist ziemlich lange. 

Das sind lange 30 Sekunden. Es gibt tatsächlich auch die Möglichkeit, dass man das nicht mit dem … 

Jetzt ist das tatsächlich Genau, in „SGB und jetzt würde ich den wieder verfügbar machen. Ich glaube, das sieht man. Jetzt sieht man wirklich einfach gar nichts. Aber da ist jetzt der Knopf zum Uncorden. 

Genau, also jetzt wird der Traffic wieder auf seinen Primärstandort weiter der geleitet werden. In diesem Fall ist die kleinste Einstellung in diesem IP-Load Balancer auf 30 Sekunden. Es gibt auch Szenarien, diesen einfach nicht zu nehmen. Dafür bräuchte man aber einen DNS, der dann beispielsweise bei Cloudflare sitzt, wo man einfach zwei L-Records hinterlegen kann, dort eine Art DNS-Failover dann durchzuführen. Aber weil ich alles per Terraform skripten wollte, habe ich mich in diesem Beispiel einfach auf den Load Balancer über den Load Balancer darauf konzentriert. 

Und genau, das, wenn ihr das haben wollt, ist es auch alles noch mal als Terraform auch bereitgestellt mit einer kleinen Anleitung und das, was ich gerade erzählt habe, per Knopf drückt dann in dem Sinne, so, dass ihr euch das dann auch noch mal im Detail anschauen könnt. 

Genau. Und das Spiel geht noch mal los, und zwar da, wenn ihr das auch haben wollt. Ja? Da war es ein Multi-Reason-Multi-Cluster-Setup, oder? Das war kein Multi-Reason-Multi-Cluster-Setup. Das war ein Failover-Setup. Das heißt, du hast zwei, und das ist in dem Sinne das Manko an dieser Variante. Du kannst das klassische Kubernetes, was es gibt, da kannst du nicht an sich über mehrere Standorte verteilen, weil du je Standort eine eigene Control Plane hast. Und für einen Multi-Region Cluster müsstest du eine gespreadete Control Plane haben, die einfach entscheiden kann, wo er seine Last verteilen möchte. Dafür gibt es eine andere Variante, die es aber auch gibt, aber halt nicht in Deutschland. Ist das dann ein Single Cluster Multi-AZ? Das hier wäre jetzt gerade ein klassisches Failover Cluster, so wie so ein Active-Pacif. Das ist ein 3erz Cluster, was ich meinte. Also was du meintest. Ein Cluster mehrere. Genau, das heißt, man hat einfach nur einen Cluster und ich bin mir nicht sicher, ob ich das zeigen kann, weil der Beamer ist schwarz. Aber hier sieht man das. Genau, also das hier, was ich kann auch, glaube ich, nicht so ganz einfach hier auf … Ich mag halt schwarz Da ist der Hintergrund. 

Ich guck einmal kurz, ob ich hier … 

Normalerweise kann man doch immer so einen schönen weißen Hintergrund auch mal anmachen. So, hier, da. So, also gucken wir mal, wie weit wir hier kommen, aber ich weiß nicht, ob ich den noch hoch habe. Leider Gottes kann ich es nicht zeigen. Da müsste ich gucken gleich. Ansonsten kann ich das vielleicht gleich einfach hier nachzeigen. Also es gibt auch die Möglichkeit, ein 3AZ darzustellen. Genau da hat man einfach die Möglichkeit, eine eine Control Plane zu liefern, die einfach auf mehrere Rechenzentren verteilt wird und auf der Basis dann einfach ein richtiges Multi-Reason-Setup möglich ist. Das kann man nur unterliegen können? Nein. Genau, auch? Bald in Mailand. 

Balt in Mailand, okay. 

Genau. Und weil das so ist, hatten wir uns überlegt, wie kriegen wir letztendlich die 99,5 besser hin. Zu der Zeit gab es auch noch nicht das Announcement von einem Premiumplan. Da hätte ich mir vielleicht diese ganzen Gedanken gespart, aber sei es so. Auf jeden Fall das, was es halt noch zusätzlich gibt, sind diese zwei Varianten und das heißt auf der linken Seite der Premiumplan. Das heißt in dem Sinne, also alles das, was hier steht, ist momentan eigentlich das, was für den 3AZ zutrifft. 

Und da habe ich noch keine richtige Anleitung oder Beschreibung für das 1AZ gesehen. 

Das heißt auf jeden Fall, also falls ihr Das ist dann analog ein Angebot zu dem, was bei Azure, bei A, W, S und Co. Gibt. Da gibt es ja auch diese Premiumpläne, wo dann einfach Redundantschicht eingebaut werden, wo man von einer hochverfügbaren Control-Planche spricht, dass sie dann einfach nicht einmal da ist, sondern dass OVH dafür sorgt, dass es dort auch Redunanzen geschaffen werden, auf dieser Basis dann einfach von der 99,5 irgendwo nach oben zu kommen. Dachte ich, erhoffe mir 99,8, weil dann wäre es genau das, was man bei Azure und AWS bekommen kann, aber ich weiß es noch nicht. Vielleicht weißt du das. Weißt du? Okay. Genau, und das zweite Setup ist das 3er-Z und das ist so in die Richtung Crème de la Crème von Kubernetes, weil da oben geht es halt wirklich dann, man hat eine Control-Plan. Man kann das Cluster so benutzen, als ob es einfach ein Standort wäre. Die Latenzen sind halt so gering, dass man quasi seine Anwendung komplett so verteilen kann, dass sie ein paar in dem einer Z sind, ein paar in dem zweiten und wenn eins ausfallen würde, Er kann dieses Cluster automatisch seine Last dann auf andere Nordpools verteilen. 

Wie das so ganz, ganz grob aussehen würde, seht ihr hier: Es gibt momentan nur EU West, Paris A, B und C, wo da die Control Plane letztendlich drüber gespreadet ist. Das heißt, ist das genau dein Szenario am Ende und du kannst da flexibel das verwalten. Ich dachte zuerst, fünf Minuten noch, das Das kriege ich auch hin. Genau, ich dachte zuerst, das wäre so eine Art Active-Active-Cluster, dass man einfach alles, was man auf der einen Seite macht, einfach spiegelt, weil die Datenbank funktioniert auf der Welt so, aber es ist tatsächlich so, dass man wirklich frei gestalten kann. Du kannst sagen, ich habe eine Anwendung, die nenne ich A, die lasse ich verteilen auf jeden einzelnen Standort und sorge halt so für eine Hochverfügbarkeit. Du kannst genauso sagen, ich habe einfach nur einen Pot, der soll nur in Standort B sein oder ich möchte mich komplett auch über mehrere die Notes in Standort A konzentrieren. Das ist alles per Anleitung konfigurierbar. Und dafür habe ich keine Anleitung geschrieben, weil OVH das schon gemacht hat. 

Und das ist hier auf der rechten Seite oder auf dem Link, den ihr da unten eindeutig sehen könnt. 

Also sucht halt nach OVH 3Z, das ist irgendwie der erste Link davon. Und das Schöne davon ist, es gibt komplett fertige Terraform-Skripte, wie man dort dann auch ein Deployment quasi horizontal machen kann oder vertikal. Und ja, also so kann man dort den Einstieg auf jeden Fall sehr erleichtern. Die letzte Frage, die, glaube ich, schon halb beantwortet war, war: Warum mache ich diesen ganzen Spaß, wenn es ein 3erz gibt? Weil dieses 3er-Z ist einfach ein sehr guter Service. Du kriegst damit 99,99% hin. Das ist ein wirklicher Multi-Revient-Service, der einfach konkurrenzfähig auch sein kann. Für mich wäre es in Paris und Italien. Ich würde mich freuen, wenn es irgendwann einen in Deutschland gibt. Da müssen wir alle noch einmal mit Falk drüber sprechen. Genau, und weil das es einfach nicht gibt, hatten wir uns die Gedanken gemacht: Wie kann eine Welt aussehen ohne 3RZ, die besser ist als das, was man hat? Und das ist halt ein Kompromissweg, der gleichermaßen so flexibel ist, dass man halt sagen kann: Ich nehme Frankfurt und Straßburg, ich nehme UK und Grave Line oder, oder, oder. Und durch die Wahl von Active-Passive ist man auch ein bisschen freier von den Latenzen. 

Vier Millisekunden ist Bombe. Für Active-Active, in dem Sinn teilweise grenzwertig, aber immer noch super. Aber wenn man halt auf wenn es dann Active-Passive-Failover geht, ist das so, dass man einfach dann sich eigentlich auf Frankfurt konzentriert, dann eine Datenbankschicht beispielsweise so aufbaut, dass man eher über MySQL-Replika geht und wenn dann einfach irgendwann Frankfurt brennt Und wenn, dann brennt dann nur in Straßburg. Sonst sagt es immer irgendjemand. Genau, auf jeden Fall hat man dann in dem Fall einfach genug Zeit. Die Replikation, das funktioniert dann problemlos und dann kann man sich schwenken und 30 Sekunden ist dann in dem Sinne auch nicht die Welt. Und wenn man mehr braucht, dann nimmt man sich das 3RZ. So viel zu mir. Das ist mein LinkedIn. Da muss man ansonsten keine weiteren Namen eintragen. Ich hoffe auf Gespräch. Ich weiß nicht, ob wir jetzt noch mehr Zeit für Fragen haben. Ich würde noch mal, wenn wir im Grunde fragen, ob noch Fragen da sind.