Entwurf des Layouts von Datenbankkopien

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2010-11-11

Beim Entwerfen einer Hochverfügbarkeitslösung für Postfachserver muss die hohe Verfügbarkeit der folgenden Infrastrukturkomponenten sichergestellt werden:

  • Infrastrukturdienste, z. B. Active Directory und DNS (Domain Name System)

  • Mitgliedsserver der Datenbankverfügbarkeitsgruppe

  • Einzelne Speicherkomponenten wie Datenträger, Speichercontroller und Arbeitsspeicher (RAM)

  • Einzelne Netzwerkkomponenten, z. B. Router, Switches und Aggregatoren

  • Server- und Speichergestelle

  • Power-Busse

  • Datencenter

Jeder dieser Komponentenbereiche stellt eine potenzielle Fehlerquelle bzw. einen potenziellen Fehlerbereich dar. Deshalb hängt der Verfügbarkeitsgrad ihrer Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) letztlich davon ab, wie Sie die Lösung hinsichtlich der Isolierung und Minimierung der negativen Auswirkungen entwerfen, die ein Fehler in einem dieser Bereiche auf Ihre DAG-Umgebung haben kann. Zum Erreichen von Unabhängigkeit zwischen potenziellen Fehlerbereichen muss jeder potenzielle Fehlerbereich über eine Kopie der Datenbank verfügen. Da darüber hinaus ein Fehler dazu führen würde, dass mehrere Kopien nicht verfügbar sind, ist pro potenziellem Fehlerbereich nicht mehr als eine Kopie erforderlich.

Angenommen, es liegt ein Szenario mit zwei Kopien einer Datenbank vor. Jede Kopie wird auf einem gesonderten Satz von Datenträgern gespeichert, die sich jedoch beide im selben Speicherarray befinden. Wenn das Speicherarray ausfällt oder einem anderen Grund nicht verfügbar sein sollte, wären beide Kopien nicht verfügbar. In diesem Beispiel ist das Speicherarray der potenzielle Fehlerbereich. Im Array darf sich nur eine Kopie jeder Postfachdatenbank befinden. Andernfalls stehen bei einem Ausfall des Arrays mehrere (oder ggf. alle) Kopien der Datenbank nicht zur Verfügung.

Berücksichtigen Sie bei der Planung der Postfacharchitektur die folgenden zusätzlichen Entwurfsaspekte:

  • Sollen mehrere Datenbankkopien bereitgestellt werden?

  • Wie viele Kopien der Datenbank werden bereitgestellt?

  • Werden Sie mit einer Architektur mit Ausfallsicherheit für Standorte arbeiten?

  • Welches Modell für die Ausfallsicherheit von Postfachservern wird bereitgestellt?

  • Wie viele Postfachserver werden bereitgestellt?

  • Mit welchem Sicherungsmodell wird gearbeitet?

  • Welche Speicherarchitektur ist geplant?

Weitere Informationen zur Planung und Beantwortung dieser Fragen finden Sie unter Grundlegendes zu hoher Verfügbarkeit.

Inhalt

Unausgewogene Layouts von Datenbankkopien

Entwerfen eines ausgewogenen Layouts von Datenbankkopien

Die Verteilung aktiver Datenbanken im Beispielszenario im Verlauf von Serverausfällen

Entwurfsszenarios

Möchten Sie wissen, welche Verwaltungsaufgaben es im Zusammenhang mit hoher Verfügbarkeit und Ausfallsicherheit gibt? Informationen hierzu finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Unausgewogene Layouts von Datenbankkopien

Untersuchen Sie zum Nachvollziehen, wie Datenbankkopien in einer DAG verteilt werden sollten, einen Entwurf einer DAG, den Contoso, Ltd. für seine hochverfügbare Postfachserverlösung plant. Die DAG von Contoso besteht auf folgenden Komponenten:

  • 4 Postfachservern

  • 20 Postfachdatenbanken

  • 2 Kopien jeder Postfachdatenbank

Alle Server sind in einem einzelnen Datencenter bereitgestellt, haben einen eigenen dedizierten Speicher und werden in einem eigenen Servergestell bereitgestellt.

