Exchange 2010 in Hyperv, wohin die Datenbank?

[RobertWi 81]

Moin,

Stell dir vor, der Host fällt aus, der einen der DAG-Knoten betreibt. Was passiert? Zweierlei: Der Host-Cluster übernimmt die VM und startet sie auf einem anderen Host neu. Gleichzeitig merkt der DAG-Cluster, dass er die Datenbank auf einer der DAG-VMs übernehmen muss. Es überlagern sich also zwei Failover-Vorgänge. Da kann eine ganze Menge dran hängen.

 

Es passiert genau das gleiche, das passiert, wenn ich einen DAG-Knoten, der nicht im HA ist, ausschalte und fünf Minuten später wieder einschaltet. Der AM stellt fest, dass der alte Knoten wieder läuft, wird entweder zurück schwenken oder sich eventuell fehlende Log-Dateien nachholen.

 

Nichts anderes passiert in den VMs, nur automatisch.

 

Ich gehe davon aus, dass das Exchange-Team dieses Szenario nicht konsequent durchgetestet hat und es daher nicht supportet.

 

Das denke ich auch.

 

Was mich erstaunt, ist weniger der Support-Ausschluss für Exchange als vielmehr, dass es z.B. für SQL Server keinen solchen Ausschluss gibt.

 

Was durchaus bestätigen würde, dass die Exchange-Entwicklung das nicht ausreichend getestet haben - oder das JET-DB-Konzept hat wirklich technische Einschränkungen.

 

Richtig, und was passiert bei einem physischen DAG Knoten wenn du Strom ausmachst? ;) Genau ein anderer Knoten übernimmt die aktiven DBs. Wenn jetzt aber der Knoten in VM per Schwenk sofort umgezogen wird, kann sich das mit dem DAG DB Failover überschneiden. Und genau das verhindert man, wenn man den Schwenk eines DAG Knoten einfach verhindert. :)

 

Allerdings schenkt VM nicht "sofort" (definiere "sofort"). Die Ersatz-Maschine wird gebootet, was je nach Performance einige Minuten dauern kann. Die Entwickler der DAG haben durchaus vorgesehen, dass ein ausgefallener DAG-Knoten wieder online geht und ich habe keine Einschränkung gefunden, dass er das erst nach x Minuten darf. ;)

 

 

Wieso? Und welche Einschränkung? ;)

 

Wenn ich in Verbindung mit VM-HA keine DAGs einsetzten darf, dann fällt bei einem geplanten Reboot (z.B. am Patchday) die Datenbank aus.

[NorbertFe 1.799]

Wenn ich in Verbindung mit VM-HA keine DAGs einsetzten darf

 

Darfst du doch. Oder liest du irgendwo was anderes als ich?

 

dann fällt bei einem geplanten Reboot (z.B. am Patchday) die Datenbank aus.

 

Warum? Bei einem geplanten Patchday kannst du bei vorhandener DB-Redundanz die DBs schwenken, oder seh ich jetzt was falsch? Wenn keine DB-Redundanz da ist, hast du die Downtime so oder so. Egal ob VM HA oder nicht. ;)

 

Bye

Norbert

[Dukel 436]

HA der VM und HA der DAG bringen für eine Mailbox DB das selbe ergebnis. Wieso sollte man beides (gleichzeitig) wollen?

[NorbertFe 1.799]

Weil viele Kunden nunmal VM HA sowieso schon haben und zusätzlich überlegen, ob eine Service REdundanz nicht doch besser ist als eine Maschinenredundanz. ;) So wie Robert es ja schon schrub. Also wo siehst du da jetzt das selbe Ergebnis, oder hab ich dich falsch verstanden?

 

Bye

Norbert

[RobertWi 81]

Darfst du doch. Oder liest du irgendwo was anderes als ich?

 

Du hast es doch selbst aus dem Technet zitiert:

DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn't employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

 

Anders gesagt:

entweder: DAG nur, wenn kein Root-Cluster

oder: wenn Root-Cluster, dann kein automatischer Failover für Mailbox-Server

 

Einen Cluster ohne automatischer Failover dürften die meisten als witzlos empfinden.

 

 

