Hallo zusammen,
Anfang nächsten Jahres müssen wir bei uns Aufgrund von Bauarbeiten unseren Maschinenraum komplett abschalten.
Dazu muss auch das Exchange-Cluster heruntergefahren werden - Vollständig!
Was wir uns bisher so gedacht haben, wie es funktionieren könnte:
Einlieferung neuer Mails abschalten und den Zugriff auf das Cluster für alle Clients Netzwerkseitig sperren.
Danach dann alle Datenbanken per Hand dismounten und anschließend alle Nodes nacheinander herunterfahren.
Nach Abschluss der Bauarbeiten dann in umgekehrter Reihenfolge das Cluster wieder anfahren.
Hat damit bereits jemand Erfahrung und/oder Tips?
Schon mal vielen Dank!
Dazu muss auch das Exchange-Cluster heruntergefahren werden - Vollständig!
Wie fährst du denn einen Cluster "unvollständig" runter?
Warum so ein umständliches Verfahren? Was spricht dagegen die Cluster-Knoten einfach runterzufahren mittels stop-computer? Wieso willst du die Datenbanken dismounten? Über wie viele DAG Knoten reden wir denn?
Wenn wir einen Teil der Nodes an einem anderen Standort hätten, könnten wir dort ja das Cluster "am leben erhalten".
Da das leider (noch) nicht der Fall ist, müssen wir halt das vollständige Cluster herunterfahren.
Wir haben 12 Nodes in der DAG (plus witness). Vier davon können ohne Beeinträchtigung gleichzeitig ausfallen.
Wenn wir die Nodes einfach so Herunterfahren, würden die Datenbanken ja jeweils auf einem anderen Host aktiv.
Nur wie verhält es sich, wenn wir dann den letzte Node mit einer Kopie heruntergefahren?
Die Datenbank würde dann ja in einen failed state gehen?!
Daher war der Gedanke, dass wir die Datenbanken zunächst dismounten und mehr Sicherheit haben, die Datenbanken konsistent zu halten.
Nur wie verhält es sich, wenn wir dann den letzte Node mit einer Kopie heruntergefahren?
Ihr habt einen 12 Node Cluster und den noch nie runtergefahren und auch keine Doku wie man sowas runterfährt? Technisch wird dann die Datenbank eben runtergefahren im Zuge des Shutdowns des Knotens. Was soll denn sonst damit passieren? Da ich davon ausgehe, dass nicht jeder der 12 Knoten jede Datenbank in Kopie hat, kannst du also alle DBs auf einen der jeweiligen Hosts aktivieren und die dann Passiv-Kopie-haltenden Nodes runterfahren (würde natürlich schauen, dass keine logs ausstehen).
Alternativ sollte eigentlich Stop-DatabaseAvailabilityGroup und Start-DatabaseAvailabilityGroup einen ähnlichen Zweck erfüllen.
Moin,
ja, für vernünftige Zukunftsplanung, "was wäre wenn"-Fragen und eine gute Doku ist in öffentlichen Einrichtungen leider meistens kein Geld/Personal da...
Bisher war es tatsächlich noch nie nötig das Cluster im Ganzen herunterzufahren. Wie gesagt haben wir die Datenbankkopien so verteilt, dass wir vier von den zwölf Nodes ausschalten können. Das reicht für Wartung/Updates, plus Sicherheitsnetz während der Wartungsarbeiten, aus.
Wie gesagt haben wir die Datenbankkopien so verteilt, dass wir vier von den zwölf Nodes ausschalten können.
Und was würde passieren, wenn man die 4 dann einfach auch runterfährt? Ich persönlich gehe davon aus, genau gar nichts. Beim Hochfahren dann die 4 letzten Server zuerst starten.
So wie du sagst ist für die Bauarbeitenzeit kein Mailserver erreichbar und es funktioniert kein Mailempfang/senden. Ist halt so. Wenn die Bauarbeiten beendet sind fährst du die Server wieder hoch. Ansonsten, setze dir einen Server aushalb der Bauarbeiten auf und nutze den als Mailempfang/senden.
Mfg
Ich "vermute", dass es nicht darum geht, dass kein Mailverkehr möglich ist, sondern wie man diese 12 Cluster-Nodes sauber runter- und wieder hochfährt. ;)