Ceph ist in aller Munde und spätestens seit Red Hat sich Inktank einverleibt hat ist die Software Defined Storage Lösung auch im Enterprise Segment angekommen.

Ceph verspricht nichts anderes, als den Storage Markt, der von Grössen wie NetApp, EMC und Co. dominiert wird, auf den Kopf zu stellen.

SUSE schickt mit SUSE Enterprise Storage ebenfalls eine Ceph Distribution mit Enterprise Anspruch ins Rennen – wir haben uns ausführlich mit der Version 2.0 beschäftigt und fassen die wichtigsten Schritte der Installation in diesem Post kurz zusammen.

Hinweise: die folgende Installation entspricht nicht einem “best practice” Szenario sondern deckt die Schritte ab, um die Lösung in einem Lab-Szenario testen zu können.

Vorwort

Die Umgebung in welcher unsere Testinstallation stattfindet, besteht aus drei physikalischen Servern, welche fortan Node1, Node2 und Node3 genannt werden. Alle drei Geräte werden als OSD verwendet und zusätzlich wird Node1 auch Monitor und Calamari beherbergen. Für eine produktive Umgebung müssten die verschiedenen Rollen (OSD/MON) getrennt betrieben werden und ein Minimum von drei MONs müsste vorhanden sein.

SUSE Enterprise Storage wird als Addon-Package für SLES 12 angeboten. Um diesen zu installieren, wird während der Installation des Basis Betriebssystems oder auch zu einem späteren Zeitpunkt im YAST2 dieses Addon-Package hinzugefügt. Nach der Installation der Pakete, kann das Setup beginnen.

Voraussetzungen

Zuerst wird sicher gestellt, dass die Nodes sich gegenseitig mit DNS-Namen auflösen können. Dies wurde mit entsprechender Konfiguration der /etc/hosts Datei sichergestellt. Auch muss auf jedem System ein Benutzer für Ceph angelegt werden. Für diesen Test ist dies ceph. Zudem muss die Monitor Node(1) ohne Passwort und jeweils mit vollen sudo Rechten ohne Passwort auf den anderen Nodes (2 + 3) Befehle ausführen dürfen.

Calamari Konfiguration

Danach konfigurieren wir als root Calamari, das Webgui zur Administration und Überwachung des Ceph Clusters. Dafür wird ein Administrationsbenutzer (in diesem Beispiel “root”) und dessen Kennwort festgelegt. Anschliessend konfiguriert calamari-ctl postgresql und apache2 und startet diese Dienste. Das Webgui ist mit der standard Installation unter der Server IP direkt auf Port 80 erreichbar.

calamari-ctl initialize

Achtung: Alle ceph-deploy Befehle, werden als Benutzer ceph auf der Node1 ausgeführt!
Nun werden alle Nodes an unseren Calamari Server angebunden:

ceph-deploy calamari --master node1 connect node1 node2 node3

 

Ceph Grund-Konfiguration

Der nächste Schritt ist das Konfigurieren des Ceph Clusters mit Hilfe des Tools “ceph-deploy”, welches auf den meisten Distributionen über die hauseigene Paket-Verwatlung installiert werden kann. Falls das Paket nicht zur Verfügung steht, ist es auch problemlos möglich, “ceph-deploy” über Python pip oder direkt aus den Quellen mit git clone https://github.com/ceph/ceph-deploy.git zu beziehen.

Danach wird der Ceph Cluster erstellt:

ceph-deploy new node1

Anschliessend wird Ceph auf allen Nodes installiert:

ceph-deploy install node1 node2 node3

Schlussendlich wird der erste Monitor erstellt:

ceph-deploy mon create-initial

Nun ist der Ceph Cluster soweit, dass Speicher hinzugefügt werden kann.

Ceph Speicher-Konfiguration

In dieser Testumgebung ist auf jeder Node die Partition /dev/sda3 als Speicherort für die Ceph Daten vorgesehen. Dies können aber auch problemlos ganze Platten (Mehrzahl) pro System sein.

Als erstes werden die Partitionen vorbereitet:

ceph-deploy osd prepare node1:/dev/sda3 node2:/dev/sda3 node3:/dev/sda3

Danach können die OSDs aktiviert werden:

ceph-deploy osd activate node1:/dev/sda3 node2:/dev/sda3 node3:/dev/sda3

Et voilà, ein fertig konfigurierter Ceph Cluster mit Calamari Webinterface ist konfiguriert.

Hilfen

Falls die Installation des Ceph Clusters neu gestartet werden soll, kann das bestehende Setup mit folgenden Befehlen zurückgesetzt werden:

ceph-deploy purge node1 node2 node3
ceph-deploy purgedata node1 node2 node3
ceph-deploy forgetkeys

Wenn es bei OSD prepare Fehlermeldungen gibt, kann ceph-deploy disk zap helfen. Der Befehl überschreibt die Partitionstabelle der Festplatte:

ceph-deploy disk zap nodeX:sda3

Um das selbe für Calamari durchzuführen, muss der folgende Befehl ausgeführt werden:

calamari-ctl clear --yes-i-am-sure

