Cluster total ausfallsicher gegen Brand etc.

[GMBauer]

Grüeziwoll beinand,

das ist jetzt eine halbe Hardware-Frage, schon klar. Aber zur Hälfte auch Software, also bitte ich um Nachsicht.


Gegeben sei ein Rathaus in einer Gemeinde mit 10.000 Einwohnern. Nun hat die Gemeinde am Sonntag Kommunalwahl (Bayern) und das wird problematisch, weil "der Serverraum ausgebrannt ist" und die elektronische Auswertung der papierenen Wahlzettel nicht mehr möglich sei.

Originaltext:
Liebe Mitbürgerinnen und Mitbürger,

heute Nacht hat es im Serverraum unseres Rathauses gebrannt. Dadurch sind die komplette Telefonanlage sowie die IT-Infrastruktur unseres Rathauses sowie aller gemeindlichen Einrichtungen derzeit außer Betrieb. Das Rathaus ist geschlossen.

Es können derzeit keine neuen Briefwahlunterlagen beantragt und abgeholt werden. Daher nehmen Sie bitte die Urnenwahl am Sonntag wahr.

Sollten Ihnen Ihre Briefwahlunterlagen bereits vorliegen, so können Sie Ihren Briefwahlumschlag weiterhin in den Briefkasten des Rathauses bis spätestens Sonntag, 8. März, 18 Uhr einwerfen.

Wir werden Sie über die sozialen Medien sowie auf unserer Homepage über den aktuellen Stand auf dem Laufenden halten.

Nun bin ich der Meinung, dass sowas ja eigentlich gar nicht sein kann. Naja, kann schon, darf aber nicht und müsste eigentlich organisatorisch / technisch verhindert werden können.

Angenommen man nutzt einen Proxmox-Cluster mit drei Rechnern, von denen zwei in Serverraum A und einer in Serverraum B steht, dann läuft das System doch auch weiter, wenn die Technik in Raum A komplett untergeht, oder? Das ist ja der Sinn davon, oder? IT für eine Gemeinde mit 10.000 Einwohnern ist ja auch kein Hexenwerk.

Wie würdet Ihr - abgesehen von baulichen Mitteln wie CO2-Löschanlage, Brandfrüherkennung etc. - ein Netz auf Proxmox-Basis vollkommen redundant und damit ausfallsicher machen?

Beste Grüße

 

[beisser]

Das würde nur funktionieren, wenn du in Serverraum A und B jeweils die gleiche Anzahl Nodes hast und dann an einer beliebigen Stelle (Serverraum oder Cloud) ein qdevice betreibst, dass als Tiebreaker funktioniert.

Sprich, der eine Serverraum brennt komplett ab und der andere Serverraum + qdevice an dritter Stelle stellen sicher, dass das Zeug weiterläuft.
Eine ungerade Anzahl Nodes auf zwei Räume verteil würde nicht funzen, da sich der überlebende Node selbst killt, wenn die Seite mit den zwei Nodes abbrennt.
Grund dafür ist, dass immer ein Quorum benötigt wird und dafür sind mehr als 50% der Stimmen notwendig.
Wenn du ein Node überlebt, sind das aber nur 33% der Stimmen und somit bricht alles zusammen.

 

[GMBauer]

Das mit dem "wenn 2 von 3 weg sind" war mir bewusst, aber die Implikation für dieses Problem nicht.

Würde ein Cluster mit 2 Nodes in Raum A und 2 Nodes in Raum B den völligen Untergang eines Raums überleben?

Ich glaube, dass das wirklich ein nicht uninteressantes Diskussionsthema ist, wie man sowas aufsetzt... Und das Problem ist ja nicht nur "Brand", sondern auch Wasser (passiert sicher öfters als Brand, die Technik ist ja oft im Keller untergebracht) und m.E. Vandalismus, wenn beispielsweise ein gekündigter Mitarbeiter mit einer Axt den Serverraum neu gestaltet.

 

[aaron]

Cluster über 2 Räume / Locations ist hier erläutert, mit Ceph als Storage: Würde grundsätzlich auch mit anderen Storages gehen. Wenn man kein HCI Ceph nimmt, kann die Stimme an dritter stelle auch gerne ein QDevice statt voller Node sein. https://pve.proxmox.com/wiki/Stretch_Cluster

 

[beisser]

Das mit dem "wenn 2 von 3 weg sind" war mir bewusst, aber die Implikation für dieses Problem nicht.

Würde ein Cluster mit 2 Nodes in Raum A und 2 Nodes in Raum B den völligen Untergang eines Raums überleben?

Ich glaube, dass das wirklich ein nicht uninteressantes Diskussionsthema ist, wie man sowas aufsetzt... Und das Problem ist ja nicht nur "Brand", sondern auch Wasser (passiert sicher öfters als Brand, die Technik ist ja oft im Keller untergebracht) und m.E. Vandalismus, wenn beispielsweise ein gekündigter Mitarbeiter mit einer Axt den Serverraum neu gestaltet.

also grundsätzlich brauchst du bei diesem szenario immer eine ungerade anzahl an stimmen, also 3, 5, 7 usw und eine davon (ein qdevice ist hier resourcensparend und kann mehr oder weniger überall, also auch in der cloud, laufen) muss zwingend an einem dritten ort laufen, der auch alle anderen clustermember erreichen kann.

