**This is an old revision of the document!**

Ceph-Setup

Host Setup (Stand 2017-10-17)

Vorerst verwenden wir die beiden Intel-Server für CEPH Tests. Beide haben ein RAID1 bestehend aus 2x250GB Harddisk. Auf diesem RAID1 sind 4 Logical Volumes installiert:

  1. /boot - 2GB
  2. /rootfs - 10GB
  3. swap - 2GB
  4. /var - 2GB

ceph1

    cavy@ceph1:~$ sudo ceph-disk list
    /dev/dm-0 other, ext4, mounted on /
    /dev/dm-1 swap, swap
    /dev/dm-2 other, ext4, mounted on /boot
    /dev/dm-3 other, ext4, mounted on /var
    /dev/md0 other, [[LVM2]]_member
    /dev/sda :
     /dev/sda1 other, linux_raid_member
    /dev/sdb :
     /dev/sdb1 ceph data, active, cluster ceph, osd.0
    /dev/sdc :
     /dev/sdc1 ceph data, active, cluster ceph, osd.1
    /dev/sdd :
     /dev/sdd1 other, linux_raid_member
    /dev/sde :
     /dev/sde1 ceph data, active, cluster ceph, osd.4
    /dev/sdf other, unknown
    /dev/sdg other, unknown
    /dev/sdh :
     /dev/sdh1 ceph journal
     /dev/sdh2 ceph journal
     /dev/sdh3 ceph journal
     /dev/sdh4 ceph journal
     /dev/sdh5 ceph journal

Frontalansicht mit Seriennummern der Devices für ceph1

\|\|HD 250GB 5 0014ee 65921284e *) \|\|HD 1TB \|\|HD 1TB \|\|\|\|Anschlüsse \|\| \|\|HD 250GB 5 0014ee 603cbd93f *) \|\|HD 1TB \|\|HD 1TB 5 0014ee 603ffa30c \|\|SSD 240G 5 5cd2e4 14ddb886f \|\|Hd 1TB 5 0014ee 607768171 \|\|

ceph2

cavy@ceph2:~$ sudo ceph-disk list
/dev/dm-0 other, ext4, mounted on /
/dev/dm-1 swap, swap
/dev/dm-2 other, ext4, mounted on /boot
/dev/dm-3 other, ext4, mounted on /var
/dev/md0 other, [[LVM2]]_member
/dev/sda :
 /dev/sda1 other, linux_raid_member
/dev/sdb :
 /dev/sdb1 ceph data, active, cluster ceph, osd.2
/dev/sdc :
 /dev/sdc1 ceph data, active, cluster ceph, osd.3
/dev/sdd :
 /dev/sdd1 other, linux_raid_member
/dev/sde :
 /dev/sde1 ceph data, active, cluster ceph, osd.5
/dev/sdf other, unknown
/dev/sdg other, unknown
/dev/sdh :
 /dev/sdh1 ceph journal
 /dev/sdh2 ceph journal
 /dev/sdh3 ceph journal
 /dev/sdh4 ceph journal
 /dev/sdh5 ceph journal

Frontalansicht mit Seriennummern der Devices für ceph2

\|\|HD 250GB 5 0014ee 6ae762535 *) \|\|HD 1TB \|\|HD 1TB 5 0014ee 607767c31 \|\|\|\|Anschlüsse \|\| \|\|HD 250GB 5 0014ee 6ae762bc6 *) \|\|HD 1TB \|\|HD 1TB \|\|HD 1TB 5 0014ee 65ccbc69a \|\|SSD 240GB 5 5cd2e4 14ddb6321 \|\|

  • ) das sind Vermutungen

Cluster Setup (Stand 04.04.2017)

Monitore:

monmap e3: 3 mons at {ceph1=172.16.16.17:6789/0,ceph2=172.16.16.18:6789/0,ceph3=172.16.16.19:6789/0}

OSD\'s:

. host ceph1 - osd.0`` ``osd.1`` ``osd.4\ . host ceph2 - osd.2`` ``osd.3`` ``osd.5

Wiederkehrende Probleme

Wenn nach einem Reboot die Journale wieder mal nicht automatisch mounten, weil sie nicht die richtige Permissions ceph:ceph haben, dann haben die Partitionen nicht die richtige parttype, dann folgendes machen: zb ceph2: 

. sgdisk --typecode=3:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/sdf
. sgdisk --typecode=4:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/sdf
. sgdisk --typecode=5:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/sdf

Einrichtung

Die Einrichtung eines neuen Ceph-Admin-Nodes folgt der offiziellen Dokumentation von ceph.

Auf allen Nodes:

  • User cavy anlegen und den ssh-key vom Admin-Node ins .ssh/authorized_keys File kopieren.
  • User cavy sudo-Rechte geben

<!– –

> 

echo "cavy ALL = (root) NOPASSWD:ALL" > /etc/sudoers.d/cavy

-

Die ceph Sourceslist anlegen - Den Ceph-Repo-Key installieren

<!– –

> 

wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -

#

## Am Admin-Node:

  • User cavy anlegen. Als Passwort den Hashwert einer beliebigen Datei verwenden; das Passwort wird nie gebraucht werden.
  • ssh-key generieren
  • Installation von ceph vorbereiten - gleich als User cavy erledigen.

