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.

OSBConf 2014 – Ein Rückblick

Trotz der gelungenen Abendveranstaltung fanden sich die Teilnehmer der Open Source Backup Conference in Köln früh am Morgen wieder ein, um an den Vorträgen teilzuhaben.
Nachdem am Vortag jeder die Gelegenheit hatte, sich durch den Bareos Introduction Workshop über Bareos informieren zu lassen oder (entsprechendes Vorwissen vorausgesetzt) im Hacking Bareos Workshop tiefer in die Marterie einzutauchen, startete Philipp Storz von der Bareos GmbH & Co KG die Vorträge mit einem Überblick über Bareos mit Details zur gerade eben veröffentlichten Version 14.2.1 Beta und deren neuen Features. Die reichen von so kleinen aber wichtigen Änderungen wie der Möglichkeit, Warnungen über das Tray Icon auf Windows Hosts anzuzeigen, über eine Reihe neuer unterstützter Betriebssystemversionen bis zu der Enthüllung, dass nun alle Bareos daemons auch auf Windows ausgeführt werden können. Des weiteren werden jetzt auch diverse Cloudstorages als Ziel für Backups unterstützt. Für bestehende und angehende User enthielt der Vortrag auch Informationen über den Einfluss von blocksize und filesize auf die Schreibgeschwindkeit beim Sichern auf Bänder.


Nach der obligatorischen Fragerunde wurde das Mikrofon an Dave Simons übergeben, der eine Einführung in Puppet gab und dabei besonders auf die Konfiguration von Bacula und Bareos Backup Clients einging. So können exported resources genutzt werden, um Informationen der zu sichernden Systeme in die zentrale Backup Konfiguration zu übernehmen. Die Slides zum Vortrag gibt es schon vorab auf Slideshare, mehr zu Puppet u.a. bei uns.
Nachdem sich Redner und Hörer in der Kaffeepause stärken konnten, gab es einen Doppelvortrag von Jan Behrend und Dr. Stefan Vollmar von zwei Max Planck Instituten über die Herausforderungen für ein Backup im wissenschaftlichen Umfeld. Als Herausforderungen wurden hier besonders die grossen Datenmengen, der besondere Wert der Daten und die durchaus ausgefallenen Anforderungen der User herausgehoben. Die grossen Datenmengen zwingen bei solchen Installationen dazu, mit virtual full backups zu arbeiten, einer Technologie, die aus einem full backup und den Sicherungen, die seit seiner Erstellung ein full backup zusammensetzen, das dem aktuellen Stand entspricht, aber völlig ohne Kontakt mit dem zu sichernden Client auskommt. Ausserdem wurde ein Weg vorgestellt, wie Hochverfügbarkeitscluster konsistent gesichert werden können. Dabei werden für 2 Knoten 3 Clients in Bareos angelegt, je einer pro Knoten und einer für den hochverfügbaren Teil, der über die virtuelle IP Adresse des Clusters gesichert wird. Wenn die Verwendung eines HFS wie Grau OpenArchive nicht dem entspricht, was sich die User erhoffen, die Datenmengen aber ein HFS verlangen, wurde in diesem Vortrag ein Weg vorgeschlagen, mit dem Backups im HFS abgelegt werden, anstatt alle Daten. Besonders ungewöhnlich war hier die Verwendung eines eigenen Netzwerkes, das nur für die Dauer eines Backups erstellt und nach Abschluss des Backups wieder deaktiviert wird.
Bevor die Mittagspause eingeläutet wurde, stellte Daniel Holtkamp noch seine Erfahrungen mit der Migration von Bacula zu Bareos vor, wobei er besonderen Wert darauf legte, dass die Bacula Backups weiterhin verfügbar sind. Gesondert hervorzuheben ist hier, dass für Wiederherstellung der Bacula Sicherungen kein Bacula mehr benötigt wird, sondern Bareos mit der bisherigen Bacula Konfiguration und Datenbank gestartet wird. Da die Migration auch für eine Bereinigung der Konfiguration benutzt wurde, finden sich in dem Vortrag einige schöne Beispiele, wie man die Bareos Konfiguration übersichtlicher und leichter handhabbar machen kann. Dabei wurde auch viel Gebrauch davon gemacht, dass Bareos statt Pfadangaben oft auch den Output von Scripts, SQL Queries oder Shellcommands verwenden kann, die Bareos selbst bei Bedarf ausführt.
Nach einem hervorragenden Mittagsbuffet gab Martin Loschwitz eine ausführliche Vorstellung von Ceph, das von Haus aus in sich redundant und mit Selbstheilungsfunktionen ausgestattet ist, weshalb in einigen Setups Snapshots als Backup ausreichend sein sollten. Dabei wurden neben weniger bekannten aber sehr vielversprechenden Features wie Qemu-rdp, mit dem KVM virtuelle Festplatten von Guests direkt in Ceph ausbringen kann, auch noch unbekanntere aber deshalb nicht unbedingt weniger vielversprechende Features wie php bindings, mit denen Webapplikationen Daten wie Bilder direkt in Ceph ablegen können, vorgestellt.
Thematisch passend handelte der nächste Vortrag vom Backup in und von einer Cloud, gehalten von Marco van Wieringen. Hier gab es einen Überblick über verschiedene verteilte Dateisysteme wie GlusterFS und eben Ceph. Dabei wurden besonders Unterschiede und die Wege, wie man als Applikation Daten in diese Services schreiben oder deren Inhalt sichern kann, hervorgehoben und jeweils eine kurze Übersicht über den Entwicklungsstand der Anbindung des jeweiligen Service an Bareos gegeben.

