HA Cluster mit 2PowerNodes und einem schwachen?

K

kuselisebith

New Member
Mar 17, 2022
1
0
1
33
Hallo Zusammen,

ich lese immer wieder dass ein Cluster erst ab 3 Nodes wegen der Gefahr von Splitbrain sauber funktionieren kann. Ist es möglich im Serversetup mit 2 Powernodes zu fahren und um die laufenden Stromkosten zu drücken einen kleinen Rechner (miniRechner) als 3. Instanz in den Cluster aufnimmt? So wie ich das sehe, geht es nur um eine Mehrzahl im Fall eines Failures. - habe ich etwas übersehen?

Danke für eine Einschätzung
 
Ja ist kein Problem.
Machen wir hier im RZ überwiegend. 2 Nodes mit epischer Leistung und 4-Wege-Ceph und ein Node als Zeuge der nur zur Not mal nen paar VMs/CTs aufnehmen kann über eine extra NIC zum CEPH-Storage.... der wird auch meist als Ceph-Manager genutzt....
 
Habe ich zuhause auch. Hab nen Mini PC mit Dual Core Celeron als Quorum.
Da ich auch nur eine NIC sein habe, nutze ich VLANs für die anderen Netzwerke.
 
itNGO said:
Ja ist kein Problem.
Machen wir hier im RZ überwiegend. 2 Nodes mit epischer Leistung und 4-Wege-Ceph und ein Node als Zeuge der nur zur Not mal nen paar VMs/CTs aufnehmen kann über eine extra NIC zum CEPH-Storage.... der wird auch meist als Ceph-Manager genutzt....
Click to expand...
Wie geht denn ein 4-Wege-Ceph auf 2 Nodes? Nicht die Regel, bei prod. 3/2 min, also min 3 Nodes ?
 
VoIP-Ninja said:
Wie geht denn ein 4-Wege-Ceph auf 2 Nodes? Nicht die Regel, bei prod. 3/2 min, also min 3 Nodes ?
Click to expand...
Naja, man legt sich halt einfach die passende Crush-Map selbst an.

Dort hinterlegt man einfach.... nimm die ersten "beiden" Hosts und davon jeweils die ersten "beiden" OSDs....

Und dann entsteht ein 4-Copy-Mirror mit mindestens 2 Online. Du kannst dann jeden Node einzeln booten und das System läuft stabil weiter....
Es gibt einen 3ten Node, aber der ist eben nur "Voter" oder wenn er entsprechend Verkabelt ist auch noch Ceph-Monitor und Manager.

rule APVE-NVME-4WayMirror {
id 1
type replicated
min_size 2
max_size 4
step take RACK-RZB class nvme
step choose firstn 2 type host
step chooseleaf firstn 2 type osd
step emit
}
 
itNGO said:
Naja, man legt sich halt einfach die passende Crush-Map selbst an.

Dort hinterlegt man einfach.... nimm die ersten "beiden" Hosts und davon jeweils die ersten "beiden" OSDs....

Und dann entsteht ein 4-Copy-Mirror mit mindestens 2 Online. Du kannst dann jeden Node einzeln booten und das System läuft stabil weiter....
Es gibt einen 3ten Node, aber der ist eben nur "Voter" oder wenn er entsprechend Verkabelt ist auch noch Ceph-Monitor und Manager.

rule APVE-NVME-4WayMirror {
id 1
type replicated
min_size 2
max_size 4
step take RACK-RZB class nvme
step choose firstn 2 type host
step chooseleaf firstn 2 type osd
step emit
}
Click to expand...
Bei dem Setup musst du nur aufpassen, dass du nicht zu viele OSDs pro knoten hast. Sonst macht der im worst case alle Datenkopien auf dem gleichen node.
 
Falk R. said:
Bei dem Setup musst du nur aufpassen, dass du nicht zu viele OSDs pro knoten hast. Sonst macht der im worst case alle Datenkopien auf dem gleichen node.
Click to expand...
Nein macht er nicht..... das geht hier mit 20 OSDs genauso wie mit 2 pro Node.... Das definiert man ja extra in der Crushmap mit Datacenter, Nodes und OSDs....
 
