Sizing Guide Exchange Server 2003 - Fujitsu

Weitere Magazine

Empfehlungen

Info

White Paper Sizing Guide Exchange Server 2003 Version: 4.2, July 2006 Zugriffsmuster Bei der Verwaltung der Datenbanken entstehen zwei völlig komplementäre Zugriffsmuster auf die Daten. Zum einen die Datenbanken mit einem 100 prozentigen wahlfreien (random) Zugriff. Typischerweise sind das 2/3 lesende und 1/3 schreibende Zugriffe. Zum anderen entsteht durch die Transaktions-Log-Files ein Datenstrom, der zu 100% sequentiell geschrieben wird. Um dem gerecht zu werden, empfiehlt es sich, die Datenbanken und Log-Files auf unterschiedliche physikalische Platten zu verteilen. Und noch ein zweiter Aspekt für die räumliche Trennung von Log-Files und Datenbanken: Bei dem Transaktionskonzept werden alle Änderungen an den Datenbanken in den Log-Files protokolliert. Gehen die Datenbanken verloren, so kann unter Zuhilfenahme eines Backups und der Log-Files seit der Erstellung des Backups der Datenbestand komplett restauriert werden. Um ein Maximum an Sicherheit zu erlangen, ist es sinnvoll, die Log-Files und die Datenbanken auf unterschiedliche physikalische Festplatten abzulegen, so dass im Falle eines Platten-Crashes nicht alle Daten verloren gehen. Solange nur eine der beiden Informationen verloren geht, lässt sich die fehlende Information restaurieren. Dies gilt insbesondere für kleine Exchange Installationen, wo man aufgrund einer geringen Anzahl Festplatten verleitet wird, beide Informationen auf einem Datenträger abzulegen. Caches Bei einem intelligenten SCSI-Controller mit eigenen Cache-Mechanismen gibt es Möglichkeiten, mit denen das Disk-Subsystem an die Anforderungen des Exchange Servers angepasst werden kann. So sollte für das Volume, auf dem die Log-Files liegen, der Write-Back-Cache eingeschaltet sein. Auch Read-Ahead-Caches sollten für die Log-Files eingeschaltet sein, dies bringt beim Restore, bei dem die Log-Files gelesen werden müssen, Vorteile. Gleiches gilt für das Volume, auf denen Queues (SMTP- oder MTA-Queues) abgelegt werden. Bei dem Volume, auf dem der Store abgelegt wird, ist es jedoch nicht sinnvoll, den Read-Ahead-Cache zu aktivieren. Das klingt erst mal unlogisch, dass man einen Cache, der ja der Beschleunigung der Zugriffe dient, abschaltet. Bei dem Store handelt es sich jedoch um viele Gigabyte große Datenbanken, auf die wahlfrei (random) in Häppchen von 4 kB zugegriffen wird. Die Wahrscheinlichkeit, dass dabei in einem Cache von wenigen MB Größe ein 4 kB Block aus einer ‟zig GB großen Datenmenge angetroffen wird und nicht von der Platte gelesen werden muss, ist sehr unwahrscheinlich. Bei einigen Controllern kann leider der Lese-Cache nicht unabhängig vom Schreib-Cache abgeschaltet werden und auch beim Lesen wird erst mal nachgesehen, ob die angeforderten Daten im Cache stehen. In diesem Fall erlangt man einen besseren Gesamtdurchsatz, indem man ausgenommen bei RAID 5, den Cache ganz abschaltet, da die Lesezugriffe typischerweise doppelt so häufig sind wie die Schreibzugriffe. Daneben bietet auch jede einzelne Festplatte Schreib- und Lese-Caches. Der Lese-Cache ist standardmäßig immer aktiviert. Über die Aktivierung des Schreib-Caches wird viel diskutiert, denn im Gegensatz zu den Schreib-Caches der RAID-Controller ist dieser Cache nicht Batterie-gepuffert. Unter der Vorraussetzung, dass der Server (und natürlich auch das Disk-Subsystem) USV-gesichert ist, ist es sinnvoll, die Schreib-Caches der Festplatte einzuschalten. Alle Festplatten von Fujitsu werden aus Sicherheitsgründen mit ausgeschalteten Schreib-Caches geliefert. Einige unserer Mitbewerber liefern ihre Festplatten mit eingeschalteten Schreib-Caches aus, so dass bei vergleichenden Teststellungen solche Systeme auf den ersten Blick performanter erscheinen. Ist ein System jedoch nicht gegen Stromausfälle mit einer USV gesichert, oder wird es abrupt ausgeschaltet, so kann es bei eingeschalteten Schreib-Caches der Festplatten zu Datenverlusten kommen. © Fujitsu Technology Solutions, 2009 Seite 20 (71)
White Paper Sizing Guide Exchange Server 2003 Version: 4.2, July 2006 RAID-Level Eine der fehleranfälligsten Komponenten eines Computersystems ist die Festplatte. Es ist ein mechanisches Teil und wird insbesondere bei Datenbank-basierten Anwendungen, zu denen auch Exchange zählt, extensiv genutzt. Daher ist es wichtig, gegen den Ausfall einer solchen Komponente gefeit zu sein. Hierfür gibt es Methoden, mehrere Festplatten in einem Verbund derart zu arrangieren, so dass der Ausfall einer Festplatte verkraftet werden kann. Man nennt dies Redundant Array of Independent Disks oder kurz RAID. Im Folgenden zunächst einen kurzen Überblick über die wichtigsten RAID-Levels. Die jeweilige Abbildung verdeutlicht, wie die Blöcke eines Datenstroms A B C D E F ... auf den einzelnen Platten organisiert werden. RAID 0 Der RAID-Level 0 wird auch als »Non-Redundant Striped Array« bezeichnet. Bei einem RAID 0 werden zwei oder mehr Festplatten zusammengeschaltet, ausschließlich mit dem Ziel, die Schreib-Lese-Geschwindigkeit zu erhöhen. Die Daten werden in kleine Blöcke mit einer Größe von 4 bis 128 kB aufgeteilt, so genannte Stripes, und abwechselnd auf den Platten gespeichert. So kann auf mehrere Platten gleichzeitig zugegriffen werden, was die Geschwindigkeit erhöht. Da bei RAID 0 keine redundanten Informationen erzeugt werden, gehen alle Daten im RAID 0-Verband verloren, wenn auch nur eine Festplatte ausfällt. RAID 0 bietet den schnellsten und effizientesten Zugriff, ist aber nur für Daten geeignet, welche sich jederzeit unproblematisch regenerieren lassen. RAID 1 Bei einem RAID 1, auch »Drive Duplexing« oder »Mirroring« genannt, werden auf zwei Festplatten identische Daten gespeichert. Es ergibt sich damit eine Redundanz von 100%. Ferner kann durch alternierendes Zugreifen die Lese-Performance erhöht werden. Fällt eine der beiden Festplatten aus, so arbeitet das System mit der verbleibenden Festplatte ungestört weiter. RAID 1 ist die erste Wahl in Performance-kritischen, fehlertoleranten Umgebungen. Außerdem gibt es zu RAID 1 keine Alter- native, wenn Fehlertoleranz gefordert, aber nicht mehr als zwei Platten gewünscht sind bzw. zur Verfügung stehen. Die hohe Ausfallsicherheit hat allerdings ihren Preis, denn es wird die doppelte Anzahl Festplatten benötigt. RAID 5 Bei einem RAID 5-Verband werden mindestens drei Festplatten benötigt. Ähnlich wie bei RAID 0 wird der Datenstrom in Blöcke unterteilt. Über die einzelnen Blöcke wird eine Parity-Information gebildet und diese zusätzlich zu den Daten auf dem RAID-Verband abgelegt, wobei die Information selbst und die Parity-Information immer auf zwei verschiedenen Festplatten geschrieben werden. Fällt eine RAID 0 Festplatte aus, so kann mit Hilfe der verbleibenden Parity-Information eine Restaurierung der Daten vorgenommen werden. Der durch die zusätzliche Parity-Information entstehende Verschnitt sinkt mit der Anzahl verwendeter Festplatten und beträgt 1 /Anzahl Platten. Eine einfache Daumenregel ist »eine Platte Verschnitt« pro RAID 5-Verband. RAID 5 bietet Redundanz und haushaltet am besten mit den Plattenressourcen. Allerdings kostet die Parity-Bildung Performance. Selbst spezielle RAID-Controller können dies nicht ausgleichen. © Fujitsu Technology Solutions, 2009 Seite 21 (71) A E I RAID 5 A D G B F J B E P(GHI) C G K RAID 1 A B C C P(DEF) H D H L A’ B’ C’ P(ABC) F I
Seite 1 und 2: Sizing Guide Exchange Server 2003 A
Seite 3 und 4: White Paper Sizing Guide Exchange S
Seite 19: White Paper Sizing Guide Exchange S
Seite 71:
White Paper Sizing Guide Exchange S
Alle anzeigen

Sizing Guide Exchange Server 2003 - Fujitsu

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?