Migration de IBM Cloud, VMware et VCF vers des serveurs virtuels VPC à l'aide de RackWare RMM

Migrer les machines virtuelles IBM Cloud VMware VCF vers des serveurs virtuels VPC à l'aide de RackWare RMM, en conservant les adresses IP via Direct Sync et un serveur-pont.

Ce guide traite de l'utilisation du module de gestion d' RackWare ( RMM ) pour migrer des machines virtuelles automatisées IBM Cloud VCF vers des instances de serveurs virtuels du cloud privé virtuel (VPC) IBM Cloud. Il existe un tutoriel associé qui explique la procédure à suivre.

IBM Cloud VCF- Les licences du système d'exploitation des machines virtuelles automatisées relèvent de la responsabilité du client et ne sont pas fournies par. IBM Cloud Lors de la création des instances de serveurs virtuels cibles, tenez compte des options de provisionnement disponibles dans le cadre de l'option « Apportez votre propre licence » (BYOL).

La plupart des machines virtuelles hébergées sur IBM Cloud VCF-Automated sont connectées à des segments overlay NSX qui ne disposent pas d'un accès natif aux réseaux IBM Cloud Classic. Pour garantir que les instances de serveur virtuel cibles disposent des mêmes adresses IP que les machines virtuelles sources, le segment de superposition NSX et les sous-réseaux VPC des instances de serveur virtuel cibles doivent être isolés. Pour ce faire, vous pouvez utiliser les fonctionnalités suivantes d' RMM:

  • Synchronisation directe (Host Sync): les données sont transférées directement depuis la machine virtuelle source vers l'instance de serveur virtuel cible, sans être stockées sur le serveur RMM. C'est l' RMM qui coordonne l'opération.
  • Passthrough - L'instance de serveur virtuel cible ne pouvant pas accéder directement à la machine virtuelle source, « RMM » utilise Secure Shell (SSH) pour se connecter à l'instance de serveur virtuel cible, puis établit à partir de là un tunnel SSH inverse vers la machine virtuelle source. Flux de données : Source → RMM → Cible, l' RMM faisant office de relais réseau/proxy pour le transfert des données.

Le site RackWare RMM avec un serveur de pont permet la migration entre des réseaux isolés :

  1. Traduction d'adresses réseau (NAT) via un pont : rend la source accessible à RMM via NAT
  2. Tunnel SSH inversé : permet à l'instance de serveur virtuel cible d'accéder à la machine virtuelle source via le serveur RMM
  3. Authentification par clé : l'instance de serveur virtuel cible utilise la clé SSH de RMM pour s'authentifier auprès de la machine virtuelle source
  4. Synchronisation des données via le tunnel : l'instance du serveur virtuel de destination récupère les données de la machine virtuelle source via le tunnel SSH sécurisé
  5. Installation du chargeur d'amorçage : la commande « RMM » rend la cible amorçable avec une configuration GRUB appropriée

Le processus est élégant et permet une migration de tout type tout en maintenant la sécurité et l'isolation du réseau.

Une alternative à la synchronisation directe, appelée synchronisation par étapes (étape 1 + étape 2), n'est pas abordée dans ce guide :

  • Étape 1 : Copier les données de la source vers le pool de stockage ZFS de RMM, en les stockant temporairement.
  • Étape 2 : Copie des données de la mémoire de RMM vers la cible.

Utilisé lorsque la synchronisation directe n'est pas souhaitée ou lorsque vous voulez découpler les opérations de la source et de la cible.

Conserver l'adressage IP

La plupart des migrations de machines virtuelles vers des serveurs virtuels VPC nécessitent le maintien de l'adressage IP des charges de travail migrées. Pour la plupart des machines virtuelles, cela est possible; toutefois, les sous-réseaux VPC disposent d'adresses IP réservées. Par exemple, les éléments suivants sont réservés sur 192.168.10.0/24:

  • adresse-réseau ibm : 192.168.10.0
  • ibm-default-gateway : 192.168.10.1
  • adresse ibm-dns : 192.168.10.2
  • ibm-reserved-address : 192.168.10.3
  • ibm-broadcast-address : 192.168.10.255

