PlateSpin Transformation Manager PlateSpin Migrate ... · Table des matières page ... meilleurs résultats. Fig. 1 PlateSpin présente des performances jusqu’à 50 % plus efficaces,

Planification et exécution de projets de migration de workloads à grande échelleMis à jour pour PlateSpin Transformation Manager 1.1 et PlateSpin Migrate 12.2

Livre blancPlateSpin Transformation Manager PlateSpin Migrate

Table des matières page

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

À qui s’adresse ce livre blanc ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Comprendre les workloads et leurs migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Présentation de PlateSpin Migrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Présentation de PlateSpin Transformation Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Planification de projets de migration de workloads à grande échelle . . . . . . . . . . . . . . . . 7

Conception d’une infrastructure de migration évolutive . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Dynamique d’exécution de projets de migration de workloads à grande échelle . . .15

Obtenir la certification Certified PlateSpin Migration Specialist . . . . . . . . . . . . . . . . . . .18

1www.microfocus.com

IntroductionDans le monde dynamique d’aujourd’hui, la nécessité de réduire les coûts conjuguée au souhait d’augmenter l’efficacité opérationnelle a un impact constant sur l’organisation des ressources informatiques.

Les entreprises recherchent sans cesse de meilleurs moyens de gérer l’infrastructure, les systèmes et les applications, ce qui aboutit souvent à l’exécution de projets pendant lesquels de nombreux workloads sont déplacés d’une plate-forme ou d’un datacenter à un(e) autre. Exemples typiques : migration de serveurs physiques vers une plate-forme virtuelle, migration de machines virtuelles d’une plate-forme virtuelle à une autre, migration de workloads sur site vers un cloud public ou géré, ou encore consolidations de datacenters traditionnels.

À qui s’adresse ce livre blanc ?

Ce livre blanc est spécialement destiné aux chefs de projet et architectes de projet qui pilotent des projets de migration à grande échelle à l’aide d’outils Micro Focus® PlateSpin® tels que PlateSpin Transformation Manager et PlateSpin Migrate. Utilisées conjointement, les solutions PlateSpin Transformation Manager et PlateSpin Migrate leur permettent d’améliorer jusqu’à 50 % l’efficacité de l’exécution de projets de transformation de datacenter. Les interruptions de service sont quasiment inexistantes, les tests sont plus flexibles, les risques et les erreurs humaines diminuent et la durée d’exécution totale des projets est considérablement réduite.

_________________________________________________________________

http://www.microfocus.com

2

Livre blancPlanification et exécution de projets de migration de workloads à grande échelle

Comprendre les workloads et leurs migrations

Dans ce livre blanc, nous utiliserons le terme « workload » comme terme global pour désigner un système d’exploitation et toutes les applications qui y sont installées, les correctifs et paramètres de configuration, ainsi que l’ensemble des fichiers ou blocs de données qui se trouvent sur ses volumes de données.

PlateSpin présente des performances jusqu’à 50 % plus efficaces, ce qui vous permet de migrer davantage de workloads en moins de temps et avec de meilleurs résultats.

Fig. 1

PlateSpin présente des performances jusqu’à 50 % plus efficaces, ce qui vous permet de migrer davantage de workloads en moins de temps et avec de meilleurs résultats .

_________________________________________________________________

3www.microfocus.com

Dans le contexte de projets de transformation de datacenters, la reconstruction intégrale d’un workload sur une nouvelle plate-forme est rarement une méthodologie de migration souhaitée. En effet, la reconstruction est un processus manuel, lent et source d’erreurs, qui requiert de nombreux tests onéreux pour garantir que le nouveau workload est créé exactement de la même manière que le workload original. Une réelle migration de workload, telle qu’effectuée par PlateSpin Migrate, rationalise les blocs ou les fichiers du workload original dans une réplique sur la nouvelle plate-forme (« cible »). L’utilisation de PlateSpin Migrate garantit que le nouveau workload est créé rapidement et automatiquement, et que son fonctionnement est identique à celui du workload original. Les migrations de workloads constituent un élément important d’un grand nombre de projets actuels de transformation de datacenters, pour ne pas dire tous.

Présentation de PlateSpin Migrate

PlateSpin Migrate est une puissante solution de portabilité du workload qui automatise le déplacement des workloads sur le réseau, entre les serveurs physiques, les hôtes virtuels et le cloud. PlateSpin Migrate dissocie à distance les workloads du matériel serveur sous-jacent et les déplace vers et à partir d’hôtes physiques ou virtuels, depuis un seul point de contrôle. Elle offre aux entreprises et aux fournisseurs de services une solution éprouvée et bien établie qui permet de tester, migrer et rééquilibrer les workloads en transcendant les limites de l’infrastructure, avec un accent particulier sur les datacenters.

PlateSpin Migrate prend en charge les principaux types de migration de workloads suivants :