Contoso fordert an, dass zwei hochverfügbare (z. B. unverzögerte) Datenbankkopien stets zur Verfügung stehen und dass die Lösung den gleichzeitigen Ausfall zweier Mitglieder der DAG ohne negative Auswirkungen auf die Verfügbarkeit der Datenbanken übersteht.

Die folgende Abbildung zeigt das auf diesen Anforderungen basierende Layout der Datenbankkopien.

Anfängliches Layout der Datenbankkopien

Datenbankkopielayout – Tabelle 1

Anfänglich sieht der Entwurf überzeugend aus, da die aktiven Kopien jeder Datenbank auf die vier Mitglieder der DAG verteilt sind. Doch bei diesem Entwurf gibt es Einwände, denn das Layout ist aus Serverressourcensicht nicht optimal. Wenn beispielsweise ein einzelner Server ausfällt, führt dies zu einer ungleichmäßigen Verteilung von Datenbanken (siehe die folgende Abbildung).

Layout der Datenbankkopien nach Ausfall eines einzelnen Servers

Datenbankkopielayout nach einem Serverausfall

Der Ausfall von Server4 führt zur Aktivierung der Datenbank DB16 bis DB20 auf Server1 und nicht zur Verteilung auf die drei verbleibenden Server. Das Ergebnis ist eine ungleichmäßige Verteilung aktiver Postfachdatenbanken und eine ungleichmäßige Nutzung von Serverressourcen. Im Vergleich zu den beiden anderen Servern (Server2 und Server3) hat sich die Auslastung von Server1 verdoppelt.

Ein weiterer Einwand ist, dass die DAG in keinem Fall genügend Kopien aufweist, um zwei gleichzeitige Serverausfälle schadlos zu überstehen. Ein weiterer Serverausfall könnte dazu führen, dass 50 % der Datenbanken nicht verfügbar sind. Wenn Server1 und Server4 ausfallen oder kurz nacheinander nicht mehr zur Verfügung stehen sollten, sind 10 Datenbanken nicht mehr verfügbar (siehe die folgende Abbildung).

Layout der Datenbankkopien nach Ausfall zweier Server

Datenbankkopielayout nach einem wiederholten Serverausfall

Dieser Entwurf erfüllt nicht die Hauptanforderung des schadlosen Überstehens eines doppelten Serverausfalls. Zum schadlosen Überstehen eines doppelten Serverausfalls und Beibehalten aller aktiven Datenbanken muss eine dritte Kopie bereitgestellt und ein neues Layout entwickelt werden.

Zurück zum Seitenanfang

Entwerfen eines ausgewogenen Layouts von Datenbankkopien

Das Entwerfen eines ausgewogenen Layouts von Datenbankkopien kann das Überdenken mehrerer Entwurfsentscheidungen mit sich bringen, um den optimalen Entwurf zu entwickeln. Befolgen Sie beim Planen des Layouts der Datenbankkopien die folgenden Entwurfsgrundsätze:

  • Sorgen Sie für eine Minimierung des Ausfalls mehrerer Datenbankkopien einer Postfachdatenbank, indem Sie die Kopien voneinander isolieren und in verschiedenen potenziellen Fehlerbereichen platzieren. Platzieren Sie beispielsweise nicht mehrere Datenbankkopien einer bestimmten Postfachdatenbank im selben Servergestell oder Speicherarray.

  • Wählen Sie für die Datenbankkopien ein einheitliches, verteiltes Layout, um sicherzustellen, dass die aktiven Postfachdatenbanken nach einem Ausfall gleichmäßig verteilt werden. Die Summe der Aktivierungseinstellungen für jede Datenbankkopien auf einem bestimmten Server muss gleich oder nahezu gleich sein. Dies führt zu einer nahezu gleichmäßigen Verteilung nach einem Ausfall, vorausgesetzt die Replikation verläuft ordnungsgemäß und ist aktuell.

Bausteine

Zur Befolgung der zuvor genannten Entwurfsgrundsätze wird das Platzieren der Datenbankkopien in einer bestimmten Anordnung empfohlen, die sicherstellt, dass alle aktiven Kopien symmetrisch auf so vielen Servern wie möglich verteilt werden. Die Anordnung der Datenbankkopien basiert auf einem Bausteinprinzip.