Par conséquent, il est souvent nécessaire de ré-IPer quelques machines virtuelles par sous-réseau.

Systèmes pris en charge

Consultez la documentation indiquée dans les références pour connaître les derniers systèmes d'exploitation pris en charge :

  • RHEL 5.2 à 5.11, 6.x, 7.x. 8.x, 9.x
  • Centos 5.2 à 5.11, 6.x, 7.x, 8.x
  • Oracle Linux 5.6 par le biais de 5.11, 6.x, 7.x, 8.x, 9.x
  • SLES 11 (y compris la version 32 bits)
  • SLES 12 (pas de btrfs)
  • SLES 15 (pas de btrfs)
  • Ubuntu 12 (y compris la version 32 bits), 14, 16, 18, 20, 22, 24
  • Debian 8, 9, 10, 11, 12
  • AlmaLinux 8, 9
  • Rocky 8 et 9 Linux
  • Windows 2008 R2, 2012, 2016, 2019, 2022

Composants de l'architecture

Ce guide :

  • Utilise des adresses IP à titre d'exemple pour faciliter le transfert de connaissances; vos adresses IP seront différentes.
  • Se concentre sur une migration Linux mais Microsoft Windows est similaire.
IBM Cloud VMware-Automated    Bridge Server              IBM Cloud VPC
┌──────────────┐             ┌───────────────┐          ┌───────────────┐
│              │             │ens192:        │          │               │
│  Source VM   │             │192.168.10.254 │          │  RMM Server   │
│ 192.168.10.11├────────────►│               │◄─────────┤  10.68.70.11  │
│              │             │   ens224:     │          │               │
└──────────────┘             │   10.134.54.62│          └───────────────┘
                             │               │                  │
                             └───────────────┘                  │
                                                                │
                                                        ┌───────▼───────┐
                                                        │  Target VSI   │
                                                        │ 192.168.10.11 │
                                                        └───────────────┘

Le diagramme ci-dessus montre une vue de la connexion logique des composants. Le nom de bridge server est trompeur car il n'utilise pas le pontage de la couche 2 mais le NAT de la couche 3.

Source VM:

  • Emplacement : IBM Cloud VCF Instance automatisée VMware
  • Exemple : VM exécutant Ubuntu 22.04
  • IP réelle : 192.168.10.11 (segment de superposition NSX)
  • Accessible via : VM a accès à l'Internet via SNAT, et un accès natif au réseau du client, mais pas au réseau IBM Cloud

Bridge Server :

  • Objectif : fournir une connectivité réseau de niveau 3 entre des réseaux isolés
  • Fonction : Utilise SNAT pour rendre un segment NSX overlay isolé accessible aux réseaux IBM Cloud VPC
  • Interfaces:
    • ens192: 192.168.10.254- Réseau interne ( 192.168.10.0/24 )
    • ens224: 10.134.54.62- Réseau extérieur ( 10.134.54.0/26 )

RMM Serveur :

  • Lieu : IBM Cloud VPC
  • Objectif : Orchestrer les opérations de migration/synchronisation
  • IP : 10.68.70.11
  • Exécute : RackWare le logiciel, héberge l'interface utilisateur, coordonne le transfert de données, agit comme un proxy pour les communications réseau en mode passthrough

VSI cible

  • Lieu : IBM Cloud VPC
  • Exemple : instance de serveur virtuel (VSI)
  • IP : 192.168.10.11
  • Objet : Destination des données migrées

IBM Cloud Private Sous-réseau statique :

  • Lieu : « IBM Cloud » Classic
  • Exemple : Déployer un sous-réseau portable /30 (4 IP)
  • IP : 10.194.177.82/30. IP utilisables : 10.194.177.82- 10.194.177.85
  • Objet : Fournit l'adresse IP pour le NAT que le réseau classique IBM Cloud dirige vers : 10.134.54.62 (l'IP ens224 du serveur de pont). IBM l'infrastructure du réseau de l'entreprise sait que tout le trafic destiné à 10.194.177.82/30 doit être envoyé à 10.134.54.62

