NetApp Tech OnTap

Replizierung von Exchange 2007

Best Practices für SP1

Vor etwa einem Jahr habe ich einen Artikel geschrieben, der hier in Tech OnTap erschien und bei dem es u.a. um die neuen Replizierungsfähigkeiten von Microsoft Exchange Server 2007 ging. Das kürzliche Release von Exchange 2007 Service Pack 1 (SP1) bietet nicht nur Bugfixes und Verbesserungen der beschriebenen Fähigkeiten, sondern bringt auch wesentliche neue Funktionen mit, die sich darauf auswirken, wie man seine Architektur von NetApp Storage für Exchange entwerfen sollte. Dieser Artikel bietet einen Überblick über die Änderungen, welche die größten Auswirkungen auf Storage-Systeme haben, und nimmt noch einmal die Best Practices für den Entwurf von Exchange-Storage unter die Lupe. Weitere Details zu diesen Themen finden Sie in meinem aktuellen technischen Bericht „Microsoft Exchange 2007 SP1 Continuous Replication Best Practices Guide“.

Wichtige Verbesserungen und neue Features

Unter den zahlreichen Änderungen bei Exchange 2007 SP1 sind fünf, die Sie auf jeden Fall kennen sollten:

SP1 ist die einzige Version von Exchange 2007, die Windows Server 2008 unterstützt. Windows Server 2003 wird von SP1 immer noch unterstützt.

SP1 bietet eine neue Variante der Replizierung: Standby Continuous Replication (SCR). SCR ermöglicht die Trennung von Hochverfügbarkeits- und Ausfallsicherheitsfunktionen und erlaubt das Erstellen zahlreicher neuer Redundanz-Szenarien. Es kann zur Verwendung mit jeder Art von Exchange Server konfiguriert werden, solange es nicht gleichzeitig für Local Continuous Replication konfiguriert ist. (Sie können auch nicht LCR auf den SCR Servern Ihres Zielsystems verwenden.) Sie können mehrere SCR Zielsysteme für jede Storage-Gruppe haben. Sie können z.B. eine lokale und eine remote Kopie haben. Sie können auch einen einzelnen SCR Server als Zielsystem für mehrere Quell-Server konfigurieren.

SP1 bietet ein vollständig überarbeitetes Konzept, wie Storage auf Replizierungszielen verwendet wird, was diese wesentlich effizienter macht. Die I/O-Operationen auf allen Replizierungszielen (LCR, CCR und SCR) sind im Vergleich zum ersten Release von Exchange 2007 drastisch verringert worden. Bislang konnten die Datenbank-I/O-Operationen auf den Replizierungszielen bis zu 200% oder gar 300% höher sein als auf dem Quellsystem. Bei SP1 sind die Datenbank-I/O-Operationen auf dem Zielsystem jetzt 78% weniger als auf dem Quellsystem. Auch die I/O-Operationen für das Zielsystemlog wurden in SP1 reduziert.

Die aggressive Online-Defragmentierung wurde gebändigt, und Monitoring ist jetzt möglich. Man kann jetzt sehen, wie lange ein Defragmentierungsdurchgang dauert und wie häufig die Datenbank vollständig defragmentiert wurde. Diese Informationen können Sie verwenden, um das Fenster für Online-Wartungsarbeiten anzupassen und weniger Änderungen auf den Festplatten zu verursachen, was Auswirkungen auf den Platzbedarf von Snapshot hat.

Das Scannen der Datenbank kann jetzt während Online-Wartungsarbeiten durchgeführt werden, um auf Korrumpierung zu überprüfen. Bis zu SP1 bestand die einzige Möglichkeit, sicherzustellen, dass eine Datenbank nicht korrumpiert war, ohne sie offline nehmen zu müssen, in der Durchführung eines Online-Streaming-Backups, wodurch jede Seite in der Datenbank gelesen und verifiziert werden musste. Dies war ebenfalls die einzige Möglichkeit, das Überschreiben mit Nullen von gelöschten Seiten zu erzwingen, wie es einige Sicherheitsszenarien verlangen. Falls Sie VSS-Backups auf einer Kopie statt auf der aktiven Datenbank durchgeführt haben, bedeutet dies wahrscheinlich, dass Ihre Produktionsdatenbank niemals vollständig verifiziert wurde.

In der Praxis empfehlen sowohl NetApp als auch Microsoft die Verwendung von Visual SourceSafe (VSS) für Backups. Die Backup-Applikation verifiziert die Backup-Daten, aber auch hier wird niemals eine echte Überprüfung der Live-Daten durchgeführt. Damit bleibt ein kleines, aber reales Restrisiko, dass sich eine Korrumpierung der Datenbank einschleicht.

