Étiquette dans HCX

Ca déménage

 

Le plus important dans un déménagement de Data Center qu’il soit de OnPrem vers/depuis le Cloud Public et/ou de OnPrem vers le OnPrem, ce sont les données, les applications et leur accessibilité par les utilisateurs internes et externes. Un des intérêts d’un déménagement de Data Center et d’en profiter pour le rendre plus moderne, plus agile, plus véloce afin d’y héberger les applications modernes à base de container à côté des applications existantes.

Dans cet article, je ne vais pas couvrir les applications fonctionnant directement sur des serveurs physiques, c’est un périmètre que je ne couvre pas habituellement chez mes clients, et il ne représente qu’un faible pourcentage d’application, environs moins de 10%. En revanche, je vais traiter celles s’exécutant sur des environnements virtualisés, ce qui représente environs pus de 90% des applications. La majorité des clients dispose d’hyperviseurs vSphere, certains peuvent encore avoir un peu d’Hyper-V ou de KVM mais c’est vraiment très rare.

Un des avantages apportés par la virtualisation des serveurs et la faculté de représenter une machine physique et de tout ce qu’elle contient (système d’exploitation, Applications, configurations, données, …) dans des machines virtuelles (VMs) qui sont stockées dans des fichiers. Le déménagement de ces VMs, consiste donc à copier ces fichiers vers la nouvelle destination. Pour accéder aux VMs copiées, il faut les connectés à un réseau si possible sans avoir à modifier le plan d’adressage IP initial car c’est un travail fastidieux et risqué, en effet certaines applications n’ont pas été conçues pour prendre en compte ce type de changement. Pour simplifier cela, il faut virtualiser le réseau et ainsi être capable de reproduire à la destination ce qu’il y avait sur le site initial permettant d’éviter le changement d’adressage IP de tous les serveurs et des applications. A noter qu’il n’est pas nécessaire de virtualiser le réseau à source seule à la destination suffit. Une autre méthode aurait été de reproduire physiquement et à l’identique le réseau à la destination, même si cela est possible dans un déménagement de OnPrem vers OnPrem, c’est impossible à réaliser dans un déménagement vers le Cloud Public. Vous l’aurez compris, appliquer la virtualisation au réseau comme cela a été fait aux serveurs physiques permet d’être complément découplé de l’infrastructure physique et être libre de choisir le fournisseurs matériel et/ou hébergeurs.

La première étape du déménagement consiste à avoir un environnement de destination virtualisé à minima l’hyperviseur et le réseau pour recevoir les VMs, il faut ensuite les transférer, nous avons vu que les VMs étaient des fichiers et qu’il suffisait de les copier sur la destination. C’est aussi simple que ça, cependant pour avoir un état cohérent des données, la copie devra se faire à froid, c’est-à-dire VMs éteintes, cela engendra une indisponibilité d’accès aux applications durant toute la durée de la copie. Une fois terminée et les VMs associées aux bons réseaux il faut les démarrer à la destination. Les copies vont être longues et donc l’indisponibilité le sera aussi car il y aura une grosse volumétrie de données. Une autre méthode consiste à utiliser des outils de réplication qui vont répliquer les VMs pendant leur fonctionnement, et seulement une fois la réplication terminée arrêter les VMs à la source, finir de répliquer les résidus puis démarrer les VMs à la destination. Ces deux méthodes manuelles peuvent convenir pour des petits environnements mais pas s’il y a des centaines ou des milliers VMs, ça devient rapidement fastidieux. Pour encore simplifier ce processus, il est possible de tout orchestrer en utilisant un outil tel que VMware HCX que je vais décrire et qui permet de répondre à certaines questions importantes, comment faire un déménagement si mes applications ne me permettent pas d’indisponibilité ? Comment je fais si je veux un déménagement séquentiel ? Ou encore comment tout préparer et le faire à un moment précis ?

