New Blog

Dear reader,

To work more inline with my twitter activities and to open my blog for more interessting stuff (not just Veeam related), I am blogging only on the http://andyandthevms.com/ blog from now.

If I will write some updates at individual posts (e.g. Exchange Backup stuff) I will add an warning message with a link to the article on this blog.

So do not hesitate to check out my new blog under http://andyandthevms.com

Thanks for all the Feedback and support

Andy

Freitag, 30. November 2012

Exchange Backup unter VMware Herausforderungen gelöst *UPDATE3*

Please find updated Version here:
http://neufert-at-veeam.blogspot.de/2014/03/exchange-dag-vmware-backups-updated.html



Versionshinweise:
*Update1*
Danke an Claus Pfleger für die vielen Hinweise


Backup von Exchange über die VMware VADP Schnittstelle (welche auch Veeam nutzt) kann einige Herausforderungen mit sich bringen, die häufig im Vorfeld schon durch das passende Design gelöst werden können.
Die hier beschriebenen Lösungen sind teilweise meine eigenen Erfahrungen und teilweise auf den Beiträgen des Veeam Forums basierend. Ich hoffe hier hat niemand etwas dagegen, dass ich Sie hier komprimiert zusammenfasse (einfach melden). Ziel ist auch gewesen, das ganze auf Deutsch aufzubereiten.


Quellen:

VSS timeout with Exchange 2010
Issue with VMware & Exchange 2010 DAG

Es gibt bei der Verwendung eines Exchange DAG Clusters auf Virtualisierungsumgebungen bzw. bei dem Backup von großen Exchange Umgebungen zwei Dinge zu beachten.
1) DAG Cluster Heart Beat Einstellungen (hier muss aktiv in jedem Fall etwas getan werden)
2) Fest in Exchange eingebautes Timeout für den VSS (Backup-) Konsistenzstatus von 20 Sekunden (hier nur tätig werden bei Errors)

Diese Zusammenfassung soll Sie nicht verschrecken, sondern gleich im Vorfeld auf mögliche Herausforderungen hinweisen, um im Vorfeld schon dagegen zu wirken und um dementsprechend in keine Dienstausfälle für die Benutzer zu laufen.

Zu 1) DAG Cluster Heart Beat Einstellungen
In einem DAG Cluster tauschen die DAG Nodes Heartbeats aus, um zu prüfen ob alle Knoten noch online sind. Wird ein festgelegter Wert überschritten, schwenkt das Cluster und die aktiven Datenbanken der nun mehr nicht aktiven Cluser-Node, werden auf einem der anderen DAG Member aktiviert. Dies ist in der Regel transparent für die User. Es kann jedoch vorkommen, dass durch häufige Schwenks z.B. Index Dienste die Systeme so auslasten, dass das Userverhalten beeinträchtigt wird. Dies kann vor allem vorkommen wenn nach kurzer Zeit mehrere Schwenks vorkommen. Die Situation dargestellt: Backup Server 1 ist fertig, Schwenk durch Auflösen des Snapshots auf Server 2 => Server 2 wird kurze Zeit später wieder fertig und löst Snapshot auf => Somit wieder Schwenk auf Server 1 => Indexdienst Auslastung kann dann so hoch sein, dass User beeinträchtigt werden.


