Timedatectl richtig nutzen

10 Dec 2019 - Reading time: ~1 minute

Mir gehen ja hin und wieder gewisse Tatsachen auf den Zeiger. Zum Beispiel unterschiedliche Zeiten auf Serversystemen. Daher hab ich mir folgenden Snippet zurecht gelegt, damit ich einheitlich mal alles richtig einstellen kann. Ausgetauscht werden muss lediglich der NTP-Server - sofern denn einer im Netzwerk bekannt ist. Und natürlich die Zeit selbst.

echo "NTP=0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org" >>/etc/systemd/timesyncd.conf
timedatectl set-ntp false
timedatectl set-time 12:45:30
timedatectl set-local-rtc 0
timedatectl set-ntp true
timedatectl

Ceph auf Proxmox mit Partition

6 Dec 2019 - Reading time: 3 minutes

Ich habe mir in meinem Proxmox-Cluster drei Knoten abgestellt, auf denen ich gern ein Backup der laufenden VMs erstellen möchte. Da mir hier die Performance nicht ganz so wichtig ist, ich aber gleichzeitig maximale Skalierbarkeit und Verfügbarkeit haben möchte, ist der Schritt zu Ceph eigentlich ein logischer.

Dummerweise hat Proxmox dieses Szenario nicht so interpretiert wie ich es gern hätte, sodass sie nur vorsehen ganze Festplatten für Ceph zu nutzen. Mein Setup ist aber viel cooler, denn ich habe auf dem Server, welcher 8 HDDs bestitzt ein ZFS Raid1 über ALLE Plattengespannt, sodass absolut jede Festplatte ausfallen kann ohne das das System kaputt geht. Dazu nutze ich allerdings nur 40GB als Partition - der Rest kann als Backup Platz genutzt werden.

Dafür muss man aber ein wenig Handarbeit leisten.

Host vorbereiten - Cluster erstellen

Auf allen Hosts muss Ceph installiert werden, damit sie es nutzten können.

pveceph install

Anschließend kann man seinen Ceph Cluster einfach erstellen - ich nutzte als Netzwerk das ohnehin schon vorhandene Backup Netzwerk:

pveceph init --network 192.168.199.0/24

Nun muss man sich die ClusterID notieren: grep -i fsid /etc/pve/ceph.conf

Ceph Monitor

Damit Ceph funktionieren kann, braucht es mindestens einen, idealerweise aber mehrere Monitore. Ich nutze dazu meine 3 Backup Knoten und initialisiere sie als Monitor

pveceph createmon

Partitionen vorbereiten

Nun wird es ernst. Ich bin ein fauler Admin. Daher habe ist bei mir möglichst viel einheitlich, damit ich automatisieren kann. In meinem Fall wird auf jeder Festplatte eine 4. Partition erstellt und für Ceph genutzt. Ich benutzt noch eine Paket, das zusätzlich installiert werden muss um eindeutige UUIDs zu erstellen:

apt-get install uuid-runtime

Anschließend kann es losgehen mit der Vorbereitung

PARTITION=4
PTYPE=4FBD7E29-9D25-41B8-AFD0-062C0CEFF05D
CLUSTERID=
for i in a b c d e f g h 
do
    OSD_UUID=$(uuidgen -r)
    sgdisk -d $PARTITION /dev/sd$i
    sgdisk --largest-new=$PARTITION --change-name="$PARTITION:ceph data" --partition-guid=$PARTITION:$OSD_UUID  --typecode=$PARTITION:$PTYPE -- /dev/sd$i
done

partprobe

for i in a b c d e f g h 
do
    OSD_UUID=$(uuidgen -r)
    ceph-disk prepare --filestore --cluster ceph --cluster-uuid $CLUSTERID --osd-uuid $OSD_UUID --fs-type xfs /dev/sd$i$PARTITION
    ceph-disk activate /dev/sd$i$PARTITION
done

Dieser Schritt dauert ein wenig. Man sollte allerdings zusehen können, die die OSDs im Proxmox auftauchen. Zur Sicherheit würde ich einen Reboot des Servers ausführen. Kontrollieren kann man übrigens auch über die CLI

ceph osd tree
ceph status

Quellen und Links:


Recover eines MariaDB Galera Cluster

6 Dec 2019 - Reading time: 3 minutes

Leider kommt es auch bei mir mal vor, das irgendwas kaputt geht und ich es dann reparieren muss. Wenn man halbwegs gute Software nutzt geht das eigentlich auch immer ganz gut.

Zuletzt saß ich vor einem MariaDB Galera Cluster, bei dem alle Member gecrasht sind. Das ist so ziemlich das übelste was passieren kann. Zum Glück war grade nicht so viel los und der Prozess gestaltet sich gut umsetzbar.

Zunächst einmal stoppen wir auch allen Knoten den Service

systemctl stop mariadb

Anschließend editieren wir die Datei /etc/my.cnf.d/server.cnf und nehmen alle Member aus der Connection-Liste wsrep_cluster_address. Zum Schluss steht nur noch

wsrep_cluster_address="gcomm://"

drin.

Anschließend starten wir den Dienst wieder. Dazu kontrollieren wir vorher die Datei /var/lib/mysql/grastate.dat ob sie den Wert safe_to_bootstrap: 1 besitzt - sollte dem nicht so sein, so ändern wir dies manuell sed 's/^safe_to_bootstrap.*/safe_to_bootstrap: 1/' */var/lib/mysql/grastate.dat

Danach geht es weiter - auf allen Knoten!

systemctl start mariadb

Jetzt sind wir in der Lage heraus zu finden, welcher der Member zuletzt etwas sinnvolles getan hat und die höchste TransaktionsID besitzt:

 mysql -u root -e "show status like 'wsrep_last_committed';"

Diesen Member schnappen wir uns und machen ihn zum Master für unseren neuen Cluster. Dazu kontrollieren wir die Datei /var/lib/mysql/grastate.dat ob sie den Wert safe_to_bootstrap: 1 besitzt - sollte dem nicht so sein, so ändern wir dies manuell

galera_new_cluster

Nun gehen wir zu den restlichen Knoten und ändern den Wert wsrep_cluster_address wieder zurück auf seinen Ursprünglichen Inhalt. Anschließend starten wir den Dienst neu und schauen im Log nach ob sich was tut und warten auf eine Meldung wie " WSREP: Recovered positi":

systemctl restart mariadb && journalctl -f -u mariadb

Quellen und Links:


Über

Ich bin manisch interessiert am Leben. An den Dingen die wir tun können und den Optionen die sich uns bieten. IT, Netzwerke und EDV im allgemeinen sind mein Steckenpferd: ich mache das einfach zu gern und bin gut darin zu kombinieren. Fotografie, Hunde, Jagd, Falknerei ist das, was mich vollständig macht. All diese Dinge gehören zu meinem Leben und ich genieße jeden Tag.