VMware HCX offre différents types de migration :

  • Bulk Migration : Pour des migrations massives de VMs, elles se feront en parallèle par lots.
  • Mobility Groups : pour migrer des VMs regroupées par thématique.
  • vMotion Migration : pour déplacer des VMs de façon unitaire.
  • OS Assisted Migration : Pour migrer des VMs non vSphere donc soit KVM ou Hyper-v

En plus des types de migration, il y a des fonctionnalités réseau intéressantes dans le cadre de migration :

  • Interconnect : déploie un virtuel interconnecte réseau sécurisé entre les appliances HCX de part et d’autre pour plus de sécurité/
  • Wan Optimization : Permet de réduire la quantité de donnée qui transite entre les sites via des mécanisme de déduplication et de compression.
  • Network Extension : Permet d’étendre le niveau 2 du réseau entre les sites et garder ainsi le même plan d’adressage de part et d’autre.
  • Application Path Resiliency : Permet de multiplier les chemins de communication entre les sites et de ne plus utiliser ceux qui ont subis une défaillance.
  • Mobility Optimized Networking (MON) : Permet utiliser la gateway la plus proche (donc sur le même site) pour les applications qui souhaitent atteindre un réseau différent.

D’autres cas d’usages sont offerts par VMware HCX :

 

  • Upgrade des versions vSphere : pour migrer des VMs hébergées sur une version de vSphere et aller vers un hyperviseur de version différente.
  • Workload Rebalancing : Déplacer les workload entre différents Cloud en fonction de la disponibilité des ressources et/ou de la saisonabilité des coûts.
  • Business continuity and Protection : pour protéger des workloads sur un autre site et bénéficier des avantages réseau. Ça peut aussi être couplé à SRM (Site Recovery Manager).

 

Revenons sur le sujet initial du déménagement avec d’autres points importants d’actualité émanent des demandes croissantes d’aller vers le Cloud Public, ces demandent amènent ces questions, comment je fais pour déménager vers un Cloud Public sans avoir à transformer mes VMs ? Comment faire si demain je décide de changer de Cloud Public et ainsi éviter d’être verrouillé ?

Pour être le plus indépendant possible il faut avoir un format de VMs multi-cloud, c’est-à-dire un format de VM qui est disponible dans les data center OnPrem mais aussi chez la quasi-totalité des hyperscalers tels que Alibaba Cloud, Amazon Web Services, Google Cloud Platform, Microsoft Azure, Oracle Cloud Infrastructure, OVH, …, et ce avec une présence géographique locale et/ou globale. C’est le cas des VMs utilisées par VMware, en effet les hyperscaler ont décidé de proposer à leurs clients d’utiliser leur hyperviseur et/ou l’hyperviseur développé VMware que les clients on l’habitudes d’utiliser. Cette décision n’est pas anodyne car elle permet de simplifier drastiquement les migrations en éliminant la nécessité de transformation et ainsi consommer plus rapidement leurs ressources. Les plus gros d’entres-eux proposent même le SDDC VMware complet en y ajoutant la virtualisation du réseau et du stockage couplé à VMware HCX pour encore plus accélérer encore plus la migration. Les clients ont ainsi plus de liberté de choisir leur fournisseur de Cloud qu’il soit OnPrem ou Public.

En résumé, le plus important dans un déménagement est d’avoir une destination qui soit le plus virtualisé possible, virtualisation des serveurs, du réseau (sécurité incluse) et du stockage. Avoir un orchestrateur qui va simplifier la migration et de choisir un format de VM qui soit multi-cloud pour éviter d’être verrouillé avec un hyperscaler.

Le Cloud Hybrid comble les inconvénients du Cloud Public

