Datenbank Management

Haben Sie schon mal einen Exchange CCR-Cluster für 5000 Benutzer mit bis zu 2 GB pro Postfach dimensioniert? Eine kurze Rechnung zeigt schon, dass man damit im extremen Fall auf 10 Terabyte (TB) Daten kommt, die man auf 50 Datenbanken a 200 GB verteilen muss. Losgelöst von der der reinen Datenmenge, die natürlich auch gesichert und performant betrieben werden will, wird kaum jemand auf den Gedanken kommen, einen Server mit dieser Kapazität aufzustellen, wenn dieser Platz nicht auch sofort benutzt wird. Fakt ist aber, dass man heute einen Server meist nicht von Anfang an ausschöpft, sondern man eben Wachstumsreserven einplant. Gerade bei Festplattenspeicher in Verbindung mit einem SAN ist es ja relativ einfach die verfügbare Kapazität bei Bedarf zu erweitern.

Aber auch wenn eine Erweiterung sehr einfach ist, muss man sich doch die ein oder andere Regel zur Hand nehmen, um auch für Geschäftsführung und SAN-Admin klare Vorgaben für die nächste Investition zu haben. Ansonsten gehen dem Server die Bytes aus und niemand fühlt sich verantwortlich.

Beispielkonzept

Ich möchte daher hier einfach einen Entwurf darstellen, welchen Sie als Ansatz für ein eigenes Konzept hernehmen können. Ziel ist die sinnvolle Verteilung von Datenbanken auf LUNs und die Kontrolle deren Wachstums. Denn eines ist sicher: Exchange beendet eine Datenbank, wenn auf der Festplatte kein Platz mehr ist. Dies gilt es zu verhindern, da eine "Erweiterung" der Festplatte zwar einfach erscheint, aber das schöne Konzept der LUNs und Sicherungen per Schattenkopie (VSS) natürlich durcheinander bringen kann.

Gehen wir wieder von der ersten Annahme aus, dass sehr viele Mailboxen mit viel Platzbedarf auf einem CCR-Cluster in Datenbanken bis 200 GB angelegt werden und nicht alle Datenbanken von Anfang an vorhanden sind.

  • Postfachgröße bis 2 GB
    Wir gehen von bis zu 2 GB Postfächern aus, auch wenn das für die weitere Betrachtung nicht ausschlaggebend ist
  • Datenbankgröße max. 200 GB
    Dieses Limit wird auch in vielen Microsoft Dokumenten als sinnvolle Obergrenze in Verbindung mit LCR/CCR genannt. Es ist aber keine Beschränkung von Exchange oder Windows sondern eher an den SLA für eine Wiederherstellung orientiert. Missverstehen Sie dies also nicht als absolute Zahl. Die Größe der Datenbank kann man übrigens per Registrierung vorgeben, so dass Exchange nicht die Festplatte vollschreibt.
  • LUN-Größe:250 GB
    Ich  mache es mir mal einfach und lege jede Datenbank auf eine eigene LUN, die mit 250GB (also 50 GB Reserve) dimensioniert ist. Das ist sicher diskussionsfähig. Man könnte auch eine LUN mit 1TB anlegen und darauf 4 Datenbanken a 200 GB anlegen und damit 200 GB "Reserve" für Defragmentierungen etc. einplanen. Legt man die Datenbanken in eigene Verzeichnisse kann man über Windows 203 R2-Quotas ein Wachstum einfach kontrollieren und beschränken.
  • Oberer Füllstand: 90% (180 GB)
    Hiermit ist die Grenze erreicht, den eine Datenbank nicht überschreiten darf. Erreicht eine Datenbank diesen Füllstand, dann müssen Postfächer auf andere Datenbanken umgezogen werden oder die Inhalte über ein Archiv reduziert werden.
  • Unterer Füllstand: 70% (140 GB)
    Datenbanken, die unter 70% ihrer Nennkapazität belegt sind, können mit weiteren Postfächern befüllt werden.

