Proxmox ZFS large_dnode Grub unknown filesystem reparieren
3 Jun 2020 Lesezeit: 3 Minuten
Aus der bliebten Reihe: "wie werde ich zum Volltrottel und kann mir Stunden meines Lebens versauen" zeige ich heute, wie man sich retten kann, wenn man etwas zu voreilig seinen ZFS Pool optimiert und dann auch noch das Wiki von Proxmox dazu nutzt.
Dort steht zwar in einer Warnung
Warning: Do not set dnodesize on rpool because GRUB is not able to handle a different size. see Bug entry https://savannah.gnu.org/bugs/?func=detailitem&item_id=48885
wer aber ein echter Mann ist überliest das und activiert das Feature in dem er
zfs set xattr=sa dnodesize=auto rpool/$IRGENDEINDATASETausführt. Ausschlaggebend ist dnodesize mit einem anderen Wert als legacy. Das steht auch so in der ZFS manpage.
Nun ist das Kind in den Brunnen gefallen und ein
``bash zpool get all rpool | grep -i node rpool feature@large_dnode active local
bestätigt uns, das wir uns bis auf weiteres nichts mehr vornehmen sollen. Wenn hier nämlich **active** steht, dann ist das doof für uns und unser rpool wird mit hilfe von Grub nicht mehr booten.
Vorausgesetzt wir haben genug Platz auf unserem Server, so können wir aber alle Container herunterfahren und die Volumes/Datasets migrieren in ein Dataset, welches dnodesize=legacy gesetzt hat. Das will man natürlich so schnell und einfach wie möglich haben. Daher hab ich den Vorgang für mich wie folgt automatisiert:
```bash
zfs create rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs snapshot -r rpool/BISHERIGESDATASET@migrate
zfs send -Rv rpool/BISHERIGESDATASET@migrate | zfs receive -F rpool/$IRGENDEINDATASET-FUER-NEUE DATEN
zfs destroy -r rpool/BISHERIGESDATASET
zfs rename rpool/$IRGENDEINDATASET-FUER-NEUE DATEN rpool/BISHERIGESDATASETAnschließend sollte unsere Kontrolle statt
zpool get all rpool | grep -i node
rpool feature@large_dnode **active** localzpool get all rpool | grep -i node
rpool feature@large_dnode **enabled** localauswerfen. Jetzt heisst es nur noch Container starten.
EDIT
Leider habe ich feststellen müsse, das die obige Anleitung nicht immer (genauere Hintergründe unbekannt) funktioniert. Auch tut sich der eine oder andere Schwer mit der CLI. Dann kann man sich behelfen indem man ein weiteres Dataset anlegt und dieses in der Proxmox UI einbindet. Nun kann man einfach über die UI LXC Server stoppen, das Dataset migrieren und wieder starten. Geht soweit ganz gut... hätte man auch früher haben können :)
Proxmox Ceph filestore zu bluestore
16 Mär 2020 Lesezeit: 2 Minuten
Ich hatte ja beschrieben wie man sich auf einfache Art und Weise den Tag versauen kann, indem man "mal eben" seinen Ceph Cluster auf Nautilus aktualisiert.
Wenn man sich wieder beruhigt hat, dann kann man auch darüber nachdenken wie man seinen ollen Filestore auf Bluestore aktualisiert. Das geht nämlich eigentlich ganz einfach, indem man aufhört Filestore zu nutzen und die Partition mit Bluestore formatiert und wieder einbindet.
Tendenziell bin ich bei sowas ja faul und möchte die Arbeit einmal richtig machen und dann beliebig oft reproduzieren. Daher muss ich folgende Schritte gehen:
- OSD im Cluster Deaktivieren: ceph osd out $
- OSD Dienst stoppen: systemctl stop ceph-osd@$i.service
- OSD kaputt machen: ceph osd destroy $ --yes-i-really-mean-it
- Partition bereinigen: ceph-volume lvm zap /dev/sdXX
- Partition mit bluestore anlegen und wieder einen OSD bereitstellen: ceph-volume lvm create --data /dev/sd$i$PARTITION
Jetzt wo ich alles habe, kann ich die Schritte auch für die anzahl der OSD und Festplatten automatisieren:
OSDONHOST="0 1 2 3 4 5 6 7"
PARTITIONTOUSE=4
for i in $OSDONHOST
do
ceph osd out $i
systemctl stop ceph-osd@$i.service
ceph osd destroy $i --yes-i-really-mean-it
done
for i in a b c d e f g h
do
ceph-volume lvm zap /dev/sd$i$PARTITION
ceph-volume lvm create --data /dev/sd$i$PARTITION
doneJetzt sollte man aber auch so brav sein und das nicht sofort bei allen Knoten machen - das Resilvern dauert ein wenig.
Periodische Snapshots mit Proxmox
13 Mär 2020 Lesezeit: 3 Minuten
Ich liebe ja Proxmox. Es ist so herrlich einfach und ziemlich gut durchdacht. Es bietet viele Möglichkeiten zu realisieren was man sich vorstellt und so sehr individuelle Umgebungen zu bauen.
Was es leider nicht mitbringt ist die Möglichkeit periodisch snapshots der vorhandenen VMs zu machen und so zumindest einen Zwischenstand für kritische Systeme zu erzeugen, bei denen es vielleicht nicht angebracht ist alle Stunde ein Backup zu machen.
Dennoch gibt es dazu eine tolle Lösung die weitestgehend auf die Boardmittel zurück greift - Danke an Corsinvest für cv4pve-autosnap.
Zunächst legt man sich einen neuen Benutzer innerhalb von Proxmox an, unter dessen Fahne man zukünftig automatisiert die Snapshots macht. Dabei macht es sinn auf die lokale Proxmox Datenbank zurück zu greifen.
Natürlich braucht dieser Benutzer auch Berechtigungen:
Anschließend schnappt man sich das kleine feine Tool:
wget https://github.com/Corsinvest/cv4pve-autosnap/releases/latest/download/cv4pve-autosnap-linux-x64.zip
unzip cv4pve-autosnap-linux-x64.zip
chmod +x cv4pve-autosnap
mv cv4pve-autosnap /usr/local/bin/ #OPTIONALAnschließend schaut man brav die Optionen an:
______ _ __
/ ____/___ __________(_)___ _ _____ _____/ /_
/ / / __ \/ ___/ ___/ / __ \ | / / _ \/ ___/ __/
/ /___/ /_/ / / (__ ) / / / / |/ / __(__ ) /_
\____/\____/_/ /____/_/_/ /_/|___/\___/____/\__/
Automatic snapshot VM/CT with retention (Made in Italy) 1.7.2
Automatic snapshot VM/CT with retention
Usage: cv4pve-autosnap [options] [command]
Options:
-?|-h|--help Show help information
--version Show version information
--host The host name host[:port],host1[:port],host2[:port]
--username User name <username>@<realm>
--password The password. Specify 'file:path_file' to store password in file.
--vmid The id or name VM/CT comma separated (eg. 100,101,102,TestDebian)
-vmid or -name exclude (e.g. -200,-TestUbuntu)
'all-???' for all VM/CT in specific host (e.g. all-pve1, all-\$(hostname)),
'all' for all VM/CT in cluster
--timeout Timeout operation in seconds
Commands:
app-check-update Check update application
app-upgrade Upgrade application
clean Remove auto snapshots
snap Will snap one time
status Get list of all auto snapshots
Run 'cv4pve-autosnap [command] --help' for more information about a command.
cv4pve-autosnap is a part of suite cv4pve-tools.
For more information visit https://www.cv4pve-tools.comNun ist es so weit: Shell auf und los geht es. Zunächst einmal fülle ich die Variablen, dann spiele ich mit den Einstellungen und Möglichkeiten des Werkzeuges. Wenn man seine Lösung gefunden hat, dann kann man daraus auch gleich einen Cronjob oder einen Rundeck-Task oder ein skript machen. So einfach ist das:
PROXMOXHOSTS=PVE01,PVE02,PVE03
PROXMOXUSER=Snapshotuser@pve
PROXMOXPASSWORD=SUP3rDup3rGehe1m
PROXMOXLABEL=takecareofit
/path/to/cv4pve-autosnap --host=$PROXMOXHOSTS --username=$PROXMOXUSER--password='$PROXMOXPASSWORD' --vmid=all snap --label='$PROXMOXLABEL' --keep=23Quellen und Links:
