Délais d’attente VSS dans Exchange
Challenge
Unfreeze error:[Backup job failed]
Cannot create shadow copy of the volumes containing writer’s data
A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer]. Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{0db23250-4d1e-42c1-8d14-2be32f448184}]. Writer’s state: [VSS_WS_FAILED_AT_FREEZE]. Error code: [0x800423f2].]
La connexion au serveur Exchange après la sauvegarde a échoué et utiliser l’invite pour entrer la commande « vssadmin list writers » affichera tous les writer et leur état en cours. En général, vous pourrez constater qu’un writer Exchange a échoué en raison d’une erreur de délai d’attente (code d’erreur 9).
Cannot create shadow copy of the volumes containing writer’s data
A VSS critical writer has failed. Writer name: [Microsoft Exchange Writer]. Class ID: [{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}]. Instance ID: [{0db23250-4d1e-42c1-8d14-2be32f448184}]. Writer’s state: [VSS_WS_FAILED_AT_FREEZE]. Error code: [0x800423f2].]
La connexion au serveur Exchange après la sauvegarde a échoué et utiliser l’invite pour entrer la commande « vssadmin list writers » affichera tous les writer et leur état en cours. En général, vous pourrez constater qu’un writer Exchange a échoué en raison d’une erreur de délai d’attente (code d’erreur 9).
Cause
Infrastructure
Voici comment fonctionne le processus de sauvegarde :
2.1. Il existe deux manières de provoquer un gel VSS de la VM : admin share (b) et VIX (a).
a) Nous nous connectons à VC sur VIX (tcp 443,902), VC passe par notre agent pour ESX/ESXi, ESX/ESXi transmet les données à l’intérieur de la VM, et notre agent est exécuté via les outils VMware.
b) Nous nous connectons à admin share et nous poussons notre agent via le protocole SMBFS/CIFS. Après avoir déployé notre agent, nous initions le gel VSS de la VM. Le compte à rebours commence au moment où la VM est gelée. En raison de sa conception par Microsoft, Exchange VSS ne peut rester figé plus de 20 secondes.
http://msdn.microsoft.com/en-us/library ... 15(v=vs.85)
2.2. Nous passons sur vSphere et nous créons un snapshot VMware de la VM.
2.3. Lorsque le snapshot VMware est créé, nous revenons à la VM et nous la dégelons.
2.4. Suivent le transfert de données puis la validation du snapshot.
Ainsi, entre l’étape 2.1 (démarrage du compte à rebours) et l’étape 2.3, nous avons seulement 20 secondes. Si Veeam ne gèle pas la VM en temps opportun, le sous-système Windows VSS le fait lui-même. D’où l’« unfreeze error » que vous obtenez.
La création du snapshot de la VM ne devrait prendre que quelques secondes ! Si elle dure plus longtemps, vous ne tiendrez pas dans les 20 secondes allouées.
Je dois également dire que les opérations via VIX sont plus lentes que les opérations via admin share.
De même, les opérations via un serveur ESX/ESXi sont généralement plus rapides que les opérations par serveur VC.
Voici comment fonctionne le processus de sauvegarde :
2.1. Il existe deux manières de provoquer un gel VSS de la VM : admin share (b) et VIX (a).
a) Nous nous connectons à VC sur VIX (tcp 443,902), VC passe par notre agent pour ESX/ESXi, ESX/ESXi transmet les données à l’intérieur de la VM, et notre agent est exécuté via les outils VMware.
b) Nous nous connectons à admin share et nous poussons notre agent via le protocole SMBFS/CIFS. Après avoir déployé notre agent, nous initions le gel VSS de la VM. Le compte à rebours commence au moment où la VM est gelée. En raison de sa conception par Microsoft, Exchange VSS ne peut rester figé plus de 20 secondes.
http://msdn.microsoft.com/en-us/library ... 15(v=vs.85)
2.2. Nous passons sur vSphere et nous créons un snapshot VMware de la VM.
2.3. Lorsque le snapshot VMware est créé, nous revenons à la VM et nous la dégelons.
2.4. Suivent le transfert de données puis la validation du snapshot.
Ainsi, entre l’étape 2.1 (démarrage du compte à rebours) et l’étape 2.3, nous avons seulement 20 secondes. Si Veeam ne gèle pas la VM en temps opportun, le sous-système Windows VSS le fait lui-même. D’où l’« unfreeze error » que vous obtenez.
La création du snapshot de la VM ne devrait prendre que quelques secondes ! Si elle dure plus longtemps, vous ne tiendrez pas dans les 20 secondes allouées.
Je dois également dire que les opérations via VIX sont plus lentes que les opérations via admin share.
De même, les opérations via un serveur ESX/ESXi sont généralement plus rapides que les opérations par serveur VC.
Solution
Ce problème est un problème d’infrastructure qui peut être difficile à cerner. Voici une liste complète des solutions mises en œuvre par les clients pour résoudre le problème :
- Assurez-vous d’abord que vous pouvez créer une sauvegarde Windows de la VM au moyen de VSS. Cela prouvera que le problème n’est pas spécifiquement lié à VSS, mais à une combinaison de VSS et de la technologie de snapshots VMware.
- Assurez-vous de n’avoir aucun autre agent de sauvegarde sur le serveur que vous sauvegardez et si tel est le cas, désinstallez-les. Si vous avez besoin d’effectuer des opérations VSS sur un SE invité, faites-le au moyen d’un seul produit de sauvegarde. Veuillez remarquer que Veeam utilise Microsoft VSS et que d’autres éditeurs de logiciels peuvent utiliser leurs propres fournisseurs/enregistreurs VSS et que ces solutions de sauvegarde effectuant des sauvegardes réussies ne constituent pas une comparaison valable.
- Redémarrage du serveur Exchange.
- Hôte ESX(i) ne disposant pas de ressources suffisantes.
- VSS désactivé pour la VM (sur supposition qu’il n’est pas nécessaire).
- Snapshot VMware d’une durée supérieure à 20 secondes (délai d’attente en dur de l’enregistreur VSS d’Exchange).
- Gel Exchange trop gourmand en E/S sur le temps de stockage et de sauvegarde et/ou le datastore Exchange doit éventuellement être modifié.
- Le service système de l’événement COM+ doit éventuellement être redémarré. Cause première inconnue. Dans certains cas, les clients ont intégré ce service à des scripts pour le redémarrer avant la sauvegarde.
- La latence entre VC et les hôtes peut permettre des sauvegardes VSS directement via l’hôte alors que passer par le VC provoque des problèmes de gel.
- Si Veeam n’a pas de communication directe avec Exchange, vous pouvez tester en mettant Veeam sur un réseau qui ne dispose d’aucune connectivité avec Exchange et voir si cela résout le problème. La communication réseau directe n’est toutefois pas nécessaire si les problèmes sous-jacents avec VIX se produisent, nous essayons alors d’utiliser IP pour communiquer et cela ne fonctionne pas correctement dans certains cas en raison de l’architecture du réseau.
-
Extrêmement important : si vous tentez d’utiliser le « mode sans connexion » pour VSS (c’est-à-dire s’il y a un pare-feu et que vous comptez donc sur l’API VIX pour communiquer), vous devez remplir au moins UNE des conditions suivantes :
1. Le compte utilisé pour le traitement prenant en compte les applications DOIT être soit l’administrateur « intégré » local, soit l’administrateur de domaine « intégré » (c’est-à-dire qu’il doit avoir un SID « bien connu » se terminant par 500). Les autres comptes d’administrateurs locaux ou de domaine ne fonctionneront pas.
--OU--
2. UAC doit être désactivé sur la VM invitée. Assurez-vous qu’il n’y a pas de snapshot en cours d’exécution sur la VM Exchange qui entraînerait des E/S de stockage supplémentaires non nécessaires.Le serveur Exchange peut nécessiter des ressources supplémentaires s’il est sollicité lors du dégel.
Vous n'avez pas trouvé ce que vous cherchiez ?
Ci-dessous, vous pouvez envoyer une idée pour un nouvel article de base de connaissances.
Report a typo on this page:
Please select a spelling error or a typo on this page with your mouse and press CTRL + Enter to report this mistake to us. Thank you!
Please select a spelling error or a typo on this page with your mouse and press CTRL + Enter to report this mistake to us. Thank you!
Spelling error in text
Knowledge base content request
