Hi zusammen! Schön, dass ihr beim letzten Vortrag noch da seid, das ist ja doch schon ein bisschen später geworden. Wir haben fast noch pünktlich angefangen. Ja, ich bin ein bisschen überrascht über die Anzahl an Leuten hier, dass es doch noch so viele sind.

Ich habe gedacht, in Zeiten von Cantena und Co. würde keiner mehr klassisch virtualisieren. Aber freut mich umso mehr, dass ihr da seid und ich hoffe, dass ich euch die nächste dreiviertel Stunde noch ein bisschen was Interessantes erzählen kann. Mein Vortrag ist zweigeteilt. Wir sind jetzt da vorne sozusagen. Ich will euch ein bisschen Theorie zur Hochverfügbarkeit erzählen und ein bisschen mehr in die Praxis, wie man so einen Mustercluster aufbauen könnte

oder beziehungsweise, wie es häufig getan wird. Ihr findet hier unten direkt die erste Anmerkung, HA, High Availability, Hochverfügbarkeit zu Deutsch, für den, den es das nicht sagt. Ich werde meistens im Hochverfügbar... Ich werde meistens vorhin Hochverfügbarkeit sprechen, weil im Englischen ich mich noch häufiger vertun werde, dass ich es im Deutschen tue. Ganz wichtig zu Anfang.

Ich rede hier nur über Servervirtualisierung heute. Ich rede nicht über Netzwerkvirtualisierung, ich rede nicht über Storagevirtualisierung, sondern es geht wirklich um die alte Servervirtualisierung, wie es sie schon lange gibt. Und ein bisschen möchte ich das auch motivieren, worüber wir heute sprechen. Stellt euch vor, ihr seid in der Organisation zuständig. Ihr habt 50, 60 Mitarbeiter und die haben alle einen zentralen Authentifikations-Server,

einen Samba-Server. Und die Leute kommen morgens alle an. Es gibt vielleicht noch ein paar Server da unten und die möchten sich morgens alle anmelden. Und wenn dieser Samba-Server ausfällt, dann werdet ihr relativ schnell mit denen ein bisschen Probleme bekommen, je nachdem, wenn der Chef auch noch sich nicht einloggen kann, dann wird es euch vielleicht sogar jobmäßig an den Kragen gehen.

Und nachdem das vielleicht ein, zwei Mal passiert ist, heißt das, dann können wir das Ding nicht irgendwie ein bisschen stabiler hinkriegen. Und damit gehen wir schon in die Theorie. Ich möchte anfangen in der Theorie, so ein bisschen im Hintergrund, mit drei Missverständnissen, die ich, Dachchen, mit drei Missverständnissen, die ich denen häufig begegne zum Thema Hochverfügbarkeit.

Das Erste ist, entgegen dessen, was euch die Werbung, in Anführungs-Sprechen, Glauben machen möchte, Hochverfügbarkeit ist nicht nur Hardware. Hochverfügbarkeit ist ein Service. Das heißt, es bringt euch nichts, zwei Maschinen in die Seite zu stellen, zu sagen so, das Ding ist jetzt hochverfügbar und gut ist. Ich bin fertig.

Das Zweite, Hochverfügbarkeit. Hochverfügbarkeit ist ein relativ schwammiger Begriff. Und viele gehen davon aus, die vielleicht schon mal virtualisiert haben, das ist irgendwie ein Knöpfchen, das drücke ich, dann ist das Ganze hochverfügbar und gut ist. Wenn wir erklären wollen, was Hochverfügbarkeit ist, müssen wir erst mal klären,

was bedeutet eigentlich Verfügbarkeit an sich. Und Verfügbarkeit ist eigentlich eine relativ einfache Gleichung. Wir haben auf der einen Seite den Dividend, die Laufzeit und auf der anderen Seite die Gesamtzeit. Während die Laufzeit relativ einfach zu definieren ist, also solange, wie meine Sachen gerade laufen, ist das bei der Gesamtzeit schon ein bisschen schwieriger. Reden wir von 9-5, fünf Tage die Woche.

Reden wir von 9-5, sieben Tage die Woche. Reden wir von 24, sieben. Und abhängig davon ist natürlich die Verfügbarkeit auch jeweils ganz anders definiert. Und das IEEE hat dazu eine Liste aufgestellt, wir sind das in Klassen eingeteilt.

Und die fängt bewusst bei Klasse 2 ab, weil sozusagen die Number of Nines ist. Jetzt mag natürlich irgendwo das nach einem Marketing-Gag klingen. Was macht der Unterschied zwischen 99,9 und 99,99%? Das ist ja irgendwie zweite Nachkommerschaft, das kann keinen großen Unterschied machen. Doch tut es und das tut es dann, wenn man sich mal überlegt, was das an Ausfallzeit bedeutet.

Bezogen auf 24,7 sieht man, dass eine Abzeichen von 99%, so viel wie dreieinhalb Tage Down-Time im Jahr bedeutet. Während die nächste Klasse schon bei nur noch einem Zehntel ist. Wenn man sich das grafisch mal anguckt, sieht man, das ist schon echt wirklich ein krasser Unterschied. Und man definiert so in der meisten Literatur

irgendwo so etwas unter eine Stunde Zeit, die das ausfällt im Jahr als Hochverfügbarkeit. Das heißt, wir wären nach dieser Definition ungefähr bei Klasse 4. Also ab dem Zeitraum können wir von Hochverfügbarkeit grundsätzlich sprechen. Jetzt ist das natürlich aber auch weiterhin sehr abhängig davon, in welchem Umfeld bewege ich mich.

Hochverfügbarkeit für den Samba-Service, da sind es eine Stunde Ausfallzeit, ist im Jahr absolut top. Es bleibt aber zu hoffen, dass die deutsche Flugsicherung ihren Cluster nicht eine Stunde ausfallen lässt im Jahr, weil dann wäre in dieser Stunde doch relativ viel am Himmel los. Das heißt, da sozusagen sich immer überlegen, was bedeutet Verfügbarkeit und daraus, wie gesagt,

was bedeutet Hochverfügbarkeit? Und zu guter Letzt das Missverständnis oder beziehungsweise das, was immer so ein bisschen schwammig bezeichnet wird. Wir müssen unterscheiden zwischen lokaler Verfügbarkeit und Netzwerkverfügbarkeit. Lokal reden wir in einem Server, da reden wir eventuell von einem Raid-Aufbau, da reden wir davon sozusagen, dass eine Maschine an sich ab ist. Netzwerkverfügbarkeit heißt auf der anderen Seite,

dass der gesamte Service da ist, dass das Gerät halt im Netzwerk erreichbar ist. Das sind zwei unterschiedliche Verfügbarkeiten bzw. zwei unterschiedliche Herangehensweisen technisch, wie ich das löse. So viel zu den Missverständnissen. Und nachdem wir die geklärt haben, möchte ich noch so ein paar Begriffe mal reinbringen,

um die so ein bisschen zur Grundsprache im Hochverfügbarkeitsumfeld gehören. Und eine Weisheit sagt, frage nie, ob etwas ausfällt, sondern frage immer nur, wann. Und stellt euch das mal ganz einfach vor, ihr wollt einen Kuchen haben. Und dazu braucht ihr abgesehen von irgendwie den Skills, Kuchen backen zu können, Backbuch, Zutaten, Backofen

und so weiter und so fort, dann seid ihr irgendwann glücklich. Wenn eines davon ausfällt, es ist egal was, dann kriegt ihr am Ende des Tages nicht euren Kuchen und seid unglücklich. Das Ganze nennen wir Single Point of Failure. Das heißt, es ist egal, was ausfällt, unser gesamter Prozess funktioniert nicht mehr. Das ist etwas, was wir nicht haben wollen.

Zweitens, stellt euch vor, ihr habt eure Internetleitung zu Hause. Die hat eine garantierte Uptime im Vertrag von 97%. Das ist gar nicht so unüblich. Das heißt, ihr habt irgendwas wie 11 Tage Downtime. Was macht der, wenn ihr mehr erreichen wollt? Na ja, ihr überlegt, ich schalte davon zwei parallel

und dann habe ich halt eine höhere Downtime. Wie hoch wird die, wird es wohl sein, wie hoch wird die Uptime, nicht der Downtime wird hochgehen, sondern die Uptime wird hoffentlich hochgehen. Wo werde ich mich ungefähr bewegen? Ja, das stimmt, da hast du vollkommen recht. Wir müssen natürlich, wenn wir rein mathematisch, wenn wir sagen, die sind unabhängig voneinander,