physique vers physique (P2P), par exemple déplacement d’un workload d’un serveur physique obsolète vers un modèle plus récent ;

physique vers virtuel (P2V) et inversement, par exemple virtualisation d’un workload actuellement exécuté sur un serveur physique ;

virtuel vers virtuel (V2V), par exemple des migrations depuis VMware vers Hyper-V ou vice versa ;

physique ou virtuel vers le cloud (X2C) et inversement.

PlateSpin Migrate n’effectue aucune des opérations suivantes :

migrations au niveau de l’application ;

conversions d’Unix vers Linux ;

mises à niveau des systèmes d’exploitation.

L’utilisation de PlateSpin Migrate garantit que le nouveau workload est créé rapidement et automatiquement, et que son fonctionnement est identique à celui du workload original. Les migrations de workloads constituent un élément important d’un grand nombre de projets actuels de transformation de datacenters, pour ne pas dire tous.


4


Voici certaines des fonctions clés de PlateSpin Migrate :

fonctionnalités de migration anywhere-to-anywhere du workload (y compris la plupart des principales plates-formes d’hyperviseur et Microsoft Azure) ;

prise en charge de la plupart des versions Enterprise de workloads Windows et Linux ;

réplications incrémentielles automatisées et points de test multiples avant la transition finale du workload source vers le workload cible. La transition est le moment où les utilisateurs sont déplacés depuis l’ancien serveur (workload source) vers le nouveau serveur (workload cible). Elle implique généralement l’arrêt ou la mise hors service du workload source ;

possibilité d’évolution jusqu’à 40 migrations simultanées par serveur PlateSpin Migrate ;

automatisation de pointe, avec points d’insertion post-migration et interface de ligne de commande.

Une migration de workload type avec PlateSpin Migrate implique deux sortes de réplications : une réplication intégrale et une ou plusieurs réplications incrémentielles. Les réplications incrémentielles sont également appelées synchronisations. La première réplication du workload est presque toujours une réplication intégrale : tous les blocs ou fichiers du workload source sont transférés vers le workload cible. Après cette première réplication intégrale, le workload cible est généralement testé. Au cours des tests, des modifications se produisent au niveau du workload source, qui doit alors être synchronisé au moins une fois, avant la transition finale. La synchronisation de ces modifications est effectuée via une réplication incrémentielle. Si le test dure longtemps, plusieurs réplications incrémentielles sont généralement appliquées. Enfin, la transition du workload est effectuée, en même temps qu’une dernière réplication incrémentielle, afin de garantir la prise en compte de toutes les modifications. Au cours de ce processus, le workload source est en ligne et entièrement accessible à ses utilisateurs métiers. Ce n’est qu’au cours de la toute dernière synchronisation et de la transition que les services doivent être brièvement arrêtés, avant d’être redémarrés sur le workload cible. Afin de limiter ces interruptions de service au strict minimum, PlateSpin vise à réduire le temps nécessaire à une synchronisation. Pour cela, PlateSpin a développé un pilote de transfert par bloc (BBT) facultatif. Celui-ci peut être installé dans le workload source, où il suit les blocs modifiés entre deux réplications. À l’ouverture de la fenêtre de synchronisation, le pilote identifie immédiate-ment les blocs « sales » et les envoie vers la cible. Les migrations peuvent être exécutées avec ou sans ce pilote, mais son utilisation réduit le temps nécessaire à une synchronisation.

PlateSpin Migrate utilise Microsoft SQL Server comme base de données back-end. Plusieurs serveurs PlateSpin Migrate peuvent partager la même instance SQL Server. Cela simplifie la mise à l’échelle horizontale des serveurs de migration. Un serveur PlateSpin Migrate peut

Un serveur PlateSpin Migrate peut générale ment administrer environ 200 migrations, dont 40 peuvent simultanément s’exécuter et effectuer une réplication. Pour les projets de grande envergure, PlateSpin recommande de répartir la totalité des migrations sur plusieurs serveurs PlateSpin Migrate mis à l’échelle horizontalement.

5www.microfocus.com

généralement administrer environ 200 migrations, dont 40 peuvent simultanément s’exécuter et effectuer une réplication. Pour des performances optimales, PlateSpin recommande de répartir la totalité des migrations sur plusieurs serveurs PlateSpin Migrate mis à l’échelle horizontalement, gérés de manière centralisée par un serveur PlateSpin Transformation Manager.

Présentation de PlateSpin Transformation Manager

