Exchange Sizing - Große Firma mit Exchange 2003

Seite 4/4

Basierend auf einer fiktiven Diskussion mit einem Kunden könnten Sie einen großen Server dimensionieren. Die Eckwerte sind:

Frage:

Wir benötigen einen neuen Exchange Server. Wir haben aktuell ca. 1000 Anwender mit insgesamt 180 Gigabyte Postfächern. Woran muss ich denken ?

Antwort:

Zum Sizing eines Servers ist es nicht einfach aus der Ferne da zu etwas zu raten. Aber ich versuche es mal. Ein neuer Server hat von sich aus schon mal einige Vorteile:

Frage:

Ok, ich brauche einen neuen Server, aber sie ist das nun mit den Speichergruppen und den Festplatten?

Antwort:

Mal abgesehen, dass Sie erst mit Exchange Enterprise mehr als eine Postfachdatenbank und eine Datenbank für öffentliche Ordner haben, müssen Sie noch einige andere Überlegungen einbeziehen: Theoretisch könnten Sie ja eine einzige Speichergruppe machen mit einer Datenbank und dann folgendes Tun:

Da stellt sich aber die Frage, ob das "gut" ist, denn wer kann eine Datenbank von 160 GB heute noch vernünftig sichern ? Da ist dann schon LTO-Laufwerk und ein schnelles Netzwerk oder SAN erforderlich.

Also ist die Obergrenze für eine Datenbank eher, was Sie noch verantworten können für Restore, Reparatur etc. Viele Firmen haben in Zeiten von DLT dann als Obergrenzen z.B. 20 GB angesetzt und sind heute (mit LTO als Backup) bei 80-100 GB angekommen. Solche eine Datenbank können Sie auch in 1-2 Stunden wieder restaurieren. mit bis zu 200 GB Postfächern bedeutet das aber, dass Sie mit drei Datenbanken starten. Dann bleibt die Frage noch, ob Sie die drei Datenbanken in einer Speichergruppe anlegen oder mehrere Speichergruppen anlegen. Eigene Speichergruppen haben primär den Vorteil, dass die Transaktionsprotokolle getrennt werden können. Das ist wichtig, wenn dieser Prozess ein Engpass ist. Zudem können mehrere Speichergruppen parallel gesichert werden,  wenn ihr Backupsoftware, ihre Bandlaufwerke und natürlich auch der Server das her gibt.

Eine generelle Empfehlung zu Datenbanken und Speichergruppen könnte so lauten:

Aber auch hier ist das nur eine grobe Empfehlung. Wenn Sie heute schon absehen können,  dass sie am Ende bei 6 Datenbanken landen, dann sollten Sie nicht erst mit einer Datenbank anfangen und danach wild umher verschieben. Überlegen Sie, wo sie in 6-12 Monaten stehen werden. Das sollte anhand der bisherigen Nutzung vorhersehbar sein. Wenn dann doch das Wachstum ganz anders verläuft, dann gibt es Gründe wie Firmenübernahmen etc. und dann steht jede Planung zur Disposition.

Für den Unterbau würde ich heute nur noch RAID1 nutzen und wenn Sie eine Trennung der I/Os benötigen, dann müssen eigene Subsysteme hierfür genutzt werden. Und das ist nun nur eine Frage des Geldes.

Wenn wir also davon ausgehen, dass wir 60-80  GB als "Obergrenze" für eine Datenbank definieren, dann bräuchten wir heute schon drei Datenbanken. Und bedenken Sie, dass das Volumen eher zunimmt. Hinzu kommen noch die öffentlichen Ordner. So könnte daher ein System wie folgt aussehen:

Alternativ könnte man auch ein RAID10 mit 288 GB für alle vier Datenbanken nutzen. eine Überlegung bleibt natürlich, jede Datenbank auf eine eigene Partition zu legen, damit ein explosionsartiges Wachstum einer Datenbank die andere nicht gleich mit auf der gleichen vollen Partition herunter fährt.

Ob eine Festplatte für Transaktionsprotokolle reicht, können Sie am besten ermitteln, wenn sie heute schon einen Exchange Server betreiben: Sichern Sie ihren Exchange Server und dann schauen Sie kurz vor der nächsten Sicherung nach, wie viele Transaktionsprotokolle sich angesammelt haben. Wenn Sie dann z.B. auf 2 Gigabyte EDB*.LOG-Dateien kommen und wir der Einfachheit halber von 12 Stunden "Arbeitszeit" des Servers ausgehen, dann bedeutet das:

2GB/12h = 166Megabyte/Stunde = 2,7 Megabyte/Minute

Das ist eigentlich nicht viel für eine heutige Festplatte. Aber lassen Sie sich nicht täuschen, denn wir können nicht von einer Gleichverteilung der Zugriffe ausgehen und wenn eine Firma einmal am Tag eine personalisierte Massenmail versendet oder abends um 17:00 Uhr alle Außendienstler ins Büro zurückkehren und alle unterwegs geschriebenen Mails und Termine replizieren, dann kann das in den Zeiten doch eng werden. Genauer finden Sie dies natürlich heraus, wenn Sie die Transaktionsfestplatte ihres aktuellen Servers mit Perfmon überwachen (Disk Queue Length) oder anhand der Uhrzeit der vorhandenen Transaktionsprotokolle auf die aktiven Zeiten schließen.

Bei diesem Plan stört mich aber, dass die Datenbanken netto 2x144 GB = 288 GB haben und wir ja schon heute von bis zu 200 GB produktiven Daten ausgegangen sind. Das könnte also schon bald wieder zu knapp werden. Die Reserve ist etwas klein und auf der anderen Seite fehlt vielleicht Platz um doch mal eine Offline Defragmentierung durchzuführen oder eine Recovery Storage Group anzulegen.

Nur je größer der Server wird, desto prekärer wird auch das Thema Datensicherung und Datenmenge. Irgendwann sollten Sie sich dann doch einmal Gedanken über Speichernetzwerke (SAN und NAS - Speicher für Exchange) machen. Speziell wenn es noch andere Server (Dateiserver, Datenbanken) gibt, die auch an entsprechende Kapazitäten benötigen. Denkbar wäre natürlich auch dass Sie die Größen der Datenbanken künstlich klein halten, indem Sie die Postfächer der Anwender limitieren (siehe Limits, oder wir kann ich Grenzen setzen) oder alte Informationen archivieren (siehe Archivieren mit Exchange)

Letztlich bleibt es eine individuelle Entscheidung basierend auf den bisherigen Werten und der geschätzten zukünftigen Entwicklung. Von Vorteil sind die, die schon länger ihre aktuelle Belastung mit Programmen wie z.B.: MOM2005 oder anderen Tools aufzeichnen.

Keywords:Sizing