Warum? Bei einem geplanten Patchday kannst du bei vorhandener DB-Redundanz die DBs schwenken, oder seh ich jetzt was falsch? Wenn keine DB-Redundanz da ist, hast du die Downtime so oder so. Egal ob VM HA oder nicht. ;)

 

Genau darum geht es. Wenn ich einen HA-Cluster betreibe, darf ich keine DAGs einsetzen. Und ohne DAGs habe ich eine Downtime.

 

Der Kunde kann nun entweder seinen teuren HA-Cluster nicht mehr nutzen, oder muss auf DAGs verzichten. Und dabei ergänzen sich beide aus meiner Sicht eigentlich eher, als dass sie sich ausschließen.

 

HA der VM und HA der DAG bringen für eine Mailbox DB das selbe ergebnis. Wieso sollte man beides (gleichzeitig) wollen?

 

Nein, sie sind nicht das gleiche. Bei VM-HA habe ich zwar mehrere Geräte, aber nur einen Datenbestand (shared Storage oder Ressorucen Pool). Fällt ein HA-Knoten aus, nimmt ein anderer den Betrieb auf und nutzt die bisherigen Daten weiter.

 

Bei DAG sind aber auch die Daten redundant, d.h. jeder Server hat seine eigene Kopie der Daten und ist damit nicht mehr auf einen Shared Storage angewiesen.

[Dukel 436]

Ich habe extra nicht das gleiche geschrieben sondern es gibt das gleiche Ergebnis. Die Datenbank läuft auf einem anderen Knoten weiter. Dem Anwender (und dem Admin) wird es egal sein, ob das per ESX HA oder Exchange DAG funktioniert. Nur beides zusammen benötigt man nicht.

 

Man kann vMotion für geplante Downtimes des Hostes und DAG für geplante downtimes der VM selber nutzen, aber bei einem Ausfall zählt obiges.

 

Und wegen Cluster ohne automatisches Failover: Gibt es doch durch die DAG. ESX HA kann man für andere VM's nutzen, welche nicht von haus aus retundand sind.

[NorbertFe 1.799]

Ich habe extra nicht das gleiche geschrieben sondern es gibt das gleiche Ergebnis. Die Datenbank läuft auf einem anderen Knoten weiter. Dem Anwender (und dem Admin) wird es egal sein, ob das per ESX HA oder Exchange DAG funktioniert. Nur beides zusammen benötigt man nicht.

 

Das Ergebnis ist eben nicht das gleiche. Abgesehen davon schriebst du sogar vom selben Ergebnis. Wenn du eine DAG mit DB Redundanzhast, hast du die Möglichkeit einen geplanten Patchday einzulegen ohne eine Downtime im Service Exchange zu verursachen. Versuch das mal bitte mit VM HA.

 

Man kann vMotion für geplante Downtimes des Hostes und DAG für geplante downtimes der VM selber nutzen, aber bei einem Ausfall zählt obiges.

 

Nein tut es nicht zwingenderweise, bzw. wieso sollte ein Failover der VM schneller funktionieren als ein DB Failover auf DAG Ebene? Wieso ist das für euch denn das selbe/gleiche? Beides ist an unterschiedlichen Stellen, wie schon mehrfach im Thread beschrieben, für die Verfügbarkeit zuständig. Deswegen ist ein Exchange VM-HA trotzdem nicht das "selbe" wie ein Exchange mit DAG und erst Recht nicht wie Exchange mit DAG in VM HA. Oder ich hab nen Knoten im Hirn.

 

Und wegen Cluster ohne automatisches Failover: Gibt es doch durch die DAG. ESX HA kann man für andere VM's nutzen, welche nicht von haus aus retundand sind.

 

Ja und?

 

Bye

Norbert

[NorbertFe 1.799]

Du hast es doch selbst aus dem Technet zitiert:

DAGs are supported in hardware virtualization environments provided that the virtualization environment doesn't employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

 

Einen Cluster ohne automatischer Failover dürften die meisten als witzlos empfinden.

 