Der erste Baustein (Ebene 1-Baustein genannt) basiert auf der Anzahl der Postfachserver, die die aktiven Datenbankkopien hosten. Angenommen, dieser Wert ist N. N bestimmt nicht nur die Anzahl der Postfachserver, sondern auch die Anzahl der Datenbanken im Baustein. Eine aktive Datenbankkopie wird auf alle Server verteilt, sodass sich ein diagonales Muster bildet. Wie im vorherigen Beispiel gibt es 4 Postfachserver und 20 Postfachdatenbanken. Die Größe des ersten Ebene 1-Bausteins ist 4 (siehe die folgende Abbildung).

Ebene 1-Baustein

Ebene 1-Baustein

Für alle verbleibenden Ebene 1-Bausteingruppen wird dasselbe Muster wiederholt. Da es 20 Datenbanken gibt, sind fünf Ebene 1-Bausteingruppen vorhanden (siehe die folgende Abbildung).

Fünf Ebene 1-Bausteine für 20 Datenbanken

Fünf Ebene 1-Bausteine für 20 Datenbanken

Wenn Sie eine zweite Datenbankkopie hinzufügen, muss diese in einer anderen Bausteingruppe platziert werden. Da ein Server bereits die aktive Kopie hostet, stehen N – 1 Server zum Hosten der zweiten Datenbankkopie zur Verfügung. Da Sie jeden dieser N – 1 Server einmal verwenden, ergibt sich eine vollständig symmetrische Verteilung, die den neuen größeren Baustein bildet. Deshalb hat der neue Baustein (Ebene 2-Baustein genannt) eine Größe von N × (N – 1) Datenbanken. Dies bedeutet, dass die zweite Datenbankkopie für die erste Datenbank auf dem zweiten Server platziert und jede zweite Kopie anschließend innerhalb des Bausteins mit einem diagonalen Muster bereitgestellt wird. Nach Fertigstellung des Musters in der ersten Ebene 1-Bausteingruppe wird die Anfangsposition der zweiten Kopie für den nächsten Block um eins versetzt, sodass die zweite Kopie auf dem dritten Server beginnt.

Im Beispiel beträgt die Bausteingröße nun 4 × (4 – 1) = 4 × 3 = 12, was bedeutet, dass jede Ebene 2-Bausteingruppe aus zwölf Datenbanken besteht. Für die Ebene 1-Bausteingruppe 1 (DB1 bis DB4) wird die zweite Kopie für DB1 auf Server2 platziert, während für die Ebene 1-Bausteingruppe 2 (DB5 bis DB8) die zweite Kopie für DB5 auf Server3 platziert wird. Die Platzierung des Anfangsservers jeder Ebene 1-Bausteingruppe wird im Vergleich zur vorherigen Ebene 1-Bausteingruppe um einen Server versetzt. Dieses Layout wird fortgesetzt, indem die zweite Kopie von DB9 auf Server4 platziert wird. Dies stellt sicher, dass bei Ausfall von Server1 zweite Kopien auf allen drei verbleibenden Server, anstatt mehrere Datenbanken auf demselben Server zu aktivieren.

Ebene 2-Baustein mit drei Ebene 1-Bausteinen

Ein Ebene 2-Baustein mit drei Ebene 1-Bausteinen

Für alle verbleibenden Ebene 2-Bausteingruppen wird dasselbe Muster wiederholt. Da es 20 Datenbanken gibt, sind im Beispiel zwei Ebene 2-Bausteingruppen vorhanden. Beachten Sie, dass die zweite Kopie für DB13 auf Server2 platziert wird.

Ebene 2-Baustein mit den verbleibenden beiden Ebene 1-Bausteinen

Ebene 2-Baustein mit verbleibenden zwei Bausteinen

Vergleichen Sie zum besseren Verständnis dieser Logik die Platzierung von Datenbankkopien für DB1, DB5 und DB9. Diese Datenbanken verfügen jeweils über eine auf Server1 gehostete aktive Kopie. Wenn Server1 ausfällt, sollen zweite Datenbankkopien auf verschiedenen verbleibenden Servern aktiviert werden, um eine gleichmäßig Lastverteilung zu erzielen. Platzieren Sie dazu eine zweite Datenbankkopie von DB1 auf Server2, eine zweite Datenbankkopie von DB5 auf Server3 und eine zweite Datenbankkopie von DB9 auf Server4. Ab DB13 muss dieses Muster einfach wiederholt werden. Die verbleibenden Datenbankkopien werden in einem diagonalen Muster hinzugefügt (siehe die folgende Abbildung).