Auf Seiten von VMware und dessen VADP Backup Schnittstelle wird ein VM Snapshot nach der Herstellung des Konsistenzstatus erzeugt, um danach sofort den Konsistenzstatus wieder aufzulösen. Dies dauert in der Regel nur einige Sekunden, in denen der Konsistenzstatus etwas Performance kostet. Der Snapshot gibt dem Backup die Möglichkeit,  ohne den Konsistenzstatus aufrechterhalten zu müssen, auf den im Snapshot eingefrorenen konsistenten Status zuzugreifen.
Bei VMware werden bei einem VM Snapshot die Daten der aktuell laufenden VM in einen separaten Storageplatz gelegt. Wird nach dem Backup der Snapshot aufgelöst, werden portionsweise diese Daten in den ursprünglichen Storage-Bereich der VM übertragen. Dies verursacht für eine kurze Zeit sehr viel Random Write I/Os.  Wird eine dieser Daten -„Portionen“ zurückgeschrieben, wird die VM kurz eingefroren bis Datenmenge der „Portion“ geschrieben wurde. Dies dauert in der Regel nur einige Millisekunden und die VM läuft aus Sicht des Benutzer ohne Ausfall weiter. Es kann jedoch vorkommen, dass das Zurückschreiben  etwas länger dauert und die VM gerade dann nicht - oder verzögert den Heartbeat sendet. Es kann dadurch zu einem Schwenk des DAG Clusters kommen. Auswirkungen siehe oben.
Um dies zu vermeiden gilt es folgendes zu beachten:

  1. Verwendung von schnellem Storage für die Exchange Server damit das Schreiben der Snapshot commits nur sehr kurz dauert.
  2. Erzeugen von möglichst wenig Änderungen in der Zeit des Backups, damit weniger Daten vom ausgelagerten Snapshot Bereich zurück geschrieben werden müssen.
    a. Deaktivierung von Hintergrunddiensten von Exchange in dieser Zeit (z.B. Datenbank Aufräumservicezeit in den Datenbankoptionen)
    b. Möglichst wenig Usertraffic => Backup Zeit so legen, dass möglichst wenig Benutzer arbeiten.
    c. Falls möglich Mails im E-Mail-Annahmeserver in dieser Zeit cachen und erst danach an die Datenbank DAG Server weiterreichen.
  3. Möglichst viel Storage Performance Ressourcen freihalten. I/O Belastung des Storage möglichst klein halten.
    a. Keine anderen Backupjobs auf oder von dem Storagesystem, das die Exchange Datenbanken hält, laufen lassen.
    b. Möglichst wenig Hintergrundbelastung auf dem Storagesystem verursachen (z.B. SQL Batch Läufe die meist nachts laufen)
    c. Keine Virus Scans, Viren Signaturverteilung und Windows Updates in dieser Zeit,  => belasten Storage Systeme
  4. Verwendung der neuesten Veeam Backup & Replication Version bzw. der neuesten anderen Backup Software (meist neuestes VMware VDDK Kit integriert). Installation von aktuellen Patches der vSphere Umgebung (wichtig)
  5. Zweingend ist das Hochsetzten der Cluster Heartbeat Timeout Zeit notwendig:
    cluster /prop SameSubnetDelay=2000:DWORD
    cluster /prop CrossSubnetDelay=4000:DWORD
    cluster /prop CrossSubnetThreshold=10:DWORD
    cluster /prop SameSubnetThreshold=10:DWORD

    Ein Neustart scheint hier nicht erforderlich, da das DAG Cluster die Änderungen sofort annimmt.
  6. Falls dies alles nichts geholfen hat, kann in Abstimmung mit VMware folgender VMX Eintrag bei den DAG Member VMs (Offline) gesetzt werden.
    snapshot.maxConsolidateTime = "1"
    1 entspricht 1 Sekunde
    Dies setzt die Zeit für das Schreiben der Snapshot Restore „Portionen“ herunter, was dazu führt, dass wir nicht in den Heartbeat Timeout laufen. Dies sollte in Abstimmung mit dem VMware Support erfolgen, da der Schalter undokumentiert ist. Weiterhin sollte man mit einem Überwachungstool (Veeam ONE, vCOPS) das Snapshot Alter der VM überwachen (Länger als 10 Stunden=Alert), um zu prüfen ob der Snapshot auch wirklich immer sauber aufgelöst wird und wie lange dies dauert.

    *UPDATE1* Neuer Text
  7.  Hat dies alles nichts geholfen oder wollen Sie von vorne herein auf Nummer sicher gehen,  ist ein DAG Member zu installieren, welcher nur inaktive Datenbankrepliken aller DAG Members enthält. Nur dieser Server ist dann zu sichern. Da es hier durch Snapshot commit zu keinem Clusterschwenk kommen kann umgehen wir hier das Problem. Beim Restore kann Veeam hier einzelne Objekte (z.B. Mails) mit dem Veeam Explorer for Exchange zurückspielen. Das nach erfolgreichem Backup stattfindende truncaten der Logs wird durch Exchange automatisch an alle Member weitergereicht.
  8. *UPDATE2* Neuer TextWird Veeam Backup & Replication eingesetzt kann es helfen Forward Incrementals mit Syntetic Fulls zu verwenden. Soll aus Platzgründen Reverse Incremental verwendet werden kann anstatt dessen auch Forward Incremental mit Syntetic Fulls und TÄGLICHEN Transform into Rollbacks die bessere Wahl sein.
  9. *UPDATE2* Neuer TextvSphere 4.x legt die Snapshot Dateien in der Regel neben das VMX File. Ist dieses Volume nicht schnell genug kann es zu Snapshot auflösen Problemen kommen (siehe oben). Lässt sich anpassen.
    vSphere 5.x legt die Snapshot Dateien neben die passenden VMDKs und kann helfen das Problem zu beheben.
  10. *UPDATE3* Neuer Text Mit Version 7 bringt Veeam dire Möglichkeit mit in der Enterprise Plus Version Storage basierte Snapshots zu Entlastung von VMware VM Snapshots zu verwenden. Hier bei wird sofort nach dem VM Snapshot ein Storage Snapshot erzeugt und sofort wieder der VM Snapshot commited. In diesen Sekunden fallen nur wenige Änderungsdaten an und der Snapshot commit stellt keine Herausforderung mehr dar.



