Grundlegendes zu hoher Verfügbarkeit

 

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

Letztes Änderungsdatum des Themas: 2015-03-09

Beim Planen eines Postfachservers und einer Datenbankarchitektur mit hoher Verfügbarkeit, müssen unter anderem folgende Entwurfsentscheidungen getroffen werden:

• Werden Sie mehrere Datenbankkopien bereitstellen?

• Wie viele Datenbankkopien werden Sie bereitstellen?

• Verfügen Sie über eine Architektur, die Ausfallsicherheit von Standorten bietet?

• Welche Art Ausfallsicherheit von Postfachservern werden Sie bereitstellen?

• Wie viele Postfachserver werden Sie bereitstellen?

• Wie werden Sie Datenbankkopien verteilen?

• Welches Sicherungsmodell werden Sie verwenden?

• Welche Speicherarchitektur werden Sie verwenden?

Microsoft Exchange Server 2010 ermöglicht die Bereitstellung Ihrer Postfachserverinfrastruktur mithilfe von eigenständigen Postfachservern oder Postfachservern, die für die Ausfallsicherheit von Postfächern konfiguriert sind. Für die Ausfallsicherheit von Postfächern konfigurierte Postfachserver stellen eine Database Availability Group (DAG) mit mehreren Datenbankkopien, die effizient über die DAG verteilt sind, bereit. Durch das Bereitstellen mehrerer Datenbankkopien können Sie Folgendes tun:

• Entwerfen einer Lösung, die das Risiko, aufgrund dessen eine Sicherung am häufigsten durchgeführt wird, verringert. Datenbankkopien bieten Schutz vor Ausfällen der Hardware, der Software und des Rechenzentrums.

• Erweitern von Datenbankgrößen auf bis zu 2 Terabyte, da der Wiederherstellungsmechanismus eine andere Datenbankkopie und keine Wiederherstellung einer Sicherung ist.

• In Betracht ziehen von alternativen Speicherarchitekturen statt herkömmlicher RAID-Konfigurationen wie JBOD (Just a Bunch Of Disks), wenn Sie mindestens drei Datenbankkopien bereitstellen. Die Kombination von JBOD und weniger kostspieligen Festplatten kann die Kosten für Ihre Organisation senken.

Durch die Bereitstellung aktiver Datenbanken auf allen Servern, die Mitglieder einer DAG sind, können Sie die Effizienz Ihrer Hardware maximieren.

Ausführliche Informationen finden Sie unter Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten und Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

Inhalt

Planen der Anzahl bereitzustellender Datenbankkopien

Datenbankkopien

Ausfallsicherheit von Standorten

Planen des Modells für die Ausfallsicherheit von Postfachservern

Planen der Anzahl bereitzustellender Postfachserver

Planen des Layouts von Datenbankkopien

Planen der Sicherungsmodellarchitektur

Planen der Speichermodellarchitektur

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

Planen der Anzahl bereitzustellender Datenbankkopien

Wie in Grundlegendes zu Postfachdatenbankkopien beschrieben, kann ein DAG-Mitglied eine Kopie jeder Postfachdatenbank hosten. Die Höchstzahl liegt bei 100 Datenbanken pro Server in der Enterprise Edition des Produkts (diese Angabe umfasst sowohl aktive als auch passive Kopien). Das heißt, dass der Grenzwert bei 1.600 Datenbanken liegt, die von einer DAG mit 16 Mitgliedern unterstützt werden (100 Datenbankkopien pro Server × 16 Server pro DAG ÷ 1 Kopie pro Datenbank = 1.600 Datenbanken pro DAG).

In einer Hochverfügbarkeitskonfiguration gibt es keinen Wert für die Bereitstellung einer einzelnen Kopie einer Datenbank, weil dadurch keine Datenredundanz ermöglicht wird. Sie können eine Formel verwenden, um die Anzahl an Datenbanken zu bestimmen, die eine bestimmte DAG unterstützen kann. Wenn Sie beispielsweise D als Anzahl der bereitzustellenden Datenbanken, C als Anzahl der Kopien jeder Datenbank und S als Anzahl der Server festlegen, gilt Folgendes:

• D × C = Gesamtanzahl von Datenbankkopien in der DAG

• (D × C) ÷ S = Datenbankkopien pro Server

Hinweis

