Grundlegendes zu Postfachdatenbank- und Protokollkapazität

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

Letztes Änderungsdatum des Themas: 2015-03-09

In diesem Thema werden die Faktoren erläutert, die Sie bei der Planung der Postfachdatenbank und der Protokollkapazität als Bestandteil Ihres Speicherentwurfs für Postfachserver in Microsoft Exchange Server 2010 berücksichtigen sollten.

Postfachdatenbankkapazität

Viele Faktoren beeinflussen die Kapazitätsplanung für Exchange Server 2010-Postfachdatenbanken. In diesem Abschnitt werden folgende Punkte behandelt:

• Postfachspeicherkontingente

• Leerraum in der Datenbank

• Wiederherstellbarer Elemente der Postfachdatenbank

• Tatsächliche Postfachgröße

• Inhaltsindizierung

• Offlinedatenbankwartung

• Wiederherstellungsdatenbank

• Datenbankgröße

• Overhead für das Datenbankwachstum

Postfachspeicherkontingente

Die erste wichtige Kennzahl ist die Begrenzung der Speichergröße, das so genannte Speicherkontingent für Postfächer, das in Ihrem Unternehmen festgelegt ist. Wenn Sie die Datenmenge kennen, die ein Endbenutzer in seinem Postfach speichern darf, können Sie bestimmen, wie viele Benutzerpostfächer der Server unterstützen kann. Auch wenn Postfachspeicherkontingente sich je nach Unternehmensanforderungen ändern können, besteht der erste Schritt bei der Bestimmung der erforderlichen Kapazität für die Postfachdatenbank darin, ein bestimmtes Postfachspeicherkontingent anzustreben.

Wenn Sie beispielsweise einen Server mit 5.000 Benutzerpostfächern zu je 250 MB verwenden, benötigen Sie mindestens 1,25 TB Festplattenspeicher, abgesehen vom Speicherplatzbedarf für wiederherstellbare Elemente. Wenn für Postfachspeicherkontingente keine Begrenzung eingerichtet ist, wird die Abschätzung der Datenbankkapazität erheblich erschwert. Bei Postfachspeicherkontingenten für Exchange 2010 muss der Speicherplatz für das primäre Postfach und das Postfach für das persönliche Archiv (falls dies verwendet wird) berücksichtigt werden. Weitere Informationen finden Sie unter Verwalten von Postfachservern und Verwalten des persönlichen Archivs.

Leerraum in der Datenbank

Die Datenbankgröße auf dem physischen Datenträger entspricht nicht nur der Anzahl der Benutzer multipliziert mit dem Postfachspeicherkontingent. Wenn die Mehrzahl der Benutzer ihr Postfachspeicherkontingent nicht voll ausschöpft, belegen die Datenbanken weniger Speicherplatz, und Leerraum stellt kein Kapazitätsproblem dar. Die Datenbank selbst weist stets freie Seiten auf, also Leerraum, der überall verteilt ist. Während einer Datenbankwartung im Hintergrund werden die zum Entfernen aus der Datenbank markierten Objekte entfernt, wodurch die entsprechenden Seiten freigegeben werden. Der Prozentsatz an Leerraum ändert sich ständig aufgrund des fortlaufenden Onlinedefragmentierungsprozesses.

Sie können die Menge an Leerraum in der Datenbank abschätzen, wenn Sie die Menge an E-Mails kennen, die Benutzer mit Postfächern in der Datenbank senden und empfangen. Wenn es z. B. 100 Postfächer mit 2 GB (insgesamt 200 GB) in einer Datenbank gibt, in der die Benutzer durchschnittlich 10 MB an E-Mails pro Tag empfangen, dann beträgt der Umfang des Leerraums ungefähr 1 GB (100 Postfächer × 10 MB pro Postfach). Die Menge an Leerraum kann diesen Annäherungswert überschreiten, wenn die Datenbankwartung im Hintergrund nicht vollständig abgeschlossen werden kann.

Zurück zum Seitenanfang

Wiederherstellbarer Elemente der Postfachdatenbank