Platzierung von Datenbankkopien für eine gleichmäßige Verteilung

Platzierung von Datenbankkopien für eine gleichmäßige Verteilung

Beachten sei, dass der zweite Baustein (DB13 bis DB20) nur 8 und nicht 12 Datenbanken enthält. Demzufolge ist dieser Entwurf nicht gänzlich symmetrisch, sollte ein einzelner Ausfall eintreten. Planen Sie zum Ermöglichen einer vollständig symmetrischen Verteilung Ihre Architektur so, dass die Anzahl der Datenbanken ein Vielfaches der größten Bausteingröße ist. (In diesem Beispiel sind 24, 36, 48 bzw. 60 Datenbanken usw. optimale Werte.)

Sobald Sie eine dritte Datenbankkopie hinzufügen, müssen Sie sie wiederum für jede Gruppe von nun N × (N – 1) Datenbanken unterschiedlich platzieren. Da Ihnen für die Platzierung der dritten Datenbankkopie nun nur noch N – 2 Server zur Auswahl stehen, führt dies zu N – 2 Variationen. Der neue Baustein (Ebene 3-Baustein genannt) besteht aus N × (N – 1) × (N – 2) Datenbanken. Dies bedeutet, dass die dritte Datenbankkopie für die erste Datenbank auf dem dritten Server platziert und jede dritte Kopie anschließend gemäß der Ausgangsposition dieses neuen Bausteins in einem diagonalen Muster bereitgestellt wird. Nach Fertigstellung des Musters in der ersten Ebene 1-Bausteingruppe wird die Anfangsposition um eins versetzt, sodass die dritte Kopie an der vierten Stelle platziert wird.

In diesem Beispiel beträgt die Bausteingröße nun 4 × (4 – 1) × (4 – 2) = 4 × 3 × 2 = 24, was bedeutet, dass jede Ebene 3-Bausteingruppe aus 24 Datenbanken besteht. Platzieren Sie zum Erstellen des symmetrischen Datenbankplatzierungsmusters die dritte Datenbankkopie von DB1 auf Server3 (dem ersten verfügbaren Server, da Server1 die erste Kopie und Server2 die zweite Kopie hostet), und versetzen Sie jede weitere Kopie um eins, bis Sie das Ende der Ebene 1-Bausteingruppe 1 erreichen. Platzieren Sie für die nächste Bausteingruppe wiederum die dritte Datenbankkopie auf dem nächsten verfügbaren Server (Server4), und fahren Sie auf gleiche Weise fort, bis Sie DB12 erreichen, die das Ende der Ebene 2-Bausteingruppe 1 markiert. Befolgen Sie für DB13 bis DB20 dasselbe Muster, doch versetzen Sie die Platzierung der dritten Datenbankkopie um eins, damit diese nicht auf denselben Servern wie DB1 bis DB12 platziert wird.

Ausgewogenes Layout mit drei Datenbankkopien und vier Servern

Ausgewogenes Layout mit drei Kopien und vier Servern

Vergleichen Sie zum besseren Verständnis dieser Logik wiederum die Platzierung von Datenbankkopien für die Datenbanken DB1 bis DB13. Bei diesen Datenbanken wird die aktive Datenbankkopie auf Server1 und die zweite Datenbankkopie auf Server2 gehostet. Wenn diese Server ausfallen, sollen die dritten Datenbankkopien auf verschiedenen verbleibenden Servern aktiviert werden, um eine gleichmäßig Lastverteilung zu erzielen. Platzieren Sie hierzu die dritte Datenbankkopie von DB1 auf Server3 und die dritte Datenbankkopie von DB13 auf Server4. Ähnliche Paare werden von DB2 und DB14, DB3 und DB15 usw. gebildet. Ab DB25 kann dieses Muster einfach wiederholt werden (wenngleich in diesem Beispiel nicht so viele Datenbanken verwendet werden).