Das Ergebnis, die Anzahl der Datenbanken pro Server, muss in der Enterprise Edition bei 100 oder weniger liegen, in der Standard Edition bei 5 oder weniger.

Angenommen, Sie verfügen über eine DAG mit sechs Servern und 84 Postfachdatenbanken mit drei Kopien pro Datenbank. (Beachten Sie, dass 6 ein ganzzahliges Vielfaches der drei Kopien ist.) Folgendes gilt:

• 84 Datenbanken × 3 Kopien = 252 Datenbanken gesamt

• 252 Datenbanken ÷ 6 Server = 42 Datenbankkopien pro Server

Angenommen, Sie verfügen über eine DAG mit vier Servern und 136 Postfachdatenbanken mit drei Kopien pro Datenbank. Folgendes gilt:

• 136 Datenbanken × 3 Kopien = 408 Datenbanken gesamt

• 408 Datenbanken ÷ 4 Server = 102 Datenbankkopien pro Server

Da 102 größer als 100 ist, ist das vorgeschlagene Szenario kein gültiger DAG-Entwurf.

Zurück zum Seitenanfang

Datenbankkopien

Es gibt zwei Arten von Datenbankkopien:

• Hochverfügbare Datenbankkopien

• Verzögerte Datenbankkopien

Bei hochverfügbaren Datenbankkopien handelt es sich um Kopien, die mit einer Wiedergabeverzögerung von Null konfiguriert wurden. Wie der Name nahelegt, werden hochverfügbare Datenbankkopien vom System aktualisiert, sie können vom System automatisch aktiviert werden, und sie werden verwendet, um Hochverfügbarkeit für Postfachdienste und -daten bereitzustellen.

Verzögerte Datenbankkopien wurden so konfiguriert, dass sie die Wiedergabe von Transaktionsprotokollen für eine bestimmte Zeit verzögern. Verzögerte Datenbankkopien bieten Zeitpunktschutz für die Wiederherstellung eines Informationsspeichers nach logischer Beschädigung, administrativen Fehlern (z. B. Löschen oder Leeren eines getrennten Postfachs) und Automatisierungsfehlern (z. B. Massenleeren getrennter Postfächer).

Normalerweise werden verzögerte Datenbankkopien aufgrund des Algorithmus für den Auswahlvorgang der besten Kopie durch den Active Manager nicht aktiviert. Da verzögerte Datenbankkopien zur Verringerung von Betriebsrisiken bereitgestellt werden, sollten sie nicht aktiviert werden. Wenn sie aktiviert werden und eine Einbindungsanforderung ausgegeben wird, wird die Protokollwiedergabe gestartet: Alle Protokolldateien, die dafür erforderlich sind, die Datenbank zu aktualisieren und in den Zustand "Clean Shutdown" zu versetzen, werden wiedergegeben, wodurch die Zeitpunktfunktionalität verloren geht.

Weitere Informationen zum Blockieren der Aktivierung auf Postfachserverebene oder zum Anhalten der Aktivierung mindestens einer Datenbankkopie, um die automatische Aktivierung einer Datenbankkopie (z. B. einer verzögerten Datenbankkopie) zu verhindern, finden Sie unter Set-MailboxServer und Suspend-MailboxDatabaseCopy.

Zurück zum Seitenanfang

Ausfallsicherheit von Standorten

Ihre Umgebung besteht möglicherweise aus mehreren Rechenzentren. Als Teil Ihres Exchange 2010-Entwurfs bestimmen Sie, ob die Exchange-Infrastruktur in einem einzelnen Rechenzentrum oder in mehr als zwei Rechenzentren bereitgestellt werden soll. Die Vereinbarungen zum Servicelevel (SLAs, Service Level Agreements) für Wiederherstellungen in Ihrer Organisation definieren, welcher Servicelevel nach einem Ausfall des primären Rechenzentrums erforderlich ist.

Wenn Ihre Exchange-Bereitstellung mehrere Rechenzentren umfasst, um die erforderliche Ausfallsicherheit der Standorte zu erzielen, müssen Sie entscheiden, welches Benutzerverteilermodell zutrifft. Zwei Verteilermodelle kommen, in Abhängigkeit von dem Standort des Postfachs in Bezug auf den des Rechenzentrums, in Frage:

• Aktiv/Passiv-Benutzerverteilermodell

• Aktiv/Aktiv-Benutzerverteilermodell

