Concevoir une architecture de charge de travail avant la migration
Cet article décrit le processus et les considérations relatives à la conception l’état de migration prévu d’une charge de travail dans le cloud. L’article passe en revue les activités qui font partie de la définition de l’architecture d’une charge de travail au cours d’une itération.
L’article sur la rationalisation incrémentielle indique que certaines hypothèses architecturales font partie de toute transformation métier qui inclut une migration. Cet article clarifie les hypothèses typiques. Il indique également quelques obstacles à éviter évités et identifie les opportunités d’accélérer la valeur métier en mettant à l’épreuve ces hypothèses architecturales. Ce modèle incrémentiel de conception de l’architecture permet aux équipes d’avancer plus vite et d’obtenir des résultats opérationnels plus tôt.
Fonder la conception de l’architecture sur des hypothèses communes
Les hypothèses suivantes sont typiques pour tout effort de migration :
- Supposons une charge de travail d’infrastructure as a service (IaaS). La migration des charges de travail implique essentiellement le déplacement des serveurs d’un centre de données physique vers un centre de donnes cloud via une migration IaaS. Ce processus nécessite généralement un redéveloppement ou une reconfiguration minimes. Cette approche est une migration de type lift-and-shift.
- Gardez l’architecture cohérente. Modifier l’architecture principale pendant une migration augmente considérablement la complexité. Le débogage d’un système modifié sur une nouvelle plateforme introduit de nombreuses variables qui peuvent être difficiles à isoler. Les charges de travail ne doivent subir que des modifications mineures pendant la migration, et les modifications doivent être minutieusement testées.
- Planifiez le redimensionnement des ressources. Supposons que peu de ressources sur site utilisent pleinement une ressource. Avant ou pendant la migration, les ressources sont redimensionnées pour s’adapter au mieux aux besoins réels de l’utilisation. Les outils tels qu’Azure Migrate et Moderniser fournissent un dimensionnement basé sur l’utilisation réelle.
- Capturez les exigences de continuité d’activité et reprise d’activité (BCDR) Si vous avez déjà négocié avec l’entreprise un contrat de niveau de service (contrat SLA) pour les charges de travail, continuez à l’utiliser après la migration vers Azure. Si un contrat SLA n’est pas encore établi, définissez-en un avant de concevoir la charge de travail dans le cloud afin de vous assurer que votre conception est appropriée.
- Planifiez les temps d’arrêt de la migration. Tout comme le non-respect des SLA, les temps d’arrêt qui surviennent lorsque vous promouvez une charge de travail en production peuvent avoir un effet négatif sur l’entreprise. Parfois, les solutions qui doivent être migrées avec un temps d’arrêt minimal nécessitent des changements d’architecture. Supposons qu’une compréhension générale des exigences de temps d’arrêt est établie avant la planification des publications.
- Définissez les modèles de trafic des utilisateurs et des applications. Les solutions existantes peuvent dépendre de modèles de routage réseau et de solutions existants. Identifiez les ressources dont vous avez besoin pour prendre en charge l’utilisation actuelle du réseau.
- Prévoyez d’éviter les conflits de réseaux. Quand vous consolidez des centres de données en un seul fournisseur de cloud, vous êtes susceptible de créer des conflits au niveau du DNS (Domain Name System) ou d’autres structures de mise en réseau. Pendant la migration, il est important de concevoir pour éviter ces conflits afin d’éviter les interruptions des systèmes de production hébergés dans le cloud.
- Planifiez les tables de routage. Assurez-vous que votre projet inclut un plan de modification des tables de routage si vous consolidez des réseaux ou des centres de données. Tenez compte des exigences de routage entre les centres de données.
Concevoir l’architecture pour une zone d’atterrissage
Dans la phase de préparation du Cloud Adoption Framework, votre organisation a déployé des services de plateforme partagée dans le cadre de l’adoption de zones d’atterrissage Azure. Dans Préparer votre zone d’atterrissage pour la migration, vous avez préparé la zone d’atterrissage pour recevoir des charges de travail migrées.
En fonction de cette planification, vous pouvez supposer que les composants de migration suivants sont en place :
- La connectivité hybride connecte vos réseaux Azure à vos réseaux sur site.
- Les appliances de sécurité réseau telles que Pare-feu Azure gèrent l’inspection du trafic en dehors de votre charge de travail.
- Les stratégies Azure visant à appliquer les pratiques de gouvernance telles que les exigences de journalisation, les régions autorisées, les services non autorisés et d’autres contrôles sont actives.
- Un espace de travail Journaux Azure Monitor pour la journalisation partagée est configuré dans Azure Monitor.
- Des ressources d’identité partagées sont établies pour prendre en charge les serveurs joints à un domaine ou pour répondre à d’autres besoins en matière d’identité.
Si ces éléments essentiels de la migration ne sont pas établis, votre organisation doit immédiatement revoir la phase de préparation pour répondre à ces besoins. Sans ces composants, votre migration connaîtra probablement des retards et des revers et sera moins réussie.
La charge de travail que vous concevez a un abonnement qui lui est attribué, idéalement par le biais d’un processus de distributeur d’abonnements. L’abonnement peut contenir une ou plusieurs charges de travail en fonction de la manière dont votre organisation a terminé son organisation de ressources pour les charges de travail. Si vous migrez une charge de travail comportant de nombreux environnements d’application, vous pouvez même avoir plusieurs abonnements en fonction des conseils relatifs aux environnements d’application.
Concevoir une architecture réseau de charge de travail
Prévoyez de déployer des ressources spécifiques à une application dans le cadre d’un abonnement spécifique et de concevoir un réseau virtuel dédié à la charge de travail. Pour plus d’informations, consultez les conseils pour la conception de votre architecture réseau. Vous devez particulièrement vous concentrer sur la segmentation des réseaux virtuels.
Votre réseau a probablement besoin de ressources telles que des équilibreurs de charge et d’autres ressources de livraison d’applications. Vous pouvez utiliser le guide d’architecture multiniveau pour planifier ces ressources dans Azure.
Concevoir des dépendances de charge de travail
Vos outils d’évaluation de la migration doivent vous permettre d’effectuer une analyse des dépendances, comme l’analyse des dépendances dans Azure Migrate et Moderniser. L’outil vous aide à identifier les interdépendances entre les serveurs.
Outre la planification de l’architecture pour la charge de travail elle-même, il peut être nécessaire de prendre en compte les dépendances entre les charges de travail. Par exemple, certaines charges de travail peuvent nécessiter une communication fréquente. Si c’est le cas, la planification de vos vagues de migration et de vos dépendances pour tenir compte de cette exigence permet de réussir votre migration.
Vous pouvez utiliser les conseils du Centre des architectures Azure, par exemple pour la mise en réseau spoke-to-spoke, pour concevoir le fonctionnement des charges de travail interconnectées après la migration.
Préparer l’adoption de l’informatique confidentielle
Un sous-ensemble de vos charges de travail avec des exigences de souveraineté peut conduire à l’utilisation de l’informatique confidentielle. Dans le cadre d’un déploiement d’une zone d’atterrissage souverain, des groupes de gestion pour l’informatique confidentielle sont créés.
Dans un contexte de souveraineté, l’utilisation de l’informatique confidentielle nécessite Azure Key Vault et les clés gérées par le client en tant que service de prise en charge. Pour plus d’informations, consultez chiffrement à l’aide de clés gérées par le client dans Microsoft Cloud for Sovereignty.
Mettre à jour votre estimation initiale du cloud
Lorsque vous terminez la conception de votre architecture, revoyez votre estimation cloud pour vous assurer que vous êtes toujours dans le budget prévu. Lorsque vous ajoutez des services de prise en charge tels que des équilibreurs de charge ou des sauvegardes, les coûts peuvent changer. Bien que vous puissiez utiliser des outils tels que des cas métier dans Azure Migrate et Moderniser pour effectuer des exercices détaillés de gestion des coûts, vous devez régulièrement revoir vos estimations lorsque vous ajustez votre conception d’architecture.
Si vous êtes familiarisé avec les processus traditionnels d’approvisionnement en informatique, l’estimation de ressources dans le cloud peut vous paraître étrangère. Lorsque vous adoptez les technologies cloud, l’acquisition passe d’un modèle de dépenses d’investissement rigide et structuré à un modèle de dépenses au fonctionnement fluide. La planification d’une migration vers le cloud est souvent la première fois qu’une organisation ou une équipe informatique est confrontée à ce changement.
Dans le modèle traditionnel de dépenses d’investissement, une équipe informatique tente de combiner le pouvoir d’achat pour de multiples charges de travail dans le cadre de divers programmes. Cette approche centralise un ensemble de ressources informatiques partagées qui peuvent prendre en charge chacune de ces solutions. Dans le modèle de dépenses d’exploitation du cloud, les coûts peuvent être directement attribués aux besoins des charges de travail individuelles, des équipes ou des unités commerciales. Elle donne à une organisation une attribution plus directe des coûts aux clients internes et aux objectifs stratégiques qu’ils prennent en charge. Cette approche plus dynamique de la gestion financière est souvent appelée opérations financières (FinOps). Bien que FinOps ne soit pas une considération spécifique à Azure, il peut être utile d’avoir une compréhension étendue de FinOps. Pour plus d’informations, consultez Qu’est-ce que FinOps ?.
Lorsque vous concevez votre architecture de charge de travail pour la migration, vous pouvez utiliser la calculette de tarification avec vos informations d’évaluation pour comprendre le prix de l’ensemble de la charge de travail.
De plus, après la migration de votre charge de travail, vous devez continuer à travailler pour optimiser les coûts de la charge de travail. Pour plus d’informations sur la manière dont les organisations peuvent développer leurs compétences en gestion des coûts, consultez Améliorer la discipline de la gestion des coûts.
Savoir quand changer votre architecture
Les migrations ont tendance à se concentrer sur la maintenance d’une architecture existante et sa transition vers votre plateforme cloud. Cependant, il peut arriver que vous deviez réorganiser votre charge de travail, même dans le cadre d’une migration. Cette liste fournit des exemples de cas où vous devrez peut-être apporter des modifications architecturales avant de procéder à la migration :
- Paiement de la dette technique. Certaines charges de travail vieillissantes présentent une dette technique importante. La dette technique peut entraîner des défis à long terme en augmentant les coûts d’hébergement avec n’importe quel fournisseur cloud. Lorsque la dette technique augmente de façon non naturelle les coûts d’hébergement, il convient d’évaluer d’autres architectures.
- Amélioration de la fiabilité. Les lignes de base d’opérations standard offrent un degré de fiabilité et de récupération dans le cloud. Certaines équipes de charge de travail peuvent demander des contrats SLA plus élevés, ce qui peut entraîner des modifications architecturales.
- Charges de travail à coût élevé. Pendant la migration, vous devez optimiser toutes les ressources pour aligner le dimensionnement avec l’utilisation réelle. Certaines charges de travail peuvent nécessiter des modifications architecturales pour répondre à des problèmes de coûts spécifiques.
- Exigences de performances. Lorsque les performances de la charge de travail ont un impact direct sur les activités, des considérations architecturales supplémentaires peuvent être nécessaires.
- Sécuriser les applications. Les exigences de sécurité ont tendance à être implémentées de manière centralisée et sont généralement appliquées à toutes les charges de travail du portefeuille. Certaines charges de travail peuvent avoir des exigences de sécurité spécifiques qui peuvent entraîner des modifications architecturales.
Chacun des critères est un indicateur d’un obstacle potentiel à la migration. Dans la plupart des cas, vous pouvez répondre à ce critère après la migration de la charge de travail en redimensionnant les serveurs, en ajoutant de nouveaux serveurs ou en apportant d’autres modifications. Toutefois, si l’un de ces critères est requis avant de migrer une charge de travail, supprimez la charge de travail de la migration et évaluez-la individuellement.
Azure Well-Architected Framework et Azure Well-Architected Review peuvent guider les conversations avec le propriétaire technique d’une charge de travail spécifique afin de l’aide à envisager d’autres options de déploiement de la charge de travail.
La charge de travail est ensuite classée comme un effort de réarchitecture ou de modernisation dans votre plan d’adoption du cloud. En raison du temps supplémentaire nécessaire à la réarchitecture d’une charge de travail, il convient de considérer ces voies alternatives d’adoption de la charge de travail comme distinctes du processus de migration.
Liste de contrôle d’architecture
Vous pouvez utiliser la liste de contrôle suivante pour vous assurer que vous tenez compte des considérations architecturales essentielles :
- Vérifiez que votre architecture répond aux contrats SLA pour la disponibilité, la récupération d’urgence et la récupération de données.
- Vérifiez que vous avez appliqué des pratiques de segmentation réseau à la conception de votre réseau.
- Vérifiez que vous avez planifié la surveillance et la capture des journaux.
- Vérifiez que vos ordinateurs virtuels sont correctement dimensionnés pour le temps de calcul réel dont vous avez besoin.
- Confirmez que le dimensionnement de vos disques est adapté à la taille et aux performances dont vous avez besoin.
- Vérifiez que vous avez prévu les services d’équilibrage de charge s’ils sont nécessaires. Les services peuvent inclure des instances Azure Load Balancer, Azure Application Gateway, Azure Front Door ou Azure Traffic Manager.
- Vérifiez que vous avez prévu des exigences en matière de souveraineté et d’informatique confidentielle, le cas échéant.