Das Passwort für den Calamari Benutzer kann man wie folgt neu setzen:

calamari-ctl change_password --password {password} {user-name}

Weiterführendes

Ab diesem Zeitpunkt steht der Konfiguration des Clusters für andere Dienste nichts mehr im Weg. Die Ceph internen Dienste sind:

• Ceph Documentation: Object Store
• Ceph Documentation: Block Device
• Ceph Documentation: Filesystem

Zu diesem Thema ist beim SUSE Enterprise Storage z.B. neu das iSCSI-Plugin vorhanden, mit welchem viele weitere Dienste in den Genuss einer Ceph-Anbindung kommen können!

Das hier gewählte Setup ist die minimale Installation. Für Ausfallsicherheit und mehr Leistung sollten den Anweisungen von Ceph gefolgt werden.

Interessante und hilfreiche Links zu SUSE Enterprise Storage und Ceph:

• https://www.suse.com/products/suse-enterprise-storage/
• http://docs.ceph.com/docs/master/

Fazit

Die Installation eines Ceph Clusters mit SUSE Enterprise Storage gestaltet sich relativ einfach. Das Webfrontend sowie die iSCSI-Schnittstelle sind interessante Ergänzungen zu Ceph, welche wir in kommenden Posts noch intensiver behandeln werden.

Verglichen mit einer Debian basierten Installation, welche erst richtig funktionierte als ceph-deploy von Hand konfiguriert wurde, gestaltet sich die Lösung von SUSE benutzerfreundlicher.

Ausblick

In weiteren Tests haben wir uns mit der Performance sowie der iSCSI/libvirt Anbindung von Ceph beschäftigt. In Kürze werden wir weitere Details dazu auf diesem Blog veröffentlichen.

Yubikeys (Hersteller Yubico) sind günstige Hardware Tokens für Multifaktor Authentifizerung.
Yubico stellt nebst den Yubikeys auch noch YubiHSM her, welche Hardware Security Module sind. HSM werden genutzt, um diverse x509 private Keys in Hardware zu speichern, damit diese nicht von einem Hacker gestohlen werden können.

Nebst Yubico gibt es z.B. auch noch den Hersteller Nitrokey, welcher Open-Hardware Tokens und HSM herstellt.

Von Yubico gibt es aktuell zwei Produkte, welche sich für Two-Factor Authentifizierung sehr gut eignen, da sie die meisten Protokolle beherrschen: Einerseits der Yubikey 4 und andererseits der Yubikey Neo.

Funktionalität

Die beiden Produkte Yubikey 4 und Yubikey Neo haben jeweils zwei Slots und einen PIV-Kompatiblen Speicher. Diese beiden Slots können für diverse Funktionen verwendet werden. Unterstützt werden die folgenden:

• Secure static password
• Yubico OTP
• OATH – HOTP (counter basiert)
• OATH – TOTP (Time basiert)
• FIDO U2F

Eine detailliertere Erklärung zu diesen Formaten ist in unserem letzten Blog Post zu entnehmen.

Der PIV-Kompatible Speicher kann für folgende zwei Funktionen verwendet werden:

• PIV-Kompatible SmartCard (x509 Zertifikate)
• OpenPGP SmartCard

Vergleich Yubikey 4 gegen Yubikey Neo

Der Yubikey 4 ist das neuere Produkt als der Yubikey Neo und hat im Vergleich einen SmartCard Speicher für 4096 Bit RSA Keys anstatt nur 2048 Bit. Es fehlt ihm hingegen an der NFC Funktionalität, welche für die Authentifizierung auf Mobiltelefonen nötig ist.
Beim Yubikey 4 handelt es sich um so neue Hardware, dass aktuelle Linux Distributionen, welche nicht “bleeding edge” sind, noch keine Tools für die Personalisierung bieten. Der Yubikey Neo ist im Gegenzug bei allen aktuellen Distributionen gut unterstützt.

Konfiguration

Um die Yubikeys zu konfigurieren gibt es das Kommandozeilen Tool ykpersonalize (Source Code, Debian Paket, ArchLinux Paket) und das GUI Tool yubikey-personalization-gui (Source Code, Debian Paket, ArchLinux Paket). Die Pakete im Debian Jessie sind zu alt, als dass sie Yubikey 4 unterstützen würden. Der Yubikey Neo funktioniert jedoch problemlos.

Nachfolgend wird auf einem ArchLinux mit einem Yubikey 4 gearbeitet. Dies sollte aber, falls die Software dies unterstützt, auf jedem System identisch sein – egal ob Yubikey 4 oder Yubikey Neo.

udev

Damit aus dem Userspace auf die Yubikeys zugegriffen werden kann, muss udev angepasst werden. Dafür wird jeweils eine Datei im Verzeichnis /etc/udev/rules.d erstellt und danach per sudo udevadm control --reload geladen. Dies ist nur nötig um die neue Konfigurationsdatei, ohne das System neu zu booten, zu laden.

Damit FIDO U2F funktioniert, sind folgende Rules notwendig:

# FIDO U2F
ACTION!="add|change", GOTO="u2f_end"

