Le serveur VM NetWorker perd son disque dur toutes les nuits

Exécution du serveur EMC NetWorker sur une VM Server 2008 R2 w/ sp1 exécutée sur un hôte ESXi. Le VMDK est stocké sur une machine VNXe avec les VMDK de tous les autres serveurs VM utilisés par notre organisation. Aucune des autres machines virtuelles ne présente ce problème :

Chaque nuit de la deuxième moitié de cette semaine, peu après 21 heures, ce serveur perd son disque dur. En vérifiant les systèmes le matin, je trouve cette machine assise à l'invite de démarrage après avoir essayé PXE et elle signale qu'elle ne peut pas trouver de périphérique de démarrage. En vérifiant les paramètres de la VM, je constate qu'aucun disque dur n'est attaché à la machine.

La récupération est aussi simple que d'affecter un nouveau disque dur au système et de le faire pointer vers le VMDK existant qui se trouve toujours sur le magasin de données hébergé sur le VNXe.

Le serveur vSphere ne signale aucun problème ni aucune erreur.

Il n'y a aucune information dans le journal du système sur le serveur lui-même, donc je suis presque sûr qu'il n'a aucune idée de ce qui lui est arrivé.

Le problème a commencé lorsque j'ai commencé à augmenter les sauvegardes à l'aide du système NetWorker, en ajoutant de nouveaux hôtes à sauvegarder. Actuellement, je ne sauvegarde que les hôtes virtuels en utilisant le proxy VADP configuré intégré au serveur NetWorker, ainsi qu'un serveur SQL de test (également une VM) en utilisant le client NetWorker installé sur cette machine. Je sauvegardais le serveur NetWorker lui-même, car la documentation indiquait que cela ne devrait pas poser de problème, mais j'ai désactivé cette sauvegarde peu après avoir découvert ce problème.

J'ai besoin de savoir comment et pourquoi le VMDK se détache du serveur NetWorker. Il serait bon que quelqu'un me le dise explicitement, mais de l'aide pour trouver les journaux vSphere montrant tout ce qui se passe avec les systèmes serait un bon point dans la bonne direction.

MISE À JOUR : détails supplémentaires

Les sauvegardes des VMs sont programmées pour commencer à 21 heures chaque nuit.

À partir des journaux de vSphere pour cette VM :

• 21/21 à 9:00:11pm : Tâche : Créer un instantané de la machine virtuelle.
• 2/22 à 2:18:57am : Tâche : Supprimer le snapshot. Il s'agissait de la première tentative de sauvegarde programmée de cette VM FROM elle-même et indique le fonctionnement correct et réussi du système de sauvegarde.
• 2/22 : Je migre la machine vers un hôte ESXi différent (il y a trois hôtes identiques dans une configuration HA) afin de mieux organiser les ressources.
• 2/22 à 9:00:15pm : Tâche : Reconfigurer la machine virtuelle. C'est la première fois que le disque dur est retiré de la VM.
• 23 février vers 8 h 25 : en vérifiant les systèmes, je constate que le disque dur manque sur cette VM pour la première fois. Cela m'amène à penser que l'opération Snapshot déclenchée par la sauvegarde programmée de NetWorker est traduite par l'hôte ESXi en "retirer le disque dur de cette VM".
• 2/23 à 9:00:14pm : Tâche : Reconfigurer la machine virtuelle.
• 2/24 J'ai rattaché le disque dur et désactivé toutes les sauvegardes planifiées de cette VM dans NetWorker.
• 24/02 à 21:31:32 : Tâche : Reconfigurer la machine virtuelle.
• 25/02 à 21:00:15, 26/02 à 21:00:11 : La même tâche de reconfiguration de la machine virtuelle supprime le disque dur de cette VM. et je le rattache le lendemain matin.

Sur la base de ce journal, je dois vérifier les points suivants :

• Le problème persiste-t-il lorsque la VM est exécutée sur un autre hôte ?
• Le problème persiste-t-il lorsqu'aucune sauvegarde n'est exécutée ?

Je vais les vérifier et faire un rapport sur le succès ou l'échec.

Mise à jour 2 : rapport de dépannage

Une autre chose que j'ai trouvée : Dans la configuration de chaque client VM dans NetWorker, il y a un endroit pour enregistrer l'hôte ESXi sur lequel se trouve la VM. Lorsque je vMotionne une VM vers un hôte ESXi différent, cette valeur n'est pas mise à jour, même si la détection automatique de VM est activée dans NetWorker. J'ai donc mis à jour cette valeur dans la configuration du client VM sur l'hôte ESXi actuel. Ce serait bien si AutoDetect la mettait à jour lui-même.