Zu 2) Fest in Exchange eingebautes Timeout für den VSS (Backup-) Konsistenzstatus von 20 Sekunden
Die weitere Herausforderung ist, dass in Microsoft Exchange fest hinterlegte Exchange VSS Writer timeout von nur 20 Sekunden. D.H. man hat 20 Sekunden Zeit Exchange in den Konsistenzmodus zu versetzten, einen VMware VM Snapshot zu erzeugen und den VSS Konsistenzstand wieder aufzulösen. Ist dies alles nicht innerhalb der 20 Sekunden passiert, löst Exchange den VSS Konsistenz Stand von alleine auf und es kommt in der Backup Software zu einem Fehler. Bei Veeam ist dies meist der VIX-Error.



Beim Backup wird folgendes Ausgeführt:
 
Non Veeam
VSS wird über Standard VMware Tools angesprochen (Non Application Aware Backup. Dies hat zur Folge, dass oftmals von MS dies als non supportet bezeichnet wird. Auch findet hier kein LogFile truncation statt

Veeam

  1. Veeam verbindet sich über das vCenter oder dem ESX durch die VMware Tools hindurch auf den Exchange Server und startet den Veeam VSS Requestor on the fly. Alternativ verbindet sich Veeam über das Netzwerk zum Admin Share und übergiebt das den Veeam VSS Requestor dort. (Benötigt eine ausgeschaltete Windows UAC oder einen Benutzer mit exactem Namen und Rechten des „Administrator“)
  2. Alle VSS Writer werden ausgelesen (unter anderem auch Exchange) (manuell über „vssadmin list writers“ möglich)  und diese werden benutzt um die Konsistenz herzustellen.
  3. Ein VM Snapshot wird erzeugt.
  4. Der VSS Konsistenzstatus wird aufgelöst.
  5. Weitere Schritte (Backup)

Zwischen 2. wenn der Exchange VSS Requestor benutzt wird und 4. dürfen maximal 20 Sekunden vergehen. Dauert es länger, löst der Exchange Writer automatisch den Konsistenzstatus wieder auf. Es folgt ein VSS Error (dass der Konsistenzstatus hart von Exchange beendet wurde) und Veeam erzeugt einen Error „VIX“ bzw. andere Backup Software erzeugen hoffentlich auch einen Error.
Um dem Entgegenzuwirken kann man folgendes tun:

  1. Schnellen Storage verwenden (Block Storage für die Datastores meist weniger betroffen als NFS-Shares)
  2. Snapshot Zeit im vCenter überwachen. Zwischen Absetzten des Kommandos und Fertigstellen des Snapshots darf nur eine kurze Zeit (kleiner 10 Sekunden) vergehen.
    a. Je mehr Volumes die VM hat desto länger dauert der Snapshot
    b. Eventuell vCenter Performance optimieren (Patches, Leistung CPU RAM Disk I/O, richtige SQL Datenbank verwenden anstatt Express).
    c. Wenn alles nichts hilft, Hinzufügen des ESX Servers zu Veeam Backup und Auswahl des Exchange Servers per ESX Host und nicht per VCenter + Passendes setzen, dass die VM auf dem Host nur im HA fall wegmigriert wird)
  3. Umsetzten der Reihenfolge mit der Veeam der VM das Tool übergibt. Dies ist nur Erforderlich falls der Veeam Server nicht per Netzwerk auf den Admin Share des Servers zugreifen kann. Ist dies nicht Möglich wartet Veeam etwas und startet den Vorgang dann direkt über die VMware Tools. Wenn Sie also kein Zugriff per Netzwerk haben, macht es Sinn die Wartezeit für den Netzwerkconnect zu umgehen und gleich über die VMware Tools die Verbindung aufzubauen. Dies kann man erzwingen mit dem Registry Key: InverseVssProtocolOrder DWORD 1  (HKLM/Software/Veeam/Backup & Replication/) und Neustart der Veeam Dienste auf dem Veeam Backup & Replication Server in. Der Modus durch die VMware Tools ist an sich selbst langsamer und nur zu setzten wenn keine Netzwerkverbindung zwischen dem Veeam Server und dem Exchange Server möglich ist.
  4. Neustart des Servers vor dem Backup  (oder Neustart von COM+  und Exchange Dienste) ACHTUNG: Neustart nur des COM+ Dienstes behebt zwar den Fehler, leert aber die VSS Writer Liste für einige Zeit. Somit schließt der Backup Job erfolgreich ab (weil der Exchange VSS writer für die Backupsoftware nicht da ist und somit auch nicht verwendet wird), aber es wird KEIN konsistentes Backup erzeugt. Datenverlust/ Probleme beim Restore!
    Beim Neustart des Servers sind folgende Vorbereitungen zu treffen:
    a) Der zu verwendende Exchange DAG Server darf nur inaktive Datenbanken halten (1 Server für Backup.
    b) Um einen Clusterschwenk zu vermeiden, müssen a
    lle Datenbanken auf dem zu sichernden Server im DAG als nicht aktiv gehalten werden.
    c) Der Server wird mit einem Skript (Windows Taskplaner) kurz vor dem Backup neu gestartet. Dies führt in der Regel dazu, dass der Exchange VSS Writer deutlich weniger Zeit für die Konsistenz benötig.
    c) Wird der Server dann erfolgreich gesichert, werden automatisch auch die Logs der anderen Datenbankserver truncated. (Im Windows Ereignislog der Exchange Server gegenprüfen, wenn Sie keine Veeam Backup Server einsetzten)
  5. Mehr RAM/CPU Ressourcen am Exchange DAG Server
  6. Oftmals müssen auch mehr Disk Ressourcen für ALLE Volumes (auch OS) hinzugefügt werden.

