Découverte de l'environnement Windows

Avec les technologies disponibles aujourd'hui, telles que le service de migration d'applications, le transfert de Windows Server, Linux et d'autres systèmes d'exploitation x86 et de leurs charges de travail vers AWS est assez simple. Faire en sorte que ces charges de travail fonctionnent correctement et à grande échelle présente toutefois un autre ensemble de défis. Cette section vise à identifier les considérations relatives à la migration qui peuvent vous permettre de migrer rapidement, en toute sécurité et en douceur vos charges de travail Microsoft.

Évaluer

Bien qu'il soit possible de procéder à des migrations de moindre envergure (telles que celles impliquant 100 serveurs) avec un minimum de planification et d'automatisation, vous ne pouvez pas déplacer 500 serveurs ou plus en utilisant cette méthodologie. Les considérations suivantes sont essentielles à la réussite d'une migration à grande échelle, et vous pouvez utiliser leÉvaluation du niveau de préparation à la migration (MRA)pour identifier les domaines de réflexion sur lesquels vous souhaitez vous concentrer.

Architecture d'entreprise

Plus l'environnement est endetté en matière de technologie, plus il est difficile de migrer. Les organisations qui disposent de programmes d'architecture d'entreprise sains s'efforcent de limiter leur environnement aux versions actuelles et récentes des logiciels et des systèmes (souvent appelées versions N et N -1 des versions majeures). Cela permet non seulement de réduire le nombre de scénarios à prendre en compte, mais également de tirer parti des avancées des nouvelles versions. Par exemple, Windows Server 2012, Windows Server 2008 et les anciennes versions de Windows Server sont de plus en plus difficiles à automatiser dans l'environnement Windows Server que les versions plus récentes. L'octroi de licences est également plus difficile pour les versions plus anciennes et non prises en charge.

Standardisation et gestion de la configuration

La standardisation de l'environnement est un autre facteur à prendre en compte. Les organisations dont les environnements sont construits à la main et entretenus sont considérées comme des animaux de compagnie. Chaque système est unique et les combinaisons de configurations possibles sont bien plus nombreuses que s'ils étaient conçus à l'aide d'images standardisées, d'une infrastructure sous forme de code (IaC) ou de pipelines d'intégration continue et de livraison continue (CI/CD).

Par exemple, il est recommandé de reconstruire un serveur Web classique à l'aide d'IaC ou CI/CD lors de la migration, plutôt que de migrer manuellement le serveur individuel. Il est également recommandé de stocker toutes les données persistantes dans une banque de données telle qu'une base de données, un partage de fichiers ou un référentiel. Si les systèmes ne sont pas reconstruits à l'aide d'IaC ou de CI/CD, ils doivent au moins utiliser des outils de gestion de configuration (tels que Puppet, Chef ou Ansible) pour standardiser les serveurs dont ils disposent.

De bonnes données

La qualité des données est également un facteur clé de la réussite des migrations. Des données précises concernant les serveurs actuels et leurs métadonnées sont essentielles pour l'automatisation et la planification. L'absence de données fiables accroît la difficulté lors de la planification d'une migration. Parmi les bonnes données, citons notamment un inventaire précis des serveurs, des applications sur les serveurs, des logiciels installés sur les serveurs avec leurs versions, le nombre de processeurs, la quantité de mémoire et le nombre de disques. Nous vous recommandons de capturer toutes les données dont les planificateurs de vagues ont besoin pour la planification ou les données que vous prévoyez d'utiliser dans le cadre de l'automatisation du processus de migration.

 Automatisation

L'automatisation est essentielle pour les migrations à grande échelle. Les exemples d'automatisation incluent l'installation de l'agent, la mise à jour des versions logicielles des utilitaires nécessaires à l'automatisation tels que .NET ouPowerShell, en chargeant ou en mettant à jour des logiciels pour AWS tels que l'agent AWS Systems Manager (agent SSM), AmazonCloudWatchagent ou autre logiciel de sauvegarde ou de gestion nécessaire à l'exécution dans AWS.