Donc, pour faire un rapport sur le dépannage que j'ai essayé hier :

Tout d'abord, le disque dur était toujours attaché ce matin, ce qui confirme que le problème était au moins déclenché par NetWorker. J'ai désactivé toutes les sauvegardes hier, et j'ai déplacé le serveur NetWorker vers un nouvel hôte ESXi. J'ai également mis à jour les informations sur l'hôte ESXi mentionnées dans le paragraphe précédent.

Aujourd'hui, j'ai réactivé la plupart des sauvegardes (en laissant de côté les systèmes à haute disponibilité comme SQL et Exchange.

Si le disque dur est retiré ce soir, c'est la configuration de sauvegarde qui pose problème.

Si le disque dur n'est PAS retiré ce soir, alors ce sont les informations de configuration de l'hôte ou l'hôte lui-même qui causent le problème.

Mise à jour 3 : Suivi du dépannage

Le disque dur a encore été perdu la nuit dernière, ce qui signifie que le problème vient probablement de la configuration de NetWorker.

Juste pour récapituler : La nuit dernière, j'ai exécuté des sauvegardes programmées de plusieurs VM (mais pas du serveur NetWorker) et juste après 21 heures, j'ai vu les mêmes entrées de journal que celles que j'ai notées plus tôt dans la question, ce qui fait qu'il n'y a plus de disque dur associé à la VM.

Il y a une autre chose que je vais essayer : D'après la documentation d'EMC, le serveur NetWorker peut également être un nœud de stockage, et la plupart des VM traitent leurs sauvegardes via ce nœud (ceci est séparé du VADP). Je vais les désactiver à travers les sauvegardes du nœud et voir si cela fait une différence.

De même, les sauvegardes physiques du système et une sauvegarde NDMP à partir de nos NAS/disques réseau fonctionnent correctement.

Je vais commencer à isoler les VM et à les ajouter une par une à la sauvegarde pour voir si je peux déterminer si une VM particulière est à l'origine du problème. C'est quelque chose que je devrais être en mesure de tester pendant les heures de travail.

UPDATE : Les tests font la lumière

Ok, le problème est que chaque fois que j'essaie de sauvegarder une VM en utilisant VADP.

J'ai testé la sauvegarde de machines virtuelles en cours d'exécution et hors tension en utilisant diverses permutations de paramètres, et le seul facteur déterminant pour savoir si le serveur NetWorker perdait son lecteur était le fait que j'avais ou non installé le client NetWorker sur la machine virtuelle cible et que je sauvegardais à l'aide du client NetWorker ou de VADP.

Lorsque vous configurez une sauvegarde à l'aide de l'assistant client, vous choisissez d'abord si vous configurez un nouveau proxy VADP, ou un client de sauvegarde VM, ou un client NetWorker.

Si vous choisissez le client de sauvegarde de la VM, vous pouvez ensuite choisir de la sauvegarder en utilisant VADP (par défaut) ou le client NetWorker installé sur la VM (si vous avez besoin de configurations spéciales pour la sauvegarde). VADP touche le VMDK réel et s'intègre à VMWare. NetWorker "sait" toujours que le client est une VM, mais il peut être utilisé pour spécifier des lecteurs particuliers, VSS et d'autres fonctions. VADP sauvegarde les VM sans utiliser de ressources invitées, en s'appuyant entièrement sur l'hôte ESXi. Le logiciel client NetWorker utilise les ressources du client pour exécuter la sauvegarde.

Ainsi, l'exécution d'une sauvegarde VADP d'un hôte VM est ce qui supprime le disque dur du serveur NetWorker. Et il y a plus d'entrées de journal qui apparaissent dans le client vSphere lorsque le disque dur est abandonné :

• Environ 20 secondes après le lancement d'une sauvegarde proxy VADP, vSphere signale une tentative de migration du serveur NetWorker de VM2 à VM2
• alors le serveur NetWorker est réinitialisé
• puis un événement indique "un ticket de typemks a été acquis".
• puis un avertissement concernant la quantité de mémoire vidéo attribuée à la VM
• enfin un rapport indiquant que la VM du serveur NetWorker est sous tension.