Gerade am Anfang wird man den unteren Füllstand etwas niedriger ansetzen, da bei einer Migration die Postfächer am Anfang meist schneller anwachsen.

Whitespace und Postfachgrößen

Um den Füllstand zu müssen und Aktionen anzustoßen, muss man drei Werte erfassen:

  • Größe der EDB-Datei
    Diese Größe sagt leider nicht viel über den tatsächlichen Füllgrad aus, sondern beschreibt nur die maximale Größe, die die Datenbank einmal hatte. Diese Größe ist aber leicht zu müssen.
  • Größe der Mailboxen
    Über WMI (Exchange 2003) oder PowerShell (Exchange 2007 Get-Mailboxstatistics) kann man sehr einfach ermitteln, wie groß die Postfächer in einer Datenbank sind. Allerdings sind diese Zahlen nur bedingt tauglich, da Sie nicht anzeigen, wie viel noch "frei" ist, sondern nur wie viel für diesen Benutzer belegt werden. Man kann allerdings näherungsweise die Datenbankgröße nehmen und die Summer der belegten Bytes davon abziehen um den freien Platz zu ermitteln.
  • Whitespace
    Exchange selbst führt regelmäßig eine "Online Defragmentierung" durch, bei der nebeneinander liegende leere Seiten zu größeren Blöcken zusammengefasst und wieder als "Frei" gekennzeichnet werden. Dieser Platz wird von der Datenbank dann wieder für die Ablage von neuen Objekten genutzt. Allerdings kann man diesen Wert nicht per WMI oder PERFMON abfragen, sondern muss im Eventlog nach der entsprechenden Meldung suchen. Allerdings enthält dieser Wert nicht alle freien Bereiche und ist daher etwas unscharf
Event Type:	Information
Event Source:	MSExchangeIS Public Store
Event Category:	General 
Event ID:	1221
Description:
The database "First Storage Group\Public Folder Store (SRV01)" has 35 
megabytes of free space after online defragmentation has terminated. für more information, click http://www.microsoft.com/contentredirect.asp. 

Die Aufnahme dieser Wert erfolgt allein mit dem Ziel, ein Wachstum einer Datenbank, die schon 200 GB auf der Festplatte belegt, vorherzusehen um durch Gegenmaßnahmen (Archivierung, Verlagerung von Mailboxen) einleiten zu können. Aufgrund der ungenauigkeit bzw. des zeitlichen Verzugs ist es jedoch nicht möglich, sekundengenau zu reagieren.

DB Management

Die 90% Markierung bedeutet, dass bis zum nächsten müssen und Gegensteuern ca. 20 GB in die Datenbank kommen dürfen, um aus einer 180 GB Datenbank eine 20 GB Datenbank zu machen.

Einfach Logik

Ich habe kein Programm zur Hand, welches diese Grenzwerte überwacht und bei Engpässen auch noch die Postfächer auf andere Datenbanken überträgt. Es gibt aber Produkte im Bereich Provisioning, die ähnliche Kennzahlen zur Neuanlage von Benutzern in bestehende Datenbanken hernehmen. Technisch ist es sicher möglich, auf der einen Seite die Belegung der Datenbank zu ermitteln und dann die Benutzer zu verschieben. Ich kann mit sogar vorstellen, dass dies mit wenige PowerShell-Zeilen zu erreichen wäre. Die Logik dahinter ist aber schnell erzählt:

  • Variante 1: Jede Stunde die Mailboxgrößen addieren. Wenn Summe > 180 GB dann Postfächer moven
  • Variante 2: Wenn Datenbank >200 GB and Whitespace Meldung <20 GB dann 20 GB Mailboxen moven und einen Tag abwarten.

Auf die Frage, welcher Weg und welche Grenzen sich in ihrer Umgebung am besten bewähren, kann ich ihnen aber hier auf der MSXFAQ keine abschließende Antwort geben.

Weitere Links