Exchange-VM-Defragmentierung oder ESEUTIL? Verwende ich den richtigen Ansatz zur Defragmentierung/Fehlerüberprüfung meines Exchange-VM-Servers?

Exchange-VM-Defragmentierung oder ESEUTIL? Verwende ich den richtigen Ansatz zur Defragmentierung/Fehlerüberprüfung meines Exchange-VM-Servers?

Szenario:

  1. Exchange 2010 VM, läuft auf VMWare
  2. 120 GB Daten
  3. Lauffenster Samstag 00:00-8:00 Uhr (kann bei Bedarf etwas verlängert werden)

Zwei actiongeladene Fragen:

  1. Ich möchte meine Datenspeicher aushängen, einen Snapshot meiner Exchange-VM erstellen, eine Defragmentierung auf Laufwerksebene der Laufwerke C und D (Datenbank) ausführen, die Datenspeicher erneut aushängen und den Snapshot entfernen (wenn alles in Ordnung ist).

  2. Meine andere Option ist: Machen Sie einen Snapshot meiner Exchange-VM, hängen Sie die Datenspeicher aus, führen Sie ESEUTIL offline aus und defragmentieren Sie das Laufwerk C (nicht Laufwerk D?), mounten Sie die Datenspeicher erneut und entfernen Sie den Snapshot (wenn alles in Ordnung ist).

Was denken Sie? Verfolge ich die richtige Vorgehensweise beim Defragmentieren/Fehlerprüfen meines Exchange-Servers?

Antwort1

Bevor ich mir die ganze Arbeit mache und das Laufwerk und die Datenbanken defragmentiere, nur um eine allgemeine Warnmeldung zu erhalten, würde ich ein paar Dinge tun:

  1. Was erwarten Sie davon? Die Fragmentierung des Exchange-Servers ist für Ihre Benutzer weitgehend irrelevant, wenn sie alle den Outlook-Cache-Modus verwenden. Wenn Exchange über genügend RAM verfügt, speichert es Teile jedes Postfachs im RAM, sodass Ihre Festplatten weniger wichtig werden. Modernes Exchange ist eigentlich für die Ausführung aufLangsamerFestplatten dann altes Exchange (2000/2003).

  2. Die Defragmentierung innerhalb einer VM ist nicht das, was Sie denken. Sie haben mehrere Abstraktionsebenen zwischen Ihren physischen Festplatten und den Exchange-Datenbanken. Sie haben ein RAID-Set, das eine LUN von einem gemeinsam genutzten Satz von iSCSI-Festplatten bereitstellt. Woher wissen Sie, ob diese LUN auf den tatsächlichen Festplatten zusammenhängend ist? Ich bezweifle, dass dies der Fall ist, insbesondere wenn sie Thin Provisioning verwendet. Dann haben Sie eine .vmdk-Datei, die Sie in VMWare erstellt haben und die wahrscheinlich selbst fragmentiert ist. Haben Sie Thin Provisioning verwendet oder die .vmdk-Größe nach der ersten Erstellung jemals geändert? Wenn Sie alle diese verschiedenen Ebenen durchlaufen würden, beginnend mit iSCSI, dann zu vmdk, dann zum Gastbetriebssystem, dann zu Exchange... was würde das Ergebnis sein? Vielleicht schnelleres OWA, wenn das so ist...

Unterm Strich habe ich noch nie erlebt, dass virtuelle Produktionssysteme defragmentiert wurden und tatsächlich zu einer Verbesserung der Benutzererfahrung führten. Ich sage nicht, dass das unmöglich ist ... Ich sage nur, dass es unwahrscheinlich ist.

Tipps zu VMWare-VMs und Defragmentierung: http://blogs.vmware.com/vsphere/2011/09/should-i-defrag-my-guest-os.html

Ein interessantes Zitat aus diesem Link:

„Ich möchte darauf hinweisen, dass ich gelesen habe, dass wir intern bei VMware nach einer Defragmentierung von Gastbetriebssystemen, die auf SAN- oder NAS-basierten Datenspeichern liegen, keine merkliche Leistungsverbesserung festgestellt haben.“

verwandte Informationen