La solution PlateSpin Transformation Manager a été conçue pour planifier, suivre et rationaliser l’exécution de projets de transformation de datacenters. Elle est généralement utilisée en combinaison avec un outil de migration du workload tel que PlateSpin Migrate. La solution comprend une architecture basée sur un serveur client et permet à plusieurs utilisateurs ayant différents rôles d’accéder aux données de projet et de les mettre à jour simultanément et en toute sécurité, via un navigateur Web. Elle permet également de gérer plusieurs projets pour divers clients grâce à son architecture multi-tenant intégrée qui garantit que toutes les données clients sont correctement stockées et inaccessibles par d’autres clients. Les informations relatives aux workloads sources peuvent facilement être importées dans un projet via une feuille de calcul ou via l’API PlateSpin Transformation Manager, ou peuvent faire l’objet d’une découverte automatique en temps réel exécutée par PlateSpin Transformation Manager. Ces informations peuvent être mises à jour en permanence, afin de garantir qu’elles reflètent la réalité potentielle-ment changeante dans l’environnement source, tandis que le projet est exécuté.

Une fois toutes les informations sur le workload importées, le projet peut être planifié. Les chefs de projet peuvent affecter différentes personnes à différents projets et partager les projets de grande taille en portions plus petites (appelées vagues et lots) afin d’organiser l’exécution du projet autour d’éléments plus faciles à gérer. Pour chaque workload, l’état final et la destination peuvent être décrits bien avant que la migration réelle n’ait lieu. Une fois l’état final du workload suffisamment décrit, il peut être soumis pour exécution, c’est-à-dire qu’il est mis à la disposition d’un spécialiste de la migration qui s’en chargera dans le délai fixé. Toutes les informations étant gérées de manière centralisée dans la base de données PlateSpin Transformation Manager, l’état du projet peut être consulté à tout moment et visualisé dans un tableau de bord, qui peut également être présenté au client.

_________________________________________________________________

Toutes les informations étant gérées de manière centralisée dans la base de données PlateSpin Transformation Manager, l’état du projet peut être consulté à tout moment et visualisé dans un tableau de bord, qui peut également être présenté au client.


6


PlateSpin Transformation Manager comprend les rôles clés suivants :

Administrateur : utilisateur qui installe le produit. L’administrateur peut être le chef de projet principal et/ou peut créer d’autres chefs de projet.

Chef de projet : crée généralement les nouveaux projets, ainsi que les architectes de projet et les spécialistes de la migration. Le chef de projet dispose de tous les droits sur un projet.

Architecte de projet : possède tous les droits sur les projets qui lui sont affectés, mais ne peut pas en créer de nouveaux. L’architecte de projet peut également créer des spécialistes de la migration.

Spécialiste de la migration : ce rôle ne dispose d’aucun privilège de planification. Le spécialiste de la migration peut uniquement exécuter des tâches dans le contexte de migrations de workloads planifiées.

Lecteur du tableau de bord : peut uniquement consulter le tableau de bord du projet.

Rôles principaux de PlateSpin Transformation Manager :

Administrateur

Chef de projet

Architecte de projet

Spécialiste de la migration

Lecteur du tableau de bord

Fig. 2

PlateSpin Transformation Manager permet à plusieurs utilisateurs ayant différents rôles d’accéder aux mêmes données et de les mettre à jour simultanément et en toute sécurité, via un navigateur Web .

_________________________________________________________________

7www.microfocus.com

Planification de projets de migration de workloads à grande échelle

Planification des ressources pour les serveurs PlateSpin Server et Microsoft SQL Server PlateSpin recommande d’exécuter tous les serveurs PlateSpin en tant que machines virtuelles. Cela vous permet de facilement allouer plus ou moins de ressources à ces serveurs lorsque le projet avance. La documentation de chaque produit contient des exemples de configuration des ressources. En règle générale, prévoyez le provisioning d’un serveur virtuel pour chacun des éléments suivants :

le serveur PlateSpin Transformation Manager ;

un serveur PlateSpin Migrate pour toutes les 200 migrations de workloads gérées simultanément, dont 40 peuvent être en cours de réplication en même temps ;

un serveur Microsoft SQL Server (édition Standard ou Enterprise) pour héberger les données des serveurs PlateSpin Migrate (reportez-vous à la documentation de PlateSpin Migrate pour connaître les versions prises en charge).

Remarque : PlateSpin Transformation Manager est une appliance téléchargeable d’environ 1 Go.

Planification de fenêtres de certification et de maintenance du pilote BBT pour les installations du pilote BBTL’installation du pilote BBT (qui permet d’accélérer les synchronisations) requiert un redémarrage des workloads sources basés sur le système d’exploitation Microsoft Windows. Pour limiter l’impact de cette opération, un programme d’installation autonome du pilote est disponible. Il peut être exécuté sur le workload source à tout moment et enregistre simplement le pilote afin qu’il soit installé lors du redémarrage suivant du workload source. Ce dernier peut alors être redémarré à tout moment avant sa migration. Dans la mesure où les fenêtres de maintenance peuvent être limitées, la planification de ces redémarrages constitue une étape importante de la planification du projet.

Dans certains environnements, l’utilisation d’un nouveau pilote nécessite sa certification. Pour éviter tout délai inutile, PlateSpin recommande de démarrer le processus de certification le plus tôt possible au cours du projet.

