La publication d'aujourd'hui est la transcription d'un entretien entre Siddharth Deekshit, responsable de programmes au service ingénierie Microsoft Azure Site Recovery, et Quentin Drion, directeur informatique de l'infrastructure et des opérations chez MSC. MSC est une entreprise internationale de transport et de logistique, et cette conversation porte sur son parcours d'adoption d'Azure Site Recovery (ASR). Pour en savoir plus sur la résilience dans Azure, consultez ce livre blanc.

Tout d'abord, j'aimerais savoir où en est MSC dans son parcours de transformation (consolidation sur Azure comprise). Pouvez-vous nous expliquer en quoi Azure est utile à votre activité ?

MSC est une compagnie maritime qui transporte des conteneurs dans le monde entier. Au fil des ans, nous avions développé nos propres logiciels pour gérer notre cœur de métier. Nous disposions de différents logiciels locaux pour petites, moyennes et grandes entités. Nous avions donc un grand nombre de ressources locales à gérer pour prendre en charge toutes ces applications métier. Il y a quelques années, nous avons décidé de regrouper toutes ces charges de travail métier au sein d'Azure, quelle que soit la taille de l'entité. Lors de la migration, nous désactivons nos systèmes locaux, puis nous commençons à utiliser le logiciel hébergé dans Azure et nous le fournissons sous forme de service à nos filiales. Une équipe informatique interne centralise la gestion de cette nouvelle conception.

C'est fantastique. La consolidation est l'un des gros avantages d'Azure. En dehors de cela, quels sont les autres avantages d'une migration vers Azure, selon vous ?

Pour nous, l'automatisation est un énorme progrès. En termes d'API, les capacités qu'offre Azure dans les domaines de l'intégration et de l'automatisation nous permettent de déployer des environnements en quelques heures, là où il fallait auparavant beaucoup plus de temps puisque nous devions commander le matériel, l'installer, puis le configurer. Désormais, nous n'avons plus à nous soucier de l'installation, du support matériel et des garanties. L'environnement est entièrement virtualisé et nous pouvons continuer à fournir le même niveau de RPO (objectif de point de récupération), de RTO (objectif de temps de récupération) et de sécurité à l'ensemble de nos entités du monde entier.

À propos de RTO et RPO, penchons-nous sur Site Recovery. Pouvez-vous me dire comment était la vie avant Site Recovery ?

En fait, lorsque nous avons commencé à migrer nos charges de travail, nous avions une approche beaucoup plus traditionnelle, avec les charges de travail de production principales dans une région Azure et une infrastructure complète de récupération d'urgence dans une autre. C'est donc avec une approche traditionnelle basée sur des centres de données locaux que nous avons abordé la récupération d'urgence (DR) sur Azure, mais nous avons ensuite pris le temps d'étudier ce que Site Recovery pouvait nous fournir. Nous avons réalisé des tests, puis décidé de modifier l'implémentation que nous avions adoptée deux ou trois ans plus tôt en basculant vers Site Recovery. Dans la mesure où nous n'avions plus besoin d'exécuter nos machines virtuelles DR Azure dans une autre région, nos coûts ont énormément baissé. La gestion est également plus facile. Pour les charges de travail traditionnelles, nous bénéficions de meilleurs RPO et RTO qu'avec notre approche précédente. Nous avons donc constaté de gros avantages à tous les niveaux.

Excellente nouvelle. Sur quoi étiez-vous le plus sceptique quant à l'utilisation de Site Recovery ? Vous avez indiqué que votre équipe avait effectué des tests, alors qu'est-ce qui vous a convaincu que Site Recovery était le bon choix ?

Les tests que nous avons effectués ont vraiment été déterminants. Auparavant, beaucoup d'opérations manuelles étaient nécessaires pour basculer vers la région DR, et vérifier que les paramètres DNS et autres paramètres réseau étaient appropriés. Les contraintes étaient très nombreuses. Lorsque nous avons testé Site Recovery, les résultats nous ont paru magiques comparés à l'ancienne méthode manuelle. Le fait qu'aucune intervention majeure de notre part ne soit nécessaire en cas de défaillance de notre région primaire nous a semblé incroyable. Nos applications pouvaient redémarrer dans la région DR et il nous suffisait de gérer la couche supérieure de l'application pour veiller à ce qu'elle démarre correctement. En ce qui concerne le redémarrage des applications, nous étions un peu sur nos gardes, non pas à cause des machines virtuelles, car nous étions convaincus que Site Recovery fonctionnerait, mais à cause de notre moteur de base de données. La fiabilité de Site Recovery nous a beaucoup impressionnés. Toutes nos équipes sont très satisfaites de la solution et sont conscientes de la valeur ajoutée qu'offre le passage à ce type de technologie pour elles en tant qu'équipes opérationnelles, mais aussi pour nous en tant qu'équipes de management grâce aux économies que permet de réaliser la réduction du nombre de machines virtuelles inutilisées.

Pouvez-vous m'en dire un peu plus sur votre expérience en matière d'intégration de Site Recovery ?

