Gründe für Exchange-Datenträger-E/A

Artikel
10/25/2013

Letztes Änderungsdatum des Themas: 2006-05-16

Sobald Daten in Exchange gelesen oder geschrieben werden, wird Datenträger-E/A erzeugt. Wenn Sie die Quellen der Datenträger-E/A von Exchange kennen, können Sie das Datenträgersubsystem im Hinblick auf maximale Leistung planen und konfigurieren. Richten Sie Ihre Aufmerksamkeit bei der Analyse der Quellen der Datenträger-E/A von Exchange vor allem auf die E/A-Vorgänge während des Zugriffs auf Protokoll- und Datenbankdateien.

Exchange-Datenkomponenten

Alle Exchange-Daten werden im Exchange-Informationsspeicher abgelegt, der drei Hauptkomponenten umfasst. In der folgenden Tabelle sind die drei Hauptkomponenten des Exchange-Informationsspeichers und deren Einfluss auf die Datenträger-E/A aufgeführt.

Komponenten des Exchange-Informationsspeichers und deren Einfluss auf die Datenträger-E/A

Komponente	Gründe für deren Einfluss auf die Datenträger-E/A
Jet-Datenbank (EDB-Datei)	In der Jet-Datenbank werden alle von MAPI-Clients übermittelten Daten gespeichert. Durch alle von einem MAPI-Client erzeugten Aktivitäten wird die Jet-Datenbank aktualisiert. Speichert eingehende SMTP-Nachrichten, die MAPI-Informationen enthalten.
Streamingdatenbank (STM-Datei)	Speichert Anlagen und Daten, die über IMAP4, NNTP, Microsoft Outlook® Web Access oder SMTP übermittelt werden. In der Jet-Datenbank werden Zeiger gespeichert, sodass die Daten auf Anforderung an die MAPI-Clients übermittelt werden können. Speichert eingehende SMTP-Nachrichten, die keine MAPI-Informationen enthalten. Alle Aktivitäten von IP-Clients führen zu einer Aktualisierung der Streamingdatenbank.
Transaktionsprotokolldateien (LOG-Dateien)	Alle an der Datenbank vorgenommenen Änderungen werden zuerst in Transaktionsprotokolldateien gespeichert. Sobald ein Benutzer eine Nachricht sendet oder liest und sobald er in seinem Postfach gespeicherte Daten ändert, werden die betreffenden Änderungen in die Transaktionsprotokolldatei geschrieben. Die Änderung wird sofort an den RAM-internen Datenbankcache weitergegeben und anschließend wieder auf den Datenträger kopiert, wenn die Auslastung des Systems dies zulässt. Transaktionen werden außerdem erneut gelesen, wenn eine Datenbank bereitgestellt wird.

Jet-Datenbank (EDB-Datei)

In der Jet-Datenbank werden alle von MAPI-Clients übermittelten Daten gespeichert. Durch alle von einem MAPI-Client erzeugten Aktivitäten wird die Jet-Datenbank aktualisiert.

Speichert eingehende SMTP-Nachrichten, die MAPI-Informationen enthalten.

Streamingdatenbank (STM-Datei)

Speichert Anlagen und Daten, die über IMAP4, NNTP, Microsoft Outlook® Web Access oder SMTP übermittelt werden. In der Jet-Datenbank werden Zeiger gespeichert, sodass die Daten auf Anforderung an die MAPI-Clients übermittelt werden können.

Speichert eingehende SMTP-Nachrichten, die keine MAPI-Informationen enthalten.

Alle Aktivitäten von IP-Clients führen zu einer Aktualisierung der Streamingdatenbank.

Transaktionsprotokolldateien (LOG-Dateien)

