Lorsque vous assurez une prestation auprès de clients, il est important de se familiariser avec son infrastructure et le périmètre que le client vous confie. Mais dans le cadre d’un projet de migration comme celui-ci, cet aspect est encore plus important ! C’est pourquoi la première phase consiste à réaliser un audit de l’infrastructure existante en se posant les bonnes questions. En voici une liste non exhaustive :
Les ESX
Toute la configuration hardware et logiciel des ESX doit être référencée avec notamment les réseaux virtuels.
Les VM
Nom/OS/Config Hardware/Type d’environnement/Application
Identifier les VM permettra de les regrouper tous par application. En effet gardez toujours à l’esprit qu’une infrastructure fournit un service. En conséquence, vous proposerez un planning de migration en migrant les VM ciblées en même temps. Par exemple elles peuvent comporter un serveur IIS et un serveur de BDD. Ces 2 VM doivent donc être migrées en même temps.
Identifier les VM par leur nom permettra de remonter au client des erreurs dans la convention de nommage. Ainsi il est possible de voir qu’une VM a été restaurée, son intitulé devra donc être changé avant ou pendant la conversion.
Identifier la configuration Hardware permet d’évaluer le temps de conversion des VM. En effet plus le stockage d’une VM sera important plus la phase de migration sera longue. Mettez également un point d’attention aux VM hébergeant des BDD
Connaître l’OS des VM permettra des actions à mener pour les services d’intégration. En effet si l’OS est de type Windows, alors la configuration sera automatique. Par contre, pour les distributions Linux, il faudra vous renseigner en amont et le jour J pour mener les actions nécessaires une fois la conversion effectuée afin d’assurer une bonne qualité de service.
Enfin, cet audit permettra de savoir quelles VM doivent être migrées ! Par exemple il est possible que des VM éteintes depuis longtemps ou de test soient encore présentes, le client est cependant le décideur final.
Audit des jobs de sauvegarde
Toute infrastructure étant normalement sauvegardée il est important d’identifier les jobs de sauvegarde pour les modifier une fois la migration des VM effectuée. En effet les sauvegardes ne sauvegarderont plus des VM sous VMWare mais sous Hyper-V. Enfin, réaliser cet audit permettra de mettre en lumière l’état des sauvegardes en répondant à des questions du type :
- De quand datent les dernières sauvegardes des VM ?
- Quelle est la rétention configurée ?
- Les sauvegardes se font-elles sur un stockage dédié ou non ?
- Quelles sont les best practices de configuration pour Hyper-V ?
Conception d’une nouvelle architecture de virtualisation
Une fois la phase d’audit terminée vient la phase de création de la nouvelle architecture Hyper-V. Il faudra donc se poser les bonnes question en fonction des informations reçues lors de la phase d’audit. En voici un exemple :
- De combien d’hôtes Hyper-V avez-vous besoin ?
- Windows Server Hyper-V sera-t-il installé avec ou sans GUI ?
- Quelle sera ma configuration réseau ? Combien de NIC ?
- Quels sont les flux réseaux à ouvrir ?
- Une baie de stockage de type NVMe (SSD) est-elle nécessaire ?
- Quelle sera la politique de déploiement des patchs ?
- Quelles sont les exclusions de l’antivirus à ajouter ?
- Quels comptes Active Directory seront autorisés à son administration ?
Phase de Migration avec System Center Virtual Machine Manager
Une fois votre nouvelle infrastructure fraichement en place, il est à présent temps de s’occuper de la migration des VM identifiées. Pour ce faire il faut installer votre SCVMM. Il y a cependant une question à vous poser : faut-il l’installer en virtuel ou sur une machine physique ?
Dans l’idéal un serveur SCVMM physique vous permettra d’avoir la main sur votre infrastructure en cas de problème !
Une fois la conversion de toutes les VM effectuées n’oubliez pas de rédiger l’ensemble des documents associés soit :
- Un Document d’Architecture Technique
- Un guide d’exploitation
- Un HLD et un LLD : le HLD définit votre architecture de manière globale tandis que le LLD la définit de manière extrêmement détaillée
Le client avait l’habitude d’utiliser son environnement VMware mais à présent il va devoir apprendre à utiliser un nouvel environnement auquel il n’est pas familier. Il faudra donc faire preuve de pédagogie ! Imaginez que vous changiez de voiture et que le concessionnaire vous donne le mode d’emploi sans rien vous expliquer. Dans notre cas c’est la même chose.
Étant donné l’augmentation des prix de licences suite au rachat de VMware par Broadcom il est fort à parier que d’autres projets de ce type verront le jour et Metsys sera toujours présent pour accompagner ses clients.