Jede Datenbank besitzt einen Dumpster, in dem mittels Soft-Deletion gelöschte Objekte gespeichert werden. Standardmäßig werden mit Soft-Deletion gelöschte Elemente 14 Tage, Kalenderelemente 120 Tage in Exchange 2010 gespeichert.

Außerdem bietet Exchange 2010 auch die Möglichkeit, das endgültige Löschen von Daten zu verhindern, bevor das Zeitfenster für die Aufbewahrung gelöschter Elemente verstrichen ist. Diese Funktionalität wird als Wiederherstellung einzelner Elemente bezeichnet. Die Wiederherstellung einzelner Elemente ist standardmäßig deaktiviert. Wenn die Wiederherstellung einzelner Elemente jedoch aktiviert ist, erhöht sich die Postfachgröße bei einem Zeitfenster für die Aufbewahrung gelöschter Elemente von 14 Tagen um 1,2 Prozent. Für Daten zur Kalenderversionsprotokollierung erhöht sich die Postfachgröße um weitere 3 Prozent. Die Kalenderversionsprotokollierung ist standardmäßig aktiviert.

Die Formel zur Bestimmung der Größenanforderungen für den Dumpster zur Aufbewahrung gelöschter Elemente für 14 Tage bei aktivierter Wiederherstellung einzelner Elemente und Kalenderversionsprotokollierung lautet folgendermaßen:

Dumpstergröße = (Täglich eingehende/ausgehende E-Mail x Durchschnittliche Nachrichtengröße x Zeitfenster für die Aufbewahrung gelöschter Elemente) + (Postfachkontingentgröße x 0,012) + (Postfachkontingentgröße x 0,03)

Wenn die Postfachgröße beispielsweise 2 GB beträgt, sind bei Aktivierung der Wiederherstellung einzelner Elemente mit einer Aufbewahrung gelöschter Elemente für 14 Tage zusätzlich 25 MB Speicherplatz erforderlich. die Kalenderprotokollierfunktion erfordert außerdem zusätzliche 61 MB.

Weitere Informationen hierzu finden Sie in den folgenden Themen:

• Entwurfsbeispiel für die Exchange 2010-Postfachserverrolle

• Grundlegendes zu wiederherstellbaren Elementen

• Verwalten wiederherstellbarer Elemente

• Grundlegendes zur Kalenderreparatur

• Verwalten der Kalenderreparatur

Tatsächliche Postfachgröße

Mit der Zeit erreichen Benutzerpostfächer das Postfachspeicherkontingent, weshalb ein E-Mail-Volumen, das der eingehenden E-Mail entspricht, gelöscht werden muss, um innerhalb des Postfachspeicherkontingents zu bleiben. Diese Anforderung hat zur Folge, dass der Dumpster die maximale Größe erreicht, die der Menge an täglich gesendeten und empfangenen E-Mails multipliziert mit der Anzahl der Tage innerhalb des Zeitfensters für die Aufbewahrung gelöschter Elemente entspricht. Wenn die Mehrzahl der Benutzer das Speicherkontingent noch nicht erreicht hat, wird nur ein Teil der eingehenden/ausgehenden E-Mails gelöscht. Daher verteilt sich das Wachstum auf den Dumpster und das anwachsende Postfach.

Zum Bestimmen der Datenbankgröße unter Verwendung eines Postfachs mit 2 GB, ohne die Funktion für persönliche Archive zu verwenden, lesen Sie den Abschnitt "Kapazitätsanforderungen für Postfächer" im Thema Entwurfsbeispiel für die Exchange 2010-Postfachserverrolle.

