Postfächer in Exchange gleichmäßig über Datenbanken verteilen


    Tags: , ,

    Datenbank verschiebenWer Exchange mit mehreren Daten­banken betreibt, der sieht sich irgend­wann mit dem Problem kon­frontiert, dass sich die Daten­banken unter­schiedlich füllen und damit den Speicher­platz ungleich aus­lasten. Folgende Scripts mig­rieren die Post­fächer gleich­mäßig auf mehrere DBs und behalten diesen Zustand dann bei.

    Viele Admini­stratoren stehen vor der Herausforderung, die Datenbanken möglichst gleich groß zu halten, damit sich die Datenträger des jeweiligen Exchange-Servers nicht ungleichmäßig füllen. Dies scheint allerdings ein unmögliches Unterfangen zu sein, da Postfächer ständig und auch verschieden schnell wachsen.

    Zwar kann hier mit Speicher­platz­kontingenten gearbeitet werden, es bleibt aber trotzdem der Faktor, dass innerhalb dieser Grenzen die Postfächer wachsen. Zudem darf die Personal­fluktuation nicht außer Acht gelassen werden.

    Bessere Ausnutzung von Speicherplatz

    Gleich große Datenbanken bieten den Vorteil, dass die Leistung des Exchange-Servers besser verteilt wird, das darunter­liegende Storage kann die Last und den Speicherplatz ebenfalls besser managen und auch Backup bzw. Recovery profitieren davon.

    Wenn die Exchange-Server in einer Database Availibility Group (DAG) betrieben werden, dann verdoppelt sich der Speicher­verbrauch, da jede Datenbank eine Failover-Kopie benötigt.

    Ein weiteres Problem bei einer DAG ist die Verteilung der Datenbanken zwischen mehreren Exchange-Servern. Hier kann es passieren, dass ein Laufwerk auf einem Server viel freien Speicher­platz aufweist, dieser sich aber aufgrund der Verteilung der Daten­banken nicht nutzen lässt.

    Die Entstehung unterschiedlicher großer Datenbanken kann unterschiedliche Gründe haben:

    • Sie wurden nach unterschiedlichen Speicher­kontingenten aufgebaut
    • Sie wurden für verschiedene Firmen erstellt, bei der jede ihre eigene Datenbank hat
    • Die Postfächer in den Datenbanken sind unterschiedlich gewachsen

    Speicherverbrauch berechnen

    Bei der Speicher­platz­belegung einer Exchange-Datenbank, kommt es auf die tat­sächliche Größe und den Whitespace der Datenbank an. Letzterer entsteht etwa immer, wenn ein Objekt von einer Datenbank in eine andere verschoben wird. Das reduziert nicht die Größe der Quell-DB, sondern der frei gewordene Platz wird als Whitespace markiert und danach wieder aufgefüllt.

    Den gesamten Speicherbedarf kann man mit folgendem PowerShell-Befehl berechnen:

    Get-MailboxDatabase -Status |
    select name,@{Name='DBSize';Expression={$_.DatabaseSize.ToMb()}}, `
    @{Name='AvailableNewMbxSpaceMb';Expression={$_.AvailableNewMailboxSpace.ToMb()}}

    Ausgabe des Scripts zur Berechnung des Speicherplatzes, den die Exchange-Datenbanken verbrauchen.

    In meinem Beispiel ist hier schon ein leichtes Ungleichgewicht bei der Speicher­platz­belegung zu erkennen.

    Wachstum von Datenbank kontrollieren

    Man kann eine Exchange-Datenbank über ein Monitoring-Tool beobachten, um zu erkennen, dass eine Partition vergrößert werden muss. Eine wirkliche Lösung für das oben beschriebene Problem ist das aber nicht. Der Administrator kann in diesem Moment nur reagieren und das Storage-Team bitten, das Volume wieder einmal zu vergrößern.

    Grundsätzlich sollte bei den geschilderten Problemen darüber nachgedacht werden, ob das aktuelle Datenbank­konstrukt überhaupt noch zeitgemäß ist, beispielsweise pro Firma eine Datenbank.

    Viele Administratoren versuchen bei zu großen Datenbanken die Benutzer mit den größten Postfächern auf neue oder andere Datenbanken zu verteilen um erstmal etwas Whitespace zu bekommen.

    Diese kann man mit folgendem Befehl ermitteln:

    Get-MailboxDatabase Data02 | Get-Mailbox | Get-MailboxStatistics |
    Sort-Object TotalItemSize | Select-Object DisplayName,TotalItemSize -first 10

    Ermitteln der größten Postfächer in einer Datenbank

    Damit die Benutzer mit den größten Postfächern allerdings nicht immer die Leidtragenden sind und immer wieder bei einem Speicherplatz­problem verschoben werden, macht es eher Sinn, eine Wachstums­statistik zu erstellen und die Benutzer zu verschieben, welche über einen bestimmten Zeitraum stark gewachsen sind.

    Exchange-Benutzerstatistik

    Da Exchange keine Mittel enthält, das Wachstum eines Postfaches zu analysieren, bietet es sich an, die Größe der Postfächer in regel­mäßigen Abständen in eine Microsoft SQL Datenbank zu schreiben. Mit PowerShell geht das so:

    Die Daten kann man dann wieder wie folgt ausgeben:

    $SQLOutput = read-sqltabledata -ServerInstance 'Name SQL Server' `
    -Databasename Mailboxsize -schemaname "dbo" -tablename "Mailbox" `
    -columnname DisplayName,Database,Mailboxsize,Date -outputas datatable

    Ausgabe der in der SQL-Datenbank gespeicherten Informationen zum Wachstum der Postfächer

    Hinweis: Wer ScriptRunner nutzen möchte, sollte an dieser Stelle beachten, dass WsmanCredSSP auf dem ScriptRunner-Server selbst aktiviert sein muss, da das Script sowohl Exchange als auch den SQL Server anspricht.

    Anhand der in der SQL-Datenbank gesammelten Daten kann man nun prozentual das Wachstum der Postfächer berechnen. Außerdem lässt sich so der Speicher­verbrauch über einen längeren Zeitraum verfolgen und ggf. mit weiteren Exchange-Servern und Datenbanken rechtzeitig gegensteuern.

    Migration in neue Datenbanken

    Da man davon ausgehen kann, dass die Datenbanken vor einer Migration ungleich groß sind, bietet es sich an, neue Datenbanken auf neuen Partitionen zu erstellen. Bei der Planung der Migration von Postfächern in neue Datenbanken sollte man festlegen, welche maximale Größe eine Datenbank in Zukunft haben soll, und ob es sinnvoll ist, eine gewisse Größe an Whitespace für ein kurzfristiges Wachstum von Postfächern vorzuhalten.

    Für die Migration habe ich folgendes Script entwickelt (Erklärung im Anschluss):

    Erklärung zum Wartungs-Script

    Im ersten Schritt werden alle Benutzer ausgelesen, welche in neue Datenbanken migriert werden. Nachdem die neuen Datenbanken möglichst gleichmäßig mit den neuen Datensätzen befüllt werden sollen, ist es sinnvoll, mit Schwellenwerten zu arbeiten (sie sind jeweils an die Umgebung anzupassen).

    Damit die Move Requests den oder die Exchange-Server nicht zu sehr belasten, ist es notwendig, diese auf eine bestimmte Zahl zu beschränken.

    Hinweis: Es sollte auch auf die zu schreibenden Exchange-Logs geachtet werden, diese könnten das Vorhaben schnell zum Erliegen bringen, solange sie nicht durch ein Backup weggeschrieben werden.

    Danach werden die verfügbaren Datenbanken ausgelesen, welche den Maximalwert nicht überschreiten sollen. Je nachdem wie groß das Benutzerpostfach ist, wird hier nun geprüft, in welche Datenbank es passt (auch bei der Migration soll der maximale Speicherplatz nicht überschritten werden).

    Sollte keine passende Datenbank mehr zur Verfügung stehen, oder läuft ein Move Request auf einen Fehler, so benachrichtigt das Script den Administrator und er kann dann eine Lösung für das Problem einleiten.

    Das Skript ist so ausgelegt, dass es automatisch in gewissen Zeitabständen laufen kann. Da es Rücksicht auf die Auslastung der Server nimmt, kann es einige Tage dauern, bis die Migration abgeschlossen ist. Beim Move Request bleibt ebenfalls offen, ob er direkt oder zu einer gewissen Uhrzeit abgeschlossen werden soll.

    Regelmäßige Wartung der Datenbankgrößen

    Nach der  Migration sollen die Datenbanken ihre feste Größe behalten und nicht wieder unkon­trolliert wachsen, ansonsten steht der jeweilige Administrator irgendwann wieder vor dem gleichen Problem und muss erneut auf neue Datenbanken migrieren.

    Für den regelmäßigen Ausgleich zwischen den Datenbanken kombiniere ich das Script für die Benutzer­statistik und jenes für die Migration. Da es ziemlich umfangreich ist, stelle ich es als eigenen Download zur Verfügung.

    Das Prinzip ist hier das gleiche wie beim Migrations-Script, nur dass nun zusätzlich nachgeschaut wird, welche Datenbanken einen gewissen Schwellenwert erreicht haben. Dieser errechnet sich aus der tatsächlichen Größe der Datenbank und dem WhiteSpace.

    Wenn ihn eine Datenbank erreicht, soll das Script anhand der in der SQL Datenbank enthaltenen Statistik die Benutzer mit dem größten Wachstum in eine andere Datenbank verschieben.

    Der Whitespace wird nicht direkt nach dem Move Request frei, daher entfernt ein Remove-StoreMailbox den verschobenen Benutzer endgültig aus der ursprünglichen Datenbank.

    Bei der Auswahl einer neuen Datenbank wird berücksichtigt, dass der Benutzer in Zukunft noch weiter wachsen wird. Hier gibt die Speicherplatz­berechnung dem Benutzer­postfach einen Wachstums­schwellenwert mit.

    Es sollte durch diesen beschrieben Automatismus möglich sein, die Datenbankgröße beizubehalten. Der Speicherplatz sollte gleichmäßig ausgelastet sein und ständige Partitions­erweiterungen der Vergangenheit angehören.

    Keine Kommentare