Étiquette dans Business Digital

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.

La Fondation Digitale pour la Transformation Digitale

De nos jours, la nouvelle monnaie c’est la rapidité.

Dans tous les secteurs d’activités les entreprises subissent une nouvelle concurrence venue de la digitalisation, ces entreprises l’ont bien compris mais malheureusement bien souvent trop tard, rares sont celles qui l’ont anticipée, elles sont réactives. Il existe de multitude d’exemples comme Uber avec les taxis et Airbnb avec l’hôtellerie. Ce qui caractérise cette concurrence, c’est l’apport ou l’amélioration d’un service par un nouvel acteur sur un secteur d’activité dominé par des acteurs historiques et qui n’ont pas sus/voulus évolués.

Ces nouveaux services nécessitent d’adapter ou de développer des logiciels à de nouveaux usages et à de nouvelles méthodes de consommation. Pour une entreprise qui vient de se créer c’est simple, elles n’ont pas d’infrastructure et de patrimoine d’applications à faire évoluer, elles peuvent démarrer directement sur un environnement agile et à partir de là développer ces applications. En revanche pour les entreprises existantes ca sera beaucoup plus complexe et cette complexité et proportionnelle à la taille de l’entreprise. Plus les entreprises sont importantes et plus elles auront à faire évoluer un patrimoine d’applications important et auront aussi besoin d’en developper de nouvelles. Pour cela elles devront entreprendre une transformation du personnel et des process mais aussi une Transformation Digitale ! Un “Digital Business” nécessite une “Digital Foundation”

 

La transformation digitale s’opère sur la fourniture des applications, l’hébergement des applications et la consommation des applications tout en renforçant la sécurité. Elle doit résulter d’une foundation unique pour différents usages. Elle repose évidement sur du matériel pour lequel on peut exiger performance, capacité et fiabilité. L’autre partie c’est la part belle du logiciel, c’est elle qui va apporter l’agilité nécessaire à la digitalisation. La fondation peut-être dans le data center privé comme sur une infrastructure cloud public. Elle doit pouvoir héberger des applications classiques comme des Cloud Native Apps qui seront consommées via des desktops, des objets connectés ou des smartphones.

 

 

