Étiquette dans NSX

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.

Pourquoi PKS (VMware Pivotal Container Service)

Après les VMs, les containers, c’est autour des orchestrateurs de containers de rencontrer un vif succès, mais dans ce domaine les modes ont été éphémères, il y en a un qui sort son épingle du jeu c’est Kubernetes et cet engouement à l’air de s’installer. Je n’ai pas rencontré un client qui ne me parle de ça. Ils ne sont pas tous au même niveau de connaissance et d’appétence mais tous y vont, certes à tâtons car c’est un monde nouveau mais ils y vont. Pour être rassurés, les clients souhaitent se reposer sur des éditeurs pérennes, en qui ils ont confiance, qui ont des solutions robustes et un support fiable. C’est une des raisons pour laquelle PKS est rassurante.

PKS est une solution issue du partenariat entre VMware, Pivotal et Google où chacun apporte sa contribution. D’un point de vu macroscopique VMware apporte la partie registre des containers ainsi que la virtualisation du réseau et de la sécurité, Pivotal apporte la partie gestion du cycle de vie des cluster Kubernetes et Google son orchestrateur de containers kubernetes.

PKS ne modifie pas Kubernetes et n’apporte pas de surcouche ou d’interface intermédiaire. Le Kubernetes qui est utilisé n’est pas non plus un “fork” (une sous branche) mais belle est bien celui de Google, toutes les APIs et les lignes de commande ainsi que les applications que vous allez développer seront compatibles avec un Kubernetes hors PKS. A quelques semaines près vous aurez toujours la dernière version stable de Kubernetes qui sera supportée.

Lorsqu’il est hébergé sur le data center privé, PKS repose sur le SDDC (Software Defined Data Center) de VMware, il utilisera à minima les ressources vSphere et idéalement s’appuiera sur vSAN et NSX. Certains éléments de kubernetes seront surveillés est relancés par PKS, certains éléments de PKS quant à eux seront surveillés et relancés par vSphere HA. Grace à PKS, Kubernetes utilisera de manière transparente la partie stockage de vSphere pour le stockage éphémère ou pour le stockage persistant, lorsque vSAN est présent, les classes de stockage Kubernetes ou les volumes Docker pourront bénéficier des politiques de stockage de vSAN comme par exemple définition de la tolérance aux pannes (FTT). PKS couplé à NSX offre un vrai SDN et une sécurité accrue. Les fonctionnalités de routage, switching et sécurité sont intégrées et distribuées aux hyperviseurs ce qui offre de meilleures performances, une meilleure scalabilité et une plus grande sécurité.  Lorsque des pod Kubernetes sont déployés, les réseaux, les routeurs et les services tels que le load balancing sont automatiquement provisionnés. Les Network Policy utilisé par Kubernetes permettent de définir des règles de sécurités qui sont traduites par des règles de firewall NSX (des vraies pas des ACLs). Il est possible de définir des règles de sécurités inter Pod. Encore une fois c’est transparent pour le développeur, il a juste besoin de connaitre les commandes/API kubernetes et Docker.

 

 

Pour connaitre les flux réseaux, la fonctionnalité Traceflow permet de les visualiser entre deux composants parmi les critères suivants logical switch, VM, IP et MAC. 

Si des règles de sécurité firewall ont bloquées les communications, elles seront aussi affichées ce qui permettra de vite identifier quelle règle est en cause.

 

PKS permet de créer des cluster Kubernetes à la demande. Chaque cluster Kubernetes est indépendant et isolé, plusieurs versions de Kubernetes peuvent résider sur une même plate-forme mais aussi pour plusieurs usages, dev, tests, pré-prod, … ou encore plusieurs “tenant” (colocation. Si vous possédez un portail self service tel que vRA (vRealize Automation), vous pouvez proposer un blueprint Kubernetes As A Service et offrir à un développeur ou à une équipe de développeurs de provisionner de manière automatisée des cluster Kubernetes.

PKS permet de gérer le cycle de vie complet des cluster kubernetes et de ses composants allant de l’installation, des mises à jour, de l’application de patches et le “scaling” du cluster, le tout à chaud.

 

PKS intègre un registre des containers privés (Harbor) pour y déposer vos images que vous ne souhaitez pas mettre sur un registre public. Il intègre une gestion des rôles d’accès (RBAC). Harbor peut scanner les images à la recherche de vulnérabilités, signer les images et répliquer les images sur un autre registre de containers. 

 

Si vous utilisez vROps (vRealize Operations) vous aurez la possibilité de surveiller vos clusters Kubernetes ainsi que l’infrastructure qui l’héberge et avoir ainsi des corrélations de performance et d’incidents.

 

 

Pour monitorer le fonctionnement des applications et/ou les métriques métiers comme par exemple le nombre de transaction par seconde, vous pouvez utiliser WaveFront :

 

 

Pour résumer les avantages de PKS :

  • Dernière version stable de Kubernetes natif de Google, même lignes de commandes, même API. Pas de surcouche !
  • Gestion complète du cycle de vie de Kubernetes, installation, mise à jour, application de patch et scalabilité.
  • Kubernetes As A Service, des cluster Kubernetes à la demande indépendant et isolé.
  • Utilisation du SDDC VMware permettant d’avoir un environnement Kubernetes résilient, performant et sécurisé.
  • Provisionnement automatique et natif de load balancer, réseaux, règles de sécurité et niveaux de service stockage.
  • Possibilité de monitorer l’infrastructure complète et les applications.

 

Les avantages non techniques :

  • Gain de temps en formation et en développement : les développeurs non que Kubernetes et Docker à connaitre.
  • Risques réduits : PKS est supportée par VMware et repose une plate-forme SDDC sécurisée.

Pour plus d’information https://cloud.vmware.com/fr/pivotal-container-service/resources

Pour la tester : http://labs.hol.vmware.com/HOL/catalogs/lab/4249