# Yubico YubiKey
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0402|0403|0405|0406|0407|0410", TAG+="uaccess"

# Happlink (formerly Plug-Up) Security KEY
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", TAG+="uaccess"

#  Neowave Keydo and Keydo AES
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1e0d", ATTRS{idProduct}=="f1d0|f1ae", TAG+="uaccess"

# HyperSecu HyperFIDO
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="096e", ATTRS{idProduct}=="0880", TAG+="uaccess"

LABEL="u2f_end"

Damit die Personal Identity Verification (PIV) mit der SmartCard aus dem Userspace funktioniert, sollten folgende udev Regeln hinzugefügt werden:

ACTION!="add|change", GOTO="yubikey_sc_end"

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0113|0114|0115|0116|0120|0402|0403|0405|0406|0407|0410", GROUP="users", MODE="0660"

LABEL="yubikey_sc_end"

Falls danach FIDO U2F oder die SmartCard noch nicht funktioniert, sollte überprüft werden, ob die USB Vendor und Product ID in obiger Liste vorhanden sind. Welche Vendor und Product ID eingetragen werden muss, ist mit folgendem Befehl ersichtlich:

lsusb | grep Yubico | awk '{print $6}'

System für die SmartCard vorkonfigurieren

Damit GnuPG mit einer SmartCard kommunizieren kann, braucht es gewisse Voraussetzungen. Als erstes sollten diverse Pakete installiert werden:

• gnupg-agent (Debian Paket, ArchLinux Paket)
• pcscd (Debian Paket, ArchLinux Paket)
• scdaemon (Debian Paket, ArchLinux Paket)

Anschliessend müssen noch diverse Konfigurationen angepasst werden. Wichtig ist vor allem folgende Zeile in der GnuPG Konfiguration (~/.gnupg/gpg.conf) zu haben:

use-agent

Eine etwas umfangreichere Konfiguration bildet das untenstehende Setup ab – dies ist nicht spezifisch für die Yubikey Konfiguration in diesem Artikel, sondern ein Beispiel für eine GnuPG Konfiguration, welche einige wichtige aber fehlende Optionen nachbessert.

keyserver hkp://pool.sks-keyservers.net
default-recipient-self
list-options show-uid-validity show-keyserver-urls
verify-options show-uid-validity
display-charset utf-8
utf8-strings
ask-cert-level
default-cert-level 0
keyid-format 0xLONG
use-agent
no-greeting
armor
fixed-list-mode
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
cert-digest-algo SHA512
no-comments
no-emit-version

Der GnuPG Agent kann auch noch konfiguriert werden, so kann z.B. der SSH Agent durch den GnuPG Agent ersetzt werden. Dies hat zur Folge, dass nebst den Keys die spezifisch für SSH erstellt wurden auch der GnuPG Key in der SmartCard verwendet werden kann.

# enable this if pinentry-gtk is installed
#pinentry-program /usr/bin/pinentry-gtk-2

default-cache-ttl 3600
max-cache-ttl 7200

# for ssh support
enable-ssh-support
default-cache-ttl-ssh 3600
max-cache-ttl-ssh 7200

Yubikey Slots konfigurieren

Mit ykinfo -a wird die aktuelle Slot-Belegung ausgegeben. Dabei können z.B. die AES Keys natürlich nicht mehr ausgelesen werden, da sonst die Sicherheit verloren gehen würde.
Yubikeys sind standardmässig nicht für U2F vorkonfiguriert. Damit dieses Feature verwendet werden kann, muss der Modus umgestellt werden. Dies geschieht mit ykpersonalize -m86. Der Yubikey unterstützt danach Yubico OTP, FIDO U2F und CCID.

Yubico OTP

Wenn Yubikeys geliefert werden, haben sie im ersten Slot schon eine Yubico OTP Konfiguration. Der dazugehörige AES Key ist in der YubicoCloud auch schon hinterlegt, somit können diese Validation Server sofort verwendet werden. Sollen aber eigene Validation Server eingesetzt werden, muss der AES Key auch auf diesen hinterlegt werden. Da der AES Key nicht mehr aus dem Yubikey ausgelesen werden kann, muss der Slot neu geschrieben werden.

Die entsprechende Konfiguration sollte mit dem Tool ykksm-gen-keys erstellt werden, die ID muss dabei jeweils eindeutig sein. Die Ausgabe des Tools ykksm-gen-keys ist Komma getrennt in folgender Reihenfolge:

• Seriennummer (auch ID genannt)
• Identität (auch Publicname genannt)
• Interne UID
• AES Key (das eigentliche Secret)
• Lock Passwort
• Erstellungsdatum
• Zuletzt zugegriffen
• Optionale Felder

Beispiel mit der ID 1:

$ ykksm-gen-keys 1
1,cccccccccccb,42e31d069785,cf00b1f4c2c80e395b5e7532a5929cba,d05f7e394f0e,2016-03-22T13:12:25,

Diese Information kann mit folgendem Kommando auf den Yubikey in Slot 1 geschrieben werden:

$ ykpersonalize -1 -acf00b1f4c2c80e395b5e7532a5929cba -o fixed=cccccccccccb -o uid=42e31d069785