Wenn sich Benutzerpostfächer primär in einem einzelnen Rechenzentrum befinden (oder wenn Benutzer von einem einzigen Rechenzentrum aus auf ihre Daten zugreifen) und eine SLA-Anforderung vorgibt, dass die Benutzer während normaler Vorgänge weiterhin über das primäre Rechenzentrum auf ihre Daten zugreifen, entspricht Ihre Architektur einem Aktiv/Passiv-Benutzerverteilermodell.

Wenn Benutzerpostfächer über mehrere Rechenzentren verteilt sind und eine SLA-Anforderung vorgibt, dass die Benutzer während normaler Vorgänge weiterhin über das primäre Rechenzentrum auf ihre Daten zugreifen, handelt es sich bei Ihrer Architektur um ein Aktiv/Aktiv-Benutzerverteilermodell.

In einem Aktiv/Passiv-Benutzerverteilermodell können Sie die Architektur wie in der folgenden Abbildung gezeigt bereitstellen: Die aktiven Postfächer werden vom primären Rechenzentrum gehostet, die Datenbankkopien werden jedoch im sekundären Rechenzentrum bereitgestellt.

Aktiv/Passiv-Benutzerverteilermodell mit zwei Rechenzentren

Die in der folgenden Abbildung dargestellte Architektur kann theoretisch für ein Aktiv/Aktiv-Benutzerverteilermodell verwendet werden.

Aktiv/Aktiv-Benutzerverteilermodell mit zwei Rechenzentren

Es gibt jedoch ein Risiko bei der in der vorangehenden Abbildung dargestellten Architektur. Das Fernnetz (WAN) stellt eine einzelne Fehlerquelle für die DAG dar. Ein Ausfall des Fernnetzes führt zu einem Verlust des Quorums für DAG-Mitglieder im zweiten Rechenzentrum. In diesem Beispiel verfügt der Windows-Failovercluster über insgesamt fünf Stimmen (vier DAG-Mitglieder plus ein Zeugenserver). Drei Stimmen müssen jederzeit verfügbar sein, damit der Failovercluster funktionsfähig bleibt. Drei der Stimmen befinden sich im Rechenzentrum "Redmond" und zwei im Rechenzentrum "Portland". Ein Ausfall der Fernnetzverbindung führt dazu, dass das Rechenzentrum "Portland" nur zwei der Stimmen hostet, was zur Aufrechterhaltung des Quorums nicht ausreicht. Das Rechenzentrum "Redmond" verfügt über drei Stimmen. Solange diese drei Stimmen funktionsfähig sind, kann das Quorum aufrechterhalten und die aktiven Postfächer weiterhin bereitgestellt werden.

Für eine Verringerung des Risikos bei Aktiv/Aktiv-Benutzerverteilermodellen wird die Bereitstellung von zwei DAGs empfohlen, wie in der folgenden Abbildung dargestellt.

Zwei DAGs für das Aktiv/Aktiv-Benutzerverteilermodell

DAG1 hostet die aktiven Postfächer für das Rechenzentrum "Redmond" und wird als Aktiv/Passiv-Benutzerverteilermodell mit passiven Datenbankkopien, die im Rechenzentrum "Portland" bereitgestellt werden, implementiert. DAG2 hostet die aktiven Postfächer für das Rechenzentrum "Portland" und wird als Aktiv/Passiv-Benutzerverteilermodell mit passiven Datenbankkopien, die im Rechenzentrum "Redmond" bereitgestellt werden, implementiert.

Diese Architektur kann den Ausfall des Fernnetzes kompensieren:

• Im Rechenzentrum "Redmond" werden die Postfachservermitglieder für DAG2 aufgrund des Verlust des Quorums in den Zustand "Fehlgeschlagen" versetzt, die aktiven Postfachservermitglieder für DAG1 bleiben jedoch für die Benutzer funktionsfähig.

• Im Rechenzentrum "Portland" werden die Postfachservermitglieder für DAG1 aufgrund des Verlust des Quorums in den Zustand "Fehlgeschlagen" versetzt, die aktiven Postfachservermitglieder für DAG2 bleiben jedoch für die Benutzer funktionsfähig.

Weitere Informationen finden Sie unter Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten.

Zurück zum Seitenanfang

Planen des Modells für die Ausfallsicherheit von Postfachservern

