1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Openstack Foundation: "Wir…

Typisch deutsche Berufsnoergler

  1. Thema

Neues Thema


  1. Typisch deutsche Berufsnoergler

    Autor: Doubleslash 21.06.15 - 12:31

    Der Vortrag von Syseleven ist sehr aufschlussreich. Es werden Erfahrungen und Lerneffekte aus der eigenen Historie als Hoster, dargestellt, die aufzeigen worauf man beim Skalieren von OpenStack achten sollte. Sowas ist wertvoll fuer alle, die nicht den Luxus haben, zwei Rechenzentren in Berlin als Spielwiese fuer so etwas zu benutzen.

    Ich bin jedoch kein Fan von der Art und Weise, wie man diese Erfahrung teilt. Wenn man sich mit OpenStack etwas beschaeftigt, und sich viele der Summit-Videos oder Usergruppen-Tracks aus anderen Laendern anschaut, erkannt man wie "Deutsch" dieser Vortrag ist: in einer Tour werden zufaellig gefundene Spaghetti-Implementierungen quer durch alle Projekte als Beweis fuer strukturelle Probleme angefuehrt.

    Es ist zwar sinnvoll diese Bugs und schlampigen Implementierung aufzugreifen, jedoch sollte man sie auch im Kontext betrachten - die Mehrheit der OpenStack-User wird nicht 10.000 Tenants haben, bei denen ein Upgrade-Prozess sehr lange dauert. Die Mehrheit wird auch nicht eine so diversifizierte User-Basis (Webserver vs. Hadoop Terasort) haben.
    Statt diese Problembereiche in einem Best Practice-Ansatz zusammenzufassen und die Alternativen zur Umschiffung aufzuzeigen, wird in einer Schimpftirade ueber die Entwickler hergezogen.

    Auf ihrer Homepage schreibt SysEleven: "Wir übernehmen Verantwortung, statt bei Problemen anderen die Schuld zuzuschieben, wir arbeiten agil und helfen unseren Kunden so, ihre Ziele schneller umzusetzen."
    Auf der anderen Seite sehe ich keinen einzigen Commit und kein einziges Review von den Kollegen zu Upstream. Kein einziger Bug gemeldet.

    Man hat sich offenbar sehr intensiv und lange mit der Materie auseinandergesetzt, bis aufs Level von einzelnen SQL-Implementierungen. Warum nicht dieses Wissen nehmen und die Implementierung verbessern? Oder zumindest die entsprechenden Bugs aufmachen und die Diagnosedaten teilen. Statt einfach, wie Golem es schon richtig schreibt, mit Haeme darueber auf regionalen Konferenzen zu herzuziehen.

    Man hat wieder die typisch deutsche Skepsis-Haltung an den Tag gelegt, und lediglich herausgefunden, was nicht funktioniert und den Vergleich zu kommerziellen Loesungen gesucht. Ueber die Tatsache, dass proprietaere Hersteller wie VMware mit vCloud mehr als 10 Jahre gebraucht haben, um so etwas wie OpenStack zu bauen - kein Wort.
    Sie testen ein Community-Projekt, dass sie ohne Lizenzkosten und Einschraenkungen frei verwenden und treten gleichzeitig das OpenSource-Prinzip mit Fuessen, indem man sich bei der Beteiligung und Verbesserung vornehm zurueckhaelt und dann oeffentlich dagegen Stimmung macht.

    Gipfel der Ignoranz ist dann der Vorwurf, Ubuntu, SuSE und Red Hat wuerden ihre eigenen Distributionen der Community bevorzugen und haetten deshalb kein Interesse an einer stabilen Community-Version - hier toent Golem sogar noch mit ins Horn.

    Da muss sich sagen, habt ihr eure Hausaufgaben nicht gemacht. Community ist immer instabil, Community ist nicht fuer die Verwendung in Produktion gedacht. Das liegt in der Natur der Sache, den andererseits ist es eben der Ort an dem explorative Implementierungen getestet werden - die sind vielleicht schon mal auf einem MacBook Air entstanden und nicht auf einem 1000-Knoten-Deployment oder mit proprietaeren Loesungen getestet worden. Eben das ist ja die Aufgabe der Enterprise-Distributionen, die dann meist auch weniger aber dafuer stabile Features haben.
    Auf der anderen Seite leisten Red Hat und SuSE ihre Arbeit alle zuerst Upstream in der Community - und leiten von dort ihre Distributionen ab. Es ist also voellig aus der Luft gegriffen zu sagen, die wuerden ihre eigenen Produkte bevorzugen.

    Schlussendlich bleibt nichts neues zu berichten. Jeder weiss, dass die Verwendung von puren OpenSource-Code Engineering-Skills ohne Ende benoetigt - dafuer gibt es kommerzielle Anbieter. Wenn man also die Eignung von OpenStack dafuer messen will, dann doch bitte an den Enterprise-Distributionen.

  2. Re: Typisch deutsche Berufsnoergler

    Autor: Isotopp 22.06.15 - 09:35

    Einige Anmerkungen dazu:

    Zu »worauf man beim Skalieren von OpenStack achten sollte« und » werden zufaellig gefundene Spaghetti-Implementierungen quer durch alle Projekte als Beweis fuer strukturelle Probleme angefuehrt«

    So weit, daß wir "skalieren", sind wir noch gar nicht. Der Testcluster, mit dem wir die Effekte beobachtet haben, ist 10 Maschinen (500 Kerne) klein und belegt nur ein Rack. Schon dort, bei 5 Tenants, 5 Roles, 5 Usern, bricht Openstack an einigen Stellen auseinander (zum Beispiel die im Vortrag berichtete Keystone-Migration genau bei dieser Größe).

    Und das ist, wie Du selbst bemerkst, keineswegs zufällig, sondern "quer durch alle Projekte". Das ("quer durch alle Projekte") ist genau das Strukturproblem - dazu weiter unten mehr. Und es sind überwiegend Strukturprobleme, wie mir genau die anwesenden Leute von der Openstack Foundation nach dem Vortrag bestätigt haben.

    Zum Beispiel Keystone: Im Vortrag habe ich berichtet, daß Keystone für 250 Tokens/Sec im MySQL 11.000 Queries pro Sekunde generiert, weil jede Operation in 6 Statements und zwei Transaktionen aufgeblasen wird ("BEGIN; SELECT 1; COMMIT; BEGIN; <das Statement>; COMMIT").

    Devananda van der Veen kam nach dem Vortrag bei mir vorbei und berichtete, daß er das Problem schon seit zwei Jahren kenne und damals (vor vier Releases) auch einen Fix submitted hätte, der jedoch abgelehnt worden ist. Die Gründe dafür sind Unkenntnis von Datenbanken und Politik. Mit 250 Tokens/s kommt man jedoch bei der Clustergröße nirgendwohin und bei ca. 20k Statements/s macht MySQL dann auch so langsam zu - sinnlose Statements brennen sinnlos Kapazität weg und Vendorpolitik blockiert den Fix seit vier Releases.

    Zum Beispiel Nova: Im Vortrag habe ich geschildert, daß Nova nicht zählen kann und die in der Datenbank hinterlegten Informationen schlicht falsch (von der Realität abweichend) sind. Wir sind mit unserer relativ kleinen Installation ebenfalls nicht die ersten, die das bemerken - http://openstack-in-production.blogspot.de/2015/03/nova-quota-usage-synchronization.html hat das Problem in etwa 100x größeren Deployments noch viel mehr. Ein "Patch" dafür ist technisch nicht möglich, es tritt an vielen Stellen auf, zum Beispiel in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5533 Dort heißt es

    # In particular we need to try very hard to ensure that
    # Nova does not "forget" about the guest. ie leaving it
    # running on a different host to the one recorded in
    # the database, as that would be a serious resource leak

    Man beachte, was dort versucht wird, und was alles nicht an Fällen dort berücksichtigt wird (werden kann): An keiner Stelle wird diskutiert, was passiert oder mit dem Cluster sein soll, wenn es während einer solchen Zustandsänderung des Clusters zu Störungen oder Unterbrechungen der inneren Konnektivität des Clusters kommt.

    Der korrekte Fix für so was ist der Einsatz eines Clustermanagers (https://www.consul.io/, https://github.com/coreos/etcd/, https://zookeeper.apache.org/) und eine Rückmeldung aller Compute-Nodes und aller laufenden VM-Instanzen in diesen. Wenn man so etwas nicht verwendet und versucht, sich so etwas selber zusammen zu löten, landet man in etwa hier - https://aphyr.com/tags/jepsen. Openstack versucht nicht mal das, sondern hofft, daß seine Message-Komponenten und Python Scripte schon irgendwie klar kommen, was nachgewiesenermaßen schlicht nicht der Fall ist.

    Würde man auf einen Clustermanager migrieren, wäre man nicht nur diese Probleme los, sondern würde auch viele SPOF- und HA-Probleme, die Openstack aus der Tüte ungelöst läßt, gleich mit loswerden, weil man nicht mehr mit migratory IPs und gratitious ARP rumhampeln muß, sondern einfach genug Instanzen von allem, was Stateless ist, haben kann. Die resultierende Architektur wäre insbesondere die Openstack-Variante von https://github.com/googlecloudplatform/kubernetes

    Wieder habe ich nach dem Vortrag mit Leuten von der Foundation drüber gesprochen, in diesem Fall mit Monty Taylor, der mir in der Tat beigepflichtet hat, und der mir erklärte, wie genau das diskutiert worden ist. Eine solche Änderung wäre allerdings, so Monty, eine sehr weitreichende architekturelle Änderung und damit ein monströses Politikum, denn sie würde große Mengen an Code in Keystone und Nova (die sowieso kaputt sind) überflüssig machen (und durch korrekten Code in Consul/etcd/ZK ersetzen). Das ist aber ein riesiges Faß, das jede Menge politische Aktion erfordert, wenn man es öffnen wollte.

    Und zu "quer durch alle Projekte" zurück zu kommen, wie ich oben versprochen habe - das ist auch an anderer Stelle zu beobachten, nämlich bei dem im Vortrag angeführten "Overlay needs to communicate securely with the underlay" Problem, das Sahara, Ceilometer/Heat, Designate und viele andere Komponenten haben und das einen einheitlichem, sicheren und getesteten zentral gesteuerten Mechanismus haben müßte, jedoch nie haben wird, weil es keine Openstack-zentrale Projektsteuerung und übergreifende Architektur gibt. Wieder haben wir nach dem Vortrag drüber gesprochen und Collier, sinngemäß: "We deliberately created the Openstack Foundation and the projects in a way that there can be no single central instance or dictator, benevolent or no, taking over. So this is not likely going to happen."

    Das ist genau das Strukturproblem, daß Du da in der Architektur beobachtest: Es gibt viele Player, die Mehrzahl davon begreift das Problem nicht und die, die das Problem begriffen haben, können es nicht reparieren, weil die Masse Angst vor der Änderung hat.

    Die Beiträge von SysEleven findest Du übrigens hier https://github.com/syseleven und https://launchpad.net/~syseleven-platform. Insbesondere haben wir das gesamte Build-System von OpenContrail und das Packaging von OpenContrail aufgeräumt (OpenContrail ist ein Open Source SDN-Projekt von Juniper und leidet nicht unter dem administrativen und organisatorischen Overhead von Openstack, sodaß Contributions eine wesentlich kürzere Durchlaufzeit haben und man sich weitaus weniger mit Politik auseinander setzen muß, wenn man was machen will. Das Feedback ist also schneller und kürzer, was gerade bei Open Source Geschichten und agilem Zeugs von zentraler Bedeutung ist).

    Openstack ist ein feines Projekt, und es ist insbesondere das einzige Projekt, das eine SDS und SDN-Story hat. Das ist genau das Haupt-Alleinstellungsmerkmal gegenüber Kubernetes, Docker, LXD, aber auch OpenNebula und CloudStack und was es da sonst noch an Dingen gibt.

    Wenn Du ein Openstack-Deployment hast, das klein genug ist ("Department-Size", ein Rack voll Hardware in etwa), dann kriegst Du es vermutlich mit überschaubaren Problemen zum Laufen - das ist eine Größe, bei der man noch keine Probleme mit Ost-West Traffic und Oversubscription an den ToR-Switches bekommen kann, und bei der OVS vermutlich noch nicht explodiert. Außerdem kann man Klasse 2-I/O (OLTP-Datenbanken und dergleichen, Latenz < 1/2000s) auf Filer tun und Ceph auf Klasse 3 I/O und langsamer beschränken.

    Enterprise-Size und größer braucht mehr Arbeit und da hat Openstack schlicht nix fertiges auf der Hand. Leider auch kein einzelner Hersteller. Deren Distros haben jeweils entweder eine funktionierende SDS- oder SDN-Story (und SDN ist das härtere Problem), aber keiner hat beides.



    1 mal bearbeitet, zuletzt am 22.06.15 09:40 durch Isotopp.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Anwendungsbetreuer*in Campus Management System (m/w/d)
    Humboldt-Universität zu Berlin, Berlin
  2. Disponent (w|m|d) - optional zusätzlich mit Anwendersupport
    ADAC e.V., Groß-Gerau
  3. Softwareentwickler C/C++ (m/w/d)
    pro-beam GmbH & Co. KGaA, Gilching (bei München),
  4. IT Workplace Administrator (w/m/d)
    RHI Magnesita GmbH, Mainzlar bei Staufenberg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de