Configuration de la connectivité du réseau

HCX doit traverser l'Internet public et des lignes privées, et se connecter à des composants de centre de données, comme des réseaux, des commutateurs et des groupes de ports.

• Pour plus d'informations sur les ports devant être ouverts pour que les dispositifs virtuels HCX puissent s'installer correctement, voir Accès aux ports requis.
• L'environnement vSphere sur site et l'environnement VMware Cloud Foundation for Classic - Automated HCX Cloud doivent permettre la synchronisation de l'horloge par le protocole NTP (Network Time Protocol) entre les dispositifs vSphere sur site et les dispositifs VCF for Classic - Automated HCX. Le port UDP 123 doit être accessible aux dispositifs virtuels et aux réseaux HCX.

Environnement local

Avant d'installer HCX, vérifiez que votre environnement peut prendre en charge les tâches que vous voulez accomplir. L'environnement local doit prendre en charge les tâches suivantes pour que HCX puisse être installé.

• Virtual Center avec vSphere 5.5 Update 3 ou 6.0 Update 2.
• vMotion et les fonctions de migration des politiques requièrent la version NSX 6.2.2 ou une version ultérieure.
• Un compte de service vSphere avec le rôle d'administrateur qui lui est attribué.
• Dans vCenter, espace disque suffisant pour l'installation des dispositifs HCX.
• Nombre d'adresses IP suffisant pour les machines virtuelles en local mises à disposition durant l'installation.
• Ports et pare-feux ouverts, comme indiqué dans la section Accès aux port requis.
• Si le serveur SSO est distant, l'URL du vCenter, du serveur SSO externe, ou le contrôleur PSC (Platform Services Controller) qui exécute le service de recherche externe doivent être identifiés. Lorsque HCX Manager est enregistré auprès de vCenter, cette URL doit être fournie.
• Si un site VMware vCenter® ne dispose pas de sa propre instance interne du service de recherche, c'est peut-être pour l'une des raisons suivantes.
  • vCenter 6.0u2 exécute un contrôleur de service de plateforme externe.
  • vCenter est en mode lié (où le site vCenter secondaire utilise le service SSO du site vCenter principal ou un service SSO externe).

Vérification de l'environnement d'installation de couche 2

L'extension réseau de couche 2 doit respecter les règles suivantes :

• vSphere édition Enterprise Plus.
• Le site vSphere vCenter doit répondre aux exigences suivantes pour prendre en charge l'extension de la couche 2 :
  • Licence vSphere Enterprise Plus.
  • vSphere Distributed Switch (vDS) Obligatoire. Ce commutateur distribué est fourni avec vSphere Enterprise Plus Edition.
  • Une fois installé, le dispositif de service du concentrateur local de couche 2 doit avoir accès à un port vNIC et aux réseaux VLAN à étendre.
  • Si le réseau doit être étendu via l'internet public ou un VPN (sur un chemin alternatif), la VM L2C dans VCF for Classic - Automated a besoin d'une adresse IP. L'adresse IP distante est obligatoire pour configurer le concentrateur de couche 2.
  • Si plusieurs concentrateurs de couche 2 sont nécessaires, chacun doit avoir une adresse IP en local et dans le cloud.

Planification de prédéploiement

Une grande partie du temps consacré au déploiement de HCX correspond à la phase de pré-déploiement. Généralement, les projets de migration des systèmes d'information prennent plusieurs mois voire plusieurs années. Toutefois, HCX permet une migration rapide et une connectivité du réseau au cloud immédiatement après le déploiement.

Etant donné que le déploiement de HCX pour un client au niveau de l'entreprise implique généralement des équipes de sécurité, de réseau, de stockage et d'infrastructure vSphere, il est logique d'impliquer ces équipes dans la preuve de concept si possible. Une gestion de projet efficace et l'inclusion précoce des parties prenantes sont essentielles pour garantir la rapidité du déploiement et de l'exploitation de HCX.

Eviter la paralysie d'analyse

La plupart des obstacles et du temps nécessaire à la migration d'une machine virtuelle ou d'un groupe de machines virtuelles sont dus à la nécessité de modifier certaines parties de l'environnement d'application. De plus, la conception de ces changements et la programmation des temps d'arrêt nécessaires pour effectuer ces changements peuvent être compliquées. Une fois ces changements apportés, la migration devient difficile à annuler, ce qui accentue la paralysie de l'analyse. Essayer de saisir tous les aspects de la migration, de coordonner les différentes équipes et de changer les principaux intervenants peut retarder la réalisation du projet.

HCX permet la migration vers cross-vSphere d'une VM ou d'un groupe de VM représentant une application composite partielle ou complète, sans aucune modification de l'application. Par conséquent, l'annulation d'une migration signifie le déplacement des machines virtuelles vers l'arrière ou le réaménagement des réseaux. Par conséquent, vous n'avez pas besoin d'une grande partie de la planification de la migration et un certain parallélisme dans le processus de planification peut se produire. Après avoir sélectionné les applications à déplacer et créé une conception de réseau de haut niveau, les applications peuvent commencer à migrer avec une configuration minimale sur l'instance de cloud pendant que la connectivité et la conception finales du réseau sont effectuées.

Réseaux étendus

Les composants d'extension du réseau de la flotte HCX sont stables. Un client possède plus de 20 réseaux locaux virtuels étendus à IBM Cloud® sur un réseau longue distance de 1 Gbps partagé avec d'autres trafics et tunnels de migration HCX. Cette configuration ne présente aucun problème d'application attribué au réseau. Les liaisons réseau ont une durée de vie supérieure à 6 mois de cette façon.