Da der nächste Vortrag leider ausfallen musste, sprangen dankenswerterweise Frank Bergkemper und Daniel Neuberger mit einer schnellen Vorschau auf das kommende Bareos Webinterface ein. Selbst Vorschaupakete sind in den contrib Repositories von Bareos verfügbar und müssen nur mehr getestet werden. Feedback sehr willkommen! Das Webinterface ist schon weit gediehen und wird nicht nur alle in der bconsole verfügbaren Daten anzeigen, sondern auch Daten ableiten, wie eine Übersicht, welche Medien in wie vielen Tagen auslaufen werden. Auch Graphen und andere Daten für einfaches Reporting sind verfügbar. Das auf dem Zend Framework basierende Interface soll Administratoren von spezialisierten Clients für einzelne Betriebssysteme loslösen und die Bedienung von Bareos mit jedem Gerät ermöglichen, das einen Webbrowser hat.
Zum Abschluss zeigte Ralf Dannert noch ReaR, mit dem Medien erstellt werden können, um in Kombination mit einem Backuptool wie Bareos, Bacula oder sogar rsnapshot ein bare metal disaster recovery von Linux Servern zu ermöglichen. Dabei müssen die Medien für jeden Host einzeln erstellt werden, müssen aber nicht ein ISO oder USB Stick sein, sondern können auch in eine PXE Boot Infrastruktur eingebunden werden. Für SuSE User ist dabei besonders interessant, dass es einige Erweiterungen gibt, mit denen insbesondere OpenSuSE und SLES Hosts so wieder hergestellt oder vom physischen zum virtuellen System umgebaut werden können.
Damit war es wieder eine abwechslungsreiche und interessante OSBConf, bei der sich wohl jeder, vom alten Hasen bis zum Frischling in Sachen Open Source Backup etwas Neues mitnehmen konnte. Zumindest war die Beteiligung an den Fragerunden geradezu ungewöhnlich groß. Wer sich schon auf die nächste OSBConf einstellen möchte, kann sich schon mal das Datum 29.&30. September 2015 vormerken und eine Suche nach dem Hashtag #OSBConf speichern. Die Mitschnitte und Folien der Vorträge werden online zur Verfügung gestellt, wir werden hier über das Blog Bescheid geben, wann und wo das der Fall sein wird.
OSBC_Facebook Header_DANKE
 

Thomas Widhalm
Thomas Widhalm
Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Ceph Datastore, OpenNebula und Authentifizierung mit CephX

OpenNebula kann Ceph bereits seit Release 4.0 als Datastore einbinden. Wie man die beiden Systeme integriert wird in der OpenNebula Dokumentation beschrieben. Natürlich benötigt man einen laufenden Ceph Cluster und einen Hostsystem der kompatibel dazu ist. Im Augenblick eignet sich hier Ubuntu LTS, da die Kernelversionen neu genug sind um aktuelle Features von Ceph zu unterstützen und zudem ist auch eine aktuelle Version von Ceph in den Repositories.
Neben der gewohnten Installation und Konfiguration eines OpenNebula Nodes muss man noch das Paket ceph installieren, was in den Abhängigkeiten die Libraries für rados und rbd mit sich bringt. Damit man den Ceph Cluster vom Hostsystem ansprechen kann, muss man noch die ceph.conf und den Keyring des gewünschten Users kopieren. Der folgenden Befehl erstellt einen User one mit Zugriff auf den Pool one.

$ ceph auth get-or-create client.one mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=one'
[client.one]
	key = aAaaaLaaKaaQaaRaaAaaYaaZaaBaaaaaaaaa==

Als Ausgabe sieht man den Key des Users. Dieser muss in der Datei /etc/ceph/ceph.client.one.keyring auf dem Hostsystem abgelegt werden. `rados -p one –id=one df` sollte jetzt den freien Speicherplatz im one Pool anzeigen. Der User oneadmin sollte lesend auf den Keyring zugreifen dürfen.
Bevor OpenNebula eine VM deployed, wird überprüft ob im Datastore genügend Speicherplatz frei ist. Dazu wird der Befehl `rados df` aufgerufen, komplett ohne Parameter, weshalb der Benutzer client.admin anstatt client.one verwendet wird. Ein Pull Request [1] welcher dies ändert hat es bisher leider nicht in das offizielle Repo geschafft.
Als Workaround kann man entweder zusätzlich den Keyring des client.admin auf dem Hostsystem ablegen oder im Monitor Skript [2] die Parameter des rados Aufrufs um „-p one –id=one“ erweitern (angenommen der verwendete Ceph Pool heißt one).
Das alles nur um zu überprüfen ob genügend Speicherplatz im Datastore frei ist. Damit man VMs im Ceph Datastore erstellen kann muss sich auch libvirt gegen CephX authentifizieren. Dies ist aber bereits in der OpenNebula Dokumentation beschrieben.
[1] https://github.com/OpenNebula/one/pull/27
[2] src/datastore/ceph/monitor

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.

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.