Seite wählen

NETWAYS Blog

Ceph: Datenintegrität durch Scrubbing

Für ein Storage ist Datenintegrität natürlich eine wichtige Eigenschaft, welches in Ceph unter anderem durch das sogenannte Scrubbing umgesetzt wird. In den meisten Fällen werden Daten in Ceph repliziert gespeichert, d.h. jedes Objekt wird mehrfach gespeichert. Bei Scrubbing prüft Ceph ob die Kopien der gespeicherten Objekte gleich sind. Dabei wird in zwei verschiedene Arten von Scrubbing unterschieden. Das normale Scrubbing vergleicht (wenn möglich) täglich die Attribute und Größe der Objekte. Deep-Scrubbing hingegen berechnet wöchentlich die Prüfsummen der Objekte und vergleicht diese. Treten Unterschiede auf werden diese korrigiert.
Das prüfen der Integrität geht natürlich stark zu lasten der Festplatten, da jedes Objekt eingelesen wird. Deshalb gibt es verschiedene Parameter um die Last zu streuen. Generell versucht Ceph die Scrubs über den ganzen Tag bzw. Deep-Scrubs über die ganze Woche zu verteilen. Verwendet man aber die Standardeinstellungen kann dies schnell dazu führen, dass diese Verteilung nicht mehr funktioniert.

  • osd scrub load threshold = 0.5: Dies führt dazu, dass Scrubs nur bei einer Load von weniger als 0.5 durchgeführt werden. Bei einem Storage Server ist eine Load von 0.5 sehr schnell erreicht. Dieser Wert wird nicht an die Anzahl der Kerne adaptiert.
  • osd scrub min interval = 86400 (täglich): Gibt an, nach wie vielen Sekunden Scrubs durchgeführt werden können, falls die Load nicht zu hoch ist.
  • osd scrub max interval = 604800 (wöchentlich): Gibt an, nach wie vielen Sekunden Scrubs spätestens durchgeführt werden müssen. Der Load Threshold wird nicht berücksichtigt.
  • osd deep scrub interval = 604800 (wöchentlich): Gibt an, nach wie vielen Sekunden Deep-Scrubs durchgeführt werden müssen. Der Load Threshold wird nicht berücksichtigt

Laut Mailingliste und IRC-Logs werden Deep-Scrubs immer und ausschließlich von normalen Scrubs angestoßen, und zwar dann wenn der letzte (normale) Scrub schon länger als eine Woche vergangen ist. Hat das Storage eine Load größer von 0.5 (was im Normalbetrieb immer der Fall ist), dann ist der Parameter osd scrub min interval sinnlos und es wird nach einer Woche ein normaler Scrub durchgeführt. Diese Kombination kann dazu führen, dass Deep-Scrubs erst nach  osd scrub max interval + osd deep scrub interval durchgeführt werden. Im Standard Fall somit erst nach zwei Wochen. Je nach Startzeitpunkt der Intervalle werden alle Scrubs hintereinander durchgeführt was somit alle zwei Wochen im gleichen Zeitraum Last verursacht. Im Graphite und Grafana kann man solch ein Verhalten natürlich leicht erkennen 🙂

Ceph Deep Scrub

Ceph Deep Scrub


Zum Glück gibt es noch den Parameter osd max scrubs welcher mit der Standardeinstellung dazu führt, dass nur ein Scrub pro OSD zur gleichen Zeit stattfinden darf. Die Last auf den Storage hält sich somit in Grenzen und Anwender merken nichts davon.
 
 
 
 
 

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Drei Wege um virtuelle Maschinen zu migrieren