dann können wir das rechnen. Da hast du, du hast natürlich vollkommen recht. Also, die Anmerkung war, wenn ich die beiden jetzt beispielsweise sage, ich habe hier Telekom und Kongstar auf der gleichen Leitung da drauf, wenn mir sozusagen der Bagger da vorne reinkommt, der trennt mir die Leitung durch, dann ist das natürlich meine ganze Verfügbarkeit an der Stelle hinfällig. Rein mathematisch erst mal, wenn ich jetzt hergehe,

wie im großen Rechenzentrum, die haben eine Leitung von links kommen, eine Leitung von rechts kommen, so groß ist hoffentlich kein Bagger, dann wird das Ganze hoffentlich nicht miteinander korrelieren und dann kann ich sagen, okay, ich kann meine Hochverfügbarkeit damit oder meine Verfügbarkeit damit erheblich erhöhen, indem ich Redundanz reinbaue. Und das ist etwas, was wir ganz, ganz zentral haben, was wir immer haben wollen, Redundanz,

damit wir halt in einem Ausfall von einem immer noch einen Rückfall auf einen anderen haben können. Stellt euch vor, wir haben jetzt hier Redundanz und zwei Samba-Server aufgebaut und die beiden müssen natürlich, das ist irgendwie relativ klein, die müssen ihre Daten austauschen. Das heißt, ich melde mich an dem einen an, ich ändere vielleicht mein Passwort, dann musst du das irgendwie zu dem anderen hinbekommen.

Dafür haben die beiden dann halt einen Crosslink und tauschen ihre Daten untereinander aus. Was passiert, wenn das ausfällt? Dann könnt ihr euch hier mit dem neuen Passwort anmelden, hier aber nicht, weil die Daten sind nicht ausgetauscht worden. Das heißt, wir reden hier von einem Split-Brain. Und Split-Brain ist so ziemlich das Schlimmste,

was uns passieren kann. Wenn die nämlich beide raussprechen und wenn ein Samba-Server ist und ein Passwort passt nicht, ist das vielleicht noch eine Sache. Schlimmer ist, überlegt euch mal, es geht hier ums Banking, es geht hier darum, dass auf der einen Seite beim Konto was abgebucht wird und auf der anderen Seite nicht. Und beide Server denken, ach, ich bin ja der Aktive. Wie wir damit umgehen, klären wir später. Das nun mal sozusagen als Legostein, das ist etwas, was wir auf gar keinen Fall haben wollen.

Zu guter Letzt, zur Einführung an der Stelle, zur Hochverfügbarkeit gehört eben, ich habe ja gesagt, das ist ein Service. Zur Hochverfügbarkeit gehören nicht nur ein paar Server hinzustellen. Zur Hochverfügbarkeit gehört auch sowas wie redundante Stromversorgung, redundantes Netzwerk, redundante Kühlung.

Zur Hochverfügbarkeit gehört auch Monitoring. Es bringt mir nichts, wenn ich mir zwei Datencenter dahinstelle, das eine fackelt mir ab und ich bekomme nichts davon mit. Und zu guter Letzt, es gehört auch Dokumentation dazu. Wenn eins ausfällt und ihr sitzt da erst mal und denkt euch, oh Gott, was mache ich denn jetzt, wie kriege ich das denn jetzt hin? Probieren wir mal ein Produktivsystem, mal irgendwas aus und dann könnt ihr euch sicher sein, dann habt ihr gar keine Verfügbarkeit mehr.

So viel zum Thema Einführung. Ganz wichtig ist noch, wir müssen uns hier ein bisschen überlegen, Server-Hochverfügbarkeit versus Service-Hochverfügbarkeit. Im Falle des Samba-Servers, es ist den Leuten ja vollkommen egal, wenn ich zwei Samba-Server habe, ob einer von denen ausgefallen ist. Wichtig ist auch für die, dass der Service als solcher verfügbar ist,

nicht, dass der Server, das interessiert die Leute nicht. Und auch das ist ein Punkt, den muss man irgendwie immer im Hinterkopf behalten. Wovon reden wir eigentlich? Reden wir von einer Server-Verfügbarkeit oder reden wir von einer Service-Verfügbarkeit? Das wird auch im späteren noch mal recht interessant für uns. Gucken wir uns doch mal so einen Mustercluster an.

Und ich glaube, also fast alle Cluster, die ich gesehen habe, sind irgendwie nach gleichem Schema aufgebaut. Die Technologien unterscheiden sich. Die einen nutzen Ethernet, die anderen nutzen Fiber Channel. Manche nutzen jemand noch Infini-Bands. Okay, ich glaube, das stirbt so langsam aus. Wodem? Wodem. Aber im Prinzip, der Aufbau ist meistens der gleiche.

Wir haben irgendwo hier unseren Virtualisierungshost und wir haben auf der anderen Seite einen Klein. Wie die Daten jetzt zum Kleinkommen, ist hier gar nicht Bestandteil der Betrachtung. Wir gehen mal davon aus, der hat eine Abteilung von 99%. Einfach mal als Zahlenspiel. Für die, die es interessiert, die Zahlen, wie wir darauf kommen, sind immer unten rechts mal eingeblendet, so als Formel. Jetzt haben wir eben festgestellt, okay, um das zu...

...erhöhen die Verfügbarkeit, packen wir doch einfach zwei nebeneinander. Virtualisierungshost, zwei Stück nebeneinander. Die haben einen Interconnect zwischen sich beiden. Und schon, wenn wir das mal ausrechnen, haben wir fest, 99,99%. Und wir haben schon ein Klasse-Vier-Cluster, zumindest rein theoretisch mit diesem Zahlenspiel, fertig, Vortrag zu Ende.

Warum nutzen wir das nicht? Also, es wird sogar tatsächlich in der Realität genutzt. Das Problem ist an der Sache, das Zeug skaliert gar nicht. Weil, wenn ich hier vorstelle, meine Virtual-Maschine fällt hier aus, dann muss ich ja auch dafür sorgen, dass die Festplatte, das Festplatten-Image auch auf dem drauf ist. Das geht bei zweien vielleicht noch.

Aber wenn ihr euch vorstellt, dass ihr 10, 15 Server habt, dann müsste ja jeder Server, oder so ziemlich jeder Server, auch die Festplatten der anderen, oder die Festplatten-Images der anderen haben. Deswegen, um das zu vermeiden, gehen wir her und sagen, okay, pass mal, wir packen uns einen Switch dazwischen und machen einen eigenen Storage-Server. Jetzt geht die Verfügbarkeit leider natürlich erheblich zurück,

weil wir hier noch mehrere Kinderchen unterwegs haben, die auch alle Probleme haben können. Gehen wir mal davon aus, Storage ist auch irgendwo bei 99% Uptime, der Switch ist irgendwo, gehen wir dem an 99,9% Uptime in dem Zahlenspiel, weil wann fällt schon mal ein Switch aus? Jetzt haben wir festgestellt, nicht so häufig wie Server der eigenen Erfahrung nach,

haben wir festgestellt, um das zu erhöhen, naja, bei den Virtualisierungs-Hosts hat das ja wunderbar geklappt, Redundanz zu machen, machen wir das bei den Storage-Servern auch. Klappt auch wunderbar, wir sind bei 89,9%, d.h. wir haben am Schluss wieder eine Verfügbarkeit ungefähr so, wie wenn wir nur einen einzelnen Virtualisierungs-Host gebaut hätten.

Ist jetzt noch nicht so ganz toll. Gehen wir den nächsten Schritt, haben gesagt, okay, das hier haben wir Redundanz, das haben wir Redundanz, dann werden wir wohl auch das Netzwerk redundant machen. Ihr seht zwei Sachen, erstens, jetzt ist alles redundant, zweitens, es wird relativ komplex vom Aufbau her. Das sollte man immer nicht vergessen, dass der Aufbau natürlich erheblich komplex ist

und es relativ schnell, man aufpassen muss, dass man keine Materialschlacht anfängt. Aber wir haben das erste Mal tatsächlich eine Situation, in der ich volle Redundanz habe. Und das betrifft auch die Wartung. D.h. ich kann das erste Mal tatsächlich sagen, nicht nur mir fällt da einer aus, sondern ich kann auch einen Down nehmen für Maintenance. Ich kann das Upgrade auf irgendeinem ausführen und so weiter und so fort.