sinn habe ich weiter oben schon erklärt. wenn du deinen cluster in brandabschnitte aufspaltest, braucht du in beiden abschnitten zwingend die gleiche anzahl an nodes.
brennt jetzt eine location ab oder säuft ab oder ein meteor schlägt ein, so hat die zweite location immer 50% der quorum-votes +1(das qdevice).
das heisst, der noch laufende teil des clusters macht weiter wie gehabt.

hintergrund ist, das bei einer geraden anzahl an votes ein split brain szenario eintreten kann, bei dem beide hälften des clusters denken, sie wären der überlebende und beide gleichzeitig die selben workloads ausführen.
sowas darf nicht sein, daher wird jeder clusterteil, der nicht mindestens 50% +1 Stimme hat sich abschotten (fencen) und sich anschliessend rebooten (wobei ich das mit dem rebooten selbst noch nie getestet habe).

daher würde ich das mit identischer anzahl nodes in allen locations machen + 1 qdevice, das z.b. in einer kleinen cloudinstanz läuft und per vpn angebunden ist.
qdevices sind nicht so anspruchsvoll, was latenz angeht, wie echte nodes.
ich meine irgendwo gelesen zu haben, das bis 100ms akzeptabel ist.
daher muss das ding nicht zwingend in der näheren umgebung des clusters laufen.

 

[Bu66as]

Was @beisser und @aaron zum Quorum sagen passt alles. Aber das ist halt nur die halbe Miete, der Cluster bleibt zwar oben, aber deine VMs brauchen ja auch ihre Daten. Wenn die Platten in Raum A verkohlt sind, nützt dir das laufende Cluster in Raum B nix, wenn die VM-Disks weg sind.
Heißt: du brauchst entweder Ceph als Stretch Cluster (repliziert die Daten synchron über beide Standorte, siehe den Link von @aaron) oder mindestens ne ZFS-Replikation zwischen den Nodes. Ceph ist da die sauberere Lösung, weil die VMs bei nem Failover direkt weiterlaufen können ohne manuelles Gefummel.
Und unabhängig davon: Proxmox Backup Server an Standort B (oder C) ist Pflicht. Selbst wenn der Stretch Cluster läuft, willst du Backups an nem separaten Ort haben. Für ne Gemeinde mit 10k Einwohnern reden wir da über überschaubare Infrastruktur, das ist kein Hexenwerk und auch kein Riesenbudget.
Falls ihr da professionelle Unterstützung beim Aufsetzen braucht, wir (B1 Systems) machen genau sowas für Kommunen und öffentliche Einrichtungen: https://www.b1-systems.de

 

[GMBauer]

Für ne Gemeinde mit 10k Einwohnern reden wir da über überschaubare Infrastruktur, das ist kein Hexenwerk und auch kein Riesenbudget.
Falls ihr da professionelle Unterstützung beim Aufsetzen braucht, wir (B1 Systems) machen genau sowas für Kommunen und öffentliche Einrichtungen: https://www.b1-systems.de

Danke, aber ich bin nur mittelbar Betroffener, ich bin Bewohner dieser Gemeinde....

Jetzt sagen wir mal, das ist ja der schlimmstmögliche Fall. Brand, völliges Untertauchen der EDV oder Vandalismus hat man ja nicht immer. Wasser sollte man vermeiden können, Vandalismus auch. Die Brandgefahr MUSS man verringern können durch Organisation und vielleicht eine 1-Zimmer-Löschanlage.

In so einem Fall dürfte eine Downtime von x Stunden auch okay sein. Das führt natürlich zu einem ganz anderen Sicherheitslevel. Backups im Haus verstreuen, Zweitgeräte vorhalten, etc.etc.

Aber: Im Serverraum laufen ja im Endeffekt alle Netzwerkkabel im Haus zusammen. Wie schützt man die gegen Totalschaden ab dem Punkt, wo sie aus dem Installationsrohr kommen? Bzw. wie umgeht man diesen Totalschaden? Backbones pro Geschoss und dann eine Glasfaser oder ein Cat 7 schnell neu einziehen?

 

[beisser]

du musst dir das so vorstellen:

alle komponenten werden redundant ausgelegt (also doppelt oder gar mehrfach).
ab dem etagenverteiler (für die arbeitsplätze), der noch als SPOF durchgeht ist alles doppelt ausgelegt und in unterschiedlichen unabhängigen abschnitten aufgebaut. das betrifft unterverteiler, core-switche, (proxmox-)server und internet-infrastruktur.

ist alles korrekt ausgelegt, kannst du entweder eine etage mit clients offline nehmen (der switch an dem die pcs von den beamten dranhängen), oder einen der redundanten abschnitte im rest.
es wird nichts passieren, ausser, das die workloads die im zerstörten abschnitt liefen, neu hochgefahren werden (was HA automatisch macht).

für die ausgefallenen clients muss man halt die kabel auf einen funktionierenden switch umstecken, und das wars.

der abgebrannte serverraum oder die abgebrannten komponenten im netzwerk können dann in aller ruhe ausgetauscht werden, während der rest unbehelligt weiterläuft.

 

[beisser]

es hängt natürlich immer davon ab, welche grössenordnung von katastrophe man kompensieren möchte.
das geht über mehrere serverräume in einem gebäude in mehreren brandabschnitten über mehrere gebäude auf dem selben gelände, mehrere gebäude in unterschiedlichen stadtteilen, unterschiedlichen städten bis hin zu unterschiedlichen ländern.

redundanz hat viele level und je höher das level um so mehr münzen muss man einwerfen um das umzusetzen.