OpenNebulaConf Grafiken 09Neue Storage-Lösungen sprießen wie Tulpen im Frühling aus dem Boden. Jede einzelne ist flexibler, schlanker und hochverfügbarer.
Da kommt meine Cloud ins Spiel, die eigentlich gut läuft aber so ein schnelleres Storage ist eine willkommene Abwechslung.
So ein neues Storage ist schnell aufgesetzt, was uns dann aber vor eine neue Aufgabe stellt,
denn unsere VMs laufen… nur nicht auf unserem hippen Storage.
Nun gibt es diverse Methoden um eine virtuelle Maschine in ein neues Image bzw. neues Storage zu transferieren.
Da haben wir zum einen die altbewährte Methode, mit dem Urgestein aller blockorientierten Kopiervorgänge dd.
Dazu muss die virtuelle Maschine komplett ausgeschaltet sein. Da sich der Zustand der VMs nicht mehr ändert, kann man beruhigt die VM kopieren.
dd if=/path/to/input/file of=/path/to/output/file bs=4096
Zum anderen die Methode ein qcow2 Image in ein Blockdevice zu schreiben.
In Worten gesagt: das Image wird mit „qemu-img convert“ in Raw umgewandelt und danach mit dd auf das neue Blockdevice kopiert. (Auch hier sollte die VM nicht mehr laufen!)
qemu-img convert -p -f qcow2 -O raw /path/to/input/file /path/to/outputfile.raw && dd if=/path/to/outputfile.raw of=/path/of/device bs=4M
Da die beiden genannten Arten eine lange Downtime benötigen, sind sie nur für VMs geeignet die nicht zeitkritisch sind.
Ein UNIX System kann mit guten Kenntnissen, mit relativ kurzer Ausfallszeit migriert werden. Ein hilfreiches Werkzeug dabei ist Rsync.
Leider kann ich hierzu kein fixes Beispiel vorzeigen, da die einzelnen Schritte von System zu System unterschiedlich ausfallen.
Die essentiellen Schritte sind:
1. Neues Device in der VM mounten und das gewünschte Filesystem erstellen.
2. Systemverzeichnisse auf dem neuen Device erstellen.
3. Das komplette System mit Rsync auf das neue Device kopieren. Hier muss man natürlich etwas aufpassen und Verzeichnisse wie /proc oder ggf. /mnt exkludieren. Auch auf bind Mounts sollte man achten, damit man Daten nicht ausversehen doppelt kopiert.
4. Die grub.cfg natürlich im neuen /boot Pfad aktualisieren. (grub-install und update-grub sind hierfür hilfreich)
5. Das „alte Device“ als read-only einbinden und die neue fstab anpassen.
6. Und last but not least, einen weiteren Rsync in dem die restlichen Files auf das neue Image übertragen werden. (auch hier bitte das Exkludieren von wichtigen Pfaden nicht vergessen. z.B.: /etc/fstab oder auch /boot !!)
Der Vorteil hierbei ist: die Downtime erstreckt sich dabei nur über den zweiten Rsync, bei dem die Festplatte im „read-only“ Modus ist.
Habt Ihr weitere coole Möglichkeiten einen VM zu migrieren?
Dann dürft ihr euch in den Kommentaren dazu äußern.
Oder seid Ihr interessiert an dem Thema Cloud und alles was damit zu tun hat? Dann besucht uns einfach auf der OpenNebula Conf 2014

Thilo Wening
Thilo Wening
Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Ceph Day in Frankfurt

Letzte Woche fand am Frankfurter Flughafen der erste Ceph Day in Deutschland statt. Neben der Möglichkeit die treibende Kräfte hinter Ceph kennen zu lernen war dies ein Tag voller spannender Vorträgen zu verschiedensten Einsatzgebieten, Best Practices und Fallbeispielen. Die dazugehörigen Vorträge werden laut den Veranstaltern noch auf Slideshare veröffentlicht.
Besonders interessant fand ich einen Vortrag von Patrick McGarry über die Ceph Community. Derzeit wird versucht diese zu vergrößern weshalb viele Möglichkeiten zur Interaktion und Kommunikation geboten werden. Neben den gängigen Möglichkeiten wie IRC und Mailingliste werden regelmäßig Ceph Development Summits veranstaltet die über mehrere Tage laufen und komplett online stattfinden. Gearbeitet wird unter anderem mit Wikis, Pads, Hangouts und Blueprints. Damit wird auch versucht Entwickler aus allen Zeitzonen abzuholen. Der Ceph Day selbst springt von Kontinent zu Kontinent und es gibt sogar die Möglichkeit an den wöchentlichen Standups der Hauptberuflichen Ceph-Entwickler teilzunehmen. Dass all diese Versuche fruchten bleibt natürlich zu hoffen, aber schön zu sehen, dass versucht wird Ceph offen und unabhängig zu platzieren.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

