Private Cloud mit Open Source

  • Published on
    24-Jun-2015

  • View
    588

  • Download
    0

Embed Size (px)

DESCRIPTION

Wie baut man ein privates Amazon AWS mit Open Source? In diesem Vortag wird die Realisierung einer privaten Cloud vom Konzept bis hin zum produktiven System vorgestellt. Die Abstraktion von einzelnen Servern, Festplatten und Netzwerkverbindungen zu allgemein verfgbaren Rechen- und Speicherressourcen ist die Grundidee des Cloud Computing. Hardware wird dadurch zu einer flexiblen Ressource, die sich agil und kosteneffizient nutzen lsst. Amazon hat mit AWS diese Idee als Public Cloud fr die breite ffentlichkeit zugnglich gemacht. Es gibt jedoch gute Grnde eine eigene, private Cloud zu bauen. Diese Grnde knnen Sicherheitsbedenken und rechtliche Kriterien sein. Zudem erleichtert die vollstndige Kontrolle des gesamten Protokollstacks die Entwicklung und Wartung von verteilten und hochverfgbaren Systemen. Dr. Lukas Pustina und Daniel Schneller von der codecentric AG haben fr das Startup CenterDevice eine private Cloud vom Konzept bis zum produktiven Einsatz realisiert. Dabei wurde ausschlielich Open Source eingesetzt und ein "privates Amazon geschaffen. In dieser Cloud laufen eine Produktions- und verschiedene Staging und Testumgebungen. In diesem Vortrag sollen anhand der Entstehungsgeschichte der CenterDevice Cloud konkret Konzepte, Entscheidungen und Probleme erlutert werden. Dabei wird auch die ein oder andere Anekdote aus dem tglichen Wahnsinn der Cloud Administration nicht fehlen. Der Vortrag beleuchtet zunchst, warum explizit nur freie Software genutzt wird und welche fr das Projekt ausgewhlt worden ist. Anhand spezifischer Anforderungen werden die eingesetzten Komponenten Ubuntu Linux, Ansible, Ceph Object Store und OpenStack eingefhrt. Die erlebten Stolpersteine und Probleme sowie deren Lsung werden zusammen mit Performance Messungen vorgestellt. Zum Abschluss gibt es einen Blick auf die Produktionsumgebung mit einer Live Demo. Das Fazit der beiden ist, dass sich die Investition in eine Open Source Cloud gelohnt hat. Jedoch gibt es viele kleine und groe Probleme bis zum produktiven System zu berwinden. Die Zuhrer des Vortrags sollen am Ende selbst einschtzen knnen, in wie fern sich eine solche Lsung fr ihre eigene Umgebung eignet. Links: Handout: https://public.centerdevice.de/399612bf-ce31-489f-bd58-04e8d030be52 Ansible: https://blog.codecentric.de/en/2014/06/ansible-simple-yet-powerful-automation/ Ceph: https://blog.codecentric.de/en/2014/03/ceph-object-storage-fast-gets-benchmarking-ceph/

Transcript

  • 1. Private Cloud mit OpenSource Dr. Lukas Pustina und Daniel Schneller codecentric AG