La transformation digitale doit être impulsée par la direction et répercutée dans toute la chaine managériales car elle implique l’adhésion du personnel qui lui aussi doit être prêt à se “transformer”. C’est la partie la plus compliquée, il faut s’attendre à avoir des résistances, je l’ai souvent constaté. La gestion des couches basses de part l’automatisation nécessitera de moins en moins de personnel qui sera désormais de en plus en plus proche du métier de l’entreprise. L’IT devient partenaire du business voire même partie prenante du business. Cependant c’est difficile de faire comprendre à un administrateur de stockage qu’il n’aura plus de baie de stockage et de réseau SAN à administrer (cf article sur la virtualisation du stockage  http://loeilduse.fr/?p=43). Difficile de faire comprendre à un administrateur réseau que la création de réseaux va être déportée dans une cloud management platform ou un orchestrateur de containers. Ils doivent pourtant comprendre qu’ils tentent de résister à un rouleau compresseur qu’est la tendance du marché et c’est une question de temps avant que la transformation ne s’opère. Ils doivent saisir l’occasion pour s’orienter vers de nouvelles technologies comme le cloud (privé, public et/ou hybride), le DevOps, les containers, la mobilité, l’IOT, les blockchains, …, la liste est longue et il y a quoi bien s’occuper.

Pour être efficiente, la fondation digitale doit être appliquée sur toute la chaine allant des ressources hébergeant les applications jusqu’à l’utilisateur qui va les consommer à l’instar de la sécurité (cf article la sécurité de bout en bout http://loeilduse.fr/?p=249). Très important, cette chaine doit être constituées de composants qui s’intègres les uns aux autres nativement sans effort. Pour diminuer les risques, il est indispensable d’avoir tous ces composants issus du même éditeur.

Commençons par l’hébergement sur le Data Center privé, ensuite le Cloud Hybrid pour finir par la consommation via les terminaux :

 

Le Data Center Privé 

L’agilité va permettre de gagner du temps en étant plus réactif voire proactif.  Pour cela, il faut le moderniser en le rendant agile afin que, le patrimoine d’applications puisse en bénéficier, pour y héberger les nouvelles applications Cloud Native et pour renforcer la sécurité existante (car on ne sécurise pas les Cloud Native Apps et les containers comme on le faisait avec les applications traditionnelles). Cette agilité ne peut être obtenue que par le SDDC (Software Defined Data Center) en virtualisant tous les composants du Data Center. Une fois virtualisés, ils pourront être automatisés presque robotisés! L’infrastructure physique, elle est là pour être capacitive, performante et fiable avec un sas de sécurité pour filtrer tout ce qui y rentre et tout ce qui sort. Le SDDC va utiliser ces ressources pour y exécuter tout type d’applications et sera couplé à une Cloud Management Platform ou un orchestrateur de container comme Kubernetes (cf article sur PKS http://loeilduse.fr/?p=158)

L’architecte peut ainsi en tout autonomie “désigner” son application en y intégrant tous les composants du SDDC dont il a besoin. Ci-dessous un exemple de design d’un service web en cluster, la création du réseau, l’insertion de service Load Balancer et l’application de règle de sécurité. Plus besoin de faire des demandes à différences services pour obtenir les ressources dont il a besoin.

 

Une fois terminé, l’architecte peut soit la déployer ou soit le mettre à disposition via un catalogue de services pour des utilisateurs puissent la déployer ultérieurement :

 

Aboutir à ce résultat n’est pas d’un point de vue technique si compliqué que ça, à condition, j’insiste, que tous les composants logiciels du SDDC soient prévus pour fonctionner nativement ensemble, ainsi les efforts d’intégrations et de maintient en condition opérationnel seront réduits. La mise à jour du SDDC se fait sans avoir à se soucier de l’intéropérabilité des versions des composants, le SDDC Manager se charge de ça.

Il ne faut pas aussi que le SDDC n’est d’adhérence avec la couche matériel, vous devez être libre de choisir et de changer les composants physiques avec un minimum d’impact. Ainsi les switches peuvent être des Cisco, des Arista, des juniper, ou autre, les serveurs peuvent être des HP, des DELL, des Lenovo, ou autre, ça n’a pas d’importance que ce soit à la création du SDDC ou durant son cycle de vie.

 

Le Cloud Hybride

Hybride au sens où on peut transférer des applications du cloud public vers le cloud privé et vice-versa en fonction des besoins. Ce qui est recherché :

  • Ce sont des services innovants utilisables à la demande sans avoir à les installer et à les administrer.
  • Des ressources physiques à la demande sans avoir à anticiper les achats matériels. Si un gros projet nécessitant beaucoup de ressources non disponibles sur le Data Center privé, il faudrait attendre de les commander, de les installer et les configurer avant de pouvoir commencer le projet. Avec le Cloud Hybrid on commande un SDDC et deux heures après il est disponible pour démarrer le projet. Si vous souhaitez le voir au final sur votre Data Center privé vous pourrez le rapatrier une fois les nouvelles ressources disponibles. Pour que ce soit faisable et sans risque, il faut que le SDDC public soit le même que le SDDC privé (à minima le même hyperviseur). Pour en savoir plus je vous conseil cet article : http://loeilduse.fr/?p=74.

 

Les terminaux

Une fois les applications déployées il faut les consommer, le problème c’est qu’elles prolifèrent et c’est difficile de s’y retrouver tellement on en a. En plus maintenant ont a plusieurs terminaux : un smartphone (Android ou IOS), une tablette (Android, IOS ou Windows) ou laptop (Mac, Chrome OS ou Windows).

Pour être efficace, l’utilisateur doit avoir une visibilité directe des applications dont il a besoin et ce quelque soit le terminal qu’il utilise. Ci-dessous une copie d’écran du portail avec les applications que j’utilise le plus souvent sur mon Mac ou mon S8.

En plus d’avoir accès rapidement aux applications, on n’a plus à se soucier d’avoir à gérer la complexité des différentes politiques de mot de passe par application, une fois connecté via son compte principal, l’utilisateur n’a plus besoin de s’authentifier à nouveau pour accéder à ses applications et ce quelque soit son mode d’hébergement (SaaS, Web ou installées sur le terminal) (cf article la sécurité de bout en bout, chapitre sécuriser les accès à distance  http://loeilduse.fr/?p=249).