Und was die Situation auch sehr sexy macht, ich kann jetzt einzelne der Elemente upgraden. Ich kann z.B. sagen, ach so, wir sind jetzt schon bei 99,98%, ich hab's jetzt vergessen, also irgendwo auch schon sehr hoch verfügbar. Und ich kann jetzt sagen, okay, pass mal auf, ich brauche mehr Rechenpower, also pack ich mir jetzt mehr Virtualisierungssorts darin. Oder ich bräuchte mehr Storage,

dann pack ich mir mehr Storage dahin. Also d.h. ich kann die einzelnen Elemente je nach Bedarf einfach vergrößern oder halt verkleinern. Jetzt sehen wir hier auch einen schönen Nebeneffekt, wir sind jetzt hier wieder bei 99,99%, haben unsere Klasse 4 erreicht. Aber darum ging es nicht. Gehen wir manchmal einen Schritt zurück und sagen, wir haben hier unsere zwei Virtualisierungssorts. Wie ich gerade eben schon sagte, Switch fällt aus, ihr seht, es ist alles redundant,

ich hab immer noch einen Pfad. Und das ist auch das erste Mal, dass ich tatsächlich hergehen kann und wirklich so was wie Service Level oder Operational Level Agreements treffen kann. Also jeder, der Systeme nicht redundant ausführt und ein entsprechend hohes Service Level Agreement unterschreibt und Sachen nicht sozusagen an der Seite hat,

der ist, wie ein Bekannter von mir sagen würde, mit dem Klammerbeutel gepudert worden. Weil ihr müsst ja bedenken, wenn euch da so ein Virtualisierungshost ausfällt oder auch wenn euch ein Switch ausfällt, ihr könnt nicht den einfach nur zur Seite nehmen, sondern ihr müsst euch auch noch einen neuen bestellen. Das heißt, ihr habt einen Downtime nicht nur von ein paar Stunden, sondern ihr wählt halt von ein paar Tagen oder ein paar Wochen. Das heißt, immer Redundanz. Das war es zur Theorie.

Ein bisschen mehr zum Thema Praxis. Ich habe ja gerade gesagt, wir haben auf der einen Seite den Storage, wir haben auf der anderen Seite die Virtualisierungshost. Und gucken wir uns dann mal eine Möglichkeit an, wie wir einen Storage aufbauen können. Das eine ist iSCSI. Relativ abgehangen.

Wir haben auf der einen Seite das Target, dort, wo die Daten liegen. Wir haben den Initiator, also sozusagen der, der die Daten haben will. Und der stellt das Ganze über TCP IP, also iSCSI ist nichts anderes als das SCSI-Protokoll, einfach an TCP IP gerapt, als Block Device zur Verfügung. Das Ganze hat den Vorteil, das ist relativ, das ist routingfähig.

Das ist mit Standard-Hardware benutzbar. Das heißt, ich kann auch meine Ethernet-Switches beispielsweise benutzen, wenn die entsprechende Bandbreite haben und entsprechend geringe Latenz. Das Ganze ist multipathfähig. Das ist im Vergleich, wenn man das jetzt mit Fiber Channel vergleicht, in der Regel etwas schlechter in der Latenz. Wobei man sagen muss,

was ist immer die Frage, mit was vergleiche ich das? Also modernes 40 oder 56 Gigabit Netzwerk ist auch schon schnell genug in der Regel für Virtualisierung. Da braucht man sich eigentlich keine Sorgen machen. Aber es ist erst mal ein Block Device. Das ist kein Netzwerk-Dateisystem. Das heißt, wenn der eine Virtualisierungshost auf die Idee kommt, auf den Blöcken 17 bis 23 was zu schreiben und der andere denkt, die fangen beim Block 22 bis 25 an, was zu schreiben,

dann ist das, was am Ende rauskommt, nichts anderes als Datenmüll. Das heißt, wir brauchen irgendjemanden noch in der gesamten Situation drin, der uns das Ganze organisiert und dafür sorgt, dass jeder so seinen Bereich hat, den er übernimmt. Nichtsdestotrotz, das ist die Variante, wie man es häufig auch nutzt und auch einbindet. Jetzt haben wir eben gesagt,

irgendwie Redundanz wäre relativ schön, wäre toll zu haben. Wie machen wir das also auf? Also ein hochverfügbares Eiskasim. Wir haben weiter an unseren Tag, wir nehmen jetzt Master und wir haben unseren Initiator. Um das Ganze hochverfügbar zu machen, nehmen wir uns noch einen zweiten mit dazu, bauen Crosslink zwischen den beiden auf und nutzen zur Synchronisation zwischen den beiden DABD.

DABD ist mittlerweile ein Kernel-Modul, was es mittlerweile ist, irgendwie seit Version 2.4 irgendwas oder so schon im Kernel da drin, sorgt dafür, dass die beiden die Sachen replizieren. Der Schreibzugriff über Eiskasim würde normalerweise ganz simpel so aussehen, ich kriege die Daten, ich schreibe die mir weg, gebe ein Okay, mache ein Häkchen dran, gebe die wieder zurück an denjenigen,

der geschrieben hat, ist alles in Ordnung, habe ich erfolgreich geschrieben. DABD erweitert das Ganze und sagt, okay, pass mal auf, ich kriege die Daten, baue eine Verbindung zu meinem Slave auf, gebe dem die Daten, der sagt mir, habe ich geschrieben, gibt mir das zurück, erst in dem Moment bezeichne ich die Daten als geschrieben und erst dann gebe ich an den Initiator zurück,

hör mal, das Ganze ist geschrieben. Das hat den Vorteil, dass wenn irgendwo zwischendurch etwas passiert und ausfällt, ich auf jeden Fall Datei-Integrität habe, denn es bringt mir die ganze Hochverfügbarkeit, bringt mir alles nichts, wenn die Dateien nicht integer sind, wenn ich irgendwie, Thema Split-Brain, total unterschiedliche Informationen auf den Servern liegen habe.

Damit die beiden auch wissen, so nach dem Motto, hör mal, ich bin da, kommunizieren, lieber Heartbeat-Pacemaker. Heartbeat ist an der Stelle ein kleines Protogoll, was wirklich wie so ein Herzschlag regelmäßig fragt, bist du noch da, bist du noch da, bist du noch da, bist du noch da, bist du noch da. Hat etwas unrühmliche Ruhm

oder etwas unrühmlichen Ruhm erfahren im letzten Jahr beim Heartbeat-Bug, weil man das Ganze über SSL machen kann und da war letztlich ein Fehler drin, der dazu auch geführt hat, dass diverse Hunderttausende Millionen von Servern im Internet verwundbar waren. Grundsätzlich aber natürlich eine vernünftige Sache oder beziehungsweise grundsätzlich gedacht,

meistens irgendwo in einem konzentrierten Rechenzentrum, wo ich einfach eine dedizierte Strecke habe und mir eigentlich über Sicherheit keine Gedanken machen muss. Dazu gehört zum Heartbeat, gehört ein Programm namens SpaceMaker, also zum Deutsch Herzschrittmacher, der letztlich Ressourcen verwaltet. Was diese Ressourcen sind, dazu kommen wir jetzt. Und zwar stellt euch vor,

ihr habt den Initiator. Der Initiator beim iSCSI-Protokoll, der hat eine IP-Adresse, mit der er sprechen will. Das heißt, der sagt, ich habe hier eine IP-Adresse, da will ich meine Daten hinschicken, von denen will ich die lesen. Nur welche der beiden IP-Adressen nehmen wir denn hier? Antwort ist, keine von beiden. Wir definieren einfach eine IP-Adresse für die beiden als Ressource und sagen, die ist hoch verfügbar

und die wird, die beiden unterhalten sich untereinander und sagen, hör mal, ich hab die gerade. Wenn wir jetzt den Master wechseln auf den Slave, dann gibt der die sozusagen ab, der übernimmt die, das Ganze wird an den Switch propagiert und der Initiator schreibt an die gleiche IP-Adresse weiter und bekommt davon nichts mit. Für den ist das völlig transparent.

Problem ist, wir haben weiterhin eine Situation, in der wir Split-Brain haben könnten, weil hier irgendwie zwischendurch ein Problem passieren kann. Wie gehen wir da mit um? Die erste Möglichkeit, es gibt zwei davon, die man auch manchmal zusammen benutzt, die erste Möglichkeit ist, dazu muss man ein Stückchen zurückgehen, Stunned Deathmatch. Ich weiß nicht, ob das jemand schon mal gehört hat.

