Exchange 2010 - LUN größer als 2 TB

[Maraun 12]

Hallo zusammen,

 

wir nutzen mittlerweile VMWare 5.5 für unsere Exchange 2010 Serverfarm, die mit Veeam gesichert werden.

Die Datenbank liegt auf einer präsentieren 2 TB RAW LUN.
 

Die Datenbank macht die LUN allmählich voll und wir wollen jetzt folgendes durchführen:
Eine neue VMDK GPT erstellen und an die VM präsentieren. Die Datenbank auf einen der beiden Postfachserver moven und vom anderen Postfachserver die Datenbank per Robocopy auf die neue Platte kopieren.

Damit umgehen wir das 2 TB Datenlimit der LUN und wandeln gleichzeitig notwendigerweise die RAW LUN in VMDK für das Backup mit Veeam.

 

Ist das so praktikabel und machbar?

Gibt es Einwände bezüglich Exchange 2010?

Was muss ich bei dem Datenbank-Kopie beachten?
Kann die Datenbank-Kopie per Robocopy kopiert werden oder muss ich die Datenbank dismounten?

Gibt es per Powershell für die Datenbank-Kopie Befehle?

 

Danke vorab und viele Grüße

Alex

 

[NorbertFe 1.799]

Du willst ernsthaft im Fehlerfall eine 2TB Datenbank wiederherstellen? Oder nutzt ihr DAG und ein erprobtes Recovery-Konzept?

 

Bye

Norbert

[Dukel 436]

K.a. ob dies mit einer DAG so funktioniert. Ggf. musst du die DB Kopie stoppen oder auflösen.

 

Ich würde das anders machen:

- Neue Disk erstellen, DB auf dieser erstellen

- Postfächer in neue DB moven

- Alte DB und Disk entfernen

[NorbertFe 1.799]

DAG Kopie auflösen. Disk dismounten, neue Disk mounten mit der entsprechenden Größe und Datenbankkopie neu erzeugen. Dürfte von vorübergehender Redundanz abgesehen die sicherste Methode sein. MIt Robocopy würde ich da nicht rumfumeln.

[Maraun 12]

Hallo zusammen,

 

zunächst mal danke für die wahnsinnig schnellen Antworten.

Wollte gerade noch den Disk dismount und die Pfadänderung anbringen, da sehe ich schon drei Antworten.

Norbert, zu Deiner ersten Frage:

Wir nutzen eine DAG mit Datenbankkopie. Ich würde die VM´s vorher natürlich sichern.

Ansonsten ist mein geplantes Vorgehen wie in Deinem zweiten Post von Dir beschrieben.

Zusätzliche Platte erstellen und präsentieren. DAG Kopie auflösen, Disk dismounten, Datenbank mit neuem Pfad versehen (move database path).

Was ich noch gelesen habe: Die DB-Kopien und physischen Daten sollte ich auch vom ursprünglichen DB-Pfad in den neuen kopieren.

Grüße

Alex

[NilsK 2.781]

Moin,

 

ich komme aber noch mal auf Norberts erste Frage zurück: Seid ihr euch sicher, dass ihr dauerhaft mit einer Exchange-Datenbank im Terabyte-Bereich umgehen wollt?

 

Gruß, Nils

[Maraun 12]

Sorry, die Frage hatte ich überlesen bzw. falsch verstanden.

Wir haben 5 DB´s im Einsatz, die jetzt in der Summe die 2TB der LUN so langsam ausfüllen.

 

Grüße

Alex.

[Dukel 436]

Wieso dann nicht pro DB eine LUN (plus eine für die Transaktionsprotokolle)?

[RobertWi 81]

Moin,

 

die Pfad müssen innerhalb einer DAG übrigens identisch sein, d.h. die Kopie liegt auf den Knoten immer im gleichen Pfad. Daher geht nur Norberts Weg, wie er ihn in #4 beschrieben hat.

 

Oder Du musst die Disks auf allen Knoten ändern.

[Maraun 12]

@Dukel:

Habe ich mir ehrlich gesagt noch nicht überlegt. Aber ich sehe die Notwendigkeit da nicht darin.

Wir archivieren fleißig aus den Postfächern und sammeln auch die PST´s mittlerweile aus dem Netzwerk ein.

Postfächer wachsen nicht mehr in dem Maße. Ich denke, mit 4 TB Gesamtgröße für die 5 DB´s sind wir gut aufgestellt.

 

Nochmals zum Vorgehen:

Auf Server 3 ist jetzt z. B. eine DB gemounted und aktiv, deren edb-File auf der Partition E: liegt.

Auf Server 4 liegt davon eine Kopie.

Ich präsentiere die neue VMDK GPT mit 4TB an den Server 4.

Ich dismounte die aktive DB Kopie (Suspend databse Copy).

