dr.jay
Goto Top

Exchange 2010 DAG - Failover Probleme trotz CAS Array und NLB

Ein herzliches Hallo miteinander,

ich habe ein Kundenprojekt übernommen, bei dem ein Exchange Server welcher zu einer DAG gehört aus dem
Verbund genommen und einer anderen Aufgabe zugeführt werden soll. Sobald dieser Server auch nur heruntergefahren wird,
kann keiner der ca. 30 Clients vor Ort mehr auf den Exchange Cluster zugreifen. Die Konfiguration vor Ort ist zwar recht
sonderbar, sollte jedoch in diesem Falle korrekt funktionieren.

Folgendermaßen ist der Exchange Cluster aufgebaut:

Es existieren zwei Exchange Server in einer DAG. Auf beiden ist das Failovermanagement aktiviert.
Beide Server haben einen VMware Server 2.0 am laufen auf welchem jeweils ein CAS Server mit NLB läuft.
Vermutlich wurde die Installation so gewählt, da der vorherige Administrator bei Setup nicht wusste, dass DAG + NLB
auf einem Host nicht möglich sind...
Beim 2. Exchange Server wurde aufgrund von Verbindungsproblemen der CAS Server in der VM nicht mehr gestartet.

Heißt: 2x Exchange, auf dem einen ist der CAS Server. Schalte ich den Exchange ohne den CAS Server ab, hat
kein Client mehr Zugriff auf den Exchange. Sieht also so aus, als ob der CAS Server, den 2. Exchange, welcher
nur eine Passive Kopie der Datenbank hat, ansteuert. Wie kann das aber gehen, wenn die Kopie nicht "aktiv"
geschaltet wurde?

Irgendetwas übersehe ich hier, aber was? Hat jemand eine Idee?

lg. der René

Content-Key: 215246

Url: https://administrator.de/contentid/215246

Printed on: April 16, 2024 at 19:04 o'clock

Member: filippg
filippg Aug 26, 2013 at 17:46:37 (UTC)
Goto Top
Hallo,

Vermutlich wurde die Installation so gewählt, da der vorherige Administrator bei Setup nicht wusste, dass DAG + NLB
auf einem Host nicht möglich sind...
Afaik kann man das nicht "nicht wissen": Die Installer der Cluster Services und vom NLB-Feature prüfen wechselseitig, ob der jeweils andere schon installiert ist und verweigern die Installation. Sprich: Es kann einem (nach meinem Wissen) nicht passieren, dass man versehentlich beides installiert. Man muss dazu schon echt hart tricksen.
Daher auch mein Rat: Wenn an den Servern irgendjemand schon gebastelt hat, der (so verstehe ich den Post) auch nicht mehr erreichbar ist, würde ich dir raten, parallel einen neuen Exchange aufzusetzen, und alles auf diesen zu übertragen.

Ansonsten solltest du halt mal schauen, ob die Dinge wirklich so sind, wie sie scheinen. Laufen sie wirklich im NLB? Wie heißt das CAS-Array? Welche IP ist bei dem DNS-Name hinterlegt? Ist der Name auf den DBs gesetzt? Welchen Namen sprechen die Clients an?

Natürlich kann auch ein Blick in die Eventlogs nichts schaden, davon schreibst du gar nichts...

Daneben finden sich auch zahlreiche Anleitungen, wie man einen Knoten korrekt aus einer DAG entfernt. Die könntest du dir mal anschauen. Du musst allerdings damit rechnen, dass du irgendeinen normalerweise völlig korrekten Schritt machst, und auf einmal gar nichts mehr geht -auch kein Zurück. Vielleicht solltest du versuchen, als allererstes das NLB aufzulösen.

Grüße

Filipp
Member: Dr.Jay
Dr.Jay Aug 26, 2013 at 18:07:23 (UTC)
Goto Top
Hallo Filipp,

vielen Dank für dein Feedback. Bezüglich des NLG und der DAG stützt sich meine Vermutung quasi auf deine Antwort. Während der Installation
wurde wohl festgestellt, dass DAG + NLB auf einem System nicht funktionieren. Anders kann ich mir nicht erklären, warum man auf dieses System
noch zusätzlich einen VMware Server installiert, welcher die bereits dürftige Performance des Systems noch weiter verschlechtert. Aber nun gut,
dass sind ja nur Mutmaßungen.

Die Outlook Clients lösen das quasi das CAS Array auf. So wie es eigentlich sein sollte. Das Array Heißt einfach nur EXCAS. Hier ist die IP des NLB
hinterlegt (192.168.5.115) Der NLB verweißt auf nur einen CAS Server (der 2. wurde wie gesagt aufgrund von Fehlern abgestellt). In den Eventlogs
sieht alles prächtig aus. Keine Fehlermeldungen.

Bevor ich den Knoten aus der DAG entferne, wollte ich auf dieser Plattform nochmal sicherstellen, ob dies die einzig vernünftige Möglichkeit
ist. Ich werde wohl so vorgehen, dass ich die gesamte Umgebung via vCenter Converter abziehe, virtualisiere und dann auf den alten Systemen
eine Neuinstallation durchführen werden. Sicher ist sicher face-wink

lg. der René