Wenn sie entsprechend in der Registrierungsdatei eines Exchange Servers mit SP1 aktiviert wurden, werden Datenbankscans und Überschreiben leerer Seiten mit Nullen jeden Tag während des Online-Wartungsarbeitenfensters ausgeführt, um die aktive Datenbank zu verifizieren und gelöschte Seiten mit Nullen zu überschreiben.

Best Practices

An dieser Stelle sagen Sie wahrscheinlich: „Das klingt ja alles ganz prima, aber wie soll ich diese neuen Features in meiner NetApp Umgebung am besten nutzen?“

Windows Server 2008. Wenn Ihre Exchange Server das aktuellste Betriebssystem ausführen sollen, müssen Sie SP1 auf einem neuen Server mit Windows 2008 installieren. Das Upgrade des Betriebssystems auf einem laufenden Server wird nicht unterstützt. Sie brauchen aber nicht Exchange 2007 vor der Installation von SP1 zu installieren, da das Service Pack alles enthält.

Unabhängig vom Betriebssystem empfehle ich ein Upgrade auf SP1, schon wegen der Bugfixes und Verbesserungen, die erhebliche Auswirkungen auf die Storage-Systeme haben.

LUN-Konfiguration für die Replizierung. Die von Microsoft empfohlene Best Practice besteht darin, dass Sie die gleiche LUN-Konfiguration sowohl für das Quellsystem als auch für das Zielsystem jeder Kopie bereitstellen – und natürlich sollten sich Quell- und Ziel-LUNs auf separaten Storage-Systemen befinden. Wegen der enormen I/O-Last des ersten Release von Exchange 2007 für die Zielserver haben wir bislang empfohlen, ein separates Log- und Datenbankaggregat für jeden Cluster-Knoten zu konfigurieren. Wenn ein Storage-System mehrere Replizierungs-Server unterstützte (Quell- und/oder Zielsysteme), brauchte es eine Menge unabhängiger Aggregate.

Dank der Reduzierung der I/O-Last bei SP1 ist diese Anforderung obsolet geworden. Wir empfehlen auch weiterhin, die Logdateien und Datenbanken in getrennten Aggregaten zu halten (und Sie sollten auch immer noch Quell- und Ziel-Storage getrennt halten), aber Sie können jetzt mehrere Datenbanken von separaten Clustern zu einem einzelnen Aggregat gruppieren. Dasselbe gilt für die Logdateien. Dies eliminiert „Storage-Inseln“, vereinfacht die Storage-Konfiguration und kann gleichzeitig die Auslastung erhöhen.

CCR Cluster

Abbildung 1: LUN-Konfiguration für Kopien mit Exchange 2007 SP1. Sowohl Quell- als auch Ziel-Storage-Systeme verwenden ein Aggregat für Datenbanken und eines für Logdateien, insgesamt vier Aggregate (zwei auf jedem System) im Vergleich zu den zwölf Aggregaten, die bislang benötigt wurden.

Online-Defragmentierung. Defragmentierung kann große Auswirkungen auf die Anzahl der Datenblöcke haben, die von NetApp Snapshot-Kopien gespeichert werden müssen. Der Defragmentierungsprozess verändert Datenblöcke und NetApp Snapshot-Kopien bewahren ein stabiles, Point-in-Time-Image, indem sie geänderte Blöcke speichern. Je mehr Blöcke daher durch Defragmentierung geändert werden, desto mehr Platz brauchen Sie zum Speichern der Snapshot-Kopien.

Hier kommen nun die neuen Zahlen ins Spiel. Microsoft empfiehlt, dass die Defragmentierung in 14 Tagen abgeschlossen sein sollte. Wenn Sie also die Kennzahlen überprüfen und feststellen, dass die Defragmentierung bereits wesentlich früher abgeschlossen ist, können Sie das Fenster für die täglichen Online-Wartungsarbeiten verkleinern, um die täglichen Veränderungen auf den Festplatten zu verringern, was wiederum den Platzbedarf für Snapshot-Kopien reduziert.

Für noch präzisere Zahlen können zwei Performance-Messwerte protokolliert werden, um herauszufinden, wie der Trend bei Ihrer Online-Defragmentierung aussieht:

  • MSExchange Database ==> Instances\Online Defrag Pages Freed/Sec
  • MSExchange Database ==> Instances\Online Defrag Pages Read/sec.