Planification détaillée

L'élaboration et la gestion d'un plan détaillé sont également essentielles pour les migrations à grande échelle. Vous devez disposer d'un plan bien défini pour migrer 50 serveurs par semaine pendant de nombreuses semaines. Un plan efficace comprend les éléments suivants :

• Utiliserplanification des vaguespour organiser les serveurs en vagues en fonction de vos dépendances et de vos priorités.

• Utiliserplanification hebdomadaire(avant le transfert) pour communiquer avec les équipes chargées des applications et identifier le réseau, le DNS, le pare-feu et les autres détails qui doivent être pris en compte lors du transfert.

• Utilisez de manière détaillée, hour-to-hourplanification(autour de la transition réelle) pour décrire la fenêtre de maintenance de la transition.

• Utilisercritères « go/no-go »pour décrire dans quelles circonstances une application sera considérée comme transférée vers AWS ou doit être renvoyée vers son emplacement source.

• Utiliseractivités de nettoyageen tant qu'activités de suivi qui doivent être menées à bien. Ces activités peuvent avoir lieu en dehors de la fenêtre de maintenance de transition ou après la fin dehypersoin. Les activités de nettoyage incluent la vérification des sauvegardes et de divers agents, la suppression de l'agent du service de migration des applications d'un serveur ou la suppression du serveur source et des ressources associées.

Mobiliser

Au cours de la phase de mobilisation, il est important de découvrir le plus grand nombre possible de complexités et de variations de votre organisation afin de pouvoir en tenir compte lors de la planification de la migration. Dans l'idéal, vous pouvez éviter de faire face à de telles complexités et variations pendant la période de maintenance de transition et éviter tout retour en arrière.

Les défis des migrations à grande échelle

Les échecs de migration se produisent lorsqu'une ou plusieurs applications sont transférées vers leur nouvel environnement et que les exigences fonctionnelles ou de performance ne peuvent pas être satisfaites dans le délai de maintenance de la migration. Cela force l'application ou les applications à revenir à leur emplacement d'origine. En outre, toutes les autres applications qui dépendent de cette ou de ces applications doivent également revenir en arrière. Les échecs de migration ont tendance à avoir un impact non seulement sur la vague actuelle mais aussi sur les vagues futures, car les applications doivent être reprogrammées.

Dépendances sensibles à la latence

Les dépendances sensibles à la latence sont l'une des principales raisons de l'échec des migrations. Le fait de ne pas identifier les dépendances sensibles à la latence peut entraîner des problèmes de performances qui se traduisent par des temps de réponse ou des temps de transaction inacceptables. Par exemple, une application déplace généralement sa base de données et ses serveurs d'applications vers le cloud en même temps, car ils communiquent fréquemment entre eux et ont besoin d'un temps de réponse inférieur à la milliseconde dont ils disposent lorsque les deux se trouvent dans le même centre de données. Le fait de déplacer uniquement la base de données vers le cloud est susceptible d'introduire de nombreuses secondes de latence dans ces transactions, ce qui a un impact significatif sur les performances de l'application. Cela s'applique également aux applications qui dépendent fortement les unes des autres et qui doivent se trouver dans le même centre de données pour fonctionner correctement.

Comprendre et gérer les dépendances des applications est donc d'une importance capitale lors de la planification des migrations. Les applications et les services qui dépendent les uns des autres doivent être identifiés afin de pouvoir être migrés ensemble.

Services informatiques partagés

Une fois qu'une charge de travail est dans le cloud, elle a besoin de divers services pour fonctionner et être maintenue correctement et en toute sécurité. Cela inclut une zone d'atterrissage, un réseau et un périmètre de sécurité, l'authentification, l'application de correctifs, des scanners de sécurité, des outils de gestion des services informatiques, des sauvegardes, des hôtes bastions et d'autres ressources. Sans ces services, les charges de travail risquent de ne pas fonctionner correctement et seront obligées de revenir à leur emplacement d'origine.

