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

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()}}

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

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:

$user = Get-Mailbox -ResultSize unlimited | Get-MailboxStatistics | select-object DisplayName,Database, ` @{Name="Mailboxsize";expression={$_.TotalItemSize.Value.ToMB()}} $date = get-date -Format "dd.MM.yyyy HH:mm" #Daten an SQL-Datenbank weitergeben Foreach($u in $user){ $Displayname = $u.Displayname $Database = ($u.Database).Name $Mailboxsize = $u.Mailboxsize Invoke-Sqlcmd -ServerInstance 'NAME SQL SERVER' -U sa -P Hallo123 -Database Mailboxsize ` -Query "Insert Into [dbo].[Mailbox] ([DisplayName],[Database],[Mailboxsize],[Date]) VALUES ('$Displayname', '$Database', '$Mailboxsize', '$Date')" }

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

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):

#Mail-Versand $Emailserver = "SMTP Server" $EmailAbsender = "Emailadresse" $EmailEmpfänger = "Emailadresse" #Benutzer auslesen aus den Datenbanken, welche umgezogen werden sollen $user = Get-Mailbox | where-object {$_.database -like "Mailbox*"} | Select alias | foreach-object {Get-MailboxStatistics -Identity $_.alias | select DisplayName,Database, @{Name="Mailboxsize";expression={$_.TotalItemSize.Value.ToMB()}}} #ERSTE Verteilung in LEERE Datenbanken $i = 0 foreach($u in $user){ #Schwellwerte welcher Userkreis genommen werden soll if(($u.Mailboxsize -le 2000) -and ($u.Mailboxsize -gt 1)){ #MoveRequestStatus prüfen $moverequest = Get-MoveRequest | Get-MoveRequestStatistics foreach($move in $moverequest){ #Wenn der Moverequest fertig ist bitte löschen if($move.statusdetail -eq "Completed"){ Get-MoveRequest -MoveStatus Completed | remove-moverequest -Confirm:$false} #Wenn der Moverequest auf einen Fehler gelaufen ist, dann Email an Administrator if($move.statusdetail -like "Failed*"){ Send-MailMessage -smtpserver $Emailserver -From $EmailAbsender -To $EmailEmpfänger ` -Subject "Datenbankwartung - MoveRequest - WICHTIGE NACHRICHT" ` -Body "User $move.displayname koennte nicht verschoben werden, Fehler im MoveRequest" }} #Offene Anzahl der MoveRequests checken wenn weniger als 2 dann los $moverequestcheck = Get-MoveRequest if($moverequestcheck.count -lt "10"){ #NEUE Datenbanken auslesen $Database = Get-MailboxDatabase -Status | where-object {$_.Name -like "DATA*"} | select name,@{Name='DBSize';Expression={$_.DatabaseSize.ToMb()}},` @{Name='AvailableNewMbxSpaceMb';Expression={$_.AvailableNewMailboxSpace.ToMb()}} #Datenbank soll unter dem Schwellwert von 2600 MB liegen $dataklein = $database | where {($_.DBSize + $_.AvailableNewMbxSpaceMb) -lt 6000} #Mailboxgröße soll zzgl. Wachstumswert unter der Datenbankgröße bleiben $data = $dataklein | where {($_.DBSize + $_.AvailableNewMbxSpaceMb) -gt ($u.mailboxsize + 100)} #Wenn mehere Datenbanken gefunden wurden, dann MoveRequest auslösen if((($data) -ne $null) -and (($data.name).count -gt "1")){ #Movevorgang wird ausgelöst New-MoveRequest -Identity $u.displayname -TargetDatabase $data.name[($i % $data.Count)] ` -Priority High -BadItemLimit 100 -AcceptLargeDataLoss $i++ } #Was soll passieren, wenn nur eine Zieldatenbank gefunden wurde if((($data) -ne $null) -and (($data.name).count -eq "1")){ #Movevorgang wird ausgelöst New-MoveRequest -Identity $u.displayname -TargetDatabase $data.name ` -Priority High -BadItemLimit 100 -AcceptLargeDataLoss } #Falls keine Datenbanken gefunden wurden, dann Mail rausschicken. if(($data) -eq $null){ Send-MailMessage -smtpserver $Emailserver -From $EmailAbsender -To $EmailEmpfänger ` -Subject "Datenbankwartung - WICHTIGE NACHRICHT" ` -Body "User $u.displayname koennte nicht verschoben werden,` da keine Datenbank mit passender Groesse gefunden wurde." }}}}

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.