 Guten Morgen erst mal. Ich finde es toll, dass es so viele heute Morgen aus dem Bett geschafft haben, hierher noch in den Talk oder vielleicht wartet gar nicht im Bett, kann ja auch sein. Auf jeden Fall. Ich hätte gedacht, das ist komplett leer, aber es gibt doch ein paar Leute, die sich scheinbar so früh morgens dafür interessieren. Also das ist der Talk heute über OpenStack. Gestern hatte ich einen Dippe-Docker gehalten und ich mache noch kurz die Ankündigungen in vier Stunden halte ich einen Dippe-Seph. Was auch OpenStack verwandt ist, also die Historischlösung für OpenStack. Also werden euch das noch weiter interessiert. Kommt später noch in den Talk. Ja, dann würde ich sagen, geht's mal los. Also nochmal kurz zu meiner Person, ich habe es mich gestern schon mal vorgestellt, aber ich sitze wahrscheinlich neue Leute, die die Vorstellungen gestern nicht bekommen haben. Ich bin Mino und mein Interessengebiet sind so hauptsächlich Netzwerke. Was alles damit zu tun hat, ich arbeite auch in der Netzwerk-Company. Viel mit Hardware, Hacken natürlich und Musik- und Lichttechnik sind so meine Fachbereiche. Aber beruflich verbinde ich auch noch Sachen, die mir Spaß machen damit und da ist zum Beispiel OpenStack jetzt ein Teil davon. Und ich arbeite hier von der Company in Karlsruhe, die nennt sich Ocido. Und warum es mich zu OpenStack gebracht hat, war, ob sich die Arbeit dort, weil wir dann eine Cloud-Lösung gesucht haben für unsere Firma und 2014 haben wir uns entschieden OpenStack zu benutzen und ich habe dann auch die zwei letzten Summits des OpenStacks von OpenStack besucht, der eine war in Paris, der andere war in Vancouver jetzt vor drei Wochen und wir nutzen das effektiv jetzt zwischenseitig als produtive Cloud bei uns. Also, das ist auch ein bisschen die Erfahrungen aus unserem produtiven Einsatz. Was ich heute euch heute vorstellen möchte in dem Bereich, also erst mal eine Einführung, was ist OpenStack generell und was ist Cloud im generellen? Dann die Geschichte zu OpenStack, wie ist das Projekt entstanden, ist auch ein relativ junges Projekt eigentlich. Dann erkläre ich euch was zu den Komponenten, die in OpenStack wichtig sind, speziellen die Kernkomponenten und natürlich aber auch Extras. Dann ein ganz wichtiger Punkt in der Cloud ist die API-Fähigkeit. Da erzähle ich auch ein bisschen was zu OpenStack und warum das so mächtig ist in den Stellen. Dann reden wir kurz über die Installation von einem OpenStack Setup. OpenStack ist nämlich keine einfache Lösung, sondern sehr komplex. Und da ist es manchmal sehr hilfreich, das nicht alles zu Fuß zu tun, sondern auch gerne mit Werkzeugen, die einen dabei unterstützen. Da gibt es unterschiedliche Arten davon. Dann zum Thema Sicherheit, auch ein Teilbereich in OpenStack, was für Probleme es da gibt und wie man die mitigieren kann und was man gerne mal auf einem Public Cloud ausprobieren sollte, bevor man sie benutzt. Dann erzähle ich noch kurz was zur OpenStack Foundation. Dann erzähle ich noch was zur OpenStack Foundation. Ja, es ist ein bisschen so der Versuch, die Apache Foundation zu kopieren. Aber naja, sie sind auch sehr in Anfängen und sind sehr kommerzbedastet. Und dann am Ende gibt es noch eine kurze Fragerunde. Also zur Einführung, was OpenStack ist. Die Folien gibt es online, ihr müsst sie nicht fotografieren. Also OpenStack, OpenStack von Wikipedia, mal die Definition rausgeholt. Natürlich von der englischen Wikipedia. Ich denke, für deutsche Wikipedia existiert der Artikel wahrscheinlich schon gar nicht mehr. Auf jeden Fall, in der englischen Wikipedia steht drin, dass OpenStack is a free and open source cloud computing software platform, users privately deployed as an infrastructure as a service, IAS solution. Ja, da schickt es ein Buzzer drin, was so in diesen ganzen Cloud-Thema oft benutzt wird, nämlich IAAAS. Dieses AAAAS-Zeug, das verfolgt euch, wenn ihr mit den Clouds zu tun habt. Das verfolgt euch überall. Und irgendwie, wenn man heutzutage mit irgendeinem Cloud-Konsultant oder sowas redet, dann schmeißt er nur so mit solchen Wörtern um sich. Und ich empfehle nur solche Cloud-Bingo-Karten, wo man so IAS und andere Wörter drauf hat, wie High Availability und Zero-Touch-Deployment und sowas Begriffe, die da gerne benutzt werden. Also, um als es zu erklären, was in diesem Cloud-Bingo benutzt wird, würde ich kurz eine Einführung geben in SS Service, was es im Allgemeinen heißt. Ja, im Oldschool-Fall hat man früher so irgendwie eine Applikation gehabt. Da hat man so Daten für eine Applikation gehabt. Da hast du ein Runtime-Environment gehabt. Du hattest eine Mittelwehr, auf der das Ganze lief, ein Betriebssystem. Unten drunter hast du vielleicht noch ein Virtualisierungs-Layer gehabt, so wenn du EMW ganz hip und modern warst oder auch nicht. Und du hast ein Server gehabt und der hat Speicher- und Netzwerkzugriff gehabt. Ja. Das heißt, du hast die volle Kontrolle. Also, du als Kunde oder dujenige, der den Server besitzt, hat die volle Kontrolle über das, was da steht. Du hast also die Möglichkeit jederzeit in all diesen komponenten Sachen zu verändern und auch dementsprechend bist du zuständig für die Wartung davon. Jetzt gehen wir einmal ins andere Extrem. Jetzt gehen wir mal rüber zu Software-SS Service. Software-SS Service ist dieser ganze Stack, nur dass du da als Kunde effektiv nichts mehr mitzutun hast. Der Anbieter kontrolliert das komplett für dich. Also, du kriegst eine Applikation, du kriegst sozusagen die GUI oder das Webinterface und auf diesem Webinterface darfst du arbeiten und darfst du auch Veränderungen machen, aber du hast effektiv nichts mit dem Code zu tun, du hast nichts mit dem Betriebssystem unten drunter zu tun, du hast nichts mit der Hardware zu tun, du weißt meistens auch gar nicht, wo das läuft, wie das läuft. Und die Kontrolle liegt eben komplett außerhalb deiner Hand. Du bist lediglich für die Daten teilweise mit verantwortlich, die da drin liegen. Aber selbst da machst du dir keine Gedanken über Datenstrukturen und so weiter. Jetzt gibt es dieses Infrastructure-SS Service. Bei dem Infrastructure-SS Service gibt es diesen ersten Block, wie es in dem Old-School-Teil auch gibt und auch im Riechen Software-SS Service-Teil gibt, den effektiv du unter Kontrolle hast. Also, die Applikationen, die Daten, die Runtime, die Mittelware, das Betriebssystem sind dein Bereich. Das gibt dir sozusagen der Infrastructure-SS Service Anbieter und lässt es dich gestalten, wie du möchtest. Du kriegst von ihm sozusagen nur die unteren Ebenen. Du kriegst also in zweifeln Warnowweise die Verteidigung zur Verfügung gestellt. Du kriegst ein Server, also dieses Server-Plattform wird verwaltet von dem Atmen dort. Der hat Speicherzugriff, Netzwerkzugriff, aber das hast du halt nichts zu tun, weil dein Betriebssystem installierst du einfach auf der Kiste und das wars. Jetzt gibt es auch das dritte im Bunde, SS Service. Es gibt es auch tatsächlich viel mehr, aber ich beschränke mich mal auf diese drei, nämlich Plattform-SS Service. Und da ist es so, dass du nur Zugriff hast auf die Applikationen, die Daten, die du verwaltest und der Rest wird auch für dich gemanagt. Also auch das kriegst du von deinem Anbieter gewartet und so weiter. Und jetzt mal, um dem irgendwie mal Leben einzuhauchen, weil diese Begriffe ja so schön sind, kann man mal so ein bisschen der Old School Begriffe dazu benutzen. Nämlich beim Old School Sachen hast du so ein Location-Rechenzentrum, also dein Data-Center. Bei Infrastructure Service, das war so ein Rout-Server früher mal war, du hast irgendwie ein Rout-Server dir gemietet, also hast du die Kontrolle gehabt über das Betriebssystem, was du darauf installieren konntest und alles aufwärts, aber um das Server auszutauschen musstest du schon an den Anbieter wenden. Bei Plattform-SS Service, das ist das alte, gute, alte Web-Posting-Paket, was man sich mal gemietet hat bei Stratto oder sonst wer. Und dort hat man eben, dort hat man sich deine Web-Applikation installiert, aber das heißt, man hat nur die Applikation in die Daten verwaltet an der Stelle. Und meistens hat man auch noch so beschränkte Zugriffmöglichkeiten gehabt wie FDP. Oder es gibt Software-SS Service und da ist der Fall in der Webshop zum Beispiel, heutzutage kaufen sich viele kleine Unternehmen, kaufen sich Webshops eingemanagt, das heißt, die hacken noch ihre Datenbestände rein, welche Produkte sie verkaufen wollen und der Rest, wie der Webshop aufgebaut ist, welches Software benutzt wird, X-Tier-Commerce und so weiter, wie sie alle heißen, das ist nicht mehr dein Problem und zweifel kriegst du sogar auch noch irgendwie eine Design-Agentur nebendran, die dir irgendwie noch schöne Grafiken bastelt und so. Genau, Infrastructure-SS Service, wollen wir mal konkret in uns angucken. Also nochmal diese Unterscheidungen zwischen diesen zwei Bereichen, den oberen Teil, den du verwaltest, den unteren Teil, den der Anbieter für dich verwaltet oder der Cloudbetreiber. Diese Verwaltung des unteren Teils, dafür gibt es mehrere Möglichkeiten, die es zu tun. Und die gängigsten oder bekanntesten Möglichkeiten, die gerade draußen im Internet existieren, sind OpenStack auf der einen Seite, also Open Source Produkt. Aber natürlich gibt es auch kommerzielle Lösungen dafür. Und da im Speziellen kommt Amazon mit Amazon Web Services ins Spiel, die diesen Dienst anbieten mit EC2. Sie bieten noch viel mehr an als das, also sie bieten auch alles, Platform-Assert-Service und so weiter an, aber du kriegst halt auch hart, also sozusagen virtualisierte Maschinen, die du selber professionieren kannst. Und da gibt es doch so einen Hybriden dazwischen drin, das ist die Google Cloud-Plattform, die macht auch sowas, auch kommerziell, bei dem man auch alle unterschiedlichen AHS-Produkte kriegt, aber tatsächlich auch einen Teil, der so aussieht, dass man die Virtualisierung, auf der Virtualisierung selber kontrolliert. Es gibt auch viel mehr da draußen, aber das sind so die Großen, wenn man sich damit beschäftigt und wenn man sich umguckt, es gibt im US, also gerade im US gibt es noch gleichgroße, so zu sagen, wie Amazon, so die unterschiedliche Sachen einsetzen. Die bauen aber meistens auf, also die Anbieter bauen meistens auf, entweder OpenStack oder den AWS-Service und so was machen und reselling davon. CloudStack ist das nicht auch? OpenStack ist auch OpenStack? Ja, CloudStack ist auch OpenStack, aber von der Verbreitung her ist es tatsächlich OpenStack, momentan gerade das größte OpenStack-Projekt in der Stille. Also CloudStack hat auch von der Historie ein bisschen eine älterere Geschichte als OpenStack und OpenStack hat sich viel davon angeguckt, aber so der Hype ist gerade um das OpenStack-Projekt entstanden und da geht eh nichts mehr. Da war glaube ich letzter Komitee ein wie vor einem Jahr. Also es gibt so andere Randprojekte noch, aber hauptsächlich in dem Talk gerichtet eben auf OpenStack eine Live-Zeike von Ressourcen. Also normalerweise, wenn man sich so eine Server-Farm zulegt, dann passiert das in erster Linie mal dadurch, dass es einen Bedarf gibt. Also dass irgendwie in der Company man ein Internet-Dienstleister ist, also die IT-Abteilung der Admin oder man natürlich für externes Anbieter als Service und das heißt derjenige hat erstmal das Bedürfnis, irgendwelche Ressourcen von einem zu bekommen. Dann gibt es normalerweise die Phase der Bereitstellung, wo man die Ressourcen zur Verfügung stellt. Das passiert oft das in Unternehmen, wenn es für die internen Entwickler oder interne QA ist, passiert das meistens manuell diese Bereitstellung und dann gibt es die aktive Nutzung dieser Ressourcen, die man requested hat. Und wenn man Glück hat, gibt es noch so was wie eine Rückgabe am Ende, sondern Recycling, dass man das Ganze wieder zurückführt. Das heißt, dass die Ressource, wenn sie nicht mehr gebraucht wird, wenn das Projekt, was da drauf lief, nicht mehr funktioniert entweder oder nicht mehr gebraucht wird, dann gibt man die Ressource wieder zurück und kann sie hoffentlich dann anderweitig verwenden, wenn sie nicht gerade komplett veraltet ist, die Hardware oder so. Das ist interessant. Im klassischen Fall muss ich ehrlich sagen, was ich draußen sehe, ist meistens dieser Schritt, das Recycling ist nicht da. Sondern es wird Hardware gekauft und es werden irgendwie Computer-Resourcen geschaffen, um Sachen zu verarbeiten und dann wird das irgendwie was drauf installiert oder teilweise nicht mal was drauf installiert, dann liegt es einfach nur rum. Und irgendwann kommt mal jemand vorbei und sagt, da ist Hardware, kann die weg und dann sagt man, ja, ich glaube, das ist tot. Und dann sieht man Stecker und dann plötzlich fällt der Webshop aus. Also, oft passiert gerade so diese ganze Verwaltung darum, also dieses Management, diese Ressourcen zu verwalten in IT-Abteilungen usw. ist ziemlich schwierig und passiert tatsächlich in kleinen Unternehmen fast gar nicht oder in größeren Unternehmen durchaus öfter. Obwohl ich denke, gerade in kleinen Unternehmen ist das ein großer Kostenfaktor, wenn man so eine Bereitstellung hat, dann kann das manchmal in manchen Firmen eine Minute dauern, bis so eine Ressource verfügbar ist. Es kann aber auch ein halbes Jahr dauern, das geht gar nicht. Dann sagt der Atmen einfach, nee, da habe ich keinen Platz dafür, macht das mal irgendwo anders oder sowas, dann passiert nix, keine Zeit. Ja, das gibt es einfach nicht. Bei der Nutzung wiederum gibt es Fälle, wo es normalerweise so von einem Monat bis fünf Jahre geht, wo dieses System genutzt wird. Es kann natürlich auch eine Woche gehen, weil es kurz irgendwie für eine Messe, was installiert werden muss und dann wird alles zusammengefrickelt und dann wird das System dastehen gelassen und es kümmert sich keine mehr darum. Oder es gibt tatsächlich Produktivsysteme, die laufen sehr lange und um die muss ich auch natürlich jemand kümmern. Und dann gibt es die Rückgabe, wie ich vorhin gesagt habe, die passiert eigentlich nie bis selten in den Unternehmen. Wie ist es jetzt, wenn wir uns mal in der Cloud angucken? Die Cloud-Ressourcen-Nutzung an der Stelle. Von der Zeit her ist es meistens so, dass die Bereitstellung eine Minute bis 20 Minuten dauert, je nachdem, wie groß diese Instanz ist oder diese Computer-Ressourcen, die man braucht. Also bei Amazon, man sich so eine riesige XXL, keine Ahnung, was Maschine geklickt hat, kann ja schon mal 10 Minuten vergehen, weil die dann noch irgendwie im Bergwerk faszinierende Sachen machen müssen, damit das funktioniert. Aber es kann auch natürlich blitzschnell gehen. Die Nutzung ist auch dieselbe wie vorher, kann wieder sein, dass es kurz benutzt wird, kann sein, dass es lange benutzt wird. Bei der Rückgabe ist es interessant, die meisten Cloud-Provider bauen ein Accounting ein, also eine Abrechnung, um deine Verbrauch, den du an Computer-Ressourcen genutzt hast oder an Speicher und so was, dir zu berechnen. Und dann entsteht das interessante Phänomen, dass Leute ganz plötzlich, ganz schnell ihr Zeug wieder zurückgeben, wenn sie es nicht mehr brauchen. Das ist ja Geld. In der internen IT oder sowas, mit ihnen in den Firmen, da machten sich die meisten Leute nicht wirklich viel Gedanken darüber. Es hat ja am Anfang mal Geld gekostet, jetzt das Strom und so, ach, egal. Aber in Wirklichkeit ist es halt so in der Cloud, die Leute geben das wieder zurück, weil es ihr Geld kostet. Und auch da ist eine Cloud-Lösung an sich, was ganz Interessantes, weil die meisten Cloud-Lösungen, auch wenn sie privat eingesetzt haben, als Private Cloud, dann haben sie so wie in Accounting drin, was relativ gut zeigt. Übrigens, der Benutzer so und so, verbraucht ihr gerade zehn virtuelle Maschinen mit so und so viel Speicher und so und so viel RAM. Vielleicht sollte man mal mit ihm reden, ob man das wirklich braucht. Ja. Jetzt kommen wir zur OpenStack, was OpenStack da eigentlich ist und wie OpenStack funktioniert. Also OpenStack ist Apache 2-lizenziert, hat einen sehr rigorosen, sechsmonatigen Release-Zyklus. Das heißt wirklich, alle sechs Monate kommt ein Major Release raus. Und die Schlagzahl an Features, die in diesen Releases mitkommen, ist irgendwie gefühlt exponentiell an der Stelle. Also das heißt, wenn man in sechs Monaten, also wenn man sechs Monate gebraucht hat, um seine Cloud in Betrieb zu nehmen, kann es schon durchaus sein, dass man von da vorne anfangen kann, um ein Update zu schippen. Ist manchmal frustrierend. Auf der anderen Seite führt es aber auch dazu, dass tatsächlich die Clouds, die mit OpenStack aufgesetzt sind und die da draußen sich befinden und die auch als Service angeboten werden, teilweise mit Releases von vor zwei Jahren laufen. Die haben zwar nicht den Feature-Umpfang, aber tatsächlich sind sie relativ stabil an den Stellen. Weil natürlich sechs Monate Release-Zyklus heißt auch, in sechs Monaten müssen diese neuen Features irgendwie getestet werden. Und das ist meistens ein Prozess, der nicht in sechs Monaten abgedeckt werden kann, wenn nicht von vornherein schon Unitests und alles Mögliche geschrieben worden sind. Also meistens entwickelt sich daraus sechs Monate, dass ein Feature kommt und dann braucht es meistens nochmal ein Release, bis es dann mal stabil ist. Der ganze Coach von OpenStack ist auf GitHub. Auf viele Repositories aufgeteilt. Es gibt nicht das Repository, das wäre viel zu gigantisch, sondern es sind ganz viele Einzelprojekte, die dort auf GitHub gehostet werden. Das OpenStack-Projekt hat eine Quilty-Struktur, die Sie, wie ich vorhin erwähnte, versuchen anzulehnen an die Apache Foundation jetzt nach und nach, weil Sie merken, Ihre eigenen Überlegungen skalieren nicht. Aber im Moment sieht es so aus, dass es PTLs gibt, das sind die Projectleads für die einzelnen Bereiche in OpenStack. Und es gibt diese, die gesamten Designsummits. Also es gibt diesen sechs, im sechs Monatzyklus, wie es auch Releases gibt, gibt es immer einen Summit. Das ist eine Treffung, die auf der Welt weltweit immer an einem anderen Ort stattfindet. Anschließend an die Konferenz, die eigentliche OpenStack-Konferenz, wo alle Hersteller ihr Zeug präsentieren, gibt es dann auch einen Design Summit, wo man dann als Code Contributor mit hingehen kann und kann tatsächlich in den Meetings mit drin sitzen, die darüber entscheiden, wo die Groberichtlinie hingeht für das Projekt. Und auch seine eigenen Ideen vorstellen und diskutieren lassen. Also die machen relativ viel Diskussion auch über IAC und so weiter, natürlich, aber es gibt diese halbjährigen Treffen, wo sich die Community dann auch immer trefft. Wie ich gesagt habe beim GitHub, es gibt viele Repositories, das heißt, es gibt auch ein modulares Design in der Stelle. Also es gibt, OpenStack besteht aus ganz vielen einzelnen Komponenten, die sich durch ihre API gegenseitig abgrenzen. Und es ist hauptsächlich Python. Also man muss sagen, sie benutzen viele, viel Code an Stellen, da natürlich ein C und so weiter implementiert ist, der uns die Individualisierung kümmert von Systemen und so weiter. Aber aller Glucode, der zwischendrin geschrieben ist, ist eigentlich Python. Und wenn du da als Programmierer reinkommst und denkst dir, hm, ich kann aber Python nicht so gut. Ich würde irgendwie mal lieber sowas machen mit Java oder mit Go oder sonst das, dann verteufen die dich meistens. Weil sie sagen gerne, unsere Codebase ist schon Python. Eigentlich haben wir kein striktes Requirement dafür, aber es wäre schon cool, wenn du Python machen würdest. Es ist im Moment so ein Umbruch im Projekt dass man da auch ein bisschen anderer Programmier sprach und unterstützt, aber hauptsächlich eben, wenn man was debaggen will oder sowas tut man das in Python. Und ein Keyteil dieses Projektes ist die API. Also jedes Cloudprojekt lebt von der API, die sie hat, um sie integriert zu machen, eine andere Lösung, um einfach die Möglichkeiten zu schaffen, dass Ressourcen einfach gebucht werden können und dass man auch schnell, schnell Hintergrundsachen verändern kann, ohne dass die API unbedingt brechen muss. Auch Veränderungen im Hintergrund treffen kann und trotzdem eine stabile API vorne dran hat, die jeder benutzen kann. Und OpenStack ist aber auch Kommerz, muss man ganz ehrlich sagen an vielen Stellen. Also dieser Summit zum Beispiel ist eigentlich so ein Händeschütteln in erster Linie der unterschiedlichen Hersteller dazu. Also da sind so alle großen Hersteller vertreten in dem Bereich, die Sponsoren diesen Summit auch. Der Summit kostet verdammt wenig, eigentlich ein Tritzgebühr für eine Konferenz, die eine Woche geht und noch Essen und alles inkludiert. Aber ja, die Gelder kommen von Sponsoren her. Diese Sponsoren sind auch aktiv, wirklich mit viel Personal vor Ort, die in diesen Designs haben, was mit die Richtung vorgeben. Also es fällt sich manchmal so ein bisschen den Eindruck ein, dass 60 bis 70 Prozent der Entscheidungen dort company driven sind. Also wirklich aus deren Überlegungen herauskommen. Und das tatsächliche Projekt OpenStack, wie ich es auch gleich in der Geschichte zeige, kommt aus dem Company-Umfeld in Stückweit. Aber mehr dazu später in der OpenStack Foundation. Also Geschichte. Die Geschichte von OpenStack beginnt irgendwie 2010. 2010 gab es Überlegungen, innerhalb der NASA, ein System zu bauen, um die Ressourcen in der Forschung dort besser nutzen zu können. Weil sie hatten genau das Problem. Es gab viel Bedarf an Ressourcen. Sie haben viel Kapazitäten zur Verfügung gestellt. Aber das Management von diesen Kapazitäten wurde immer schwieriger. Und gerade dieser Rückfluss an Ressourcen wieder in den allgemeinen Verfügungspool ist auch ganz selten passiert und sie haben einfach nicht die Manpower gehabt dazu, dieses Problem zu lösen. Und die Forschung hat immer mehr gebraucht, immer mehr gebraucht, immer mehr gebraucht. Also haben sie sich umgeguckt, wie können sie da was machen? Können sie da selber was strecken? Und dann haben sie sich zusammengetan mit einer Firma namens Rackspace. Und Rackspace ist jetzt auch heutzutage ein Cloudbetreiber für OpenStack, ein Publiklautbetreiber für OpenStack. Und mit denen zusammen haben sie dann eine Codebasis geschaffen, die jetzt eigentlich hauptsicher OpenStack drinnen steckt. Und in diesem Fall gab es dann ein Community Release von dieser ganzen Codebasis, das ist gar erstmal nur NASA relevant und Rackspace relevant. Aber es gab dann Community Release und das wurde Ende 2010 dann auch veröffentlicht. Dann gab es 2011, als interessanter Meilenstein, gab es dann Ubuntu und RedHatch, die auf dieses Projekt gestiegen sind und haben sich gedacht, so eine OpenSource Cloud-Lösung gibt es zwar noch andere Sachen, aber irgendwie das, was die Jungs von Rackspace und NASA da zusammengecoded haben, das sieht ganz brauchbar aus für uns und das können wir auch relativ einfach in unsere Distribution integrieren. Und wenn wir uns hinstellen und sagen, wir sind eine Cloud, also wir sind auch Cloud-Ready und können Cloud-Plattformen ausrollen, dann ist das bestimmt super für die Zukunft und wir können viele Kunden generieren. Und deswegen hat Ubuntu und RedHatch offiziell dann tatsächlich OpenStack als Plattform unterstützt und ein Support dafür angeboten für ein Projekt, was eigentlich auf OpenSource Cloud basiert. Dann kam es 2013 zu einem Rückzug der NASA und der Mangel daran war hauptsächlich der Fortschritt innerhalb des Projekts. Die NASA hat einige Ressourcen, also Personalressourcen zur Verfügung gestellt, das Projekt weiterzuentwickeln und hat dann 2013 gemerkt, dass irgendwie, dass nicht in die Richtung geht, auch sie nicht mehr sozusagen für Entscheidungsgewalt darüber haben und haben es dann zurückgezogen. Jetzt kam allerdings wieder weitere Firmen dazu ins Projekt, in dem Fall Oracle und HP, die dann die OpenStack-Plattform auch auf ihren Systemen unterstützt haben und gesagt haben, doch das ist wahrscheinlich die Zukunft für unsere, also für eine OpenSource Cloud oder allgemein von der Cloud-Lösung auf unserem Betriebssystem. Und jetzt heute springen wir die Release von OpenStack namens Kilo und der Feature-Umfang, den wir jetzt haben, ist wirklich richtig, richtig schwer zu überblicken, also da kann man sich mal einige Wochenende hinsetzen und sich das mal durchlesen. Und das nächste Release, also das letzte Release jetzt war letzten Monat und das nächste Release kommt eben in sechs Monaten dann wieder. Was ist OpenStack aus den Komponenten? Es gibt eben den Zusammenschluss viele Einzelkomponenten an der Stelle und viele Projekte, die ich euch jetzt vorstelle, behaupten auch von sich selbst, dass sie eigenständig funktionieren und dass sie den Rest gar nicht brauchen und das kann man auch alles so benutzen. Ja, das mag stimmen. Allerdings, ich habe noch nie so gesehen, dass diese Einzelkomponenten exzessiv benutzt werden. Meistens werden sie in diesem Verbund zusammen, wie ich euch jetzt vorstelle, benutzt und sie sind natürlich alle austauschbar. Also, die erste Hauptkomponente in dem Cloud-Bereich und Compute wird dann ergänzt von Networking, das ein Teil davon ist und von Storage und am Ende von Support-Systemen an der Stelle. Also, man hat jetzt im Compute-Bereich ein bekanntes Projekt, das heißt NOVA, dass viele setzen das Synonym zu OpenStack. Man hat unser Network ein Projekt, das heißt Neutron und im Storage gibt es ganz, ganz, ganz, ganz viele Projekte, die parallel laufen. Tatsächlich gibt es im Network-Bereich auch parallele Projekte dazu und da gibt es Glance und Cinder. Ich erkläre euch später, was das ist und im Support gibt es Projekte, die heißen Horizon, das ist das Dashboard, Keystone, das Authentifizierung und noch ein paar andere Sachen, die ich euch erklären. Also, zum Detail, was sind diese Komponenten? OpenStack Compute. Der Projektname ist NOVA, was unterstützt OpenStack Compute. OpenStack Compute ist eine Lösung, die auf verschiedenen Produkten, also auf verschiedenen Anlösungen aufsetzt. Nämlich LibVirt, KVM, Xen, HyperV, Vmware, YouNameIt. Alle möglichen Virtualisierungsmöglichkeiten werden unterstützt, hauptsächlich die, die von LibVirt eh schon unterstützt werden und mit diesen Hypervisern kann der Compute-Bereich NOVA zusammenarbeiten. Also, Sie können den eurer OpenStack Cloud benutzen und ausrollen. Der gängigste Fall allerdings in NOVA ist tatsächlich KVM, was benutzt wird, um die Virtualisierung zu realisieren. Aber wenn man jetzt zum Beispiel mal guckt und möchte gerne Windows Server auch ins in der Cloud betreiben und so was, dann läuft das meistens relativ gut, wenn man das nativ machen kann auf einem Hyper-V oder so und auch dafür bietet NOVA Schrittstellen an, dass man nach wie vor die NOVA benutzen kann und trotzdem Ressourcen sich für Windows zuteilen lassen kann. Ja, es kann halt diese ganze Managementaufgaben, diese NOVA-Projekt, starten, stoppen, löschen, anlegen und so weiter, die halt so eine virtuelle Maschine mit sich bringen. Es unterstützt solche Sachen wie Pooling, dass man auch Zonen definieren kann innerhalb seines Rechenzentrums, zum Beispiel eben eine Zone Frankfurt, eine Zone Kanada oder man hat Zonen übergreifende Sachen, dass man sagen kann, es gibt eine Hochverfügbarkeitszone, eine stärkere Data Center oder es gibt eben Zonen, die je nachdem abhängen, wie Speicherintensiv oder sonst was deine Applikationen sind. Und was NOVA zu neuem auch mitbringt, ist Bare Metal Provisioning. Also man kann tatsächlich mit NOVA, mit dem Projekt NOVA auch auf Bare Metal System Software ausrollen oder virtuelle Maschinen ausrollen, die dann dem Kunden zur Verfügung gestellt werden. Das heißt, es teilen den kleinen Kunden und drunter, das wird direkt. Es ist ein Betriebssystem natürlich unten drunter, aber dieses Betriebssystem übernimmt NOVA. Also NOVA deployt diese Betriebssystem für dich. Und NOVA hat zwischenseitlich auch wieder, das gab mal eine Zeit lang, da hatten sie es nicht mehr, aber sie unterstützt jetzt auch wieder Container, das passend zu meinem Vortrag von gestern, dass Docker in dem Fall unterstützt und LXD kommt gerade, tatsächlich Ubuntu, weil Ubuntu dieses LXD-Projekt selber kreiert hat. Das ist also ein Docker-Clone. Und dadurch kann man halt auch tatsächlich nicht nur volle VMs starten, sondern auch Container. Und NOVA kommt mit der NOVA-API, die da das Ganze erreichbar macht, per HTTP und CLI. Und diese NOVA-API ist EC2-Kompatibel. Also das heißt, man kann tatsächlich mit Sachen, die man schon für Gegen-Amazonen gebaut hat auf die API, kann man das rübernehmen in NOVA und kann es tatsächlich so ausführen. Es fühlt sich an, als wäre das Amazon. Und jegliche API-Calls innerhalb dieser API finden Asynchron statt. Also wenn man sich so eine virtualisierte Maschine startet, so eine Ressource, dann sendet man natürlich erstmal den Befehl ab, dass man das gerne hätte. Und später muss man da aber nochmal nachfragen, ob diese Ressource auch tatsächlich jetzt fügbar ist, weil natürlich im Hintergrund einige Dinge passieren müssen, damit das Ganze klappt. Auch damit Netzwerk dran ist und so weiter. Jetzt kommen wir zum Open-Stack-Networking-Teil. Das bekannteste Projekt hier ist Nutron. Es gibt auch ein anderes Projekt, das heißt auch interessanterweise NOVA, NOVA-Network. Aber Nutron hat sich tatsächlich so als der Platz herstrich gesetzt. Also es gibt wenig Lösungen, also wenig Diplote-Installationen, die nicht Nutron benutzen. Es gibt eine ganz große Laufbeweihr, das ist Rackspace, weil die noch aus der Historie gekommen, weil sie einfach ihr Netzwerk-System nicht noch einmal komplett umstricken wollen. Aber alles heutzutage fasiert das neue Projekt, was entsteht mit Open-Stack, ist eigentlich ein Nutron-Projekt. Also hat Nutron inkludiert. Also Nutron macht die ganze Netzwerk-Verwaltung. Wozu natürlich auch die ganzen Subnetze gehören, die man in Open-Stack tatsächlich als Benutzer sich selber konfigurieren kann. Also ich kann in der GUI von Open-Stack oder auch per CLI, kann ich mir Subnetze-Design mit welchen Hosts ich da gerne drinnen hätte. Und ich krieg sozusagen laier 2-Segmente damit zur Verfügung gestellt. Und ich krieg auch von Nutron IP-Adressen zur Verfügung gestellt. Also ich kann auch von Nutron IP-Adressen bekommen aus eine Public IP-Adress Range, sogenannte Floating IPs, die mir dann ermöglichen, dass ich von außen auf meine virtuelle Maschine zugreifen kann. Im Amazon-Sprech heißt das Elastic IP und im Open-Stack-Bereich heißt das eben Floating IP. Also die Komponenten, die hier drinnen benutzt werden in diesem Nutron Network-Stack, sind noch mal in sich austauschbar. Also das Projekt basiert zwar auf ganz viel Technologie, die von Haus aus sozusagen benutzt wird, aber man kann das alles austauschen. Also im Hintergrund werden irgendwie V-Lands benutzt, da kann man aber auch Gret-Handels stattdessen benutzen. Dann kann man irgendwie High Availability mit VARP realisieren oder mit Dollar-Commerz-Produkt und so weiter. Um bestimmte Fälle abdecken zu können. Und genau hier tobeln sich auch unheimlich für die Netzwerkehersteller, die ihre Switche verkaufen und ihre Switche integrieren in die API von Nutron und dann am Ende sozusagen dem Kunden die Möglichkeit schaffen, also dem Endkunden die Möglichkeit schaffen, ihre Switche versteckt zu konfigurieren und eigene V-Landsegmente darauf zu spornen, irgendwie über mehrere Datacenter oder bis zu ihnen nach Hause und so weiter. Das ist eine unterschiedliche Lösung an der Stelle. Und das ist mit auch eines der komplexesten Projekte im ganzen OpenStack. Also wenn man mal eine Nutron-Installation gesehen hat und versucht mal irgendwie zu debaggen von wo nach wo Daten fließen, kann ich einem nur sagen, solltet sich vorher mal zwei Wochen irgendwo hinsetzen, eine Flasche Wein nehmen und ein paar Flasche Wein nehmen und sich das mal ganz langsam angucken, weil ich weiß nicht, wie wir hier im Raum mit OpenV-Spitch schon was zu tun hatten mit Network Namespaces und alles drum und dran, das alles schön einander verschachtelt und man muss da wirklich mit TCP-Dump so an 10 Stellen gleichzeitig um einen Datenverkehr mitzukriegen. Nicht sehr einfach. Also die Komplexitätsskala ist da einfach unendlich. Gibt es da einen besten Projekte, sodass man zusammengestellt ist und man noch sagt, wenn man anfangen will? Ja, ich komme auch noch zu der Installationsteil. Da ist meistens so, dass wir das Projekte mitliefern. Aber natürlich, die Installierung ist dann noch viel ein. Wenn man dann zum Problemfall kommt, das Debuggen muss, dann muss man trotzdem in das Bergwerk runtersteigen und dann wird es meistens richtig schmutzig. Die Nutone hat auch eine API, die nennt sich natürlich Nutone-API und dafür gibt es eben diese ganz vielen Hersteller Plugins, die dann nochmal Spezialfunktionen realisieren oder Sachen besser machen, angeblich. So, dann kommen wir zu ein erstes Block Storage. Das Projekt, was das macht, in OpenStack ist Cinder. Also zur Erklärung kurz, Block Storage ist so Daten im Rohformat zu bekommen, also wirklich Bits und Bytes, ganze Devices zu bekommen, also zu sagen, das was ihr als eure Festplatte kennt oder als Partition durchzuschieben und eine virtuelle Maschine zur Verfügung zu stellen. Das ist ein Teil eben im OpenStack-Projekt und wird von Cinder realisiert. Es gibt auch Storage für die Computer-Resources. Es gibt auch Storage für andere Dienste, aber in erster Linie ist Cinder für die Computer-Instancen da. Also es stellt eben diese Block-Devices zur Verfügung. Auch hier gibt es wieder multiple Backends, die benutzt werden können im Hintergrund, also Cinder ist nur sozusagen die Schnittstelle. Man kann gängige Sachen in aller großen Storage-Hersteller irgendwie mit drin, um dort ihre Lösungen zu verkaufen und ich kann eben beliebige Backends hinten reinpacken, die mir dann diese Storage zur Verfügung stellen. Ich weiß, Eisgasen kann Freenas eigentlich, ja, genau. Tatsächlich ist es so, dass man eigentlich fast alles reinkriegen kann, also man kann auch irgendwelche Obskurelösungen da reinbauen, solange es sich sozusagen für ihn darstellt, auf dem Gastsystem, wo Cinder läuft, wo man die Möglichkeiten hat. Und auch Cinder hat eine API, natürlich. Und auch hier gibt es wieder die ganzen Hersteller Backends. Jetzt kommen wir zu einem weiteres Storage-Lösung im OpenStack und das nennt sich Object Storage. Und Object Storage wird von einem Projekt Zwift realisiert. Und Zwift oder Object Storage ist ein anderes Herangehensweise an Storage-Lösung. Wo ich den Block-Device habe, ich möchte einen Video speichern. Also sowas wie irgendwie in der Trockbox gespeichert wird. Ihr ladet da irgendwas hoch, ihr ladet da ein Detail hoch, die ein Video ist oder eine Präsentation oder sonst was. Und das wird als Objekt da abgelegt in dem Storage und wird auch mit Metadaten versehen, wie zum Beispiel, wann das letzte Mal aktualisiert worden ist, wann es hochgeladen worden ist und welche Zugriffsrechte darauf bestehen von wo. Hallo. Irgendwie reagiert mein Präsenter langsam. Man hat eben in diesem Object Storage schon Möglichkeiten, wenn man das nicht so auf Bits und Bytes-Ebene anguckt, sondern wenn man das eher eben auf Objektbasis anguckt, diese Teilen auch verteilt zu speichern, einfacher verteilt zu speichern. Also so ein Block-Device an sich zu verteilen irgendwo in die Welt ist nicht so einfach. Meistens braucht man dazu volle Duplizierung von diesen ganzen Materialien einfacher. Und dafür gibt es dann eben in Zwift auch Möglichkeiten, Redundanzen zu schaffen. Also man kann damit sozusagen Hochverfügbarkeit schaffen und auch Performance-Redundanzen, wo man einfach mehr schneller die Daten kriegen kann, indem man einfach aus mehreren parallelen Data-Center- oder Storage-Lösungen sich die Daten zieht. Und das hat Zwift eben in sogenannten Pools auch und benutzt dort die Daten zu organisieren. So. Auch hier gibt es viele multiple Backends. Self ist ein Backend, was ich wieder auch noch vorstellen werde dafür in meinem anderen Vortrag und auch ganz viele kommerzielle Lösungen. Und Zwift selber ist auch ein Backend tatsächlich. Also es gibt noch ein Projekt, was Zwift nicht nur diese Schnittstelle ist, sondern auch einen Backend dafür ist. Also, wenn man normalerweise denkt so, dass der Hersteller das irgendwie so bei sich hostet oder so was, oder irgendwie ein zusätzliches Github-Repository, die dafür hat. Nee, es ist tatsächlich so, dass in diesen Projekten diese Herrscher Plugins mit in der Codebasis liegen und die Herrscher das dort managen. So, jetzt kommen wir zum letzten Teil, das ist der Imaging Service. Der heißt Glance im OpenStack Projekt. Also, normalerweise habt ihr so was, dass ihr Images habt, die irgendwie in KUKAO 2 formatiert sind, RAW, ISO, VHD, VMDK und so weiter. Und die braucht ihr als Basissystem um überhaupt eine Ressource ausrollen zu können. Also, normalerweise will ja niemand sich noch so ein Betriebssystem das selbst installieren, sondern ihr wollt schon mit dem Betriebssystem ausgeliefert das Ganze dem Kunden geben. Und natürlich unterstützt du eine Containerimages. Und hier ist es interessant, das Glance Projekt an sich ist nur eben eine Schrittstelle, um diese Imageverwaltung zu tun. Stellt aber selber keine Speichersachen zur Verfügung, sondern nutzt bestehende Speicherkomponenten, die ihr im OpenStack ausgerollt habt. Und da zum Beispiel eben wieder Swift, den Object Store und speichere die Daten dort. Oder speichere das in SEV oder eben in LVM und so weiter. Und dann kommen wir zu Support-Sachen. Die meisten, wenn ihr zu tun habt mit OpenStack, dem Projekt, landen meistens in erster Linie die Webgui kennen. Die Webgui ist reine JavaScript gekonnt. Und im Hintergrund benutzt die tatsächlich so gut wie es geht, die offizielle API. Also, das heißt, wenn ihr darauf zugreift, also das Webgui, wenn ihr darauf zugreift, tut es im Hintergrund API-Calls ausführen gegen die offizielle HTTP API Inhalte anzuzeigen. Das heißt, ihr habt eigentlich dieselbe Möglichkeit, um euch auch dieses Webgui selber zu basteln und selber euch JavaScript Code zusammen zu schreiben, der das tut. Und deswegen ist dieses Projekt allgemein sehr erweiterbar für jede Komponente, die ihr in eurem Projekt nutzt. Also in jeder OpenStack-Installation. Weil ihr könnt ja alles möglich zusammenstecken. Und dann gibt es noch eine Komponente, die ich euch noch erklären möchte, die mit dem Identity-Problem zurechtkommt. Nämlich, man muss irgendwie auch Identifizierung schaffen in so einem Projekt, wo es so viele Subsysteme gibt. Und dort hat OpenStack ein Hauptprojekt, das nennt sich Keystone. Und es ist auch relativ alt schon. Es wird schon relativ lange unterstützt. Und das stellt euch zur Verfügung und auch ein Dienste-Katalog integriert ist. Also hier ist so die Schnittstelle im OpenStack-Installation, wo ihr auch Lesen mitkriegen könnt, was hat denn diese Art, wenn da alles installiert? Also Brutz der Chef, benutzt der Swift, gibt es ein Object-Storage und so weiter. Weil diese Komponenten sind teilweise optional. Teilweise werden sie auch benötigt. Und über diesen Keystone-Dienste-Katalog kann man das eben herausfinden. Und seit neuestem kann man sich über multiple Data-Centers spornen. Also man kann natürlich sich da noch OpenStack-Cloud installieren und da noch OpenStack-Cloud installieren und sich irgendwie noch eine Public Cloud da von OpenStack mieten. Und man hat trotzdem dieselben Benutzer, Annahmen und Passwörter und dieselben Capabilities. Das ist ein Projekt, das ganz neu aufgekommen ist. Das nennt sich Keystone Federation. Und dann möglich, dass ihr tatsächlich eure lokalen OpenStack-Installation wie aber auch die Public Cloud ist, Google Authentifizierung und so weiter. Oder was selber gestricktes. Und natürlich hat auch ein Keystone der API. So, dann gibt es doch ein OpenStack-Telemetrie-Projekt. Psylometer heißt das. Und das ist genau das, was ich vorhin meinte mit Abrechnung, die eine Cloud mit sich bringt. Das kann man auch installieren, das ist auch optional, muss man nicht tun. Aber wenn man das installiert, dann ist es möglich, dass man pro Komponente ein Counter kriegt, wie für die benutzt wird. Also derjenige verbraucht so einen so viel CPU-Zyklin, derjenige verbraucht und dann kriegt man das halt aufgeschlüsselt. Und kann dann dementsprechend den Kunden auch dafür das berechnen lassen. Also den Kunden eine Rechnung schreiben darüber. Und der Kunde kann das Normalfall auch selber einsehen. Dann gibt es natürlich auch Arbeiterbarkeiten, wo man selber Counter einbauen möchte, weil man spezielle Sachen checken möchte. Z.B. auch wie oft schiebt er denn ein Image, also wie oft die Bläute den VM sich neu. Vielleicht gibt es irgendwelche Kunden, die es lustig finden, sich 100-mal ein Image auf eine DVM neu zu deployen. Und ich möchte das rauskriegen. Und allgemein die Erweiterbarkeit ist sehr einfach, weil es agentenbasiert funktioniert. Also ich kann tatsächlich auch ganz hohe Layer 7 Integration schreiben, indem ich einfach nur die API unterstütze und mir einen Agenten Bastel dagegen diese API funktioniert. Ja. Und dann kommt man zum Überblick kurz über diese einzelnen Projekte, wie die so entstanden sind. Nämlich 2010 gab es so die ersten Hauptkomponenten, nämlich Compute und Object Storage, die da geschaffen worden sind. Diese Object Storage Teil hat Rackspace geschaffen. Den Compute Teil hat hauptsächlich die Nase geschafft an der Stelle. Und dann gab es Schlag auf Schlag, jedes Release, jedes Release neue Features. Die Feature waren dann Image Services Lands. 2012 kam dann der Identity überhaupt dazu. Vorher war das also sozusagen ganz Private, wo man das benutzen konnte. Dann gab es das Dashboard Horizon, was eben die Goi zur Verfügung stellt. Und dann kam das Nutrumprojekt auf das Sinterprojekt 2012. 2013 dann die Abrechnungssachen. Ein Orchestration Tool, um merkere Maschinen auf einmal zu deployen. Das nennt sich Heat. Ein Datenbank-Lösung, um euch mit einem Klick einen ganzen Galera-Cluster zu starten oder sonst was. 2014 dann so Lösungen wie Sahara, die Big Data machen. Auch ein tolles Basswort. Hadoop Apache Projekt, seit er zu nur gesagt. Und jetzt 2015 eben auch Bermetal Provisioning unter dem Ironic Projekt, was jetzt gerade neu entsteht, um eben auch auf Bermetal Ressourcen zur Verfügung zu stellen zu können. Und wenn man sich das mal gesamt anguckt, dann sieht das so aus, wenn man so die ganzen Teilprojekte mal irgendwie miteinander verbindet. Das haben schon viele versucht. Auch dieses Bild ist nicht vollständig. Auf jeden Fall erkennt man relativ gut, so sieht die zentrale Komponenten irgendwie diese VM. Und dann gibt es die ganzen Randprojekte, die dazu hinarbeiten, dass diese VM funktioniert. Und es ist tatsächlich so, dass es aber nicht nur Projekte gibt, die sich hier fokussieren, sondern auch komplett getrennt davon liegen, wie Sahara oder so was, die da eigentlich ziemlich abseits liegen. Und das ist tatsächlich ein Problem mit dem OpenStack-Projekt. Es ist ein bisschen Feature-Creep-Zeit. Also es wird unheimlich viel Zeug implementiert, was tatsächlich auch mit diesen ganzen verfügten Verstellungen von Ressourcen auf virtuellen Maschinen eben nichts mehr zu tun hat, sondern das heißt dann, wir stellen alles zur Verfügung, eben Software as a Service. Wir stellen euch ein Datenbank-Klasse zur Verfügung mit einem Klick. Wir stellen euch Big Data-Klasse zur Verfügung. Im Zweifel legen wir euch auch noch ein OwnCloud an und so weiter. Ja, aber was macht sich so mächtig eben und warum ist es so viel Verbreitung? Die API. Man kann es gar nicht oft genug erwähnen. Das OpenStack-Projekt hat es geschafft, 20 APIs rauszubringen, also 20 Parallele für ESP-Projekt 1, nicht sich überschleidende, um die ganzen Subkomponenten durch zu konfigurieren zu können, die teilweise auch ineinander in ihre API integrieren. Sie haben SDKs rausgebracht für alle großen Programmiersprachen eigentlich. Sie haben eine CLI geschrieben für alle Projekte, die diese API benutzt. Also, sicherlich habe ich auf der Kommande ein relativ guter Interface dafür. Und ich kann mit Keystone granularer Zugriffstrechte und Quotas definieren. Also, ich kann tatsächlich wirklich sagen, derjenige darf 5 VMs anlegen, die genauso einen Speicher haben dürfen und der darf nur diese Images benutzen, die ich ihm zur Verfügung stelle. Okay, jetzt kommen wir zur Installation. Die Installation bei Hardware, beim OpenStack ist das Motto, nicht gläckern, sondern klotzen. Ich habe immer ein Controller, ich habe einen Compute Note und ich habe einen Storage Note. So, von Hardware-Ausstattung her ist noch halbwegs normales System Envy. Für die Compute Notes, da will ich schon viel, viel, viel Arbeitsspeicher haben, weil da laufen viele VMs drauf, die brauchen viel Arbeitsspeicher und ich brauche viele Chores, um Rechenkapazität zur Verfügung zu stellen. Und dann habe ich eben noch ein Storage Note, der mir irgendwie Speicher an das ganze System ranbringt, dass die H-Anforderungen an CPU-Ramen nicht so groß, aber dafür brauche ich viele Festplatten. Das wäre jetzt um ein Basisystem für eine OpenStack-Installation. Wenn ich das mal ausprobieren möchte. Und auf dieses Storage Note, das ist beides Deutsch, der Objekt-Storage und der ... In dem Fall wäre das beides auf diesem einen System drauf. Ja, ja. Die Frage war, ob auf dem Storage-System Object-Storage wie auch Block-Storage drauf ist und so weiter, ja, es ist in dem Fall wäre beides drauf. Es kommt auf allen welche Lösungen man nimmt, welche Komponenten man nimmt, aber z.B. wenn ihr das F einsetzen würdet, hättet ihr beides da drauf. Aber es darf vielleicht auch noch ein bisschen mehr sein, nämlich im Zweifel möchte man, wenn ihr das in Cloud betreibt, das auch noch wie ausfallsicher betreiben. Und wenn ich es ausfallsicher betreibe, dann brauche ich eindeutig viel mehr Hardware. Weil tatsächlich ist so es, dass ich anhand der Algorithmen, die dazu benutzt werden, um die Ausflächsicherheit zu realisieren, ich ungerade Anzahlen an Hardware Notes brauche, für bestimmte Komponenten. Und dann habe ich die Möglichkeit, dass tatsächlich mehr, wenn ihr mehr so ein Controller hier stirbt, der z.B. das Web-Guy verwaltet und da das Netzwerk, dass ich immer noch diese beiden habe, die sich darum kümmern, dass diese Compute Notes hier hinten mit Netzwerk angebunden sind und dass auch der Speicher natürlich noch stimmt an der Stelle. Und genauso kann ich auch, können mir zwei Speichernaus hier sterben und ich habe immer noch hoffentlich meine Daten nicht verloren. Was gibt es auch noch für Extras, die ich brauche? Naja, ich brauche dedizierte Ports für Public Management und Storage-Netzwerke. Das sind nämlich im Nutrum-Projekt getrennte Netze. Wenn man es richtig konfiguriert, man kann es auch kaputt konfigurieren und dann kann das alles eins. Ich brauche sowas wie 10 Gigabit-Anbindungen, wo nötig. Also im Storage-Umfeld gerade, wenn ich der NWS-DS einsetze und sowas möchte ich nicht in Gigabit-Link zu meinem Compute Notes haben, weil das reicht einfach nicht. Ich brauche so Rackspace, ziemlich viel davon, weil so ein Server hat Zweifel 1 bis 4 HE, nachdem, wie kompakt man das kauft. Das wird auch dementsprechend teurer, umso kompakter man normalerweise kauft. Und ich brauche noch den ganzen anderen Stellen, nämlich ich brauche noch Netzwerkerett und Danzen, zweimal 10 Gigabit, so wenn die ein Fiber stirbt, oder die eine Konverter stirbt, dann kann ich das andere brützen. Und eben Hardware-Geschichten, die ich noch ersetzen muss, Switches und so weiter, Kühlung, ganz klar. Switches, Routers, Firewalls, weil OpenStack an sich ist ein tolles Projekt und kommt alle sechs Monate was Neues raus. Und wenn ich immer darauf verlassen, dass mit der Sicherheit von bestimmten Diensten es so gut bestellt ist und dann ist man schon fährt man meistens sicherer und stellt vorne dran eine Firewall, die alles erstmal wegriegelt, was noch nicht bekannt ist. Aber eben auch 10G-Switches und so was sind nicht bittig. Und man braucht irgendwie Außenanbindungen in einem größeren Mausstab für so eine Cloud. Herr Ja, wenn man so ein Slash 20, IPv4 hat, dann kann man 1000 VMS deployen, dann ist aber auch Schluss. Das hört sich in erster Linie vielleicht viel an. Für den Public-Hoster ist das natürlich nichts. Und IPv4-Adressen sind unheimlich schwierig zu kriegen. Also, wenn der manchmal an einer Co-Location oder so was seid und dort fragt nach, können wir mal mit den Slash 26 haben, sagen die schon, oh nein, da müssen wir nach Rumänien fahren und müssen kaufen und so. Ja. Zum Thema Hardware-Bennutzung. Die OpenStack-Installationen, die es gibt, werden hauptsächlich im QA Dev-Bereich in der Skalierung von 1 bis 100 Notes Compute Notes wird hier gerechnet, installiert. Das ist so die gängigste Verbreitung, die so ein User Survey mal ergeben hat, 2014. Wenn es in Produktion-Environment geht, sieht man immer noch die 1 bis 100 Notes OpenStack-Installationen sind relativ groß. Aber es gibt natürlich auch so ein paar Kleinen, die machen zu 10.000 plus. Und das ist zum Beispiel das CERN benutzt OpenStack und die benutzen das, um ihre Forschungsdaten zu rechnen. Und dafür haben die eben eine Installation mit eben 25.000 Compute Notes. Also ein Riesenprojekt in der Stille. Dann kommen wir mal zur Deployment-Hilfe. Es gibt Deployment-Tools, die euch diese Installation ermöglichen, weil es gibt ganz viele Subkomponenten, die dafür installiert werden müssen. Ich habe euch nur die Projekte vorgestellt. Ich habe euch nicht gesagt, welche Datenbanken ihr noch braucht, welche Rapid-MQ-Server ihr noch braucht und so weiter. Das will man nicht alles von Hand installieren. Also hat man gefragt in der Community, was benutzt ihr denn so. Und sie benutzen als Hypervisor Konfiguration nach AKVM. Aber es gibt eben auch Chef, was relativ intensiv benutzt wird. Und Def-Stack, was so eine, aber interessanterweise kein richtiges Deployment für eine Produktion in der Weile mit ist, sondern eher ein Deployment zum Testen. Ja. Und als Config-Tools on top of OpenStack, was Leute benutzen, war dann auch ganz interessant, wenn sie schon ein paar mit kennen von eben dem OpenStack-Installation, benutzen meistens eben auch Config-Tools auf, von Top-of-OpenStack genauso auch Puppet. Oder dann die anderen Projekte, die OpenStack mitbringt, nämlich Heat und so weiter. Jetzt zum Deployment. Es gibt zwei Arten von Deployment vom OpenStack. Das eine ist in Bare Metal Deployment. Und da ist die Anforderung an jeden Hardware-Node iPixie Unterstützung. Und am Ende gibt es dann folgende Projekte, die ich euch kurz sagen möchte, wo ihr einen Anhaltspunkt habt, die euch angucken könnt, die eben dann dieses Deployment übernehmen mit iPixie. Das ist Ubuntu Mars, Crowbar Fuel, HP Helion und Red Hat OpenStack. Es gibt allerdings noch viele mehr und es kommen ständig neue raus. Oder es gibt Deployment-Szenarien, wo ihr schon mal ein Basisystem auf den Hardware-Nodes installiert haben müsst und dann noch SSH-Zugriff ermöglichen müsst. Und dann könnt ihr tools nutzen wie Ansible, Puppet und Chef. Und wie wir vorhin gesehen haben, die meisten nutzen das sich daraus Puppet. Okay. Nun kommen wir noch zu kurz und dann geht es um die Projekte. Die Projekte, die wir gehabt haben, ist unheimlich komplex. Das ist ein Sicherheitsproblem. Weil es kann eigentlich fast keiner mehr überblicken, was in diesem Projekt alles drin ist. Und es kann auch keiner mehr überblicken, was da alles an Features wieder dazukommt und wie gut die gewartet worden sind. Und die Integration von allen Features klappt zwar vielleicht irgendwie und fühlt sich so an, als würde das System laufen. Aber wenn dann was bricht in der Installation, die vielleicht noch gar niemand ausprobiert hat, wo ich der erste bin, der das tut. Also es sind die Systeme kurz um einzigartig ein. Jede Open-Stack-Installation, die ich bis jetzt gesehen habe, war eine einzigartige Installation. Es gab selten die Installationen, weil die haben entweder unterschiedliche Hardware benutzt, die der andere nicht benutzt hat, was das gängige Fall ist, oder sie haben sich für andere Komponenten entschieden, die der andere nicht benutzt hat. Z.B. die Netze trennen muss. Dass so ein Storage-Netz und so ein Management-Netz nichts zu tun hat in dem Public IP-Adress-Netz. Und schon habe ich das Problem, dass eben Leute effektiv, wenn da keine Firewall vorne dran steht, mit IP-Adressen, die Controller direkt erreichen können und irgendwie lustige Sachen mit denen machen kann. Und ein Angriffsfaktor ist natürlich auch die HTT-PAPI, die nach außen exposed wird mit Absicht natürlich, ist wieder so ein Thema, was ich auch schon gestern in der Docker-Prestation hatte. Ich finde, es ist schade, dass diese modernen Projekte um die Ecke kommen und sagen, ja, nee, nur wenn ihr wollt mit Verschlüsselung, ich finde das wäre mandatory und das heißt, es gibt auch durchaus HTT-PAPI's wie Keystone, die dann einfach nicht verschlüsselt benutzt werden von Leuten. Und darüber passiert und natürlich ein interessanter Angriffsfaktor sind die Public Cloud Hoster, die da draußen sind. Also klickt euch mal so eine Open-Stack-Cloud-Lösung zusammen, so eine 1VM vielleicht auch nur bei Rackspace oder so. Und guckt mal, was ihr damit alles tun könnt. Ich zeige dir noch so Stichworte wie Venom. Ich weiß immer noch davon, dass es ein paar Distributionen gibt, was für die eben benutzt werden kann. Also ein Angriff von innen ist meistens eindeutig effektiver als von außen. Und dann möchte ich noch ein paar Worte von denen, die ich am Anfang gesagt habe zur Foundation. Die Foundation unterteilt sich eigentlich in diese drei Sektionen. Nämlich ein Tech-Komitee in Board of Directors und ein User-Komitee. Und das Interessante ist, was wir hier machen. Und da sieht man dieses Tech-Komitee, kann das Software-Development und Direction bestimmen und hat 13 Mitglieder. Und diese 13 Mitglieder, das ist Open-Stack-Projekt besonders stolz drauf, werden aus der Community gewählt. Außen aktiven Contributoren, Active Contributors. Und das Lustige ist, die hauptsächlich aktiven Contributoren in diesem Projekt sind zum Beispiel die Firma mit den Mitgliedern, die sich in die Community hin insenden. Und natürlich kann man sagen, ja, die machen es auch in ihrem Privatfreizeit und so was und drum und dran, aber klar haben die auch ein Bias zu ihrer Company bestimmte Entscheidungen, dementsprechend in die Richtung zu drücken. Und da gibt es noch das Board of Directors. Das ist so ein Gentleman's Club, wo man irgendwie reingewählt wird und am Ende gibt es noch das User-Komitee, was irgendwie Feedback geben darf und das so seine Daseinsberechtigung hat. Und da gibt es eben 75 verteilte Gruppen ganz weltweit, also so User-Treffen, die halt irgendwie mal sagen, wir hätten gern das und wir hätten gern das. Aber auf keinen Fall haben die direkt die Steuerungsmöglichkeit an der Stelle. Also wie man sieht, weil die Komplexität zu hoch ist, gibt es da auch viele Lösungen dafür und es gibt viele Firmen, die versprechen, diese Komplexität zu reduzieren. Und man muss ehrlich sagen, dieses OpenStack-Projekt über die Zeit hin, jetzt gerade seit den letzten zwei Jahren oder sowas, hat wahrscheinlich jetzt langsam so sein Peak erreicht, wo es dann vielleicht auch mal ein bisschen weniger gehyped wird und nach unten geht, weil man, weil der Feature-Creep zugenommen ist, das kann ich euch nur an ein Herz legen, die Dokumentation dazu lesen, die ist sehr gut und gegebenenfalls auch ein Summit zu fahren, bevor ihr es tut. Es hilft tatsächlich massiv, weil es so viel Zeug gibt in OpenStack. Und wenn ihr noch Fragen habt und so weiter, die Zeit ist schon knapp, ist schon eine Stunde rum, dann würde ich euch bitten, einfach draußen vorbeikommen. Ich weiß nicht, ist da noch ein Talk-Nacht danach? Ja. Welche der Komponenten, wenn man mal das Test will, kann man Sinf oder Weiße? Test, Test, Test. Hallo. Okay, also die Frage war, was ich denn dazu wirklich alles auf Bär-Metal brauche und ob ich nicht Komponenten davon auch auslagern kann in wetterisierter Umgebung und gegebenenfalls sogar die Komponenten selber auf eine Computer-Node starten kann. Das ist ein Problem, wenn ich auf OpenStack die Bläuer, dann geht das. Aber ansonsten geht das nicht. Natürlich kann man zum Ausbilden am Anfang empfehle ich jedem Def-Stack, was die einfache Lösung ist, um so ein Gesamtsystem aufzusetzen. Da wird einfach alles virtualisiert und man hat teilweise Performance-Einbußen, je nachdem, was ein System darunter liegen hat. Wenn man da ist oder sowas mit Hardware-Wertualisierungsunterstützung, dann geht das eigentlich ganz gut. Dann kann man sicherlich viel auch noch in dieser wetualisierten Umgebung testen und auch in dieser wetualisierten Umgebung wiederum virtuelle Maschinen starten, die noch relativ performant sind. Ansonsten habe ich eben das Basis-Setup vorgestellt, dass sie diesen drei Notes funktionieren kann und als Zwischendrin erwartet wird, dass ein richtiges Netzwerk existiert und nicht ein Netzwerk, was VirtualBox euch z.B. zur Verfügung stellt. Ja. Das geht. Wie geht es auf den Netzwerk? Der Netzwerk-Note, ist das, kann ich auch was gut erinnern? Ja, man kann natürlich also Neutron auch virtuell deployen auf einem Controller. Es geht natürlich auch oder auf dem desizierten Hardware inzwischen zwischen dem Controller und dem Compute Note. Und das kann ich in VirtualBox halt nicht wirklich abbilden. Dann brauche ich halt schon noch Hardware. Wenn ich dann allerdings Neutron benutze mit Greta, dann kann ich dass wir tatsächlich den Compute Note mit dem Neutron Service auf dem Controller verbinden. Weil dann muss das, muss die unterliegenden Struktur davon keine Ahnung haben. Das ist unterschiedlich. Ach so, die Wiederholung, okay. Die Frage war, wie ich Ausfallsicherheit realisiere. In OpenStack, es gibt ja ja unterschiedliche Lösungen dafür. Und OpenStack, wie ich gesagt habe, hat ganz viele unterschiedliche Komponenten, die man benutzen kann. Und auch in dem Nova-Fall gibt es wirklich unterschiedliche Ausfallmöglichkeiten, die man unterstützen muss, wenn man nach dem, ob man Cortena Maschinenausfallsicher machen will und ob die jetzt unter KVM laufen oder ob die unter Hyper-V laufen oder ob die in der X-Hand laufen und so weiter. Es ist ganz unterschiedlich. In dem Fall von KVM bietet LibWirth die Library, die Nova da an der Stelle benutzt, schon Möglichkeiten Ausfallsicherheit zu bieten, in dem tatsächlich, wenn ein System ausfällt, ein Compute Note ausfällt, die virtuelle Maschine auf einem anderen System hochgefahren wird. Also Ausfallsicherheit ist damit gemeint, dass der Ausfall relativ kurz ist. Und da werden tatsächlich auch, kann man Maschinen live migrieren von einem System aus anderen mit LibWirth, wenn man das richtige Storage-Backend auch wieder hat, also man muss auch da aufpassen, wenn man das falsche Storage-Backend hat, dann geht es auch schon nicht mehr. Aber wenn man solche Self-Einsätzen im Hintergrund, dann kann man das machen, dann kann man tatsächlich eine Maschine von einem Compute Note aus den anderen verschieben im laufenden Betrieb, in der Verfügung gestellt. Oder man kann Features nutzen von VMWirth zum Beispiel, was die meisten Leute kennen, Live Migration heißt das von VMWirth, oder wie Motion. Die kann man mit integrieren Nova und dann werden diese kommerziellen Features von diesen Wenders unterstützt und dann kann man mit Nova auch einen Umzug machen, der dann im Hintergrund wie Motion von VMWirth benutzt auf VMWirth System. Also hat man so relativ viel Flexibilität an den Stellen. Ja, ja. Also die Hybridenglautansatz, das ist genau das, was ich meinte mit Keystone, Datacenter, Detacenter übergreifend, der ist jetzt gerade ins OpenStack Projekt neu reingekommen. Und das heißt, ich kann tatsächlich, wenn ich das mal nach außen, wenn ich die Sachen brauche, automatisch nach außen gehe zu Ängsten, zu NextBase, wie sieht das aus? Ja, also die Hybridenglautansatz, das ist genau das, was ich meinte mit Keystone, Datacenter, Datacenter übergreifend, der ist jetzt gerade ins OpenStack Projekt neu reingekommen. Und das heißt, ich kann tatsächlich mit Nova und Keystone zusammen mir Cloud-Instanzen bei Rackspace, die OpenStack im Hintergrund benutzen, hochfahren lassen und auch gleichzeitig hochfahren lassen in deiner Private Cloud. Wie das da netzwerktechnisch ist, also ob du dann sich da auch in Layer 2-Segment kriegst, das hängt ja nochmal ab, welche Netzwerklösung du unten drunter benutzt. Da gibt es SDN-Wender, die dir dies anbieten, dass du tatsächlich die beiden Clouds da auch noch interconnecten kannst und das ist halt so eine Sache, die ist meistens dann abhängig von den unterschiedlichen Lösungen, die du da einsetzt. Also ich kann die VRM, die bei mir intern läuft, dann wirklich, sag ich mal, falls es zu eng wird, in den laufenden Betriebchen, jetzt frage ich jetzt mal... Okay, die Frage war Live Migration von der Private Cloud in die Public Cloud und so Spielchen. Aber ich kann es aber über Nacht kein Problem, das sage ich mal, wo ich das losrufe. Genau, der Vorteil ist halt meistens, dass man, wenn man die Nova oder die APIs benutzt, dann gehe ich hin und ich habe eine Maschine, die läuft gerade, davon mache ich einen Snapshot und dieses Snapshot gebe ich mir raus als Datenblop und diesen Datenblop stecke ich über die API in einen anderen Public Cloud-House da rein und starte daraus dann mein Image wieder hoch. Also diese Möglichkeiten habe ich. Dann ist dir der Cloud zu sagen, leid, der findet dann auch den Storage und der findet das auch im Idealfall. Um diese Probleme kümmert man sich normalerweise nicht, dann, wenn man die VRM starten will, dann sagt einfach nur, das ist das Image, ich möchte es jetzt starten haben, wie das dann in welchem Storage das brützt und so was, das interessiert dich dann normalerweise eigentlich nicht. Allerdings eben, es sind unterschiedliche IP-Adressen dann in Zweifel, also man muss dann den DNS-Rekord umbiegen oder solche Spielchen machen und das ist halt dann natürlich dann auch immer noch so, dass man da die Vendor meistens in diese, also gibt es mehrere Backend-Möglichkeiten, dass man auch zwischen unterschiedlichen Backends wie VRM-Ware, Xen, Hyper-V und VRM hin und her migrieren kann oder irgendwie die Systeme umziehen kann, auch mit Ausfall oder sonst wie. Und zur Frage muss ich sagen, ja und nein, je nachdem auch wieder abhängig, was der Vendor unterstützt, da sie sich aber alle in diese Nova-API mit reinhucken und wenn sie dieses Migration-Feature, was man überprüfen kann über die Nova-API unterstützen, dann tun sie halt solche Hacks machen, wie eben, dass sie diese Maschine in VRM-Ware Snapshotten, diesen Snapshot gespeichert haben auf einem Storage-System, was sich gegebenenfalls schon alle teilen und von dort aus dann eine andere KVM-Instanz hochgefahren wird. Also es gibt da Lösungen, aber nicht in allen Stellen funktioniert das und das ist auch sehr herstellerabhängig. Das ist tatsächlich ein Problem im OpenStack, die Upgrade, also die Upgradebarkeit war die Frage, wie gut ist das im OpenStack gelöst? Wie gut kann ich Upgrades schippen, besonders wenn ich ein 6-mode Release-Zyklus habe? Tatsächlich ist es so, dass diese Frage irgendwie lange Zeit ins Hintertreffen geraten ist im OpenStack-Projekt und jetzt immer mehr versuchen sich da irgendwie drauf zu stürzen und dieses Problem zu lösen, aber es ist kein einfaches Problem, besonders weil man halt auch sagen muss, diese Dienste müssen irgendwie vorher hoch verfügbar sein, damit ich sie später auch live im Betrieb austauschen kann, damit ich auch mal was runterfahren kann und nicht vielleicht mein Service zusammenbricht. Und da gibt es unterschiedliche Ansätze. Viele Sachen darauf basieren auf irgendwelchen Puppet-Modulen zur Orchestrierung, die dann halt schon voraussetzen, dass das System hoch verfügbar aufgebaut ist und dass ich das sich die einzelnen Komponenten rausnehmen kann, neu installieren kann, so ein Compute Note oder so ein Controller Note 9 sehen kann und die API-Version allerdings noch stabil geblieben ist und deswegen sie auch die alten Systeme mit den neuen Systemen reden können und das versuchen Sie, es gibt Lösungen, da klappt das ganz gut und die Lösungen, da klappt das überhaupt nicht. Also das ist auch von jedes Release jetzt, das kommt, sollte eigentlich immer mehr Unterstützung dafür bieten, aber es ist im Moment noch ein Problemkind. Die meisten Leute, was sie draußen tun, ist AB-Deployment. Also das heißt, sie installieren OpenStack Cloud und wenn sie die Updaten müssen, installieren sie irgendwo ein anderes noch noch OpenStack Cloud, die neue Software und dann moveen sie in den Workload von AB. Das ist aber auch, ja, das ist dann ein Stück für Stück. Man kann dann auch die Compute Einzelnen umschiften und so was, das geht auch. Allerdings ist es natürlich ein unheimlicher Ressourcenaufwand, das Ganze zu tun natürlich und auch es ist kein einfaches Problem. Also so eine Rackspace, also so was sie tun, dass wirklich tagtäglich tun, die Hunde-Daten-Servern irgendwie upgradeen über den Rolling-Upgrade und den neuen Systeme reinbringen. Aber auch ganz oft ist es so, dass gar nicht die neuesten Features von OpenStack unterstützt werden. Also Randkomponenten nochmal reinsteckt zusätzlich und nicht was einen großen Austausch macht. Ich denke mir jetzt auch, kommen Nova Networks irgendwie kacke, ich will das nur schon haben und ich schmeiß da alles Networking einmal raus, das klappt nicht. Also jedenfalls nicht, wenn man nicht AB-Deployment macht. Das funktioniert es nicht.