KVM etabliert sich als Standardlösung zur Virtualisierung unter Linux. Der ADMIN-Schwerpunkt hilft beim Bau virtueller Linux-Maschinen, stellt das ... (mehr)

Die eigene Crushmap

In einer eigenen Crushmap kann der Administrator nach Belieben festlegen, wie die Objekte seiner Pools zu verteilen sind. Das Tool »crushtool« leistet in diesem Zusammenhang wertvolle Dienste, denn es erstellt entsprechende Vorlagen. Das folgende Beispiel erstellt eine Crushmap für ein Setup aus sechs OSDs (also einzelne Storage-Devices in Servern), die auf drei Racks verteilt sind:

»crushtool --num_osds 6 -o crush.example.map --build host straw 1 rack straw 2 root straw 0«

Der Parameter »--num_osds 6« legt fest, dass dem Cluster sechs einzelne Storage-Devices zur Verfügung stehen. »--build« leitet ein Statement aus drei dreiteiligen Parametern ein, die der Syntax »Name Interner Crush- Algorithmus Zahl« folgen. »Name« ist frei wählbar, allerdings empfiehlt es sich, aussagekräftige Bezeichnungen zu nutzen. »host straw 1« legt fest, dass pro Host eine Replica erlaubt ist, »rack straw 2« lässt RADOS wissen, dass pro Rack 2 Server existieren. »root straw 0« bezieht sich auf die Anzahl der Racks und legt fest, dass die Replicas gleichmäßig auf die vorhandenen Racks verteilt sein sollen.

Wer sich die entstandene Crushmap im Klartext ansehen möchte, der greift anschließend zum Befehl »crushtool -d crush.example.map -o crush.example« ; die Datei, in der die Map im Klartext steht, ist dann »crush.example« (Listing 1). Die Namen der Devices und Hosts (»device0, device 2 ...« und »host1m host 2 ...« ) sind freilich an die lokalen Gegebenheiten anzupassen. So sollte der Name des Devices mit dem Devicenamen aus »ceph.conf« übereinstimmen (im Beispiel »osd.0« ), und der Hostname sollte mit dem Hostname des Server kongruieren.

Listing 1

Die Crushmap für 6 Server in 2 Racks

 

Replikas auf Racks verteilen

Die eigentliche Replikation definiert die Zeile »step chooseleaf firstn 0 type rack« , die festlegt, dass Replicas auf die Racks zu verteilen sind. Um für eine Verteilung pro Host zu sorgen, weicht »rack« zugunsten von »host« . Die Parameter »min_size« und »max_size« wirken unscheinbar, sind aber ganz besonders in Kombination mit »ruleset 1« von großer Bedeutung dafür, dass RADOS später tatsächlich auch die erstellte Regel nutzt. Für jeden Pool ist festgelegt, welches Ruleset der Crushmap es verwendet; RADOS matcht dabei aber nicht nur auf den Namen, sondern eben auch auf die Paremeter »min_size« und »max_size« , die sich auf die Anzahl der Replikas beziehen. Konkret heißt das: Soll RADOS einen Pool nach dem Ruleset 1 beackern, der 2 Replicas nutzt, greift die Regel aus dem Beispiel. Hat der Admin aber mit dem oben erläuterten Befehl festgelegt, dass 3 Replikas für die Objekte des Pools vorhanden sein sollen, würde RADOS die Regel nicht anwenden. Um sie genereller zu gestalten, empfiehlt sich »min_size« mit 1 und »max_size« mit 10 – diese Regel greift dann für alle Pools, die das Ruleset 1 nutzen und eine bis zehn Replikas voraussetzen.

Ausgehend von diesem Beispiel ist es Admins möglich, eine eigene Crushmap zu gestalten. Diese muss anschließend ihren Weg zurück in RADOS finden.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019