Beachten Sie, dass der dritte Baustein (DB1 bis DB20) nur 20 und nicht 24 Datenbanken enthält. Aus diesem Grund ist dieser Entwurf nicht gänzlich symmetrisch, sollte es zu einem doppelten Serverausfall kommen. Planen Sie zum Ermöglichen einer vollständig symmetrischen Verteilung Ihre Architektur wiederum so, dass die Anzahl der Datenbanken ein Vielfaches der größten Bausteingröße ist. (In diesem Beispiel sind 24, 36, 48 bzw. 72 Datenbanken usw. optimale Werte.)

Sobald Sie eine vierte Datenbankkopie hinzufügen, müssen Sie sie wiederum für jede Gruppe von nun N × (N – 1) × (N – 2) Datenbanken unterschiedlich platzieren. Der neue Baustein besteht aus N × (N – 1) × (N – 2) × (N – 3) Datenbanken. Dabei wird derselbe logische Ansatz befolgt und sichergestellt, dass die Datenbankverteilung innerhalb des neuen Bausteins auch bei einem Ausfall von drei Servern gleichmäßig ist.

Das Beispiel mit vier Servern lässt nur eine Variation für die Platzierung der vierten Datenbankkopie übrig (da nur noch ein verbleibender Server verfügbar ist). Deshalb bleibt die Bausteingröße weiter 24. Dies ergibt sich auch aus der folgenden Formel für die Bausteingröße: 4 × 3 × 2 × (4 – 3) = 4 × 3 × 2 × 1 = 24.

Wenn Sie weitere Datenbankkopien hinzufügen, nimmt die Bausteingröße weiter zu, sodass die allgemeine Formel für die Bausteingröße wie folgt lautet: Perm(N,M) = N × (N – 1) … (NM + 1) = N!/(NM)! = CNMM!, wobei N = Anzahl der Server M = Anzahl der Datenbankkopien. Dies wird offenkundig, wenn Sie feststellen, dass eine vollständig symmetrische Verteilung der Datenbankkopien erreicht wird, indem alle möglichen Permutationen von M Datenbankkopien auf N verfügbaren Servern ausgewählt werden.

Diese Vorgehensweise unterliegt verschiedenen Einschränkungen:

  • Das Bereitstellen einer Anzahl von Datenbanken, die nicht ein Vielfaches der größten Bausteingröße ist, führt bei Ausfallereignissen zu einer nicht symmetrischen Verteilung aktiver Datenbanken.

  • Das Bereitstellen von Architekturen zum Abfedern des Ausfalls mehrerer Domänen kann bei Ausfallereignissen zu einer nicht symmetrischen Verteilung aktiver Datenbanken führen. Der Grund hierfür ist, dass Fehlerbereichsdefinitionen für Einschränkungen bei der Platzierung von Datenbankkopien sorgen, wodurch die Symmetrie dies Musters gestört wird.

  • Das Bereitstellen ausfallsicherer Lösungen, die zu standortexternen Switch- bzw. Failoverereignissen für Datenbanken führen, können eine nicht symmetrische Verteilung von Datenbanken verursachen, die im Verlauf von Serverausfällen im primären Datencenter im sekundären Datencenter aktiviert werden.

Zurück zum Seitenanfang

Die Verteilung aktiver Datenbanken im Beispielszenario im Verlauf von Serverausfällen

Bei Verwendung des vorherigen Beispiels werden bei einem Ausfall eines einzelnen Servers (z. B. von Server4) die aktiven Postfachdatenbanken wie in der folgenden Abbildung gezeigt verteilt. Die zweite Kopie wird für DB4, DB8, DB12, DB16 und DB20 (orange als aktiv gekennzeichnet) aktiviert.

Verteilung aktiver Datenbankkopien nach Ausfall eines einzelnen Servers

Verteilung der aktiven Datenbankkopie nach einem Ausfall

Bei einem doppelten Serverausfall (die dritte Kopie wird für mehrere Datenbanken aktiviert und grün als aktiv gekennzeichnet) verfügen die beiden verbleibenden Server (Server1 und Server3) über eine identische Anzahl aktivierter Postfachdatenbanken.

Verteilung aktiver Datenbankkopien nach Ausfall zweier Server

