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:
- 1000 Anwender
- 190 GB Postfächer
- 10 GB öffentliche Ordner
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:
- aktuelle Server sind von sich aus schon mal wieder schneller
Das liegt nicht nur an der CPU. Die ist wirklich heute nicht mehr das Problem. Aber die BUS-Systeme sind leistungsfähiger geworden und viele Server haben heute mehrere PCI-Busse, die von einander unabhängig sind.. - Die Festplatten haben größere Kapazitäten
Sie benötigen weniger Festplatten im Server selbst. Daher können Sie einen Server heute mit viele mehr Kapazität ausstatten und sparen vielleicht die externe Erweiterungseinheit. Weniger Festplatten bedeutet natürlich auch eine Kosteneinsparung - Die Festplatten drehen schneller
Heute sind Festplatten mit 10.000 oder 15.000 umdrehungen keine Seltenheit. Das heißt aber auch, dass die angeforderten Daten viel schneller unter den Lesekopf kommen und daher schneller gelesen werden können. Die Latenzzeit ist geringer. Die eigentliche Positionierung der Köpfe auf die Spuren hingegen ist kaum schneller geworden. Allerdings optimieren heute auch IDE-Festplatten mittlerweile die Zugriffe, wie dies SCSI-Platten schon lange vorher gehaben, indem Sie die Lese und Schreibbefehle des Computers gegebenenfalls umsortieren. - Die Festplatten schreiben "dichter"
Da nun mehr Daten auf eine Spur passen und diese enger beschrieben sind und sich die Festplatte noch schneller dreht, können die Daten sehr viel schneller gelesen werden. Der Durchsatz nimmt zu, was speziell beim Backup oder Restore auch erforderlich ist. Die neuen LTO-Laufwerke sichern auch 4mal so viel wie ein früher schon schnelles DLT-Laufwerk. - RAID1 statt RAID5
Die Festplatten sind mittlerweile so groß, dass man nicht mehr mit RAID5 arbeiten muss, um hohe Kapazitäten zu akzeptablen Preisen zu erreichen. Wichtig ist heute das Tempo und da die Physik der Festplatten (im wesentlichen Drehzahl und Positionierungszeit) limitiert sind, sollte der Zugriff nicht noch durch einen ungünstigen RAID-Level verlangsamt werden.
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:
- 2x72GB Raid1 in drei Partitionen geteilt
20 GB Betriebssystem'
20 GB Programme
32 GB Protokolldatein - 4x 144GB Raid 10
288 GB netto für die Datenbanken in einer Speichergruppe
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:
- Die erste Datenbank
Starten Sie mit einen Speichergruppe mit einer Datenbank - Datenbankgrenze erreicht
Wenn die Datenbank größer als ihre definierte Obergrenze (Backup, Recovery etc.) wird, dann legen Sie die nächste Datenbank an - Speichergruppe voll oder Transaktionsprotokoll zu langsam
Wenn die Speichergruppe "voll" ist oder die Transaktionslogs der Flaschenhals werden, dann wird es Zeit für eine weitere Speichergruppe mit getrennten Protokolldateien
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:
- 2x72 GB RAID1
für Boot, System, Programme - 2x72 GB RAID1
für Tracking Logs SG1 - 2x 144GB RAID1
für SG1/Datenbank1 und SG1/Public Folder - 2x 144GB RAID1
für SG1/Datenbank2 und SG1/Datenbank3
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 müssenmail 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.