Muss die DB auch dismounted werden?
Alle Database Kopien von Server 3 und 4 entfernen (remove database copy).

Daten der Database Kopie vorhalten.

Jetzt wähle ich bei der dismounted DB Copy Move DB Pfad, gebe den Pfad der neuen VMDK und der edb an.

Zum Schluss verschiebe ich auf Server 4 die physischen Daten der DB auf die neue VMDK.

Mount DB und DB Kopie neu erzeugen.

 

Ist das so richtig?

http://www.telnetport25.com/2012/07/exchange-2010-moving-the-database-path-on-dag-servers/

 

Mit der aktiven DB mache ich nichts?
Ich verschiebe nur den Pfad der DB Kopie?

 

Danke und viele Grüße

Alex

bearbeitet 1. Oktober 2014 von Maraun

[RobertWi 81]

Moin,

 

in Deinem Link fehlt IMHO ein Schritt, so dass das nicht gehen wird.

 

Bei Deinem Ablauf sind gleich mehrere "Fehler" drin.

 

Mehr schreibe ich, wenn ich in 45 Minuten im Büro bin.

[NorbertFe 1.799]

Wie kommt man auf die Idee 5 Dbs in eine Lun zu packen. Ich ja ja mal davon aus, dass das dann auch nur ein Volume ist. Da sieht man ja nie wirklich einfach welche dB grad Probleme machen kann. Mal davon abgesehen, dass du jetzt grad merkst, dass du alle Kopien gleichzeitig auflösen musst um Änderungen durchzuführen. Ich würde da mal drüber nachdenken, an dieser Stelle meine Konfiguration zu ändern. Dann braucht man auch keine 4tb Lun.

[Maraun 12]

Die zwei großen DB´s haben 752 bz. 950 GB.

Die drei anderen DB´s kann man eher vernachlässigen.

Das heißt, ich überdenke die Konfig und splitte die beiden großen DB´s auf jeden Fall in jeweils eine LUN auf.

Die drei weiteren DB´s packe ich dann in eine weitere LUN.

Somit hätte ich drei LUN´s für 5 DB´s und die großen zwei gesplittet.

 

VMDK GPT´s in VM;Ware 5.5 stellen mit Exchange 2010 keine Probleme dar?

[NorbertFe 1.799]

Du hast dann aber konkurrierende iops. Ist zwar meist zu vernachlässigen, aber rein vom Handlung würde ich das trennen. Außerdem schau dir mountpoints an, dann brauchst du auch keine laufwerksbuchstaben.

[RobertWi 81]

Moin,

 

so.... Erst mal muss ich Norbert recht geben. Ein solches Design würde ich nicht machen. Kleinere DB und kleinere Volumes haben diverse Vorteile. Eine Aufteilung DB/LOG wie weiter oben beschrieben ist ok, aber nicht zwingend notwendig.

 

Zu dem Ablauf:

Im Link fehlt der Hinweis, dass man die Copy mit der Shell anlegen muss: Add-MailboxDatabaseCopy -Identity DAG-DB3 -MailboxServer MBX-3 -SeedingPostponed:$TRUE 

 

Das Problem ist, dass schon Dateien im Ordner sind und das mag eine DAG-Kopie eigentlich nicht. Mit dem Schalter erklärt man, dass das Seeding bereits erfolgt ist. Referenz - Klick.

 

In Deinem eigenen Ablauf gibt es diverse "Fehler". 

 

> Auf Server 3 ist jetzt z. B. eine DB gemounted und aktiv, deren edb-File auf der Partition E: liegt.

> Auf Server 4 liegt davon eine Kopie.

 

Es gibt also nur zwei Kopien der DB? Oder liegt auf einem Server 2 auch noch eine?

 

> Ich präsentiere die neue VMDK GPT mit 4TB an den Server 4.

> Ich dismounte die aktive DB Kopie (Suspend databse Copy).

> Muss die DB auch dismounted werden?

 

Es wird immer die Datenbank dismounted, nicht eine Kopie.

 

> Alle Database Kopien von Server 3 und 4 entfernen (remove database copy).

 

Wenn es keine weitere Kopie gibt, dann sind danach Deine Daten weg. Also gibt es wohl noch eine Kopie auf Server 2? Sonst kannst Du natürlich nur die Kopie auf Server 4 löschen, Server 3 ist ja dann die einzige Kopie und damit das Original.

 

> Daten der Database Kopie vorhalten.

> Jetzt wähle ich bei der dismounted DB Copy Move DB Pfad, gebe den Pfad der neuen VMDK und der edb an.

 

Nochmal: Alle Kopien einer DB haben den GLEICHEN Pfad. Du kannst nicht den Pfad einer Kopie verschieben, nur der Datenbank! Und das geht auch nur, solange es nur eine Kopie der DB gibt. 

 

Du solltest den Fall mal mit einer leeren Test-DB durchspielen.