FIDO U2F

Damit U2F funktioniert, ist entweder Chrome oder Chromium nötig oder für Firefox die Erweiterung u2f4moz. Die native Unterstützung in Firefox ist aktuell in Arbeit.
Um im Slot 2 U2F zu konfigurieren, kann folgendes Kommando verwendet werden:

$ ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible

Danach ist U2F im Slot 2 konfiguriert und der Yubikey kann z.B. bei GitHub als Security Key hinzugefügt und verwendet werden.

Personal Identity Validation (SmartCard)

Die SmartCard wird mit PKCS #11 angesteuert, wie dies bei anderen SmartCards auch der Fall ist. Soll z.B. GnuPG mit der SmartCard kommunizieren, wird dafür das Tool gpg verwendet. Das Kommandozeilen-Interface dafür kann über gpg2 --card-edit erreicht werden. Der Status wird über gpg2 --card-status abgefragt. Funktioniert das Abfragen des Status nur als User root und nicht aus dem Userspace, sind die udev Regeln noch nicht geladen oder korrekt hinzugefügt worden.

Letzten Freitag machten sich drei Späher der Adfinis SyGroup AG am Morgen früh auf den Weg auf den Berner Hausberg, den berühmten Gurten. Jedoch nicht um der schönen Aussicht zu fröhnen, sondern um bei gezogenen Vorhängen in dunklen Räumen die “Future of Web Development” zu sehen: die Jazoon TechDays 2016. Hier ist ihr Bericht:

Die Talks

Die Vorträge wurden von namhaften Stars der JavaScript-Welt präsentiert. So hörten wir viel Interessantes über aktuelle Technologien, wie z.B. über das neue Angular 2, das neue RxJS 5, Ember sowie Gedanken zur Zukunft der Web-Technologien.

Hierbei war für uns als Ember-Entwickler eine Einsicht durch Gerard Sans und Rob Wormald in Angular 2 sehr interessant. Zu unserer Überraschung sind sich diese beiden Frameworks näher, als wir erwartet haben – so konnten wir die eindrucksvolle On-Stage-Coding-Session von Rob Wormald ohne Probleme nachvollziehen.

Der Ember Vortrag von Mike North war für uns ein Heimspiel – bei der Frage, wer Ember schon eingesetzt hat, gingen nebst der Hände der Ad-Sy nur eine weitere Hand hoch – notabene ein ex Adfinisler 😉 Der Vortrag verschuf uns einen schönen Einblick über die erweiterten Vorteile von Ember im Bereich der Mobile- und Desktop-Entwicklung.

Sehr interessant war der Vortrag von Ben Lesh in Hinblick darauf, wie Asynchronität in JavaScript effizienter und sauberer gehandhabt werden kann. Dies ist z.B. für Netflix relevant, um ihre Applikation auf verschiedensten Geräten performancetechnisch wie gewünscht zum Laufen zu bringen. Uns wurde bei diesem Referat schnell klar, dass diese Ansätze nicht nur für solche Einsatzbereiche nützlich sind – noch während dem Vortrag fielen uns Einsatzmöglichkeiten in unseren Projekten ein.

Nicht nur Vorträge waren auf dem Programm: es gab auch Gesprächsrunden, denen wir beiwohnen durften – faszinierend war z.B. zu höhren, wie Ben Lesh und Mike North Alltagsprobleme in ihren erheblich grösseren Entwicklungsteams lösen. Es wurde offensichtlich, dass auch sie mit ähnlichen Problemen wie wir zu kämpfen haben.

Fazit

Generell können wir uns glücklich schätzen, ein Teil dieser zukunftsweisenden Entwicklung der Web-Technologien sein zu können. Schön zu sehen ist auch, wie die lokale Community wächst und aktiv ist. Wir fühlen uns sehr bestätigt, in diesem Bereich aktiv zu sein und sind sehr motiviert, Ember und Co. noch stärker einzusetzen, unser Wissen zu erweitern und unseren Beitrag an die Weiterentwicklung zu leisten.

Das SUSE Manager 3 beta Programm ist Ende Dezember 2015 gestartet worden. Diese Gelegenheit wollten wir nutzen, um uns einen ersten Überblick zu verschaffen, was die kommende Version beinhalten wird. Vorneweg, die wichtigste Änderung ist die Integration von SaltSack als Remote Execution und Configuration Management Framework.
Für diesen Blog Post haben wir uns folgenden Anwendungsfall ausgesucht und ein kurze Anleitung, wie es in der Praxis umgesetzt würde, verfasst.

Szenario

Damit in grösseren IT-Systemlandschaften ein vernünftiges Release und Patch Management durchgeführt werden kann, werden oft identische Systeme in unterschiedlichen Umgebungen (phases oder stages) betrieben. Steht ein neuer Release oder ein Patch zur Verfügung, werden diese zuerst auf den Entwicklungssystemen eingespielt und durchlaufen dann einige Tests und eventuelle Anpassungen, bevor sie auf den produktiven Systemen ausgerollt werden.

