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 verfügbaren Rechen- und Speicherressourcen ist die Grundidee des Cloud Computing. Hardware wird dadurch zu einer flexiblen Ressource, die sich agil und kosteneffizient nutzen lässt. Amazon hat mit AWS diese Idee als Public Cloud für die breite Öffentlichkeit zugänglich gemacht.
Es gibt jedoch gute Gründe eine eigene, private Cloud zu bauen. Diese Gründe können Sicherheitsbedenken und rechtliche Kriterien sein. Zudem erleichtert die vollständige Kontrolle des gesamten Protokollstacks die Entwicklung und Wartung von verteilten und hochverfügbaren Systemen.
Dr. Lukas Pustina und Daniel Schneller von der codecentric AG haben für das Startup CenterDevice eine private Cloud vom Konzept bis zum produktiven Einsatz realisiert. Dabei wurde ausschließlich 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 erläutert werden. Dabei wird auch die ein oder andere Anekdote aus dem täglichen Wahnsinn der Cloud Administration nicht fehlen.
Der Vortrag beleuchtet zunächst, warum explizit nur freie Software genutzt wird und welche für das Projekt ausgewählt worden ist. Anhand spezifischer Anforderungen werden die eingesetzten Komponenten Ubuntu Linux, Ansible, Ceph Object Store und OpenStack eingeführt. Die erlebten Stolpersteine und Probleme sowie deren Lösung 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 große Probleme bis zum produktiven System zu überwinden. Die Zuhörer des Vortrags sollen am Ende selbst einschätzen können, in wie fern sich eine solche Lösung für 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/
Opensource Storage Lösung mit Ceph
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:Ceph
----
Opensource Cloud Solution with Ceph
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:Ceph
Wie baut man ein privates Amazon AWS mit Open Source? In diesem Vortag wird die Realisierung einer privaten Cloud vom Konzept bis hin zum Produktivsystem vorgestellt. Amazon hat mit AWS diese Idee als Public Cloud für die breite Öffentlichkeit zugänglich gemacht. Es gibt jedoch gute Gründe eine eigene, private Cloud zu bauen. Diese Gründe können Sicherheitsbedenken und rechtliche Kriterien sein. Dr. Lukas Pustina und Daniel Schneller von der codecentric AG haben für das Startup CenterDevice eine private Cloud realisiert. In diesem Vortrag werden konkret Konzepte, Entscheidungen und Probleme erläutert. Dabei wird auch die ein oder andere Anekdote aus dem täglichen Wahnsinn der Cloud Administration nicht fehlen. Anhand spezifischer Anforderungen werden die eingesetzten Komponenten Ubuntu Linux, Ansible, Ceph und OpenStack eingeführt.
Slides unseres Talks auf der DevOps Conference 2015 in Berlin.
Opensource Cloud Lösung mit openstack
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:OpenStack
----
Opensource Cloud Solution with openstack
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:OpenStack
LinuxTag 2008 - Virtuelle Cold-Standby Server mit LinuxSchlomo Schapiro
Cold-Standby-Server sind eine anerkannte Methode zur Realisierung hochverfügbarer Umgebungen. Will man damit mehrere Produktiv-Server absichern, steht schnell viel ungenutzte Hardware im Rechenzentrum herum. Mit Virtuellen Maschinen und einem SAN lässt sich dieser Overhead deutlich reduzieren.
Dabei wird ein Linux-Server aus dem SAN gestartet, so daß das System auf einer dedizierten Hardware und in einer Virtuellen Maschine lauffähig ist. Beim Ausfall der Hardware kann die VM das System sofort übernehmen, ohne daß Daten kopiert werden müssen.
Die Vorteile eines SAN kommen hierbei zum tragen und ermöglich erst die Gestaltung dieser Lösung. Am Beispiel SuSE Linux Enterprise Server wird die Technologie und die Implementierung vorgestellt.
Hintergrundinformationen zur Kundenumgebung, in der die Lösung entwickelt wurde, runden den Vortrag ab.
„Das Internet vergisst nicht, so sagt man. - Ganz so ist das aber nicht. Wer wichtige Daten langfristig und vollständig und
für die Nachwelt erhalten will, muss sich nicht nur Gedanken
über die zukünftige Lesbarkeit der Dateien machen, sondern
auch über ein technisch ausgereiftes Archivsystem, das
auf Jahrzehnte ausgelegt ist.“
AnyARK ist auf CentOS und Gluster basierendes Langzeitarchive, welche genau dafür ausgelegt ist.
Opensource Storage Lösung mit Ceph
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:Ceph
----
Opensource Cloud Solution with Ceph
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:Ceph
Wie baut man ein privates Amazon AWS mit Open Source? In diesem Vortag wird die Realisierung einer privaten Cloud vom Konzept bis hin zum Produktivsystem vorgestellt. Amazon hat mit AWS diese Idee als Public Cloud für die breite Öffentlichkeit zugänglich gemacht. Es gibt jedoch gute Gründe eine eigene, private Cloud zu bauen. Diese Gründe können Sicherheitsbedenken und rechtliche Kriterien sein. Dr. Lukas Pustina und Daniel Schneller von der codecentric AG haben für das Startup CenterDevice eine private Cloud realisiert. In diesem Vortrag werden konkret Konzepte, Entscheidungen und Probleme erläutert. Dabei wird auch die ein oder andere Anekdote aus dem täglichen Wahnsinn der Cloud Administration nicht fehlen. Anhand spezifischer Anforderungen werden die eingesetzten Komponenten Ubuntu Linux, Ansible, Ceph und OpenStack eingeführt.
Slides unseres Talks auf der DevOps Conference 2015 in Berlin.
Opensource Cloud Lösung mit openstack
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:OpenStack
----
Opensource Cloud Solution with openstack
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:OpenStack
LinuxTag 2008 - Virtuelle Cold-Standby Server mit LinuxSchlomo Schapiro
Cold-Standby-Server sind eine anerkannte Methode zur Realisierung hochverfügbarer Umgebungen. Will man damit mehrere Produktiv-Server absichern, steht schnell viel ungenutzte Hardware im Rechenzentrum herum. Mit Virtuellen Maschinen und einem SAN lässt sich dieser Overhead deutlich reduzieren.
Dabei wird ein Linux-Server aus dem SAN gestartet, so daß das System auf einer dedizierten Hardware und in einer Virtuellen Maschine lauffähig ist. Beim Ausfall der Hardware kann die VM das System sofort übernehmen, ohne daß Daten kopiert werden müssen.
Die Vorteile eines SAN kommen hierbei zum tragen und ermöglich erst die Gestaltung dieser Lösung. Am Beispiel SuSE Linux Enterprise Server wird die Technologie und die Implementierung vorgestellt.
Hintergrundinformationen zur Kundenumgebung, in der die Lösung entwickelt wurde, runden den Vortrag ab.
„Das Internet vergisst nicht, so sagt man. - Ganz so ist das aber nicht. Wer wichtige Daten langfristig und vollständig und
für die Nachwelt erhalten will, muss sich nicht nur Gedanken
über die zukünftige Lesbarkeit der Dateien machen, sondern
auch über ein technisch ausgereiftes Archivsystem, das
auf Jahrzehnte ausgelegt ist.“
AnyARK ist auf CentOS und Gluster basierendes Langzeitarchive, welche genau dafür ausgelegt ist.
Integrierte und dedizierte Backup Lösung von GFI MAXMAX2014DACH
GFI MAX bietet nun eine umfassende, robuste und sehr schnelle Backup-Lösung in Zwei fantastischen Versionen – Egal ob integriert oder als Standalone Lösung.
Sowohl GFI MAX Backup (Standalon/dediziert) und Managed Online Backup (integriert in GFI MAX RM) bieten einen Grad an militärischen Schutz für Ihren Kundendaten und sorgt so für Zufriedenheit zu einem guten Preis.
Mit einem Hybriden „Disk-to-Disk-to-Cloud“ (D2D2C) Ansatz, bei der True-Delta Technologie gibt keine Auswirkung auf die Bandbreitenauslastung und beschleunigt die Backups. Zusätzlich besteht die Möglichkeit des kostenfreien Seed-Loading-Service und viele weitere Vorteile. Nehmen Sie an dem Vortrag teil, umm mehr zu erfahren über die Unterschiede der beiden Lösungen und Ihren Nutzen.
Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)data://disrupted®
Zur Unterstützung von Big Data und Machine Learning Szenarien wurde am Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) der TU Dresden eine neue Speicherlandschaft mit „NVMe Storage“ (2 PB Kapazität und 2 TB/s Bandbreite, <100us Latenz) und „Warm Archive“ auf Basis des S3-Protokolls (10 PB Kapazität und 50 GB/s Bandbreite) aufgebaut. Dr. Michael Kluge vom ZIH (Abteilungsleiter System- und Dienstentwurf) erläutert die besonderen Anforderungen dieses Projektes und berichtet vom Aufbau und Betrieb der Umgebung.
Keepalived & HA-Proxy as an alternative to commercial loadbalancer - August 2014inovex GmbH
The speaker Jan Gehring is the initiator of the Rex Project, which he has developed in his free time since 2010. Jan works for inovex GmbH as a senior linux system architect and designs, optimises and deploys highly scalable, automated linux environments for customers. For 13 years he has been professionally with Linux and open source and could through numerous projects gained extensive practical experience. His duties include the design, construction and operation of systems. His focus is here in the Data Center Automation, highly available and highly scalable web architectures, and Java-based application servers.
Where are all transactions gone? Was in_der_cloud_alles_verboten_istRamon Anger
Mein Vortrag auf der OOP 2015
Where all the transactions gone?
Was in der Cloud alles verboten ist.
Gegenstand des Vortrags sind neun Dinge, die in der Cloud im Gegensatz zu inhouse-Anwendungen grundlegend anders sind. Darüber hinaus geht der Vortrag kurz auf DevOps für die Cloud und Organisation für die Cloud ein.
Ursprünglich hat mein Kollege Marc Bauer den Vorschlag eingereicht, hatte dann aber leider keine Möglichkeit, den Vortrag selbst zu halten.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Solr & Cassandra: Searching Cassandra with DataStax EnterpriseDataStax Academy
Wait! Back away from the Cassandra secondary index. It’s ok for some use cases, but it’s not an easy button. “But I need to search through a bunch of columns to look for the data… and I can’t model that in C*, even after watching all of Patrick McFadins data modeling videos. What do I do?” The answer, dear developer, is in DSE Search. With it’s easy Solr API, Lucene indexes (and fault tolerance) you can search data stored in your Cassandra database until your heart’s content. Take my hand. I will show you how.
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHagilemethoden
Slide of a workshop about DevOps with Docker in German.
DevOps mit Docker - ein Workshop für Softwareentwickler und Systemadministratoren
Docker zieht seit einiger Zeit viel Aufmerksamkeit auf sich, hauptsächlich weil es das aktuelle sehr populäre Thema DevOps adressiert. Bei Docker handelt es sich eine offene Plattform für Software-Entwickler und Sysadmins, mit der sie Software annähernd überall bauen, ausliefern und betreiben können. In diesem Workshop werden Sie lernen wie Software-Container gebaut, ausgeliefert, konfiguriert und betrieben werden. Der Vortragende wird sie anhand von praktischen Beispielen an seinen Erfahrungen teilhaben lassen.
www.opitz-consulting.com
Bei unserer Best-Practices-Konferenz inspire|IT in Frankfurt am Main haben unsere Experten Uwe Küchler und Simon Hahn am 15. April 2018 Anwendungsbeispiele und Vorteile des Oracle Database Security Assessment Tool DBSAT vorgestellt.
Container Services mit Docker
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:Docker
----
Container services with Docker
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:Docker
Dateisysteme und Datenbanken im Cloud ComputingLothar Wieske
Cloud Computing transformiert die Informationstechnik. Die Konzepte zum Storage fallen bei den Anbietern von Infrastructure-as-a-Service und Platform-as-a-Service einstweilen noch recht unterschiedlich aus. Ein Überblick über Blob, Block, Queue und Table Storage stellt die Möglichkeiten vor. In Minutenschnelle zur relationalen Datenbank mit automatischem Backup- und Patch-Management? Auch dazu gibt es einen Einstieg. Die Erläuterungen des theoretischen Hintergrunds des CAP-Theorems und der praktischen Nutzung von Eventual Consistency machen Sie fit, sich mit Amazon Dynamo, Google Bigtable und Apache Cassandra zu beschäftigen.
Häufig starten Oracle-Application-Express-Anwendungen als kleine, von Fachabteilungen gestartete Initiativen,
entwickeln sich dann aber schnell zu geschäftskritischen Anwendungen. Um diesem Umstand
gerecht zu werden, reicht der Rechner unter dem Schreibtisch nicht mehr aus. Dieser Artikel zeigt eine
mögliche Architektur, um Apex zukunftssicher zu betreiben.
Integrierte und dedizierte Backup Lösung von GFI MAXMAX2014DACH
GFI MAX bietet nun eine umfassende, robuste und sehr schnelle Backup-Lösung in Zwei fantastischen Versionen – Egal ob integriert oder als Standalone Lösung.
Sowohl GFI MAX Backup (Standalon/dediziert) und Managed Online Backup (integriert in GFI MAX RM) bieten einen Grad an militärischen Schutz für Ihren Kundendaten und sorgt so für Zufriedenheit zu einem guten Preis.
Mit einem Hybriden „Disk-to-Disk-to-Cloud“ (D2D2C) Ansatz, bei der True-Delta Technologie gibt keine Auswirkung auf die Bandbreitenauslastung und beschleunigt die Backups. Zusätzlich besteht die Möglichkeit des kostenfreien Seed-Loading-Service und viele weitere Vorteile. Nehmen Sie an dem Vortrag teil, umm mehr zu erfahren über die Unterschiede der beiden Lösungen und Ihren Nutzen.
Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)data://disrupted®
Zur Unterstützung von Big Data und Machine Learning Szenarien wurde am Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) der TU Dresden eine neue Speicherlandschaft mit „NVMe Storage“ (2 PB Kapazität und 2 TB/s Bandbreite, <100us Latenz) und „Warm Archive“ auf Basis des S3-Protokolls (10 PB Kapazität und 50 GB/s Bandbreite) aufgebaut. Dr. Michael Kluge vom ZIH (Abteilungsleiter System- und Dienstentwurf) erläutert die besonderen Anforderungen dieses Projektes und berichtet vom Aufbau und Betrieb der Umgebung.
Keepalived & HA-Proxy as an alternative to commercial loadbalancer - August 2014inovex GmbH
The speaker Jan Gehring is the initiator of the Rex Project, which he has developed in his free time since 2010. Jan works for inovex GmbH as a senior linux system architect and designs, optimises and deploys highly scalable, automated linux environments for customers. For 13 years he has been professionally with Linux and open source and could through numerous projects gained extensive practical experience. His duties include the design, construction and operation of systems. His focus is here in the Data Center Automation, highly available and highly scalable web architectures, and Java-based application servers.
Where are all transactions gone? Was in_der_cloud_alles_verboten_istRamon Anger
Mein Vortrag auf der OOP 2015
Where all the transactions gone?
Was in der Cloud alles verboten ist.
Gegenstand des Vortrags sind neun Dinge, die in der Cloud im Gegensatz zu inhouse-Anwendungen grundlegend anders sind. Darüber hinaus geht der Vortrag kurz auf DevOps für die Cloud und Organisation für die Cloud ein.
Ursprünglich hat mein Kollege Marc Bauer den Vorschlag eingereicht, hatte dann aber leider keine Möglichkeit, den Vortrag selbst zu halten.
Docker und Kubernetes Patterns & Anti-PatternsQAware GmbH
JavaLand 2018, Brühl: Vortrag von Josef Adersberger (@adersberger, CTO bei QAware).
Abstract:
Kubernetes und Docker sind trotz des hohen Verbreitungsgrads noch relativ junge Technologien. Viele Menschen machen gerade gute und teilweise auch schmerzliche Erfahrungen mit beiden. Der Vortrag bietet einen Katalog an Patterns und Antipatterns bei der Entwicklung von Anwendungen auf Basis Kubernetes und Docker. Der Katalog repräsentiert dabei die Erfahrung aus mehreren Industrieprojekten, die es bis in Produktion geschafft haben.
Es geht darum, was man bei Docker-Files und Kubernetes-Deskriptoren richtig und falsch machen kann; welche Architekturbausteine man einsetzen sollte; wie die Continuous Delivery Pipeline gestaltet werden sollte und wie Anwendungen auf Cloud-Native-Plattformen gut betreibbar und diagnostizierbar gemacht werden können.
Solr & Cassandra: Searching Cassandra with DataStax EnterpriseDataStax Academy
Wait! Back away from the Cassandra secondary index. It’s ok for some use cases, but it’s not an easy button. “But I need to search through a bunch of columns to look for the data… and I can’t model that in C*, even after watching all of Patrick McFadins data modeling videos. What do I do?” The answer, dear developer, is in DSE Search. With it’s easy Solr API, Lucene indexes (and fault tolerance) you can search data stored in your Cassandra database until your heart’s content. Take my hand. I will show you how.
Docker Workshop Experten Forum Stuttgart 2015, Agile Methoden GmbHagilemethoden
Slide of a workshop about DevOps with Docker in German.
DevOps mit Docker - ein Workshop für Softwareentwickler und Systemadministratoren
Docker zieht seit einiger Zeit viel Aufmerksamkeit auf sich, hauptsächlich weil es das aktuelle sehr populäre Thema DevOps adressiert. Bei Docker handelt es sich eine offene Plattform für Software-Entwickler und Sysadmins, mit der sie Software annähernd überall bauen, ausliefern und betreiben können. In diesem Workshop werden Sie lernen wie Software-Container gebaut, ausgeliefert, konfiguriert und betrieben werden. Der Vortragende wird sie anhand von praktischen Beispielen an seinen Erfahrungen teilhaben lassen.
www.opitz-consulting.com
Bei unserer Best-Practices-Konferenz inspire|IT in Frankfurt am Main haben unsere Experten Uwe Küchler und Simon Hahn am 15. April 2018 Anwendungsbeispiele und Vorteile des Oracle Database Security Assessment Tool DBSAT vorgestellt.
Container Services mit Docker
Deutsch/Englische Folien. Es gibt eine deutsche Video Aufzeichnung des Talks unter https://entropia.de/GPN15:Docker
----
Container services with Docker
German/English slides. There is a german recording to this talk at https://entropia.de/GPN15:Docker
Dateisysteme und Datenbanken im Cloud ComputingLothar Wieske
Cloud Computing transformiert die Informationstechnik. Die Konzepte zum Storage fallen bei den Anbietern von Infrastructure-as-a-Service und Platform-as-a-Service einstweilen noch recht unterschiedlich aus. Ein Überblick über Blob, Block, Queue und Table Storage stellt die Möglichkeiten vor. In Minutenschnelle zur relationalen Datenbank mit automatischem Backup- und Patch-Management? Auch dazu gibt es einen Einstieg. Die Erläuterungen des theoretischen Hintergrunds des CAP-Theorems und der praktischen Nutzung von Eventual Consistency machen Sie fit, sich mit Amazon Dynamo, Google Bigtable und Apache Cassandra zu beschäftigen.
Häufig starten Oracle-Application-Express-Anwendungen als kleine, von Fachabteilungen gestartete Initiativen,
entwickeln sich dann aber schnell zu geschäftskritischen Anwendungen. Um diesem Umstand
gerecht zu werden, reicht der Rechner unter dem Schreibtisch nicht mehr aus. Dieser Artikel zeigt eine
mögliche Architektur, um Apex zukunftssicher zu betreiben.
Fachposter, 2017: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Fachhochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM).
Bestellbar unter https://www.sigs-datacom.de/order/poster/Cloud-Native-Applikationen-Poster-2017.php
(Dokument bitte herunterladen für bessere Lesbarkeit)
Die Oracle Datenbank und Apache Hadoop
DOAG -Big Data für Oracle Entwickler: Zweitagesveranstaltung mit Hands-On - 25.09.2014 in Köln
DOAG 2014 -Die größte Anwenderkonferenz rund um alle Oracle Themen, vom 18.11.2014 - 20.11.2014 in Nürnberg
Die Oracle Datenbank in die Welt von Hadoop und NoSQL integrieren
Wie lassen sich die beiden Welten, Oracle RDBMS und der NoSQL Ansatz sinnvoll für die Archivierung und das Datensammeln einsetzen?
Ziel des Vortrags ist es aufzuzeigen, wie die Kombinationen aus den Vorteilen der beiden Welten für die Analyse und Archivierung von Daten eingesetzt werden kann.
Hadoop, mit einer entsprechen Container Datenbank Lösung, eignet sich gut, um im ersten Schritt Daten zu sammeln und/oder im letzten Schritt Daten zu archivieren.
Die eigentliche Oracle RDBMS Datenbank kann dabei schnell und schlank gehalten werden, um Hardware und damit Lizenzkosten einzusparen.
Es werden Architekturansätze aufgezeigt, wie die Integration der Oracle RDBMS und NoSQL Datenbank in das Hadoop Ökosystem dabei erfolgen kann.
Mit den kostenpflichtigen Adaptern der Oracle RDBMS lässt sich zwar einfacher eine tiefe Integration mit Hadoop erreichen, aber auch mit den freien Lösungen kann bereits eine umfangreiche Lösung implementiert werden.
Fachposter, 2018: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Fachhochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM).
Bestellbar unter http://software-poster.sigs-datacom.de/i/37rTk-hM56nmgYGGuwNK_yKFgfkHtbQjtpKeTmPZ6jw
(Dokument bitte herunterladen für bessere Lesbarkeit)
Caching - Hintergründe, Patterns und Best PracticesMichael Plöd
Das Thema Caching ist für zahlreiche Business Anwendungen relevant und der Markt für Caching-Lösungen reicht von einfachen lokalen Caches bis hin zu mächtigen und komplexen Data Grids. Ein weiteres Differenzierungsmerkmal ist die Konsistenzgarantie beziehungsweise die transaktionale Integrität, welche die unterschiedlichen Lösungen bieten. Allerdings unterscheiden sich Anwendungen, welche Geschäftsprozesse in gewachsenen Unternehmenslandschaften umsetzen stark von sozialen Netzwerken oder Internetdiensten, welche aus dem Startup-Umfeld kommen.
Der Vortrag adressiert in erster Linie das erste Szenario: Caching in Unternehmensanwendungen, welche auf Basis einer bereits bestehenden Infrastruktur umgesetzt werden. Hierbei werden zuerst die Herausforderungen, die diese Anwendungen an das Thema Caching stellen, vorgestellt. Aspekte die hierbei betrachtet werden sind: Security, Monitoring, Audit-Compliance, Art der Daten sowie Geschäftsprozesse. Im zweiten Teil werden unterschiedliche Arten des Cachings vorgestellt und im Hinblick auf die eben erwähnten Herausforderungen bewertet. Abschließend geht der Vortrag darauf ein, welche Patterns und Best Practices sich in der Praxis bewährt haben und wie das Thema Caching möglichst transparent und deterministisch in Business-Anwendungen integriert werden kann.
Sven Schlarb of the Austrian National Library presented SCAPE (in German). Besides giving a general overview of SCAPE the presentation also includes descriptions of SCAPE solutions, including tools, software integration, planning, and more.
The presentation was given at the Austrian Library day on ‘National Initiatives on Digital Information. Repositories, Research data and long-term preservation in Austria’ (http://www.obvsg.at/voeb-obvsg-bibliothekstage-2013/programm-410/) on 4 October 2013 in Vienna.
Wenn Sie Solr vs. Elasticsearch in Google eingeben, bekommen Sie eine ganze Reihe von Blogs, Artikeln, Vergleichen, Meinungen und Gedanken, die sich diesem Thema widmen. Warum sollten Sie sich dieses Webinar also anhören und ansehen? Weil keiner der Links, die Sie über Google finden, tatsächlich die aktuellen Versionen der beiden Technologien aus dem Bereich Open Source Suchmaschinen abdeckt, sondern auf teilweise sehr betagte Artikel führen. Gerade im Open Source Bereich ist Aktualität jedoch entscheidend, denn hier werden Entwicklungen in teilweise rasantem Tempo vorangetrieben.
Aber nicht nur die Tatsache, dass es sich hierbei um ein tagesaktuelles Webinar handelt, sondern auch die Tatsache, dass es zwei führende Open Source Suchserver gibt, macht die Notwendigkeit, diese beiden Projekte zu vergleichen, offensichtlich. Ist Elasticsearch ein momentaner Trend, dem man folgen sollte? In welchen Gebieten ist Apache Solr die wegweisende Technologie? Gibt es Branchen, in denen sich der Einsatz einer Technologie verbietet oder besonders anbietet? Ist Elasticsearch im Gegensatz zu Solr wirklich schemafrei und warum bringt mir das einen Vorteil? Diesen und noch mehr Fragen werden wir auf den Grund gehen, um Sie letztendlich bei der Beantwortung der Frage zu unterstützen, auf welches Pferd Sie in Ihrem Unternehmen setzen sollten.
Als neutraler Technologieberater, der Partnerschaften zu LucidWorks und Elasticsearch pflegt, sind wir in der Lage, diesen Vergleich technisch, strategisch und konzeptionell zu ziehen. Verpassen Sie diese einmalige Gelegenheit also nicht!
59. 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-
hören insbesondere die zur Virtualisierung
der Speicher- und Rechenkapazitäten.
Wir setzen hierbei für die codecentric AG auf
den Storage Cluster Ceph und die Virtuali-
sierungsplattform OpenStack, mit denen wir
eine private Cloud für die Firma CenterDevice
erfolgreich umgesetzt haben.
Ceph und OpenStack sind mächtige Plattfor-
men, die sich hervorragend ergänzen und au-
ßergewöhnliche 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. Für alle Fragen, die of-
fen bleiben, sind wir für Sie da.
Dr. Lukas Pustina und Daniel Schneller
5
Dr. Lukas Pustina hat langjähri-
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 beschäftigt
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 handelsüblicher Serverhardware läuft und problemlos Speicher-
mengen von wenigen hundert Gigabyte bis hin zu Peta- oder gar Exabytegröße bereitstellen kann. Dabei
sorgt eine intelligente Peer-to-Peer- Kommunikation dafür, dass alle abgelegten Daten redundant und
hochverfügbar 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 Verfügung.
Abgrenzung zu SANs
Wenn schnelle Speicherkapazität in großer
Menge benötigt 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 für 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 Abhän-
gigkeitsverhältnis vom jeweiligen Hersteller,
da trotz Bestrebungen in dieser Richtung eine
Interoperabilität zwischen Systemen verschie-
dener Anbieter nicht gewährleistet ist.
Soll ein SAN hochverfügbar ausgelegt werden,
bedeutet dies normalerweise eine Verdopp-
lung der Hardware, einhergehend mit den
entsprechenden Kosten. Eine nachträgliche
Aufrüstung ist nur im Rahmen dessen mög-
lich, was der Hersteller des Systems dafür an
kompatiblen Optionen vorsieht.
Im Gegensatz dazu basiert Ceph vollständig
auf handelsüblicher Serverhardware mit da-
zugehörigen einfachen, zum Beispiel via SAS
verbundenen, Speichermedien. Diese können
-
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 zuverlässig und schnell abzu-
legen bzw. darauf zugreifen zu können.
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 trägt dabei Sorge dafür, 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 Schlüssel abgelegt werden. Dabei spielt die
Größe dieser Objekte keine wesentliche Rolle.
Es kann sich dabei um einen nur wenige Bytes
langen Text handeln oder um ein hunderte Gi-
gabyte großes Disk Image.
Object Storage Devices
Ungeachtet aller logischen Strukturen müs-
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. Für 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-
tät; insgesamt also etwa 175 TB Speicherplatz.
Zu beachten ist, dass Struktur und Inhalt der
in diesen Dateisystemen gespeicherten Da-
ten vollständig Ceph obliegen. Jeder manuelle
-
fährden und sollte daher dringend unterlas-
sen werden.
Für jedes OSD wird auf dem jeweiligen Ser-
ver ein einzelner Ceph-OSD-Daemon-Prozess
gestartet. Dieser ist verantwortlich dafür, das
Gerät zu überwachen und den von ihm bereit-
gestellten Platz für den Cluster verfügbar zu
machen.
Die Aufgaben, die der OSD Daemon dabei
übernimmt, sind vielfältig. Er erledigt unter
anderem die Überwachung der Verfügbarkeit
des von ihm betreuten OSD, das Manage-
ment der Netzwerkkommunikation mit Ceph-
Clients und anderen OSD Daemons. Darüber
hinaus führt er regelmäßige Integritätschecks
(„Scrubbing“) der gespeicherten Daten durch,
um Datenkorruption durch Bit-Fehler oder an-
zu korrigieren. Darüber hinaus sind OSDs
Objektredundanz verantwortlich.
An dieser Stelle sei deshalb erwähnt, dass ex-
plizit davon abgeraten wird, Ceph auf RAID Vo-
lumes oder anderen bereits auf andere Weise
virtualisierten Datenträgern aufzusetzen. Zen-
trale Aufgabe der OSD Daemons ist es, je ein
konkretes Stück Storage-Hardware zu verwal-
Datensicherheit, im Cluster bereitzustellen.
Dies ist jedoch nur dann möglich, wenn sie
Medium haben und es in Eigenregie steuern
können. Andernfalls käme es zu Wechselwir-
kungen der verschiedenen Abstraktionsebe-
nen, die in Summe negative Auswirkungen
Performance hätten.
Skalierbarkeit
Cephs theoretisch unbegrenzte Skalierbarkeit
und Flexibilität basiert auf einer breiten Ver-
teilung aller anfallenden Aufgaben auf mög-
lichst viele Maschinen. Ab einer bestimmten
Clustergröße wäre selbst ein sehr leistungs-
starker zentraler Objektbroker mit der Last
-
len Lookup Table und anderer Verwaltungs-
aufgaben entstünde.
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-
trächtigt würde.
Eine Konsequenz dieses Verzichts auf eine
zentrale Verwaltungsinstanz ist jedoch, dass
Clients keine dedizierte Anlaufstelle haben, an
die sie Anfragen und Aufgaben richten könn-
ten. Ceph-Clients sind daher selbst mit einer
Konkret verwenden sie den gleichen CRUSH-
Algorithmus wie die OSD Daemons, um be-
rechnen zu können, wo im Cluster sich die
erreichen sind.
CRUSH-Algorithmus
Die Bestimmung des Ablageorts eines Objekts
in Ceph erfolgt vollständig ü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-
sächlichen Ablageorte zu speichernder bzw.
zu lesender Objekte. Dabei wird angestrebt,
die Ressourcen im Cluster möglichst sinnvoll
auszulasten. In die Berechnung gehen neben
dem Objektnamen auch ein wählbarer 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 Geräten 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
-
träglich angepasst werden. Ein typischer Wert
liegt bei etwa 100 PGs pro OSD.
Diese Vorgehensweise ermöglicht es Ceph-Cli-
ents, selbstständig zu bestimmen, welcher OSD
Daemon für die Speicherung eines Objekts zu-
ständig ist und direkt mit diesem zu kommuni-
zieren, anstatt hierfür einen dedizierten Dienst
als Mittelsmann bemühen zu müssen.
Eine besondere Rolle kommt dem jeweils ers-
ten OSD zu, der für ein Objekt errechnet wird.
Er ist dafür verantwortlich, die vom Client er-
haltenen Daten entsprechend des gewünsch-
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 Veränderung der Eingabepara-
meter möglichst stabile Ergebnisse zu liefern.
Ändert sich die Anzahl verfügbarer OSDs, zum
Beispiel durch Ausfall einer Festplatte oder
Hinzufügen weiterer zur Erhöhung der Kapa-
zität, werden gerade so viele Daten wie nötig
umverteilt, um wieder eine gleichmäßige Aus-
lastung zu erzielen.
Der überwiegende Teil der Daten bleibt an Ort
und Stelle (Abb. 3). Im Gegensatz dazu hätte
die Verwendung einer echten Hash-Funktion
die Umverteilung aller bestehenden Daten
zur Folge. Da Ausfälle und Erweiterungen ab
einer gewissen Cluster-Dimension alltägliche
Vorgänge sind, wäre ein solches System bald
nahezu ausschließlich mit Rebalancierung be-
schäftigt.
Als zusätzlichen Faktor kann Ceph jeden OSD
basierend auf seiner Kapazität und Leistung
unterschiedlich gewichten, um insgesamt
Abbildung 3 -
eine möglichst ideale Ausnutzung aller Res-
sourcen zu gewährleisten. Hat etwa ein spä-
ter zum Cluster hinzugefügter Server deutlich
leistungsstärkere Hardware, wie zum Beispiel
eine oder mehrere SSDs, die als dediziertes
Medium für das Schreiben von Journaleinträ-
-
sichtigen und dieser Maschine mehr Arbeit
zuweisen als anderen, schwächeren Knoten.
Monitore
Wer bis hierhin gelesen hat, stellt sich inzwi-
schen vielleicht zu Recht die Frage, wie die
Beteiligten eines Ceph-Systems, Server wie
Clients, Informationen über die aktuelle Kon-
-
besondere wäre es kaum praktikabel, allen
-
datei mit allen relevanten Clusterparametern
bereitzustellen. Stattdessen sieht die Ceph-
Architektur hierfür einen dedizierten Dienst
vor: den Ceph-Monitor. In jedem Ceph-Clus-
ter existiert wenigstens ein Ceph-Monitor.
Ceph-Monitore haben die Aufgabe, eine stets
aktuelle Cluster-Map bereitzustellen. Dabei
handelt es sich um eine aus mehreren Einzel-
Maps zusammengesetzte Gesamtbeschrei-
bung des Clusterzustands. Ein Client, der sich
mit einem Monitor verbindet, kann dadurch
alle relevanten Systeminformationen erfah-
ren. Dazu gehören unter anderem Status und
Adressen aller OSD Daemons, weiterer Moni-
tore und Metadata-Server (mehr dazu später).
Bevor ein Ceph-Client also Daten mit einem
oder mehreren OSD Daemons austauschen
kann, muss er zunächst Kontakt zu einem
Ceph-Monitor aufnehmen, um eine aktuelle
Cluster-Map abzurufen. Mittels dieser Map
und durch Anwendung des CRUSH-Algorith-
mus lässt sich die Position aller Objekte – und
damit auch, von welchen OSD Daemons sie
erreichbar sind – errechnen. An dieser Stelle
endet damit die Abhängigkeit des Clients vom
dann unabhängig über direkte Kommunikati-
on mit den zuständigen OSD Daemons.
Im Sinne der Ausfallsicherheit und Skalier-
barkeit sollten Cluster sinnvollerweise immer
mehr als einen einzigen Monitor haben. An-
dernfalls führte dies den zuvor genannten
Vorteil eines Verzichts auf zentrale Kompo-
nenten ad absurdum, da ein einzelner Moni-
tor ein Single Point of Failure für das Gesamt-
system würde.
Ceph-Monitore synchronisieren sich unterein-
ander und verwenden mit Paxos [3] einen Al-
gorithmus zur verteilten Entscheidungs- und
einzelner Monitore weiterhin eine korrekte
Cluster-Map zur Verfügung gestellt werden
kann, solange noch eine Mindestanzahl von
Monitoren erreichbar ist.
-
rationsdatei, die einen oder mehrere Monito-
re mit ihren Adressen im Netzwerk benennt.
Die Ceph-Monitore selbst verwenden einen
Teil der Cluster-Map (die Monitor-Map), um
jederzeit ein über das Cluster hinweg konsis-
tentes Wissen über die verfügbaren Monito-
re zu haben. Bei der Installation eines neuen
Clusters wird die initiale Monitor-Map mittels
entsprechender Tools basierend auf einer
keine weitere Relevanz mehr hat.
Selbst für kleine Cluster sollten mindestens
drei Monitore aufgesetzt werden, um auch bei
Ausfall eines einzelnen weiterhin mehrheits-
fähig zu bleiben. Wächst der Cluster, können
nach Bedarf weitere hinzugefügt werden. Im
Idealfall werden Monitore auf dedizierten Ser-
vern betrieben, können aber auch auf beste-
henden Maschinen laufen, die auch OSDs be-
reitstellen. In Testinstallationen, bei denen ein
OSD Daemon keine dedizierte Platte, sondern
Speicher in einem existierenden Dateisystem
verwendet, sollte allerdings zumindest ein
anderes Gerät zur Speicherung der Monitor-
fsyncs() auslösen und damit die Performance
Pools
Pools ermöglichen eine logische Strukturie-
rung der Gesamtressourcen des Clusters, die
individuell je nach Anforderung abweichend
-
den können. Wenn ein Cluster initial aufge-
setzt wird, werden alle Objekte im Standard-
pool namens „data“ abgelegt. Pools sind somit
vergleichbar mit Mount Points oder Laufwer-
ken.
Mirroring
Pro Pool können verschiedene Parameter
unabhängig von den Defaults des gesamten
10 11
interessant ist hier der Grad der Redundanz,
mit dem Objekte, die in einem bestimmten
Pool abgelegt werden, über das Cluster rep-
liziert werden. Standardeinstellung für den
„data“-Pool sowie neu angelegte weitere
Pools ist 2. Das bedeutet, dass jedes Objekt
doppelt im Cluster vorliegt. Dies wirkt – ganz
ähnlich wie ein RAID Mirror – Hardwareausfäl-
len entgegen, indem auch beim Wegfall einer
Kopie die Daten dennoch weiterhin zugreifbar
bleiben.
Basierend auf der Kritikalität der zu spei-
chernden Objekte bietet es sich daher an,
verschiedene Pools anzulegen und entspre-
erwähnten Cluster unseres Dokumentenma-
nagementprodukts CenterDevice verwenden
wir einen Pool mit dreifacher Redundanz (also
das Originalobjekt und zwei Kopien) für vom
Kunden hochgeladene Dokumente.
Neben der reinen Erhöhung der Ausfallsicher-
heit erlaubt das Vorhalten mehrerer Kopien
von Objekten auch eine Verteilung von Lese-
anfragen auf alle vorhandenen Kopien. Da-
her kann es – je nach Anwendungsfall – auch
sinnvoll sein, Objekte, die besonders hoch-
frequent gelesen werden, in einen Pool mit
höherer Redundanz zu legen, selbst wenn sie
aus anderen Gesichtspunkten keine mehrfa-
che Speicherung benötigten.
Striping
Ceph unterstützt neben dem Mirroring auch
das Striping von geschriebenen Daten. Dadurch
lässt sich der Durchsatz insbesondere beim Sch-
reiben weit über die maximale Geschwindigkeit
eines einzelnen OSD hinaus steigern.
Um Verwirrung zu vermeiden, verwenden wir
zur besseren Unterscheidung an dieser Stelle
das im Cluster gespeichert werden soll. Eine Da-
tei wird – ganz wie bei einem RAID 0 – nicht „am
Stück“ abgelegt, sondern in mehrere Einzelteile
gesplittet, die im Cluster abgelegt werden. Drei
-
gung der Daten:
die zu speichernde Datei zerlegt wird (zum
Beispiel 64 KB).
Objekten zusammengefasst (daher die
-
chert. Ein Objekt enthält dabei 1 bis n viele
Stripe Units. Daher muss die Objektgrö-
ße ein ganzzahliges Vielfaches der Stripe-
Unit-Größe sein.
einzelnen Stripe Units sequenziell in einen
Satz von Objekten, dessen Größe über die
Stripe-Anzahl geregelt wird. Nachdem eine
Stripe Unit ins letzte Objekt eines solchen
Satzes geschrieben wurde, wird die nächs-
te Unit wieder im ersten Objekt abgelegt.
Zur Verdeutlichung sei zunächst eine Stripe-
Anzahl von 1 angenommen. In diesem Fall
werden Stripe Units in ein einziges Objekt ge-
schrieben, bis dessen maximale Objektgröße
erreicht ist. Mit der nächsten Stripe Unit be-
ginnt ein neues Objekt, so lange, bis die kom-
plette Datei abgelegt wurde (Abb. 4).
Da ein einzelnes Objekt auf einem einzigen
OSD gespeichert wird, bringt dies noch keine
Verbesserung der Schreibgeschwindigkeit.
Denn die Stripe Units werden lediglich hinter-
einander in die Objekte geschrieben. Daher
erhöhen wir nun die Stripe-Anzahl auf 4.
Beim Schreiben der ersten Stripe Unit wird
nun nicht ein Objekt angelegt, sondern gleich
Abbildung 4 -
4. Die erste Stripe Unit wird in das erste Ob-
jekt geschrieben, wie im vorherigen Beispiel.
Die zweite folgt nun jedoch nicht im gleichen
Objekt, sondern wird in das nächste Objekt
des Objektsatzes gespeichert. Dies setzt sich
für die nächsten beiden Stripe Units fort. Die
fünfte Stripe Unit wird wiederum im ersten
Objekt gespeichert usw.
Genügt die kombinierte Kapazität eines kom-
plett gefüllten Objektsatzes nicht, um die Da-
tei abzulegen, wird mit der ersten Stripe Unit,
die die Kapazität übersteigt, ein neuer Objekt-
satz angelegt. Das Konzept wird deutlich in
Abbildung 5.
12 13
um einen Maximalwert handelt und kein Spei-
cherplatz für einen Objektsatz reserviert wird,
kommt es hierbei nicht zu einer Verschwen-
dung von Speicherkapazität.
Clients
Nachdem nun die Serverseite von Ceph grund-
legend beschrieben worden ist, kommen wir
zu den verschiedenen Möglichkeiten, auf Da-
ten eines Ceph-Clusters zugreifen zu können.
Swift/S3-APIs: Statt das Rad neu zu
APIs existierende Schnittstellen. Das Swift-In-
terface bietet eine weitgehend mit dem Open-
Stack-Swift-API kompatible Schnittstelle an.
Darüber hinaus existiert ein API, das weitge-
hend kompatibel mit Amazons S3 Storage Ser-
vice ist. Beide APIs lassen sich gleichzeitig über
das so genannte RADOS-Gateway verwenden.
Hierbei handelt es sich um ein FastCGI-Skript,
das die entsprechenden Endpoints bereitstellt.
Für Entwickler steht damit eine Vielzahl ferti-
ger Bibliotheken und Bindings für verschiede-
ne Sprachen und Frameworks bereit.
Ceph Block Device: Zur Nutzung
des Speicherplatzes im Cluster in Form von
Block Devices bringt Ceph sowohl ein Kernel-
modul als auch eine Userland Library (librbd)
mit. Über diese beiden Wege lassen sich vir-
tuelle Block Devices zur direkten Verwendung
oder als Basis für virtuelle Maschinen verwen-
den. Durch das von Ceph geleistete Striping
und die Verteilung der zugrunde liegenden
Objekte über viele OSDs hinweg lassen sich
dadurch sogar virtuelle Devices erstellen, die
schneller Daten lesen und schreiben als lokale
Festplatten das könnten.
CephFS: Bis hierher wurde voraus-
gesetzt, dass Anwendungen, die einen Ceph-
Cluster verwenden wollen, dies über die oben
genannten APIs tun, sofern sie nicht direkt auf
dem grundlegenden Low-Level-librados-API
aufsetzen wollen. Für viele Anwendungen gilt
dies jedoch nicht. Eine große Anzahl existie-
render Anwendungen fußt auf einer dateiba-
sierten Datenablage.
Um diesem Umstand Rechnung zu tragen
(und für Fälle, in denen explizit ein verteiltes
Dateisystem benötigt wird; zum Beispiel als
NFS-Alternative), steht mit CephFS ein verteil-
tes Dateisystem zur Verfügung, das unter der
Haube den Ceph-Cluster zur Speicherung der
eigentlichen Daten verwendet, Anwendungen
aber eine POSIX-konforme Dateisystemsicht
darauf anbietet. Es ist diesbezüglich vergleich-
bar mit anderen verteilten Dateisystemen wie
zum Beispiel Gluster.
CephFS wird wie andere Dateisysteme ge-
mountet. Dabei stehen sowohl ein Kernelm-
odul als auch ein FUSE-Dateisystem zur Wahl.
Abbildung 6 verdeutlicht den Zusammenhang
der Komponenten. CephFS setzt die Installati-
on eines oder mehrerer Ceph-Metadata-Ser-
ver (MDS) im Cluster voraus, um dateisystem-
typische Metadaten wie Ordnerstrukturen,
Berechtigungen oder Zeitstempel zu verwal-
ten. Zwar können Ceph-Objekte generell ne-
ben den eigentlichen Daten auch beliebige
zusätzliche Key-Value-Paare als Metadaten
speichern, jedoch ist deren Semantik nicht de-
Abbildung 6 -
Der Ceph MDS Daemon nutzt diese Key-Value
Tupel zur Speicherung der Dateisystemmeta-
daten, die in einer reinen Object-Store-Se-
mantik nicht vorkommen. Im Sinne schneller
Antwortzeiten werden diese Daten vom MDS
soweit wie möglich im RAM vorgehalten. Auf
diese Weise wird sichergestellt, dass einfache
Operationen wie Verzeichnis-Listings oder
Rechteprüfungen nicht an potenziell zahlrei-
che OSD Daemons weitergeleitet und die Er-
gebnisse wieder zusammengeführt werden
müssen. Wäre dies der Fall, hinge die Per-
formance solcher Operationen stark von der
sonstigen Auslastung des Netzwerks und der
OSDs ab.
CephFS und Pools: Die weiter oben be-
schriebenen Pools (mit ihren jeweiligen Ein-
stellungen bzgl. Redundanz und Striping) ste-
hen auch für CephFS zur Verfügung. Teile des
Verzeichnisbaums können konkreten Pools
zugeordnet werden. Alle Dateien, die in die-
sem Teil des Baums gespeichert werden, wer-
den im Cluster im entsprechenden Pool ab-
gelegt. Dadurch steht die mit Pools erreichte
Flexibilität auch dateibasierten Anwendungen
zur Verfügung.
CephFS-Hochverfügbarkeit: Während
ein einzelner Ceph MDS Daemon im Cluster
prinzipiell genügt, um CephFS nutzen zu kön-
nen, ist auch für diesen eine redundante Aus-
legung empfehlenswert, um einen weiteren
potenziellen Single Point of Failure zu vermei-
den. Es stehen sowohl Aktiv-Passiv- als auch
Daemons im Standby bereit, von denen einer
bei Ausfall der aktiven Instanz übernehmen
kann. Da die benötigten Daten ohnehin im
Storage-Cluster persistiert sind, ist dies ohne
Datenverluste leicht möglich und wird von
den Ceph-Monitoren übernommen.
wird das Management verschiedener Ab-
schnitte des gesamten CephFS-Verzeichnis-
baums von verschiedenen MDS Daemons
übernommen, um die Last zu verteilen. Auch
Kombinationen beider sind möglich, sodass
-
on aufgefangen werden können.
FAZIT
Ceph ist ein leistungsstarkes und robustes
Softwarepaket, das unter Verwendung von
kostengünstiger Standardhardware einen
und Striping – global oder pro Pool einstellbar
– ermöglichen eine feingranulare Kontrolle
über die Ressourcenverwendung. Die Verfüg-
barkeit sowohl objekt- als auch dateibasierter
Schnittstellen macht das System in einer Viel-
zahl von Szenarien einsetzbar.
Im Rahmen der Installation unseres Clusters
sowie mithilfe von Benchmarks [4] und ba-
sierend auf unserer bisherigen Erfahrung –
sowohl im Einsatz als Object Store für unse-
re eigene Anwendung, als auch als Basis für
die interne CenterDevice OpenStack Cloud
– konnten wir, im Unterschied zur bislang
eingesetzten Speicherlösung auf Basis von
Gluster, weder Performance- noch andere
nennenswerte Probleme erkennen. Testwei-
se herbeigeführte Ausfälle ganzer Knoten
wurden korrekt erkannt und behandelt und
die Komponenten vollautomatisch nach dem
Wiederverfügbarwerden in den Cluster integ-
riert.
Allerdings bringen Flexibilität und Mächtig-
keit eine steile Lernkurve bei der Installation
und Inbetriebnahme mit sich. Insbesondere
verlangt sie eine sorgfältige Planung und Um-
setzung der zugrunde liegenden Netzwerkin-
frastruktur, um die Kommunikation der OSD
14 15
Daemons untereinander sowie die mit Ceph-
Clients mit maximaler Geschwindigkeit zu ge-
währleisten. Wir planen für die Zukunft eine
deutliche Ausweitung der Einsatzfelder von
Ceph, insbesondere im Zusammenspiel mit
OpenStack. Gern sind wir bereit, Unterstüt-
zung bei der Planung und Umsetzung Ihrer
Ceph-Systeme anzubieten.
Links & Literatur
[1] http://ceph.com/papers/weil-crush-sc06.
pdf
[2] Alle Abbildungen wurden unverändert ge-
mäß CC-BY-SA-2.0 (https://creativecommons.
org/licenses/by-sa/2.0/) übernommen von
http://ceph.com/docs
[3] http://en.wikipedia.org/wiki/Paxos_(com-
puter_science)
[4] https://blog.codecentric.de/en/2014/03/
ceph-object-storage-fast-gets- benchmarking-
ceph/
Mit OpenStack eine eigene Cloud aufbauen
Privatsache
Die Abstraktion von einzelnen Servern, Festplatten und Netzwerkverbindungen zu allgemein verfügba-
ren Rechen- und Speicherressourcen ist die Grundidee des Cloud Computing. Amazon hat mit AWS [1]
-
wareplattform, mit der man sein „eigenes, privates Amazon“ aufbauen kann.
Cloud Computing entkoppelt Rechen- und Speicherressourcen von konkreter Hardware. Auf diese
Weise entsteht eine Abstraktionsschicht zwischen der Baremetal-Hardware und darauf laufenden
Softwarediensten. Durch die konsequente Virtualisierung aller Hardwarekomponenten wie CPU,
Speicher und Netzwerk wird es möglich, beliebige, virtuelle Infrastrukturen aufzubauen, ohne
schweißtreibende Änderungen am Cluster im Rechenzentrum durchführen zu müssen. Infrastruk-
tur wird damit zu einem Dienst – Infrastructure as a Service (IaaS), den man seinem Team oder
Kunden anbieten kann. Ein besonderer Vorteil von IaaS ist, dass Hardwareausfälle nicht sofort den
Ausfall der Softwaredienste bedeuten müssen. Durch Verlagerung der virtuellen Infrastruktur auf
noch funktionierende Baremetal-Hardware werden Ausfallzeiten minimiert.
OpenStack
OpenStack ist eine Linux-basierte Soft-
wareplattform, die ursprünglich von RackSpace
[3] und der amerikanischen Raumfahrtagentur
NASA [4] seit 2010 entwickelt wurde. Mittler-
weile wird OpenStack unter der Kontrolle der
OpenStack Foundation mit der Unterstützung
von über 200 Firmen weiterentwickelt; u. a.
von Cisco, Dell, HP, IBM, Intel, Oracle, Red Hat,
Suse, Ubuntu und VMware. Bei der Entwick-
lung von OpenStack wird besonderer Wert auf
die Kompatibilität mit Amazon AWS gelegt, so-
dass Anwendung und virtuelle Infrastrukturen
für AWS leicht auf OpenStack übertragbar sind.
Abbildung 1 zeigt den grundsätzlichen Aufbau
einer privaten Cloud mit OpenStack.
OpenStack ist kein einzelnes Softwareprodukt
wie etwa VMware vSphere, sondern eine mo-
dulare Softwareplattform zum Aufbau einer pri-
konkrete Anforderungen angepasst werden. Das
notwendig ist, um erfolgreich eine Cloud-Umge-
bung aufzusetzen. In diesem Artikel werden wir
OpenStack anhand der CenterDevice-Cloud vor-
stellen.
Abbildung 1 -
16 17
OpenStack bei CenterDevice
CenterDevice ist ein hochskalierbarer Cloud-
Dienst zum Verwalten, Teilen und Finden von
Dokumenten aller Art. Unsere Kunden sind
kleine und große Unternehmen sowie Behör-
den, die immer und überall auf ihre Doku-
mente zugreifen wollen. Ferner erlaubt Cen-
terDevice das Durchsuchen von gigantischen
Dokumentenmengen über Volltextindizierung
und verzichtet dabei auf undurchsichtige Ver-
zeichnisstrukturen.
Für unseren Cloud-Dienst ist es deswegen
erforderlich, leicht zu skalieren und mit Hard-
wareausfällen umzugehen, ohne dass unse-
re Kunden einen Serviceverlust bemerken.
OpenStack ist hierfür die beste Lösung, um
unserer verteilten Software eine stabile und
robuste Infrastruktur zu bieten. Unser aktu-
elles OpenStack-Cluster kann hierbei zwanzig
virtuelle Maschinen mitsamt virtuellem Netz-
werk in knapp 40 Sekunden starten. Ausfälle
eines Hardwareknotens werden ohne Unter-
brechung von den restlichen Knoten aufge-
fangen.
OpenStack-Versionen
Die Linux-Referenzdistribution für OpenStack
ist Ubuntu. OpenStack folgt wie Ubuntu ei-
nem sechsmonatigen Releasezyklus. Seit Ok-
tober 2013 ist das OpenStack-Havana-Release
für Ubuntu 12.04 LTS freigegeben. Im April ist
zeitgleich mit Ubuntu 14.04 LTS die jüngste
stabile Version von OpenStack mit dem Na-
OpenStack-Knotentypen
OpenStack unterscheidet drei Knotentypen:
Controller, Network und Compute Node. Die
Controller-Knoten beherbergen die internen
-
onsschnittstellen (sowohl für Konsole als auch
das Web-UI – siehe unten). Die Networkkno-
ten sind die Endpunkte für die virtualisierten
Netzwerke und stellen den Übergang von vir-
tuellen in physikalische Netzwerke her. Auf
Compute-Knoten laufen die tatsächlichen vir-
tuellen Maschinen.
OpenStack-Komponenten
Die OpenStack-Plattform besteht aus zehn
Komponenten – siehe Tabelle 1. OpenStack
ist voll multimandantenfähig. Das bedeutet,
dass man voneinander unabhängige virtuelle
Infrastrukturen aufbauen kann, die vollkom-
men isoliert ausgeführt werden. Dies erlaubt
-
ware durch verschiedene Teams und Kunden.
Man kann aber auch zum Beispiel leicht Pro-
Diese Isolation setzt eine konsequente Rech-
teverwaltung voraus. Die OpenStack-Kompo-
nente Keystone verwaltet hierbei alle Objekte,
wie Projekte, Netzwerke, virtuelle Maschinen
und Benutzer. Keystone muss immer instal-
liert werden.
Virtuelle Maschinen bestehen meist aus zwei
Komponenten: einem Image und einem vo-
latilen Speicher. Das Image ist das Template,
aus dem die virtuelle Maschine erzeugt wird.
Dafür dient der Glance-Dienst. Glance spei-
chert Images in verschiedenen Formaten je
nach ein- gesetztem Hypervisor – siehe weiter
unten. Unterstützt werden die Formate Raw,
AMI, VHD, VDI, qcow2, VMDK und OVF [5].
Um virtuellen Maschinen die Möglichkeit zu
geben, Daten zu schreiben, können Volumes
an eine virtuelle Maschine angehängt wer-
den. Diese Volumes werden als Block Storage
Devices, also reguläre Festplatten, durch den
Cinder-Dienst in die virtuelle Maschine einge-
blendet.
Die Speicherung von Images und Volumes
kann entweder mit klassischen Dateisystemen
oder über den Dienst Swift erfolgen. Swift ist
als Object Store implementiert, der Daten be-
liebiger Art anhand eines Schlüssels ablegt.
Diese Form der Speicherung ist für größere
-
systeme und skaliert deutlich besser. Darü-
ber hinaus kann Swift auch an die virtuellen
Maschinen weitergereicht und dort als Object
Store für Anwendungen genutzt werden. Für
die CenterDevice-Cloud haben wir uns ent-
schieden, statt Swift Ceph [6] als Object Store
zu nutzen (Kasten: „Object Store mit Ceph“).
Das Verteilen auf die Computing-Knoten und
das Ausführen von virtuellen Maschinen erle-
digt die Open- Stack-Komponente Nova. Sie ist
das Herzstück von OpenStack und unterstützt
eine Vielzahl von Hypervisors. Darunter sind
KVM/QEMU, Xen, LXC/Docker und VMware.
Der Kasten „Wahl eines Hypervisors“ schildert,
warum wir bei CenterDevice KVM einsetzen.
18 19
Neutron ersetzt seit OpenStack Havana die
Nova-basierte Virtualisierung von Netzwer-
ken. Neutron verfolgt dabei das Konzept des
Whitepaper [8] bzw. Einführungsvortrag [9]
bei YouTube. Mit Neutron lassen sich nahezu
beliebig komplizierte Netzwerke auf Ebene 2
und 3 aufbauen. Es ist also möglich, getrennte
Netzwerke aufzubauen und diese mithilfe von
Routen zu verbinden. Abbildung 2 zeigt den
prinzipiellen Aufbau eines Neutron-basierten
Netzwerks mit zwei voneinander isolierten
Mandanten bzw. Projekten.
In dieser Abbildung ist zu sehen, dass die bei-
den Mandantennetzwerke (Tenant Networks)
-
guration des Routers entscheidet hierbei, ob
die beiden Netzwerke miteinander bzw. mit
dem Internet kommunizieren dürfen oder
nicht.
Abbildung 3 zeigt ein konkretes Netzwerk für
das Projekt Java Magazin, dargestellt im Hori-
zon Dashboard – siehe unten. Es werden vier
Netzwerke abgebildet, die der klassischen
Aufteilung in eine DMZ (rot), ein Frontend-
(grün) und ein Backend-Netzwerk (orange)
folgen. Das blaue Netzwerk spielt eine beson-
dere Rolle. Es stellt das so genannte externe
Netzwerk dar, das die virtuelle Welt mit der
physischen verbindet.
Über dieses Netzwerk können die virtuellen
Maschinen nach außen kommunizieren – sie-
he in Abbildung 2 das Providernetwork.
Die IP-Subnetze der virtuellen Netzwerke sind
alle private Netzwerke. Soll eine virtuelle Ma-
schine von außen erreichbar sein, so muss zu-
IP genannt – eine so genannte Floating- IP ver-
geben werden. Floating-IPs sind IP-Adressen,
die über Network Adress Translation (NAT)
von einer virtuellen Maschine zur anderen
-
werk stammen. Sie werden dynamisch von
OpenStack vergeben. Mithilfe dieser Floating-
IPs ist es möglich, einen Dienst hinter einer
solchen IP zu betreiben und sie im laufenden
Betrieb von einer auf eine andere virtuelle
Maschine zu migrieren; zum Beispiel, um eine
neue Version seiner Software zu aktivieren
oder einen Knoten zu ersetzen. Im Beispiel
aus Abbildung 3 haben die beiden Load Ba-
lancer am roten DMZ-Netzwerk von außen
erreichbare Floating-IPs. Floating-IPs stellen
jedoch eine besondere Herausforderung dar,
wenn die damit verbundenen Dienste von
anderen Knoten genutzt werden, da sie sich
ändern können (Kasten: „Dynamische Provisi-
onierung mit Metadaten“).
Abbildung 2 -
Abbildung 3 -