Wartung Proxmox Knoten mit Ceph im Livebetrieb

[KnowVation]

Hallo Zusammen,

Bei meiner Frage geht es um die standard Prozedur im Wartungsfall.

Aktuell hatten wir wieder den Fall dass eine OSD mit einem Defekt verabschiedet hat. Bisher haben wir das mit der Wartung so gehandhabt:

Benötigte VMs von dem Knoten mit der defekten OSD auf einen anderen Knoten migiriert
Set osdnoout um dem Ausgleich zu stoppen
Dann den Knoten mit der defekten OSD heruntergefahren, SSD Getauscht etc.

Bisher hat das immer ganz gut so funktioniert, das heißt alle anderen Knoten liefen normal weiter und es konnte ohne Probleme auf deren VMs gearbeitet werden.

Seit Anfang des Jahres sind wir auf Proxmox 7 umgestiegen und hatten eben wieder mal einen Fall mit defekter SSD/OSD.
Hier haben wir die gleiche Prozedur wie immer durchgeführt, nur leider wurden die OSDs des entsprechenden Knoten obwohl wir vorher den Ausgleich gestoppt hatten und der Knoten heruntergefahren war immer noch als up&in angezeigt. Als Folge gab es einen kompletten Freeze aller VMs und es konnte nichtmehr gearbeitet werden. Erst als wir den Knoten mit der ausgetauschten SSD/OSD wieder hochgefahren hatten war der Freeze weg, Ausgleich lief und alle VMs konnten normal benutzt werden.

Müssen wir hier bei Proxmox bzw. Ceph weitere schritte durchführen bevor ein Knoten kurzzeitig aus dem Cluster genommen wird?

Danke und Gruß
Ronny

 

[aaron]

Wie war denn der Status von Ceph vorm Herunterfahren der Node? Wenn die Pools stehen, sobald die Node down ist, kann ich mir vorstellen, dass Ceph auch anderweitig gerade nicht die volle Redundanz hatte. Wenn dann durch das Herunterfahren der Node weniger als "min_size" Kopien von mindestens einer PG vorhanden sind, wird IO komplett geblockt bis ausreichend Kopien vorhanden sind. Das ist entweder, wenn Ceph genug Kopien recovern konnte oder die OSDs mit den Kopien wieder da sind.

Deshalb ist es am besten, vor so einer Aktion Ceph zuerst wieder einmal ein Recovery machen zu lassen, damit die Kopien, die auf der defekten OSD waren wiederhergestellt werden können und der Ceph Status wieder "HEALTH_OK" ist. Ja nach dem Austausch gibts dann auch wieder ein Rebalance das mitunter dauert. Aber so kann man vermeiden, dass andere Probleme übersehen werden, die dann dazu führen können, dass nicht genug Kopien/Replicas vorhanden sind.


Sind die Server Hot Plug fähig? Dann könnte man sich das Herunterfahren der Node auch sparen.

 

[KnowVation]

Also der Ceph Status war vor der Austausch Aktion schon wieder auf "HEALTH_OK" die Daten der defekten OSD waren bereits wiederhergestellt / auf andere OSDs verteilt. Daran lag es also nicht, trotzdem Danke für den Hinweis.

 

[aaron]

Ich hab das gerade in einem kleinen 3-Node Testcluster nachgestellt. Eine Node herunterfahren, während eine VM IO produziert. Hat alles geklappt, ohne dass die VM hängen blieb.
Bis Ceph die OSDs als Down anzeigt, kann es ein paar Augenblicke brauchen.

Ohne weitere Informationen zum Cluster kann ich nur ein bisschen ins blaue raten. Wenn es nicht genug Monitore gibt (<3) dann kann es sein, dass das Quorum der Monitore verloren geht, wenn eine Node mit Mon heruntergefahren wird. Wie sind die "size" und "min_size" Parameter der Pools? Wenn diese kleiner als 3/2 sind, könnte es hier auch dazu kommen, dass nicht genug Redundanz vorhanden ist. Wurden eigene Crush Regeln erstellt, die vielleicht die Replicas so verteilen, dass auf einer Node mehr als eine liegt? Gibt es genug Nodes im Cluster, damit die Replicas auf Node Ebene verteilt werden können?

 

[KnowVation]

Hier ein Paar zusätzliche Infos:

Wir haben 6 Knoten von denen alle auch Monitore sind, einer davon ist Manager. Size und min_size des Pools ist 2/2. Jeder der Knoten verfügt über 6x 1TB OSDs, also insgesamt 36 von denen dann 6 OSDs durch ausschalten des einen Knoten weggefallen sind.
Crush Regeln sind Standard.