C’est un constat personnel que j’ai fait, dans certains secteurs d’activité notamment là où c’est économiquement très tendu comme dans la distribution ou l’industrie, il y a une plus grande appétence au cloud public. Ils ont mis en place une stratégie Cloud Public First ou Cloud Public Only. Quand je pose la question à mes interlocuteurs habituels quelle est la raison de cette stratégie, la réponse est souvent la même, ça vient d’en haut, de la direction informatique et/ou des finances. En effet un gros contrat signé avec l’un des trois acteurs du Cloud Public à savoir Amazon pour AWS, Microsoft pour Azure ou Google pour GCP, promettant de faire de grosses économies financières. Les opérationnels eux, ne sont pas consultés dans cette décision mais ont tout de même la charge de devoir mettre en place une campagne de migration massive pour suivre cette stratégie.  Pour la majorité de ces entreprises cette stratégie est récente, d’autres ont été précurseurs et cela permet d’avoir un peu de recul sur les bénéfices et les déficits qu’elle apporte :

  • L’aspect économique doit être scruté à la loupe car il y aura des mauvaises surprises, c’est sûr. Les éléments à prendre en compte :
    • Le gabarit des machines virtuelles. Un certain gabarit de machine virtuelle en ressource processeur et mémoire sera plus favorable au Cloud Public. Ce gabarit permet à l’hébergeur de faire fonctionner un nombre optimal de machine virtuelle sur un hôte physique et donc mieux amortir le coût de la machine physique. Alors que d’autres gabarits seront plus favorables au cloud privé. Il faut bien vérifier le coût du gabarit à migrer avant de faire le transfert.
    • La saisonnalité. Si votre application a des saisonnalités comme par exemple en période de solde, elles vont nécessiter des ressources physiques à la hausse durant cette période puis à la baisse une fois cette période terminée. L’élasticité native présente dans le Cloud Public évite des investissements en matériel et en logiciel d’infrastructure pour une utilisation périodique faible.
    • La périodicité. Si des environnements peuvent fonctionner sur une plage horaire partielle comme par exemple, la journée ou la nuit, ils permettent de payer l’infrastructure uniquement durant ces périodes d’utilisation et non pas tout le temps comme ça serait le cas sur un environnement On-Premise.
    • Les flux réseau. Les flux entrants vers le cloud public sont gratuits par contre les flux sortants sont dans la plupart des cas facturés, c’est un élément à prendre en compte si vous avez des échanges inter application ou si vous devez faire des exports de model de données volumineux.
    • Les services additionnels. Certains services comme une adresse IP publique ou encore des load balancer peuvent être commander (donc payés) à la demande puis associés à des VMs. Lorsque que la VM est détruite, les services associés ne sont pas “décommissionés” pour autant et continueront à être facturés.
    • Pour éviter les surprises il faut se doter d’un outil (eg : CloudHealth) qui vous donnera une visibilité pertinente de la consommation à l’instar d’un tableau de bord d’un d’avion. Il proposera ainsi des économies en identifiant les ressources mal, peu ou pas utilisées.
  • L’aspect services à valeur ajoutée comme l’intelligence artificielle ou le machine learning apportent un bénéfice indéniable car ce genre de service est difficile à obtenir On-Premise.
  • L’aspect agilité est là aussi un point fort au cloud public, avoir des ressources à la demande et les libérer quand on en a plus besoin.
  • L’aspect couverture géographique international est intéressant mais ne pourra pas se faire avec un hébergeur unique car pour des raisons réglementaires et/ou politiques, les trois acteurs principaux ne sont pas présents dans certains pays comme en Russie.

Il y a plusieurs possibilités pour aller dans le cloud public, il faut soit développer ses applications directement dessus, soit avoir une application basée sur des containers pour les transférer sans les retoucher, mais pour les autres qui sont la grande majorité des cas, il faudra les transformer. En effet il y a une forte chance que le format des VMs qui hébergent les applications dans vos Data Center On-Premise soit différent de celui des VMs du cloud public, il faudra donc les transformer. Il existe des outils pour les transformer mais ils fonctionnent correctement que si ce sont des applications simples.

