ADVENTOS Blog

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.