Openstack im reality check

2.362 Aufrufe

Veröffentlicht am

Vortrag auf dem iX Openstack Tag in Köln am 15. April 2015

Veröffentlicht in: Internet
0 Kommentare
4 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.362
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
40
Aktionen
Geteilt
0
Downloads
44
Kommentare
0
Gefällt mir
4
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Openstack im reality check

  1. 1. OpenStack im Reality Check Kristian Köhntopp Cloud Architect Alter Sack SysEleven https://www.flickr.com/photos/pinksherbet/188842453 Pink Sherbet Photography (CC BY 2.0)
  2. 2. https://uksysadmin.files.wordpress.com/2011/03/openstackwallpaper1.png
  3. 3. Breite Unterstützung aller Marketingabteilungen https://www.flickr.com/photos/ahockley/8662640096 Aaron Hockley (cc-by-sa 2.0)
  4. 4. 4 http://clouduser.de/analysen/ein-gorilla-im-nebel-sap-sucht-zuflucht-bei-openstack-und-cloud-foundry-24382
 http://www.businesscloudnews.com/2015/04/09/red-hat-dell-redouble-openstack-private-cloud-efforts/
 http://blogs.wsj.com/cio/2015/02/25/the-morning-download-h-p-deal-with-deutsche-bank-is-step-forward-for-openstack/
  5. 5. 4 http://clouduser.de/analysen/ein-gorilla-im-nebel-sap-sucht-zuflucht-bei-openstack-und-cloud-foundry-24382
 http://www.businesscloudnews.com/2015/04/09/red-hat-dell-redouble-openstack-private-cloud-efforts/
 http://blogs.wsj.com/cio/2015/02/25/the-morning-download-h-p-deal-with-deutsche-bank-is-step-forward-for-openstack/
  6. 6. 4 http://clouduser.de/analysen/ein-gorilla-im-nebel-sap-sucht-zuflucht-bei-openstack-und-cloud-foundry-24382
 http://www.businesscloudnews.com/2015/04/09/red-hat-dell-redouble-openstack-private-cloud-efforts/
 http://blogs.wsj.com/cio/2015/02/25/the-morning-download-h-p-deal-with-deutsche-bank-is-step-forward-for-openstack/
  7. 7. 4 http://clouduser.de/analysen/ein-gorilla-im-nebel-sap-sucht-zuflucht-bei-openstack-und-cloud-foundry-24382
 http://www.businesscloudnews.com/2015/04/09/red-hat-dell-redouble-openstack-private-cloud-efforts/
 http://blogs.wsj.com/cio/2015/02/25/the-morning-download-h-p-deal-with-deutsche-bank-is-step-forward-for-openstack/
  8. 8. Was OpenStack Vendors versprechen… https://www.flickr.com/photos/debarshiray/8237431709/sizes/l debarshiray (CC-BY-SA)
  9. 9. Wie Admins sich das Arbeiten mit OpenStack vorstellen… (C) Kristian Köhntopp, 2006
  10. 10. Was geliefert wird… (C) Hendrik Scholz, 2006
  11. 11. Wie der Adminjob wirklich aussieht… (C) Kristian Köhntopp, 2015
  12. 12. Was wollen wir eigentlich erreichen? 9
  13. 13. „Any VM, anywhere.“ 10
  14. 14. „Infrastructure as Code.“ 11
  15. 15. Warum brauche ich das? • 24 Cores (48 Cores HT), 256G RAM, 2* 10GBit und 12* 3TB HDD mit solidem BBU • 10k EUR
 • Anwendungen, die so eine Kiste voll machen sind selten, also schneiden wir sie klein und verkaufen die Teile. 12
  16. 16. "Any VM, anywhere"13
  17. 17. "Any VM, anywhere"13
  18. 18. "Any VM, anywhere"13
  19. 19. "Any VM, anywhere"13 CPU, RAM StorageNetwork OverlayUnderlay
  20. 20. Storage "Where the Internet lives", http://www.google.com/about/datacenters/gallery/#/tech/12
  21. 21. Storage: Anforderungen • VM mit Ephemeral Storage • Das ist kein Problem, richtig? Weil der Storage ja auch eine ungesicherte, lokale Platte kann. 15
  22. 22. Storage: Anforderungen • VM mit Ephemeral Storage • Das ist kein Problem, richtig? Weil der Storage ja auch eine ungesicherte, lokale Platte kann. • Aber dann geht Migration nicht. • Und das macht Maintenance der Hardware-Node schwieriger planbar. 15
  23. 23. Erkenntnis #1:
 Lokaler Storage kann nirgendwo Default sein. 16
  24. 24. Storage • VM und Volume: Writes sind immer Remote. • Und redundant. 17
  25. 25. Storage • VM und Volume: Writes sind immer Remote. • Und redundant. • Metriken: • Bandbreite, IOPS und Latency • MB/sec, multithreaded-fsync()/sec und sequential- fsync()/sec 17
  26. 26. Storage • VM und Volume: Writes sind immer Remote. • Und redundant. • Metriken: • Bandbreite, IOPS und Latency • MB/sec, multithreaded-fsync()/sec und sequential- fsync()/sec • Woher kommen die Limits? 17
  27. 27. Storage: Anforderungen • Problemlos skalierbar: • Bandbreite, MT-IOPS 18
  28. 28. Storage: Anforderungen • Problemlos skalierbar: • Bandbreite, MT-IOPS • Schwierig: • Sequential-IOPS (Latenzabhängig, Ziel: 10k) • Default-Benchmark: "MySQL Slave auf einem Volume" • "16 KB single-thread random-write auf einem Datafile." 18
  29. 29. Erkenntnis #2:
 Es reicht, einen Single-Threaded Random-Write Benchmark zu machen. 19
  30. 30. Storage • OpenStack Default ist iSCSI und tgtd • »Das Problem bleibt dem geneigten Leser zur Übung überlassen.«
 20
  31. 31. Storage • OpenStack Default ist iSCSI und tgtd • »Das Problem bleibt dem geneigten Leser zur Übung überlassen.«
 • Storage Vendors finden diesen Ansatz voll super. • https://wiki.openstack.org/wiki/CinderSupportMatrix 20
  32. 32. Storage: Ceph - the good • Bandbreite sehr gut • Multithreaded-IOPS gut • Sehr robust 21
  33. 33. Storage: Ceph - the bad • CRUSH • Datenposition von der Cluster-Topologie abhängig • Bei Topologie-Änderungen sinnlose Datenschaufelei • Braucht ein eigenes Storage-Netzwerk im Hintergrund bei Rebalancing/Recovery/Cluster-Reorganisation 22
  34. 34. Storage: Ceph - the ugly • Sequentielle IOPS fatal langsam (200 IOPS). • MySQL Slave auf Ceph-Volume macht 200 Commit/s • Windows 8.1 bootet von Ceph-Volume in circa 15 Minuten. 23
  35. 35. Erkenntnis #3:
 Pure Play OpenStack wird nicht sinnvoll funktionieren.
 OpenStack ist kein funktionierendes Open Source Projekt. 24
  36. 36. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig 25
  37. 37. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig 25 "Magento Indexer" Single-Threaded Database Updates
  38. 38. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig 25
  39. 39. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig 25 Wo nichts ist kann man nichts quotieren. Kleine IOPS = große Schrittweite bei Schwankungen.
  40. 40. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig • SSD schwierig - Preis vs. dauerhafte Performance 25
  41. 41. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig • SSD schwierig - Preis vs. dauerhafte Performance 25 Zielpreis derzeit 1 EUR/GB, gleichförmige Performance wichtiger als hohe Spitzenleistung
  42. 42. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig • SSD schwierig - Preis vs. dauerhafte Performance • Caches schwierig 25
  43. 43. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig • SSD schwierig - Preis vs. dauerhafte Performance • Caches schwierig 25 Working Set > Cache bedeutet, man arbeitet mit dem nackten Eisen.
  44. 44. Storage: Anforderungen vs. Multitenancy • IOPS-Anforderungen machen SSD notwendig • IOPS Quotas machen SSD notwendig • SSD schwierig - Preis vs. dauerhafte Performance • Caches schwierig 25
  45. 45. Erkenntnis #4:
 Caching ist genau so Problem 
 wie es Lösung ist. 26
  46. 46. Network Mercury Redstone Connector MR-1 (1960) https://www.flickr.com/photos/jurvetson/5691350527 Steve Jurvetson (CC-BY)
  47. 47. Network: Anforderungen • Hoster-Szenario: • Topologie: Wait-Free, Oversubscription-Free • Redundanz: SPOF-Free • Multi-Tenancy: Isolation und Quotas • Außerdem: • Storage Traffic mit tragen 28
  48. 48. –Joe Random Alphauser „Wir haben einmal ein paar Dutzend VMs mit Hadoop ausgerollt und Terasort gespielt.“ 29 http://bradhedlund.com/2012/01/25/construct-a-leaf-spine-design-with-40g-or-10g-an-observation-in-scaling-the-fabric/
  49. 49. Notwork: Der Default • Open vSwitch, GRE-Ball, Broadcast-Problem, Chokepoint, SPOF 30 SPOF
  50. 50. Notwork: Der Default • Open vSwitch, GRE-Ball, Broadcast-Problem, Chokepoint, SPOF • In aktuellen Releases nur marginal weniger hirntotes Design. 30 SPOF
  51. 51. Erkenntnis #5:
 Ok, Netz geht also auch nicht. 31
  52. 52. Suchen wir also eine andere Lösung…32
  53. 53. Opencontrail: the good, … • Open Source Projekt von Juniper • Verwendet vorhandene Hardware-Routing-Infrastruktur • skaliert, SPOF- und Chokepoint-frei • basierend auf MPLS, BGP, und anderen gut verstandenen Protokollen • liefert im Gegensatz zu Opendaylite tatsächlich was 33
  54. 54. Opencontrail: the bad, … • Contrail von Juniper gekauft, kein Vertriebs/ Produktkonzept • kaum Dokumentation, schlechtes Release- Management, schlechte Paketierung • lustige Support-Organisation 34
  55. 55. … and the ugly. https://www.flickr.com/photos/59145750@N03/5559004171 Mara Tr. (CC-BY 2.0)
  56. 56. Technology-Jenga • Opencontrails "Stack" • vrouter (.ko), if-map, Sandesh (XML over Thrift!) • C++, Python, node.js, irond (Java) • redis, Cassandra, Zookeeper • xmpp, BGP, MPLS 36
  57. 57. Technology-Jenga • Opencontrails "Stack" • vrouter (.ko), if-map, Sandesh (XML over Thrift!) • C++, Python, node.js, irond (Java) • redis, Cassandra, Zookeeper • xmpp, BGP, MPLS • Hat das schon mal jemand in ein Jobprofil geschrieben und dafür Kandidaten interviewed? 36
  58. 58. Erkenntnis #6:
 Das ist kein auf Contrail beschränktes Problem. 37
  59. 59. Network: Generell nicht unlimitiert skalierbar Ferme des étoiles,© Jean-Claude Pignoux
  60. 60. Was so in der Packung ist… https://www.flickr.com/photos/markjsebastian/4217877353/ Mark Sebastian (CC BY-SA 2.0)
  61. 61. Generelle Anforderungen, 2015 • Jede verteilte Anwendung: • NTP, zentrales Logging, zentrales Monitoring • funktionale Validierung von Clustercomponenten und sauberer Startup • interne Kommunikation Kyle-Kingsbury-proof • CA, encrypted data in flight, optionally encrypted data at rest • User-Story für Live-Upgrades, mit Canaries 40
  62. 62. OpenStack Lieferumfang… https://www.flickr.com/photos/z287marc/3189567558/ z287marc (CC BY 2.0)
  63. 63. Wildes Gebastel geht los… https://www.flickr.com/photos/nauright/11341288174/ Romana Klee (CC BY-SA 2.0)
  64. 64. Das ist kein isoliertes Problem… • Starte 20 VMs mit ein paar Netzen in einem HEAT-Stack… • … und der ganze Cluster geht aus. 43
  65. 65. Das ist kein isoliertes Problem… • Starte 20 VMs mit ein paar Netzen in einem HEAT-Stack… • … und der ganze Cluster geht aus. • Nova wartet nicht auf Rückmeldungen von Cinder, sondern geht nach $timeout Sekunden einfach aus. 43
  66. 66. Das ist kein isoliertes Problem… • Starte 20 VMs mit ein paar Netzen in einem HEAT-Stack… • … und der ganze Cluster geht aus. • Nova wartet nicht auf Rückmeldungen von Cinder, sondern geht nach $timeout Sekunden einfach aus. • "Sind wir blöd, oder ist OpenStack blöd? Laß uns mal ein paar öffentliche Clouds testen…" 43
  67. 67. Ergebnis • Telefon klingelt. • "Was immer Ihr da tut, könnt Ihr bitte was anderes machen?" 44 "Rotes Telefon", http://de.wikipedia.org/wiki/Datei:Jimmy_Carter_Library_and_Museum_99.JPG User:Piotrus (CC-BY 3.0)
  68. 68. Das ist kein isoliertes Problem…45
  69. 69. Das ist kein isoliertes Problem…45 Getestet mit Devstack in VMware Fusion auf einem MacBook Air im St. Oberholz?
  70. 70. Das ist kein isoliertes Problem… • "Kannst Du mal gucken, meine Instances starten nicht." 46
  71. 71. Das ist kein isoliertes Problem… • "Kannst Du mal gucken, meine Instances starten nicht." • Nach längerer Debug-Session stellt sich raus, daß auf cloud17 libvirt auf eine dysfunktionale Weise konfiguriert ist. 46
  72. 72. Das ist kein isoliertes Problem… • "Kannst Du mal gucken, meine Instances starten nicht." • Nach längerer Debug-Session stellt sich raus, daß auf cloud17 libvirt auf eine dysfunktionale Weise konfiguriert ist. • OpenStack nimmt Compute-Nodes in den Cluster auf, sobald sie im AMQP sichtbar werden (sich also als Consumer registrieren.) 46
  73. 73. Das ist kein isoliertes Problem...47 Ceilometer
  74. 74. Was ist eigentlich das Problem? https://www.flickr.com/photos/jdhancock/8395113234 JD Hancock (CC BY 2.0)
  75. 75. „Any VM, anywhere.“ 49
  76. 76. „Wir bauen eine Virtualisierungsplattform für Hoster/ Firmen-IT/Abteilungs-IT.“ 50
  77. 77. Problemspec vs. Produktspec • Anforderungen an • Tenant Isolation, • Billing Model, • Operations Model, • Development Model, • Skalierbarkeit 51
  78. 78. Prototypen vs. Produktmodell "Prototype in the round file", https://www.flickr.com/photos/generated/3313311558 Jared Tarbell (CC-BY 2.0)
  79. 79. Fokus auf das Kernproblem
 vs.
 Aufsplitterung in mehr Komponenten 53
  80. 80. “The Big Tent” https://www.flickr.com/photos/fmckinlay/2410261506 Fiona Shields (CC BY-NC-ND 2.0)
  81. 81. "The problem with the Big Tent is that it is full of clowns." https://www.flickr.com/photos/fmckinlay/2410261506 Fiona Shields (CC BY-NC-ND 2.0)
  82. 82. –Maik Zumstrull „Statt eine funktionierende Lösung zu haben kann ich nun unter 13 kaputten Lösungen wählen.“ 56
  83. 83. Demokratie ist kein gutes Software-Architekturmodell • Produktdefinition == Zieldefinition 57
  84. 84. Demokratie ist kein gutes Software-Architekturmodell • Produktdefinition == Zieldefinition • Wer ist der Kunde und was will er? 57
  85. 85. Demokratie ist kein gutes Software-Architekturmodell • Produktdefinition == Zieldefinition • Wer ist der Kunde und was will er? • Welche Eigenschaften muß das Produkt haben, um Teil der Lösung statt Teil des Problems zu sein? 57
  86. 86. Demokratie ist kein gutes Software-Architekturmodell • Qualitätskontrolle 58
  87. 87. Demokratie ist kein gutes Software-Architekturmodell • Qualitätskontrolle • "Aber Openstack hat doch Blueprints, CI und Code Review” 58
  88. 88. Demokratie ist kein gutes Software-Architekturmodell • Qualitätskontrolle • "Aber Openstack hat doch Blueprints, CI und Code Review” • Ohne Zieldefinition keine Idee von Anforderungen an Scale, Workload Types, Security. 58
  89. 89. Who actually votes on your commit…
  90. 90. Demokratie ist kein gutes Software-Architekturmodell • Beherrschbarer, schmaler Technologie-Stack 60
  91. 91. Demokratie ist kein gutes Software-Architekturmodell • Beherrschbarer, schmaler Technologie-Stack • Eine empfohlene, getestete Lösung mit einer Best Practice für das Deployment, statt einer Plugin- Schnittstelle. 60
  92. 92. Demokratie ist kein gutes Software-Architekturmodell • Beherrschbarer, schmaler Technologie-Stack • Eine empfohlene, getestete Lösung mit einer Best Practice für das Deployment, statt einer Plugin- Schnittstelle. • Standardlösungen für vergleichbare Probleme in benachbarten Teilprojekten (“Architecture Refactoring”). 60
  93. 93. Monasca
  94. 94. How to win at Hipsterbingo… • »Monasca is an open-source multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a- service solution that integrates with OpenStack.
 
 It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine.« 62
  95. 95. How to win at Hipsterbingo… • »Monasca is an open-source multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a- service solution that integrates with OpenStack.
 
 It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine.« 62 Bingo!
  96. 96. Demokratie ist kein gutes Software-Architekturmodell • Sinnvoll vs. Hyped • “Docker ist ja so was wie Openstack, aber aus Dev statt aus Ops-Sicht. 
 
 Wäre ja toll, wenn man das vereinen könnte.” 63 https://twitter.com/martinisoft/status/527191803603468288
  97. 97. Außerdem…64
  98. 98. Außerdem…64
  99. 99. Was bleibt? 65
  100. 100. Was bleibt? • Im Moment ist Openstack ist kein Produkt, sondern eine Kiste Schrauben. • Qualität der Komponenten stark unterschiedlich.
 • Kein anderes Projekt hat so viel Momentum. • Die meisten Projekte haben keine Mandantenfähigkeit. 66
  101. 101. Was bleibt? • Das Projekt ist tief im Hype-Zyklus: • Anwender und damit Produktdefinitionen fehlen. • Uneinigkeit über akzeptable Lösungen. • Hersteller glauben, sie könnten “gewinnen” und pushen ihre propietären Lösungen. • Anwender fehlen. 67
  102. 102. Was bleibt? • “Apache” ist auch ein Vendor-Mechanismus zur Open- Source-Zähmung • Siehe auch Hadoop • basierend auf den Erfahrungen mit Java 68
  103. 103. 69 ?
  104. 104. 3. Openstack DACH Tag 11. Juni 2015 Berlin http://openstack-dach.org 70

×