Nachdem Sie die geplante tatsächliche Postfachgröße bestimmt haben, können Sie diesen Wert verwenden, um die maximale Anzahl von Benutzern pro Datenbank zu ermitteln. Teilen Sie die voraussichtliche Postfachgröße durch die empfohlene Datenbankgröße. Anhand dieses Werts können Sie auch ermitteln, wie viele Datenbanken für die geplante Benutzeranzahl erforderlich sind, wobei angenommen wird, dass die Datenbanken vollständig aufgefüllt sind. Beachten Sie, dass Sie aufgrund der nicht transaktionalen E/A oder wegen der Hardwarebeschränkungen möglicherweise die Anzahl der Benutzer ändern müssen, die einem einzelnen Server zugeordnet sind. Manche Administratoren bevorzugen die Verwendung mehrerer Datenbanken, um die Datenbankgröße noch weiter zu reduzieren. Dieser Ansatz ist hilfreich für Sicherungs- und Wiederherstellungsfenster, führt jedoch zu einem komplexeren Verwaltungsaufwand für eine größere Anzahl von Datenbanken pro Server.

Inhaltsindizierung

Bei der Inhaltsindizierung wird ein Index oder Katalog erstellt, mit dessen Hilfe die Benutzer ihre E-Mail-Objekte schnell und einfach durchsuchen können, anstatt das Postfach manuell zu durchlaufen. Exchange 2010 erstellt einen Index, der ungefähr 10 Prozent der gesamten Datenbankgröße einnimmt und sich auf derselben LUN befindet wie die Datenbank. Eine zusätzliche Kapazität von 10 Prozent muss bei der Größe der Datenbank-LUN für die Inhaltsindizierung berücksichtigt werden.

Zurück zum Seitenanfang

Offlinedatenbankwartung

Eine Datenbank, die offline komprimiert werden muss, benötigt Kapazität, die der Größe der Zieldatenbank plus 10 Prozent entspricht. Unabhängig davon, ob Sie ausreichend Speicherplatz für eine einzelne Datenbank oder einen Sicherungssatz zuordnen, muss für die Durchführung dieser Operationen zusätzlicher Speicherplatz verfügbar sein.

Wiederherstellungsdatenbank

Wenn Sie im Rahmen Ihrer Pläne für die Notfallwiederherstellung eine Wiederherstellungsdatenbank verwenden möchten, muss ausreichend Kapazität zur Verarbeitung aller Datenbanken verfügbar sein, die gleichzeitig auf dem jeweiligen Server wiederhergestellt werden sollen. Weitere Informationen finden Sie unter Wiederherstellungsdatenbanken.

Datenbankgröße

Die Datenbankgröße legt letztlich fest, wie viele Postfächer innerhalb der einzelnen Datenbanken und wie viele Datenbanken bereitgestellt werden. Die bereitgestellte Datenbankgröße hängt von mehreren Faktoren ab:

• Sicherungs-/Wiederherstellungs-SLAs (Service Level Agreements, Vereinbarungen zum Servicelevel)   Die Datenbankgröße gibt vor, wie schnell Sie die Daten innerhalb eines angemessenen Zeitraums sichern und wiederherstellen können.

• Architektur für hohe Verfügbarkeit   Wenn Sie mehrere Datenbankkopien einsetzen möchten, können Sie die Datenbanken mit einer Größe von 2 TB entwerfen, da Ihre Kopien im Hinblick auf Wiederherstellungsverfahren die erste Schutzmaßnahme darstellen.

• Speicherarchitektur   Wenn die Bereitstellung auf JBOD-Speicher erfolgen soll (beide Datenbanken und die zugehörigen Transaktionsprotokolle befinden sich auf einem Datenträger), gibt die Größe des verwendeten Datenträgers die maximale Datenbankgröße vor. Beispielsweise müssen Sie auf einem 1-TB-Datenträger (mit einer formatierten Kapazität von etwa 917 GB) auch Speicherplatz für Transaktionsprotokolle und den Inhaltsindex berücksichtigen und sicherstellen, dass nicht der gesamte verfügbare Speicherplatz aufgebraucht wird.

Overhead für das Datenbankwachstum

Nachdem alle Faktoren berücksichtigt und berechnet wurden, empfiehlt es sich, einen zusätzlichen Overheadfaktor von 20 Prozent für die Datenbank-LUN (Logical Unit Number) einzuplanen. Dieser Wert umfasst andere Daten in der Datenbank, die beim Berechnen von Postfachgrößen und Leerraum nicht unbedingt offensichtlich sind.

