Découverte de l'environnement Windows

Avec les technologies disponibles aujourd'hui, telles que le transfert de Windows Server AWS Application Migration Service, Linux et d'autres systèmes d'exploitation x86 et de leurs charges de travail vers Windows Server, Linux et leurs charges de travail, est assez simple. AWS Faire en sorte que ces charges de travail fonctionnent correctement et le faire à grande échelle présente toutefois un ensemble de défis différents. 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.

Évaluation

Bien que vous puissiez « forcer » des migrations plus petites (comme 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 l'évaluation de l'état de préparation à la migration (MRA) pour identifier les domaines 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. Organisations dotées 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 configuration

La standardisation de l'environnement est un autre facteur à prendre en compte. 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 et de livraison continues (CI/CD).

Par exemple, il est recommandé de reconstruire un serveur Web classique à l'aide d'iAC ou CI/CD when migrating, as opposed to manually migrating the individual server. It's also a best practice to store all persistent data in a datastore such as a database, file share, or repository. If systems aren't rebuilt using IaC or CI/CD d'utiliser au moins des outils de gestion de configuration (tels que Puppet, Chef ou Ansible) pour standardiser les serveurs dont ils disposent.

Bonnes données

La qualité des données est également un facteur clé pour des migrations réussies. Des données précises concernant les serveurs actuels et leurs métadonnées sont essentielles pour l'automatisation et la planification. Le manque de données fiables accroît la difficulté lors de la planification d'une migration. Des exemples de données fiables incluent un inventaire précis des serveurs, des applications sur les serveurs, des logiciels présents sur les serveurs avec leurs versions, du nombre CPUs, de la quantité de mémoire et du nombre de disques. Nous vous recommandons de capturer toutes les données dont les planificateurs de vagues ont besoin pour la planification ou toutes 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 ou PowerShell le chargement ou la mise à jour de logiciels AWS tels que l' AWS Systems Manager agent (agent SSM), l' CloudWatch agent Amazon ou tout autre logiciel de sauvegarde ou de gestion nécessaire à l'exécution. 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 inclut les éléments suivants :

• Utilisez la planification des vagues pour organiser les serveurs en vagues en fonction de vos dépendances et de vos priorités.

• Utilisez la planification hebdomadaire (avant le passage) 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 une hour-to-hourplanification détaillée (autour du passage réel) pour décrire la fenêtre de maintenance du transfert.

• Utilisez les critères go/no-go pour décrire dans quelles circonstances une application sera considérée comme redirigée vers son emplacement source AWS ou devra être renvoyée à son emplacement source.

• Utilisez les activités de nettoyage comme activités de suivi qui doivent être effectuées. Ces activités peuvent avoir lieu en dehors de la période de maintenance intermédiaire ou après la fin de l'hypercare. Les activités de nettoyage incluent la vérification des sauvegardes et de divers agents, la suppression de l'agent Application Migration Service d'un serveur ou la suppression du serveur source et des ressources associées.

Mobilisation

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 intermédiaire et éviter tout échec.

Les défis des migrations à grande échelle

Les échecs de migration se produisent lorsqu'une ou plusieurs applications ont été transférées dans leurs nouveaux environnements et que les exigences fonctionnelles ou de performance ne peuvent pas être satisfaites pendant la période 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 faire marche arrière. Les migrations échouées 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 délais 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 aura un impact significatif sur les performances de l'application. Cela vaut également pour les 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 traiter 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 d'une variété de services pour fonctionner et être entretenue correctement et en toute sécurité. Cela inclut une zone d'atterrissage, un réseau et un périmètre de sécurité, des authentifications, des 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 de configuration pour qu'une charge de travail fonctionne correctement après son transfert 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

La nécessité de tester le fonctionnement des applications constitue un autre défi pour les migrations à grande échelle. Cela est particulièrement important car de nombreuses entreprises s'appuient sur les équipes chargées des 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 d'application fournit un plan de test écrit ou automatisé qu'elle peut exécuter pendant la période de maintenance intermédiaire afin de valider que son application est entièrement fonctionnelle avec des performances acceptables. Pour réduire au minimum la période de maintenance de la transition, le test devrait pouvoir être effectué dans les 30 minutes.

Outils pour la découverte des dépendances des 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 que AWS Application Discovery Service(outil agent et outil sans agent) et Cloudamize (outil basé sur un agent).

Lorsque vous choisissez un outil pour la découverte des dépendances des applications, tenez compte des 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 événements de fin de mois et autres. Le minimum recommandé est de 30 jours.

• Actif (basé sur un agent) : les outils de découverte des dépendances actives sont souvent intégrés au noyau du système d'exploitation et capturent toutes les transactions. Cependant, il s'agit généralement de la méthode la plus coûteuse et la plus longue.

• Passif (sans agent) : les outils passifs de découverte des dépendances sont beaucoup moins chers et plus rapides à mettre en œuvre, mais ils 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 des applications. Les équipes chargées des applications connaissent 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 liste d'autorisation. Vous pouvez utiliser les connaissances institutionnelles pour améliorer la découverte des dépendances de vos applications, mais nous vous recommandons également de prendre en compte et d'atténuer les risques encourus. Par exemple, vous risquez de manquer des éléments de configuration de connectivité ou de créer des dépendances sensibles à la latence si vous ne comptez que sur les connaissances de vos équipes chargées des applications. Cela peut 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.