Je crois qu'à l'époque, six ou sept applications étaient développées dans Azure en interne. Nous avons choisi d'effectuer un test avec l'une de ces applications. Et il s'est révélé concluant. Nous avons ensuite étendu les tests à un autre ensemble d'applications qui étaient en production. Là encore, aucun problème majeur n'a été détecté. Le seul inconvénient concernait les disques de grande taille. Au départ, certains d'entre eux n'étaient pas pris en charge. Mais ce problème a été vite résolu, et depuis tout va bien. Nos tests ayant été concluants, nous nous sommes préparés à basculer toutes les applications de la plateforme afin qu'elles utilisent Site Recovery pour la récupération d'urgence.

Pouvez-vous me donner une idée des charges de travail que vous exécutez aujourd'hui sur vos machines virtuelles Azure ? Combien de personnes utilisent les applications exécutées sur ces machines virtuelles au quotidien ?

Il s'agit des applications métier de base. Il y a, bien sûr, l'infrastructure principale en dessous, mais ce que nous servons, ce sont des applications métier que nous avons développées en interne, présentées au frontend Citrix dans Azure. Ces applications effectuent des réservations de conteneurs, des inscriptions de clients, etc. Différentes charges de travail sont associées au processus complet de transport. Certaines applications sont utilisées par plus de 5 000 personnes, et il s'agit souvent de leur application principale au quotidien.

Eh bien, cela fait beaucoup d'utilisateurs, et je suis heureux que vous fassiez confiance à Site Recovery pour la récupération d'urgence. Pouvez-vous m'en dire plus sur l'architecture de ces charges de travail ?

Il s'agit, pour la plupart, de charges de travail basées sur Windows. Le logiciel le plus utilisé dans le monde est une application à 3 niveaux. Nous avons une base de données sur SQL, un serveur de niveau intermédiaire, un serveur d'applications, ainsi que quelques serveurs web frontaux. Le nouveau logiciel que nous venons de développer, quant à lui, est basé sur des microservices. Nous avons également quelques serveurs Linux à usage spécifique.

Dites-m'en plus sur votre expérience Linux.

Site Recovery fonctionne à merveille avec les charges de travail Linux. Nous avons rencontré quelques erreurs au début, mais elles venaient toutes de nous. Nous voulions utiliser un produit de Red Hat appelé Satellite pour les mises à jour. Or, pour cela, le mode de gestion des machines virtuelles devait être changé, ce qui n'était pas possible. Celui-ci doit en effet être défini au début, sinon c'est trop tard. Mais à part ça, le BYOL (apportez votre propre licence) fonctionne très bien, en particulier avec Site Recovery.

Content d'apprendre que l'expérience a été positive pour vous. Y a-t-il un autre aspect de Site Recovery qui vous a impressionné, ou que dont vous souhaitez faire part à d'autres organisations ?

Oui, la facilité avec laquelle on peut effectuer des tests. Avec l'approche traditionnelle, lorsque vous voulez effectuer un test complet de récupération d'urgence, les préparatifs prennent du temps et nécessitent beaucoup des ressources. Avec Site Recovery, nous avons effectué un test il y a quelques semaines sur l'environnement complet et les préparatifs ont été très simples. Non seulement le basculement vers la région de récupération a été rapide mais la restauration de la charge de travail dans la région primaire s'est également révélée très facile. Par conséquent, ce qui m'impressionne le plus, c'est la facilité d'utilisation de Site Recovery.

Si vous deviez tout recommencer, que changeriez-vous dans votre parcours d'adoption de Site Recovery ?

Je commencerais à l'utiliser plus tôt. Si nous n'avions pas adopté l'approche active/passive traditionnelle, je pense que nous aurions fait gagner du temps et de l'argent à l'entreprise. D'un autre côté, cela nous a permis d'entamer notre parcours en toute confiance. Mis à part ça, je pense que nous n'aurions pas changé grand-chose. Ce que nous aimerions faire maintenant, c'est commencer à examiner les services Azure Site Recovery pour pouvoir répliquer les charges de travail exécutées sur des machines virtuelles locales dans Hyper-V. Pour les applications qui n'ont pas encore été migrées vers Azure, nous aimerions au moins assurer une récupération d'urgence appropriée. Nous aimerions également répliquer certaines des machines virtuelles VMware qui nous restent dans le cadre de notre parcours de migration vers Hyper-V. Voilà à quoi nous réfléchissons actuellement.

Avez-vous des conseils à donner aux clients actuels ou potentiels de Site Recovery ?

Je leur conseillerais de commencer plus tôt et, si nécessaire, plus petit. Commencez à utiliser Site Recovery avec l'application de votre choix, même petite. Cela vous aidera à prendre conscience de sa valeur ajoutée, et à convaincre les équipes opérationnelles qu'elles peuvent faire confiance aux services de Site Recovery au lieu d'essayer de tout faire elles-mêmes.

Voilà un excellent conseil. Je n'ai plus de questions, Quentin. Merci d'avoir partagé votre expérience avec nous.

En savoir plus sur la résilience avec Azure