Pour éviter tout délai inutile, PlateSpin recommande de démarrer le processus de certification le plus tôt possible au cours du projet.


8


Installation, configuration et initialisation de PlateSpin Transformation Manager (logiciel)PlateSpin Transformation Manager est une appliance Linux téléchargeable et requiert simplement l’ajout d’un disque de données supplémentaire (d’une taille de 40 Go) avant son lancement. Au premier démarrage, l’appliance pose quelques questions de configuration simples. Après cette configuration initiale, le chef de projet doit utiliser un navigateur Web pour se connecter, découvrir les workloads sources, les environnements cibles et les serveurs PlateSpin Migrate, puis créer le plan de projet.

Installation de serveurs PlateSpin Migrate (logiciel)PlateSpin recommande d’installer PlateSpin Migrate sur un système d’exploitation Microsoft Windows 2012 R2 dédié. Aucune autre application ne devrait être installée sur ce système. Une description complète du processus d’installation est disponible dans la documentation du produit. Un serveur PlateSpin Migrate peut gérer environ 200 workloads sources découverts simultanément, dont 40 peuvent être en cours de réplication en même temps. Si la taille du projet nécessite l’installation de plusieurs serveurs PlateSpin Migrate, envisagez d’installer une instance centralisée de Microsoft SQL Server pour gérer l’ensemble des données associées à la migration (l’édition Standard ou Enterprise de Microsoft SQL Server est requise).

Création d’équipes d’exécution efficacesPlateSpin recommande que tous les membres de l’équipe qui utilisent PlateSpin Migrate suivent la formation sur l’administration de PlateSpin Migrate. Au moins un membre de l’équipe doit posséder la certification Certified PlateSpin Migration Specialist. Vous trouverez plus d’informations sur la certification à la fin du présent livre blanc.

Outre les compétences d’administration de PlateSpin Migrate, PlateSpin recommande également de disposer des compétences suivantes, qui peuvent être réparties entre les membres de l’équipe :

Si des workloads Linux doivent être migrés : compétences de base d’administration de Linux. Pour certaines versions de Linux, il peut être nécessaire de compiler un pilote BBT personnalisé. Ce processus n’est pas difficile et est bien documenté, mais il requiert des compétences d’administration de Linux via l’interface de ligne de commande. Consultez la documentation du produit pour connaître les versions de Linux pour lesquelles un pilote BBT précompilé est disponible.

Si des workloads Windows doivent être migrés : compétences de base d’administration de Windows.

PlateSpin recommande vivement une bonne compréhension des plates-formes cibles vers lesquelles les workloads doivent être migrés. Chacune d’entre elles présente ses propres spécificités et, en particulier en cas de résolution de problèmes, une connaissance au moins intermédiaire de la plate-forme cible est requise. Pour les migrations vers des plates-formes cibles VMware, il est vivement conseillé qu’au moins un membre de l’équipe possède une certification VMware. Pour les migrations vers d’autres plates-formes cibles, il est conseillé de vérifier si des certifications existent pour chacune d’entre elles, et qu’au moins un membre de l’équipe les obtienne, le cas échéant.

PlateSpin recommande d’installer PlateSpin Migrate sur un système d’exploitation Microsoft Windows 2012 R2. Une description complète du processus d’installation est disponible dans la documentation du produit.

9www.microfocus.com

Les principaux défis relatifs à la migration proviennent de problèmes réseau, qu’ils soient liés à des contraintes de bande passante, des pare-feu ou des architectures réseau qui entravent certains chemins de communication. Une bonne connaissance des réseaux impliqués dans le projet est essentielle à son bon déroulement. En outre, PlateSpin recommande qu’au moins un membre de l’équipe possède une certification en réseautique TCP/IP standard, particulièrement dans le contexte des calculs de bande passante.

Collecte d’informations sur les workloads sourcesPlateSpin Transformation Manager inclut un mécanisme flexible d’importation de données basé sur les feuilles de calcul Microsoft Excel. Sur le principal onglet de présentation du workload dans l’interface utilisateur, un widget peut être lancé afin d’importer des informations relatives aux workloads sources dans le projet. Ce widget présente un lien qui permet de télécharger facilement un modèle de feuille de calcul sur un ordinateur. L’étape suivante consiste à remplir cette feuille de calcul avec les données relatives aux workloads sources. Les informations sur les workloads sources peuvent également être ajoutées à PlateSpin Transformation Manager via une API REST.

Tandis que la phase de planification avance, davantage de données sur les workloads sources peuvent devenir disponibles. PlateSpin Transformation Manager permet les importations ultérieures d’informations relatives aux systèmes précédemment importées. Le nom de domaine complet est utilisé comme clé pour rechercher et mettre à jour ou compléter les informations existantes.