<!– –

> 

wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -
echo deb http://ceph.com/debian-dumpling/ $(lsb_release -sc) main | sudo tee /etc/apt/sources.list.d/ceph.list

-

ceph-deploy installieren

<!– –

> 

sudo apt-get update
sudo apt-get install ceph-deploy

-

Einen neuen cluster anlegen - Die Konfigurationsdatei anpassen - Den ersten Monitor anlegen - OSDs auf den Nodes anlegen

Libvirt/KVM

Mehr Info dazu gibt\'s auch auf der Ceph-Seite. Leider geht noch nicht alles sauber mit dem machine-manager. Ich bin mal so vorgegangen:

<!– –

> 

ceph osd pool create images 200 200

-

Authentication für libvirt einrichten.

<!– –

> 

ceph auth get-or-create client.libvirt mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=images'

-

Den Pool am Virtualisierungsserver mit virsh angelegt. Dazu gibt\'s 

  gute Hinweise auf den Seiten von libvirt,
  <https://libvirt.org/storage.html#StorageBackendRBD> und
  <http://libvirt.org/formatsecret.html#CephUsageType>. Die beiden
  Files, die ich zum Anlegen des Pools verwendet habe sind diese:

ceph-secret.xml 

<secret ephemeral='no' private='yes'>
  <description>Secret holding CEPH passphrase</description>
  <uuid>dcf50f8c-4374-416f-8718-e33815f2cec0</uuid>
  <usage type='ceph'>
    <name>libvirt</name>
  </usage>
</secret>

pool-define.xml 

<pool type='rbd'>
  <name>images</name>
  <source>
    <host name='ceph1.admin.mur.at' port='6789'/>
    <host name='ceph2.admin.mur.at' port='6789'/>
    <host name='ceph3.admin.mur.at' port='6789'/>
    <name>images</name>
    <auth username='libvirt' type='ceph'>
      <secret uuid='dcf50f8c-4374-416f-8718-e33815f2cec0' />
    </auth>
  </source>
</pool>

- Damit legt eins (als root!) zuerst ein Secret an:

<!– –

> 

virsh secret-define ceph-secret.xml

-

Dann wird das secret mit dem KEY des client.libvirt verknüpft (der 

  KEY kann auf ceph1 mit
      ceph auth list
  gefunden werden:

<!– –

> 

virsh secret-set-value dcf50f8c-4374-416f-8718-e33815f2cec0 KEY

-

Damit ist das Secret irgendwo (ich hab selber keine Ahnung wo) in 

  der Virtualiseriungsumgebung gespeichert und kann später in den
  Konfigurationsdateien verwenden werden.

<!– –

>

<

!– –

> 

virsh pool-define pool-define.xml

J

etzt steht der Pool mal prinzipiell auch im virt-manager zur Verfügung (wo er noch gestartet werden muss). Anlegen von Files für Vserver-Images funktioniert auch schon, nur das Einbinden der Images in einen Vserver erfordert noch einen Zwischenschritt mit virsh. Wir verwenden übrigens das selbe Secret auf allen Virtualisierungsservern, damit die VServer auch mirgriert werden können.

VServer einrichten

Das ist jetzt auf eine eigene WikiSeite gewandert.

Snapshots

Wir verwenden Snapshots als Teil des Backups, das hier dokumentiert ist!

Image Snapshots werden mit dem Tool rbd gemacht. Die Doku für die derzeit verwendete CEPH-Version ist hier zu finden. Um einen Snapshot von einem Image zu erstellen, muss I/O der Maschine gestoppt werden. Die wahrscheinlich beste Lösung ist es, die virtuelle Maschine zu pausieren (virsh suspend Domain). Dann kann ein Snapshot sicher erstellt werden:

--(Auf ceph1 ist jetzt ein Mechanismus zum automatischen erstellen von Snapshots eingerichtet: /home/cavy/cephsnap. Das Skript ist dokumentiert und läuft derzeit für die nelke und wal, einmal pro Tag (Nacht) um 5 Minuten nach 4 Uhr. Testhalber heben wir Snapshots vorerst nur für einen Tag (24 Stunden) auf.)--

Die CEPH-Doku hat eine eigene Seite zum Snapshot-Mechanismus: Snapshots mit CEPH.

Icinga Plugin Howto

Damit Icinga-Pluings am Ceph-Cluster ausgeführt werden können, muss sich der Client authentifizieren. Aus diesem Grund muss am Ceph-Server ein spezieller Keyring für den user Icinga/Nagios angelegt werden. So gehts: 

 cavy@ceph2:~$ ceph auth get-or-create client.nagios mon 'allow r' > client.nagios.keyring

Beim Ausführen des Plugins mit dem Keyring schauts so aus: 

/usr/lib/nagios/plugins/check_ceph_health --id nagios --keyring /usr/lib/nagios/plugins/key/client.nagios.keyring

Das ganze funktioniert via nagios-nrpe-server!

Verschiedenes

Ceph verwendet für einige Dinge die Type Codes von GPT. Diese sind (hier gefunden):

TODO

doc/ceph.1690988562.txt.gz · Last modified: by 127.0.0.1