Ein wesentlicher Aspekt der Kapazitätsplanung für Exchange 2010-Postfachserver besteht darin, die Anzahl der Datenbankkopien zu ermitteln, die im Rahmen der Ausfallsicherheit von Postfächern pro Server aktiviert werden sollen. Eine Reihe von Entwürfen sind möglich, aber es werden zwei Modelle empfohlen, die in den folgenden Abschnitten beschrieben werden.

Entwurf mit Aktivierung aller Datenbankkopien

Sie können Ihre Serverarchitektur so konzipieren, dass 100 Prozent aller gehosteten Datenbankkopien aktiviert werden. Wenn Ihr Server beispielsweise 35 Datenbankkopien hostet, können Sie den Prozessor und den Arbeitsspeicher so konzipieren, dass während der Spitzenauslastung alle 35 Datenbanken aktiviert sind. Diese Lösung wird normalerweise paarweise bereitgestellt. Wenn Sie beispielsweise vier Server bereitstellen, besteht ein Paar aus den Servern 1 und 2 und das zweite Paar aus den Servern 3 und 4. Außerdem planen Sie bei diesem Szenario für jeden Server nicht mehr als 40 Prozent verfügbare Ressourcen für normale Laufzeitvorgänge ein.

Dieses Modell verfügt über die höhere Anzahl an Servern im Vergleich zu dem zweiten, in diesem Thema beschriebenen Modell.

Entwurf für anvisierte Fehlerszenarien

Sie können Ihre Serverarchitektur so konzipieren, dass sie die aktive Postfachlast im schlimmsten angenommenen Fall verarbeiten kann. Bei diesem Modell sind eine Vielzahl von Faktoren zu berücksichtigen, z. B. Ausfallsicherheit, RAID-Speicher im Vergleich zu JBOD, DAG-Größe und die Anzahl der Datenbankkopien. Dieses Kapazitätsplanungsmodell bietet ein ausgewogenes Verhältnis zwischen Kapitalkosten, Verfügbarkeit und Clientleistungseigenschaften.

Angenommen, die Datenbankkopien sind gleichmäßig und nach dem Zufallsprinzip verteilt:

• Entwurf für automatische Serverfehler eines einzelnen Mitglieds in DAG-Konfigurationen mit zwei oder drei Mitgliedern und zwei hochverfügbaren Datenbankkopien pro Postfachdatenbank.

• Entwurf für Serverfehler von zwei Mitgliedern (manuelle Aktivierung nach dem zweiten Fehler) bei DAG-Konfigurationen mit drei Mitgliedern und drei hochverfügbaren Datenbankkopien pro Postfachdatenbank.

• Entwurf für automatische Serverfehler von zwei Mitgliedern, wobei die DAG über mindestens vier Mitglieder und mindestens drei hochverfügbare Datenbankkopien pro Postfachdatenbank verfügt.

Wenn Sie sich für dieses Kapazitätsplanungsmodell entscheiden, wird ausdrücklich empfohlen, die Anzahl der aktivierbaren Datenbanken pro Server zu beschränken, sodass ein einzelner Server nicht überlastet wird und kein Leistungsabfall die Folge ist.

Sie können die Anzahl der Datenbanken beschränken, indem Sie die Einstellung für die maximale Anzahl aktiver Datenbanken konfigurieren. Sie können diesen Grenzwert in der Exchange-Verwaltungsshell konfigurieren, indem Sie Set-MailboxServer -MaximumActiveDatabases ausführen. Konfigurieren Sie diesen Grenzwert auf jedem Server in der DAG, damit er mit der maximalen Anzahl aktiver Datenbanken, die von Ihrer Bereitstellung unterstützt werden, übereinstimmt.

Weitere Informationen finden Sie unter Entwurfsbeispiele für Datenbankverfügbarkeitsgruppen.

Zurück zum Seitenanfang

Planen der Anzahl bereitzustellender Postfachserver

Beim Bestimmen der Anzahl bereitzustellender Postfachserver müssen Sie ein Vielfaches der Anzahl bereitzustellender Datenbankkopien verwenden. Wenn Sie beispielsweise die Bereitstellung von drei Datenbankkopien planen, beginnen Sie den Entwurf mit drei, sechs, neun, zwölf oder 15 Servern.

Nach einer ersten Bestimmung der Anzahl der Server in der DAG skalieren Sie die DAG-Mitglieder entsprechend, basierend auf der Anzahl der Postfächer, auf dem Entwurfsmodell für Fehler und auf weiteren Entwurfseinschränkungen, die die Anzahl der erforderlichen Postfachserver entweder erhöht oder verringert.