mises à jour de configuration

Dans la plupart des cas, vous devez apporter plusieurs modifications à la configuration pour qu'une charge de travail fonctionne correctement après son déplacement vers le cloud. Ces modifications de configuration sont souvent associées aux dépendances suivantes de la charge de travail :

• Règles de pare-feu

• Autoriser les listes

• Enregistrements DNS

• Chaînes de connexion

Si vous n'effectuez pas les mises à jour de configuration appropriées, la charge de travail, ses utilisateurs et ses systèmes dépendants risquent de ne pas communiquer entre eux. Il est possible de résoudre ces problèmes pendant la période de panne, mais les modifications apportées à ce stade peuvent prendre du temps ou nécessiter des enregistrements de modifications qui ne peuvent pas être satisfaits à temps.

Tests fonctionnels des applications

Un autre défi pour les migrations à grande échelle est la nécessité de tester le fonctionnement des applications. Cela est particulièrement important car de nombreuses entreprises s'appuient sur des équipes d'applications pour identifier les dépendances sensibles à la latence, les services informatiques partagés ou les mises à jour de configuration nécessaires. Idéalement, une équipe chargée des applications fournit un plan de test écrit ou automatisé qu'elle peut exécuter pendant la période de maintenance de transition afin de vérifier que son application est pleinement fonctionnelle avec des performances acceptables. Pour minimiser la période de maintenance de transition, le test doit pouvoir être terminé dans les 30 minutes.

Outils pour la découverte des dépendances entre applications

La détermination des dépendances entre les applications est essentielle à la réussite des migrations, à la fois pour détecter les dépendances sensibles à la latence et les éléments de configuration de connectivité. Plusieurs outils sont disponibles sur le marché pour découvrir les dépendances, tels queService de découverte d'applications(agent et outil sans agent) etCloudamize(outil basé sur un agent).

Lorsque vous choisissez un outil de découverte des dépendances entre applications, prenez en compte les points suivants :

• Durée— Nous vous recommandons d'exécuter les outils de découverte suffisamment longtemps pour capturer les événements spécifiques à l'application, tels que les pics connus, les fins de mois et d'autres événements. Le minimum recommandé est de 30 jours.

• Actif (à base d'agents)— Les outils de découverte active des dépendances sont souvent intégrés au noyau du système d'exploitation et capturent toutes les transactions. Toutefois, il s'agit généralement de la méthode la plus coûteuse et la plus longue.

• Passif (sans agent)— Les outils de découverte des dépendances passives sont beaucoup moins coûteux et plus rapides à mettre en œuvre, mais risquent de manquer certaines connexions moins utilisées.

• Connaissances institutionnelles— Bien que les outils de découverte d'applications fournissent des informations plus détaillées et plus précises, la plupart des entreprises s'appuient sur leurs équipes chargées des applications et leurs connaissances institutionnelles pour découvrir les dépendances entre les applications. Les équipes chargées des applications connaissent bien souvent les dépendances sensibles à la latence, mais il n'est pas rare qu'elles oublient certains détails tels que les paramètres de configuration de la connectivité, les règles de pare-feu ou les exigences d'un partenaire en matière de listes d'autorisations. Vous pouvez utiliser les connaissances institutionnelles pour améliorer la découverte des dépendances entre applications, mais nous vous recommandons également de prendre en compte et d'atténuer les risques encourus. Par exemple, il existe un risque de perte d'éléments de configuration de connectivité ou de dépendances sensibles à la latence si vous vous fiez uniquement aux connaissances de vos équipes applicatives. Cela pourrait entraîner des pannes ou des échecs de migration. Pour atténuer ce risque, nous vous recommandons de réaliser des tests fonctionnels détaillés des applications.