Verteilung der aktiven Kopie nach einem wiederholten Ausfall

Da die Anzahl der Datenbanken in diesem Beispiel kein Vielfaches der größten Bausteingröße (24 Datenbanken) ist, führen nicht alle Ausfälle zweier Server zu einer symmetrischen Verteilung.

Verteilung aktiver Datenbankkopien nach einem anderen Ausfall zweier Server

Verteilung der aktiven Kopie nach einem anderen Ausfall

Zurück zum Seitenanfang

Entwurfsszenarios

Untersuchen Sie zum Verstehen des Entwurfsgrundsatzes des Layouts von Datenbankkopien einschließlich der dazugehörigen mathematischen Formel zwei weitere Architekturlayouts.

Entwurfsszenario: Ausfallsichere Lösung mit aktiver/passiver Benutzerverteilung

In diesem Szenario entschließt sich Contoso zur Bereitstellung der folgenden Architektur:

  • Die DAG wird auf zwei Datencenter erweitert, die mit einem aktiven/passiven Benutzerverteilungsmodell betrieben werden.

  • Jeder Server wird in einer einem eigenen Servergestell bereitgestellt.

  • Der Speicher jedes Servers ist innerhalb des Datencenters vom Speicher der anderen Server isoliert.

  • Pro Datencenter gibt es vier Postfachserver.

  • Es gibt insgesamt 24 Postfachdatenbanken.

  • Das Ziel sind vier hochverfügbare Datenbankkopien und das schadlose Überstehen des Ausfalls eines einzelnen oder zweier Server.

In diesem Beispiel hat der Ebene 1-Baustein die Größe 4, die Datenbanken sind in Vierer-Einheiten gruppiert, und die aktiven Kopien sind innerhalb des Bausteins auf vier Server verteilt.

Gleichmäßige Verteilung der ersten Kopie in einem Baustein

Gleichmäßige Verteilung von Datenbanken im Baustein

Für jeden Server, der aktive Kopien hostet, wird die sekundäre Datenbankkopie so gleichmäßig wie möglich auf alle verbleibenden Mitgliedsserver verteilt, was in einem diagonalen Muster fortgesetzt wird, da jede Kopie von der anderen isoliert ist. Bei diesem Beispiel hat der Ebene 2-Baustein die Größe 12, was das Wiederholungsmuster alle 12 Datenbanken wird.

Gleichmäßige Verteilung einer zweiten Kopie in einem Baustein

Gleichmäßige Verteilung der zweiten Kopie im Baustein

Da diese ausfallsichere Lösung für ein aktives/passives Benutzerverteilungsmodell mit einer identischen Anzahl von Servern und Datenbankkopien in beiden Datencentern vorgesehen ist, wird die dritte Datenbankkopie in einem diagonalen Muster auf Server5 und Server6 mithilfe des Werts 4 für den Ebene 1-Baustein platziert. Dies stellt sicher, dass Server5 und Server6 die Platzierung der primären Datenbankkopie auf Server1 bis Server4 spiegeln.

Gleichmäßige Verteilung einer dritten Kopie im zweiten Baustein

Gleichmäßige Verteilung der dritten Kopie im Baustein

Da diese ausfallsichere Lösung für ein aktives/passives Benutzerverteilungsmodell mit einer identischen Anzahl von Servern und Datenbankkopien in beiden Datencentern vorgesehen ist, wird die vierte Datenbankkopie in einem diagonalen Muster auf Server5 und Server6 mithilfe des Werts 12 für den Ebene 2-Baustein platziert. Dies stellt sicher, dass Server5 und Server6 die Platzierung der zweiten Datenbankkopie auf Server1 bis Server4 spiegeln.

Gleichmäßige Verteilung einer vierten Kopie im zweiten Baustein

Gleichmäßige Verteilung der vierten Kopie im Baustein

Wenn ein einzelner Server ausfällt, verfügen die restlichen drei Sever im primären Datencenter über eine identische Anzahl aktivierter Postfachdatenbanken (8 pro Server).

Verteilung aktiver Datenbankkopien nach Ausfall eines einzelnen Servers

Verteilung aktiver Kopien nach einem Serverausfall