Eine Entwurfseinschränkung ist bei vielen Organisationen die maximale Anzahl an Postfächern, die auf einem Server eingerichtet werden können. Wenn eine Organisation beispielsweise über 20.000 Postfächer verfügt und im Falle eines Fehlers nur 25 Prozent beeinträchtigt werden können, lautet die maximale Anzahl von Postfächern, die auf einem einzelnen Server bereitgestellt werden können, 5.000. Folglich ist die Bereitstellung von mindestens vier Postfachservern erforderlich.

Die ausgewählte Serverhardware und das Speichermodell führen möglicherweise auch zu einer Anpassung der Anzahl von Postfächern oder Datenbankkopien, die pro Server bereitgestellt werden können, wodurch die Gesamtanzahl von Postfachservern beeinflusst wird.

Server mit mehreren Serverrollen im Vergleich zu Servern mit einer eigenständigen Serverrolle

In Exchange Server 2007 müssen sich die Clientzugriffs- und Hub-Transport-Serverrollen auf Servern befinden, die separat von Postfachclusterservern sind. In Exchange 2010 gibt es keine Postfachclusterserver mehr, sodass diese Einschränkung nicht mehr gilt. Clientzugriffs- und Hub-Transport-Serverrollen können auf DAG-Mitgliedern gehostet werden und bieten so verbesserte Bereitstellungsoptionen.

Bei der Bereitstellung von Servern mit mehreren Serverrollen (Postfach-, Clientzugriffs- und Hub-Transport-Serverrollen auf demselben Server) werden die meisten Architekturen vereinfacht. Außer den Edge-Transport- und Unified Messaging-Servern können alle Exchange 2010-Server identisch sein. Für diese Server kann dieselbe Hardware, dieselbe Vorgehensweise bei der Softwareinstallation sowie dieselben Konfigurationsoptionen eingesetzt werden. Diese serverübergreifende Konsistenz vereinfacht die Verwaltung der Exchange-Implementierung.

Server mit mehreren Serverrollen (in hoch skalierten Umgebungen) bieten eine effizientere Verwendung von Servern mit hoher Kernanzahl, die mit einer besseren Megazyklusfunktionalität ausgestattet sind. Jede Rolle verfügt, wenn sie einzeln bereitgestellt wird, über ein empfohlenes Maximum von zwei belegten Prozessorsockets. Bei der Kombination von Rollen liegt das empfohlene Maximum für Prozessorsockets bei vier. Server können größere Arbeitslasten auffangen, wodurch sich die Gesamtanzahl an Servern in der Organisation verringert. Durch die Bereitstellung weniger Server reduzieren sich die Kosten für die Verwaltung dieser Server, da dank eines Servers mit mehreren Serverrollen statt wiederkehrenden Betriebskosten nur eine einmalige Ausgabe anfällt. Eine reduzierte Anzahl von Servern führt zu erheblichen Einsparungen bei den Kosten für Energie und Kühlung sowie beim Platzbedarf im Rechenzentrum, wodurch die wiederkehrenden Betriebskosten weiter gesenkt werden können.

Obwohl das Konzept mit mehreren Serverrollen effizient ist, können Server mit einer eigenständigen Serverrolle unter Umständen doch die bessere Lösung sein. Umgebungen mit einer eigenständigen Serverrolle eignen sich beispielsweise für bestimmte virtualisierte Umgebungen oder bei bestimmten Hardwarearchitekturen (z. B. einer Blade-Server-Infrastruktur, in der die Hardware nicht angemessen isoliert werden kann).

Bei der Bereitstellung von Servern mit mehreren Serverrollen müssen Sie den Prozessor und die Speicherarchitektur entsprechend konzipieren. Bezüglich des Prozessors sollten Sie sicherstellen, dass die Postfachserverrolle nicht mehr als 40 Prozent der verfügbaren Megazyklen im Fehlermodus beansprucht, sodass 40 Prozent für die Hub-Transport- und Clientzugriffsserverrolle verfügbar sind. Befolgen Sie die Arbeitsspeicherempfehlungen in Grundlegendes zum Postfachdatenbankcache, um sicherzustellen, dass ausreichend Arbeitsspeicher für alle Serverrollen verfügbar ist.

