Das Kommandozeilentool ceph-deploy bietet eine vereinfachte und automatisierte Konfiguration mehrerer Ceph-Nodes. Ein Teil dessen ist das Erstellen von OSDs, die seit Version Luminous standardmäßig als Bluestore angelegt werden. Das sog. Journaling des ehem. Filestore wurde durch die Parameter Block-DB/WAL abgelöst, die - vereinfacht formuliert - mithilfe (je) eines schnellen dezidierten Speichers (z.B. einer SSD) das Datenmanagement des OSDs beschleunigen. Der darauf angepasste Befehl sähe nun folgendermaßen aus:

ceph-deploy osd create --data /path/to/data/dev --block-wal /path/to/wal/dev --block-db /path/to/db/dev NODE

Das data/dev sollte eine hohe Speicherkapazität (z.B. HDD) aufweisen, das wal/dev bzw. das db/dev eine hohe Lese-/Schreibrate (z.B. SSD, kann dasselbe dev sein).

 

Die Zeitsynchronisation bei Ceph auf Ubuntu 18.04-Systemen muss so konfiguriert werden, dass NTP anstatt des standardmäßigen timesyncd-Dienst verwendet wird. Dies erfolgt mit folgenden Befehlen auf allen Ceph-Nodes (setzt einen installierten NTP-Dienst voraus):

sudo timedatectl set-ntp off

sudo systemctl enable ntp

Zusätzlich ist empfehlenswert, in der /etc/ntp.conf auf allen Nodes einen Node-Hostnamen als weitere Referenz durch folgende Zeile server NODE1 hinzuzufügen, falls die externen Zeitserver nicht erreicht werden können. Danach muss je Node der NTP-Dienst neugestartet werden.

sudo systemctl restart ntp

Werden die obigen Schritte nicht durchgeführt, gibt Ceph eine Warnmeldung über die Asynchronizität der Nodes aus, sodass ein sicherer Datenabgleich nicht gewährleistet werden kann.

 

Beim Versuch, unter ONe ein Snapshot von einer VM zu erstellen, erscheint im Log, dass das Format raw für VM-Snapshots nicht kompatibel sei, obwohl die Images als qcow2 angelegt wurden. Dieser Schein trügt, denn in der jeweiligen Datei mit den Eigenschaften einer VM steht, dass das Image als raw vorliegt. Grund dafür ist, dass Ceph derzeit keine native Unterstützung für qcow2 enthält und somit alle Images automatisch als raw anlegt. Ein Snapshot ist unter der Verwendung von Ceph nur für Images und nicht für VMs möglich. Ein Rollback eines solchen Snapshots ist zudem nur im ausgeschalteten Zustand der VM möglich. Außerdem bietet ONe bisher keine Möglichkeit, einen scheduled task für Image-Snapshots zu erstellen. Eine Möglichkeit, sich dagegen Abhilfe zu verschaffen, wäre, ein (Ana)cron-Job (zeitgesteuerte Skripts unter Linux) mithilfe eines Shell-Skriptes zu erstellen. Die Programmierung eines solchen Skriptes erfordert zwar erweiterte Programmierkenntnisse, jedoch lassen sich so die Snapshot-Aufgaben sehr detailliert formulieren, da jegliche Tools des Betriebssystems zur Verfügung stehen. Z.B. lassen sich die Snapshots direkt auf ein externes Medium, wie einem NAS, als Image-Datei exportieren, um später wieder – auch in einem anderem Cluster – importiert zu werden. Hier ein Beispiel für ein solches Skript:

#!/bin/bash
# Create VM snapshots weekly

set -e

#Disk IDs must match VM IDs!
vmids=(1 2 3)       #space separated VM IDs
diskids=(0 1 0)     #space separated Disk IDs

if [ "${#vmids[@]}" != "${#diskids[@]}" ]
then
        echo "Disk IDs don't equal VM IDs! Aborting..."
        exit 1
fi