À tout moment, les données importées peuvent être complétées grâce à la découverte en temps réel d’informations sur le workload source. Cette découverte facultative est exécutée par PlateSpin Transformation Manager conjointement avec au moins un serveur PlateSpin Migrate. Grâce à cette découverte en temps réel supplémentaire, les données exigées pour l’importation initiale via des feuilles de calcul ou l’API sont limitées.

Il est important de savoir que PlateSpin Migrate impose deux exigences en matière d’espace disque disponible au workload source :

100 Mo d’espace disque disponible sont requis pour l’installation du contrôleur PlateSpin Migrate. Celui-ci est généralement automatiquement installé lors de la phase de préparation de la migration ;

pour les workloads Windows, 10 % d’espace disponible sont requis par volume. En effet, PlateSpin Migrate crée des snapshots VSS au cours de la réplication, pour garantir une réplication cohérente des données. Les 10 % d’espace disponible sont requis pour accueillir les snapshots. La même exigence s’applique aux workloads Linux, mais au niveau du groupe du volume, et uniquement si un LVM est utilisé.

PlateSpin recommande également de vérifier l’intégrité du système de fichiers de tous les workloads sources avant de commencer la réplication. La corruption des données peut empêcher le démarrage correct du workload cible, car les corruptions peuvent être copiées de la source

PlateSpin recommande de vérifier l’intégrité du système de fichiers de tous les workloads sources avant de commencer la réplication.


10


vers la cible. Cela s’applique tout particulièrement aux réplications par bloc. Pour les workloads Windows, l’utilitaire de vérification du disque (chkdsk) peut être utilisé pour procéder à la vérification de l’intégrité.

Planification de votre projet dans PlateSpin Transformation ManagerUn seul projet de transformation de datacenter peut contenir des dizaines de milliers de workloads, mais même un millier de workloads peut être difficile à traiter sans la possibilité de catégoriser et regrouper les workloads en portions plus faciles à gérer. PlateSpin Transformation Manager propose trois niveaux de regroupement :

Lot : un lot contient un ou plusieurs workloads. En règle générale, ces workloads appartiennent à une ou plusieurs applications et leur transition devra être effectuée dans le même délai.

Vague : une vague contient un ou plusieurs lots.

Projet : un projet contient une ou plusieurs vagues.

Lors de la planification du projet, les workloads peuvent facilement être regroupés en vagues et en lots grâce aux outils de recherche avancée et d’édition groupée, comme illustré dans la figure suivante.

_________________________________________________________________

Niveaux de regroupement de PlateSpin Transformation Manager :

Lot

Vague

Projet

Fig. 3

Les groupes de workloads peuvent facilement être identifiés grâce au formulaire de recherche avancée .

11www.microfocus.com

Fort de son expérience, PlateSpin recommande de ne pas effectuer plus de 10 réplications simultanées dans un cluster VMware.

Conception d’une infrastructure de migration évolutive

L’architecture de l’infrastructure de migration PlateSpin constitue un facteur déterminant pour la réussite d’un projet. Plusieurs limites d’évolutivité déterminent le type d’architecture nécessaire.

1. Limites d’évolutivité de PlateSpin MigrateUn serveur PlateSpin Migrate peut gérer jusqu’à 40 réplications simultanées et environ 200 workloads découverts et/ou configurés simultanément. Il s’agit de « fenêtres de déplacement » : lorsqu’une réplication se termine, une autre peut démarrer dans la mesure où la limite maximale de 40 réplications simultanées n’est pas dépassée. De même, si un workload a été migré, les informations le concernant peuvent être supprimées du serveur PlateSpin Migrate afin de libérer l’espace pour un nouveau workload. Lorsque la solution PlateSpin Transformation Manager est utilisée, les migrations de workloads bénéficient d’un équilibrage de charge automatique sur tous les serveurs PlateSpin Migrate disponibles.

En outre, jusqu’à 30 plates-formes cibles distinctes peuvent être découvertes et gérées par le serveur PlateSpin Migrate. Lors de la découverte d’un cluster VMware, les hôtes ESX(i) individuels deviennent les plates-formes cibles. Par exemple, un serveur PlateSpin Migrate peut gérer 2 clusters VMware de 15 hôtes chacun, ou 3 clusters de 10 hôtes.

2. Limites d’évolutivité de la plate-forme cibleLa réplication de workloads sur une plate-forme cible entraîne des contraintes importantes au niveau des ressources de réseau et de stockage sur la plate-forme cible. Si celle-ci contient des ressources partagées, comme c’est le cas avec les hyperviseurs, cette contrainte peut avoir un impact négatif sur les autres workloads exécutés sur la plate-forme cible en même temps que les migrations. Pour éviter cela, une approche en deux temps est recommandée : les workloads sont migrés vers une « plate-forme cible temporaire » sur laquelle aucun workload de production n’est exécuté, avant d’être envoyés vers leur destination de production finale.

