Update eines R5 Clusters

[dlang]

Hallo zusammen,

wir planen ein Update eines R5 (5.013a) Clusters. Die Geschäftsleitung möchte so gering wie möglich Ausfallzeiten. Aus dem Grund denken wir an einen schrittweisen Update nach (zu 6.5.4.3). Hat jemand Erfahrungen mit Cluster im Mischbetrieb (5.013a und 6.5.4.3)? Ist das überhaupt machbar?
Es sind die Maildatenbanken und verschiedene weitere Datenbanken mit Applikationen im Clusterverbund. Ebenfalls sind die Datenbanken sehr groß (bis zu 8GB).

Vielen Dank für die Hinweise und Erfahrungen schon im Voraus.
Dieter

[Maverick]

Hallo Dieter,

ist es nicht so, dass Ihr ein Clustermitglied abschalten und updaten könnt, während das andere teilweise im failover-Betrieb arbeitet, um nach erfolgreicher Arbeit den anderen Server anfassen könnt?

Grüße
Paul

[dlang]

Hallo Paul,

ja so ist es gedacht. Nur arbeiten dann eine Zeit lang (1-2 Tage) die Cluster-Knoten im Mischbetrieb. Der eine unter 5.0.13a und der andere unter 6.5.4.3. Kann das zu Störungen oder Datenverlust führen?

Gruß
Dieter

[Maverick]

Also aus dem Dokument (Anhang) - welches zugegebenermassen schon etwas älter ist - ist zu entnehmen, dass schon ein 4.6-Server mit nem R5er im Cluster gearbeitet hat.

Ich wäre an Deiner Stelle optimistisch.

Wenn du mal etwas für mich tun würdest : Schau Dir mal bitte den ServerAvailabilityIndex beider Server vor und nach der Migration an und poste mal Deine Werte. Ich weiss, dass mit R6 ein neuer Algorithmus verwendet wurde. Meine Indizes sanken von ~ 100-90 auf ~50-30. Sowas lässt anfänglich auch den härtesten Admin zittern.

Paul

[dlang]

Hallo Paul,

ok, kann aber eine Weile Dauern, da Zeitpunkt noch abgestimmt wird.

Gruß
Dieter

[dlang]

Hallo zusammen,

wir haben nun soweit unser Upgrade erfolgreich abgeschlossen. Vorgabe war vom Kunden so wenig wie möglich Ausfallzeit mit größt möglicher Sicherheit, bei einem sehr großen Datenbestand. Wir haben dabei einen etwas untypischen Weg gewählt. Wir haben, um Zeit zu sparen (es wurde sehr viel Ausfallzeit gespart) die Migration über Replikation durchgeführt.
Dabei wurde im Testfeld auf neuen Systemen die Installation der Produktionsserver "Cluster-Noteweise" übernommen und ein "normales" Upgrade (nach Redbook) durchgeführt. Dabei sind wir auf einen bereits bekannten Fehler beim Compakt gestoßen. Das war auch der Grund für unsere Migrationsstrategie. Anschließend wurde alles gründlich getestet und Änderungen dokumentiert. Anschließend wurden nochmals die Installationen im Testfeld übernommen und es wurde wieder "normal" migriert. Der "alte Cluster" ist immer noch in Produktion und bleibt auch bis nach der Pilotphase. Dann wurden in der Pilotphase in einem eigenem Netz alle Applikationen und Daten geprüft.
Nachdem erst alle Tests positiv abgeschlossen waren sind wir zur eigentlichen Ablösung der alten Server übergegangen. Da wir nun zwei Clusterpaare haben mit den jeweils gleichen Identitäten sind wir in der Lage auch diese gegenseitig zu tauschen. Genau das war auch unser nächster Schritt. Um die Daten vom Produktiv-Cluster zum "neuem" zu aktualisieren, haben wir jeweils nur einen Clusterknoten im Produktiv-Cluster getauscht. Somit wurden durch Replikation die Daten vom aktuellen Clusterknoten (V5) zum nicht aktuellen Clusterknoten (V6) übertragen. Wir haben aus Sicherheitsgründen das Replizieren im Offline-Betrieb durchgeführt um Irritationen zu vermeiden. In diesem Zwischenstadium wurden nochmals die Daten und Applikationen geprüft. Anschließend wurde im nächsten Schritt der Zweite Clusterknoten (V5) noch gegen den neuen Knoten (V6) getauscht. Damit ist nun der Produktiv-Cluster durch Replikation aktualisiert worden.

Mit der Vorgabe einen sehr hohen Sicherheitsgrad einzuhalten und eine sehr komplexe Umgebung zu migrieren wurde diese Vorgehensweise mit dem Kunden gemeinsam erarbeitet und erfolgreich durchgeführt.

@Paul: Der Index ist bei 49. Durch die Migration vielleicht auch etwas verfälscht.

Viele Grüße
Dieter

[Maverick]

Dank Dir sehr.

49 ist ein Wert, den ich hier auch erreiche. Damit kann ich und vor allem meine Anwenderlein gut leben.

Ma et jooht.

Paul