Die Idee ist, jeder Server heutzutage hat ein IPMI-Interface da dran. Das ist ein kleiner Controller im Server drin, der unter anderem Powerfunktionen hat. Das heißt, ich kann über Netzwerk dafür sorgen, dass ich den aus- oder wieder einschalte. In dem Fall klingt Deathmatch ja relativ böse. Was aber noch viel böser ist, ist die Abkürzung Stunned.

Heißt nämlich, shoot the other node in the head. Das heißt, wir haben hier eine konstante High-Noon-Situation und der fragt die ganze Zeit, bist du noch da, bist du noch da, bist du noch da. Und wenn er nicht da ist, weil der Interconnect zwischen den beiden jemand, dann schießen die sich gegenseitig, es gibt ein wunderschönes Bild dazu im Internet, das habe ich nur leider nicht drauf genommen, weil ich nicht wusste, ob das gemeinfrei ist, dann schießen die sich gegenseitig ab.

Und irgendeiner von den beiden ist schneller, als der andere es ist. Und damit kann ich auch, wenn hier beispielsweise das Betriebssystem, Betriebssystem eingefroren ist, kann ich sicherstellen, dass der erstmal einen definierten Zustand hat und von da aus wieder starten kann. Das zweite ist, ich habe ja gerade gesagt, wir haben hier Pacemaker mit seinen Ressourcen

und wir nehmen jetzt irgendwie einen dritten Server hinzu. Der muss nicht mal auch nicht, der muss nicht die Daten haben, die da drauf liegen, sondern der muss einfach nur ein unbeteiligter Server sein. Und den binden wir in diese ganze Heartbeat-Pacemaker-Geschichte ein. Nicht piece, sondern Pacemaker. Und jetzt stellen wir uns vor, es passiert Folgendes,

der Target, der Slave-Target verliert die Connection. Dann gibt es hier zwischen denen ein Quorum. Der, der unter der Hälfte ist, also das Quorum macht man meistens ungerade oder grundsätzlich ungerade. Der, der die kleinere Menge hat oder die Gruppe derer, die die kleinere Menge hat, setzt sich automatisch inaktiv, weil die wissen ja vorher, wie viel es gibt,

also in dem Fall drei. Das heißt, der sagt, okay, ich gehöre zur kleineren Gruppe, also mache ich nichts mehr. Und die anderen sagen, okay, wir gehören zur größeren Gruppe, also bleiben wir weiter aktiv. Und auf diese Art und Weise habe ich sozusagen mit einer ungeraden Anzahl von Beteiligten, die diese verteilte Datenbank von Pacemaker haben, sehr schön und elegant sichergestellt, dass ich keine Split-Brain-Situation habe

und dass ich Datenintegrität habe. Das Ganze sieht dann, wenn man das mal sich anguckt, PCS, es gab früher dieses Programm CRM, aber das wird nicht weiter gepflegt, das ist jetzt eine neue Variante, sieht dann so aus. Wir haben, sehen erst mal oben, beide Server sind in unserem Fall online. Wir haben unten zwei DABD-Sets.

Ich muss an der Stelle ein bisschen vorgreifen. Overt braucht eine Management-Maschine, die sogenannte Overt Engine, und die muss auch irgendwo laufen. Und in diesem Setup sind wir hergegangen und haben gesagt, okay, wir haben einmal auf den Storage-Servern die Nutzdaten für die virtuellen Maschinen liegen und wir haben ein gespiegeltes DADB-Set,

was die Festplatte für diese einzelne Maschine darstellt, die einfach über KWM läuft. Und wir haben hier am Schluss unsere Ressourcen. Wir haben eine Cluster-IP auf einem Gigabit, wir haben eine Cluster-IP auf 40 Gigabits, die sind alle auf Server 1 gestartet. Wir haben Overt M als virtuelle Maschine,

das wird verwaltet und wir haben das iSCSI. Und im Prinzip gehören die sozusagen so zusammen. Das heißt, in dem Moment, wo der hier ausfällt oder ich das switche, schaltet hier Master und Slave um. Der nun neue Slave beendet die virtuelle Maschine bei sich und der nun mehr neue Master startet die virtuelle Maschine bei sich.

Hier genau das Gleiche, bei einem switch, die beiden gehören zusammen, der nun mehr neue Master übernimmt die aktive Rolle bei DABD und übernimmt auch das iSCSI-Target bzw. die entsprechende Löhne für das iSCSI-Target oder die Löhne, wenn ich mehrere davon habe.

So, so viel zu dem Thema iSCSI. Sehr abgehangen und das meine ich positiv. Also das funktioniert einwandfrei, das funktioniert, das ist halt ein bisschen, ich sage mal, ein bisschen schwieriger am Anfang einzurichten und etwas zickig bei einzelnen Einstellungen, wenn man nicht genau das Richtige macht bzw. sich nicht ganz gut auskennt damit. Die Alternative ist G-Luster FS.

Ich muss dazu sagen, ich komme ursprünglich aus einem High-Performance-Segment oder wir kommen aus einem High-Performance-Segment und wir haben vor einigen Jahren dabei ein bisschen Erfahrung mit G-Luster gemacht und wir hatten das Problem so ein bisschen, die Metadaten-Performance bei G-Luster war nicht so optimal. Deswegen war es bei uns irgendwie so, naja, G-Luster ist noch nicht ganz ausgereift warm.

Aber wir haben damals dann gesagt, okay, es gibt auch Alternativen, lassen wir mal G-Luster sein, sind aber vor einiger Zeit wieder da drauf gestoßen auf G-Luster und haben gesehen, es hat sich a, erheblich einiges weiterentwickelt und b, ich muss natürlich auch bedenken, wenn ich hier 100 oder 200 virtuell Maschinen habe, so viel Metadaten brauche ich nicht, weil das sind 100 bis 200 Images,

die ich da liegen habe und das ist für Metadaten eigentlich nichts. Das heißt also, dieses Problem, was wir damals mit den Metadaten hatten, das ist nicht so gravierend hier in dem Umfeld. Deswegen haben wir gesagt, okay, let's give it a try, wir bauen das auch nochmal mit G-Luster das Ganze auf. G-Luster hat den Vorteil,

es ist ein verteiltes Dateisystem. Das heißt, ich habe wirklich in G-Luster drin schon jemanden, der sich darum kümmert, dass es keine Überschneidungen gibt in den einzelnen Blöcken. Es ist, Zitat von Red Hat, extra für Daten intensive Aufgaben entwickelt und auch das ist wieder natürlich sehr wichtig, es ist weiterhin für TCRP möglich. Das heißt, ich kann meine Standard-Hardware benutzen.

Aufgebaut ist das Ganze ungefähr folgendes. Ich habe in diesem Fall, sagen wir mal, drei Storage-Nodes. Da liegt jeweils sein Dateisystem drauf, Lokal, X4, XFS, worauf auch immer ich auch Bock habe. Und das Ganze ist zusammengefasst zu einem G-Luster, zu einem G-Luster FS in dem Moment mit einem, in dem Fall, Replika 3.

Das heißt, alles, was dort ist, ist dreifach repliziert. Beispielsweise, ich habe hier von meinem Server 1 die QCode-Datei und die liegt dann demzufolge auf allen dreien da drauf. QCode ist das Image-Format für KVM. Ich habe meine zweite Datei, mein zweites Image da drauf. Das heißt dann QCode. 2 sieht genauso aus.

Das ist auf allen dreien repliziert. Ich habe eine einheitliche Schnittstelle nach außen. Das ist sozusagen der Mount-Polt für die anderen dann. Und die Wirt-Horsts greifen alle darauf zu. Fällt einer aus. Kümmern sich G-Luster built-in vollautomatisch darum, dass das sozusagen auf die anderen umgeswitcht wird, dass die darüber informiert werden. Da brauche ich nichts mehr selber zu machen,

wie ich sozusagen, ich brauche kein Heartbeat, kein Pacemaker selber einzurichten. Das macht alles G-Luster für mich built-in. Bitte? Das sind sich alles hot online. Genau, das macht sich alles hot online. Genau, da brauche ich mich nicht drum zu kümmern. Für den Virtualisierungshost ist das sozusagen eine IP-Adresse, mit der man am Anfang spricht.

Und die kümmern sich intern um alles. Ich gehe mal darauf ein. Es gibt nicht nur die eine. Es gibt dieses Replika 3, was ich gerade angesprochen habe. Im Prinzip ist das hier Replikavariant. Ich habe an der Stelle einfach mal, wie ihr unten seht, von G-Luster selber aus der Dugu. Es gibt noch ganz viele andere Art und Weisen. Das ist im Prinzip hier Distributed Replika. Das heißt, ich verteile das auf mehrere und verteile das auch noch auf.