Der SUSE Manager liefert für dieses Szenario eine einfache Lösung. Damit einzelne Patches und Pakete von einer Umgebung in die nächste weitergereicht werden können. Zudem ist es möglich einen gesamten Stand oder ein Snapshot eines definierten Zeitpunkts von einer Umgebung in die nächste zu synchronisieren.

Voraussetzungen

Die beschriebenen Konfigurationen setzen voraus, dass ein SUSE Manger 3 installiert und mindestens ein Client System mit SLES11 oder SLES12 als Salt Minion angebunden ist.

Konfiguration

Damit das komplette Setup in der Shell durchgeführt werden kann, müssen die Pakete spacewalk-utils und spacecmd installiert werden.

suma3:~ # zypper in -y spacewalk-utils spacecmd

Dann lassen wir uns die bestehenden Software Channels anzeigen.

suma3:~ # spacewalk-manage-channel-lifecycle \
-u admin -p $PASSWORD -l

Zum jetzigen Zeitpunkt ist nur ein Channel zu sehen. Im sogenannte Vendor Channel liegen alle Pakete und Patches die vom SCC heruntergeladen werden.
Also ein Mirror der aktuellsten Paketen von SUSE.

Nun werden die vier Umgebungen (phases) erstellt.

suma3:~ # spacewalk-manage-channel-lifecycle \
-u admin -p $PASSWORD \
--channel sles12-sp1-pool-x86_64 --init \
-P devl,test,inte,prod
suma3:~ # for PHASE in devl test inte prod ; do
> spacewalk-manage-channel-lifecycle \
> -u admin -p $PASSWORD \
> --channel $PHASE-sles12-sp1-pool-x86_64 \
> --promote -P devl,test,inte,prod
> done

Werden die Umgebungen (phases) nicht explizit mit-P angegeben, wird als Standard (dev, test, prod) verwendet. Wird der Channel tree jetzt noch einmal mit dem oben genannten Befehl angezeigt, sind die fünf Base Channels zu sehen. Der Vendor- und die vier erstellten Umgebungs-Channels (devl, test, inte, prod).

Damit wir die Konfiguration testen können, weisen wir ein SUSE Manager Client System einer Umgebung zu, in unserem Beispiel der Test-Umgebung.

suma3:~ # spacecmd -u admin -p $PASSWORD -y \
system_setbasechannel suma3-client1.example \
test-sles12-sp1-pool-x86_64

Auf dem Client System kann mit folgendem Befehl überprüft werden, ob die Zuweisung funktioniert hat.

suma3-client1:~ # zypper lr

Es erscheinen nur Repositories der zugeteilten Umgebung.

Ab jetzt ist es möglich, über das WebUI oder das CLI einzelne Pakete oder Patches in eine Umgebung zu importieren, oder eine Umgebung mit einer anderen zu synchronisieren.

Hinter den Kulissen

Sobald ein Client System einem Base Channel zugewiesen ist, wird auf dem SUSE Manager, welcher als Salt Master läuft, eine Datei mit den entsprechenden Repositories erstellt.

suma3:~ # cd /srv/susemanager/salt/channels ; \
> cat channels.repo.044625baad3d49889f067f14d7cae86f
[susemanager:test-sles12-sp1-pool-x86_64]
name=test-sles12-sp1-pool-x86_64
enabled=1
autorefresh=1
baseurl=https://suma3.example/rhn/manager/download/test-sles12-sp1-pool-x86_64?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0ODc4MzU1NDgsImlhdCI6MTQ1NjI5OTU0OCwibmJmIjoxNDU2Mjk5NDI4LCJvcmciOjEsImp0aSI6IlRrYldFQWUwaHZGdzNZUklQQk1aWmcifQ.cmGZyuMU_SJT_fHRmj9X0zP7vM1A2KwWgNRp6m4BDcI
[...]

Das Suffix des Dateinamens entspricht der Salt Minion ID des jeweiligen Client, in unserem Falle der ID von suma3-client1.example.

Anschliessend führt der SUSE Manager den folgenden Befehl aus, welcher die Datei /etc/zypp/repos.d/susemanager:channels.repo auf dem Zielsystem suma3-client1.example neu schreibt, falls es Abweichungen zur lokalen Version gibt.

suma3:~ # salt 'suma3-client1.example' state.apply

Interaktion Spacewalk / SaltStack

Spacewalk übergibt dem Salt Master seine Befehle über dessen Rest API, und als Client Library wird die von SUSE entwickelte salt-netapi-client verwendet.

Fazit

Dieses Setup liess sich dank dem Configuration Management von SaltStack sehr einfach durchführen. Im Vergleich zu Vorgängerversionen des SUSE Manager, die als Client Stack rhns verwendeten, war die Konfiguration um einiges schlanker und die Repository-Quellen wurden schneller den Clients zugeteilt.
Die Integration von SaltStack ist eine Bereicherung für den SUSE Manager, welche nicht nur im beschriebenen Anwendungsfall erhebliche Vorteile mit sich bringt.

Markenhinweise

DRBD® und LINBIT® sind Marken oder eingetragene Marken der LINBIT in Österreich, den Vereinigten Staaten und anderen Ländern.