itNGO said:
Nein macht er nicht..... das geht hier mit 20 OSDs genauso wie mit 2 pro Node.... Das definiert man ja extra in der Crushmap mit Datacenter, Nodes und OSDs....
Click to expand...
Ich habe das selbst mit 4 OSDs pro Node getestet. Nach ein paar Monaten gab es pg‘s die nur auf einem Node repliziert waren.
Dazu müsste man eine Definition zwischen Host und OSD einfügen und da die OSDs gruppieren. Das hat bei mir nie richtig funktioniert.
Kann aber sein, dass ich da einen Fehler drin hatte.
 
Falk R. said:
Ich habe das selbst mit 4 OSDs pro Node getestet. Nach ein paar Monaten gab es pg‘s die nur auf einem Node repliziert waren.
Dazu müsste man eine Definition zwischen Host und OSD einfügen und da die OSDs gruppieren. Das hat bei mir nie richtig funktioniert.
Kann aber sein, dass ich da einen Fehler drin hatte.
Click to expand...
Die Crush-Map muss in etwa so aussehen....
Das haben wir hier bestimmt 2 Dutzend mal so laufen und teils seit Jahren. Da ist nichts was nur auf einem Node repliziert ist.
Es war eine recht aufwendige Suche in den entsprechenden CEPH-Mailings-Listen um diese Config, die eigentlich der MS Storage Spaces Direct 2-Node-4-Way-Mirror Variante nachempfunden ist abzubilden. Aber es funktioniert seit dem 100% zuverlässig. Node-Ausfälle, reboots, es hat bisher alles absolut sauber überstanden. Wir hosten ERP-Systeme, da würden wir was anderes auch "niemals" akzeptieren...


Code: 
# buckets

host RZB-APVE1 {
    id -3        # do not change unnecessarily
    id -4 class nvme        # do not change unnecessarily
    id -7 class ssd        # do not change unnecessarily
    # weight 13.972
    alg straw2
    hash 0    # rjenkins1
    item osd.4 weight 3.493
    item osd.5 weight 3.493
    item osd.6 weight 3.493
    item osd.7 weight 3.493
}
host RZB-APVE2 {
    id -5        # do not change unnecessarily
    id -6 class nvme        # do not change unnecessarily
    id -8 class ssd        # do not change unnecessarily
    # weight 13.972
    alg straw2
    hash 0    # rjenkins1
    item osd.2 weight 3.493
    item osd.1 weight 3.493
    item osd.3 weight 3.493
    item osd.0 weight 3.493
}
rack RACK-RZB {
    id -10        # do not change unnecessarily
    id -11 class nvme        # do not change unnecessarily
    id -12 class ssd        # do not change unnecessarily
    # weight 27.944
    alg straw2
    hash 0    # rjenkins1
    item RZB-APVE1 weight 13.972
    item RZB-APVE2 weight 13.972
}
datacenter APVE {
    id -13        # do not change unnecessarily
    id -14 class nvme        # do not change unnecessarily
    id -15 class ssd        # do not change unnecessarily
    # weight 27.945
    alg straw2
    hash 0    # rjenkins1
    item RACK-RZB weight 27.945
}

# rules

rule APVE-NVME-4WayMirror {
    id 1
    type replicated
    min_size 2
    max_size 4
    step take RACK-RZB class nvme
    step choose firstn 2 type host
    step chooseleaf firstn 2 type osd
    step emit
}
 
itNGO said:
Die Crush-Map muss in etwa so aussehen....
Das haben wir hier bestimmt 2 Dutzend mal so laufen und teils seit Jahren. Da ist nichts was nur auf einem Node repliziert ist.
Es war eine recht aufwendige Suche in den entsprechenden CEPH-Mailings-Listen um diese Config, die eigentlich der MS Storage Spaces Direct 2-Node-4-Way-Mirror Variante nachempfunden ist abzubilden. Aber es funktioniert seit dem 100% zuverlässig. Node-Ausfälle, reboots, es hat bisher alles absolut sauber überstanden. Wir hosten ERP-Systeme, da würden wir was anderes auch "niemals" akzeptieren...


Code: 
# buckets

