 Ich bin der Minu und bei der Interessensschwerpunkt sind so ein bisschen Netzwerke, Hardware-Sachen. Ich trinke gerne Cocktails. Bitte, wenn ihr mehr Bier spendieren wollt, nehmt lieber einen Schunk. Habe ich auch gestern schon gesagt. Und so ein bisschen Hacken und Musik- und Lichttechnik. Interessiere mich. Warum mache ich den ZF-Vortrag für euch heute? Seit 2014 beschäftige ich mich mit ZF, weil ich das in meiner Firma, wo ich arbeite, aussiede aus Karlsruhe, einsetzte als Storage-Lösung für unsere Open-Stack-Cloud. Also wir haben das im Produktivbetrieb dort. Und seitdem haben wir einiges an Erfahrungen gesammelnden, was ZF angeht und was so die Sicherheit von ZF angeht. Und weil ich einfach eine coole Technologie finde, habe ich mir gedacht, halte ich heute auf der GPN mal einen Vortrag darüber. Um was geht es in dem Vortrag? Es gibt euch eine kurze Einführung ins Storage allgemein, was es da so gibt und wieso das funktioniert normalerweise. Dann über ZF und speziell natürlich die Basics von ZF, wo wir uns so unterhalten werden, die Verteilung von Daten innerhalb von ZF, die Sicherheit in dem Fall von ZF und am Ende noch ein bisschen Frage rum zur Einführung. Was ist in Storage im Allgemeinen? Naja im Allgemeinen habe ich jetzt schon in meinem Ankündigungstext geschrieben, das ist die Datenhalt. Also dahin schiebt man irgendwelche Daten, die man irgendwann wiederholen möchte oder nicht mehrholen möchte oder die man schnell wieder braucht und der Benutzer speichert also seine Daten auf diesen Medium, was auch üblich immer das aussieht. Und man kann jetzt sagen, in einem Anfangszenario mit eurer Computer vor Ort, hat man einen Benutzer, einen Speichermedium zum Beispiel, eine Festplatte und daraufhin werden die Daten gespeichert und abgerufen. Das ist jetzt aber nicht das klassische Storage-Fall, sondern es ist der Home-Use-Fall, den man da hat. Wenn man als Storage schriedet, meint meistens noch was anderes, nämlich man meint, dass man relativ viele Benutzer hat, die zusammen auf einen Speicher zugreifen möchten. Und in dem Fall spricht er meistens dann von einem Storage-Cluster, den man dafür benutzt. Erst recht, wenn man ganz schön viele Speichermedien hat. Also wenn man den Speicher zusammenfasst und ihn den ganzen Benutzern zur Verfügung stellen will, dann braucht man normalerweise ein Storage-Controller, der vorne dran agiert und der diese Anfragen annimmt von den Benutzern und dann ihnen sozusagen das zurückgibt, was sie haben möchten. Und hoffentlich auch nur das und nicht noch was anderes. Was hat es aber zur Folge? Umso mehr Benutzer manne hat, umso mehr Speichermedien man hat, dieser Storage-Controller wird immer größer. Also den Aufwand, den man da treiben muss, um vielen Benutzern Zugang zu so einem System zu ermöglichen, ist relativ groß und es gibt halt relativ viel Overhead in diesem Management davon. Nicht mehr so, also die Festdaten skalieren eigentlich ziemlich linear normalerweise mit dem Bedarf, aber so ein Storage-Controller skaliert ein bisschen anders meistens an den Stellen, wenn es viele Benutzer werden, weil er muss die Benutzer auch noch mitskalieren. Also man hat dann so eine gemeinsame Lösung, wo man normalerweise Speicher und mehrere Controller hat. Also Controller im Sinne von die Systeme, die die Datenanfragen weiterleiten an die Benutzer oder halt die Daten gegennehmen zum Speichern. Und in den größeren Storage-Lösungen, die es heutzutage da draußen gibt, man sieht das normalerweise immer darauf hinaus, dass man eben relativ viele von diesen Controller-Elementen hat, gegebenenfalls gleich viele wie die Speicherelemente, um die Last einfach zu verteilen auf dem gesamten System. Also man möchte nicht so Bottlenecks haben, obwohl es manche Storage-Systeme immer noch haben, wo man einfach das Problem hat, dass der Durchsatz an diesen Bottlenecks der limitierende Faktor ist, warum ich nicht mehr Festdaten dazuhängen kann oder mehr SSDs und so weiter. Also versucht man schon im moderneren Bereich eher so diesen Controller-Ansatz aufzusplitten in mehrere Controller. Und dann passiert oft das, wenn die Kunden oder wenn Leute das brauchen, dass sie dann schnell Rückzug zu properterer Software und properterer Hardware greifen, weil die eben diese Anforderungen erfüllt. Also man hat die Anforderungen der Benutzer, die verschiedene Protokolle erwarten, die wie sie irgendwie Daten kriegen wollen. Und man hat das Problem, wie die Manage bekommen. Und es gibt Open-Source-Möglichkeiten, das schon zu managen, die schon da waren. Und die ließen sich aber alle immer nicht so einfach konfigurieren. Also ich weiß nicht, ob ihr die DAB kennt und so weiter, zur Replikation von Daten oder zum Speichern von Daten. Das sind also relativ komplizierte Sachen, die auch im Zweifel nicht immer so laufen, wie man sich das vorstellt, wie man es erwartet von einem Storage-System. Viele Firmen greifen einfach zurück auf große Hersteller davon. Und dann hat man Wenderlock in und man kauft sich halt dumm und dämlich bei der Firma. Wenn man dann irgendwann auch nochmal weiter skalieren will, dann gibt es gar nicht die Option eigentlich, eine Open-Source-Lösung damit zu integrieren, weil das Wenderzeug klappt mit dem Wenderzeug. Und das war es dann. Also jetzt kommt aber Seth ins Spiel. Seth ist die Open-Source-Lösung, die versucht dieses Problem aufzulösen. Es ist in erster Linie Open-Source. Es gibt auch eine Firma, die sich mit diesem Projekt beschäftigt. InkChank heißt die. Die versucht so ein bisschen den Enterprise-Level dafür zu schaffen, indem sie Support anbietet. Aber hauptsächlich muss man sagen, in dem Projekt ist es Community-driven. Also man hat eigentlich ganz viele Entwickler, die sich daran beteiligen und hier Quotes beitragen. Es ist ein skalierbares System. Also Seth hat von Anfang an gesagt, wir müssen über mehrere Tausende an Festplatten skalieren können oder andere Medien skalieren können. Und das muss von Haus aus unterstützt werden. Da gibt es also nicht irgendwie, du kannst diesen Weg wählen, dann kannst du eben wie nur 10 installieren, 10 Festplatten nehmen, und du musst dann umswitschen auf einen anderen Weg, um dann zu 100 skalieren und zu 1000 skalieren. Sondern das muss relativ linear passieren an der Stelle. Und der Algorithmus, den Seth benutzt, stammt aus einer Forschungsarbeit. Also da hat sich nicht irgendjemand hingehockt und hat sich lange überlegt so, wie kann ich das irgendwie sinnvoll vermarkten, wie kann man das irgendwie sinnvoll mit unserer Hardware zusammendengeln und so. Sondern das war in erster Linie eine reine Forschungsarbeit, die darum ging, wie ich Daten verteilen kann über mehrere Systeme. Der Algorithmus hat ein paar Vorteile. Er bietet zum Beispiel den Vorteil, dass es keinen Single-Point auf Fehler gibt in dieser Lösung. Und er ist rein Software basiert an den Stellen. Also die Software kann man sich jederzeit auf einem normalen System installieren. Und er hat selbst kontrollierende Funktionen. Das heißt, er nimmt einem Arbeit ab, und darf an den Stellen, wo es zu Datenverlusten so weiter kommen könnte, wenn nicht agiert wird. Also man könnte so von Self-Healing, Technology reden, wäre das Passwort vielleicht dazu, die tatsächlich bei Seth, finde ich, auf einem gesunden Level implementiert ist, und man hat immer noch als Atmen aber genug Eingriffsmöglichkeiten, sich damit zu beschäftigen oder Sachen zu verändern und Einflussnahme zu haben auf den Algorithmus. Nun zu den Basics von Seth. Seth basiert aus diesen fünf Komponenten. An der untersten Ebene gibt es Rados. Und Rados beschreibt diesen Algorithmus, wie ich ihn vorhin definierte, im Hauptsinn. Also er beschreibt die Logikebene. Dann gibt es LibRados. Das ist die LibraryDionTop in allen möglichen Programmiersprachen Zugriff auf Rados implementiert. Und diese LibRados wiederum wird auch genutzt von Projekten, die weiter oben dran stehen, die in Seth mit eingebaut sind, nämlich dem Rados Gateway und dem Rados Block Device. Dazu erzähle ich euch später noch mehr. Und es gibt noch eine andere Implementierung, nämlich SethFS, wo ihr tatsächlich auch ein Filesystem bekommen könnt. Und wie man jetzt schon hier sieht, gibt es verschiedene Anwendungszwecke für diese unterschiedlichen Sysubsysteme. Das eine Mal will man mit einer Applikation damit reden. Das andere Mal möchte man mit einem VM sich dahin connecten oder mit einem Virtualisierer. Und das andere Mal kann man tatsächlich auch mit einem Betriebssystem Partitionen innen raunen. Das ist ein Problem in Seth. Dafür gibt es diese sogenannten OSDs. Und eine OSD ist ein Stück Software, was auf einem Storage Note ausgeführt wird. Und das kann die X86 Hardware sein. Mit Festplattenanschlüssen. Kein Rate Controller notwendig und so weiter. Und dort startet man ein OSD-Demon pro Festplatte. Und das funktioniert dann sozusagen als Datenspeicher in einem Rados-System. Und der übernimmt auch Aufgaben wie Replikation. Also dieses kleine Stück Software, was da vorne dran hängt, kümmern sich auch darum, dass deine Daten, wenn man sie repliziert, werden sollten. Wenn du z.B. 3-fache oder 4-fache Datenreduanz haben möchtest ausgrund der Ausfallsicherheit, dass diese Daten auch von einer OSD auf die andere OSD geschrieben werden. Und es übernimmt auch den Recovery-Fall. Also so schmal ist das Stück Software dann doch nicht mehr. Es wird dann auch hier tatsächlich unterstützt, dass wenn OSDs nicht mehr erreichbar werden, also mit der OSD meine ich Synonym OSD plus Festplatte, also wenn eines davon nicht mehr erreichbar wird, dann wird ein Recovery-Fall angestoßen. Da wurde algorithmisch sich dann darum kümmert, dass die Daten wieder hergestellt werden. Und in dem Fall, was damit auch teilweise zusammenhängt, ist Backfilling unterstützt. Das heißt, auch wenn ich später meinen Cluster größer skaliere, kann es sein, dass ich vielleicht auf OSDs Sachen ändern und bestimmte Daten dort nicht mehr residieren sollten, sondern umgelagert werden sollten und so weiter, und dass ich einfach an den Parametern tweekere und die OSD übernimmt es dann selber und kümmert sich selber um die Restrukturierung mit den anderen OSDs zusammen. Also es ist wirklich so ein Peer-to-Peer-Prinzip in den OSDs. Die kommunizieren relativ viel miteinander. Und darüber können sie dann auch sich rebalanzen, wenn es zu dem Fall kommen sollte, dass NVino Datenungleichheit existiert, dass auf einem System irgendwie 20 Gigabyte liegen auf einem anderen OSD. Und sie können sich auch gegenseitig monitoren. Also sie wissen auch über ihren Status Bescheid. Sie wissen auch darüber, wie viele OSDs gerade im System sind und wenn eine OSD stirbt. Zu dem ganzen System braucht man allerdings mindestens 2 Speichermedien. 2 SSDs, eine SSD, eine Festplatte. Meistens nimmt man 2 gleichgroße Festplatten dazu und die werden halt als OSDs eingebunden. Wie setzt so eine OSD aus im Detail? Man hat auf einer OSD den oberen Layer, der ist eben dieses OSD-Stück Software. Darunter gibt es ein File-System, was tatsächlich austauschbar ist, wo es mehrere Möglichkeiten gibt. Es gibt also ein paar Recommendations und Möglichkeiten von selbst, was man benutzen sollte, für was. Also zum Beispiel, wenn ihr das wirklich in Produktivbetrieb irgendwo betreiben wollt, solltet ihr vielleicht nicht X4 nehmen, da gibt es nämlich ein bisschen Probleme, sondern meistens ist es XFS, was für ein Produktivseinsatz da benutzt wird. Und dann gibt es unten drunter, unter diesem File-System Layer, gibt es dann die eigentlichen Festplatten. Und die Festplatten sind eben ganz normale Stangen Hardware. Also das ist ganz normal, was ihr einkaufen könnt überall. Das ist wirklich keine spezielle Anforderung daran. Und dann am Ende wird diese OSD in ein Gesamtcluster verbunden gebracht, oder diese OSDs. Also hier oben seht ihr den oberen Kasten, der Teil hier, das ist das, was man als Storage-Note bezeichnet. Und im unteren Bereich zieht ihr dann, wie so Storage-Notes nebeneinander liegen, also normalerweise im Rack übereinander stehen und damit das Storage-Cluster bilden. Und die liegt jetzt aber noch hier in dem Bild, diese kleinen schwarzen Kasten. Die haben eine andere Funktion in SEV. Und das sind die sogenannten Mons-Monitorer, die man hat. Und die tracken den Cluster-Status, der wichtig ist in so einem Distributed Storage-System. Du hast Cluster-Mitglieder, die natürlich verwaltet werden müssen, und du hast natürlich immer eine Status jedes einzelnen Cluster-Mitglieds, was verwaltet werden muss. Und dazu benutzt zur Meinungsfindung innerhalb von so einem Cluster, das ist SEV, ein Konsensus-Algorithmus, der die verteilten Entscheidungen ermöglicht. Also tatsächlich, dass hier Entscheidungen getroffen werden können, auch wenn tatsächlich OSDs wegfliegen, also OSDs oder Mons wegfliegen können, immer noch gewisserweise Mehrheiten gebildet werden und Entscheidungen getroffen werden. Das System bleibt nicht stehen. Von denen gibt es tatsächlich in einem Cluster relativ wenig. Also ich habe in dem Bild vorhin, war das Verhältnis wahrscheinlich irgendwie so 1 zu 10 zwischen OSDs und Monitoren. Und die haben auch tatsächlich nur diese Aufgabe, die ich jetzt beschrieben habe. Also es gibt keinen User-Zugriff. Das heißt, der Benutzer, der mit dem Storage interagiert, weil er irgendwie Daten davon dort bezieht, agiert nicht mit diesem System. Und sie kümmern sich wirklich nur konzentriert um diese Cluster-Status-Geschichten. Dann, was ich vorhin angesprochen habe, was es gibt, gibt Librados eben, was diese Sachen implementiert, die man braucht, um Zugriff auf diese Radus-Applikationen zu kriegen. Also alle Radus-Applikationen, die on top waren, in der Schaubild vorhin, die nutzen Librados normalerweise, außer CFFS. Und das ist eben so, es gibt das für jegliche Programmiersprache normalerweise an die Librados-Implimentierung. Also die gängige Programmiersprache, ich möchte jetzt nicht irgendwie uguk oder sowas hören. Und damit kann man effektiv direkten Zugriff auf die OSDs kriegen. Und da ist es auch ein fundamentaler Unterschied, den man wissen muss, wenn man mit CFF oder Radus redet. Man muss immer über dieses Protokoll mit Radus reden. Also ich habe hier wirklich ein Stück Software, was ich implementieren muss, in meiner Applikation oder da, wo ich es verwenden will, um mit einem CFFS zu reden. Weil dieses Stück Software ermöglicht mir, dass ich mit diesen OSDs, die ich vorhin angelegt habe, direkt reden kann und man auch darüber Statusinformationen abholen kann. Und selbst Entscheidungen treffen kann, wie zum Beispiel eben, oh, diese OSD ist nicht mehr erreichbar für mich. Deswegen probiere ich mal eine andere, weil die Daten sind repliziert auf dem gesamten OSDs. In dem Fall von Librados habe ich auch kein HDTP overhead, weil es gibt auch HDTP-Arpies innerhalb von CFFS und kann damit also relativ effizient darauf zugreifen. Die meistgängige Implimentierung ist halt die C-Implimentierung in der Stelle. So, das war jetzt prinsicherer zum Datenzugriff. Jetzt gibt es die Applikationen, die obendrauf gesetzt sind. Dazu zählt in erster Linie das Rados Gateway. Das Rados Gateway ist ein Object Storage. Object Storage, habe ich vorhin kurz schon in meinem OpenStack vortrag erklärt, aber ich erkläre es gerne nochmal. Object Storage steht davon, dass wir nicht das Dateisystem angucken, sondern wir gucken nur effektive Dateien an davon. Also, ich könnte sagen, Objekte. Deswegen Object Storage. Also, man guckt irgendwie eine Datei an. Es kann irgendwie geachtet sein, es kann im Film sein, es kann im Präsentation sein und so weiter. Und diese Datei möchte man dann speichern. Und dazu gibt es im CFF, das Rados Gateway, was eben ein Interface bietet auf HDTP-Ebene, um solche Daten speichern zu können. Und dafür gibt es ein Rest. Interface per HDTP, was wiederum mit diesem Rados Gateway redet, was wiederum unten runter mit LibRados redet, um dann die Daten in das Storage-Klasse einzubringen. Also, wir haben in diesem Rados Gateway diesen Rest-Proxy, wir haben ein Backend, und das ist Rados selbst, und wir haben eine API für Buckets und Accounts. Also, wenn man von einem Object Storage redet, gibt es auch den bekanntesten Object Storage, das ist wahrscheinlich Amazon S3. Da gibt es immer die Definition von, man hat ein Bucket, das heißt, also irgendwie Stumblebacken, wo die ganzen Objekte drin sind. Und darauf will man meistens Zugriff ermöglichen von unterschiedlichen Systemen her, und deswegen braucht man auch Accounts und Zugriffsrechte. Und an der Stelle hat auch SEV diese ganze Verwaltung eingebaut, um diese Zugriffsrechte zu realisieren und eben diese Buckets anlegen zu können. Und am Ende gibt es dann auch noch ein Feature, was oft gewünscht wird in der Art, nämlich das Accounting. Also, ich will auch dann im Ende tatsächlich abrechnen können, wie oft die Leute an Speicherler nutzen im Object Storage. Meistens im Emegabyte, Gigabyte, Tarabyte oder auch wie oft greifen sie auf alle Teilen zu. Also ist es eher so, dass das einmal gespeichert worden ist und dann nie wieder würzt worden ist, oder wird da regelmäßig hoch und runter geladen. Und an der Stelle, um es einfach integrierbarer zu machen in andere Systeme, ist dieses Rados Gateway auch S3 und Swift kompatibel. Swift ist ein OpenStack-Projekt, um Object Storage abzubilden und da integriert sich das schön. Aber auch eben S3-API, die von Amazon unterstützt wird, wird auch in Saves unterstützt direkt. Also man muss eine Applikation, wenn die schon S3 benutzen, nicht umbauen, damit sie mit dem Saves Cluster reden kann. Jetzt gibt es auch ein weiteres System, eine weitere Applikation, die oben drauf liegt, nämlich RBD. Das Rados Block Device. Hier reden wir jetzt von Block Storage. Block Storage ist der Unterschied eben hier, wir speichern nicht zu kleinere Dateien und sonst was, sondern wir speichern große Binary Blobs. Also wir wollen wirklich tatsächlich festplatten, abspeichern, um sie an VMs zu hängen und dann darauf die Software eben auszuführen zu können. Und dazu benutzen wir eben unser Self-Cluster, der aus vielen einzelnen Elementen, innerhalb des Self-Clusters, sogenannten Placement Groups, die sich hier ergeben, die Daten, die sie zusammensucht, die dieses Gesamt-Binary-Block ergeben. Also erst bitte dieses Gesamt-Binary-Block auf, in einzelne Subblöcke, die ihr dann verteilt im System. Wie ihr das macht und so weiter, das erkläre ich nachher noch. Und dann am Ende auf jeden Fall sucht ihr alle diese Daten zusammen, baut diesen einen Binary-Block, den ihr da braucht, innerhalb von Liberados und gibt das mit LibRBD an den Kernel weiter, der es einbinden kann. Auch das, wie wir es vorhin erwähnt haben, Software, also die LibRBD und LibRados, das muss auf den Betriebssystem, wo das in der Form benutzt wird, implementiert sein. Und hier hat eben dann das Betriebssystem, dass ich auch die Hoheit darüber mitzukriegen, wo in welchem Cluster, an welcher OSD gerade geredet werden muss. Also diese ganzen Punkte, die ihr unten seht, sind alles OSDs. Und da holt sich tatsächlich die virtuelle Maschine selbst die Daten raus. Das heißt auch, wenn da ein System nicht mehr erreichbar wird, wo es hingehen muss, um die anderen die Daten noch zu kriegen. Dann gibt es das Ganze auch noch als Kernelmodul, um sozusagen direkt Partitionen sowas einbinden zu können. Da gibt es KRWD. Und damit kann man auf jedem beliebigen System, also ohne dass man die ganze Partitionen nimmt und überselbst abbildet, kann man sich auch einzelne Partitionen darüber holen. Und das ist auch ein Feature, das im modernen Kernel inzwischen seitlich drinnen ist. Also ein Rados Block Device ist ein Festplattenabbild in erster Linie und speichert Festplattenabbilder. Man hat den Vorteil, dass man dann VMs losgelöst von Hosts hat. Das heißt, wenn ich jetzt eine Maschine habe, mit der ich mit LibRados und RBD mir ein Volumen eingebunden habe, dass tatsächlich diese Maschine sterben kann. Und ich kann dieses Volumen auf einem anderen System wieder etatschen und dann wieder das System hochfahren. Also ich schaffe es sozusagen, die Persistenten-Daten im Storage hinten zu halten. Und wenn es der Fall kommt, dass eben mir das System, was eigentlich diese betreibt, stirbt, dass ich es dann trotzdem rüber migrieren kann, natürlich mit dem Ausfall, auf ein anderes System. Dazu kann ich dieses Abbild, was da gebraucht wird, dieses Festplattenabbild, in meinem Cluster verteilt speichern. Das ist übernimmt sehr febend für einen. Das ist wirklich die Daten striped und schön gleichmäßig verteilt. Ich habe dann auch noch so Features, wie dass ich Snapshots habe, dass ich tatsächlich von diesen Volumes, die ich dort habe, also das ist das Volumen in der VM, einen Snapshot machen kann, der ziemlich instantan funktioniert in der Stelle und damit auch gar nicht das System im laufenden Betrieb bei einem Schluß, sondern einfach nur ein Abbild davon kriege. Und dazu unterstützt auch das System Rados Block Device selber Copy-On-Write-Mechanismen. Die ist auch ermöglichen, dass ich tatsächlich innerhalb von kürzester Zeit multiplis VMs mit dem selben Image hochfahren kann, weil ich Copy-On-Write mache, aber dazu gerne, dazu auch später mehr. Zur Unterstützung von wo Rados Block Device überall drin ist, ja, es ist im Kernet 2639 und aufwärts drin, also alles, was ihr mit drei Ehren was habt, das sollte ohne Probleme funktionieren. Aber auch andere Applikationen haben das eben, also nicht nur Kernel hat es implementiert, sondern Applikationen wie Goemon KVM, haben es schon eingebaut und in den Cloud-Lösungen, diese draußen gibt es OpenStack, CloudStack, Nebula, Proxmox gibt es Unterstützung dafür, dass man das benutzen kann. Rados und Box. Jetzt gibt es noch eine dritte Komponente, die ich vorhin bei den OSDs mit dem, was ich von Monitoren nicht erwähnt habe, das sind die MDS. Und die MDS sind die Metadatenserver innerhalb von einem Cef-Cluster. Und Metadatenserver, das sieht man hier unten wieder, man hat ein Cef-Cluster mit vielen OSDs, mit Monitoren und jetzt aber auch mit einem Metadatenserver oder sogar mehreren Metadatenservern. Diese Metadatenserver dienen zur Entlastung von seinem Cef-Cluster, wenn es darum geht, dass man direkt Fallsysteme Zugriff haben möchte, also das FFS besitzen möchte, also direkt sich an eine Partition rein mounten möchte. Und dafür speichern die Metadaten im Prozess kompatibel in Fallsystemformat. Und sie kennen Verzeichnissstrukturen, also sie wissen tatsächlich, wie Verzeichnisse aufgebaut sind und sie kennen auch die Metadaten, die normalerweise mit Dateien in Verzeichnissen anhergehen, Besitzer, Speicherzeit, Rechte und so weiter, die halt benötigt werden, damit man auch den Fallsystem hat. Das Problem ist, wenn das nicht über so einen Metadatenserver abgelegt werden würde, würde es heißen für ein Directorialisting mit LS, müsste ich einmal quer über alle OSDs drüber rennen und müsste mir irgendwie die Daten besorgen und müsste mir rausschreiben, wie die heißen und so weiter, das würde einen unheimlichen Load verursachen auf einem Cluster, auf ein historical Cluster. Und dafür benutzen sie eben spezielle Metadatenserver. Und die Metadaten selbst zum Speichern von dieser Metadaten. Und auch hier diese Komponente liefert keiner Datei Inhalte an User, also an Leute, die das benutzen. Also hier werden nur die Metadaten ausgelegt, hier werden keinerlei Daten getunkelt über dieselbe Verbindung. Und im Moment ist es eigentlich einziger Leinen, diese Metadaten können genutzt werden von anderen Fallsystems auch, aber im Moment das einzige Fallsystem, was das unterstützt, ist FFS. Also eine spezielle Fallsystem, wie klappt die Verteilung innerhalb von SEV? Es gibt die sogenannte Crush Map. Das ist eine der Haupt Bestandteile des Algorithmus. Und diese Algorithmus kriegt es erstmal Daten vorgeliefert, nämlich so ein Datenblop. Und darüber bildet der ein Hash. Und diesen Hash nimmt der Modulo die Nummer an Placement Groups. Jetzt muss man mal erklären, was Placement Group ist. Eine Placement Group sagt, wo diese Daten auf welchen OSD verteilt gespeichert werden sollen. Also es gibt zum Beispiel eine Placement Group, die sagt OSD1, OSD3, OSD5. Und das heißt, wenn jetzt Daten in diese Placement Group reingeschrieben werden, dann werden sie auf OSD1, OSD3 und OSD5 gespeichert. Das ist eine Indirektion, die der Kleint kennt. Das ist immer in Placement Groups rein. Also Liberalus schreibt nur in Placement Groups rein. Interessiert sich nicht dafür, was dann tatsächlich die Placement Group unten drunter tut, nämlich in welche OSDs sie reinschreibt. Sondern du gibst einfach den Liberalus in Placement Group vor und sagst ihm, hier ist der Placement Group, kannst du unsere Daten reinschreiben, schreib mal rein. Und dann übernimm ich das mal und verteil das mal im Storage Cluster richtig. Aber du kriegst eben keine Informationen darüber, wo sie in verteilt worden sind. Und in dem Fall jetzt, wo der Placement Group angekommen ist, zerteilt er das in solche Placement Groups. Das hier unten, die sie bunten, die hier sind alles Placement Groups. Und damit er eben die Anzahl der Placement Groups richtig hinkriegt, nimmt er eben monolo die Anzahl der Placement Groups, die oben da sind. Und durch den Herrsch hat er den Vorteil, dass er tatsächlich relativ, also nicht tatsächlich relativ, sondern auf jeden Fall eine stabile Placement Groups. Und der Crush Map bezeichnet dann den Zusammenschluss aus einer Placement Group mit einem Status und bestimmten Regeln, die man noch definieren kann. Und das ist dann die eigentliche Crush Map. Und die sagt jetzt eben, zum Beispiel in dem Fall, diese Placement Group 10, die erste Placement Group, die hier ist, die bin halt den binary blob 1.0 und der geht eben auf OSD 0 und auf OSD 7. Und wenn jetzt noch mehr solche Daten reinkommen, wie wir jetzt hier noch zum Beispiel sehen, dann verteilt er die eben auf andere OSDs. Die Placement Group ist eben, es stellt eben sicher die Placement Group, dass auf jeden Fall immer unterschiedliche OSDs benutzt werden. Das kann nicht sein, dass eine Placement Group dreimal aus derselben OSD das speichert, sondern das übernimmt wirklich die Sicherheit, dass es verteilt über die ganzen OSDs ist. Und diese sinnvolle Verteilung passiert über ein pseudo-randomisierten Algorithmus. Also diese Haschfunktion ist das eben nicht vorhin gemeint habe. Die ist sehr schnell und sie ist deterministisch unwiederholbar, was an dieser Stelle wichtig ist. Und sie ist halt auch eine statistisch-gleich-Verteilung. Und dadurch entstehen viele Zuweisungen, die sich auch seltenst verändern an den Stellen oder auch nur minimale Ausgleichungen brauchen. Und die Crush Map ist dadurch auch topologie-aware. Sie weiß tatsächlich, wo diese Daten liegen und wie sie die Daten umstrukturieren muss, wenn es zum Fehlerfall kommt. Und sie kennt eine definierbare Replikation. Bei einem Service System stellt man in der Crush Map ein, wie viel Replikation man haben möchte. Standardmäßig ist 2. Das kann man hochskalieren bis 10. Dann muss man halt dementsprechend viel Hardware reinstecken. Aber es kann es so halt eben auch auf 2 lassen und dann hast du einfach nur die Daten, die man in der CD hat im Zweifel keinen operativen Ausfall. Erst wenn die zweite OSD ausfällt, könnte es gegebenenfalls einen operativen Ausfall geben, wenn selbst nicht rechtzeitig die Daten wieder neu verteilen konnte. Und hier kommt dann auch ins Spiel, man kann Gewichtungen noch innerhalb von selbst definieren, um einfach zu ermöglichen, dass bestimmte Daten an bestimmten Stellen oft repliziert werden sollen oder auch unterschiedliche Storage-Medien unterstützen, wie SSDs und herkömmliche Festplatten voneinander zu trennen. Und da gibt es eben Gewichtungsparameter, die man definieren kann. Jetzt komme ich noch kurz zurück zum Thema Copy-on-Write. Bei Copy-on-Write habe ich einfach den großen Vorteil. Ich habe jetzt hier so eine Ubuntu Image. Das besteht aus 144 Objekten, die im Self gespeichert sind. Und diese 144 Objekte, die ich jetzt hier habe, die versuche ich jetzt in 3VMs, also ich versuche jetzt 4VMs zu starten, die exakt auch ein Ubuntu-System sind, also diese Ubuntu Image benutzen. Und im Normalfall führt es dazu, dass ich genau im Cluster diese Daten nur einmal habe und diese 4 Systeme, die da sind, sind nur als leere Hülle vorhanden und werden sich gemerkt, dass die Daten da benutzt werden. Das ist nicht dafür, wenn du Systeme startest, die auf Daten zugreifen, die bereits schon existieren und dupliziert die auch nicht. Auch wenn das eigenständige virtuelle Maschinen sind. Was er dann tut, ist, allerdings, wenn du schreibst, schreib der in diese Schablone rein. Und das sind dann effektiv Daten, wo du das System vorher verändert hast, die auch geschrieben werden müssen und die abgespeichert werden müssen. Weil du hast jetzt Veränderungen gemacht an der linken Seite hier, die da nicht vorhanden sind. Also hast du jetzt 144 in dem Rechenbeispiel plus 4 Sachen, die du verändert hast, also 148 Daten gespeichert. Wenn du jetzt hingehst und die Daten dann wieder lesen willst, dann liest der an unterschiedlichen Stellen, je nachdem, ob diese Daten schon mal benutzt worden, also schon mal verändert worden sind oder nicht. Wenn sie verändert worden sind, dann kannst du ja in dieses Basis-Image zu sagen, reingucken. Und kann die Daten dort nutzen. Und dadurch habe ich tatsächlich die Möglichkeit, dass ich in so einem Open-Stack-Cluster, so ein Cloud-Cluster, hingegen kann und kann 500 virtuelle Ubuntu's auf einmal starten. Und ich habe ziemlich innerhalb von ein paar Minuten diese Systeme oben. Ohne, dass ich vorher meinen Cluster überprüfen muss, ob er nicht gerade zu viel zu tun hat, dann gibt es da wirklich die Copy and Write-Mechanismen, die einfach für diese Anwendungsfalt, dass ich eigentlich immer ziemlich vom selben Image ausgehe oder vom Basis ausgehe, dort relativ effizient arbeiten kann. Und jetzt müssen wir noch mal kurz über die Metadaten reden, die ich vorhin gesprochen habe. Nämlich diese Metadaten, da hat man vorhin ein Bild. Also im Normalfall, wenn der Klein darauf zugreift, will er das haben, was zuletzt verändert worden ist. Also er will eigentlich das zugreifen können. Das bilden auch die gängigen Sachen dort nicht ab. Also Revision ist da eigentlich nicht eingebaut an der Stelle. Bei den Metadaten habe ich das Bild vorhin gezeigt, dass man eben diese Metadaten-Server hat. Und auch hier gibt es einen Skalierungsproblem, was man, was Self-Versuch zu lösen. Nämlich in so einem Cluster hat man mehrere Metadaten-Server, wenn man den Anspruch hat, Self-FS so was zu benutzen, statt nur einen. Und seit das man jetzt Bottlenecks hat in diesen Metadaten-Servern, wo vielleicht nur einer dann alle Anfragen beantwortet, hat man sich auch hier zu Gedanken gemacht, wie man das verteilen kann, wie man das besser tarieren kann in den Stellen. Und da ist man übergegangen dazu. Einfach in diesem Directory Tree, den man so kennt, also ein Verzeichnungsbaum, hinzugehen, einfach Subtrees daraus zu nehmen und auf die Metadaten-Server zu verteilen. Und wenn ein System per Self-FS Anfragen hat dann weiß das, zu welchem Sub-Tree es hin muss, weil es den Top- Stop-Element kennt und kann dann dementsprechend in diesem Sub-Tree selber nachgucken, ohne dass die anderen Bäume davon beeinflusst werden. Also man hat tatsächlich einen Zugriff, der dann eben von den restlichen beeinflusst ist. So, jetzt gibt es noch ein paar Worte zu Self und seiner Sicherheit. Self hat das Problem, wie jede Story-Schlösung eigentlich das Problem hat. Es will relativ schnell sein. Und das heißt im Normalfall auch, dass ich Verbindungen zwischen Clients, also Leute, die Daten anfragen und dem eigentlichen Cluster unverschlüsselt halte. Das heißt, die Daten, die hier fließend sind, komplett zu mitlesen und mitschneiden, weil ich eben nicht den Overhead haben möchte von Verschlüsselungen an diesen Stellen noch. Aber sie unterstützen Session-Tokens. Also bevor eine Kleint eine Verbindung aufbaut, baut identifiziert er sich und gegen den Keyring von dem Cluster und geht dann auch hin und kriegt einmaliges Token zurück für diese Operation und kann dann über dieses Token seine Daten eben erfragen und ein anderer ist damit ausgeschlossen. Es gibt keine meldende Mittel an der Stelle. Also diese Keyrings, die kommen aus dem Session Notes. Und da ist das Interessante daran, dass diese Keyrings halt da unverschlüsselt natürlich liegen. Und das heißt, wenn jemand Zugriff auf so ein System kriegt, kann er tatsächlich diesen Keyring exportieren und kann tatsächlich damit sich mit dem Cluster verbinden und vorgeben, irgendjemand zu sein. Also da muss man relativ viel Sicherheit darauf legen, dass diese Systeme nach außen hin dicht sind und dass da nicht jemand anders mit drin rum vorwärkt. Dann kann man auch Pool-Separierungen betreiben. Das ist ein Feature, was ich vorher noch nicht vorgestellt habe, was ZEV drin ist. Ich kann jetzt über den ZEV-Cluster auch einzelne Pools definieren, die mir für bestimmte Anforderungen den Service leisten. Das ist dann zum Beispiel ein Pool, der ist Hochperfomante, 40.000 IOPS, SSDs, und das andere ist COPS, SSDs in einem Pool zusammengefasst. Oder ein anderer Pool, der heißt langsamer Festplatten um Object Storage abzubilden und so weiter. Also ich kann diese Pools nehmen und ich kann es tatsächlich mit diesen Pools aber auch erreichen, dass Daten, die nicht vermischt werden sollten am besten, weil irgendwie hochsensibler Daten und weniger sensibler Daten, über diese Pools voneinander separiert werden. Weil die Pools gehen über die OSDs und sind damit also eine Separierung von den eigentlichen physikalischen Festplatten. Und noch ein Angespektor, den man auf jeden Fall nicht vergessen sollte, ist die S3 Swift API an der Stelle. Es gibt nämlich diesen Dienst den ZEV einfach nach außen hin schon zur Verfügung stellt meistens, weil es convenient ist, dass man diese S3 API per Web erreichen kann. Und die wird meistens verschlüsselt angeboten per SSL, das hat man auch schon manchmal gesehen, ohne SSL, und dort hat man eben die Daten hoch und geladen und runter geladen. Die einzige Sicherheit die man hat, wenn es nicht verschlüsselt ist, ist die Krypto, die Amazon geschrieben hat, als sie sich ihr S3 Protokoll ausgedacht hat. Vielleicht auch nicht unbedingt das Auflass, was man sich verlassen möchte. Und Swift API, es ist in einem OpenStack-Fall interessant, wo OpenStack darauf zugreift auf dieses Storage. Wenn es Objects Storage benötigt wird. Und ein Sander Angespektor auf jeden Fall im Chef ist auch DOS. Also Distributional of Service gibt es auch in einem Cluster. Kann man auch sehr gut in einem Cluster spielen. Aber so die interessantesten Angespektoren für DOS sind eigentlich so API Requests. Hammert man einfach mal 1000 API Requests pro Sekunde gegen den Server dagegen, mal gucken, was er tut. Auch wenn er vielleicht rejected, wenn er sagt, die Daten sind nicht da oder sonst was. Unten ein interessanter DOS ist, wenn man die Daten gegen einen Chef-Cluster gebaut ist. Man verursacht mal ordentlich IO-Lust. Wenn man sich überlegt, dass wie ich vorhin erklärt habe, dass diese Daten aufgespillt werden, also so eine Partition oder ein Fallsystem, nicht ein Fallsystem, eine virtuelle Festplatte, die angemountet wird an eine SVM, wenn man überlegt, dass das eben aufgespillt wird im Radus verteilt auf den Cluster, kann man relativ viel schlimmer IO-Lust verursachen, wenn man einfach kleine File Rights macht und immer wieder löscht und File Rights macht und löscht und so weiter. Also man verursacht damit einfach so eine hohe IO-Lust, dass im Zweifel halt die Replikation und sowas nicht mehr richtig funktioniert in meinem Cluster. Und da gibt es die Möglichkeit, das abzufangen. Aber genau an diesen Stellen wird auch noch tatsächlich viel gearbeitet, dass man das richtig hinkriegt und dass man auch so ein bisschen, ja, ich habe, ich schuldigung ein bisschen nicht verstanden. Wenn man ein Cef-Cluster liegen hat. Ah, danke. Das Fallsystem auf ein Cef-Cluster, wenn man das wirklich nutzt, muss man dann die Access-Time auch wirklich abschalten. Sonst zu viel Last erzeugt bei Lesen, wenn man viel sucht. Also eigentlich musst du es nicht abschalten. Also ich habe es jetzt noch nicht im Live-Betrieb gesehen, wo es ein Problem deswegen durchaus gab. Aber ich kann mir vorstellen, wenn du so 1000 Plus-Deployments machst, dann musst du solche Sachen überlegen. Aber in der Skalierung habe ich noch nicht das Problem gehabt. Aber bis jetzt hat sich das relativ noch Roman-Verhalten an den Stellen. Das ist nicht ein Problem gehabt. Aber ja, das Heißsystem darüber ist sehr entscheidend, wie ich am Anfang gesagt habe. Also wenn man damit ein X4 rumvorwerkt, dann kann man schnell an seine Limits kommen, weil das Fallsystem einen gewissen Overhead hat. Der gerade, wenn man dann noch eben kleine Files writes macht und reads macht, dass das schnell ein und die Ohren fliegt. Okay, dann macht es auch. Mikrofon. Danke. Ich frage mich, wie es aussieht mit Partitionstoleranz. Also wenn jetzt mir der Router, der mein Netzwerk zusammenhält, rausfällt und ich zwei Partitionen habe und dann eine Partition Group, andere Schreib-Eingänge bekommt als, also die gleiche Partition Group in getrennten Notes verschiedene Schreibanträge bekommt und somit in Konsistenz wird. Kann man sowas erkennen? Ja, also solche Split-Zustände. Dafür gibt es Erkennung in Self-Eingebaut, die eben die Anforderung ist zum Beispiel eben auch, dass man solche Self-Cluster deployet, dass man normalerweise in ungeraden OSDs arbeitet, um auch immer ein Quorum zu haben, mit dem man Entscheidungen treffen kann und das versucht eben auch immer die Liberados zu ermöglichen, warum gefunden werden kann und dass nicht passiert, dass eben unterschiedliche Zustände entstehen auf zwei Systemen, die dann nachher nicht mehr miteinander vereinbar sind. Also da gibt es Möglichkeiten dagegen zu mitigieren und ich habe bis jetzt auch nicht irgendwo gesehen, dass das dann schief gegangen ist. Ist das dann halbautomatisch oder muss man da manuell eingehen? Das ist automatisch, das ist das, was ich meinte vorhin mit, das übernimmt das Self-System selbst. Sehr cool, danke. So, hier vorne war noch noch eine Frage. Ja, ich hätte eine Frage zu CFFS. Kannst du was sagen, was da so die Stabilität, Zuverlässigkeit, Entwicklungsstand und so weiter angeht? Gute Frage. CFFS befindet sich immer noch nach meiner Meinung in der Beta-Phase. Also die Stabilität davon ist nicht sehr gut. Es gibt auch viele Überlegungen, das nochmal umzubauen und anders zu strukturieren, um eine stabilitäre Lösung zu finden, was CFFS heißt, sondern irgendwie noch mehr Sachen unterstützt. Also da würde ich prinzliche, ich finde es interessant, diesen Ansatz zu wählen, mit einem Fallsystem auf CF, aufzusetzen zu können, aber man würde ich ganz schwer davon abraten, das produktiv irgendwo einzusetzen. Stefan? Hier. Kannst du was dazu sagen, wie klein man, zuspeichende Objekte z.B. abmachen darf? Gibt es da irgendwie einen konstanten Overhead pro gespeicherten Objekt? Mal angenommen, ich hätte irgendwas zwischen 100 und 100 Byte und 10 Gigabyte zu speichern, ungefähr gleich verteilt. Kann ich das damit tun, ohne weiter nachdenken zu müssen? Also im Falle von großen Dateien gibt es eine gewisse Demetierung, dass man das auch konfigurieren kann. Damit das nicht allzu groß wird, weil das Thema ist, wenn er so eine große Teil annehmen muss, muss er die Auftrennung übernehmen und muss dann teilen in die Placement Group rein und die wiederum auf alle OSDs. Also da ist die Limiterung meistens die Placement Group Größe an der Stelle und da gibt es eben Parameter, um das noch zu tweaken, aber klar, der Overhead, der entsteht, wenn man so eine 64 Kilo sehr relativ groß. Und im Falle von Object Storage ist es performant technisch für den Cluster weit aus krasser, als wenn man über ein Block Device irgendwie 64 Byte dort verändert. Also da werden nicht mehrere Objekte zusammen in einen Bucket getan, bis der dann den Füllstand erreicht hat und dann der nächste Bucket angefangen oder so etwas. Nein, also es füllt einfach gleichmäßig über die Placement Groups auf. Da drüben war noch eine Frage. Wenn jetzt die einzelnen Demons oder untereinander Mehrheitsentscheidungen treffen, kriege ich dann nicht einen bottleneck, wenn ich sehr, sehr, sehr viele Festplatten mit jeweils einem Demon habe, weil die ja untereinander für die Große Anzahl Lutz auch sehr viele Mehrheitsentscheidungen treffen müssten, dann eigentlich nicht wenn ich zu ihrer eigenen Aufgabe komme? Ja, also die Chaterei, die sozusagen den OSD stattfindet, die wird natürlich umso größer Klaster, wird umso größer, so intensiver. Allerdings gibt es ja eben in diesem Klaster verbunden nicht nur die OSD, sondern es gibt auch noch die Monitorer, die da mit rein gehen und dann diese Systeme, also diese Mehrheitsentscheidung mit tragen auch und die Klaster-Starty überwachen. Und wenn man eben größere Klaster anlegt, kann man tatsächlich dann auch hingehen und kann dieses miteinander reden, beschränken auf bestimmte Teilbereiche und dann kann man damit sozusagen dagegen wirken, dass es nicht so groß wird. Also es gibt tatsächlich Self-Deployments, die gehen über mehrere Tausende OSDs. Ja. Kann man das dann auch auf mehrere Netze aufteilen, dass man sagt, hier Netz A darf nur ja geredet werden und Netz B ist dann nur für die da eigentlichen Daten zuständig? Das habe ich bis jetzt in der Art noch nicht gesehen. Also bis jetzt ist es eigentlich immer tatsächlich du hast ein separates Storage Network normalerweise, also eher eine Vorlandseparierung oder sowas, die dann dafür greift eben diesen Storage-Treffizier verwalten, aber das Chatten darüber findet eigentlich auch darunter statt. Ich schätze mal mit so ein paar Linux-Sportmitteln könntest du es hinkriegen, dass du tatsächlich auch diese Verkehrer auf unterschiedliche Interfaces auflegen kannst. Aber da nagest du mich nicht fest, das weiß ich nicht, das habe ich hier auch probiert. Das ist ein Fälle, die muss man dann selbst recoveren tatsächlich. Also im Falle von einem Metadatenausfall ist es gar nicht so schlimm, weil die Metadaten sind überall gleich verteilt. Also jeder weiß über alles zwar Bescheid, aber die Anfrage kommt halt nur immer für den speziellen Datenschutz. Das ist ein Fälle, das ist ein Fälle, aber die Anfrage kommt halt nur immer für den bestimmten Teilbereich an eine bestimmte Note. Also in dem Fall musst du wirklich tatsächlich eine händische Sache machen, dass du irgendwo einen neuen Metadaten-Service aufwitzst, das fixste System ich selbst. Nur so, um es abschätzen zu können, was neuer größter Cef-Cluster den ihr bisher aufgebaut habt, so ein Terabyte, Festplatten, Clients etc. Den Cef-Cluster, den wir im Betrieb haben, ist dreifach repliziert. Den wir im Betrieb haben. Das habe ich in der Präsentation nicht gezeigt, aber man kann auch Caching-Mechanismen einbauen, damit der Zugriff schneller funktioniert, gerade für diese Ride-Zyklen. Da haben wir auch SSDs verbaut und Gesamtfestplatten sind es im Moment, ich glaube 32 und 4 OSDs Das ist die Hälfte von dem, was wir in einem Not haben, deswegen. Danke. Wir haben 6 Notes oder so was und wir haben relativ wenig OSDs pro Festplatter reingehangen. Du meinest, die Library, die man lokal im Kleint einbindet, weiß mit welchen OSDs sie reden muss. Was hält mich davon ab, OSDs anzufragen, die mich nichts angehen, nicht meine Daten beinhalten? Ich würde mal sagen, dass da der Session-Mechanismus greift an der Stelle, der dich dann nicht darauf zugreifen lässt und auch glaubt, dass die Datenzugriff dann stichtweg ins Leere läuft. Die antwortet nicht darauf. Aber ich habe es nicht ausprobiert. Kannst du was zum Speicherverbrauch sagen? Wie viel braucht ein OSD, wie viel braucht ein Monitorinserver an Arbeitsspeicher? OSD ist eben so viel Speicher, wie man haben möchte, weil es eben das Datengrab, was man da aufmacht. Ah, Arbeitsspeicher. Zef hatte so ein paar grobe Vorgaben und die heißen normalerweise eine Dokumentation immer noch mit 1 Gigabyte angegeben pro OSD an Arbeitsspeicher, den man reservieren sollte. Also mal 8 OSDs, 8 Gigabyte. Ich benutze bei uns mit 2. 2 Gigabyte. Ich habe das allerdings auch noch nicht gesehen, dass das irgendwie da ein Speicherproblem gab an der Stelle. Und wir in dem Monitoring-System und so weiter, da haben wir glaube ich auch nur 8 Gigabyte gesamt für das System reingebohrt. Aber ob das wirklich notwendig ist, glaube ich nicht. Also es geht auch mit weiter aus weniger an der Stelle. Man hat mit der Datensaufe gegeben, falls mit mehr. Also das da war es, glaube ich, da haben wir 16. Ich hätte noch eine Anmerkung, falls jemand mit Python und RBD rumspielen will. Wir haben im Checkspace mal ein Projekt angefangen, einen Binary-Paste-Bin in Python zu implementieren. Da kann man also nicht nur Text reinschmeißen, da kann man auch Bilder, Filme, alles Mögliche reinschmeißen. Und der hat auch ein Chef-Backend. Also wo mit RBD arbeitet ist allerdings momentan noch ein bisschen nachbesserungswürdig. Also wenn sich jemand damit beschäftigen will, wäre ein Projekt. Okay. Inwiefern unterstützt Zef Multi-Fahrt-Io, also sei es für Verfügbarkeit oder auch Performance? Noch mal bitte, welche Technologie? Multi-Fahrt-Io, dass ich von mehreren Quellen gleichzeitig lesen kann, falls eine ausfällt beziehungsweise auch zu Performance-Zwecken eventuell ratemäßig von mehreren zu lesen. Im konkreten Fall diese Technologie, keine Ahnung, ehrlich gesagt, weiß ich nicht. Es kommen immer noch mehr und mehr. Also aber vorhin die Frage kam, was sind die großen Setups? Also ich weiß, dass wir auf Arbeit irgendwie zwei Peter bei den Zef-Nots haben in alles SSDs. Das geht schon ganz gut. Ich weiß zwar nicht, wie genau das gebaut ist, das kann sich rausfinden. Ich weiß noch, dass die immer mehr Netzwerk wollen. Ja, Netzwerkung riecht ist das System auf jeden Fall. Also zum Beispiel auch, dass es genau das große Ding zwischen Historik-Nauts sollte man auf jeden Fall 10, 40 Gigabit Verbindungen bauen, dann danke.