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.

Gegen 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.

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 messen und Aktionen anzustoßen, muss man drei Werte erfassen:

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. 

For 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 Messen 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:

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

Keywords:Konzepte Management Datenbank Größe