host RZB-APVE1 {
    id -3        # do not change unnecessarily
    id -4 class nvme        # do not change unnecessarily
    id -7 class ssd        # do not change unnecessarily
    # weight 13.972
    alg straw2
    hash 0    # rjenkins1
    item osd.4 weight 3.493
    item osd.5 weight 3.493
    item osd.6 weight 3.493
    item osd.7 weight 3.493
}
host RZB-APVE2 {
    id -5        # do not change unnecessarily
    id -6 class nvme        # do not change unnecessarily
    id -8 class ssd        # do not change unnecessarily
    # weight 13.972
    alg straw2
    hash 0    # rjenkins1
    item osd.2 weight 3.493
    item osd.1 weight 3.493
    item osd.3 weight 3.493
    item osd.0 weight 3.493
}
rack RACK-RZB {
    id -10        # do not change unnecessarily
    id -11 class nvme        # do not change unnecessarily
    id -12 class ssd        # do not change unnecessarily
    # weight 27.944
    alg straw2
    hash 0    # rjenkins1
    item RZB-APVE1 weight 13.972
    item RZB-APVE2 weight 13.972
}
datacenter APVE {
    id -13        # do not change unnecessarily
    id -14 class nvme        # do not change unnecessarily
    id -15 class ssd        # do not change unnecessarily
    # weight 27.945
    alg straw2
    hash 0    # rjenkins1
    item RACK-RZB weight 27.945
}

# rules

rule APVE-NVME-4WayMirror {
    id 1
    type replicated
    min_size 2
    max_size 4
    step take RACK-RZB class nvme
    step choose firstn 2 type host
    step chooseleaf firstn 2 type osd
    step emit
}
Click to expand...
Vielen Dank fürs teilen, ich teste das mal demnächst.
 
VoIP-Ninja said:
Ich muss das auch mal testen.... wenn "man" schon soviel so "groß" hosted, warum dann diese 2 Node Lösung? Und nicht 5 oder 7 Knoten im produktiven Hostingbetrieb?
Click to expand...
Wir isolieren damit die Nodes vom rest des Netzwerks.... sind immer 2 Nodes direkt mit 25gbe verbunden.... ein "dritter" mit etwas älterer Hardware dann noch mal mit 10GBe und zum internen Hosting-Netz halt jeweils nochmal mit je 2x10gbe. Die Flexibilität gefiel uns einfach besser. Große Cluster können halt auch mal große "Probleme" haben. Wir hatten ursprünglich einen 13Node.Cluster... ein Ruckler im Corosync und alles war "essig". Das mag jetzt in PVE 7.x bzw. 8.x besser sein, aber generell fahren wir mit der 3-Node, 2 als Storage aktuell sehr gut. 2 PBS dazu und man ist sehr "schnell" wieder aus einem Disaster-Case zurück auf Spur, wenn es denn mal einen geben sollte.

Es sind überwiegen EPYC Rome, Milan und einige Naples-Cluster. Da wir sehr genau definieren, welcher Kunde, welche Leistung haben soll, stellte sich das einfach als die "zeitlich" effizienteste Lösung heraus.... Zumal wir so, relativ schnell mal einen 3er Cluster "leer" machen können um dinge zu tun, die man vielleicht nicht auf den "heissen" Kisten machen möchte wenn man 99,9% zusichert. (Pve 7>8) steht grad an....
 
itNGO said:
sind immer 2 Nodes direkt mit 25gbe verbunden.... ein "dritter" mit etwas älterer Hardware dann noch mal mit 10GBe
Click to expand...
Wie macht ihr das mit dem Ceph Storagenetzwerk? Wird der dritte Node geroutet?
 
Falk R. said:
Wie macht ihr das mit dem Ceph Storagenetzwerk? Wird der dritte Node geroutet?
Click to expand...
Ja, in der interfaces config sind entsprechende Zeilen, damit die 3 sich "sehen". Der dritte ist auch immer Monitor und Manager.... damit man da im Ceph halt 3 "Votes" hat....
 
Interessante Strategie... Ceph ist ja eher so Scale-out also mehr Knoten und viele OSDs auf die Knoten verteilt. Zu viele OSDs per Knoten ist eher nicht die Norm. Cluster leer machen, heißt bei euch alle VMs von Cluster auf Cross-migrate auf n andere Cluster usw. ?
 
VoIP-Ninja said:
Cluster leer machen, heißt bei euch alle VMs von Cluster auf Cross-migrate auf n andere Cluster usw. ?
Click to expand...
Ja so in etwa läuft das ab. Hat natürlich entsprechend Vorlauf....
 
You must log in or register to reply here.
Top Bottom