Alle an der Datenbank vorgenommenen Änderungen werden zuerst in Transaktionsprotokolldateien gespeichert. Sobald ein Benutzer eine Nachricht sendet oder liest und sobald er in seinem Postfach gespeicherte Daten ändert, werden die betreffenden Änderungen in die Transaktionsprotokolldatei geschrieben. Die Änderung wird sofort an den RAM-internen Datenbankcache weitergegeben und anschließend wieder auf den Datenträger kopiert, wenn die Auslastung des Systems dies zulässt. Transaktionen werden außerdem erneut gelesen, wenn eine Datenbank bereitgestellt wird.

Da die einzelnen Komponenten des Exchange-Informationsspeichers jeweils auf unterschiedliche Weise geschrieben werden, können Sie die Leistung erhöhen, wenn Sie die EDB-Dateien und die entsprechenden STM-Dateien für eine Speichergruppe in einem Volume und die Transaktionsprotokolldateien in einem anderen Volume ablegen. Die folgende Tabelle zeigt, wie die Schreib- und Lesevorgänge auf dem Datenträger für die einzelnen Komponenten des Exchange-Informationsspeichers ausgeführt werden.

Schreib- und Lesevorgänge auf dem Datenträger für die einzelnen Komponenten des Exchange-Informationsspeichers

Jet-Datenbank (EDB-Datei)

Lesen und Schreiben im Direktzugriff
Seitengröße 4 KB

Streamingdatenbank (STM-Datei)

Normalerweise sequenzielle Lese- und Schreibvorgänge
Variable Seitengröße von durchschnittlich 8 KB in der Produktionsumgebung

Anmerkung:
Aufgrund der sehr hohen Anzahl der Suchvorgänge sind die E/A-Operationen weder ausschließlich zufällig noch ausschließlich sequenziell.

Transaktionsprotokolldateien (LOG-Dateien)

Vollständig sequenzielle Schreibvorgänge im Normalbetrieb
Vollständig sequenzielle Lesevorgänge bei Wiederherstellungsoperationen
Größe der Schreibvorgänge schwankt zwischen 512 Byte und Protokollpuffergröße

Anmerkung:
Wenn sich auf dem Server Öffentliche Ordner befinden, ergeben sich zusätzliche E/A-Lasten. Wenn auf dem Server jedoch keine Replikate von Ordnerinhalten vorhanden sind, ist die durch die Datenbank für Öffentliche Ordner erzeugte E/A im Gegensatz zu der durch den Zugriff auf Benutzerpostfächer erzeugten E/A nicht sequenziell.

Weitere Aktivitäten, die Einfluss auf die E/A haben

Datenträger-E/A wird nicht nur durch den Zugriff auf die Datenbankdateien erzeugt, sondern auch durch weitere Aktivitäten. Diese Aktivitäten und deren Einfluss auf die Datenträger-E/A sind in der folgenden Tabelle aufgeführt.

Zusätzliche Aktivitäten, die Einfluss auf die Datenträger-E/A haben