La vitesse à laquelle la plate-forme cible peut gérer les réplications entrantes doit également être prise en compte. Fort de son expérience, PlateSpin recommande de ne pas effectuer plus de 10 réplications simultanées dans un cluster VMware.


12


3. Limites d’évolutivité de la plate-forme sourceLa réplication de workloads génère également des contraintes au niveau des ressources du réseau sur la plate-forme source. Les contraintes relatives au processeur, à la RAM et aux ressources de stockage ne sont pas importantes ici, car les données doivent seulement être lues et non pas écrites. Il est important de prendre en compte la bande passante réseau de la carte réseau (carte d’interface réseau, virtuelle ou physique) qui relie la plate-forme source à l’infrastructure réseau : quelle que soit la vitesse de cette dernière, aucune migration ne doit pouvoir consommer davantage de bande passante que celle offerte par la carte d’interface virtuelle de connexion. Ce facteur est d’autant plus important dans les environnements virtualisés où une carte d’interface réseau physique peut être partagée par plusieurs workloads : si cette carte a un débit de 1 Gbit/s et si plusieurs workloads sont répliqués en même temps, toutes les réplications devront partager la liaison de 1 Gbit/s, ce qui entraînera des temps de migration accrus, même sur une infrastructure réseau de 10 Gbit/s ou plus.

4. Erreur humainePlateSpin Migrate est un outil de migration permettant à plusieurs utilisateurs de travailler en même temps sur la migration de workloads. Cependant, pour éviter toute erreur humaine (ne plus savoir qui travaille sur quel workload ou un administrateur effectuant par erreur une opération sur le workload d’un autre administrateur, par exemple), PlateSpin recommande de ne pas avoir plus de trois administrateurs se partageant le même serveur PlateSpin Migrate. Une personne peut travailler sur plusieurs serveurs PlateSpin Migrate, mais un serveur ne doit pas être géré par plus de trois personnes. Chaque équipe se voit attribuer un ensemble d’applications à migrer et doit utiliser un seul et unique serveur PlateSpin Migrate pour migrer tous les workloads appartenant à ces applications.

Lorsque la solution PlateSpin Transformation Manager est utilisée, le risque de ce type d’erreurs humaines est pratiquement inexistant.

_________________________________________________________________

PlateSpin recommande que trois personnes au maximum partagent le même serveur PlateSpin Migrate.


5. Infrastructure réseau

Mesure de la bande passanteMême si des vitesses de réseau rapides (par exemple, 10 Gbit/s) sont théoriquement disponibles, des calculs doivent être effectués afin de garantir que la bande passante disponible est suffisante pour le volume de données devant être déplacées simultanément. La véritable bande passante disponible entre le workload source et la plate-forme cible devrait être déterminée le plus tôt possible dans le projet, car elle aura une influence significative sur la vitesse réelle de migration. Pour mesurer efficacement la bande passante réellement disponible, il est possible d’utiliser l’outil iPerf. Il s’agit d’un outil basé sur un serveur client qui doit être exécuté sur la plate-forme cible. Pour une cible VMware, cela peut être effectué au sein d’une petite machine virtuelle dédiée. Le côté client peut alors être téléchargé et lancé sur le workload source, après quoi la bande passante entre la source et la cible peut être mesurée. PlateSpin recommande vivement de mesurer l’intégralité de la bande passante disponible pour tous les chemins réseau de la plate-forme source vers la cible avant le début des migrations réelles.

PlateSpin recommande vivement de mesurer l’intégralité de la bande passante disponible pour tous les chemins réseau de la plate-forme source vers la cible avant le début des migrations réelles.

Fig. 4

Visualisation de certaines des contraintes les plus importantes (exemple pour une infrastructure cible VMware) .

_________________________________________________________________


14


Ajustement du réseauSelon la latence du réseau, la fenêtre de réception TCP/IP entre la source et la cible peut être ajustée afin d’obtenir un débit supérieur au cours des réplications. Pour connaître les étapes détaillées de ce processus, consultez la documentation de PlateSpin Migrate. En outre, chaque infrastructure réseau a une taille caractéristique de messages pouvant être transmis, appelée unité de transmission maximale (MTU). PlateSpin Migrate permet aux administrateurs de définir la MTU pour toutes les réplications, afin d’éviter la fragmentation de paquets et la baisse conséquente des performances en matière de débit. Pour connaître les étapes détaillées de ce processus, consultez la documentation de PlateSpin Migrate.

CompressionPour les liaisons très lentes telles que les liaisons WAN, PlateSpin Migrate permet de comprimer les données avant de les envoyer sur le réseau. Selon le type de données, une compression allant jusqu’à 70 % peut être obtenue, ce qui accélère la réplication. Toutefois, dans la mesure où le processeur sur le workload source est utilisé pour compresser les données, une surcharge de processeur supplémentaire d’environ 5 % doit être prise en compte.