Wenn das Verhältnis von „Read“ zu „Freed“-Seiten größer als 100:1 ist, sollten Sie das Fenster für Online-Wartungsarbeiten verkleinern. Wenn das Verhältnis von „Read“ zu „Freed“ kleiner als 50:1 ist, sollten Sie das Fenster für Online-Wartungsarbeiten vergrößern.

Datenbankscans und Page Zeroing. Standardmäßig sind Datenbankscans entweder aktiviert oder deaktiviert. Falls sie aktiviert sind, werden sie jede Nacht während Ihrer Online-Wartungsarbeiten durchgeführt. Das ist zwar in Ordnung, aber Sie sollten sich fragen, ob Sie wirklich Ihre Datenbank so häufig verifizieren müssen, da dabei im Prinzip die gesamte Datenbank Block für Block gelesen werden muss. Das erzeugt natürlich eine erhebliche zusätzliche Last für die Storage-Systeme.

Falls Page Zeroing für Sie nicht entscheidend ist und Sie NetApp SnapManager für Exchange verwenden, besteht eine Alternative darin, eine wöchentliche Backup-Kopie zu konfigurieren, die Ihre Logdateien nicht beeinträchtigt. Damit wird Ihre aktive Datenbank auf Korrumpierung überprüft und verifiziert. Das können Sie für das Wochenende einplanen, wenn der Workload geringer ist.

Falls Sie absolut Page Zeroing durchführen müssen, ist ein Datenbankscan jede Nacht die beste Möglichkeit, um sicherzustellen, dass dies auch durchgeführt wird. Sie sollten bedenken, dass dies beim ersten Mal eine extreme I/O-Last verursacht, falls bei der Datenbank nicht von Anfang an Page Zeroing aktiviert war. Um die Auswirkungen beim ersten Ausführen von Page Zeroing zu verringern, können Sie die Lastbegrenzung aktivieren.

Das Optimum aus Exchange 2007 SP1 herausholen

Exchange 2007 SP1 bietet so viele Verbesserungen und neue Funktionen, dass es fast wie ein neues Release von Exchange wirkt. Durch Beachten einiger weniger Best Practices können Sie das Optimum aus Ihrer Exchange-Installation und Ihrem NetApp Storage herausholen. Hier eine Zusammenfassung der aktuellen Best-Practice-Empfehlungen von NetApp für Exchange 2007 SP1.

LUN-Konfiguration und Replizierung
  • Isolieren Sie den Storage des aktiven und des Zielservers auf separate Storage-Systeme.
  • Konfigurieren Sie die aktiven und Zielsystem-LUNs hinsichtlich Kapazität und Performance identisch.
  • Teilen Sie Logdateien und Datenbanken auf eigene Aggregate auf.
  • Erstellen Sie ein separates NetApp FlexVol Volume für jede Storage-Gruppe.
  • Verwenden Sie NetApp RAID-DP für noch bessere Performance und Datensicherheit.
  • Führen Sie SnapManager für Exchange-Backups auf dem Zielsystem-Knoten aus und passen Sie das Fenster für die Online-Wartungsarbeiten auf dem aktiven Knoten an.
  • Erwägen Sie NetApp ReplicatorX und/oder SnapMirror, um einen RPO von weniger als 5 Minuten zu erzielen, wenn Sie Exchange-Datenbanken, Logdateien oder Hub-Transportdaten replizieren.
Defragmentierung und Datenbankscans
  • Verkleinern Sie das Fenster für Online-Wartungsarbeiten, wenn eine vollständige Defragmentierung innerhalb von zwei Wochen abgeschlossen ist und das Verhältnis von „Read“ zu „Freed“ größer als 100:1 ist.
  • Erwägen Sie die Verwendung einer Backup-Kopie (die keine Auswirkungen auf die Logdateien hat) und der Prüfsummenintegrität zum Validieren des Datenbankstatus als Alternative zu Online-Datenbankscans.
Robert Quimbey

Robert Quimbey
Microsoft Alliance Engineer
NetApp

Robert wechselte 2007 nach acht Jahren im Microsoft Exchange-Produktteam, wo er für Storage und Hochverfügbarkeit verantwortlich war, zu NetApp. Auch bei NetApp befasst er sich weiterhin schwerpunktmäßig mit Exchange 2007, einschließlich des Entwurfs von Best Practices und einer gründlichen Analyse von CCR-I/O (Clustered Continuous Replication). Aus seiner aktuellen Beschäftigung werden Referenzarchitekturen für Exchange hervorgehen.

Explore