Serveur de pont

Le serveur de pont utilise iptables pour assurer le NAT :

  1. Lorsque RMM se connecte à 10.194.177.82, le pont traduit la destination en 192.168.10.11 (l'adresse IP VM de la source réelle).

  2. Lorsque la source VM répond, elle semble provenir de l'IP NAT 10.194.177.82

    Lorsque RMM tente d'atteindre 10.194.177.82:

    1. RMM envoie un paquet
      • SRC : 10.68.70.11
      • DST : 10.194.177.82
    2. VPC Routes vers Transit Gateway qui route vers le réseau Classic qui sait que :
      • " 10.194.177.82 est dans le sous-réseau 10.194.177.82/30 "
      • "Route this subnet to 10.134.54.62 "
    3. Étape 3 : Paquet transmis au serveur de pont
      • Arrivée sur ens224 ( 10.134.54.62 )
      • DST : 10.194.177.82 (inchangé)
    4. DNAT d'iptables Bridge
      • iptables -t nat -A PREROUTING -i ens224 -d 10.194.177.82 -j DNAT --to-destination 192.168.10.11
    5. Paquet transmis à la source VM
      • SRC : 10.68.70.11
      • DST : 192.168.10.11 (DNAT'ed)

Exigences relatives aux clés SSH

Pour que le tunnel fonctionne pour le transfert de données, la cible doit s'authentifier auprès de la source. L'ISP cible a besoin de la clé privée SSH qui correspond à une clé publique dans le fichier authorized_keys de l'ISP source VM.

Emplacements clés :

  • RMM: /root/.ssh/id_rsa Créé dans le cadre du processus manuel après le déploiement de RMM
  • Cible Linux VSI : /root/.ssh/id_rsa Doit être la même clé que celle de RMM et transférée via un processus automatisé RMM
  • Source Linux VM: /home/rackware/.ssh/authorized_keys Créé dans le cadre du processus manuel de configuration de la source

Pour les serveurs Windows, l'utilitaire RackWare SSHD est utilisé. RackWare SSHD pour Windows est une implémentation légère du serveur SSH sous la forme d'un programme d'installation MSI spécialement conçu pour les systèmes Windows afin de permettre la connectivité RackWare RMM. Le MSI, RWSSHDService_x64.msi, peut être téléchargé directement à partir du serveur RMM à l'adresse suivante : https://<RMM_IP>/windows/RWSSHDService_x64.msi

flux d'authentification

  1. RMM → Source VM (via le serveur de pont)
    • Utilise : RMM 's SSH key
    • S'authentifie en tant que : rackware user
    • Objectif : Découverte, montage du système de fichiers, nettoyage
  2. RMM → VSI cible
    • Utilise : RMM 's SSH key
    • S'authentifie en tant que : root user
    • Objectif : créer un tunnel, monter des systèmes de fichiers, transférer des données
  3. VSI cible → Source VM (à travers le tunnel)
    • Utilise : Copie de la clé SSH (identique à celle de RMM )
    • S'authentifie en tant que : rackware user
    • Objet : Transfert de données

Core RackWare RMM Opérations

Voici les principales opérations de RackWare RMM pour la migration.

Découvrir/Examiner

Objectif : recueillir des informations sur la source VM Processus :

  • L'utilisateur fournit l'adresse IP ou le nom d'hôte DNS de la source VM. Dans notre cas d'utilisation, nous utilisons l'adresse IP NAT.
  • RMM se connecte via SSH au serveur source VM
  • Effectue des recherches standard dans le système d'exploitation pour collecter des métadonnées :
    • Cœurs de l'unité centrale, mémoire vive, configuration du disque
    • Partitions et structure des volumes
    • Version du système d'exploitation et paquets installés
    • Configuration de réseau
    • informations sur l'application
  • Métadonnées stockées dans la base de données de gestion de la configuration (CMDB) de RMM
  • Utilisé ultérieurement pour AutoProvisioning VSI cibles, si nécessaire

Exigence de clé : Les clés SSH doivent être correctement configurées entre RMM et le serveur source

Capture (approche "Store-and-Forward")

L'approche Store-and-Forward n'est pas utilisée dans ce cas d'utilisation, car nous utilisons l'approche Direct Assign (Flex Sync/Host Sync).

Objectif : Créer un instantané/clone de l'image source VM sur le site Web de l'entreprise RMM Processus :

  • Prend un instantané LVM ( Linux ) ou un instantané VSS (Windows) sur la source VM
  • Le système d'exploitation envoie les entrées-sorties de l'application sur le disque pour assurer la cohérence
  • Le système d'exploitation place un signet dans le système de fichiers (non perturbateur)
  • RMM copie des bits d'image de l'instantané statique vers le stockage RMM
  • Seules les données utilisées sont copiées (au niveau du fichier et non du bloc)
  • Image stockée dans l'emplacement de stockage du serveur RMM
  • Métadonnées supplémentaires sur l'image stockée dans la CMDB

Principales caractéristiques :

  • Pas de perturbation du serveur d'origine (la production continue)
  • Réplication basée sur les fichiers (et non sur les secteurs/blocs)
  • Prise en charge de la compression et du cryptage
  • Possibilité de spécifier des listes d'inclusion/exclusion pour les données sélectives

Affecter

Objectif : Déployer l'image capturée vers une VSI cible Processus :

  1. AutoProvision vSI cible (ou utilisation d'un serveur préprovisionné)
    • RMM utilise les métadonnées de Discover pour dimensionner la cible de manière appropriée
    • Dispositions VSI dans VPC
  2. La connexion à la cible utilise SSH
  3. Examiner la cible
    • Vérifier que la VSI cible peut exécuter l'image source VM
    • Comprendre le matériel sous-jacent
  4. Démarrer sur RackWare Microkernel
    • Déployer le micro-noyau dans la VSI cible
    • Insérer dans les options du chargeur de démarrage
    • Démarrage de l'ISV cible à partir du micro-noyau
  5. Préparation du disque VSI cible
    • Reformater le disque
    • Recréer la structure du volume logique (correspondance exacte avec l'origine)
    • Créer des partitions à l'aide de l'algorithme d'ajustement optimal
  6. Transfert d'image
    • Transfert des bits d'image de la mémoire RMM vers l'ISV cible
    • Injecter les pilotes de périphériques nécessaires pour le nouveau matériel
    • Modifier éventuellement la configuration du réseau pour l'ISV cible
  7. Configuration et redémarrage
    • Configurer le chargeur de démarrage pour le système d'exploitation actuel
    • Redémarrer dans le système d'exploitation répliqué
  8. Vérification
    • Vérifier que la VSI cible démarre correctement
    • Vérifier que la mise en réseau est correcte
    • Vérifier que les données sont répliquées correctement
    • SSH dans le serveur répliqué en utilisant les mêmes informations d'identification que l'origine

Affectation directe (également appelée Flex Sync ou Host Sync)

C'est l'approche que nous utilisons dans ce cas d'utilisation.

Objectif : Réplication directe de la source VM vers le VSI cible sans stockage intermédiaire Processus :

  1. Combine la capture et l'affectation en une seule opération
  2. Effectue toutes les fonctions de Discover
  3. Dispositions serveur cible (ou utilisation d'un serveur existant)
  4. Préparation du serveur cible
  5. Réplique directement de la source VM vers la cible VSI
  6. La connexion réseau peut toujours passer par RMM (aucune connexion directe entre la source et la cible n'est requise)

Sync (Synchronisation Delta)

Objectif : mettre à jour la cible avec les seules données modifiées de la source VM Processus :

  1. Prise d'un instantané sur la source VM (LVM ou VSS)
  2. Calcul du delta (uniquement pour les fichiers modifiés)
  3. Transfère uniquement les données modifiées vers la cible
  4. Mises à jour soit :
    • Image capturée sur RMM storage, OR
    • Serveur cible en cours d'exécution, OU
    • Les deux (image + serveur cible)

Options de synchronisation

  • Synchronisation de la phase I
    • Origine → RMM Stockage (image capturée)
    • Mise à jour de l'image stockée uniquement
  • Synchronisation de niveau II
    • RMM Stockage → Serveur cible
    • Mise à jour de la cible en cours d'exécution à partir de l'image stockée
  • RMM Passage
    • Origine → RMM → Cible
    • Les données circulent sur le site RMM mais ne persistent pas
    • Aucun stockage sur RMM n'est nécessaire
  • Synchronisation directe
    • Origine → Cible (connexion directe)
  • Synchronisation sélective*
    • Synchroniser uniquement des fichiers/répertoires spécifiques
    • Utilise des listes d'inclusion/exclusion
  • Cartographie des lecteurs/répertoires
    • Faire correspondre des chemins d'origine spécifiques à différents chemins d'arrivée

Sync Engines :

  • RWSync (par défaut):
    • Sans agent
    • Tolérance aux pannes de réseau
    • Gestion des mises à jour massives et simultanées
    • Inclut la somme de contrôle finale
    • Plus lent que TNG
  • TNG (avancé):
    • Nécessite l'installation de delta file tracker
    • Beaucoup plus rapide et efficace
    • Pour les grands serveurs, les taux de mise à jour élevés, les RPO agressifs
    • Doit figurer sur la liste blanche de l'antivirus
    • Plus sensible aux pannes de réseau
    • Ne prend pas en charge les montages à distance NFS /CIFS

Le processus de démarrage du micro-noyau RackWare

Pendant l'opération d'attribution, RMM démarre l'ISP cible avec un micro-noyau RackWare et le disque de démarrage est reformaté, ce qui garantit que les systèmes de fichiers, leurs types et leurs tailles correspondent à ceux de la source VM. Le site RMM fait une tentative d'ajustement en fonction de la disposition du disque cible et des partitions à insérer en fonction de ce que la source possède.

Déploiement du micro-noyau

Lorsque RackWare prépare un VSI cible à recevoir l'image répliquée :

  • RMM déploie un micro-noyau RackWare sur la VSI cible
  • Ce micro-noyau "s'insère dans les options du chargeur de démarrage" du système d'exploitation de la plateforme
  • Le micro-noyau démarre à partir du chargeur de démarrage (GRUB sur Linux )

Le micro-noyau peut être considéré comme un LiveCD, et constitue un environnement minimal amorçable :

  • Héberge les pilotes nécessaires pour le matériel cible
  • Permet à RMM de communiquer avec le serveur cible
  • Permet le reformatage des disques et la création de partitions
  • Facilite le transfert effectif des données de l'origine à la cible
  • Configure le système pour le nouvel environnement matériel

Pendant la phase d'affectation, RackWare:

  1. Démarrage de l'ISV cible dans le micro-noyau (via l'entrée GRUB)
  2. Reformate le disque dans le micro-noyau
  3. Recrée la structure de la partition en fonction de la source VM
  4. Création de volumes logiques pour créer la structure LVM
  5. Transfère les données de la source VM vers l'ISV cible
  6. Injecte les pilotes nécessaires pour le matériel cible
  7. Configure GRUB pour qu'il démarre le système d'exploitation actuel
  8. Redémarrage dans le système d'exploitation répliqué

RackWare modifie la configuration de GRUB en :

  • Ajouter une entrée temporaire de démarrage du microkernel pendant le processus d'attribution
  • Configurer les paramètres de démarrage corrects pour le système d'exploitation répliqué
  • Définir l'option de démarrage par défaut du système d'exploitation répliqué une fois le transfert terminé
  • Gérer tous les paramètres du noyau nécessaires pour le nouveau matériel

Pour les systèmes Windows :

  • Le gestionnaire de démarrage Windows est utilisé à la place de GRUB
  • Le même concept de micro-noyau s'applique
  • Le micro-noyau s'insère dans la configuration de démarrage de Windows
  • Après la réplication, la configuration de démarrage pointe vers le système d'exploitation Windows répliqué

L'environnement micro-noyau permet à RackWare de.. :

  • Injecter des pilotes de stockage appropriés
  • Injecter des pilotes de réseau
  • Configurer les pilotes de périphériques pour le nouveau matériel
  • S'assurer que le système d'exploitation répliqué peut démarrer sur du matériel différent

Le processus de réplication pour les synchronisations delta, les synchronisations ultérieures, fonctionne de la même manière que la synchronisation initiale. La synchronisation delta est effectuée après le redémarrage du serveur cible avec le micro-noyau RackWare. Une fois la synchronisation delta terminée, la VSI cible est redémarrée dans le système d'exploitation hôte,

Cette approche micro-noyau est un élément clé de différenciation pour RackWare car elle leur permet de gérer la complexité des migrations inter-plateformes, inter-hyperviseurs et physique-virtuel en ayant un contrôle total sur l'environnement cible pendant la phase critique de transfert et de configuration.

RackWare Passthrough avec le processus de synchronisation directe

La procédure est la suivante :

  1. RMM Découvre la source VM
RMM → Bridge (10.194.177.82) → Source VM (192.168.10.11)
  • RMM se connecte via SSH à 10.194.177.82 (NAT IP)
  • Le pont se traduit par 192.168.10.11
  • RMM rassemble les métadonnées : Système d'exploitation, systèmes de fichiers, disposition des disques, etc.
  1. RMM Découverte de l'ISV cible
RMM → Target VSI (192.168.10.11)
  • RMM se connecte via SSH à 192.168.10.11
  • Examiner le matériel et les capacités de la cible
  1. RMM Création d'un tunnel SSH inversé vers la VSI cible

L'automatisation RMM crée un tunnel SSH inversé entre la VSI cible et la source VM via le serveur RMM:

Target VSI (192.168.10.11)
  │
  └─ localhost:23 ──[SSH Tunnel]──► RMM ──► Bridge ──► Source VM:22

  1. RMM établit une connexion SSH avec le VSI cible

  2. Crée un port d'écoute (23) sur la cible

  3. Toute connexion à localhost:23 sur la cible est transférée :

    • Par le biais du tunnel SSH, revenir à RMM
    • RMM transmet à 10.194.177.82:22 (source via le pont)
    • Relier les DNAT à la source réelle

    Flux visuel :

    Target:       [App tries localhost:23]
                       ↓
               [SSH tunnel to RMM]
                       ↓
RMM: [Receives and forwards to 10.194.177.82:22]
                       ↓
 Bridge: [DNAT: 10.194.177.82 → 192.168.10.11]
                       ↓
Source:   [Receives connection on port 22]

  4. Monter des systèmes de fichiers

RMM monte les systèmes de fichiers sur la source et la cible à l'aide de commandes similaires aux exemples ci-dessous :

Sur la source VM (via le pont):

# RMM executes on source
mount --bind / /mnt/rackware/tmp.xxxxx

VSI cible (direct):

# RMM executes on target
mount /dev/vda2 /mnt/rackware/tmp.yyyyy
  1. Transfert de données

RMM exécute le transfert de données sur l'ISV cible pour extraire les données de l'ISV source VM:

  1. Installation de GRUB

RMM installe et configure GRUB sur la cible pour le démarrage UEFI :

  • Copie les fichiers du chargeur de démarrage GRUB
  • Génère grub.cfg avec des paramètres de noyau corrects
  • Création d'entrées de démarrage UEFI
  • Configure les nouveaux pilotes de matériel
  1. Démontage des systèmes de fichiers
# On both source and target
umount /mnt/rackware/tmp.xxxxx

  1. Fermer le tunnel

  2. RMM ferme le tunnel SSH vers la cible

  3. Le port 23 cesse d'écouter sur la cible

  4. Supprimer les utilitaires

# RMM removes temporary files from source and target
rm -rf /var/tmp/rackware/

Références