2. Flexible, leistungsfhige Private Clouds mit OpenSource 3. @drivebytesting @dschneller 4. Private Cloud 5. ?Private Cloud Was ist eine Cloud? Welche Vorteile hat eine private Cloud? 6. ! Abstraktion Abstraktion von Bare Metal Hardware 7. Abstraktion von Hardware Bessere Auslastung und Ausnutzung Hhere Ausfallsicherheit Leichtere Skalierbarkeit Immutable Infrastructure 8. ! Kontrolle Betriebs-, Daten- und Informationssicherheit 9. Kontrolle Fullstack Verstndnis Datensicherung auf allen Ebenen Klare echte Zugriffssicherheit 10. ! Leistung Hhere Leistungsfhigkeit 11. Leistung Zugeschnittene Performance Dedizierte Ressourcen 12. Demo OpenStack Horizon Dashboard 13. Cluster Layer Cake 14. Storage Virtualization Bare Metal Hardware Compute Virtualization Network Virtualization Virtual Infrastructure Application 15. 1. Bare Metal 16. Bios Update 3 Betriebssysteme und 1 GB fr ein Update 17. iDRAC und VLAN Out of Band Management ohne Band und Management 18. LACP IEEE 802.3ad != IEEE 802.3ad [node01] > iperf -s -B node01.ceph-cluster! [node02] > iperf -c node01.ceph-cluster -P 2! [node03] > iperf -c node01.ceph-cluster -P 2! ------------------------------------------------------------! Server listening on TCP port 5001! Binding to local address node01.ceph-cluster! TCP window size: 85.3 KByte (default)! ------------------------------------------------------------! [ 4] local 10.102.5.11 port 5001 connected with 10.102.5.12 port 49412! [ 5] local 10.102.5.11 port 5001 connected with 10.102.5.12 port 49413! [ 6] local 10.102.5.11 port 5001 connected with 10.102.5.13 port 59947! [ 7] local 10.102.5.11 port 5001 connected with 10.102.5.13 port 59946! [ ID] Interval Transfer Bandwidth! [ 4] 0.0-10.0 sec 342 MBytes 286 Mbits/sec! [ 5] 0.0-10.0 sec 271 MBytes 227 Mbits/sec! [SUM] 0.0-10.0 sec 613 MBytes 513 Mbits/sec! [ 6] 0.0-10.0 sec 293 MBytes 246 Mbits/sec! [ 7] 0.0-10.0 sec 338 MBytes 283 Mbits/sec! [SUM] 0.0-10.0 sec 631 MBytes 529 Mbits/sec 19. 2. Provisionierung 20. ?Softwaresetup Wie installieren wir System und Anwendungen? 21. ! Automation Keine Installation oder Konguration von Hand 22. Automation Reproduzierbarkeit Nachvollziehbarkeit Lauffhige Dokumentation 23. Automation Agentenlos Flache Lernkurve Leistungsstark 24. 3. Storage 25. ?Storage Wo und wie speichern wir unsere Daten? 26. ! Ceph Unied, distributed storage system designed for excellent performance, reliability and scalability 27. Ceph Storage Cluster Object Store Extrem skalierbar Kein Single Point of Failure 28. Ceph Komponenten 29. Ceph Storage Cluster OSDs und Monitors CRUSH Algorithmus Verschiedene APIs 30. Keine Dateien So viele Files, und doch kein System. 31. ! OpenStack Ceph wird als Backend Store fr Images und Volumes direkt untersttzt. 32. 4. Compute 33. ?CPUs ausnutzen Wie nutzt man die vorhandenen CPU Kapazitten bestmglich aus? 34. ! OpenStack Nova Compute Service 35. OpenStack Nova VM Management Flavors Scheduler Analog EC2 36. OpenStack Nova Verschiedene Hypervisors KVM by Default Cloud Init (Live) Migration 37. 5. Network 38. ?Netzwerk Wie werden virtuelle Maschinen untereinander und mit der Auenwelt verbunden? 39. ! OpenStack Neutron OpenStack Software Dened Networking. 40. OpenStack Neutron Netzwerk wie VMs virtualisiert Keine Kabel mehr Beliebig viele Netze 41. OpenStack Neutron Access Groups Floating IPs Projektindividuell 42. Netzwerktopologie in Horizon 43. CenterDevice 44. Systemberblick 45. Systemberblick 46. Systemberblick 47. Systemberblick 48. Systemberblick 49. Dokumente in Ceph Node 1 OSD 1 Rados GW Node 2 Rados GW Node 3 Rados GW Node 4 OSD 48 Rados GW VMs Bare Metal VM 1 Ceph HAProxy CenterDevice Swift VM 1 HAProxy CenterDevice Swift VM 1 HAProxy CenterDevice Swift VM HAProxy CenterDevice Swift 50. Zukunft 51. Nchste Schritte Partitionierung der virtuellen Maschinen System Level Virtualisierung Immutable Deployment 52. Zum Schluss 53. Handout bei CenterDevice 3 Der Weg in die private Cloud ist steinig. Be- geben Sie sich auf ihn, stehen Sie vor zahl- losen Entscheidungen und der Auswahl aus einer Vielzahl von Technologien. Dazu ge- hren insbesondere die zur Virtualisierung der Speicher- und Rechenkapazitten. Wir setzen hierbei fr die codecentric AG auf den Storage Cluster Ceph und die Virtuali- sierungsplattform OpenStack, mit denen wir eine private Cloud fr die Firma CenterDevice erfolgreich umgesetzt haben. Ceph und OpenStack sind mchtige Plattfor- men, die sich hervorragend ergnzen und au- ergewhnliche Leistung bieten. Aus diesem Grund werden sie von vielen Firmen produk- tiv eingesetzt. In diesem Sonderheft der code- centric AG beschreiben wir die Grundlagen dieser Technologien in den beiden folgenden Artikeln Grundlagen und technische Konzep- te des Ceph-Storage-Clusters und Mit Open- Stack eine eigene Cloud aufbauen, die zuerst in den Ausgaben 7.2014 und 8.2014 im Java- Magazin erschienen sind. Viel Spa beim Lesen. Fr alle Fragen, die of- fen bleiben, sind wir fr Sie da. Dr. Lukas Pustina und Daniel Schneller 5 Dr. Lukas Pustina hat langjhri- ge Erfahrung in der Entwicklung und dem Betrieb von verteilten Systemen. Er hat dabei stets ein Auge auf neue Technologien in diesem Umfeld. Zur Zeit arbei- tet er als Leiter des Bereichs Inf- rastruktur bei der CenterDevice GmbH an der Realisierung einer hochskalierbaren Cloudsoftware. lukas.pustina@codecentric.de @drivebytesting Daniel Schneller beschftigt sich seit ber 15 Jahren mit dem Entwurf und der Umset- zung komplexer Software- und Datenbanksysteme und ist un- ter anderem Autor des MySQL Admin Cookbook. Er leitet der- zeit er bei der CenterDevice GmbH den Bereich Mobile De- velopment. daniel.schneller@codecentric.de @dschneller Grundlagen und technische Konzepte des Ceph-Storage-Clusters Ceph ist ein Storage-Cluster, der auf handelsblicher Serverhardware luft und problemlos Speicher- mengen von wenigen hundert Gigabyte bis hin zu Peta- oder gar Exabytegre bereitstellen kann. Dabei sorgt eine intelligente Peer-to-Peer- Kommunikation dafr, dass alle abgelegten Daten redundant und hochverfgbar gespeichert werden. Dieser Artikel beleuchtet die grundlegenden Konzepte von Ceph am Beispiel unserer Installation. Diese stellt derzeit insgesamt 175 TB Speicherplatz verteilt ber 48 Festplatten in vier Servern als hochperformanter Object Store und verteiltes Dateisystem zur Verfgung. Abgrenzung zu SANs Wenn schnelle Speicherkapazitt in groer Menge bentigt wird, richten sich die Blicke traditionell in Richtung Storage Area Networks (SAN). Diese oft via Fibre Channel angebun- denen Speichernetzwerke bieten den ange- schlossenen Rechnern virtuelle Block-Devices zum Beispiel ber das iSCSI-Protokoll an. Im Hintergrund sorgen sie fr eine automatische Verteilung der Daten auf eine Anzahl indivi- dueller Festplatten. SANs sind weit verbrei- tet, haben aber einige Nachteile. Neben dem Komponenten begibt man sich in ein Abhn- gigkeitsverhltnis vom jeweiligen Hersteller, da trotz Bestrebungen in dieser Richtung eine Interoperabilitt zwischen Systemen verschie- dener Anbieter nicht gewhrleistet ist. Soll ein SAN hochverfgbar ausgelegt werden, bedeutet dies normalerweise eine Verdopp- lung der Hardware, einhergehend mit den entsprechenden Kosten. Eine nachtrgliche Aufrstung ist nur im Rahmen dessen mg- lich, was der Hersteller des Systems dafr an kompatiblen Optionen vorsieht. Im Gegensatz dazu basiert Ceph vollstndig auf handelsblicher Serverhardware mit da- zugehrigen einfachen, zum Beispiel via SAS verbundenen, Speichermedien. Diese knnen - geschlossen werden. Die Kommunikation zwischen den Komponen- ten erfolgt ber 1-GBit- oder 10-GBit-Ethernet und kommt ohne zentrale Komponenten wie zum Beispiel SAN-Controller aus. Damit gibt es keinen Single Point of Failure. Die ein- zelnen Knoten tauschen sich untereinander ber Peer-to-Peer-Kommunikation aus, um abgelegte Daten zuverlssig und schnell abzu- legen bzw. darauf zugreifen zu knnen. RADOS Kernbestandteil von Ceph ist RADOS, das Re- liable A tonomic Distributed Object Storage. Hierbei handelt es sich um einen verteilten Object Store, der die Intelligenz aller beteilig- ten Knoten nutzt, um die Notwendigkeit einer zentralen Verwaltungsinstanz zu vermeiden. RADOS skaliert durch die horizontale Vertei- lung aller anfallenden Aufgaben nahezu be- 6 7 liebig und trgt dabei Sorge dafr, dass ge- speicherte Daten dynamisch verteilt und bei - nisiert werden, gleichzeitig aber jederzeit zu- greifbar sind. Ein Objekt im Sinne von RADOS ist eine beliebi- ge Menge von Daten, die unter einem eindeuti- gen Schlssel abgelegt werden. Dabei spielt die Gre dieser Objekte keine wesentliche Rolle. Es kann sich dabei um einen nur wenige Bytes langen Text handeln oder um ein hunderte Gi- gabyte groes Disk Image. Object Storage Devices Ungeachtet aller logischen Strukturen ms- sen auch in Ceph letztlich Daten auf physi- schen Speichermedien abgelegt werden. In der Ceph-Terminologie handelt es sich hier- bei um so genannte Object Storage Devices (OSDs). Im Normalfall sind dies Festplatten. Es kann sich jedoch auch insbesondere zu Testzwecken um Loopback Devices oder einzelne Verzeichnisse in einem existierenden Dateisystem handeln. Fr den Produktions- einsatz werden in jedem Fall dedizierte Plat- ten empfohlen. Jede Platte wird im Rahmen der Installation von Ceph mit dem XFS-Dateisystem forma- tiert. In unserem Cluster ergeben sich dadurch 48 OSDs mit je ca. 3,7 TB formatierter Kapazi- tt; insgesamt also etwa 175 TB Speicherplatz. Zu beachten ist, dass Struktur und Inhalt der in diesen Dateisystemen gespeicherten Da- ten vollstndig Ceph obliegen. Jeder manuelle - fhrden und sollte daher dringend unterlas- sen werden. Fr jedes OSD wird auf dem jeweiligen Ser- ver ein einzelner Ceph-OSD-Daemon-Prozess gestartet. Dieser ist verantwortlich dafr, das Gert zu berwachen und den von ihm bereit- gestellten Platz fr den Cluster verfgbar zu machen. Die Aufgaben, die der OSD Daemon dabei bernimmt, sind vielfltig. Er erledigt unter anderem die berwachung der Verfgbarkeit des von ihm betreuten OSD, das Manage- ment der Netzwerkkommunikation mit Ceph- Clients und anderen OSD Daemons. Darber hinaus fhrt er regelmige Integrittschecks (Scrubbing) der gespeicherten Daten durch, um Datenkorruption durch Bit-Fehler oder an- zu korrigieren. Darber hinaus sind OSDs Objektredundanz verantwortlich. An dieser Stelle sei deshalb erwhnt, dass ex- plizit davon abgeraten wird, Ceph auf RAID Vo- lumes oder anderen bereits auf andere Weise virtualisierten Datentrgern aufzusetzen. Zen- trale Aufgabe der OSD Daemons ist es, je ein konkretes Stck Storage-Hardware zu verwal- Datensicherheit, im Cluster bereitzustellen. Dies ist jedoch nur dann mglich, wenn sie Medium haben und es in Eigenregie steuern knnen. Andernfalls kme es zu Wechselwir- kungen der verschiedenen Abstraktionsebe- nen, die in Summe negative Auswirkungen Performance htten. Skalierbarkeit Cephs theoretisch unbegrenzte Skalierbarkeit und Flexibilitt basiert auf einer breiten Ver- teilung aller anfallenden Aufgaben auf mg- lichst viele Maschinen. Ab einer bestimmten Clustergre wre selbst ein sehr leistungs- starker zentraler Objektbroker mit der Last - len Lookup Table und anderer Verwaltungs- aufgaben entstnde. Neben der reinen Lastverteilung bewirkt die Verwendung intelligenter Knoten weiterhin, dass Ceph den Ausfall von Teilen der Infra- struktur verkraften kann, ohne dass dadurch notwendigerweise der gesamte Cluster beein- trchtigt wrde. Eine Konsequenz dieses Verzichts auf eine zentrale Verwaltungsinstanz ist jedoch, dass Clients keine dedizierte Anlaufstelle haben, an die sie Anfragen und Aufgaben richten knn- ten. Ceph-Clients sind daher selbst mit einer Konkret verwenden sie den gleichen CRUSH- Algorithmus wie die OSD Daemons, um be- rechnen zu knnen, wo im Cluster sich die erreichen sind. CRUSH-Algorithmus Die Bestimmung des Ablageorts eines Objekts in Ceph erfolgt vollstndig ber den so ge- nannten CRUSH-Algorithmus [1] in praktisch konstanter Zeit. Der Algorithmus ermittelt dabei hnlich einer Hash-Funktion basie- rend auf einigen Eingabeparametern die tat- schlichen Ablageorte zu speichernder bzw. zu lesender Objekte. Dabei wird angestrebt, die Ressourcen im Cluster mglichst sinnvoll auszulasten. In die Berechnung gehen neben dem Objektnamen auch ein whlbarer Redun- danzlevel und eine clusterweite Gesamtzahl von Placement Groups ein. Eine Placement Group (PG) ist eine logische Gruppierung von Objekten, die jeweils auf dem gleichen Satz von physikalischen Gerten gespeichert wer- den (Abb. 1). Die Gesamtanzahl an Placement Groups wird beim ersten Aufsetzen des Clusters initial fest- gelegt, kann aber bei Bedarf, insbesondere bei - trglich angepasst werden. Ein typischer Wert liegt bei etwa 100 PGs pro OSD. Diese Vorgehensweise ermglicht es Ceph-Cli- ents, selbststndig zu bestimmen, welcher OSD Daemon fr die Speicherung eines Objekts zu- stndig ist und direkt mit diesem zu kommuni- zieren, anstatt hierfr einen dedizierten Dienst als Mittelsmann bemhen zu mssen. Eine besondere Rolle kommt dem jeweils ers- ten OSD zu, der fr ein Objekt errechnet wird. Er ist dafr verantwortlich, die vom Client er- haltenen Daten entsprechend des gewnsch- ten Grads an Redundanz an weitere OSDs zu bermitteln. Erst wenn alle Erfolg gemeldet haben, gilt eine Schreiboperation aus Sicht des Clients als abgeschlossen. Abbildung 2 zeigt, wie ein Objekt mit dreifacher Redundanz ge- speichert wird. 8 9 Stabile Zuordnungen CRUSH ist darauf ausgelegt an dieser Stelle im Unterschied zu klassischen Hash-Funktio- nen auch bei Vernderung der Eingabepara- meter mglichst stabile Ergebnisse zu liefern. ndert sich die Anzahl verfgbarer OSDs, zum Beispiel durch Ausfall einer Festplatte oder Hinzufgen weiterer zur Erhhung der Kapa- zitt, werden gerade so viele Daten wie ntig umverteilt, um wieder eine gleichmige Aus- lastung zu erzielen. Der berwiegende Teil der Daten bleibt an Ort und Stelle (Abb. 3). Im Gegensatz dazu htte die Verwendung einer echten Hash-Funktion die Umverteilung aller bestehenden Daten zur Folge. Da Ausflle und Erweiterungen ab einer gewissen Cluster-Dimension alltgliche Vorgnge sind, wre ein solches System bald nahezu ausschlielich mit Rebalancierung be- schftigt. Als zustzlichen Faktor kann Ceph jeden OSD basierend auf seiner Kapazitt und Leistung unterschiedlich gewichten, um insgesamt Abbildung 3 - eine mglichst ideale Ausnutzung aller Res- sourcen zu gewhrleisten. Hat etwa ein sp- ter zum Cluster hinzugefgter Server deutlich leistungsstrkere Hardware, wie zum Beispiel eine oder mehrere SSDs, die als dediziertes Medium fr das Schreiben von Journaleintr- - sichtigen und dieser Maschine mehr Arbeit zu...

Recommended

View more >