Ich habe Stripe. Das heißt, ich teile meine Datei sogar komplett in mehrere Teile auf. Ich kann auch Distributed Stripe. Muss ich ehrlich sagen, an der Stelle kurz erwähnt, das gibt es. Da haben wir keine große Erfahrung bisher mit gesammelt. Also eigentlich gar nicht. Denn das Problem ist, an der Stelle, so viel es auch gibt, wenn man OVIRT installiert

und man hat nicht gerade die Einstellung Replika 3, dann verweigert er einem die Installation. Das heißt, der sagt, ich will nur Replika 3 haben. Und deswegen ist an der Stelle, muss man einfach sagen, wenn wir noch nicht so viel Erfahrung gemacht haben und gesagt, okay, du willst das, dann nimm du das erst mal. Wäre natürlich schön, mal rauszubekommen, warum kann ich aber leider nicht beantworten, warum das noch nicht anders möglich ist oder ob es anders möglich ist, wenn man halt irgendwelche Einstellungen trifft.

Das kann ich leider gerade nicht sagen. Das heißt, wir haben jetzt hier unsere Storage Server, wir haben unsere VIRTOS im Setup eben gehabt. Das Netzwerk habe ich jetzt mal nicht redundant gezeichnet, weil es hier um gar nicht gehen soll. Also ob das redundant macht oder ob ihr es nicht redundant macht, das war an der Stelle völlig unbenommen. Ihr habt im OVIRT,

habe ich ja eben schon gesagt, eine sogenannte OVIRT Engine. Das ist die Verwaltungsmaschine an der Stelle. Und im OVIRT Sprech wird dann aus den VIRTOS auch werden dann die sogenannten OVIRT Notes. Das Ganze ist Grundlage für die Red Hat Virtualization. Also das ist schon eine Sache, die mit den Red Hat auch rausgeht und sagt, darauf könnt ihr euch verlassen auf den Quark.

Die Engine ist in Java geschrieben und nutzt Wildfire, was ja früher JBoss war. Und das muss man auch sagen, das Ganze ist primär für Red Hat natürlich und seine Derivate. Also wir benutzen dort, wo wir es jetzt gerade als letztes eingesetzt haben, hauptsächlich Scientific Linux, was ja auch von Red Hat abgeleitet ist. Selbst da konnten wir es nicht installieren, sondern es ging halt nur anstatt dessen unter Red Hat selber

bzw. unter CentOS. Das hat sich geschichtlich einfach ergeben und das ist einfach beibehalten worden, weil du halt einfach nicht viele verschiedene Derivate von Red Hat pflegen willst. Also das ist keine Ahnung seit 10 Jahren so. Okay, aber es gibt keinen Spezialgrund? Nö, es gibt keinen Spezialgrund an der Stelle. Also zumindest ist es keiner, der mir bekannt wäre, dass es den noch gibt.

Aber hier sind wir halt einfach auf CentOS umgestiegen, weil wir gesagt haben, das ist das nächste, was möglich ist und unter Scientific läuft es nicht und vielleicht würde man es hinbiegen können. Auf jeden Fall, es gibt Ansätze, das Ganze unter Debian zum Laufen zu bringen. Da sagen aber alle, das ist noch weit davon entfernt, als stabil bezeichnet zu werden. Demzufolge haben wir gesagt, das brauchen wir nicht oder das wollen wir uns nicht antun.

Letztlich steckt dahinter KVM. Wird glaube ich kaum jemanden überraschen. Das Ganze ist Linux virtualisiert, also wird da wohl KVM dahinter stecken. Die Overt Engine hat das Web Frontend, hat eine relativ schöne Rest-Schnittstelle, mit der ich arbeiten kann und der kommuniziert über einen Agent, der auf den Overt Notes läuft, den sogenannten VDSM

oder Virtual Desktop und Server Manager und gibt dem Befehle und der führt die für den aus. Da gehe ich gleich noch ein bisschen drauf ein. Wichtig ist, die Overt Engine selber spricht nicht mit den Storages, sondern sie wählt sich immer einen sogenannten Storage Pool Manager, der seinerseits mit dem Storage dann spricht und die Verwaltung des Storages übernimmt und dann seinerseits die Kommunikation

an die Overt Engine zurückspielt. Das heißt, was ich eben gezeigt habe, dieses hochverfügbare Setup mit KVM und der Overt Engine, da sind wir uns nicht mal sicher, ob es unbedingt notwendig gewesen wäre, weil theoretisch kann die Overt Engine auch aus sein und das ganze System läuft trotzdem weiter. Also ich könnte auch einfach hier

eine Engine laufen lassen. Es gibt neuerdings auch die Möglichkeit oder neuerdings, so neuer ist es gar nicht mehr, der sogenannten Self-Hosted Engine. Das heißt, die virtuelle Maschine der Overt Engine läuft in dem von ihr selber verwalteten Cluster. Als wir uns da dreimal drangesetzt haben, war uns das aber irgendwie aus abstrakten Gründen eine Nummer zu heiß

zu sagen, da liegt die Maschine, die das ganze verwaltet, in dem System, was sie verwaltet und was machen wir, wenn das Ganze aus dem Takt gerät? Wo finden wir die Maschine wieder? Vorteil ist, bei G-Luster, wenn ich mich auf einen der Notes begebe, auf einen der Storage Notes, sehe ich die Q-Code-Datei. Das heißt, ich kann mir wirklich auf dieser Maschine notfalls die Q-Code-Datei nehmen, wenn alles zusammenbricht und kann die irgendwo anders

als KVM starten und kann das Ganze damit wieder bootstrappen und hochziehen. Bei iSCSI, wie gesagt, war uns das damals noch eine Nummer zu heiß. Aber ich will sagen, es gibt's. Und seitdem wir G-Luster benutzen, haben wir uns das auch mal getraut und es funktioniert seitdem auch. Das muss man sagen, es funktioniert seitdem. Es gibt keine größeren Probleme. Oder zumindest gar keine.

Genau, wenn man sich einloggt, sieht das ungefähr so aus. Wir haben hier in der Mitte unsere globale Auslastung. Und was man hier sehr schön sieht, ist einerseits der Speicher, der verwendet worden ist, Arbeitsspeicher und CPU. An der Stelle sozusagen mal eine kleine, ich sag mal in Anführungsstrichen, Kaufempfehlung. Man geht ja nun mal her

virtualisiert aus verschiedensten Gründen. Und die meiste ist ja, dass ich irgendwie die Hardware konsolidieren will und dass ich halt nicht so viel Overhead haben will. In der Regel, wenn man sich einen Server kauft, sagt man, naja, OK, dann kauf ich, zieh ich halt den Regler bei CPU ein bisschen hoch, hol mir eine Mid-Range bis Upper-Range-CPU und hol mir dann halt ein bisschen Arbeitsspeicher da drin. Was ihr hier seht, das sind, ich glaube,

i5-2630 oder so was. Also da sind hier in dem gesamten Cluster sind 48 Kerne drin und 512 Gigabyte RAM. Die Empfehlung eigentlich, wenn man sich Virtualisierung Hosts kauft, ist in aller Regel RAM, RAM und nochmals RAM, wie bei jeder Virtualisierung. Weil hier kann ich am Ende des Tages Overcommitment machen, ohne dass es große Probleme gibt. Bei RAM, ja, es geht technisch,

aber auch das ist eine Sache, wo ich sage, also, da juckt es mich so ein bisschen im Hinterkopf, irgendwie RAM Over zu committen. Das würde ich niemals tun. Das heißt, also RAM, immer schön, das seht ihr hier wunderbar, zwei Prozent. Und das seht ihr hier unten. Na, ist auch erst in den letzten Tagen gestiegen. Also rein rechnerisch würde ich das hier fast schon mit einem Atom abfackeln können.

Und ihr seht gleich nochmal eine Liste über die ganze Liste über die gesamten virtuellen Maschinen. Wir haben so knapp 50, 60, 70 virtuelle Maschinen da drin laufen. Wenn ihr natürlich irgendwie High-Performance-Maschinen da drin laufen hättet, dann sehen natürlich die CPU-Nutzung ein bisschen anders aus. Aber in aller Regel so ein Web-Server, so ein Fileserver, der eidet einen Großteil des Tages, der schläft einfach, der hat nichts zu tun.