Weitere Informationen finden Sie unter Grundlegendes zur Konfiguration mehrerer Serverrollen bei der Kapazitätsplanung.

Zurück zum Seitenanfang

Planen des Layouts von Datenbankkopien

Teil des Hochverfügbarkeitsentwurfs ist ein ausgeglichenes Layout von Datenbankkopien. Die folgenden Entwurfsgrundsätze sollten bei der Planung des Layouts der Datenbankkopien berücksichtigt werden:

• Stellen Sie sicher, dass Mehrfachfehler von Datenbankkopien einer bestimmten Postfachdatenbank minimiert werden, indem Sie jede Kopie isolieren. Platzieren Sie beispielsweise nicht mehr als eine einzelne Datenbankkopie einer bestimmten Postfachdatenbank in einem Server-Rack oder einem Speicherarray. Ansonsten tritt ein Rack- oder Arrayfehler auf, der wiederum zu einem Fehler bei mehreren Kopien derselben Datenbank führt, wodurch die Verfügbarkeit der Datenbank beeinträchtigt wird.

• Die Datenbankkopien müssen konsistent und gleichmäßig verteilt sein, sodass sichergestellt ist, dass auch die aktiven Postfachdatenbanken nach einem Fehler gleichmäßig verteilt werden. Die Summe der Aktivierungseinstellungen jeder Datenbankkopie auf einem bestimmten Server muss gleich oder fast gleich sein, da dies zu einer fast gleichmäßigen Verteilung nach einem Fehler führt, sofern die Replikation fehlerfrei und aktuell ist.

Weitere Informationen finden Sie unter Entwurf des Layouts von Datenbankkopien.

Zurück zum Seitenanfang

Planen der Sicherungsmodellarchitektur

In Exchange 2010 sind verschiedene Funktionen und Architekturänderungen enthalten, die bei ordnungsgemäßer Bereitstellung und Konfiguration einen systemeigenen Datenschutz ermöglichen, der die Notwendigkeit beseitigt, herkömmliche Sicherungen von Ihren Daten zu erstellen. Sie können anhand der folgenden Tabelle entscheiden, ob Sie weiterhin ein herkömmliches Sicherungsmodell verwenden müssen oder die Funktionen für den systemeigenen Datenschutz in Exchange 2010 implementieren können.

Problem	Risikominderung
Softwarefehler	Ausfallsicherheit von Postfächern (mehrere Datenbankkopien)
Hardwarefehler	Ausfallsicherheit von Postfächern (mehrere Datenbankkopien)
Ausfälle des Standorts oder des Rechenzentrums	Ausfallsicherheit von Postfächern (mehrere Datenbankkopien)
Unbeabsichtigtes oder böswilliges Löschen von Elementen	Zeitfenster für die Wiederherstellung einzelner Elemente und die Aufbewahrung gelöschter Elemente, das die SLAs für die Wiederherstellung von Elementen erfüllt oder überschreitet
Szenarien mit physikalischen Beschädigungen	Wiederherstellung einzelner Seiten (hochverfügbare Datenbankkopien)
Szenarien mit logischen Beschädigungen	Wiederherstellung einzelner Elemente Kalenderreparatur-Assistent Verschieben von Postfächern Cmdlet New-MailboxRepairRequest Zeitpunktsicherung
Administrative Fehler	Zeitpunktsicherung
Automatisierungsfehler	Zeitpunktsicherung
Nicht autorisierte Administratoren	Zeitpunktsicherung (isoliert)
Unternehmens- und gesetzliche Kompatibilitätsanforderungen	Zeitpunktsicherung (isoliert)

Logische Beschädigungen stellen ein typisches Szenario dar, in dem eine Zeitpunktsicherung erforderlich ist. In Exchange 2010 sind jedoch verschiedene Optionen verfügbar, die die Notwendigkeit einer Zeitpunktsicherung reduzieren.

• Wenn der Benutzer bestimmte Eigenschaften eines Elements in einem beliebigen Postfachordner ändert, wird bei der Wiederherstellung einzelner Elemente eine Kopie des Elements im Ordner "Wiederherstellbare Elemente" gespeichert, bevor die Änderung in die Datenbank geschrieben wird. Wenn die Änderung der Nachricht zu einer fehlerhaften Kopie führt, kann das Originalelement wiederhergestellt werden.