Zurück zum Seitenanfang

Protokollkapazität

Die Transaktionsprotokolldateien enthalten eine Aufzeichnung aller vom Datenbankmodul durchgeführten Transaktionen. Alle Transaktionen werden zuerst in das Protokoll und anschließend ganz allmählich in die Datenbank geschrieben. Im Gegensatz zu Exchange Server 2003 wurde die Größe der Transaktionsprotokolldateien in Exchange 2010 von 5 MB auf 1 MB reduziert. Diese Änderung ist erfolgt, um die fortlaufenden Replikationsfunktionen zu unterstützen und den Umfang des Datenverlusts zu minimieren, falls das primäre Speichermedium ausfallen sollte.

Anhand der folgenden Tabelle können Sie die Anzahl der auf einem Exchange 2010-Postfachserver generierten Transaktionsprotokolle bei einer durchschnittlichen Nachrichtengröße von 75 KB einschätzen.

Der Wert für die Anzahl der pro Tag generierten Transaktionsprotokolle basiert auf dem ausgewählten Nachrichtenprofil und der durchschnittlichen Nachrichtengröße. Er gibt an, wie viele Transaktionsprotokolle pro Postfach und Tag generiert werden. Die Anzahl der Protokollgenerierungen pro Nachrichtenprofil werden durch folgende Faktoren beeinflusst:

• Nachrichtengröße

• Menge der gesendeten/empfangenen Daten

• Wartungsvorgänge zur Erhaltung der Datenbankintegrität

• Datensatzverwaltungsvorgänge

• In einem Postfach gespeicherte Daten, bei denen es sich nicht um Nachrichten handelt (Aufgaben, lokale Kalendertermine, Kontakte)

• Erzwungenes Protokollrollover (ein Mechanismus zum regelmäßigen Schließen der aktuellen Transaktionsprotokolldatei)

Anzahl der für jedes Postfachprofil generierten Transaktionsprotokolle

Anhand der folgenden Richtlinien können Sie nachvollziehen, wie die Nachrichtengröße sich auf die Generierungsrate von Transaktionsprotokollen auswirkt:

• Wenn sich die durchschnittliche Nachrichtengröße auf 150 KB verdoppelt, nehmen die pro Postfach generierten Protokolle um einen Faktor von 1,9 zu. Diese Zahl stellt den Prozentsatz der Datenbank dar, der die Anlagen und Nachrichtentabellen (Nachrichtentexte und Anlagen) enthält.

• Bei einer Verdopplung der Nachrichtengröße auf über 150 KB verdoppelt sich auch die Protokollgenerierungsrate pro Postfach von 1,9 auf 3,8.

Angenommen, Sie erhalten etwa 100 Nachrichten pro Tag:

• Bei einer durchschnittlichen Nachrichtengröße von 150 KB werden pro Postfach 20 × 1,9 = 38 Protokolle generiert.

• Bei einer durchschnittlichen Nachrichtengröße von 300 KB werden pro Postfach 20 × 3,8 = 76 Protokolle generiert.

In den folgenden Abschnitten werden die Faktoren behandelt, die sich auf die Protokollkapazität auswirken:

• Faktoren bei der Sicherung und Wiederherstellung

• Verschieben von Postfächern

• Overheadfaktor für das Protokollwachstum

• Faktoren für hohe Verfügbarkeit

• LUN-Kapazitätsplanung

Faktoren bei der Sicherung und Wiederherstellung