Chemins de communication requisPour une présentation détaillée des chemins de communication, y compris les ports qui doivent être ouverts dans les pare-feu, reportez-vous à la documentation technique de PlateSpin Migrate, dans laquelle ces informations sont facilement accessibles. Les exigences suivantes sont les plus importantes :

connectivité entre le serveur PlateSpin Migrate et le workload source ;

connectivité entre le serveur PlateSpin Migrate et l’image ISO auxiliaire Linux Ram Disk (LRD) au cours de la réplication. Au cours de toute réplication, le workload cible démarre toujours à partir de cette image. Cette connectivité peut utiliser un réseau dédié, le cas échéant, qui peut être sélectionné à la phase de configuration de la migration ;

connectivité entre le workload source et la même image ISO auxiliaire LRD, au cours des réplications. Ce chemin réseau est le chemin utilisé pour le trafic de réplication, de sorte que la bande passante requise doit être minutieusement étudiée ;

connectivité entre le serveur PlateSpin Migrate et la plate-forme cible (par exemple, le serveur VMware ESX) vers laquelle le workload est migré ;

connectivité entre le serveur PlateSpin Migrate et le workload cible dans son format final, c’est-à-dire une fois que l’adresse IP de production lui a été assignée. Cette exigence s’applique également lorsque le workload est en cours de test, après que l’adresse IP de test lui a été assignée. Le processus final de configuration du workload cible explique ces exigences : il est effectué via un service de configuration injecté dans le workload cible avant son premier démarrage. Au moment de l’initialisation, ce service de configuration exécute la personnalisation du workload final, puis est automatiquement supprimé. Toutefois, ce service nécessite un accès réseau au serveur PlateSpin Migrate pour télécharger les informations relatives aux éléments devant être configurés.

PlateSpin Migrate permet aux administrateurs de définir la MTU pour toutes les réplications, afin d’éviter la fragmentation de paquets et la baisse conséquente des performances en matière de débit.


Gestion des adresses IPLorsque PlateSpin Migrate réplique un workload (c.-à-d. au cours d’une réplication intégrale ou incrémentielle), le workload cible est toujours démarré à partir d’une image ISO auxiliaire Linux RAM Disk (LRD). Cette image nécessite une adresse IP afin de pouvoir communiquer avec le workload source et le serveur PlateSpin Migrate via le réseau. Il faut configurer cette adresse IP dans le cadre de la configuration de la migration de workload dans PlateSpin Migrate.

Cela signifie que quatre adresses IP potentiellement différentes sont actives au cours du processus de migration intégrale :

adresse IP du workload source (généralement fixe, au moins dans le cadre d’une migration à chaud) ;

adresse IP du serveur PlateSpin Migrate (fixe) ;

adresse IP du workload cible dans sa configuration finale. Cette adresse IP peut être identique à celle du workload source (en supposant que la source sera arrêtée après la transition), ou peut être différente ;

adresse IP de l’image ISO auxiliaire LRD au cours des réplications. Si l’adresse IP du workload cible dans sa configuration finale est différente de celle du workload source, généralement cette même adresse IP de workload cible peut être utilisée, car elle n’est pas en conflit avec l’adresse IP source. Cependant, si l’adresse IP de la source doit être transférée en l’état vers le workload cible dans sa configuration finale, une adresse IP dédiée doit être prévue pour la réplication. L’adresse IP du workload cible ne peut pas être utilisée dans ce cas, car elle sera en conflit avec l’adresse IP (identique) du workload source.

Notez que si le service DHCP est utilisé dans l’environnement où se trouve le workload cible, l’assignation d’adresse IP sera principalement gérée automatiquement par celui-ci.

Dynamique d’exécution de projets de migration de workloads à grande échelle

Suivi de la progression du projet avec PlateSpin Transformation ManagerLorsque les workloads sont migrés, les informations dans la base de données PlateSpin Transformation Manager sont constamment actualisées pour refléter l’état le plus récent du projet. Si des délais de transformation de workload sont manqués, un avertissement s’affiche pour indiquer que l’architecte de projet ou le chef de projet doit s’en préoccuper. Ils peuvent alors choisir d’ajouter ce workload à un futur lot, de créer un nouveau lot pour celui-ci ou d’engager toute autre action nécessaire.

Lorsque PlateSpin Migrate réplique un workload, le workload cible est toujours démarré à partir d’une image ISO auxiliaire Linux RAM Disk (LRD).


16


PlateSpin Transformation Manager comprend les états de migration de workload suivants :

Importé : le chef de projet ou l’architecte de projet a importé le workload dans un projet (via une feuille de calcul ou l’API), mais aucune modification n’a encore été apportée.

Informations supplémentaires requises : le chef de projet ou l’architecte de projet a commencé la planification, mais d’autres éléments sont nécessaires pour une bonne exécution de la migration.