Es geht nur um den automatischen Failover der DAG Nodes. Und da du sowieso mehr als einen DAG Node pro DAG hast (im Normalfall) braucht man die VM HA an der Stelle nicht zwingenderweise. Sie bietet natürlich trotzdem diverse andere Vorteile. Einen manuellen Failover kannst du dagegen sehr wohl vollziehen.

 

 

Genau darum geht es. Wenn ich einen HA-Cluster betreibe, darf ich keine DAGs einsetzen. Und ohne DAGs habe ich eine Downtime.

 

Die Aussage ist so pauschal aber nunmal falsch. Du kannst einen HA Cluster mit DAG benutzen solange die DAG Nodes nicht einen automatischen Failover auf VM HA Ebene vollziehen.

 

Der Kunde kann nun entweder seinen teuren HA-Cluster nicht mehr nutzen, oder muss auf DAGs verzichten. Und dabei ergänzen sich beide aus meiner Sicht eigentlich eher, als dass sie sich ausschließen.

 

Aaaaaaah. Ich gebs gleich auf. Wieso kann der Kunde seinen teurern HA Cluster nicht benutzen, bloß weil er ne DAG einsetzen will? Das steht doch explizit oben im Zitat drin.

 

Nein, sie sind nicht das gleiche. Bei VM-HA habe ich zwar mehrere Geräte, aber nur einen Datenbestand (shared Storage oder Ressorucen Pool). Fällt ein HA-Knoten aus, nimmt ein anderer den Betrieb auf und nutzt die bisherigen Daten weiter.

 

Bei DAG sind aber auch die Daten redundant, d.h. jeder Server hat seine eigene Kopie der Daten und ist damit nicht mehr auf einen Shared Storage angewiesen.

 

Korrekt.

 

Bye

Norbert

[NilsK 2.781]

Moin,

 

Wenn ich in Verbindung mit VM-HA keine DAGs einsetzten darf

 

genau diese EInschränkung gibt es nicht. Du darfst. Nur darf es kein automatisches Failover und keine automatische Live Migration für die VM geben. Manuelle Live Migration wäre erlaubt.

 

dann fällt bei einem geplanten Reboot (z.B. am Patchday) die Datenbank aus.

 

Nö, wieso? Selbst wenn ich keine manuelle Live Migration machen würde, könnte ich doch ein DB-Failover machen.

 

Gruß, Nils

[NorbertFe 1.799]

Danke, ich dachte schon ich wäre der Einzige der das grad nicht nachvollziehen kann. ;)

 

Bye

Norbert

[RobertWi 81]

Es geht nur um den automatischen Failover der DAG Nodes. Und da du sowieso mehr als einen DAG Node pro DAG hast (im Normalfall) braucht man die VM HA an der Stelle nicht zwingenderweise. Sie bietet natürlich trotzdem diverse andere Vorteile. Einen manuellen Failover kannst du dagegen sehr wohl vollziehen.

 

Es gibt keinen manuellen Failover. Es liegt in der Natur der Sache, dass ein Failover ungeplant und damit automatisch erfolgt.

 

Ein manuelle Failover wäre ein Switchover, und dieser Fall ist ausdrücklich nicht gemeint.

 

 

Aaaaaaah. Ich gebs gleich auf. Wieso kann der Kunde seinen teurern HA Cluster nicht benutzen, bloß weil er ne DAG einsetzen will? Das steht doch xplizit oben im Zitat drin.

 

Weil ein HA-Cluster ohne automatischen Failover ungefähr genauso eine Verschwendung ist, wie mit einem 400 PS Auto durch eine Tempo 30-Zone zu fahren.

 

Natürlich kann er den HA für 1000 andere Sache einsetzen. Er *will* es aber für *Exchange* machen. Und natürlich für die Datenbank, denn für CAS und HT gibt es andere Methoden der Hochverfügbarkeit.

 

 

genau diese EInschränkung gibt es nicht. Du darfst. Nur darf es kein automatisches Failover und keine automatische Live Migration für die VM geben. Manuelle Live Migration wäre erlaubt.

 

Sorry, für die Spitzfindigkeit, aber entscheidend ist nicht, was ist implementieren kann. Entscheidend ist, was am Ende dabei rauskommt.

 

