Migration de VMware vers OpenShift avec Cisco Isovalent, par vagues, en conservant vos adresses IP.
Red Hat OpenShift Virtualization exécute vos machines virtuelles existantes sur Kubernetes, aux côtés de conteneurs. Cisco Isovalent raccorde les réseaux vSphere et OpenShift pour que les applications migrent par vagues sans renumérotation. Les ingénieurs principaux de Ngenium évaluent votre parc, conçoivent la cible sur Cisco UCS, migrent avec Migration Toolkit for Virtualization de Red Hat et sécurisent le résultat. Services seulement : vous vous procurez la plateforme par votre partenaire ou distributeur; nous faisons l’ingénierie de la migration.
Tout ce qui sépare un parc vSphere d’une plateforme OpenShift en exploitation.
Déplacer des machines virtuelles est la partie facile. Ce qui décide du succès d’une migration, c’est de savoir ce qui migre facilement et ce qui ne migre pas, de préserver l’identité réseau et de réimplémenter l’intention de sécurité sur la nouvelle plateforme.
Sachez ce qui migre facilement, et ce qui ne migre pas.
Inventaire avec RVTools et l’OpenShift migration advisor gratuit de Red Hat, dépendances applicatives et une fiche de préparation en feux de circulation : vert pour les VM Windows et Linux standards, ambre pour les gros disques, les grappes à disques partagés et le GPU pass-through, à repenser pour les fonctions sans équivalent direct.
Une plateforme que vous pouvez dimensionner et vous procurer.
OpenShift Virtualization sur Cisco UCS avec gestion du cycle de vie par Intersight, stockage FlexPod avec NetApp, FlashStack avec Pure Storage ou OpenShift Data Foundation, et Cisco Unified Edge pour les succursales et les usines.
Migrez aujourd’hui la VM 12 sur 40, en gardant son adresse IP.
Cilium comme réseau du cluster avec Cisco Isovalent. Private Networks donne aux VM des réseaux isolés de type VLAN; le Network Bridge raccorde vSphere et OpenShift en couche 3, sans domaine de couche 2 étendu, pour qu’une VM garde son adresse pendant que le reste de son groupe attend.
L’intention NSX, réimplémentée, pas copiée.
La base de règles existante triée en règles nécessaires, en double, trop larges et désuètes, puis réimplémentée en politiques réseau Cilium avec des modèles d’application réutilisables, avec des preuves de flux Hubble avant et après chaque bascule.
Des vagues maîtrisées avec Red Hat MTV.
Correspondances réseau et stockage, migration à chaud ou à froid choisie par charge de travail, séquencement par groupe de dépendances, guides de bascule et critères de retour arrière. La migration à chaud raccourcit l’interruption sans l’éliminer, et nous le disons dès le premier jour.
Terminez la migration, puis retirez VMware.
Validation après bascule par rapport à la référence de flux, modèles de politiques et surveillance des flux exportés vers Splunk, modèles de sauvegarde et de reprise après sinistre sur OpenShift, et un plan pour retirer les dépendances au bridge et démanteler les hôtes une fois chaque vague stabilisée.
Avant, pendant, après : une seule équipe responsable.
Les mêmes ingénieurs principaux portent le travail du premier inventaire jusqu’au dernier hôte démantelé. Après la mise en service, la plateforme peut passer à des opérations de sécurité gérées grâce à notre partenariat stratégique avec Port53.
Ce que votre équipe VMware connaît déjà, sur OpenShift.
- vCenter → la console Web d’OpenShift, avec Advanced Cluster Management pour les parcs de clusters
- Hôte ESXi → un nœud de travail bare metal exécutant KVM, provisionné depuis Intersight
- DRS et HA → l’ordonnanceur, la santé des nœuds et les politiques d’éviction, configurés par VM
- vMotion → la migration à chaud en direct, sur un stockage partagé en lecture-écriture multiple
- Port group et commutateur distribué → une network attachment definition avec Cilium et Isovalent Private Networks
- Datastore → une storage class et un persistent volume claim, mis en correspondance un pour un par MTV
- Pare-feu distribué NSX → des politiques réseau Cilium : l’intention est réimplémentée, pas convertie règle par règle
- VMware Tools → l’agent invité QEMU, installé pendant ou après la conversion
Pourquoi les équipes font appel à Ngenium.
- Des ingénieurs principaux seulement — l’ingénieur qui évalue votre parc est celui qui mène la bascule.
- Services seulement — nous ne revendons jamais de matériel ni de logiciel et ne portons aucune marge produit; nos conseils sur l’opportunité de migrer, et sur quoi migrer, suivent votre parc, pas un quota.
- Profondeur réseau et sécurité — le réseau Cisco et Isovalent aux côtés de Red Hat OpenShift, NetApp, Pure Storage et Splunk; c’est sur le réseau que les migrations VMware échouent le plus souvent.
- Honnêtes sur les compromis — la migration à chaud exige quand même une fenêtre de bascule, certaines charges doivent rester ou être reconçues, et exploiter deux plateformes coûte de l’argent jusqu’à la dernière vague.
À propos de la migration de VMware vers OpenShift.
Nos machines virtuelles peuvent-elles fonctionner sur OpenShift sans devenir des conteneurs?
Oui. Red Hat OpenShift Virtualization exécute des machines virtuelles sur KVM, gérées par OpenShift, à côté des conteneurs. Les systèmes d’exploitation invités et les applications restent tels quels. Red Hat propose aussi l’édition OpenShift Virtualization Engine, un point d’entrée réservé aux VM qui peut évoluer plus tard vers la plateforme complète.
Les applications garderont-elles leurs adresses IP?
Elles le peuvent. Le Network Bridge de Cisco Isovalent raccorde les réseaux vSphere et OpenShift en couche 3, sans domaine de couche 2 étendu, pour qu’une VM garde son adresse lorsqu’elle migre et que ses dépendances continuent de fonctionner pendant que le reste de son groupe attend. Nous validons la conception du bridge par rapport à la matrice de prise en charge en vigueur pendant l’évaluation.
À quelle interruption faut-il s’attendre?
Une certaine interruption, pour chaque VM. La migration à chaud copie les disques pendant que la VM continue de fonctionner, puis arrête la source pour une synchronisation finale à la bascule, ce qui raccourcit l’interruption sans l’éliminer. Nous consignons la tolérance à l’interruption de chaque application pendant l’évaluation, choisissons la migration à chaud ou à froid par charge et planifions les bascules dans vos fenêtres de changement.
Ngenium vend-elle OpenShift, Isovalent ou le matériel?
Non. Ngenium est une firme de services seulement. Vous vous procurez Red Hat OpenShift, Cisco Isovalent et Cisco UCS par votre partenaire ou distributeur; Ngenium évalue, conçoit, migre et sécurise. Les partenaires de distribution Cisco font aussi appel à nous pour livrer des migrations à leurs clients, y compris des mandats en marque blanche sous NDA.
Qu’est-ce qui ne devrait pas migrer, ou devrait migrer en dernier?
Les VM Windows et Linux standards sur stockage partagé migrent généralement facilement. Les gros disques, les grappes à disques partagés, le GPU et le PCI pass-through, les longues chaînes d’instantanés et les invités soumis à des conditions logicielles particulières demandent plus de planification, et les fonctions sans équivalent direct sont reconçues plutôt que copiées. La fiche de préparation classe chaque groupe de charges en vert, ambre ou à repenser avant d’établir un plan.
Vous planifiez de quitter VMware?
Parlez aux ingénieurs principaux qui évalueraient et migreraient votre parc — pas à un vendeur.