D'autres réseaux étendus ont été ajoutés et supprimés sans problème. Le choix d'un centre de données IBM Cloud proche (temps d'attente de < 6 ms pour ce client particulier) joue également sur la stabilité du réseau étendu. Ce n'est pas un facteur négatif dans votre conception que de laisser les réseaux étendus en place à long terme si vous disposez d'une largeur de bande suffisante et d'un temps de latence suffisamment faible pour vos applications.

Cycle de vie de la migration

Les sections suivantes décrivent les phases d'un cycle de migration HCX typique, en indiquant où des flux de travail peuvent être effectués en parallèle.

Inventaire vSphere

• Evaluation grossière des machines virtuelles au sein d'une application à migrer. Ce processus implique la compréhension des machines virtuelles qui participent à une application, sans entrer dans les détails.
• Si vous prévoyez de migrer de nombreuses machines virtuelles et que la bande passante réseau est limitée entre les sites source et cloud, regroupez les machines virtuelles par VLAN ou VXLAN si NSX est utilisé à la source. Cela permet un plan de migration HCX en cascade où les groupes de machines virtuelles par VLAN sont migrés et les réseaux L2 sur lesquels ils résident ne sont étendus que jusqu'au point où les VLAN sont libérés.

Cela signifie que le groupe initial de réseaux étendus L2 connexes ne peut être libéré que lorsque la conception du réseau côté cloud est finalisée et déployée. Le déblocage implique de faire basculer le trafic VXLAN particulier vers l'infrastructure NSX de l'instance de cloud.

Configuration réseau de base

Créer un réseau périmétrique sécurisé au sein de l'instance vSphere du côté du nuage. Il s'agit généralement d'un appareil NSX DLR ou Edge. Si vous utilisez le routage de proximité HCX, vous n'avez pas besoin de créer des règles de pare-feu ou une topologie de liaison montante car elle peut être terminée ultérieurement ou simultanément sans affecter le trafic L2 étendu.

Extension de réseau

Etendre le réseau signifie simplement prendre le VLAN ou VXLAN existant de l'environnement vSphere source, représenté par un groupe de ports de commutateur distribué virtuel (vDS), et l'étendre à un VXLAN NSX sur le côté cloud de HCX.

Tests pré-implémentation

Les tests pré-implémentation consistent à effectuer une migration HCX avec la fonction vMotion et la fonction de migration en bloc afin d'établir un taux de transfert de base.

Migration d'applications de non-production

La migration des machines virtuelles commence avec les vagues prévues de machines virtuelles moins critiques. Les équipes de développement et de test utilisent la connectivité Internet pour la migration et le trafic L2 étendu.

Début de la conception et de l'implantation du réseau cloud

Pendant que les migrations se poursuivent, les conceptions de réseau côté nuage sont finalisées et mises en œuvre dans l'instance vSphere côté nuage.

Autres remarques relatives à la connectivité du réseau

Pendant que les migrations se poursuivent, la connectivité du réseau WAN privé est commandée, car il faut généralement de quelques semaines à quelques mois pour établir une connexion avec le fournisseur de cloud. Une fois la connectivité du réseau privé achevée, HCX peut être configuré pour utiliser à la fois la liaison du réseau privé dédié et l'Internet pour la migration et le trafic étendu L2.

Serveurs physiques

Lorsque l'objectif est la migration du centre de données dans le cloud, tous les serveurs physiques qui interagissent avec les machines virtuelles en cours de migration peuvent être évalués pour la migration dans IBM Cloud en tant que machines virtuelles (P2V), bare metal ou rester à la source. Si le serveur physique doit rester à la source, et que HCX n'est utilisé que pendant la migration jusqu'à ce qu'un réseau dédié soit établi, il est important de comprendre s'il réside sur un réseau qui est étendu dans le cloud avec HCX. Dans ce scénario, HCX permet non seulement aux machines virtuelles, mais à l'ensemble du sous-réseau d'être migrés dans le cloud.

Pour supprimer HCX à la fin de la migration, le sous-réseau ne peut pas exister dans la source et la destination si la connexion entre les dispositifs physiques et les machines virtuelles migrées doit être maintenue. Cela implique que tous les dispositifs physiques laissés sur le site source qui existent sur des réseaux L2 étendus doivent être migrés vers un autre sous-réseau du réseau qui peut être routé vers le côté cloud. L'exception à cette règle est l'utilisation d'une autre technologie L2 étendue, telle que le VPN NSX L2, pour remplacer les noeuds finaux L2 étendus de HCX.

Migration de la production et des applications complexes

Les machines virtuelles avec des VMDK partagés en mode d'écriture multiple telles que les clusters Oracle RAC ou MS Exchange/SQL ou les machines virtuelles avec des mappages de périphériques bruts sont des exemples de machines virtuelles qui nécessitent une attention particulière avant la migration.

Basculement du réseau

Un basculement du réseau se produit une fois que l'évacuation des machines virtuelles des réseaux côté source est terminée et que la conception et l'implémentation du réseau sont terminées côté cloud. Configurer HCX pour déconnecter les réseaux liés aux VM achevées dans les vagues de migration permet aux VM migrées d'acheminer le trafic réseau en utilisant l'infrastructure NSX côté cloud.

Plateformes client prises en charge

Pour l'extension du réseau, seuls les groupes de ports avec un commutateur distribué virtuel (vDS) vSphere sont pris en charge. Cela implique également que les hôtes ESXi autonomes ne sont pas pris en charge, car vous ne pouvez avoir qu'un site vDS lorsque les hôtes ESXi sont gérés par le serveur vCenter.

Plateformes cloud prises en charge

Le côté cloud de HCX est fourni par l'automatisation IBM Cloud.

Options de connectivité

Liens connexes

• Glossaire des composants et des termes HCX
• Maillage de services sur site HCX
• Migrations de VMware Hybrid Cloud
• Paramètres et composants de surveillance
• Traitement des incidents liés à HCX