Une fois que vous êtes dans le cloud public, êtes-vous sûr d’y rester ? Que faire si les coûts d’hébergement augmentent ou si les éditeurs des applications changent leur mode de tarification lorsqu’elles sont hébergées sur le Cloud Public ? Que faire si l’hébergeur devient un concurrent dans votre secteur d’activité, si les performances, le niveau de service ou les services ne sont pas au rendez-vous ? Comment faire des retours arrière, car cela nécessiterait une deuxième transformation pour revenir sur l’On-Premise et voire une troisième si c’est pour aller ensuite vers un autre hébergeur ?

La transformation n’est pas si simple, elle comporte des indisponibilités de service, des risques techniques et financiers et est très chronophage. Le coût de cette transformation et l’évaluation des risques associés ne sont pas pris en compte dans le coût de cette stratégie.

Alors comment éviter une telle transformation et pouvoir être libre de changer d’hébergeur tout en respectant la stratégie de son entreprise exigeant d’aller vers le Cloud Public ?

Il existe une solution moins radicale et plus agile, si vos applications sont hébergées sur l’hyperviseur vSphere ce qui doit représenter environs plus de 80% des cas, vous pouvez commander directement un SDDC VMware (Software Defined Data Center : Data Center virtualisé) chez l’hébergeur de votre choix, Atos, AWS, Azure, GCP, Oracle, OVH et bien d’autres avec pas loin de 4500 partenaires (VMware Cloud Verified Partner). Cela se fait en général directement à partir de la Market Place de l’hébergeur (Exemple : Azure VMware Solutions), ou directement chez VMware dans le cas d’AWS seulement (VMware Cloud On AWS) Ce processus prend environs 2 heures et vous avez ensuite un environnement complet serveur, stockage, réseau et sécurité qui vous ait dédié. Cet environnement est aussi basé sur l’hyperviseur vSphere, ce qui permet d’exécuter vos applications sans avoir à les transformer. La virtualisation du réseau permet de reproduire la topologie de votre réseau actuel sans avoir à modifier les adresses IP des serveurs et des applications. Vos applications s’exécutent ainsi comme chez vous mais dans le Data Center d’un Cloud Public à proximité des services natifs de l’hébergeur, comme montré dans le schéma qui suit, exemple sur AWS :

Vous avez ainsi le meilleur des deux mondes. Vos applications consomment des services natifs via les APIs et si vous souhaitez changer d’hébergeur, vous déplacez votre application vers le nouvel hébergeur et modifiez uniquement les appels API à ces services natifs. Et même cette partie peut être éviter en utilisant un “Wrapper” qui sera adresser les spécificités des APIs de chaque fournisseur. Il n’est donc pas nécessaire de transformer l’application complète. 

Maintenant que vous avez un SDDC chez un cloud public, comment déplacer simplement ses applications ?

Il est possible d’utiliser la méthode classique, c’est à dire faire un vMotion entre les deux environnements comme il est possible de le faire On-Premise depuis plusieurs années, ce qui fut une des forces de l’hyperviseur vSphere, ou utiliser l’outil de migration HCX qui permet de faire des migrations à chaud ou à froid, en masse, planifiable tout en bénéficiant d’une optimisation réseau pour que les migrations durent moins longtemps.

Le Cloud Public offre beaucoup de services innovants qu’il ne faut pas hésiter à utiliser. Par contre, il ne faut pas vous “verrouiller” avec un acteur, il faut que vos applications soient mobiles. La meilleure approche pour cela est de minimiser au maximum les dépendances. Cela passe par la modification partielle du code de l’application, en modifiant uniquement l’appel aux services natifs (ou passer par un “wrapper” d’API) et de garder son hébergement sur un format de VM qui garantira sa mobilité. Il n’y aura pas de “verrouillage” commercial avec VMware car les SDDC se contractualisent directement avec les fournisseurs des Cloud Public, sauf pour AWS où vous avez le choix de contractualiser avec VMware ou AWS.