tmppath="/home/cephadmin"       #path to store Imagess before moving to destination path
destpath="/mnt/nas/vmbackups"   #final destination path
datenow=$(date +%Y%m%d)
for i in "${!vmids[@]}"; do     #walk through the array above
        vmexist=$(onevm list -l ID | grep ${vmids[$i]} | tr -s ' ')
        if [ -z $vmexist ] || [ ${vmids[$i]} != $vmexist ]      #check whether VM ID exists with given Disk ID
        then
                echo "VM with ID ${vmids[$i]} doesn't exist. Skipping..."
        else
                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                #ensure snapshot can or needs to be created
                if [ -z "$(onevm show ${vmids[$i]} | awk '/VM DISKS/' RS= | tail -n +2 | awk '{ print $1$2 }' | grep ${diskids[$i]}cephds)" ] || [ -n "$(oneimage list -x | grep ${vmids[$i]}-${diskids[$i]}-IMG$datenow)" ] || [ $vmstate == "unde" ]
                then
                        echo "VM ${vmids[$i]} not valid or necessary, skipping..."
                else
                        onevm disk-snapshot-create  ${vmids[$i]}  ${diskids[$i]} "Snap$datenow"
                        vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "snap" ]
                        do
                                sleep 1
                                echo "Waiting for snap to be created..."
                                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        imgout=$(onevm disk-saveas ${vmids[$i]}  ${diskids[$i]} "${vmids[$i]}-${diskids[$i]}-IMG$datenow")
                        vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "hotp" ]
                        do
                                sleep 1
                                echo "Waiting for image to be created..."
                                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        imgid=$(echo $imgout | cut -d ' ' -f3)
                        imgstate=$(oneimage list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "lock" ]
                        do
                                sleep 1
                                echo "Waiting for image to get finished..."
                                imgstate=$(oneimage list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        qemu-img convert -f raw rbd:one/one-$imgid -O raw $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                        #copy to destination
                        cp $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw $destpath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                        #remove temporary file
                        rm -rf $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                fi
        fi
done

exit 0

 

 

Ziel

Die auf dem Proxmox VE betriebenen VMs sollen auf ein OpenNebula-Cluster migriert werden.

Vorgehensweise

Backup der Proxmox VE VMs

Zunächst müssen von den für die Migration vorgesehenen VMs jeweils ein Backup erstellt werden. Am einfachsten geschieht dies über die Weboberfläche des Proxmox VE. Dazu wird jeweils die VM ausgewählt und mittels der Backup-Schaltfläche (nicht Snapshot) an einem beliebigen Ort ein unkomprimiertes Backup erstellt. Dabei gilt es, ggf. den im Log angezeigten Pfad in die Zwischenablage zu kopieren.

Konvertierung des Backups

Nach Beendigung des Backupvorgangs ist die Kommandozeile des Proxmox VE zu öffnen - am besten via ssh. Hier ist folgender Befehl auszuführen:

vma extract BACKUP AUSGABE

Dabei ist BACKUP der Pfad aus der Zwischenablage (inkl. .vma-Endung) und AUSGABE das Verzeichnis, in das die konvertierte VM abgelegt werden soll. Die im Ausgabeverzeichnis entstandene raw-Datei ist das zu importierende VM-Image.

Anmerkung: Bei anderen Virtualisierungs-Lösungen, wie z.B. VMware oder VirtualBox, besteht i.d.R. ebenfalls die Möglichkeit einer Konvertierung der Images. Bei den genannten Beispielen ist diese Funktionalität entsprechend im qemu-Toolkit integriert.

Import der VM-Images in OpenNebula

Die schnellste Variante für den Import der VM-Images ist die Verwendung der Kommandozeile. Dazu müssen die raw-Dateien für den KVM-Node zugänglich sein, auf dem OpenNebula installiert ist. Ist diese Bedingung erfüllt, wird sich optimalerweise wieder per ssh mit diesem Node verbunden. Dort ist mit einem dazu berechtigtem User folgender Befehl auszuführen:

oneimage create -d DSID --name NAME --path RAWDATEI --type OS [--persistent]

Dabei ist DSID die ID des Datastores, in der das Image gespeichert werden soll, NAME der Anzeigename des Images und RAWDATEI der Pfad der zuvor entstandenen raw-Datei (mit .raw-Endung). Als Zusatz gibt es das optionale Flag "--persistent", mit dem das Image als persistent angelegt werden kann.

Starten vom neuen Image

Ist das neue Image zur Verwendung freigegeben (Status READY), kann nun aus einem VM-Template eine Instanz mit diesem Image als Startdisk initiiert werden. Nach dem Starten dieser VM-Instanz sind i.d.R. keine weiteren Eingriffe in Konfigurationen notwendig.

Resume

Das obige Szenario erwies sich in unserem Unternehmen als äußerst erfolgreich. Innerhalb weniger Stunden wurden alle relevanten Proxmox VE-VMs in das OpenNebula-Cluster migriert. Durch die zudem stärkere Hardware ergaben sich signifikante Leistungssteigerungen, besonders im Seitenaufbau von Webservern. 

 

Recently we struggled somehow on our first Opennebula Cluster with LVM Datastores.

In the past we‘re using ceph as Storage where the integration with Opennebula is well documented and all in all straight forward.

For an new private Cloud of one of our customers descision was taken to choose HP MSA 1040 with SAS-Controller due to limited budget and as massive scaling is not expected in the near future.

 

So we followed the Opennebula documention but we expirence some aweful lacks of hints how to bring all together.

 

So here what we‘ve done to get the setup running:

 

As mentioned in the docs you don‘t need to have a cLVM (Clustered Logical Volume Manager) in Place. LVS metadata is spread by Opennebula, but you have to be careful regarding some conventions.

 

Create or change Datastores

Take config from original docs

> cat system.conf

NAME = lvm_system

TM_MAD = fs_lvm

TYPE = SYSTEM_DS >

onedatastore create system.conf

ID: 103 cat image.conf

NAME = production

DS_MAD = fs

TM_MAD = fs_lvm

DISK_TYPE = "BLOCK"

TYPE = IMAGE_DS

SAFE_DIRS="/var/tmp /tmp"

> onedatastore create image.conf

ID: 107

Install LVM2 on all nodes

As we‘re running Ubuntu server 16.04LTS

 

sudo apt install lvm2

 

Stop and disable lvm metadata caching daemon lvmetad

 

sudo systemctl stop lvmetad.service

sudo systemctl disable lvmetad.service

 

Change /etc/lvm/lvm.conf on all nodes

 

use_lvmetad = 0

 

Add user oneadmin to group „disk“

 

sudo moduser -a -G disk oneadmin

 

Setup LVM pv, vg

 

If you like to run System and Image Datastore on LVM create two Physical Volumes. As we have only one RAID we first created to partitions with approbriate sizes with fdisk.

 

sudo pvcreate /dev/sdb1

sudo pvcreate /dev/sdb2

 

Now the tricky part:

For the system datastore you must create a volume group with the naming convention vg-one-<DatastoreId>. In our case we have 103 as System datastore id

 

sudo vgcreate /dev/sdb1 vg-one-103

 

Create volume group and logical volume for Images

 

sudo vgcreate /dev/sdb2 vg-one-107

sudo lvcreate vg-one-107 images

 

About the next steps to bring up Image datastore we come back later.

 

Ensure with vgscan that all hosts in cluster

vgscan

Reading all physical volumes. This may take a while...

Found volume group "vg-one-103" using metadata type lvm2

Found volume group "vg-one-107" using metadata type lvm2

 

 

Right now you should have the system datastore in place and ready to run.

 

Image Datastore

In contrast to system datastore you need to have a file system on image datastore and have something like NFS or GlusterFS in place to make the images accessable for the nodes.

Create filesystem on LV „images“

sudo mkfs.ext4 /dev/vg-one-107/images

Mount the volume e.g.

mount /dev/vg-one-107/image /mnt/images

Add to fstab to make mapping persistant

 

Install nfs-server on frontend

sudo apt install nfs-kernel-server

Export the image directory

 

Add the directory and nodes to /etc/exports

/mnt/images node02(rw,sync,no_subtree_check,no_root_squash) node03(rw,sync,no_subtree_check,no_root_squash)

! ensure too add the no_root_squash option !

Create symblic link to datastore

ln -s /mnt/images /var/lib/one/datastore/107

and change owner to oneadmin

chown -R oneadmin:oneadmin /var/lib/one/datastore/107

NFS Settings on cluster nodes

Install nfs

sudo apt install nfs-common

create mounting point

mkdir /mnt/images

add nfs export to /etc/fstab

192.168.123.123:/mnt/images /mnt/images nfs rw,soft,intr,rsize=32768,wsize=32768 0 0

mount -a

Create symbolic link to datastore

ln -s /mnt/images /var/lib/one/datastore/107

change owner to oneadmin

That‘s all!

You have to keep in mind that you have to change your exports at nfs server in case you add a new node to your cluster.  

SSO für Magento 1.9

Für ein Webshop Projekt aus der Volkswagengruppe haben wir die Magento Extension Samsson fertiggestellt, die SingleSignOn gegen beliebige Saml 2.0 konforme IdentityProvider bereitstellt. 

Die Extension basiert auf der Bibliothek php-saml und kann bequem über das Backend konfiguriert werden. Vorrausgesetzt der Saml-Assertion liefert eine eMail-Addresse, wird beim ersten Login automatisch ein neuer Customer angelegt, falls noch nicht vorhanden. 

Das Upgrade von Jewel nach Luminous hält doch den einen oder anderen Fallstrick parat. Vor allem, wenn wie unserem Fall das Upgrade per apt auf den Nodes selbst vorgenommen wird. 

Hier die Schritte im Einzelnen:

Die Nodes vorbereiten

ceph osd set sortbitwise
ceph set noout

Die Quellen für apt anpassen: 

sed -i 's/jewel/luminous/' /etc/apt/sources.list.d/ceph.list

Und das eigentliche Update durchführen:

apt-get update && apt-get dist-upgrade

Dann die MON Dienste neustarten

systemctl restart ceph-mon@<id>

Schließlich noch die OSDs

systemctl restart ceph-osd.target

Und schließlich mit 

ceph osd require-osd-release luminous
ceph osd crush tunables optimal
ceph osd unset noout

den Cluster für Luminous optimieren. 

Soweit alles ganz problemlos und genauch nach ceph-Manual

Was die offizielle ceph Dokumentation leider verschweigt, ist das auf diese Weise der neue Dienst ceph-mgr nicht installiert wird, was ceph health nicht nur mit der ungewohnten Meldung "no active mgr" quittiert, sondern auch sämtliche Pools als inexistent ausweist 

ceph status
  cluster:
    id:     046d138f-6d9a-4aaa-918b-142ea99cffbc
    health: HEALTH_WARN
            no active mgr
 
  services:
    mon: 3 daemons, quorum ham-nebula-01,ham-nebula-02,ham-nebula-03
    mgr: no daemons active
    osd: 3 osds: 3 up, 3 in
 
  data:
    pools:   0 pools, 0 pgs
    objects: 0 objects, 0 bytes
    usage:   0 kB used, 0 kB / 0 kB avail
    pgs:  

Nachdem der ersten Schrecken aus den Beinkleidern gewichen, erst mal über ceph-mgr kundig gemacht und wie in den Release Notes zu lesen ist der MGR Dienst seit Luminous ein notwendiger notwendiger Bestandteil geworden. 

Zuerst einfach auf allen MON Nodes das Paket ceph-mgr mit 

apt-get install ceph-mgr

nachinstallieren. Dann wird es etwas tricky: 

Für jeden MGR-Node einen Keyring generieren 

ceph auth get-or-create mgr.<mgr-name> mon 'allow profile mgr' osd 'allow *' mds 'allow *'
ceph auth get mgr.<mgr-name>

exported keyring for mgr.<mgr-name>

[mgr.<mgr-name>]

	key = xxxxxxxxxxxxxxxxxxxxxxxx==
	caps mds = "allow *"
	caps mon = "allow profile mgr"
	caps osd = "allow *"

und unter /var/lib/ceph/mgr/<cluster>-<mgr-name>/keyring speichern. Dabei muss der File-Eigentümer unbedingt auf ceph:ceph geändert werden. 

Wenn das erledigt ist kann der Dienst enabled und gestartet werden 

systemctl enable ceph-mgr@mgr3.service
systemctl start ceph-mgr@mgr3

Und als kleines Extra noch das nagelneue Dashboard in Betrieb nehmen mit 

ceph mgr module enable dashboard

Damit steht ein schickes Web Dashboard unter Port 7000 zur Verfügung