• Der Kalenderreparatur-Assistent erkennt und korrigiert Inkonsistenzen, die für einzelne und wiederkehrende Besprechungseinträge für Postfächer auf diesem Postfachserver auftreten, sodass Empfänger keine Besprechungsankündigungen verpassen oder unzuverlässige Besprechungsinformationen erhalten.

• Während des Verschiebens von Postfächern erkennt der Microsoft Exchange-Postfachreplikationsdienst beschädigte Elemente und verschiebt diese Elemente nicht in die Zielpostfachdatenbank.

• In Exchange 2010 Service Pack 1 (SP1) wird das Cmdlet New-MailboxRepairRequest eingeführt, mit dessen Hilfe Beschädigungen von Suchordnern, Elementanzahlen und Ordneransichten sowie Probleme bei über- und untergeordneten Ordnern behoben werden können.

Eine Zeitpunktsicherung kann entweder eine herkömmliche Sicherung oder eine verzögerte Datenbankkopie sein. Beide Lösungen stellen dieselben Funktionalitäten bereit. Die Auswahl zwischen den beiden Optionen hängt von Ihren SLAs für die Wiederherstellung ab. Die SLAs für die Wiederherstellung definieren den angestrebten Wiederherstellungszeitpunkt (wenn ein Notfall eintritt, müssen die Daten innerhalb eines bestimmten Zeitraums wiederhergestellt werden) und die Aufbewahrungsdauer für die Sicherungen. Wenn die SLAs für die Wiederherstellung 14 Tage oder weniger vorgeben, kann eine verzögerte Datenbankkopie verwendet werden. Wenn die SLAs für die Wiederherstellung mehr als 14 Tage vorgeben, muss eine herkömmliche Sicherung verwendet werden. Bei nicht autorisierten Administratoren und in Szenarien mit Unternehmens- und gesetzlicher Kompatibilität wird die Zeitpunktsicherung normalerweise getrennt von der Messaginginfrastruktur und dem Messaging-IT-Personal verwaltet, was eine herkömmliche Sicherungslösung notwendig macht.

Wenn Sie sich dafür entscheiden, die Zeitpunktsicherung beizubehalten, ändern sich möglicherweise mehrere Aspekte des Entwurfs:

• Die Bereitstellung von verzögerten Datenbankkopien hat Auswirkungen auf den Speicher. Für die Transaktionsprotokolle auf den verzögerten Datenbankkopien muss aufgrund der ReplayLagTime-Einstellungen zusätzlicher Speicherplatz zugewiesen werden. Außerdem kann die Platzierung der verzögerten Datenbankkopie Ihre Speicherarchitektur beeinflussen. (Ausführliche Informationen finden Sie unter "Planen der Speichermodellarchitektur" weiter unten in diesem Thema.)

• Die Bereitstellung einer herkömmlichen Sicherungslösung hat in Abhängigkeit von der VSS-Lösung (Volumeschattenkopie-Dienst) Auswirkungen auf das Layout der logischen Gerätenummer (LUN), da für hardwarebasierte VSS-Klonlösungen zwei LUNs pro Datenbankarchitektur erforderlich sind.

Je nach Speicherarchitektur ist für die Verwendung herkömmlicher Sicherungslösungen möglicherweise eine deutliche Verringerung der gewünschten Benutzerpostfachgrößen notwendig, um die SLAs für Sicherungs- und Wiederherstellungszeiträume zu erfüllen.

Bei der Bereitstellung der Exchange-Funktionen für den systemeigenen Datenschutz können Sie die Umlaufprotokollierung auf den Postfachdatenbanken aktivieren. Bei aktivierter Umlaufprotokollierung muss ausreichend Kapazität im System vorhanden sein, sodass die Lösung Ereignisse, die das Abschneiden von Protokollen verhindern, verarbeiten kann. Es muss ausreichend Kapazität für die Transaktionsprotokolle von mindestens drei Tagen vorhanden sein (ausschließlich Anforderungen für verzögerte Kopien). Weitere Informationen zur Funktionsweise der Umlaufprotokollierung bei fortlaufender Replikation finden Sie unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.

Weitere Informationen zur Planung von Sicherungen finden Sie unter:

• Grundlegendes zur Exchange 2010-LUN-Architektur

• Grundlegendes zu Postfachdatenbank- und Protokollkapazität

• Grundlegendes zur Kalenderreparatur

• Grundlegendes zu wiederherstellbaren Elementen