Wer schon mal mit VMware gearbeitet hat, dem wird das Ganze hier auch bekannt vorkommen. Ich habe hier Data Center. Ich kann mehrere Data Center aufstellen. Ich kann sogar so weit gehen, dass ich geo-replizieren kann. Da muss ich sagen, habe ich auch keine Erfahrungen bisher gesammelt. Ich kann in einem Data Center kann ich halt verschiedene Cluster aufbauen. Jeden Cluster kann ich halt Storage und Netzwerke zuorten.

Also in dem Sinne keine große Überraschung für jemanden, der schon mal ein bisschen virtualisiert hat. Du musst ja die Netze machen mit irgendwelchen Nuts und sonst was dazwischen. Wie meinst du das? Danke, ich habe eine Büchse. Die macht mir Nuts. Die nächste mal ein Zettel rauf. Die irgendwelche Netze nach Tor. Die nächste mal rauf. Du hast oben einen VPN und hast nicht gesehen. Hier drauf. So innen drin, ja innen drin,

wo du irgendwie 5, 6 Netze hast. Du kannst mehrere Netze definieren. Genau, ich gehe auch... Genau, genau. Das kann man alles definieren. Geh, zeige ich gleich nochmal eine Übersicht. So. Jetzt habe ich ja gerade eben gesagt, okay, wir haben immer genau einen Storage Pool Manager. Das heißt, wenn ich das ganze System das erste Mal aufbaue, ist natürlich klar, ich muss als erstes mir mal einen Virtualisierungshost in das ganze System

reinbringen. Und das geht relativ pretty straight forward. Ich habe hier einen auch wieder, in dem Fall CentOS Maschine. Ich packe da meinen Public Key da drauf und den... Also in dem Fall von der Overt Engine, die lockt sich da ein, die installiert sich die Pakete von ganz alleine. Beziehungsweise stimmt nicht, ich muss mir die Repositories

noch freischalten von Overt, aber dann macht die alles vollkommen alleine. Und ich darf an der Stelle nicht viel machen. Also wir sind am Anfang haben wir ja angefangen, die Bonding einzurichten. Wir haben schon die Bridges eingerichtet auf der Maschine und gesagt, dann brauchen wir gleich alles. Nein, da ist die Installation fehlgeschlagen. Der wollte das nicht. Der will einfach plane seine Netzwerkinterfaces sehen. Alles andere mache ich

später bei dem. Wie gesagt, das seht ihr gleich nochmal. Und was ich hier auch machen kann, Power Management. Ich kann mir hier wieder Fencing definieren. Das heißt, ich habe zu meinem IPI Interface habe ich halt die die IP Adresse beziehungsweise die Zugangsdaten hinterlegt. Und wenn der mir halt ausfällt oder ich den nicht erreiche, kann ich auch da wie eben bei dem Stunt Deathmatch

einfach über die Web Frontend sagen, so nach dem Motto Solomaschine, du starte mal neu. Das ist insbesondere auch bei Hochverfügbarkeit dann wichtig. Wenn ich natürlich sage, OK, da habe ich einen Host, der ist undefinierbar. Dann ist natürlich die Frage, was ist mit eigentlich mit den virtuellen Maschinen da drauf? Laufen die noch? Laufen die nicht mehr? Was ist mit deren Services? Sind die nach außen hin erreichbar? Sind die nicht erreichbar?

Und genau dafür sage ich nach einer gewissen Grace Time oder sagt, oh wird nach einer gewissen Grace Time. So pass mal ab. Ich erreiche dich nicht mehr. Also wirst du hart abgeschossen, weil dann weiß ich ganz genau, wenn der Host nicht mehr läuft, dann haben wir die virtuellen Maschinen nicht mehr da drauf. Können woanders Das Ganze sieht dann sozusagen, wenn man mehrere Hosts hat, in dem Fall sind es vier, so aus.

Ihr seht ganz rechts. Ich habe meinen Storage Pool Manager genau einen definiert. Ihr seht daneben, ich habe die Auslastung vom Arbeitsspeicher, CPU und Netzwerk. Und was ihr noch seht ist, die Overt Engine sieht, oh, die Host brauchen wir wieder ein Update. Da kann ich rechtsklicken sagen, setze den einen in Maintenance Modus, wie man da rechts seht. Und der sagt zu mir, hör mal, bei mir laufen noch ein paar virtuelle Maschinen.

Soll ich die migrieren von einem zum anderen? Dann ist einfach, jo, mach so, ist in Ordnung. Und die Maschinen werden von A nach B migriert und zwar live. Das heißt, es geht kein Ping verloren, es geht keine Arbeit verloren. Das ist für den Nutzer völlig transparent. Die Maschinen werden komplett inklusive Arbeitsspeicher von A nach B geschoben. Und es klappt auch. Was? IP Interessen werden auch mitgeschoben? Ja, klar. Das wird auch.

Das ist... Balancer und so weiter? Bitte? Ihr müsst ja dann irgendwie an der Modbalancer hängen und sagen, die haben beide gleiche IP nach draußen. Nein, nein, muss das nicht. Muss das nicht. Das machen die selber. Das funktioniert vollautomatisch. Also die hängen auch in unterschiedlichen Switches dran. Also auch das klappt. So, jetzt kommen wir zum Netzwerk.

Wie ihr gerade seht, dass es von einem Host ist, das ist das Netzwerk. Ich kann hier mir die Hardware-Geräte reinschieben. Ich kann Bonding daraus machen. Ich kann die Bonding-Modi einstellen. Ich habe hier in dem Fall, wir haben ein 40 Gigabit Interface und wir haben ein 1 Gigabit oder 1 Gigabit Interfaces. Bonding gibt es bis heute einen sehr kuriosen Bug.

Und zwar, es geht alles durch, außer im DHCP-Ablauf, das DHCP-Eck. Das ist relativ doof, wenn man wie hier die gesamte Infrastruktur auf PXE aufgebaut hat, die natürlich DHCP brauchen und man keine virtuelle Maschine installiert bekommt. Das heißt, das Einzige, was hier funktioniert, ist auch irgendwie, glaube ich, relativ logisch,

wie jemand, der sich ein bisschen mit Bonding auskennt, ist halt Active Backup. Der eine ist aktiv, der andere ist passiv, übernimmt nichts an. Dann gehen die DHCP-Pakete durch. Ansonsten, wenn die einmal gestartet sind, könnte ich auch andere Modi einstellen, wenn ich wollte. Und es funktioniert. Nur halt, wie gesagt, dieser eine Bug, der ist auch bekannt, aber bisher leider noch nicht behoben. Das ist die Ansicht

über den Storage an der Stelle. Und was ihr hier seht, ist halt unten erst mal das SSD. Das heißt, da ist unser SSD angebunden. Ich glaube in dem Fall genau, das ist noch das iSCSI. Was ihr hier seht, ist auf einem Host selber die ISO-Domain. Da liegen ein paar ISOs da drauf. Das bringt Overwatch automatisch mit, wenn ich den ersten Host installiere.

Ich habe hier Backup an der Stelle. Das ist über NRFS angebunden. Und ich habe hier noch, das ist aus Testzeiten noch, eine zweite Exportdomäne für Restore. Das ist leider ein bisschen doof. Das ganze Backup hier läuft in dem Setup über ZFS. Und dann werden halt sozusagen Snapshots gemacht. Das Backup selber funktioniert einwandfrei.

Aber in dem Moment, wo ich das Snapshot anlege, ist dieses Snapshot nur read-only. Und selbst wenn ich hier an der Stelle, wie diese Exportdomäne nur noch fürs Lesen nehmen wollen würde, Overwatch testet, ob es schreiben kann. Und wenn es nicht schreiben kann, sagt das funktioniert nicht. Und deswegen ist da an der Stelle sind das noch zwei. Das ist ein Problem, was wir leider bis heute nicht gelöst haben. Elegant. Das heißt, wir haben zwar das Backup,

aber Restore geht leider sehr, sehr um den Weg. Wir müssen an der Stelle die QCore-Datei aus dem ZFS manuell rausnehmen, in die ISO-Domain legen und damit eine neue Maschine anlegen. Das ist nicht wirklich schön, muss man ganz ehrlich zugeben. Wir hoffen, dass wir da noch eine schönere Lösung finden, beziehungsweise falls jemand eine hat. Sehr gerne. Backup läuft über ein externe

Skript an der Stelle, was über die Rest-API funktioniert. Und wie in den meisten Fällen bei KVM, ich mache einen Snapshot, exportiere mir den Snapshot in ein eigenes Image und das eigene Image schreibe ich in meine Export-Domäne einfach weg. Genau. Soviel zum Thema Speicher an der Stelle.