Aktivität	Gründe für deren Einfluss auf die Datenträger-E/A
Gelöschte Datenbankseiten unwiderruflich löschen	Sie können den Server so konfigurieren, dass gelöschte Datenbankseiten unwiderruflich gelöscht werden. In diesem Fall werden bei jedem Löschen eines Elements aus der Datenbank mehrere Seiten gelöscht. Exchange überschreibt die gelöschten Seiten anschließend mit Nullen. Dieses Feature wird nur während einer Onlinestreamingsicherung ausgeführt und sorgt während der Sicherung für mehr E/A-Vorgänge auf dem physischen Datenträger.
Inhaltsindizierung	Beim Durchsuchen der Datenbanken nach Indexaktualisierungen wird viel Speicher ausgelagert. Dies führt außerdem zu vielen Schreibvorgängen in der Inhaltsindizierungsdatei und erzeugt eine Datenträger-E/A-Spitze auf dem Datenträger, auf dem die Indizierungsdatei gespeichert ist.
SMTP-Mailübertragung	Ein- und ausgehender SMTP-Verkehr wird beim Übermitteln des Systems auf den Datenträger geschrieben. Wenn Benutzerdatenbank- oder Protokolldateien auf diesem Datenträger gemeinsam genutzt werden, konkurrieren SMTP-Nachrichten, die auf den Datenträger geschrieben bzw. vom Datenträger gelesen werden, mit den Datenbank- und/oder Protokolldateien um die E/A. Wenn SMTP-Nachrichten aus der Warteschlange in die erste Exchange-Datenbank überspielt werden, werden sie vom MIME- in das IMail-Format konvertiert. Dies erzeugt zusätzliche E/A auf den Protokolldatei- und Datenbankvolumes, die von der Datenbank verwendet werden.
Auslagerung	Wenn Exchange mehr Speicher benötigt, als physisch verfügbar ist, lagert Windows Daten in die Auslagerungsdatei auf der Festplatte aus. Häufige Auslagerung führt zu intensiver Datenträger-E/A und reduziert die Leistung des Exchange-Servers. Informationen zum Behandeln von Problemen mit der Seitenauslagerung und dem Löschen des Kernelspeichers finden Sie unter Ausschließen von Problemen in Zusammenhang mit dem Hauptspeicher (https://go.microsoft.com/fwlink/?LinkId=62575).
MTA-Nachrichtenverarbeitung	In Exchange 2000 und Exchange 2003 werden Nachrichten, die bei Postfachoperationen oder von Exchange 5.5-Servern, X.400-basierten Servern bzw. über EDK-Connectors empfangen werden, in die Transaktionsprotokolldateien geschrieben. Dadurch kommt es zu einer Datenträger-E/A-Belastung des Speichersystems.
Anzahl der Objekte in einem Ordner	Mit steigender Anzahl von Objekten in den Exchange 2003-Hauptordnern nimmt die Verarbeitungslast auf physischen Datenträgern beim Durchführen einiger Aufgaben auch für Benutzer von Outlook im Onlinemodus zu. Bei Verwenden von Outlook im Cachemodus werden auf dem Client Indizes erstellt und Suchen durchgeführt. Das erstmalige Sortieren Ihres Posteingangs nach Größe erfordert die Erstellung eines neuen Indexes, wofür viele Datenträger-E/A-Vorgänge erforderlich sind. Künftige Sortiervorgänge des Posteingangs nach Größe erfolgen dagegen sehr schnell. Die Anzahl der möglichen Indizes ist statisch, sodass Benutzer, die ihre Ordner auf viele verschiedene Weisen sortieren, diesen Grenzwert überschreiten können, was weitere Datenträger-E/A-Vorgänge auf der Festplatte verursachen kann.
Anzahl der Postfächer	In Exchange kann die Anzahl der Datenbanklesevorgänge mithilfe des Datenbankcache mit fester Größe reduziert werden. Je mehr Postfächer einem Server mit Exchange hinzugefügt werden, desto mehr Postfächer greifen auf diesen Cache zu. Alle weiteren 1000 Benutzer, die einem Server mit Exchange über den Basiswert 1000 hinzugefügt werden, erhöhen die Anzahl der Datenbank-IOPS (E/A-Vorgänge pro Sekunde) um 25 %.
Exchange-Version	Bei einer Migration von Exchange 5.5 nach Exchange 2000 SP3 können Sie einen 5 %-igen Anstieg der Datenbank-IOPS erwarten, während alle anderen Faktoren konstant bleiben. Bei einer Migration von Exchange 5.5 nach Exchange 2003 SP1 können Sie eine 20 %-ige Reduzierung der Datenbank-IOPS erwarten, während alle anderen Faktoren konstant bleiben.
Einzelinstanzspeicherung	In Exchange 5.5 gibt es eine Datenbank auf dem Server. An mehrere Postfächer auf diesem Server gesendete E-Mail wird nur einmal gespeichert, wobei Zeiger für jeden Empfänger bereitgestellt werden. In Exchange 2000 und Exchange 2003 sind bis zu 20 Datenbanken möglich, wobei jede Datenbank eine Kopie der Nachricht enthalten kann, sollte jede Datenbank einen Empfänger enthalten. Durch jede zusätzliche Datenbank wird die Datenbank-IOPS um weitere 2 % erhöht. Der Grad der Nutzung der Einzelinstanzspeicherung durch Exchange hängt von der Häufigkeit (in Prozent), mit der Nachrichten an Empfänger in derselben Datenbank gesendet werden, und von der durchschnittlichen Nachrichtengröße ab. Größere Nachrichten profitieren stärker von der Einzelinstanzspeicherung.
BlackBerry	In Exchange 2000 und Exchange 2003 stellen Benutzer mit BlackBerry-Geräten zusätzliche Anforderungen an den Server. Im Außendienst werden viele Benutzer einen zwei- bis vierfachen E/A-Anstieg auf dem Datenbankdatenträger feststellen. Weitere Informationen finden Sie im RIM-Whitepaper. BlackBerry-Benutzer verursachen einen zusätzlichen Verarbeitungsaufwand, der sich auf die Datenbank-IOPS auf einem Server auswirkt. RIM testete 1000 BlackBerry-aktivierte MMB2-Benutzer mit BlackBerry Enterprise Server 4. Dabei wurde ein Anstieg der Datenbank-IOPS um den Faktor 3,64 im Vergleich zu MMB2-Standardbenutzern ohne BlackBerry festgestellt. Dieser Faktor kann abhängig von der Nutzung von BlackBerry-Geräten in der Umgebung wesentlich höher oder niedriger sein. Der BlackBerry-Test umfasste Folgendes: 10 Synchronisierungsbefehle, zwei Hinzufügungen von Memos sowie eine Aufgabenänderung, eine Aufgabenlöschung und vier Aufgabenhinzufügungen. Die tatsächliche Nutzung von BlackBerry-Geräten wird nicht so konstant sein, was zu einem schwächeren oder stärkeren Einfluss auf die tatsächliche IOPS führen kann. Bei einem Mailsystem mit 2000 intensiv genutzten Postfächern, von denen 500 für BlackBerry aktiviert sind, werden auf dem Datenbankvolume insgesamt 3820 IOPS prognostiziert. Dieser Wert wird mit folgender Formel berechnet: Geschätzte BlackBerry-IOPS pro Benutzer für Benutzertyp x Benutzeranzahl In diesem Beispiel lautet die Gleichung: 1,0 IOPS x 2.000 Postfächer = 1.500 IOPS. Wenn 500 dieser Benutzer BlackBerry-Geräte haben, fügen diese 500 Benutzer 500 Postfächer x 3,64 IOPS=1820 IOPS bzw. insgesamt 3820 IOPS hinzu. Wenn Sie bei einer vorsichtigen Schätzung davon ausgehen, dass auf jeden Schreibvorgang zwei Lesevorgänge kommen (66 % Lesevorgänge zu 33 % Schreibvorgänge), müssen Sie für das Datenbankvolume 2.546 Lese-E/A- und 1.273 Schreib-E/A-Anforderungen pro Sekunde einplanen. Jede Schreibanforderung wird zunächst in die Transaktionsprotokolldatei und danach in die Datenbank geschrieben. Etwa 10 Prozent der 3.820 IOPS des Datenbankvolumes treten auf dem Transaktionsprotokollvolume auf (10 Prozent von 3.820 sind 382 IOPS). 1.273 Schreib-E/A-Anforderungen werden in die Datenbank geschrieben. Im Handbuch zur Leistung und Skalierbarkeit von Exchange Server 2003 finden Sie ausführliche Anweisungen zum ordnungsgemäßen Berechnen der Servergröße.

Empfohlene Vorgehensweisen zur Optimierung der Datenträger-E/A von Exchange

Nachdem Sie die Exchange-Aktivitäten kennen gelernt haben, die Datenträger-E/A erzeugen, sollten Sie das Speichersystem im Hinblick auf eine maximale Leistung anpassen. In der folgenden Tabelle werden empfohlene Vorgehensweisen für die Platzierung der verschiedenen Datendateien aufgeführt.

Empfohlene Vorgehensweisen zur Optimierung der Datenträger-E/A

Quelle der Exchange-E/A	Empfohlene Vorgehensweise zur Maximierung der Leistung
Datenbankdateien	Sie sollten alle Datenbankdateien (EDB und STM) in eine Speichergruppe auf einem Volume platzieren, das speziell für diese Datenbanken vorgesehen ist. Datenträger, auf denen Datenbankdateien gespeichert sind, sollten eine hohe Geschwindigkeit bei zufälligem Zugriff aufweisen.
Inhaltsindizierungsdateien	Speichern Sie Inhaltsindizierungsdateien nie auf demselben Datenträger wie die Auslagerungsdatei (auch wenn es sich hierbei um den vorgegebenen Speicherort handelt). Da es sich bei der Inhaltsindizierungsdatei um eine Datei mit wahlfreiem Zugriff handelt, kann diese auf demselben Volume wie die Datenbanken platziert werden, sofern das Datenträgersubsystem die Last verarbeiten kann.
Einzelinstanzspeicherung	Zum Maximieren des Nutzens der Einzelinstanzspeicherung sollten sich Postfächer, die zu den selben Arbeitsgruppen und Verteilerlisten gehören, in derselben Datenbank befinden.
Transaktionsprotokolldateien	Da alle Transaktionen zunächst in die Transaktionsprotokolle geschrieben werden, sollten sich die Transaktionsprotokolle auf einem Speichergerät mit einer möglichst niedrigen Schreiblatenz befinden. Die niedrigste Schreiblatenz wird in der Regel erzielt, indem ein RAID-1/RAID-1+0-Satz für die Protokolle einer einzelnen Speichergruppe vorgesehen wird. Auf diese Weise werden die Vermischung der Datenströme mit anderen E/A vermieden und 100 Prozent sequenzielle E/A-Schreibvorgänge gewährleistet, womit der höchste Datenträgerdurchsatz und die niedrigste Latenz erzielt wird. Speicherarrays mit einem effektiven gespiegelten, akkuunterstützten Write-Back-Cache zeigen bei dieser Verfahrensweise u. U. keine Leistungsverbesserung, weil alle E/A-Schreibvorgänge zuerst in den Cache geschrieben, zugeordnet und dann auf den Datenträger geschrieben werden (niedrige Schreiblatenz vorausgesetzt, weil der Schreibvorgang als erfolgreich an das Betriebssystem zurückgegeben wird, sobald er im Cache zwischengespeichert wird). Mithilfe von Jetstress kann gemessen werden, ob dieser Typ der E/A-I/O-Isolierung bessere Leistungsdaten für eine bestimmte Speicherplattform/-konfiguration erbringt. Um eine optimale Wiederherstellbarkeit zu erzielen, wird empfohlen, die Transaktionsprotokolle und Datenbanken für eine bestimmte Speichergruppe auf verschiedenen LUNs (Logical Unit Numbers) zu platzieren; als RAID-1/RAID-1+0 konfiguriert. Die getrennten LUNs, die als Host für die Protokolle und Datenbankdateien für dieselbe Speichergruppe dienen, sollten außerdem die physischen Datenträger in dem Array nicht gemeinsam nutzen. Dadurch soll der Grad der Wiederherstellbarkeit erhöht werden, womit Ihnen ermöglicht wird, bei Ausfällen von mehreren Datenträgern mit geringen Datenverlusten eine Wiederherstellung vorzunehmen (Verlust entweder der Datenträger mit den Sicherungen der Protokolle oder der Datenträger mit den Sicherungen der Datenbanken; aber nicht von beiden). Wenn die Protokoll-LUN verloren geht, verfügen Sie immer noch über eine fast aktuelle Datenbank. Wenn die LUN der Datenbank verloren geht, können Sie aus der Sicherung die Wiederherstellung vornehmen und die Protokolle vorwärts abspielen, um die Datenbank zu aktualisieren. Wenn die Protokolle und die Datenbanken aus derselben Speichergruppe auf derselben LUN platziert werden oder auf verschiedenen LUNs, die dieselben physischen Datenträger gemeinsam verwenden, besteht die Gefahr, bei einem Ausfall mehrerer Datenträger die Protokolle und die Datenbank zu verlieren. Dabei würden alle Änderungen seit der letzten erfolgreichen Sicherung verloren gehen. Die Empfehlung, Protokolle und Datenbanken innerhalb einer bestimmten Speichergruppe auf unterschiedlichen physischen Datenträgern zu trennen, ist dann von geringerer Bedeutung, wenn die Exchange-Datenbanken und -protokolle über eine synchrone Replikation auf ein anderes Speicherarray repliziert werden (bei einem Ausfall mehrerer Datenträger können die Datenbank und die Protokolle mithilfe dieses alternativen Speicherarrays wiederhergestellt werden). Wenn der Hardware-RAID-Controller einen gespiegelten, akkuunterstützten Write-Back-Cache aufweist und die Möglichkeit bietet, das Lese-/Schreibcacheverhältnis zu optimieren, legen Sie den Anteil der Schreibvorgänge auf 75 Prozent und der Lesevorgänge auf 25 Prozent fest.
SMTP-Warteschlange	Für das SMTP-Warteschlangenvolume sollten Sie ein RAID-1+0-Array mit mehreren Datenträgerspindles verwenden. Die erforderliche Anzahl von Datenträgerspindles und die Größe des Schreibcaches sollte sich nach dem erwarteten Durchsatz von SMTP-Nachrichten auf dem Server richten. Die SMTP-Warteschlange sollte sich nie auf einer Spindle befinden, auf der eine andere Funktion ausgeführt wird (beispielsweise Transaktionsprotokolle, Datenbank-, Auslagerungs- oder Systemdateien). Ob eine Nachricht für ein Postfach auf demselben Server oder auf einem Remoteserver bestimmt ist oder nicht, wirkt sich nur geringfügig auf die von SMTP-Warteschlangen erzeugte Datenträger-E/A aus.
Auslagerungsdatei	Zur Gewährleistung einer optimalen Leistung sollten Sie die Auslagerungsdatei auf separaten Spindles ablegen, und sie sollte sich auf mindestens einem RAID-1-Gerät befinden. Wenn Sie den Datenträger mit der Auslagerungsdatei verlieren, kommt es auf dem Server zu einem Abbruchfehler.
MTA-Warteschlange	Die MTA-Warteschlange (Message Transfer Agent) sollte sich niemals auf einem Protokoll- oder Datenbankvolume befinden. Wenn der Server SMTP- und/oder MTA-Datenverkehr in größerem Umfang verarbeitet, sollten Sie für die SMTP- und MTA-Warteschlangen separate Spindles bereitstellen.

Wenn der Exchange 2003-Computer z. B. eine Speichergruppe mit fünf Datenbanken enthält, sollten Sie die folgenden separaten physischen RAID-Arrays konfigurieren:

C:\ – Systemvolume, Betriebssystem, Exchange-Systemdateien – RAID-1 (direkt angeschlossenes Speichersystem, kein SAN)
D:\ – Auslagerungsdatei – RAID-1 (direkt angeschlossenes Speichersystem, kein SAN)
E:\ - SMTP- und MTA-Warteschlangen - RAID-1+0 (SAN)
F:\ – Protokolldateien der Speichergruppe 1 – RAID-1 (SAN)
G:\ – Datenbanken der Speichergruppe 1 – RAID-1+0 (SAN)