Bei anderen in diesem Dokument genannten Namen kann es sich um Marken oder eingetragene Marken ihrer entsprechenden Eigentümer handeln.

Lizenzhinweise

Hierbei handelt es sich um ein Handelsdokument der LINBIT und Adfinis SyGroup, für das Vertriebsbedingungen gelten. Weitere Informationen dazu finden Sie unter http://links.linbit.com/t-and-c.

1. Über DRBD
2. Einleitung
   2.1. DRBD Übersicht
   2.2. Galera Cluster Übersicht
3. Vergleich
   3.1. Netzwerkverkehr
   3.2. Commit Verzögerung
   3.3. Replikation
   3.4. Lastverteilung
   3.5. Ausfallsicherung
   3.6. Resynchronisierung
4. Zusammenfassung
5. Weitere Dokumentationen

1. Über DRBD

Bei der DRBD-Software handelt es sich um eine Linux-Kernel Replikationsfunktion auf Datenblock-Ebene, die weit verbreitet als Baustein für Shared-Nothing Cluster eingesetzt wird. Sie ist in Vanilla Kernels ab Version 2.6.33 enthalten und die erforderlichen Dienstprogramme für die Benutzerumgebung werden von den meisten Distributionen mitgeliefert. Darüber hinaus verfügen viele Distributionen über neuere DRBD-Versionen als die im Kernel-Paket enthaltene in Form von Extra-Paketen.

DRBD ist in der Lage, die Replikation über mehrere Netzwerkprotokolle und (gegenwärtig) in drei Modis durchzuführen – von synchroner Replikation für lokale HA Cluster bis hin zu asynchroner Replikation für die Weiterleitung von Daten zu einem Disaster-Recovery-Standort.

DRBD wird von LINBIT entwickelt und weltweit vertrieben; dies schließt die meisten Distributionen und Architekturen ein, mit einigen wenigen SLA Ebenen bis hinzu 24/7 E-Mail und telefonischer Verfügbarkeit.

Bei Galera Cluster handelt es sich um einen synchronen Multi-Master Datenbank-Cluster, der eine hohe Verfügbarkeit durch die Replikation der Transaktionen an alle Knoten im Cluster bereitstellt. Durch die Entfernung des von einem Zwei-Phasen-Commits eingebrachten Overheads und die Weiterleitung an einen Zertifikat basierten Replikationsmechanismus ermöglicht die Lösung eine fast lineare Skalierung bei gleichzeitiger hoher Verfügbarkeit und Konsistenz.

Galera wird von Codership entwickelt und wird vollständig in die Lösungen von MariaDB integriert und unterstützt. Adfinis SyGroup ist ein Partner von MariaDB und bietet Unterstützung bei der Implementierung, Überwachung und Wartung von MariaDB basierten Infrastrukturen.

2. Einleitung

In diesem Tech-Guide werden zwei verschiedene High-Availability Lösungen für MySQL Datenbanken verglichen; Bei der einen Lösung handelt es sich um eine Block-Device basierte Replikationslösung, die andere erweitert MariaDB Internals für die Bereitstellung einer synchronen Replikation.

Es werden einige Unterschiede aufgezeigt sowie Vor- und Nachteile diskutiert.

2.1. DRBD Übersicht

Bei DRBD handelt es sich um eine Block-Device basierte Replikationslösung, die einfach sicherstellt, dass ein Bereich an Speicherblöcken (einer Partition, Festplatte oder eines logischen Laufwerks usw.) an zwei Knoten (oder mit DRBD 9 an weiteren) identisch ist.

Dies bedeutet vollständige Unabhängigkeit von der diesen Speicher nutzenden Anwendung. Sogar das Dateisystem spielt keine Rolle – XFS, ext4, BTRFS usw. funktionieren gleich gut.

DRBD wird gewöhnlich über TCP/IP Verbindungen genutzt; mit DRBD 9 steht ebenfalls ein RDMA-Transport zur Verfügung, der die Netzwerkverzögerung reduziert und somit die Anzahl der verfügbaren IOPs ein wenig erhöht.

2.2. Galera Cluster Übersicht

Galera Cluster arbeitet innerhalb des MariaDB Binärprogramms. Über die Konfigurationseinstellungen lädt das mysql Binärprogramm die von Galera geteilte Bibliothek, die die Netzwerkkommunikation und die Replikation anderer mysql Prozesse an Remote-Netzknoten ermöglicht.

Gegenwärtig ist Galera Cluster nur mit der InnoDB Storage Engine kompatibel, da nur diese Engine die erforderliche Transaktionsunterstützung bereitstellt. Die Unterstützung weiterer Storage Engines ist möglich, sobald von diesen Transaktionen unterstützt werden.

3. Vergleich

3.1. Netzwerkverkehr

Da DRBD vom Dateisystem und den darüber liegenden Anwendungsebenen nichts mitbekommt, repliziert es alle Schreibvorgänge an den Remote-Netzwerkknoten – dass heißt Anwendungsdaten, Transaktionsprotokolle, Indizes sowie Metadaten des Dateisystems (z. B. Journal des Dateisystems, Inodes, Verzeichnisse).