Was für einen Sinn hat dieser Cluster dann noch? Wegen Failover und LM betreibe ich den. Und nicht, weil ich zu viel Geld habe. ;)

 

 

Ok, mache wir mal eine einfache Aufgabe daraus:

- HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden)

- drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle)

 

Kunde will:

- wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung

- beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank

 

Wie macht er das?

[NorbertFe 1.799]

Was für einen Sinn hat dieser Cluster dann noch? Wegen Failover und LM betreibe ich den. Und nicht, weil ich zu viel Geld habe. ;)

 

Wenn der Cluster allein wegen Exchange 2010 betrieben wird, war das vielleicht einfach die falsche Entscheidung? ;) Dann bleibt halt entweder damit (also ohne automatische Failover und LM) zu leben oder eben sich einzugestehen, dass man falsch geplant hat oder die falschen Ansprüche gestellt hat.

 

Ok, mache wir mal eine einfache Aufgabe daraus:

- HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden)

- drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle)

 

Kunde will:

- wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung

- beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank

Wie macht er das?

 

Auf jedem Host je einen DAG Knoten und mindestens eine DB Kopie pro DB. Und jetzt sag nochmal, warum du einen automatischen Failover benötigst. Damit wäre zumindest nach meinem Wissen die Anforderung abgedeckt.

- Bei einem Hostausfall geschieht per DAG ein DB Failover. Die Wiederherstellung des Guests erfolgt mittels manueller Verschiebung auf einen anderen Host.

- Bei einem Guestausfall geschieht per DAG ein DB Failover. Die Wiederherstellung des Guests erfolgt dann so, wie er auch erfolgen würde wenn du direkt aufs Blech installiert hättest. Entweder durch Neuinstallation und Neueinbindung in die DAG, oder aber über ein Recovery vom Backup.

 

Falls ich es jetzt immer noch nicht gerafft habe, worauf du hinauswillst, geb ichs wirklich auf. :)

 

Bye

Norbert

[RobertWi 81]

(Warum zitiert die Software eigentlich immer nur eine Ebene, das ist Mist....)

 

Wenn der Cluster allein wegen Exchange 2010 betrieben wird,

 

Nein, eben nicht. Virtualisierung wird i.d.R. auch betrieben, weil man damit Hardware konsolidieren kann. Es ist also nicht nur Nebeneffekt, sondern die Regel, dass noch weitere virtuelle Maschinen mit anderen BS, Software, etc. laufen.

 

war das vielleicht einfach die falsche Entscheidung? ;) Dann bleibt halt entweder damit (also ohne automatische Failover und LM) zu leben oder eben sich einzugestehen, dass man falsch geplant hat oder die falschen Ansprüche gestellt hat.

 

Die Ansprüche sind klar und in der Aufgabenstellung definiert. Exchange erlaubt das Gewünschte zur Zeit noch nicht.

 

 

Auf jedem Host je einen DAG Knoten und mindestens eine DB Kopie pro DB. Und jetzt sag nochmal, warum du einen automatischen Failover benötigst. Damit wäre zumindest nach meinem Wissen die Anforderung abgedeckt.

- Bei einem Hostausfall geschieht per DAG ein DB Failover. Die Wiederherstellung des Guests erfolgt mittels manueller Verschiebung auf einen anderen Host.

- Bei einem Guestausfall geschieht per DAG ein DB Failover. Die Wiederherstellung des Guests erfolgt dann so, wie er auch erfolgen würde wenn du direkt aufs Blech installiert hättest. Entweder durch Neuinstallation und Neueinbindung in die DAG, oder aber über ein Recovery vom Backup.

 

Falls ich es jetzt immer noch nicht gerafft habe, worauf du hinauswillst, geb ichs wirklich auf. :)

 

Ok, ich habe oben eine wichtige Information unterlassen, die für mich selbstverständlich war - in dem VM-Cluster läuft natürlich noch mehr, als nur Exchange. Tut mir leid, für Deine eventuell doppelte Mühe.

 

Ich formuliere neu:

 

- HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden)

- drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle)

- außerdem laufen folgende virtuelle Maschinen:

-- 1x DC (hier gibt es noch Diskussionen und eventuell Änderungen wegen Exchange)

-- 1x Print Server

-- 1x Fileserver

-- 1x Linux Server (Systemüberwachung mit Nagios)

 

Angeplant sind:

- Datenbank-Server (BS und DB-System noch nicht definiert)

- Webserver auf Linux/Apache-Basis für Intranet

- Terminalservice (verm. in eigener Virtualisierung)

 

Kunde will:

- wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung (aller Rollen!)

- beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank

 

Kunde will von der jetzigen Lösung weg (Fremdprodukt) und stuft Mail als "kritisch" ein. Er ist von DAGs sehr angetan, weil er genau dieser Funktion bei seinem jetzigen System vermisst. Die vorhandene und ausreichend dimensionierte VM-Landschaft soll weiter benutzt werden.

 

Wie löschen wir das?

[NorbertFe 1.799]

(Warum zitiert die Software eigentlich immer nur eine Ebene, das ist Mist....)

 

;)

 

Nein, eben nicht. Virtualisierung wird i.d.R. auch betrieben, weil man damit Hardware konsolidieren kann. Es ist also nicht nur Nebeneffekt, sondern die Regel, dass noch weitere virtuelle Maschinen mit anderen BS, Software, etc. laufen.

 

Genau. Und was genau ist jetzt das Problem? Kann er doch tun, sogar mit automatischem Failover. Nur eben nicht für die DAG Member.

 

Die Ansprüche sind klar und in der Aufgabenstellung definiert. Exchange erlaubt das Gewünschte zur Zeit noch nicht.

 

Meiner Meinung nach ist es auch total überflüssig, wenn es das erlauben würde. Oder wo wäre deiner Meinung nach da der Vorteil?

 

Ok, ich habe oben eine wichtige Information unterlassen, die für mich selbstverständlich war - in dem VM-Cluster läuft natürlich noch mehr, als nur Exchange. Tut mir leid, für Deine eventuell doppelte Mühe.

 

Kein Problem. :)

 

Ich formuliere neu:

 

- HA-Cluster mit drei Knoten und einem Storage (Platz genug vorhanden)

- drei virtuelle Windows-Server mit Exchange (nur Mailbox-Rolle)

- außerdem laufen folgende virtuelle Maschinen:

-- 1x DC (hier gibt es noch Diskussionen und eventuell Änderungen wegen Exchange)

-- 1x Print Server

-- 1x Fileserver

-- 1x Linux Server (Systemüberwachung mit Nagios)

 

Angeplant sind:

- Datenbank-Server (BS und DB-System noch nicht definiert)

- Webserver auf Linux/Apache-Basis für Intranet

- Terminalservice (verm. in eigener Virtualisierung)

 

Kunde will:

- wenn ein physischer Knoten ausfällt möglichst hohe Verfügbarkeit und schnelle Wiederherstellung (aller Rollen!)

- beim geplanten oder ungeplanten Ausfall eines virtuellen Exchange-Server möglichst hohe Verfügbarkeit und schnelle Wiederherstellung der Datenbank

 

Kunde will von der jetzigen Lösung weg (Fremdprodukt) und stuft Mail als "kritisch" ein. Er ist von DAGs sehr angetan, weil er genau dieser Funktion bei seinem jetzigen System vermisst. Die vorhandene und ausreichend dimensionierte VM-Landschaft soll weiter benutzt werden.

 

Die Lösung meiner anderen Antwort bleibt gleich. Oder gibts nur global an/aus für Failover? Ich meine, dass das pro Guest definiert wird, oder?

 

Wie löschen wir das?

 

Muß man doch nicht. ;)

 

Bye

Norbert

[gelöscht 0]

Hallo,

 

kurz zurück zum Thema:

 

Ich empehle die Exchange Datenbank in eine Fixed Size VHD/VMDK zu legen, ein Raw-Device Mapping (Pass Through Disk) bringt keine Vorteile, nur die bekannten Einschränkungen, z.B. Backup (hostbasiert), Storage VMotion bzw. Quick Storage Migration etc.

 

ASR