Könnte in dieser Kombination die Size und min Size ausschlaggebend sein? Früher hatten wir die gleichen Parameter und mit set noout keinerlei Probleme.

 

[aaron]

Size und min_size des Pools ist 2/2

Das wird der Grund sein. Wenn die Node down ist, haben einige PGs nur noch eine Replica -> weniger als die min_size und somit wird IO geblockt. Das wird auch Probleme machen, wenn eine Node mal komplett stirbt. Bei 3/2 wären noch 2 Replicas vorhanden und der Cluster würde weiter laufen.

Wenn mehr Nettospeicherplatz wichtig ist, schaut euch EC Pools an. Seit Proxmox VE 7.2 gibt es dafür Unterstützung: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pve_ceph_ec_pools

einer davon ist Manager

Auf anderen Nodes sind hoffentlich auch Manager installiert die übernehmen, falls die jetzige Manager Node ausfällt.

 

[KnowVation]

Kann man den IO block auch kurzfristig abschalten? Wäre eine Umstellung auf 2/1 bei 6 Knoten vertretbar untern normalen umständen fallen nicht zwei Knoten gleichzeigtig aus bzw. sollten bei 6 Knoten mit jeweils 6 OSDs auch gleichzeitig zwei ausfallen können? Danke für den Hinweis für EC Pools und den Hinweis für die Manager, wir haben auf den zusätzlichen Knoten "standby Manger" installiert.

 

[itNGO]

Keine Ahnung was für Server ihr verwendet,
aber wir hatten kürzlich eine defekte OSD/SSD in einem SuperMicro mit SAS/SATA-Backplane. (3-Node-System)

OSD out und destroy. Platte gezogen, neue OSD rein.... kurz hardware-rescan per shell, OSD angelegt fertig.
Ohne boot ohne stall.... geht einfach.....

Ich kann aber verstehen, das man ggf. den Node räumt und/oder herunterfährt. Wobei das meines Erachtens für eine "disk" wirklich nicht mehr notwendig sein soll... wir haben ja nicht mehr 1990...

 

[aaron]

Kann man den IO block auch kurzfristig abschalten?

Nein.

Wäre eine Umstellung auf 2/1 bei 6 Knoten vertretbar untern normalen umständen fallen nicht zwei Knoten gleichzeigtig aus bzw. sollten bei 6 Knoten mit jeweils 6 OSDs auch gleichzeitig zwei ausfallen können?

Wenn euch eure Daten lieb sind, setzt ihr die min_size nie auf weniger als 2. Das kann im schlimmsten Fall zu unschönen Situationen führen. Entweder schlägt Murphy's Law zu und es passiert halt doch noch was mit der letzten OSD, oder es kann zu anderen Problemen kommen. Folgernder Blog erklärt das recht nett:

We operate our cluster under default CRUSHMAP with the host as a failure domain and with size=2/min_size=1. With replication 2, you usually have two problems:

• if you find an inconsistent object you have some hard time to tell which copy is the correct one
• if you have flapping OSDs, i.e. osd.0 goes down, osd.1 is up and acting and accept writes. At the next moment, osd.1 goes down and osd.0 comes up. osd.0 becomes primary, but the PG is ‘down’ because osd.1 had the last data. In that case, you need osd.1 to come back so that the PG will work again.

And the latter was exactly the situation we got into. Ceph is pedantic and will try to prevent split-brains in the PG level by halting IO. As an administrator you have two options here: either mark the data on the down OSD as lost and let IO continue or try to bring up the crashed OSDs.

Deshalb, min_size bleibt immer mindesten 2. Wenn dann werden die size/min_size bei spezielleren Usecases mitunter höher gesetzt. Zum Beispiel wenn man einen Ceph / PVE Cluster über zwei Brandabschnitte verteilt und den Ausfall eines Brandabschnitts verkraften muss. Dann hat man eher ein 4/2 (neben weiteren Dingen).

 

[KnowVation]

Kann ich irgendwo prüfen / sehen ob IO block aktiv ist bzw. war? Ceph logs?

 

[aaron]

Halte nach "Inactive PGs" ausschau. Ceph sollte eine Warnung haben, die angibt, wie viele PGs inactive sind und im Output von ceph -s sieht man auch noch eine % Anzeige bevor aufgelistet wird, wie viele PGs in welchem Zustand sind.