Grundlegendes zur Exchange 2010-LUN-Architektur

  • Artikel

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Häufig wird der physikalische Datenträger oder die optimale logische Gerätenummer (Logical Unit Number, LUN), der/die vom Betriebssystem erkannt wird, von der Hardware abstrahiert, die verwendet wird, um den Datenträger dem Betriebssystem zu präsentieren. Die LUN-Architektur wird in Microsoft Exchange Server 2010 verwendet.

Wenngleich es für den Entwurf von LUNs in Exchange 2010 viele Möglichkeiten gibt, werden zum Eingrenzen der Komplexität die beiden folgenden Entwürfe empfohlen:

  • Eine LUN pro Datenbank

  • Zwei LUNs pro Datenbank

  • Zwei LUNs pro Sicherungssatz

Eine LUN pro Datenbank

Bei einer Architektur mit einer LUN pro Datenbank werden sowohl die Datenbank als auch ihre entsprechenden Protokolldateien in derselben LUN abgelegt. Zum Bereitstellen einer LUN-Architektur mit nur einer LUN pro Datenbank müssen Sie über eine Datenbankverfügbarkeitsgruppe mit zwei oder mehr Kopien verfügen und dürfen keine hardwarebasierte Volumeschattenkopie-Dienstlösung (Volume Shadow Copy Service, VSS) verwenden.

Diese Strategie hat u. a. folgende Vorteile:

  • Vereinfachung der Speicherverwaltung durch eine kleinere Anzahl zu verwaltender LUNs

  • (Potenzielle) Reduzierung der Anzahl der Sicherungsaufträge

  • Flexibilität zum Isolieren der Leistung zwischen Datenbanken, wenn Spindeln nicht zwischen LUNs gemeinsam verwendet werden

Ein Nachteil dieser Strategie ist, dass die Möglichkeit hardwarebasierter VSS-Sicherungs- und Wiederherstellungsvorgänge (z. B. das Klonen von Momentaufnahmen) eingeschränkt wird. Weitere Informationen zu VSS finden Sie unter Best Practices für die Verwendung des Volumeschattenkopie-Diensts (VSS) mit Exchange Server 2003.

Zurück zum Seitenanfang

Zwei LUNs pro Datenbank

Unter Exchange 2010 und bei maximal 100 Datenbanken hängt die Anzahl der bereitgestellten LUNs von Ihrer Sicherungsstrategie ab. Wenn die angestrebte Wiederherstellungsdauer sehr kurz ist oder Sie VSS-Klone (Volume Shadow Copy Service, Volumenschattenkopie-Dienst) für eine schnelle Wiederherstellung verwenden, ist es ggf. am besten, jede Datenbank ihrer eigenen Transaktionsprotokoll-LUN und Datenbank-LUN zuzuordnen. Da dabei die Anzahl verfügbarer Laufwerkbuchstaben überschritten wird, muss der Volumebereitstellungsdienst verwendet werden.

Diese Strategie hat u. a. folgende Vorteile:

  • Ermöglichung von hardwarebasiertem VSS auf Datenbankebene sowie der Sicherung und Wiederherstellung einzelner Datenbanken

  • Flexibilität zum Isolieren der Leistung zwischen Datenbanken, wenn Spindeln nicht zwischen LUNs gemeinsam verwendet werden

  • Höhere Zuverlässigkeit, da sich ein Kapazitäts- oder Datenbeschädigungsproblem einer einzelnen LUN nur auf eine Datenbank auswirkt. Dies ist ein wichtiger Aspekt, wenn Sie nicht die integrierten Ausfallsicherheitsfunktionen von Postfächern nutzen.

Diese Strategie hat z. B. die folgenden Nachteile:

  • 100 Datenbanken erfordern 200 LUNs, wodurch Maximalwerte bestimmter Speicherarrays überschritten werden könnten

  • Eine separate LUN für jede Datenbank sorgt für mehr LUNs pro Server, wodurch sich Verwaltungsaufwand und -komplexität erhöhen

Zurück zum Seitenanfang

Zwei LUNs pro Sicherungssatz

Ein Sicherungssatz entspricht der Anzahl der Datenbanken, die pro Nacht vollständig gesichert werden. Eine Lösung, die pro Nacht eine vollständige Sicherung von 1/7 der Datenbanken durchführt (z. B. bei Verwenden einer wöchentlichen oder zweimonatlichen vollständigen Sicherung mit täglichen inkrementellen oder differenziellen Sicherungen), kann die Komplexität reduzieren, indem alle zu sichernden Datenbanken derselben Protokoll- und Datenbank-LUN zugeordnet werden. Dadurch kann die Anzahl der LUNs auf dem Server verringert werden.

Diese Strategie hat u. a. folgende Vorteile:

  • Vereinfachung der Speicherverwaltung durch eine kleinere Anzahl zu verwaltender LUNs

  • (Potenzielle) Reduzierung der Anzahl der Sicherungsaufträge

Diese Strategie hat z. B. die folgenden Nachteile:

Zurück zum Seitenanfang

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.