Galera Cluster sendet einfach die logischen Änderungen, z. B. den Inhalt der Transaktion in Form eines gepackten Galera write-sets über das Netzwerk. Ein mehrere tausend Zeilen umfassendes UPDATE Statement hat ungefähr die Größe der aktualisierten Datensätze. Es existiert kein weiterer Overhead für Indizes oder Transaktionsprotokolle.

Die Galera Cluster Kommunikation kann entweder Unicast (TCP) oder Multicast (UDP) Verbindungen nutzen. Multicast eignet sich insbesondere für ausgedehnte Umgebungen, um den Netzwerkverkehr noch weiter zu reduzieren.

3.2. Commit Verzögerung

Mit DRBD existiert nur ein aktiver Master für diese Datenbank; sobald der endgültige Schreibvorgang auf der Festplatte für das COMMIT abgeschlossen ist, kann DRBD eine Bestätigung an die Anwendung senden. Je nach Stapelspeicher^[1] kann die Verzögerung weniger als 100 μsec betragen.

In Galera Cluster wird der Inhalt einer Transaktion an jeden Knoten im Cluster gesendet. Sobald der Client die Transaktion an einem Knoten bestätigt, sendet dieser Knoten das write-set an die anderen Knoten, die den Empfang bestätigen. Jeder Knoten führt anschließend eine Zertifizierung des ‘write-sets’ durch und nimmt die Transaktion lokal vor. Der Ursprungsknoten bestätigt die Transaktion an den Client, nachdem die lokale Zertifizierung erfolgreich abgeschlossen wurde.

Eine zusätzliche Verzögerung entsteht nur während des Sendeschritts und entspricht der längsten Roundtrip-Zeit zu irgendeinem der Knoten im Cluster. Für die Bereitstellung innerhalb der gleichen Colocation beträgt die Verzögerung normalerweise weniger als 400 μsec.

3.3. Replikation

DRBD unterstützt die synchrone und asynchrone Replikation; Letztere ist für das Disaster-Recovery über große Entfernungen hilfreich. Für diesen Fall gibt es ein separates Produkt (den DRBD Proxy), das die Komprimierung des Datenstroms der Replikation unterstützt und somit die erforderliche Bandbreite reduziert.

Galera Cluster kann nur synchron verwendet werden. Es können jedoch an jeden Galera Cluster Knoten asynchrone Standard MariaDB Replikations-Slaves angebunden werden. Da jedoch mit jedem Commit eine zusätzliche Verzögerungszeit in Verbindung steht, ist die Anzahl der Transaktionen, die über WAN-Bereitstellungen verarbeitet werden können, begrenzt. Eine Faustregel für die maximale Anzahl an Transaktionen lautet 1/RTT trx/s.

3.4. Lastverteilung

DRBD wird normalerweise in einem Aktiv/Passiv Setup verwendet, d. h. jede DRBD Ressource ist nur an einem Knoten aktiv^[2]. Dies bedeutet, dass nur ein Knoten Zugang zum Dateisystem hat, in dem eine Datenbank gespeichert wird ^[3]; dieser Knoten ist für das gesamte Statement Parsing, Abholen der Daten, Treffen von Entscheidungen und Schreiben zuständig.

Galera Cluster ist eine reine Multi-Master Lösung – jeder Knoten stellt seine eigenen Ressourcen bereit. Die einzige Auswirkung auf die Leistung entsteht durch das Senden der Transaktion an alle Knoten. Jeder Knoten kann für schreibgeschützte Anfragen verwendet werden, somit skaliert die Lese-Leistung linear. Optimistisch betrachtet kann ein gewisser Grad an Skalierbarkeit der Schreibvorgänge erreicht werden. Dies hängt jedoch von der Anwendungsstruktur ab^[4], bestenfalls kann die Schreibleistung um ca. 15 % gesteigert werden.

3.5. Ausfallsicherung

In einer HA-Umgebung muss ebenfalls eine Vorausplanung im Falle von Problemen vorhanden sein.

Wenn der aktive Knoten in einer DRBD Umgebung (aus welchen Gründen auch immer) ausfällt, muss der Cluster Stapel (normalerweise Pacemaker mit Heratbeat oder Corosync) das Problem erkennen und den Dienst auf einen anderen Knoten umschalten. Im schlimmsten Fall zieht dies eine Überprüfung des Dateisystems, eine Datenbankwiederherstellung und anschließend die Wartezeit nach sich, die erforderlich ist, um die Cachespeicher wieder verfügbar zu machen^[5].

Wenn bei Galera Cluster ein einziger Knoten ausfällt, arbeiten die verbleibenden Knoten im Cluster ohne Unterbrechung weiter. Ein Client, der gerade mit dem ausgefallenen Knoten verbunden ist, versucht die Verbindung über einen Loadbalancer^[6] wiederherzustellen. Die anderen Clients sind keiner Unterbrechung ausgesetzt. Wenn der ausgefallene Knoten wieder in Betrieb ist, kann eine Überprüfung des Dateisystems und eine Wiederherstellung der Datenbank erforderlich sein, wodurch dieser Knoten innerhalb dieser Zeit nicht für den Lastausgleich zur Verfügung steht.