Zusammenfassend möchte ich nochmals betonen, dass diese Herausforderungen auf Seiten VMware Snaphshot/Exchange Kombination liegen, dementsprechend sind viele Backuptools, die die VMware Schnittstellen für Backup nutzen, aber auch agentenbasierte Backuptools (20 Sekunden) betroffen.
Unter Hyper-V/Exchange/Veeam gibt es die VSS 20 Sekunden Timeout Herausforderung nur bei grottenschlechter Disk Performance, da ein Volume Snapshot im Storagesystem anstatt eines VM Snapshot (mit Snapshot commit Herausforderung) erzeugt wird.

Ich hoffe diese Informationen können helfen, Exchange DAG Cluster und Exchange Server erfolgreich zu sichern um somit auch einen erfolgreichen Restore anzubieten.

Für diejenigen, die Veeam Backupsoftware nicht einsetzten, empfehle ich auch einen Blick auf die kostenfreie Veeam Backup free Edition zu werfen. Mit ihr kann man auch einzelne Exchange Objecte (Mails usw.) aus einer mit einem anderen Backuptool gesicherten Exchange Datenbankdatei exportieren (PST) und in dem Produktions Exchange über Outlook (PST load) restoren. Hierzu müssen lediglich die Datenbank Dateien auf einem Medium liegen, dass die Veeam Software "Veeam Explorer for Exchange" lesen kann.

Happy Backup and Restore... Andy


Keine Kommentare:

Kommentar veröffentlichen

Dieses Blog durchsuchen