Und da sind wir wieder Eiskasi, dem ist völlig egal. Der hat eine IP-Adresse, ob das hochverfügbar ist, wie viele dahinterstecken, das sieht er alles gar nicht. An der Stelle können ich halt auch beispielsweise G-Laster einbinden und auch diverse andere. Ich kann es jetzt gerade gar nicht aufzählen. Wichtigste Ansicht überhaupt natürlich. Ihr seht, das ist ein bisschen blurry, weil das halt natürlich in einer sicheren Umgebung ist

und natürlich viele Sachen davon nicht ganz public sein sollen. Ihr seht alles, was so an Statistiken ist. Ihr seht, wenn man den Maschinen, den Guest Agent installiert, sieht man sogar die IP-Adressen von denen. Man sieht die FQDNs, das wird alles angezeigt. Ich sehe, wo die laufen, auf welchem Host. Ich sehe, ob sie up oder down sind. Ich kann die Maschine einfach

mit einem Rechtsklick migrieren auf eine andere Maschine. Also ich kann entweder aus dem Host heraus sagen, migriere mir jetzt heißt mir alle weg, weil ich dich in Maintenance setze. Oder ich kann einzelne Maschinen von A nach B migrieren, wenn ich möchte. Alles, wie gesagt, völlig transparent. Ich kann neue Maschinen hier drüber installieren. Ich kann Snapshots hier drüber installieren. Ich kann das Netzwerk und so weiter und so fort. Ich kann alles über die grafische Oberfläche machen.

Und das ist die grafische Oberfläche für die Admins. Ich kann und das finde ich auch sehr schön für die Nutzer. Oberflächen gibt es eine Oberfläche. Das heißt, ich kann Nutzer. Das Ganze ist natürlich für ein professionelles Umfeld nicht ungewöhnlich an AD beziehungsweise LDAP anbindbar. Ich kann sagen OK, pass auf Nutzer John Doe. Du kriegst jetzt

Maschine XYZ zugewiesen und dann kannst du die selber starten. Du kannst sie selber runterfahren. Du kannst dir die Konsole darauf öffnen etc. Und ich kann sogar so weit gehen und kann sagen OK, John Doe, du hast ein Kontingent von 20 Gigabyte. Du hast 5 Gigabyte Arbeitsspeicher. Du hast deine Netzwerk Interfaces. Du hast so und so viele Ethernetz, ach quatsch, so und so viele

MAC Adressen zur Verfügung. Und dann mach damit, worauf du Bock hast. Setze die Maschinen auf, starte die neue, lösche die. Mir alles egal. Kannst du komplett selber verwalten. Nicht, dass ich wüsste. Das ist in dem Umfeld absolut uninteressant für uns. Aber es hat eine Restschnittstelle. Ich kann mir durchaus vorstellen, dass man da was anbinden könnte.

Genau. Also das ist so viel soweit zu dem zu dem System, mit dem Kontingent. Wie gesagt, ich finde das sehr, sehr schön an der Stelle. Wir haben halt in dem Umfeld auch wirklich, dass die Nutzer sagen Ja, ich möchte meine Maschine verwalten können etc. Das klappt wunderbar. Ich kann die Maschine zuweisen. Ich kann den Kontingent zuweisen. Gehen wir noch mal zurück zu unserem hoch verfügbaren Samba.

Wie man das hat, an der Stelle aufbauen würde. Gehen wir davon aus, wir haben wir hier jeweils oder vier Wirt-Hosts. Das sind nicht die Wirt-Store-Tschuldigungen, das sind Fehler. Das sind die Wirt-Hosts. Das ist kein Storage, sondern das sind die Virtualisierungs-Hosts. Die sind in der Stelle so eingemalt, weil die in dem Fall keine dedizierten 19 Zoll-Geräte sind, sondern das sind so zweieinhalb 19 Zoll-Geräte,

weil Supermicro heißen die Twins. Die sind immer in einem drin. Das heißt, wenn ein Host abstürzt, läuft der andere zwar weiter. Aber wenn ich die aus dem 19 Zoll-Schrank rausnehmen will, kann ich natürlich immer nur beide zusammen rausnehmen. Jetzt gehe ich hier und sage, okay, ich baue mir meine erste Samba-Maschine auf und sage, die läuft auf dem Wirt-Store 1 und ich kann einen Constraint festlegen und kann sagen, die darf nur auf 1 oder auf 2 laufen

auf keinem anderen Host. Mache das Ganze auch andersherum und sage, okay, die läuft auf 3 oder auf 4 und darf nur auf 3 oder auf 4 laufen, auf sonst keinem. Das heißt, ich habe die beiden. Die setze ich jetzt noch als HA-Modus auf, habe meinen Client, den ich darüber anbinde, den kann ich auch an mehrere anbinden und schon habe ich einen hochverfügbaren Samba aufgebaut, der mir, sofern mir nicht

das Datencenter komplett abfackelt, eigentlich immer laufen können sollte. Ich kann sogar hergehen, eine von denen runternehmen. Das war es schon fast von meiner Seite aus. Kurz zum Fazit. Hochverfügbarkeit, also mehr als 99 Prozent abzahlen ist möglich. Ich weiß nicht, wann unser Cluster das letzte Mal als solcher nicht funktioniert hat

und als es das letzte Mal war, war als es einen Stromausfall im gesamten Bezirk in Berlin gab. Georeplikation ist auch möglich. Das ganze System ist wunderbar skalierbar, hat auch den Vorteil, es kann mit Standard Hardware genutzt werden. Ich brauche also nicht zwangsläufig irgendwelche Fiber Channel

Geschichten oder ähnliches zu kaufen. Hat, das ist auch noch was Positives. Ich wollte gerade schon mit dem negativen Anfang ein Nutzerportal, ein Kontingent und das ist nämlich das, was ich nicht so schön finde. Der Horstausfall bedeutet, dass die VM neu gestartet werden muss. Da ist VMWare leider an der Stelle ein bisschen weiter. Die haben einen Modus, der nennt sich Fault Tolerance, wo eine virtuelle Maschine

auf einem Server läuft und auf dem anderen als Shadow mitläuft. Die kriegt sozusagen ständig ihren Arbeitsspeicher unterfüttert. Da sind wir bei dem Punkt Server HA versus Service HA. In den meisten Fällen reicht ja Service HA. Aber wenn es halt so ein Spezialfall gibt, wo die Maschine an sich nicht ausfallen kann, dann bin ich hier an dem Punkt, dass ich sagen muss, da hat leider VMWare noch einen Punkt,

den Overt an der Stelle zumindest meines Wissens nicht mitbringt. Und zu guter Letzt die Doku. Die Doku von Overt ist ein Indikator, auf welchen Mailing-Listen man mal gucken könnte, wenn man irgendwie zu etwas was sucht. Also die ist teilweise einfach schlichtweg falsch oder outdated.

Das ist wirklich etwas, was uns an Overt persönlich total stört. Die Doku ist einfach wirklich leider gar nicht zu gebrauchen. Das muss man leider sagen. Nichtsdestotrotz, tolle Software, wie ich finde, vollkommen zuverlässig. Und das war's von meiner Seite. Vielen Dank für eure Aufmerksamkeit zum Abend hin.

Habt ihr Fragen? Oh, da geht's los, dahinten. Georeplikation, das heißt, ich habe einen Datencenter in Berlin und das andere habe ich irgendwo, was heißt ich, in Afrika. Achso, ich sollte die Fragen wiederholen, Entschuldigung. Also die Frage ist, was Georeplikation ist. Georeplikation heißt, ich habe das irgendwie

eins in New York, eins in Berlin oder was das ich was verteilt. Also wirklich richtig weit auseinander, falls mir halt irgendwo ein Erdbeben das auseinanderreißt oder wie halt in dem Fall, den ich gerade beschrieben habe, die gesamte das gesamte Datencenter fällt aus, weil Strom ausfällt, die USV nicht anspringt, wie sie sollte. Dann fallen mir natürlich auch alle Schränke zusammen aus. Und dann habe ich natürlich an der Stelle ein kleines Problem.

Dafür gibt es halt die Georeplikation. Das ist natürlich klar, das löst es natürlich nicht für dich. Du kannst es über Waren lösen. Du kannst dir eine Dark Fiber mieten. Das ist natürlich wieder ein ganz anderes Problem, das du lösen musst. Aber Overt selber ist erst mal in der Lage, auch wirklich über verteilte Standorte