OSDC 2014: Der Countdown läuft – nur noch 106 Tage

Bevor Ihr alle in den Weihnachtsurlaub verschwindet, möchte Martin Gerhard Loschwitz euch, in unserem Countdown zur OSDC, noch mit einem Vortrag über Ceph beschenken.

OSDC? Noch nie gehört…
Das ist aber schade und fast schon ein unentschuldbares Versäumnis!
Aber wir holen das nach:
Die Open Source Data Center Conference (kurz OSDC) ist unsere internationale Konferenz zum Thema Open Source Software in Rechenzentren und großen IT-Umgebungen. 2014 findet sie zum sechsten Mal statt und bietet mit dem Schwerpunktthema Agile Infrastructures ganz besonders erfahrenen Administratoren und Architekten ein Forum zum Austausch und die Gelegenheit zur Aneignung des aktuellsten Know-Hows für die tägliche Praxis. Diesmal treffen wir uns dafür in Berlin!
Workshops am Vortag der Konferenz und das im Anschluss an die Veranstaltung stattfindende Puppet Camp komplettieren dabei das Rundum-sorglos-Paket für Teilnehmer, die gar nicht genug Wissen in sich aufsaugen können.

Skalierbarer Storage mit Ceph

Martin Loschwitz hat auf der OSDC mit Ceph eine Storage Lösung vorgestellt, die horizontal skalierbar ist und keinen Single Point of Failure hat. Falls mehr Speicher benötigt wird, reicht es aus einen weiteren Node hinzuzufügen. Dieser Node wird als OSD (Object Store Daemon) in den sogenannten RADOS Object Store mit eingebunden. Für einen OSD benötigt man keine teure Hardware und auf RAID, teure Platten und mehrere Netzteile kann verzichtet werden, da ein Ausfall eines einzelnen Node weniger tragisch ist, da eine Replikation bereits integriert ist. Die Redundanz der Daten kann frei konfiguriert werden und es kann auch auf die Standorte der einzelnen Nodes Rücksicht genommen werden.
Für den Zugriff auf den RADOS Object Store gibt es verschiedene Clients. librados bietet direkten Zugriff und bietet Unterstützung für die gängigsten Programmiersprachen. Mit RADOS Block Devices (RBD) kann man einen Blockdevice erstellen und einbinden, welcher über das RADOS Protokoll auf den Object Store zugreift. Snapshots und Copy-on-Write werden ebenfalls unterstützt. Mit CephFS gibt es auch ein POSIX kompatibles Dateisystem, welches auf den RADOS Cluster zurückgreift. Dieses kann wie gewohnt mit mount eingebunden werden (Achtung: CephFS ist noch experimentell!).

 mount -t ceph 192.168.1.1:6789:/ /mnt/ceph 

Zudem gibt es mit RADOSGW noch ein RESTful Gateway, mit dem man über HTTP auf den Object Store zugreifen kann.
An welchen OSD die Clients Daten senden müssen, erfahren diese von einem Monitor (MON) und die Daten werden anschließend von den Clients direkt an einen OSD gesendet, welcher sich auch um deren Replikation kümmert.
Weitere Details und was das Ganze mit qemu zu tun hat findet ihr in der Dokumentation von Ceph und natürlich in den Slides und Artikeln von Martin Loschwitz.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.