Problème
Un hôte de sauvegarde VMware peut accéder aux données de machine virtuelle à partir des stockages de données à l’aide de quatre méthodes différentes : SAN, LAN(NBD), HotAdd et NBDSSL. Ces méthodes sont appelées modes de transport VMware. Cet article aborde ces modes de transport, les recommandations en la matière et les conseils de dépannage pour certaines erreurs couramment observées avec ces modes de transport dans NetBackup et Backup Exec.
Solution
Pour les opérations de sauvegarde et de restauration, NetBackup et Backup Exec permettent de choisir l’un des quatre modes de transport ou une combinaison de plusieurs modes. Si une combinaison de modes de transport est indiquée, NetBackup et Backup Exec les testent tous un par un jusqu’à pouvoir accéder aux données de la machine virtuelle.
Détails sur chacun des modes de transport
1. SAN : le mode de transport SAN requiert que l’hôte de sauvegarde VMware réside sur un ordinateur physique ayant accès au SAN Fibre Channel ou iSCSI qui contient les disques virtuels auxquels vous souhaitez accéder. Il s’agit d’un chemin d’accès aux données efficace, car aucune donnée ne doit être transférée via l’hôte ESX/ESXi de production.
Dans ce mode, les API vStorage obtiennent des informations du serveur vCenter ou de l’hôte ESX/ESXi sur la structure des LUN VMFS. Sur la base de ces informations, elles lisent les données directement depuis le SAN ou le LUN iSCSI sur lequel le VMDK réside.
Recommandations pour le mode de transport SAN :
- Pour l’utilisation du mode de transport SAN, assurez-vous que les LUN de stockage de données sont accessibles par l’hôte de sauvegarde VMware.
- Le transport SAN est généralement le meilleur choix pour les sauvegardes lorsqu’elles s’exécutent sur un hôte de sauvegarde physique VMware. Cependant, il est désactivé dans les machines virtuelles. Vous devez donc plutôt utiliser HotAdd sur un hôte de sauvegarde virtuel VMware.
- Le transport SAN n’est pas toujours le meilleur choix pour les restaurations. Il offre les meilleures performances sur les disques pré-alloués, mais n’est pas performant sur les disques à allocation dynamique en raison du fonctionnement des API vStorage. Pour la restauration de disques à allocation dynamique, LAN(NBD) est plus rapide.
- Pour les restaurations SAN, la taille de disque doit être un multiple de la taille de bloc VMFS sous-jacente, sinon l’écriture sur la dernière fraction d’un disque échouera. Par exemple, si le disque virtuel a une taille de bloc de 1 Mo et si le stockage de données est de 16,3 Mo, la dernière fraction de 0,3 Mo ne sera pas inscrite. Dans ce cas, la solution de contournement consisterait à utiliser NBD pour les restaurations de ces machines virtuelles.
- Lors de l’utilisation du transport SAN ou du mode d’ajout à chaud sur un hôte de sauvegarde VMware s’exécutant sous Windows Server 2008/2008 R2, veillez à définir :
- la stratégie SAN sur onlineAll ;
- le disque SAN en lecture seule, excepté pendant les restaurations.
2. LAN (NBD) : dans ce mode, l’hôte ESX/ESXi lit les données à partir du stockage et les envoie à l’hôte de sauvegarde VMware via un réseau. Comme son nom l’indique, ce mode de transport n’est pas sans fil à la différence du transport SAN.
Le transport LAN offre les avantages suivants :
- L’hôte ESX/ESXi peut utiliser n’importe quel périphérique de stockage, y compris le stockage local ou NAS.
- Le serveur de sauvegarde VMware peut être une machine virtuelle. Ainsi, vous pouvez utiliser un pool de ressources et les capacités de planification de VMware vSphere pour réduire l’impact des sauvegardes sur les performances. Par exemple, vous pouvez placer l’hôte de sauvegarde VMware dans un autre pool de ressources que les hôtes ESX/ESXi de production et définir une priorité inférieure pour la sauvegarde.
- Si l’hôte ESX/ESXi et l’hôte de sauvegarde VMware sont sur un réseau privé, vous pouvez utiliser le transfert de données non chiffré, qui est plus rapide et consomme moins de ressources que NBDSSL. Si vous devez protéger des informations sensibles, vous avez la possibilité de transférer les données de machine virtuelle à un format chiffré à l’aide de NBDSSL.
Recommandations avec le transport LAN :
- Dans ce cas, puisque les données sont lues par le serveur ESX/ESXi à partir du stockage avant d’être envoyées à l’hôte de sauvegarde VMware, la connectivité réseau entre le serveur ESX/ESXi et l’hôte de sauvegarde VMware est obligatoire. Si l’hôte de sauvegarde VMware est connecté au serveur vCenter mais pas au ESX/ESXi, les snapshots aboutissent, mais les opérations de lecture/écriture de VMDK échouent.
- L’hôte de sauvegarde VMware devra pouvoir se connecter au port TCP 902 sur les hôtes ESX/ESXi si vous utilisez NBD/NBDSSL pour la sauvegarde et les restaurations.
- VMware utilise le protocole NFC (Network File Copy) pour lire le VMDK à l’aide du mode de transport NBD. Vous avez besoin d’une connexion NFC pour chaque fichier VMDK en cours de sauvegarde. Le nombre de connexions NFC pouvant être établies par le serveur ESX/vCenter est limité. Ces limites varient dans les différentes versions de vSphere. Veuillez consulter le Guide de l’administrateur NetBackup for VMware (lien ci-dessous) pour connaître ces limites. Les opérations de sauvegarde/restauration à l’aide de NBD peuvent être bloquées si cette limite est atteinte.
3. HotAdd : lorsque vous exécutez l’hôte de sauvegarde VMware sur une machine virtuelle, les API vStorage peuvent exploiter la fonction d’ajout à chaud SCSI du serveur ESX/ESXi pour joindre les fichiers VMDK d’une machine virtuelle en cours de sauvegarde à l’hôte de sauvegarde VMware. On parle de mode de transport HotAdd.
L’exécution du serveur de sauvegarde VMware sur une machine virtuelle a deux avantages : le déplacement d’une machine virtuelle est aisé, et le stockage local peut être sauvegardé sans utiliser le réseau local, bien que cela entraîne des surcharges supplémentaires sur l’hôte ESX/ESXi physique par rapport au mode de transport SAN.
Recommandations avec le transport HotAdd :
- HotAdd fonctionne uniquement avec les machines virtuelles équipées de disques SCSI et n’est pas pris en charge pour la sauvegarde de machines virtuelles équipées de disques IDE.
- Un maximum de 15 disques peuvent être joints à un seul contrôleur SCSI. Pour exécuter plusieurs travaux simultanés représentant plus de 15 disques, il est nécessaire d’ajouter davantage de contrôleurs SCSI à l’hôte HotAdd. Un maximum de quatre contrôleurs SCSI peuvent être ajoutés à un hôte HotAdd, ce qui signifie qu’un maximum de 60 périphériques sont pris en charge.
- HotAdd requiert que l’hôte de sauvegarde VMware ait accès aux stockages de données sur lesquels réside la machine virtuelle en cours de sauvegarde. Dans le fond, cela signifie que :
- l’hôte ESX sur lequel l’hôte de sauvegarde VMware s’exécute doit avoir accès aux stockages de données sur lesquels réside la machine virtuelle en cours de sauvegarde ;
- l’hôte de sauvegarde VMware et la machine virtuelle en cours de sauvegarde doivent être dans le même centre de données.
- HotAdd ne peut pas être utilisé si la taille de bloc VMFS du stockage de données contenant le dossier de machine virtuelle pour la machine virtuelle cible ne correspond pas à la taille de bloc VMFS du stockage de données contenant la machine virtuelle de l’hôte de sauvegarde VMware. Par exemple, si vous sauvegardez un disque virtuel sur un stockage de données doté de blocs de 1 Mo, l’hôte de sauvegarde VMware doit également être sur un stockage de données doté de blocs de 1 Mo.
- Les restaurations à l’aide de HotAdd sur un proxy Windows Server 2008 nécessitent de définir la stratégie SAN sur onlineAll
- Si vous convertissez un ordinateur physique en une machine virtuelle dans l’intention d’utiliser HotAdd pour sauvegarder la machine virtuelle, n’utilisez pas les contrôleurs IDE pour tous les disques qui interviennent durant le processus de conversion.
- L’hôte de sauvegarde VMware devra pouvoir se connecter au port TCP 902 sur les hôtes ESX/ESXi si vous utilisez HotAdd pour la sauvegarde et les restaurations.
4. NBDSSL : NBDSSL est identique à NBD, à l’exception près que NBDSSL utilise SSL pour chiffrer toutes les données transmises via la connexion TCP/IP.
Dépannage pour certains échecs courants liés au mode de transport
Les sauvegardes/restaurations échouent avec l’état 6, 13 ou 11, et l’indication suivante dans le moniteur d’activité peut laisser supposer un problème avec les modes de transport :
- ERR - Erreur lors de l’ouverture des disques du snapshot à l’aide du/des mode(s) de transport donné(s) : état 23 indique qu’un problème s’est produit lors de l’accès au vmdk à l’aide du mode de transport donné.
Voici quelques conseils pour résoudre ce type d’erreur :- Si vous utilisez NBD, assurez-vous que l’hôte de sauvegarde VMware est connecté au serveur ESX qui héberge la machine virtuelle.
- Si vous utilisez SAN, assurez-vous que les LUN de stockage de données sont accessibles par l’hôte de sauvegarde VMware.
- Si vous utilisez HotAdd, assurez-vous que votre hôte de sauvegarde est une machine virtuelle et que les conditions suivantes sont remplies :
- La machine virtuelle ne doit pas contenir de disques IDE.
- Assurez-vous qu’il y a suffisamment de contrôleurs SCSI connectés sur la machine virtuelle de l’hôte de sauvegarde.
- La machine virtuelle de l’hôte de sauvegarde a accès aux stockages de données sur lesquels réside la machine virtuelle en cours de sauvegarde.
- La machine virtuelle de l’hôte de sauvegarde et la machine virtuelle en cours de sauvegarde doivent être dans le même centre de données.
- Si la sauvegarde précédente a échoué, certains disques de la machine virtuelle de sauvegarde sont peut-être connectés à l’hôte de sauvegarde. Ces disques doivent être supprimés manuellement avant de tenter la prochaine sauvegarde.
- Si un port autre que les ports vCenter par défaut est utilisé, ce port doit être défini lors de l’ajout des informations d’authentification de vCenter à NetBackup ou Backup Exec.
- Si vous utilisez NBD/NBDSSL/HotAdd, assurez-vous que l’hôte de sauvegarde VMware est en mesure de communiquer sur le port 902 du serveur ESX qui héberge la machine virtuelle.
- Échec d’analyse du fichier indique qu’un problème s’est peut-être produit lors de la lecture du VMDK à l’aide du mode de transport donné.
- Échec d’écriture du fichie indique qu’un problème s’est peut-être produit lors de l’écriture du VMDK à l’aide du mode de transport donné.
- Si vous utilisez SAN pour les restaurations, assurez-vous que les LUN de stockage de données sont accessibles par l’hôte de sauvegarde VMware et à un état en ligne.
- Si vous utilisez HotAdd pour la restauration, assurez-vous que la stratégie SAN sur l’hôte de sauvegarde est définie sur OnlineAll.
- Si vous utilisez SAN pour la restauration, assurez-vous que la taille du VMDK est un multiple de la taille de bloc de stockage de données. Dans le cas contraire, l’écriture du dernier bloc échouera. Dans ce cas, une solution de contournement consisterait à utiliser NBD pour la restauration.
- Assurez-vous d’affecter les privilèges nécessaires à l’utilisateur configuré dans NetBackup ou Backup Exec pour se connecter à vSphere.