und das sozusagen auch bei seinen Algorithmen mit einzubeziehen, dass er sagt, OK, ich versuche mal eher sozusagen bei Ausfällen nah zu greifen, damit ich nicht von über das transatlantische Kabel halt so viel Daten transportieren muss, nehme ich erst mal statt Berlin auf einmal München oder Frankfurt und muss nicht irgendwie nach New York sofort gehen. Das ist, glaube ich, so die Hauptidee, die letztlich dabei steckt,

dass ich das auch eingeben kann in Overt, dass der damit umgehen kann. Frage oder Antwort? Habt ihr in dem Rahmen von Eisgasi zu Glaster gewechselt seit auch mal über Ceph nachgedacht? Nein. Also die Frage ist, ob wir über Ceph nachgedacht haben. Ja und nein. Also wir sind uns dessen bewusst,

dass es Ceph gibt. Wir haben bisher einfach gar keine Erfahrungen damit gesammelt. Wir haben, wie gesagt, früher ein bisschen Erfahrung mit G-Luster gemacht. Da beides aus dem Hause Red Hat kommt, verzahnen die das natürlich auch sehr gut, was die Einstiegshöhen für G-Luster oder Glaster sehr, sehr gering macht. Und an der Stelle es gibt einen Connector zu Ceph.

Das scheint auch zu funktionieren, aber wir persönlich haben gar keine Erfahrungen an der Stelle gemacht. Mit Treffing auch sage ich mal, ich habe jetzt so ein Newscast. Ich habe so eine Zeit in Marokko stehen und die nächste Zeit steht keine Ahnung in Irland und die nächste steht in Island und da habe ich noch eine irgendwo in Panama. So und in Marokko

ist gerade Reduktion. Die machen wir im Saal des Zentra Caput. Wie sieht es denn aus mit respektive Treffing? Weil ich will vielleicht, dass diese Storch-Dinger halt nur die Differenzen über die Farbe schicken und nicht den ganzen Treffing einmal oberdaten. Genau. Also die Frage war letztlich, wie sieht das beim Treffing aus mit dem Thema Georeplikation,

dass ich wirklich nur Minimaldaten übertrage. Dafür weise ich noch mal auf das, was ich eben zum Thema Georeplikation gesagt habe. Keine Erfahrung. Also da weiß ich leider auch nichts an der Stelle sozusagen, ob die da das irgendwie optimieren oder nicht. Also das Ganze ist vor zwei Jahren oder drei Jahren ist das, hat richtig eingestiegen die Sache. Seitdem tut sich da sehr, sehr viel, aber ich weiß nicht,

wo genau da der Status ist, was die genau da wie reingebracht haben. Weil wie gesagt, das ist für uns bisher kein Use Case gewesen. Die Verwendung wurde über IPsec oder VPN oder irgendwas gemacht oder? Zwischen den... Das kann ich dir auch nicht sagen an der Stelle. Aber theoretisch müsste ja eigentlich beides möglich oder alles möglich sein, weil es an dem an dem Punkt ist dem ja das Layer, was da drunter liegt, vollkommen egal.

Da lassen sich Server auch hinzufügen. Einfach... Frage soll ich nochmal wiederholen. Bei DABD ob sich da einfach die die Server hinzufügen müssen. Ich könnte natürlich jetzt sagen,

bei DABD ist nichts einfach. Das ist leider... Das ist halt einer der Gründe, warum DABD zwar gut funktioniert, aber es braucht schon eine gewisse Kenntnis. Es lassen sich zu begrenzt. Also DABD ist bis vor kurzer Zeit eigentlich auch nur in der Lage gewesen, zwei Server miteinander zu verbinden. Dann konnte man sozusagen zwei Server

und darüber noch einen dritten, wenn ich mich nicht ganz vertue. Aber die waren nicht darauf ausgelegt, so ähnlich wie wir das jetzt üblich bei G-Luster oder ähnliches haben, dass ich noch einfach einen Brick hinzufüge und sag so nach dem Motto, ich verteile das Ganze oder wie bei Seth. Das ist gar nicht die Idee von DABD gewesen, sondern die haben wirklich gesagt, wir haben zwei Stück und die werden miteinander verknüpft und ich kann halt noch einen dritten. Jetzt gibt es halt auch die Möglichkeit, das zu erweitern.

Das weiß ich nicht. Aber nicht in dem Sinne, wie sich Seth oder G-Luster verstehen, dass sie sagen, ich kann jetzt einfach beliebig viele Notes an die ganze Geschichte dran packen. Bei Heartbeat und Pacemaker und so sieht das ganz anders aus. Die können, ich glaube, bis zu 256 Stores Server oder beziehungsweise Geräte in einen Cluster mit reinpacken. Das ist auch einfach.

Ja, das funktioniert relativ straight forward. Ja, genau. Aber da muss man auch da muss man auch vorsichtig sein. Also auch da ist das, das sind wirklich sehr, sehr spezielle Funktionen an der ganzen Stelle, die nicht, also das ist nicht, ich sag mal, Level grafisches Frontend, sondern das ist Level. Ich muss mich wirklich vorher mit der Funktionalität auseinandergesetzt haben

und muss genau wissen, was ich an der Stelle tun, weil sonst mache ich mir so dieses typische ich schieße mir selber in den Fuß ganz schnell. So jetzt war irgendwo da hinten, hat sich noch jemand gemeldet. Du machst im Prinzip einen Snapshot, dann wiederum die Frage wiederholen.

Die Frage ist, wie sozusagen der Transfer auf den anderen funktioniert. Also letztlich funktioniert es darüber. Du machst auch der an der Stelle von dem Arbeitsspeicher einen Snapshot, überträgst das und dann überträgst du am Schluss das Delta von der ganzen Geschichte noch mal. Frage, so Sachen wie Freelance können Centerfest unterstützen.

Alles krass. Würdest du sowas für so ein Setup als Stoppage-Server? Also wer sich die Mühe macht, sowas wie Overt aufzusetzen, was sicherlich ein bisschen länger dauert, wenn man es halt ordentlich macht als irgendwie einen halben Nachmittag, der braucht meines Erachtens kein Freelance, sondern der kann sich auch direkt auf einem weiteren Server

das Ganze direkt aufs Betriebssystem installieren. Also wer sich die Mühe macht. ZFS. Ja, aber ZFS kann ja auch ZFS und Linux kann es ja auch ganz einfach installieren. Das ist ja auch relativ straight forward mittlerweile. Also kann ich es empfehlen? Kann ich es nicht empfehlen? Habe ich keine persönliche Meinung dazu, nur ich bin halt eher der Freund davon, dass ich mir nicht so viel Überbau dazuhole, sondern wenn ich sage,

ich nutze Lego Steine, dann nutze ich halt die tiefsten, die es dann halt möglichst gibt und versuche, die bestmöglich miteinander zu verzahnen. So, jetzt hatte ich eben irgendwo dahinten noch was gesehen, nicht mehr. Ja, die Story.

Also die Frage ist, wir haben Hypervisor und und Storage getrennt, ob es theoretisch möglich wäre. Ja, das wäre es an der Stelle mit DABD und iSCSI. Weiß ich es nicht mal. Mit G-Laster dürfte das gar kein Problem sein. Ich muss natürlich nur bedenken, dass ich mir dann entsprechend auch Netzwerk Interfaces

zur Verfügung stelle, wenn ich das, weil ich ja natürlich dann gleichzeitig von der VM zu ihrem Storage gehen muss, das gegebenenfalls sozusagen auf dem anderen Server liegt oder bei 50 Prozent der der Host auf dem anderen Server liegt und gleichzeitig das Ganze auch noch nach draußen geben muss für den Nutzer, der mit der Maschine kommuniziert. Das heißt, ich brauche dort natürlich erheblich mehr

Datenbandbreite, als wenn ich das sozusagen trenne. Weitere Fragen? Noch einer? Ja. Lassst du mit FreeBSD auf oder muss ich dafür die Nost haben? Weil mit FreeBSD könnte ich jetzt auch als Host... Nee, das läuft, wie ich eben schon sagte, das läuft sogar eigentlich nur mit den Red Hat-Derivaten.

Overt nutzt halt, also das nutzt auch... Ich weiß, weil es in der Doku steht, dass da KVM drin ist, aber du hast sonst, siehst du nicht, dass es KVM ist. Na ja, wenn es das war, dann vielen Dank nochmal und euch einen wunderschönen Abend und gute Heimreise.