Stockage primaire : quelle transition du on-premise vers le cloud ?
Plusieurs approches sont possibles pour réussir la migration d’une application existante vers le cloud. Mais toutes requièrent de s’interroger sur la meilleure façon de transférer et de stocker ses données une fois la migration achevée.
La plupart des applications dans les entreprises s’appuient aujourd’hui sur des baies de stockage SAN et NAS pour entreposer leurs données. Ces applications s’appuient sur des architectures traditionnelles et n’ont pas les attributs de résilience des applications modernes comme les applications cloud natives.
Lorsqu’elles doivent migrer dans le cloud, il faut donc prendre soin de répliquer les caractéristiques des infrastructures dont elles dépendent (dans le cas d’une approche de type « lift and shift ») ou trouver dans le cloud des services alternatifs afin de reproduire leur fonctionnement.
Une autre question importante se pose : celle de l’organisation, plus ou moins transparente, de la migration des données.
Cloud hybride homogène : la solution de facilité
La solution la plus simple pour la migration d’une application on-premise dans le cloud est de la transporter sur une cible dont la technologie est identique à celle de la plate-forme source. Pour les entreprises qui opèrent une infrastructure virtualisée avec VMware, il est par exemple possible d’opter pour un service de cloud motorisé par VMware Cloud Foundation, comme celui proposé par IBM ou celui que commercialise VMware sur la plate-forme Amazon AWS.
Celui d’IBM a l’avantage d’être déjà disponible assez largement à l’international, alors que VMware on AWS n’est disponible qu’aux États-Unis (mais le service devrait élargir sa couverture ce printemps). OVH devrait aussi faire évoluer prochainement son offre de cloud privatif VMware vers VMware Cloud Foundation. Cette offre s’appuie sur le stockage hyperconvergé VSAN et présente donc la plupart des attributs d’un stockage traditionnel en matière de services avancés, tout en ayant des attributs de scalabilité proches de ceux d’un service cloud.
L’avantage d’une approche homogène est qu’elle permet des déploiements de type cloud hybride pilotés depuis une console hybride. Il est même possible - à condition d’avoir une connexion suffisamment performante - de migrer des applications « en live », c’est-à-dire sans arrêt de production, entre l’infrastructure on premise et le cloud.
Avec Nutanix Xi et Azure Stack, Nutanix et Microsoft ont l’ambition d’offrir le même type de simplicité.
C’est aussi le cas d’Oracle qui permet des migrations transparentes de son offre Cloud@customer vers son cloud. Ou du français OutScale pour les clients qui déploient son offre à la fois en mode privé on-premise en en mode public.
Le bénéfice d’une telle approche est qu’elle permet de migrer ses applications rapidement dans un cloud public ou privé sans changer fondamentalement la façon dont on opère ses applications, ni reformer ses personnels. L’entreprise n’a plus à gérer l’infrastructure des applications migrées dans le cloud et peut convertir tout ou partie de sa dépense en mode OPEX.
Seul vrai bémol, en choisissant cette approche, on ne bénéficie pas vraiment de tous les bénéfices d’un vrai cloud notamment en matière de flexibilité et d’élasticité.
L’approche « Lift and Shift »
L’autre façon de migrer une application vers le cloud est d’adopter une approche de type « lift and shift ». L’objectif est alors de recréer dans le cloud une infrastructure présentant des caractéristiques similaires à celles des applications sur site, puis de migrer les données application par application afin de les ré-instancier progressivement sur une infrastructure différente de celle de l’infrastructure d’origine.
Pour les applications virtualisées avec VMware, de multiples solutions existent pour migrer vers les clouds les plus courants. Il est possible de réaliser les migrations manuellement, mais Amazon propose un plug-in pour vCenter qui permet d’orchestrer la migration de VM et de leur stockage associé vers Amazon AWS.
Ce plug-in permet de recréer à la cible des volumes EBS en lieu et place des disques virtuels des machines d’origine. La migration doit toutefois être planifiée avec précision (notamment pour ce qui est de la gestion du réseau et des plans d’adressages) et elle requiert un certain temps. Elle nécessite aussi un arrêt planifié de l’application.
Pour minimiser les temps de migration, il est possible de créer les instances cibles avec des volumes EBS SSD performants, avant progressivement de basculer ces volumes vers des classes de services plus appropriées.
La migration vers Google Cloud peut elle-aussi s’effectuer de façon manuelle ou de façon automatisée, via les services de CloudEndure, un partenaire israélien de Google Cloud qui a développé une solution de migration au fil de l’eau des environnements on premise vers l’infrastructure cloud du géant américain.
Comme AWS, Google Cloud préconise tout d’abord de veiller à bien paramétrer la configuration réseau avant de migrer les VM et leurs disques associés. Pour la migration de services NAS, il n’est pas possible (tout comme chez AWS) d’organiser la copie et la synchronisation des données en s’appuyant sur des connexions en mode NFS - Google Cloud n’offrant pas un service NAS.
Mais comme l’explique Bastien Legras, en charge des équipes d’avant-vente du fournisseur en France, il est possible de combiner l’offre de stockage objet Google Cloud Storage avec les services virtualisés d’Avere (plate-forme vFXT) pour offrir des services de stockage NAS performants et de les combiner avec les mêmes outils on-premises pour migrer des services NAS de façon transparente vers son cloud.
La technologie d’Avere peut être déployée de la même façon sur la plupart des clouds du marché dans un but similaire.
Chez Microsoft, plusieurs scénarios de migration sont possibles, mais le plus simple est bien sûr celui de la migration d’un environnement Hyper-V vers Azure.
Mais Microsoft propose également le service Azure Migrate pour aider à planifier et à orchestrer la migration d’environnements virtualisés avec VMware vers son cloud public. L’outil permet d’inventorier les ressources à migrer, d’analyser les dépendances puis de faire correspondre de façon optimale les ressources de stockage d’Azure aux ressources de stockage on-premises. Un autre outil - Site Recovery - permet ensuite d’automatiser une large partie du processus de migration.
Une dernière alternative dans le cas d’approche de type « lift and shift » est de ne pas se contenter de migrer les applications, mais de faire un « lift and shift » de l’infrastructure de stockage.
C’est une approche que permet par exemple NetApp en proposant une version appliance logicielle de ses baies de stockage que l’on peut déployer au-dessus des services en mode bloc de la plupart des services cloud. Avec l’appliance Ontap Cloud, il est ainsi possible d’avoir l’équivalent d’une vraie baie NetApp avec tous ses services (snapshots, réplication synchrone et asynchrone, haute disponibilité) mais dans le cloud.
La généralisation des approches Software Defined Storage, permet également aux entreprises utilisatrices de ces technologies de les étendre au cloud. Des systèmes de fichiers distribués comme Dell EMC Scale IO ou Elastifile, pour n’en citer que deux, peuvent être déployés en mode hybride et servir de socle de stockage à une infrastructure distribuée entre des datacenters privés et des infrastructures de cloud public.
Au-delà du « Lift and Shift »
Dans certains cas, il peut être intéressant dès la phase de migration d’aller au-delà du simple « Lift and Shift ».
Pour les bases de données, par exemple, il peut être intéressant de passer d’un modèle de base de données traditionnel, ou il faut provisionner le stockage, les VM et les instances de bases de données (avec l’impact que cela peut avoir en matière de licences logicielles) à un modèle de type Database as a Service.
Ce modèle est par exemple encouragé par Oracle pour son SGBD. Il l’est aussi chez AWS et chez Microsoft. De son côté, Google propose son service CloudSQL pour la bascule d’environnement de bases de données open source comme MySQL ou PostGreSQL. Il met aussi en avant ses services maison Google Spanner (base de données SQL massivement distribuée) et Google BigTable (base NoSQL distribuée) comme des alternatives aux bases équivalentes sur site.
L’avantage d’une telle approche est que l’entreprise n’a plus à gérer l’infrastructure de stockage sous-jacente à la base et qu’elle est assurée que la performance évoluera en fonction de ses besoins (dans les limites, bien sûr, des capacités du service managé de base de données).
La migration vers des services managés de type cloud peut aussi être intéressante pour les entreprises opérant des clusters Hadoop. La plupart des fournisseurs de cloud public offrent en effet un service Hadoop/Spark managé.
Enfin il existe aujourd’hui un large écosystème d’outils qui permet de faciliter la migration des applications et de leurs données vers le cloud. On peut par exemple citer les fournisseurs d’outils de réplication et de reprise après sinistre comme Double Take, Zerto ou Cloud Endure, ou des acteurs de la sauvegarde et de la gestion de données comme Veeam ou Rubrik.
Autant de solutions qui peuvent grandement simplifier la migration progressive des données et, au final, la bascule des applications vers le cloud.