Prêt pour soumission : toutes les informations relatives à l’exécution d’une migration ont été fournies, le workload est prêt à être soumis pour migration ultérieurement, selon la planification du projet.

Soumis : le workload a été officiellement remis au chef de projet ou à l’architecte de projet pour migration.

En cours : la migration du workload est en cours.

Terminé : la migration de workload est terminée.

Les informations les plus importantes sur le projet peuvent être consultées à tout moment par tous les rôles disposant d’autorisations sur le projet, dans le tableau de bord du projet. Ce tableau de bord peut également être partagé avec un tiers via le rôle de lecteur du tableau de bord, qui dispose de droits d’affichage uniquement.

_________________________________________________________________

États de transformation de workload de PlateSpin Transformation Manager :

Importé

Informations supplémentaires requises

Prêt pour soumission

Soumis

En cours

Terminé

Fig. 5

Le tableau de bord du projet offre une vue d’ensemble des informations les plus importantes .


Transition de vos workloads : testez tôt et souventAvant la transition vers le nouveau serveur, un certain nombre de tests doivent être effectués. Avec PlateSpin Migrate, le test du workload cible peut s’effectuer dans un environnement isolé tandis que le workload source est toujours en ligne et en production. Aucune limite ne s’applique quant à la durée du test ou au nombre de tests exécutés avant la transition. Une fois les tests terminés, une réplication incrémentielle est automatiquement effectuée afin de synchroniser les workloads source et cible, de sorte que le workload cible contienne les dernières mises à jour pour le test suivant. Ce processus de test et de synchronisation peut être répété autant de fois que nécessaire. Une fois que les équipes de test ont validé le workload cible, une synchronisation finale entre la source et la cible a lieu, après quoi la transition est exécutée.

Pour assurer une cohérence totale des données entre la source et la cible, il est recommandé d’arrêter les services métiers sur le workload source au cours de la synchronisation finale. Cela garantit qu’aucune modification n’est apportée aux données lors du transfert des deltas finaux depuis le workload source vers le workload cible. PlateSpin Migrate comprend un widget qui permet de facilement sélectionner les services à interrompre avant la synchronisation finale.

Les services métiers étant interrompus au cours de la transition, il est indispensable que celle-ci s’effectue le plus rapidement possible. Des synchronisations multiples (généralement intercalées avec des tests, comme décrit plus haut) garantiront que les interruptions de service au cours de la synchronisation finale et de la transition soient maintenues au strict minimum (générale-ment quelques minutes) et, tout aussi important, que les interruptions de service puissent être prévues : la synchronisation finale ne devrait pas prendre plus de temps que les synchronisations automatisées précédentes.

_________________________________________________________________

Avec PlateSpin Migrate, le test du workload cible peut s’effectuer alors que le workload source est toujours en ligne et en production.


162-FR0113-002 | Q | 05/17 | © 2017 Micro Focus . Tous droits réservés . Micro Focus, le logo Micro Focus et PlateSpin, entre autres, sont des marques commerciales ou des marques déposées de Micro Focus ou de ses filiales et sociétés affiliées au Royaume-Uni, aux États-Unis et dans d’autres pays . Toutes les autres marques sont la propriété de leur détenteur respectif .

Obtenir la certification Certified PlateSpin Migration Specialist

Les spécialistes de la migration qui souhaitent devenir des experts de l’utilisation de PlateSpin Migrate peuvent s’inscrire au cours sur l’administration de PlateSpin Migrate. Ce cours couvre tous les aspects de l’utilisation de PlateSpin Migrate, y compris l’installation du produit, la compréhension de la dynamique de migration en masse, la connaissance des options de licence disponibles, l’utilisation de l’interface de ligne de commande, la gestion de pilotes et le dépannage. Une fois ce cours terminé, l’étudiant peut s’inscrire à l’examen de la certification Certified PlateSpin Migration Specialist, qui consiste en une série de questions à choix multiples visant à tester ses connaissances sur tous les sujets pertinents. Pour plus d’informations sur les options de formation et la certification, consultez la page Web de PlateSpin Migrate sur microfocus.com (www.microfocus.com/products/migrate).

Fig. 6

Dans l’interface utilisateur Web de PlateSpin Migrate, il est extrêmement aisé de planifier la réplication d’un workload grâce à un assistant .

___________________________________________________________

Micro FocusFrance+33 (0) 1 55 70 30 13

Micro FocusSiège social au Royaume-UniRoyaume-Uni+44 (0) 1635 565200

www.microfocus.com

www.microfocus.com




http://www.microfocus.com/products/migrate

Documents

PlateSpin Transformation Manager PlateSpin Migrate ... · Table des matières page ... meilleurs résultats. Fig. 1 PlateSpin présente des performances jusqu’à 50 % plus efficaces,