Wenn zwei Server gleichzeitig ausfallen, verfügen die restlichen zwei Sever im primären Datencenter über eine identische Anzahl aktivierter Postfachdatenbanken (10 pro Server), während 4 Datenbanken im sekundären Datencenter aktiviert werden.

Verteilung aktiver Datenbankkopien nach Ausfall zweier Server

Verteilung aktiver Kopien nach einem wiederholten Ausfall

Entwurfsszenario: Mehrere potenzielle Fehlerbereiche

In diesem Beispiel entschließt sich Wingtip Toys zur Bereitstellung der folgenden Architektur:

  • Alle Server werden in einem Datencenter bereitgestellt.

  • Server werden in Dreier-Einheiten gruppiert.

  • Jeder der drei Server wird zusammen mit seinem Speicher im selben Gestell platziert.

  • Es gibt insgesamt 3 Gestelle und 9 Server.

  • Es gibt insgesamt 18 Postfachdatenbanken.

  • Das Ziel sind drei hochverfügbare Datenbankkopien und das schadlose Überstehen des Ausfalls zweier Mitgliedsserver oder eines einzelnen Gestells.

In diesem Beispiel hat der Ebene 1-Baustein die Größe 6, sodass die Datenbanken in Sechser-Einheiten gruppiert werden, und die aktiven Kopien sind innerhalb des Bausteins auf sechs Server verteilt.

Layout der Datenbankkopien für den Ebene 1-Baustein

Datenbankkopielayout für Ebene 1-Baustein

Für jeden Server, der aktive Kopien hostet, wird die zweite Datenbankkopie so gleichmäßig wie möglich auf alle verbleibenden Mitgliedsserver verteilt. Zugleich wird sichergestellt, dass die beiden Kopien derselben Datenbank nicht im selben Servergestell platziert werden. In diesem Beispiel wird anstelle der Formel N × (N – 1) für Ebene 2-Bausteine die Formel N × (N – 2) verwendet, um sicherzustellen, dass zwei Kopien derselben Datenbank nicht im selben Gestell platziert werden. Dies bedeutet, dass die Größe des Ebene 2-Bausteins 6 × 4 = 24 beträgt.

Layout der Datenbankkopien für die erste und zweite Kopie

Datenbankkopielayout für die erste und die zweite Kopie

Die dritte Datenbankkopie wird in einem diagonalen Muster auf den Servern verteilt, was wiederum gewährleistet, dass mehrere Kopien derselben Datenbank nicht im selben Servergestell platziert werden. In diesem Beispiel wird anstelle der Formel N × (N – 2) die Formel N × (N – 2) × (N – 4) verwendet, um sicherzustellen, dass zwei Kopien derselben Datenbank nicht im selben Gestell platziert werden. Dies bedeutet, dass die Größe des Ebene 3-Bausteins 6 × 4 × 2 = 48 beträgt.

Layout der Datenbankkopien für die erste, zweite und dritte Kopie

Datenbankkopielayout für drei Kopien

Wenn ein einzelner Server ausfällt, verfügen die restlichen fünf Sever im primären Datencenter über eine nahezu identische Anzahl aktivierter Postfachdatenbanken. Vier Server verfügen über 10 aktivierte Datenbanken, während ein Server (der Gestellpartner) 8 aktivierte Datenbanken aufweist.

Anzahl und Layout der aktiven Datenbankkopien nach Ausfall eines einzelnen Servers

Anzahl und Layout aktiver Datenbanken nach einem Ausfall

Wenn zwei Server (in unterschiedlichen Gestellen) gleichzeitig ausfallen, verfügen die restlichen vier Sever über eine nahezu identische Anzahl aktivierter Postfachdatenbanken.

Anzahl und Layout der aktiven Datenbankkopien nach Ausfall zweier Server (in unterschiedlichen Gestellen)

Anzahl und Layout aktiver Datenbanken nach einem wiederholten Ausfall

Wenn zwei Server (im gleichen Gestell) gleichzeitig ausfallen, verfügen die restlichen vier Sever über eine identische Anzahl aktivierter Postfachdatenbanken.

Anzahl und Layout der aktiven Datenbankkopien nach Ausfall zweier Server (im selben Gestell)

Anzahl und Layout aktiver Datenbanken nach einem wiederholten Ausfall

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.