Zurück zum Seitenanfang

Planen der Speichermodellarchitektur

Exchange 2010 bietet Flexibilität beim Speicherentwurf. Exchange 2010 umfasst Verbesserungen bei der Leistung, der Zuverlässigkeit und der Hochverfügbarkeit, wodurch Organisationen Exchange auf einer Vielzahl von Speichergeräten ausführen können. Infolge der Verbesserungen der Datenträger-E/A, die in Exchange 2007 eingeführt wurden, ist für die neueste Version von Exchange weniger Speicherleistung erforderlich, und die Toleranz bei Speicherfehlern ist höher.

Wählen Sie eine Speicherplattform aus, die sicherstellt, dass Kapazitäts- und E/A-Anforderungen ausgeglichen sind und dass die Lösung eine ausreichende Datenträgerlatenz und eine hohe Benutzerfreundlichkeit aufweist.

RAID oder JBOD

Bestimmen Sie, ob die Speicherplattform mit RAID-Technologie oder einem JBOD-Ansatz implementiert werden soll (vorausgesetzt, die Speicherplattform erlaubt JBOD-Konfigurationen). Im Rahmen von Exchange bedeutet JBOD, dass sowohl die Datenbank als auch die zugeordneten Protokolle auf einem einzelnen Datenträger gespeichert werden. Bei der Bereitstellung auf mehreren Festplatten (JBOD) müssen Sie mindestens drei hochverfügbare Datenbankkopien bereitstellen. Die Verwendung eines einzelnen Datenträgers führt zu einer einzelnen Fehlerquelle, da bei einem Ausfall des Datenträgers die darauf befindliche Datenbankkopie verloren geht. Ein Minimum von drei Datenbankkopien sorgt für Fehlertoleranz, da bei einem Ausfall der Kopie (oder des Datenträgers) zwei zusätzliche Kopien vorhanden sind. Die Platzierung von drei hochverfügbaren Datenbankkopien und die Verwendung verzögerter Datenbankkopien müssen jedoch beim Speicherentwurf berücksichtigt werden. Die folgende Tabelle enthält Richtlinien für RAID und JBOD.

RAID oder JBOD

Rechenzentrumsserver	Zwei hochverfügbare Kopien (gesamt)	Drei hochverfügbare Kopien (gesamt)	Mindestens zwei hochverfügbare Kopien pro Rechenzentrum	Eine verzögerte Kopie	Mindestens zwei verzögerte Kopien pro Rechenzentrum
Primäre Rechenzentrumsserver	RAID	RAID oder JBOD (zwei Kopien)	RAID oder JBOD	RAID	RAID oder JBOD
Sekundäre Rechenzentrumsserver	RAID	RAID (eine Kopie)	RAID oder JBOD	RAID	RAID oder JBOD

Bei der Bereitstellung auf mehreren Festplatten (JBOD) für primäre Rechenzentrumsserver sind mindestens drei hochverfügbare Kopien in der DAG erforderlich. Wenn Sie verzögerte Kopien und hochverfügbare Datenbankkopien auf demselben Server kombinieren (wenn Sie also keine dedizierten Server für die verzögerten Datenbankkopien verwenden), sind mindestens zwei verzögerte Datenbankkopien erforderlich.

Auf sekundären Rechenzentrumsservern, die JBOD verwenden, sollten mindestens zwei hochverfügbare Datenbankkopien im sekundären Rechenzentrum bereitgestellt werden. Der Verlust einer Kopie im sekundären Rechenzentrum führt nicht zu einem erneuten Seeding im Fernnetz oder einer einzelnen Fehlerquelle bei der Aktivierung des sekundären Rechenzentrums. Wenn Sie verzögerte Datenbankkopien und hochverfügbare Datenbankkopien auf demselben Server kombinieren (wenn Sie also keine dedizierten Server für die verzögerten Datenbankkopien verwenden), sind mindestens zwei verzögerte Datenbankkopien erforderlich.

Bei dedizierten Servern für die verzögerten Datenbankkopien müssen mindestens zwei verzögerte Datenbankkopien im Rechenzentrum vorhanden sein, um JBOD verwenden zu können. Andernfalls führt der Verlust eines Datenträgers zum Verlust der verzögerten Datenbankkopie sowie zum Verlust des Schutzmechanismus.

Weitere Informationen finden Sie unter Grundlegendes zur Speicherkonfiguration.

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.