Die Bestimmung der Größe von Protokoll-LUNs hängt zum Teil von Ihrem Sicherungs- und Wiederherstellungsentwurf ab. Wenn Ihr Entwurf beispielsweise zulässt, dass Sie zwei Wochen zurückgehen und alle seitdem generierten Protokolle wiedergeben, benötigen Sie Protokolldateispeicher für zwei Wochen. Wenn Ihr Sicherungsentwurf wöchentliche vollständige und tägliche differenzielle Sicherungen vorsieht, muss die Protokoll-LUN größer als der Protokolldateispeicher für eine gesamte Woche sein, um während der Wiederherstellung sowohl eine Sicherung als auch eine Wiedergabe zu ermöglichen. Die meisten Unternehmen, die eine nächtliche vollständige Sicherung durchführen, ordnen das Zwei- oder Dreifache der erforderlichen Speicherkapazität für die tägliche Protokollgenerierung zu. Dieser Ansatz soll verhindern, dass das Protokolllaufwerk durch einen Sicherungsfehler vollständig belegt wird, wodurch die Bereitstellung der Datenbank aufgehoben würde.

Wenn Sie die Exchange 2010-Funktionen der Datenbankausfallsicherheit und der Wiederherstellung einzelner Elemente als Sicherungsinfrastruktur nutzen möchten (und somit die Umlaufprotokollierung aktivieren), sollten Sie idealerweise sicherstellen, dass das Dreifache der erforderlichen Kapazität für die tägliche Protokollgenerierung zugeordnet wurde. Wenn die Replikation angehalten wird oder mit normalen Parametern nicht funktioniert, ist auf diese Weise gewährleistet, dass die Bereitstellung der Datenbank nicht aufgrund von Abschneidefehlern aufgehoben wird.

Verschieben von Postfächern

Das Verschieben von Postfächern ist ein wichtiger Kapazitätsfaktor bei großen Postfachbereitstellungen. In vielen Großunternehmen wird ein Prozentsatz der Benutzerpostfächer jede Nacht oder einmal pro Woche in andere Datenbanken, auf andere Server oder an andere Standorte verschoben. Wenn dies in Ihrer Organisation der Fall ist, müssen Sie ggf. die Protokoll-LUN mit mehr Kapazität ausstatten, um Postfachverschiebungen zu unterstützen.

Auch wenn der Quellserver die Datensatzlöschvorgänge protokolliert (die klein sind), muss der Zielserver zuerst alle übertragenen Daten in die Transaktionsprotokolle schreiben. Wenn Sie an einem Tag 10 GB an Protokolldateien generieren und einen dreitägigen Puffer von 30 GB eingerichtet haben, führt das Verschieben von 50 Postfächern mit je 2 GB (100 GB) zur vollständigen Belegung der Zielprotokoll-LUN und dadurch zu einer Downtime. In solchen Fällen müssen Sie ggf. den Protokoll-LUNs zusätzliche Kapazität zuordnen, um diese Postfachverschiebungen zu unterstützen.

Overheadfaktor für das Protokollwachstum

Für die meisten Bereitstellungen wird empfohlen, beim Erstellen der Protokoll-LUN die Protokollgröße mit einem Overheadfaktor von 20 Prozent auszustatten (nach Berücksichtigung aller anderen Faktoren), um die erforderliche Kapazität auch bei einer unerwarteten Protokollgenerierung sicherzustellen.

Faktoren für hohe Verfügbarkeit

Hohe Verfügbarkeit beeinflusst die Anforderungen an die Protokollkapazität in dreierlei Hinsicht:

• Anzahl der Datenbankkopien   Die Protokollkapazität des gesamten Systems erhöht sich basierend auf der Anzahl von Datenbankkopien, die in der Hochverfügbarkeitsbereitstellung gewählt wurde. Wenn Sie drei Datenbankkopien auf drei Server verteilt haben, müssen Sie jeden Server mit Protokollkapazität für jede Kopie ausstatten.

• Mechanismus zum Abschneiden von Protokollen   Die hohe Verfügbarkeit in Exchange 2010 mit der Möglichkeit, bis zu 16 Kopien jeder Postfachdatenbank zu verwalten, bietet die Grundlage für die Verwendung der Umlaufprotokollierung der fortlaufenden Replikation als Mechanismus zum Abschneiden/Löschen von Protokollen im Gegensatz zur Ausführung vollständiger/inkrementeller Sicherungen, um die älteren Protokolle abzuschneiden oder zu löschen. Weitere Informationen finden Sie im Abschnitt "Abschneiden von Protokollen ohne Sicherungen" unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung und Hohe Verfügbarkeit und Ausfallsicherheit für Standorte.

