[Eisfair] Benutzer migrieren

[Thomas Quast]

Am 12.10.23 um 22:48 schrieb Kay Martinen :
> Am 12.10.23 um 20:26 schrieb Thomas Quast:

>> Da B nun M wurde, koennen alle User wieder wie gewohnt weiter arbeiten und
>> Du kannst Dich an die Reparatur von dem defekten M machen.

> Und wie lang wäre da die übliche Downtime bis B zu M wurde und alles läuft?

Haengt davon ab, wie lang der Pruefinterval ist (Sekunden oder Minuten), und
die Dauer zweier Startsequenzen (eine verkuerzt, da nur Backup, die zweite
laenger, da ein regulaerer Serverstart).

Das ganze sollte (wie kann es auch anders sein und wer kennt es nicht?), wie 
immer so guenstig wie moeglich sein.

Eine elgantere und professionellere Loesung war fuer einen anderen Kunden mit
zwei Servern (je mit zwei NICs), zwei Switch und einem Router, gesteuert ueber
einen Heartbeat. Der Bedarf hier waren aber 7 x IP (1 x Router, 2 x Switch und
4 x Server). Allerdings lag der Kostenaufwand nur fuer die Hardware schon bei
knapp 130.000,- Euro. Und ich denke, das diese Loesung hier nicht gefragt war.
Ausfallzeit hier: < 2 Sekunden. Zusaetzlich gabe es noch eine redundante
Anbindung zum Internet via Glas, zugeführt von verschiednen Seiten zum Haus.
Auch musste die Anbindung durch den ISP redundant erfolgen und durfte nicht
ueber den selben Verteiler laufen. Extrem aufwaendig das alles damals. Selbst
die Erdarbeiten fuer die Glasfaser mussten wir selber tragen und extra nochmal
mit knapp 40.000,- Euro kalkulieren.

Alles in Allem ein spannendes und lehrreiches Projekt. Hat Spass gemacht.
Der Test war dann:
- ein Glas auftrennen -> User haben nichts bemerkt.
- einfach dem Master-Server den Strom abziehen -> User bemerkten zwar eine
  kurze Unterbrechung, konnten aber sofort weiterarbeiten.

Ach ja, bevor die Frage kommt: Die Festplatten wie auch die Netzteile in den
Server waren redundant.

>> Fuer den Wechsel vom Backupserver (M vormals B) zurueck zu B, hatte ich
>> auch ein passendes Script geschrieben, welches den Wechsel automatisierte.

> Da sehe ich als erstes Problem das M ja immer noch seine IP hat die
> jetzt B beansprucht. Wenn man nicht auch noch die MAC ändert dann sehe
> ich da verwirrung in beteiligten Switches voraus die ihre SAT wohl neu
> aufbauen müssen weil Temporär eine IP zu zwei MACs gehört. Was beim Hin-
> und zurück-schalten passieren würde.

Da (ehemals) M jetzt ausser Betrieb ist, ist dies vorerst ohne Belang.
M kann repariert und dann zu B werden.

In obiger Zusammenfassung habe ich so einiges weggelassen, so auch die
Anpassung der MAC-Adresse. Es wurde doch nur ein Denkanstoss erbeten, keine
fertige Loesung.

> Wenn M mit der gleichen IP startet die B hat dann können die beiden sich
> gegenseitig auch nicht erreichen und es in den höheren Schichten dann
> wohl durcheinander gibt. Eben duplicate IP.

Keiner startet mit der gleichen IP des Anderen, solange dieser noch werkelt.

> Lief dein o.g. script evtl. schon früh, aus der initrd? Und macht
> irgendwas mit arping o.ä.?

Nein. Wie geschrieben startete B lediglich in einer Minimalconfig nur fuer
den Backupbetrieb. Erst im Ernstfall, nach Ausfall von M wurde B
rekonfiguriert und nach dem Neustart zu M.

Man sollte diese Loesung aber dennoch mit Vorsicht betrachten, denn es wurde
nicht beruecksichtigt, was passiert, sollte sich (vormals) M erholen und den
Betrieb wieder aufnehmen wollen (Warum auch immer). Das war aber auch nicht
die Forderung und sollte bei der Realisierung auch nicht beruecksichtigt
werden.

Ansonsten tat diese Loesung ihren Dienst. Die Ausfallzeit lag zwischen 80 und
150 Sekunden. Fuer den Kunden damals absolut akzeptabel.
Zwei ausrangierte Arbeitsplatz-PC zum Server hochgeruestet und kostenguenstig
eine Redundanz 'gebastelt' (ja, mehr war es nicht).
Der Kunde war sehr zufrieden und darum ging es.

Bei all dem sollte man auch nicht vergessen, das hochredundante
Virtualisierunsgloesungen zu dieser Zeit nur gegen sehr viel Geld zur Verfuegung
standen und mit den heutigen Moeglichkeiten nicht zu vergleichen sind.

Gruss,
Thomas

-- 
Packageserver: https://www.oritopha.de/index.txt