| VMware vCenter Site Recovery Manager 5.0.1 | 15 MARS 2012 | Build 633117 Dernière mise à jour : 9 mars 2016 Vérifiez les compléments et les mises à jour pour ces notes de mise à jour. |
Ces mises à jour contiennent les rubriques suivantes :
VMware vCenter Site Recovery Manager 5.0.1 présente les améliorations suivantes :
VMware vCenter Site Recovery Manager 5.0.1 est disponible dans les langues suivantes :
Pour les informations actuelles sur l'interopérabilité et la compatibilité des produits, consultez les Matrices de compatibilité pour VMware vCenter Site Recovery Manager.
Pour la liste actuelle des baies de stockage et adaptateurs de réplication de stockage compatibles pris en charge, consultez la Matrice de compatibilité des partenaires de stockage de Site Recovery Manager.
Les machines virtuelles qui résident sur vSphere Storage Appliance (VSA) peuvent être protégées par SRM 5.0.1 en utilisant VR (vSphere Replication). VSA ne nécessite pas d'adaptateur de réplication de stockage (SRA) pour fonctionner avec SRM 5.0.1.
SRM 5.0.1 peut être exécuté avec ESXi Server 4.0 et 4.1 et avec Virtual Infrastructure 3.5 uniquement si vous utilisez la réplication basée sur la baie. Si vous utilisez vSphere Replication, seul ou avec la réplication basée sur la baie, vous devez mettre à niveau les hôtes ESXi Server vers la version 5.0 ou ESXi Server 5.0 update 1 dans le cadre du processus de mise à niveau.
Pour installer SRM 5.0.1 sans effectuer de mise à niveau, reportez-vous à la section Installation et mise à jour de Site Recovery Manager dans le Guide d'administration de Site Recovery Manager .
Vous pouvez effectuer une mise à niveau sur place de SRM 5.0 vers SRM 5.0.1. VMware recommande les mises à niveau sur place plutôt que les installations complètes, car tous les rapports d'historique, plans de récupération, groupes de protection et personnalisations des plans de récupération sont ainsi conservés. Vous devez effectuer la procédure de mise à niveau sur le site protégé et sur le site de récupération.
VMware-srm-5.0.1- buildnumber.exe.Une fois que vous avez mis à niveau le serveur SRM, vous devez réinstaller le plug-in du client SRM.
SRM 5.0 inclut vSphere Replication 1.0. SRM 5.0.1 inclut vSphere Replication 1.0.1. La mise à niveau de SRM 5.0 vers SRM 5.0.1 ne met pas automatiquement à niveau vSphere Replication 1.0 vers vSphere Replication 1.0.1. vSphere Replication 1.0.1 est identique du point de vue des fonctions à vSphere Replication 1.0, avec l'ajout des correctifs de bogues.
Vous pouvez exécuter SRM 5.0.1 avec vSphere Replication 1.0, ou vous pouvez mettre à niveau vSphere Replication vers la version 1.0.1 pour bénéficier des correctifs de bogues dans la version 1.0.1. Vous mettez à niveau vSphere Replication Management Server (VRM Server) et les serveurs vSphere Replication (VR) Server séparément.
IMPORTANT : Ne sélectionnez pas l'option dans Mise à jour > Paramètres dans l'interface VAMI pour mettre à jour automatiquement vSphere Replication. Si vous optez pour les mises à jour automatiques, l'interface VAMI met à jour vSphere Replication vers la version 5.x la plus récente qui est incompatible avec SRM et vCenter Server 5.0.x. Vous devez par conséquent laisser le paramètre de mise à jour défini sur Aucune mise à jour automatique.
Mettez à niveau le VRM Server :
Mettez à niveau les serveurs VR Server :
Vous pouvez effectuer une mise à niveau sur place de SRM 4.1.2 vers SRM 5.0.1. VMware recommande les mises à niveau sur place plutôt que les installations complètes, car tous les rapports d'historique, plans de récupération, groupes de protection et personnalisations des plans de récupération sont ainsi conservés. Pour mettre à niveau le client SRM vers 5.0.1, vous devez préalablement désinstaller le client SRM 4.1.2.
REMARQUE : La mise à niveau de SRM 4.1 ou SRM 4.1.1 vers SRM 5.0.1 n'est pas prise en charge.
Pour mettre à niveau SRM 4.1.2 vers SRM 5.0.1, suivez la procédure de mise à niveau de SRM 4.1 ou de 4.1.1 vers SRM 5.0 dans Mise à niveau de SRM dans le Guide d'administration de Site Recovery Manager . Consultez également le blog SRM 5 Upgrade Process (Processus de mise à niveau de SRM) .
Les déclarations de droits d'auteur et les licences applicables aux composants logiciels open source distribués dans vCenter Site Recovery Manager 5.0.1 sont disponibles sur le site de téléchargements de SRM. Vous pouvez également télécharger les fichiers sources pour toute licence GPL, toute licence LGPL, ou d'autres licences similaires qui nécessitent la mise à disposition du code source ou des modifications du code source pour la sortie la plus récente de vCenter Site Recovery Manager qui est disponible en général.
Interopérabilité avec Storage vMotion et Storage DRS
En raison de certains cas spécifiques et limités où la récupérabilité peut être compromise durant le mouvement de stockage, l'utilisation de Site Recovery Manager 5.0.1 n'est prise en charge ni avec Storage vMotion (SVmotion) ni avec SDRS (Storage Distributed Resource Scheduler), de même que l'utilisation des clusters de banque de données. Si vous utilisez SVMotion pour transférer une machine virtuelle d'une banque de données, qui se trouve dans un groupe de protection, vers une banque de données non protégée, vous devez reconfigurer manuellement la protection de la machine virtuelle.
La conversion NAT (Network Address Translation) n'est pas prise en charge avec SRM
Lorsque vous configurez vSphere Replication, vous devez configurer vSphere Replication Server (VR Server) avec une adresse IP visible de vSphere Replication Management Server (VRM Server) et de Recovery VRM Server.
Intéroperabilité avec vCloud Director
Site Recovery Manager 5.0.1 fournit un support limité pour les environnements vCloud Director. Il n'est pas possible d'utiliser SRM pour protéger les machines virtuelles dans les pools de ressources vCloud (machines virtuelles déployées dans une organisation). Il est possible d'utiliser SRM pour protéger la structure de gestion de vCD. Pour plus d'informations sur l'utilisation de SRM pour protéger les instances vCD Server et vCenter Server, ainsi que les bases de données qui fournissent l'infrastructure de gestion pour vCloud Director, voir Étude de cas de résilience de l'infrastructure VMware vCloud Director.
Reprotection et retour arrière automatisé non pris en charge avec vSphere Replication
La reprotection et le retour arrière automatisé sont pris en charge uniquement avec les machines virtuelles répliquées basées sur la baie. Les machines virtuelles configurées avec vSphere Replication ne peuvent pas faire l'objet d'un retour arrière automatique vers le site d'origine en utilisant des plans de reprise d'activité existants.
Certaines fonctions vSphere et RDM ne sont pas prises en charge avec vSphere Replication
Vous ne pouvez pas utiliser vSphere Replication avec vSphere Fault Tolerance, les modèles de machines virtuelles, les clones liés et le mappage de disque brut physique (RDM).
Protection et récupération des machines virtuelles avec des snapshots d'état de mémoire
Lorsque vous protégez des machines virtuelles avec des snapshots d'état de mémoire, les hôtes ESX sur les sites de protection et de récupération doivent disposer de CPU compatibles, comme indiqué dans les articles Conditions de compatibilité de CPU VMotion pour les processeurs Intel et Conditions de compatibilité de CPU VMotion pour les processeurs AMD dans la base de connaissances VMware. Les hôtes doivent également avoir les mêmes fonctions BIOS activées. Si les configurations BIOS des serveurs ne correspondent pas, elles affichent un message d'erreur de compatibilité, même si elles sont identiques. Les deux fonctions devant, le plus souvent, être contrôlées sont : la Protection mémoire des microprocesseurs (NX / XD) et la Technologie de virtualisation (VT / AMD-V). Pour connaître les autres limitations de la protection et de la récupération des machines virtuelles avec des snapshots, voir Limitations de la protection et de la récupération des machines virtuelles dans le Guide d'administration de Site Recovery Manager .
Interopérabilité avec vSphere Replication
vSphere Replication prend en charge une taille maximale de disque de 2 032 Go.
Nombre maximum de plans de récupération par instance SRM Server
Vous pouvez créer la quantité suivantes de plans de récupération par instance SRM Server :
Pour connaître le nombre de plans de récupération que vous pouvez exécuter simultanément et les autres limites opérationnelles de SRM, voir le Guide d'administration de Site Recovery Manager .
Durant la migration planifiée, le serveur SRM donne d'abord l'instruction aux hôtes ESX de démonter les banques de données répliquées et de détacher les LUN assurant la sauvegarde de ces banques de données. Le SRM donne ensuite l'instruction au logiciel de baie de stockage de faire passer les LUN détachées en lecture seule. Ce processus permet de s'assurer que les périphériques sur les hôtes ESX ne rencontrent pas une condition APD (Tous chemins hors service) pour les banques de données et les LUN qui font l'objet d'une migration. La migration d'une machine virtuelle avec des RDM peut amener les LUN RDM à passer dans une condition ADP. Après que les RDM passent dans une condition ADP, les hôtes ESX continuent de réessayer d'établir la connectivité avec les LUN RDM perdues. Au fur et à mesure que le nombre de RDM indisponibles s'élève, le nombre de tentatives de l'hôte ESX pour se reconnecter aux RDM perdues augmente en conséquence. Alors que cela continue, l'hôte ESX peut être lent à répondre et vCenter Server peut finalement trouver que les hôtes répondent mal. Ce problème est plus susceptible de se produire avec certaines baies de stockage. Par exemple, le risque est plus important lors du support d'un SRA sur la cible iSCSI par LUN. Ce problème est maintenant corrigé.
Les tâches SRM sont supprimées du service vmware-dr une minute après la fin des tâches. Si SRM fait référence à un objet Tâche qui a été supprimé, il renvoie l'exception ManagedObjectNotFound et affiche le message d'erreur L'objet a déjà été supprimé ou n'a pas été créé complètement. Le délai de nettoyage des tâches par défaut est de une minute. Dans ce cas, vous pouvez configurer l'heure de nettoyage en définissant le paramètre Topology.drTaskCleanupTimedans le fichier config.xml.
<topology>
<drTaskCleanupTime>300</drTaskCleanupTime>
</topology>
Certains clients ayant acheté SRM 1.x et SRM 4.0 peuvent encore utiliser des licences allouées par CPU. Ils peuvent continuer à travailler avec SRM 5.0.1 en utilisant ces licences par CPU. Dans SRM 5.0, la formule de comptage du nombre de licences CPU utilisées est trop tolérante. Dans ce scénario, il est possible que la conversion accorde incorrectement un trop grand nombre de licences par CPU pour SRM 5.0. Ce problème a été résolu dans SRM 5.0.1 et il existe des avertissements plus stricts sur le nombre insuffisant de licences.
Si vous protégez une machine virtuelle contenue dans une banque de données répliquée répartie sur deux partitions de disque d'un même périphérique, SRM s'arrête de manière intempestive lors du recalcul du groupe de banques de données. Les journaux SRM contiennent l'erreur Panic: Assert Failed "ok" @ d:\build\ob\bora-474459\srm\public\persistence/saveLoadUtils.h:329. Dans ce cas, SRM Server ne redémarre pas. Ce problème a été résolu.
Si la communication réseau entre les sites protégés et de récupération est interrompue pendant moins de cinq minutes, SRM Server peut ne pas répondre. Ce problème est généré par le fait que SRM Server ne dispose pas des résultats de mise à jour et par l'expiration sur le serveur du délai d'attente des appels waitforupdate du site distant au cours de l'interruption réseau. Ce problème a été résolu en introduisant des délais d'attente côté client dans l'appel waitforupdate. Le délai d'attente par défaut côté client est de 5 minutes.
SRM 4.1 fournissait une option de configuration, storageProvider.hostRescanCnt, pour vous permettre d'analyser de manière répétitive les hôtes au cours du test et de la récupération. Cette option n'existait pas dans SRM 5.0, mais elle a été restaurée dans le menu Paramètres avancés dans SRM 5.0.1. Cliquez avec le bouton droit de la souris dans la vue Sites, sélectionnez Paramètres avancés, puis storageProvider. Consultez l'article KB 1008283 .
La personnalisation d'image des machines virtuelles Red Hat Enterprise Linux 5.x ne configure pas correctement la passerelle. Par conséquent, si vous affectez une nouvelle passerelle à la machine virtuelle RHEL 5.x en récupération au cours de la personnalisation, la nouvelle entrée de passerelle est ajoutée au fichier /etc/sysconfig/network-scripts/route-ethX . Le service réseau RHEL sélectionne la première entrée dans le fichier, à savoir l'ancienne passerelle sur le site de protection, au lieu de la nouvelle passerelle définie par l'utilisateur lors de la personnalisation. Ce problème a été résolu.
Suite à une suspension des sites protégé et de récupération, SRM Server côté récupération s'arrête de manière intempestive lorsque vous le redémarrez, en générant l'erreur CreateRemoteSuspendVmListViewAndCallback on Plan Recovery Plan on wrong context. Ce problème a été résolu.
Si vous utilisez SRM dans un environnement régional en chinois simplifié avec vCenter Server Appliance et que vous tentez de configurer une réplication vSphere sur une machine virtuelle, l'opération échoue avec une erreur d'environnement régional non valide. Ce problème a été résolu.
Dans certains cas, SRM s'arrête de manière intempestive au cours du démarrage lors de la vérification de l'utilisation de la licence CPU, en générant l'erreur Unexpected Object in results: vim.VirtualMachine. Ce problème a été résolu.
Au cours d'une mise à niveau sur place de SRM 4.1.x vers 5.0.x, SRM crée le fichier exportConfig.xml qui contient des informations des mappages d'inventaire, des mappages de banque de données, des machines virtuelles protégées et des groupes de machines virtuelles protégées, des plans de récupération, etc. Vous pouvez utiliser ce fichier pur migrer les données vers la base de données après la mise à niveau. Toutefois, si vous exécutez le programme d'installation SRM en mode de réparation avant de migrer les données vers la base de données, le programme supprime le fichier exportConfig.xml. Ce problème a été résolu et le programme d'installation en mode de réparation ne supprime plus le fichier exportConfig.xml.
La personnalisation IP des machines virtuelles échoue avec l'erreur There was an error in communication' Error code: '14010' lorsqu'elle tente de configurer les adaptateurs qui ne sont pas spécifiques de VMware. Ce problème a été résolu et la personnalisation IP ignore désormais les adaptateurs réseau qui ne sont pas des adaptateurs réseau par défaut et elle configure uniquement l'adaptateur physique.
L'exécution d'une récupération de test peut échouer avec l'erreur Panic: Assert Failed "runtimeInfo._results != 0 (Missing results in plan: recovery-plan-10257)" @ d:/build/ob/bora-474459/srm/src/recovery/engine/manager.cpp:1300^M. Ce problème apparaît, car les adaptateurs de réplication de stockage (SRA) permettent d'utiliser des ID identiques sur des périphériques de stockage différents, alors que SRM nécessite que les ID soient uniques. Ce problème affecte les récupérations de test, mais pas les récupérations réelles. Le problème a été résolu et SRM accepte désormais les ID de snapshot dupliqués.
Si plus de 30 réseaux sont disponibles dans l'environnement SRM, la liste complète des réseaux disponibles que vous pouvez sélectionner lorsque vous créez un plan de récupération n'est pas visible. Ce problème a été résolu et vous pouvez désormais faire défiler la liste complète.
Les problèmes connus suivants ont été rencontrés lors de tests rigoureux. Nous espérons qu'ils vous aideront à comprendre certains désagréments que vous pourriez rencontrer dans cette version.
Votre dispositif vSphere Replication peut être affecté par une vulnérabilité dans glibc qui autorise l'exécution de code distant.
Solution : Pour plus d'informations sur la manière de résoudre le problème, reportez-vous à l'article http://kb.vmware.com/kb/2144289
Lorsque les disques d'un volume supérieur à 256 Go sont protégés en utilisant VR (vSphere Replication), toute opération qui provoque un redémarrage interne du disque virtuel amène le disque à effectuer une synchronisation complète. Les redémarrages internes se produisent à tout moment :
La synchronisation complète est lancée par ESX, et toute résolution de ce problème nécessiterait une mise à jour d'ESX. Ces synchronisations nécessitent une E/S supplémentaire pour les disques du site protégé et du site de reprise, ce qui demande souvent plus de temps que l'objectif de point de récupération (RPO), ce qui entraîne une cible manquée de RPO. Ce problème existe dans ESXi Server 5.0, mais a été corrigé dans ESXi Server 5.0 update 1.
Solution : mettez à niveau ESXi Server vers la version 5.0 Update 1.
SRM ne prend pas en charge les environnements ESX dans lesquels l'indicateur LVM.enableResignature à la valeur 0. Au cours d'un basculement de test ou d'un basculement réel, SRM affecte automatiquement la valeur 1 à LVM.enableResignature si cet indicateur n'est pas déjà défini. SRM définit l'indicateur pour resigner les volumes de snapshot et il les monte sur les hôtes ESX pour la récupération. Une fois l'opération terminée, l'indicateur reste affecté de la valeur 1. Pour plus d'informations, voir l'article 2010051 dans la base de connaissances.
Error committing the transaction au cours de la configuration Si vous recevez le message Error committing the transaction au cours de la configuration de la réplication d'une machine virtuelle et que vous tentez de reconfigurer la réplication sur la machine virtuelle, l'opération échoue. Ce problème survient, car vSphere Replication ne nettoie pas correctement les données de configuration après la tentative de configuration. Par conséquent, la réplication de la machine virtuelle apparaît configurée pour vSphere Replication alors qu'elle ne l'est pas.
Solution : pour nettoyer correctement les données de configuration, désactivez la réplication de la machine virtuelle depuis la ligne de commande.
# vim-cmd vmsvc/getallvms | grep
virtual_machine_name
L'ID de la machine virtuelle est le nombre figurant dans la première colonne.
# vim-cmd hbrsvc/vmreplica.disable
virtual_machine_ID
Si vous exécutez un plan de récupération en sélectionnant l'option de basculement forcé et revenez à la migration planifiée en sélectionnant Migration planifiée, la case du basculement forcé reste cochée et elle est estompée dans l'assistant d'exécution d'un plan de récupération. Ce problème affecte uniquement l'interface utilisateur et SRM fonctionne correctement.
Solution : fermez et rouvrez l'assistant d'exécution d'un plan d'un récupération après avoir désélectionné l'option de basculement forcé.
Au cours d'une récupération et d'une migration, les machines virtuelles réservées sont remplacées par des machines virtuelles récupérées. Si vous disposez d'un cluster avec plusieurs hôtes sur le site de récupération, toutes les banques de données réservées doivent être disponibles pour tous les hôtes du cluster, car dans le cas contraire, la permutation des machines virtuelles échoue. SRM ne vous empêche pas de sélectionner des banques de données réservées qui ne sont pas disponibles pour tous les hôtes du cluster. Si les banques de données réservées ne sont pas visibles de tous les hôtes, le plan de récupération échoue avec l'erreur Error - Unable to access file [datastore]" Unable to access file [datastore] Failed to unregister protected VMs. Les hôtes doivent avoir accès aux banques de données qui contiennent à la fois les machines virtuelles réservées et les machines virtuelles récupérées.
Solution : vérifiez manuellement que les banques de données des machines virtuelles réservées et récupérées sont visibles de tous les hôtes du cluster protégé.
Si vous mettez à niveau une installation existante du dispositif VRMS (vSphere Replication Manager Server) de la version 1.0 vers la version 1.0.1, les numéros de version de VRM Server et de VR Server ne sont pas mis à jour dans l'onglet du récapitulatif des machines virtuelles. Lorsque vous sélectionnez le serveur VRM Server ou un serveur VR Server dans l'inventaire vCenter Server, l'onglet du récapitulatif affiche toujours la version 1.0.0.0, même si le serveur VRM Server a été mis à jour vers la version 1.0.1. Si vous effectuez une nouvelle installation de VRM Server version 1.0.1, l'onglet du récapitulatif affiche le numéro de version correct.
Solution : vérifiez le numéro de version dans l'interface de gestion du dispositif virtuel VRMS :
Vous pouvez également afficher le numéro de version correct dans la console du serveur VRM Server ou VR Server dans vSphere Client.
Vous pouvez configurer VRMS (vSphere Replication Management Server) pour utiliser des bases de données non prises en charge ; la configuration VRMS aboutit sans avertissements sur le support des bases de données. Toutefois, l'utilisation d'une base de données non prise en charge peut générer un comportement imprévisible. Les bases de données suivantes ont été testées complètement et sont prises en charge totalement avec VRMS :
Les basculements test et réels peuvent s'arrêter avec l'erreur Failed to create snapshots of replica devices for group 'protection-group-999' using array pair 'array-pair-999': Vmacore::SystemException "The parameter is incorrect. " (87). Cette erreur est due à une gestion incorrecte du fuseau horaire que la baie de stockage retourne au SRA. Ce problème est commun à tous les horodatages antérieurs au 1er janvier 1970. Pour obtenir des informations détaillées et une solution, voir KB 2018597.
srm-migration importConfig échoue en raison de la modification des ID des objets de la banque de données. Le processus de mise à niveau SRM 5.0.1 se termine sans erreur, vCenter Server redémarre, et les hôtes, les invités et le stockage se mettent tous en ligne, dans le même état que lorsque le service vCenter Server a été arrêté. Toutefois, lors de la migration SRM, l'importation du groupe de protection échoue avec l'erreur suivante :
Protection des VM ignorée pour toutes les VM dans le groupe ( groupe) en raison d'une erreur : Une ou plusieurs banques de données sont déjà protégées dans un autre groupe ou ne sont pas répliquées actuellement.
Les ID des objets de la banque de données répertoriés dans le fichier SRM exportConfig.xml sont différents des mêmes ID des objets de la banque de données qui sont affichés dans le navigateur MOB. Ce problème est lié à celui décrit dans KB 2007404.
Solution : Modifiez le fichier exportConfig.xml afin d'utiliser les ID des objets de la banque de données du navigateur MOB, puis réexécutez la commande srm-migration importConfig.
Lorsque vSphere Client démarre, il détermine le paramètre régional sur lequel il fonctionne, puis choisit l'ensemble des messages à afficher sur la base du paramètre régional. Lorsque vSphere Client est installé sur un système d'exploitation coréen, le client demande des messages du dossier kodepuis l'installation vCenter Server parce que vCenter Server et vSphere Client sont localisés pour la Corée. Bien que vCenter Server et vSphere Client soient localisés pour la Corée, SRM ne l'est pas. Par conséquent, les messages XXXs'affichent, à la place des messages du serveur SRM. Pour résoudre ce problème, créez une copie du dossier enqui se trouve dans C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\com.vmware.vcDr\locale\. Renommez le dossier de envers koet redémarrez vCenter Server et les services SRM.
Dans de rares circonstances, cette erreur peut se produire lorsque vous configurez la personnalisation d'IP ou une légende d'invité pour la machine virtuelle et que le cluster du site de récupération est en mode DRS entièrement automatisé. Un vMotion inattendu peut provoquer une interruption de communication temporaire avec la machine virtuelle, entraînant l'erreur de script de personnalisation.
Solution : Exécutez à nouveau le plan de récupération. Si l'erreur persiste, configurez le DRS du cluster du site de récupération en mode manuel et relancez le plan de récupération.
Erreur lors de la création d'une image de bulle de test pour le groupe ... L'exception détaillée est Erreur lors de l'obtention de montages d'hôte pour la banque de données : managed-object-id...ou L'objet a déjà été supprimé ou n'a pas été complètement créé. Si vous exécutez une récupération test ou une récupération planifiée et si le plan de récupération échoue avec l'exception spécifique, le LUN utilisé pour stocker les données de réplication a été temporairement déconnecté d'ESXi. Une fois reconnectée, la réplication se poursuit normalement et aucune données de réplication n'est perdue. L'exception se produit au cours de ces scénarios :
Vous devez reconfigurer manuellement la réplication pour actualiser le nouvel ID.
Solution : Si le site principal n'est plus disponible, contactez l'assistance VMware pour obtenir des instructions sur la mise à jour manuelle de la base de données VRMS avec le nouvel ID d'objet géré de la banque de données. Si le site principal est toujours disponible :