• Wiedergabeverzögerung von Datenbankkopien   Die hohe Verfügbarkeit in Exchange 2010 bietet die Option, die Protokollwiedergabe für passive Datenbankkopien zu verzögern (wird pro Kopie konfiguriert). Mithilfe dieser Funktion werden Protokolle mit Verzögerung in verzögerte Datenbankkopien eingespielt. Diese Verzögerung kann zum Schutz gegen Ereignisse nützlich sein, durch die nicht erwünschte Inhalte in alle Datenbankkopien repliziert würden. Die Wiedergabe der Inhalte in der verzögerten Datenbankkopie kann angehalten werden, indem die Wiedergabe unterbrochen wird, bevor die Protokolle mit den unerwünschten Inhalten in der Datenbank wiedergegeben werden.

  Ist die Wiedergabeverzögerung für eine Datenbankkopie aktiviert, ändern sich die Anforderungen an die Protokollkapazität entsprechend. Wenn Sie eine Verzögerung von 14 Tagen konfiguriert haben, müssen Sie Protokolle für 17 Tage einplanen. Die zusätzliche Protokollkapazität ist nur für die Datenbankkopie erforderlich, für die die Verzögerung konfiguriert wurde. Andere Kopien der Datenbank, für die keine Verzögerung festgelegt wurde, stellen normale Anforderungen an die Protokollkapazität.

Weitere Informationen finden Sie unter Grundlegendes zu hoher Verfügbarkeit.

LUN-Kapazitätsplanung

Die Kapazitätsanforderungen für die LUN basieren auf der Größe des Datasets (Datenbank, Transaktionsprotokolle, Inhaltsindex und Wiederherstellungsspeicherplatz) und einigem zusätzlich verfügbaren Speicherplatz. Die meisten Operations Management-Programme sehen Kapazitätsschwellenwerte vor, die eine Warnung ausgeben, sobald eine LUN zu mehr als 80 Prozent ausgelastet ist.

Anhand der folgenden Formel können Sie die ungefähre Größe der LUN bestimmen:

LUN-Kapazität = Datengröße / (1 - Anforderung an den freien Speicherplatz in Prozent)

Wenn Sie beispielsweise eine Datengrößenanforderung von 3000 MB und eine Anforderung an den freien Speicherplatz von 20 Prozent besitzen, muss die LUN, die diese Daten hostet, 3750 MB umfassen.

Verhindern der vollständigen Nutzung des Speicherplatzes für Transaktionsprotokolle

Um zu verhindern, dass der Speicherplatz für Transaktionsprotokolle vollständig belegt wird, müssen Sie zunächst eine Baseline für Ihre Umgebung konfigurieren, mit der Sie die typische Protokollgenerierungsrate pro Tag ermitteln können. Zweitens müssen Sie die Überwachung sowie Aktionen für generierte Warnungen einrichten. Sie sollten folgende Elemente überwachen:

• LUN-Speicherplatz des Transaktionsprotokolls. Richten Sie mehrere Schwellenwerte und verschiedene Warnmechanismen ein. Wenn Sie Ihre Baseline für die typische Protokollgenerierung kennen, können Sie beispielsweise einen Schwellenwert einrichten, bei dem eine Überschreitung der Baseline um 20% protokolliert wird.

• Erfolgreiches Abschließen der Sicherungsvorgänge (wenn Sie nicht den systemeigenen Exchange-Datenschutz verwenden).

• Das Abschneiden von Ereignissen im Anwendungsprotokoll.

• Replikationsintegrität Ihrer Datenbankkopie.

Problembehandlung bei einer nicht erklärbaren Vergrößerung der Transaktionsprotokolle

Informationen zum Beheben einer nicht erklärbaren Vergrößerung der Transaktionsprotokolle finden Sie unter Verwalten des Datenbankprotokollwachstums über das Skript "Troubleshoot-DatabaseSpace.ps1" in der Shell.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.