3.6. Resynchronisierung

Nach einem Ausfall muss der ausgefallene Knoten sicherstellen, dass er die neuesten Daten erhält.

Das sich in der Block-Device Ebene befindende DRBD hält eine Bitmap der Dirty Datenböcke bereit und übernimmt diese einfach, sobald die DRBD Verbindung nach dem Ausfall wiederhergestellt ist. Der Kopiervorgang erfolgt in der auf der Festplatte vorliegenden Reihenfolge; die Leistung wird nur durch die Speicher- und Netzwerkhardware begrenzt. Bei einem 10 GBit Netzwerk und FusionIO Karten sollten 1,2 GByte/Sek. erreicht werden können.

Galera Cluster verfügt über zwei Wege für die Aktualisierung eines sich anschließenden Knotens. Wenn der Knoten bereits zuvor ein Mitglied des Clusters war und den Cluster nur für kurze Zeit verlassen hat^[7], versucht der Knoten einen Incremental State Transfer (IST) durchzuführen, indem er die Änderungen aus dem ‘write-set’ Cache eines anderen Knotens im Cluster herunterzieht.

Wenn kein anderer Knoten im Cluster die für den IST erforderlichen Änderungen aus seinem ‘write-set’ Cache zur Verfügung stellen kann oder wenn ein neuer Knoten dem Cluster hinzugefügt wird, wird ein Snapshot State Transfer (SST) durchgeführt. Dies bedeutet, dass alle Daten aus der Datenbank an den sich anschließenden Knoten übertragen werden. Galera wählt einen sogenannten Donor Knoten, der die Quelle für den Transfer darstellt. Da ein Donor einen großen Einfluss auf die Leistung haben kann, werden Donor-Knoten häufig aus dem Lastausgleich ausgeschlossen, um eine konsistente Lese- und Schreibleistung innerhalb des Clusters zu gewährleisten.

4. Zusammenfassung

Es folgt eine abschließende Tabelle auf Grundlage der oben diskutierten Themen.

	DRBD	Galera Cluster	Vorteil
Netzwerkverkehr	Alle geänderten Datenblöcke	nur Transaktionsinhalte	Galera
Verzögerung	μsec bis msec, je nach Speichersystem	msec, aufgrund von Userspace/Kernel Übergängen	DRBD
Replikation	synchron oder asynchron (Disaster-Recovery)	synchron oder asynchron	DRBD/Galera
Lastausgleich	Daten auf Datenblockebene können von anderen Knoten gelesen werden	vollständiger Multi-Master	Galera
Ausfallsicherung	Über Cluster-Stapel; Ausfallzeit Sekunden oder Minuten	andere Knoten arbeiten ohne Unterbrechung weiter	Galera
Resynchronisierung	Nur geänderte Datenblöcke, Datenblockgerät Reihenfolge	IST/SST	–

 

5. Weitere Dokumentationen

Die DRBD Projektseite. Unter der Adresse http://drbd.linbit.org, mit einer Menge an Informationen einschließlich eines Benutzerhandbuchs mit einem Umfang (bei der letzten Zählung) von 172 Seiten im PDF-Format – eine der umfangreichsten Projektdokumentationen in der Open Source Welt!

Die LINBIT Home Page. Die Website http://www.linbit.com beantwortet alle Ihre Fragen über den zahlungspflichtigen Support von den Entwicklern. Eine Übersicht über die unterstützten Plattformen, SLAs und Preise finden Sie unter http://www.linbit.com/en/products-and-services/drbd-support/pricing?id=358

Die Adfinis SyGroup Home Page. “We are the Linux Engineers” lautet der stolze Slogan auf https://adfinis.com. Mit mehr als 15 Jahren Linux-Erfahrung ist Adfinis SyGroup die erste Adresse in der Schweiz.

Die MariaDB Home Page. Die MariaDB Corporation https://mariadb.com ist die treibende Kraft hinter der Entwicklung von MariaDB und stellt zusammen mit ihren Partnern den Support und die Betreuung für MariaDB Produkte bereit.

---

1. RAID Controller mit BBU, FusionIO Karten und einige SSDs ↩

2. Die Verfügbarkeit eines Aktiv/Aktiv Cluster durch Aufteilen der aktiven Ressourcen auf die Knoten wird empfohlen. ↩

3. Das Aufteilen einer Datenbank funktioniert nicht. Sie können jedoch mehrere MySQL-Prozesse in einem DRBD-Cluster ausführen, bei dem jeder über eine eigene Datenbank und separate Service-IP-Adressen verfügt. ↩

4. z. B. Datenbank Hot Spots ↩

5. All dies kann von einem guten Speichersystem migriert werden. Einer unserer Kunden konnte diese Zeit durch den Wechsel der Speicherung von Festplatten auf FusionIO Karten von ca. 45 Minuten auf 30 Sekunden reduzieren. ↩

6. z. B. MariaDB MaxScale ↩

7. Zum Beispiel aufgrund eines Neustarts oder Upgrades und anschließendem Neustart von MariaDB. ↩