Préparer votre environnement pour un scénario hybride et multicloud

Article
05/07/2024

La méthodologie de préparation Cloud Adoption Framework guide les clients au fur et à mesure qu’ils préparent leur environnement pour l’adoption du cloud. La méthodologie comprend les accélérateurs techniques, comme les zones d’atterrissage Azure, qui constituent les éléments de base de tout environnement d’adoption du cloud.

Ce guide peut vous aider à choisir la bonne zone d'atterrissage à déployer pour votre organisation.

Zones d’atterrissage hybrides et multiclouds

Les zones d’atterrissage Azure représentent la sortie d’un environnement Azure multiabonnement qui prend en compte les aspects suivants :

Scale
Gouvernance de la sécurité
Mise en réseau
Identité
la gestion des coûts ;
Supervision

Les considérations relatives à votre environnement peuvent être légèrement différentes lorsque vous préparez un déploiement hybride et multicloud. Dans le cadre d’un déploiement hybride et multicloud, un environnement cohérent implique que vous vous penchiez sur ce qui suit :

Topologie et connectivité du réseau
Contrôles de processus opérationnels unifiés pour les opérations, la gouvernance, la sécurité et la conformité
Disciplines d’automatisation unifiées et cohérentes, expérience de développement et pratiques DevOps dans des environnements hétérogènes

Azure Arc permet d’obtenir des architectures hybrides et multiclouds et contient un ensemble de technologies. Chaque architecture qu’il active inclut toutes les zones de conception critiques et considérations dont vous avez besoin pour créer un déploiement réussi.

Évaluer votre combinaison de clouds

Le choix d’un environnement hybride et multicloud implique non pas une mais plusieurs décisions. Avant de configurer votre environnement cloud, identifiez la manière dont celui-ci prendra en charge votre mix spécifique de choix d’hébergement dans le cloud. Le diagramme suivant présente quelques exemples de combinaisons cloud courantes :

Dans ce diagramme, chaque point bleu foncé est une charge de travail, et chaque cercle bleu clair un processus métier pris en charge par un environnement distinct.

Chaque combinaison de cloud requiert une configuration d’environnement Azure très différente. Vous pouvez le voir avec nos trois clients de référence :

Client principalement hybride : la plupart des charges de travail restent locales, souvent dans un mix de modèles traditionnels, hybrides et portables d’hébergement des ressources. Peu de charges de travail spécifiques sont déployées en périphérie, sur Azure ou auprès d’autres fournisseurs de Cloud.
- Fabrikam est un client principalement hybride qui a lourdement investi dans des centres de données vieillissants. Ses priorités sont le coût et la gouvernance. Les priorités informatiques héritées et l’infrastructure technologique vieillissante ont entravé l’innovation de Fabrikam, ce qui a conduit à une adoption précoce du cloud.
Client axé sur Azure : la plupart des charges de travail sont déplacées vers Azure et seules quelques-unes sont conservées localement. Les décisions stratégiques ont conduit à quelques charges de travail vivant en périphérie ou dans des environnements multiclouds.
- Contoso est un client axé sur Azure. Comme Fabrikam, il a terminé sa première vague de transformation numérique, acquis quelques entreprises et ajouté des clients dans des secteurs réglementés. Sa priorité reste l’innovation, mais avec son environnement multicloud, elle est axée sur la gestion des opérations. Il a besoin d’opérations efficaces et évolutives pour poursuivre sa stratégie d’acquisition.
Client axé multicloud : La plupart des charges de travail sont hébergées sur un autre cloud public, comme Google Cloud Platform (GCP) ou Amazon Web Services (AWS). Les décisions stratégiques ont conduit à quelques charges de travail résidant dans Azure ou en périphérie. Les clients passent fréquemment d’une combinaison hybride à une combinaison Azure à mesure que leur stratégie cloud mûrit, mais nous prenons également en charge les clients qui privilégient les combinaisons hybrides ou multiclouds. Azure joue un rôle dans chaque type de combinaison.
- Tailwind Traders est un client axé multicloud. Comme Contoso, il a été déplacé vers le cloud, mais n’a pas utilisé Azure pour le faire. Il dispose de quelques ressources de centre de données local et d’appareils périphériques. Tailwind Traders a adopté précocement d’autres cloud en phase de démarrage, et la croissance est sa priorité. Exigences de vente au détail des clients et nécessité d’améliorer les opérations permettant une mise à l’échelle efficace de la croissance hybride et multicloud.

Quelques considérations sont essentielles pour préparer n’importe quel environnement cloud pour l’hybride et le multicloud. Les réponses aux questions suivantes guident votre stratégie hybride et multicloud pour les applications et les données. Identifiez clairement la combinaison cloud requise, puis réfléchissez à la configuration optimale de vos environnements :

Quelle combinaison d’environnements hybrides, en périphérie et multiclouds avez-vous en charge aujourd’hui ?
Quelle combinaison correspond le mieux à votre stratégie pour l’avenir ?
Souhaitez-vous exploiter chaque plateforme indépendamment ou selon une approche d’unification des opérations et de volet unique ?

Vue d’ensemble d’Azure Arc

Vous pouvez vouloir simplifier les environnements complexes et distribués dans des configurations locales, de périphérie et multicloud. Azure Arc vous permet de déployer des services Azure n’importe où et étend la gestion Azure à n’importe quelle infrastructure.

Organiser et régir à travers les environnements : contrôlez des bases de données, des clusters Kubernetes et des serveurs répartis dans des environnements locaux, multiclouds et à la périphérie à l’aide d’une organisation et d’une gouvernance centrales à partir d’un emplacement unique.
Gérer les applications Kubernetes à grande échelle : utilisez les techniques DevOps pour déployer et gérer des applications Kubernetes dans des environnements. Veillez à déployer et configurer des applications de manière cohérente à partir du contrôle de code source.
Exécuter des services Azure n’importe où : bénéficiez d’une mise à jour corrective automatisée, de mises à niveau, d’une sécurité et d’une mise à l’échelle à la demande dans des environnements locaux, multiclouds et à la périphérie pour votre patrimoine de données.
Activez l’accès en libre-service à vos machines virtuelles : utilisez le contrôle d’accès en fonction du rôle Azure (RBAC) pour accorder une capacité en libre-service à vos ressources VMware vSphere et System Center Virtual Machine Manager via Azure. Effectuez des opérations de cycle de vie et de cycle de vie des machines virtuelles à partir de Portail Azure et créez une automatisation à l’aide de modèles, d’API et de kits sdk Azure.

Instantané du client Azure Arc

Les trois clients de référence précédemment mentionnés exécutent des charges de travail sur un matériel différent. Ils exécutent également des charges de travail sur des centres de données locaux et plusieurs fournisseurs de cloud public, et prennent en charge les charges de travail IoT déployées en périphérie. Leurs charges de travail incluent différents services et sont basées sur des serveurs nus, des machines virtuelles, des services PaaS (Platform as a Service) managés et des applications cloud natives basées sur des conteneurs.

Les trois clients comprennent que la nécessité d’avoir des pratiques hybrides et multiclouds établies pour la réussite de l’entreprise. La nécessité de moderniser les charges de travail est de plus en plus cruciale pour la pertinence des trois clients dans leurs domaines respectifs.

Avec Azure Arc comme plan de contrôle hybride et multicloud, ces clients peuvent utiliser les investissements informatiques existants et les pratiques opérationnelles actuelles de manière non distribuée. Pour continuer à utiliser leurs pratiques actuelles, les clients intègrent ces ressources :

Serveurs avec Azure Arc, VMware vSphere avec Azure Arc, ou System Center Virtual Machine Manager avec Azure Arc
Serveurs SQL
Clusters Kubernetes

Ils sont également en mesure de moderniser les charges de travail tout en répondant aux exigences de souveraineté des données à l’aide de services de données, de services d’application et de services Machine Learning avec Azure Arc.

Azure Arc étend les API Azure Resource Manager (ARM) pour vous permettre de représenter n’importe quelle charge de travail en tant que citoyen de première classe dans Azure. Cette extension constitue la base qui vous permet d’implémenter des opérations unifiées, la gestion, la conformité, la sécurité et la gouvernance à grande échelle. Elle est implémentée avec :

Analyse centralisée
Journalisation
Télémétrie
Stratégies
Gestion des correctifs
Suivi des modifications
Gestion des stocks
Détection de menaces
Gestion et audit des vulnérabilités de sécurité

Configurer votre environnement Azure initial

Pour chaque combinaison cloud, vous aurez besoin d’un environnement Azure pour prendre en charge, régir et gérer vos ressources cloud. La méthodologie de préparation du Cloud Adoption Framework propose quelques étapes pour vous aider à préparer votre environnement :

Consultez Qu’est-ce qu’une zone d’atterrissage Azure ?
Examinez chacune des zones de conception de la zone d’atterrissage Azure et évaluez correctement vos exigences techniques.
Comparez vos besoins avec les options d’implémentation de la zone d’atterrissage Azure pour rechercher et implémenter le modèle le plus approprié pour votre configuration.
Découvrez comment faire passer des environnements Azure existants dans l’architecture conceptuelle de la zone d’atterrissage Azure.

Azure Arc comme accélérateur de zone d’atterrissage

Les ressources Azure Arc peuvent faire partie de n’importe quelle application. Voici quelques exemples :

Serveurs avec Azure Arc, VMware vSphere avec Azure Arc, et System Center Virtual Machine Manager avec Azure Arc, qui représentent les ressources informatiques déployées en dehors d’Azure. Les services Azure Arc intégrés, tels que VMware vSphere avec Azure Arc et System Center Virtual Machine Manager avec Azure Arc, projetent les ressources informatiques déployées dans VMware vCenter et System Center Virtual Machine Manager gérés localement dans Azure.
Clusters Kubernetes managés par le client dans un environnement multicloud.
Données, applications et services Machine Learning compatibles avec Azure Arc qui fonctionnent à la périphérie.

Les abonnements de zone d’atterrissage d’application peuvent également contenir des ressources Azure Arc et des ressources Azure régulières.

Comme les ressources Azure Arc se trouvent en dehors d’Azure, vous pouvez les considérer comme une ressource de métadonnées dans la façon dont elles sont représentées dans Azure. Traitez les ressources Azure Arc comme n’importe quelle autre ressource Azure qui peut faire partie de votre zone d’atterrissage. Peu importe s’il s’agit d’une plateforme ou d’une application, elle suit les principes de conception Centrage sur les applications et indépendance de tout archétype.

Exemples courants de ressources Azure Arc dans les zones d’atterrissage Azure

Les exemples suivants montrent comment projeter des ressources Azure Arc en tant que ressources de métadonnées dans les zones d’atterrissage Azure.

Exemple 1 : Projection de contrôleurs de domaine en dehors d’Azure

De nombreux clients possèdent des déploiements Active Directory Domain Services (AD DS) au sein de leurs environnements. Les contrôleurs de domaine constituent un composant critique d’AD DS et de l’architecture globale des clients.

Dans l’architecture conceptuelle de la zone d’atterrissage Azure, il existe un abonnement de zone d’atterrissage d’identité dédié conçu pour héberger des ressources basées sur les identités. Vous pouvez héberger cet abonnement dans Azure à l’aide de machines virtuelles de contrôleur de domaine AD DS. Vous pouvez également le projeter dans Azure via des serveurs avec Azure Arc à partir de n’importe quel autre emplacement.

Exemple 2 : Projection de centres de données locaux dans Azure

La plupart des clients possèdent des centres de données locaux présents dans leurs environnements. L'empreinte de ces centres de données peut varier d'un seul serveur à de vastes environnements virtualisés.

Les clients peuvent traiter leurs centres de données locaux comme des zones d’atterrissage normales et les placer dans des zones d’atterrissage nouvelles ou existantes comme ils le jugent opportun. Il existe différentes approches courantes :

Déplacement des ressources de projet dans des abonnements de zone d’atterrissage dédiés pour les ressources de centre de données locales.
- Dans des environnements plus grands dotés de plusieurs centres de données dans le monde entier, les clients peuvent avoir une zone d’atterrissage par région géopolitique. Ces zones d’atterrissage contiennent également les ressources de cette région pour fournir une séparation logique des centres de données locaux dans Azure.
- Cette approche peut également faciliter le respect les exigences de sécurité, de gouvernance et de conformité pour différents centres de données locaux.
Déplacement des ressources de projet dans des abonnements de zone d’atterrissage distincts en fonction d’autres ressources Azure qui prennent en charge la même application ou le même service.

Exemple 3 : Projection de ressources d’application distantes dans Azure

Les clients peuvent développer des applications sensibles à la latence ou des applications avec des exigences de souveraineté des données. Ces applications peuvent avoir besoin d’héberger les ressources qui font partie de leur application en dehors d’Azure. Les clients souhaitent toujours contrôler, régir, sécuriser et exploiter de manière centralisée toutes les ressources qui forment leur application. Azure Arc permet aux clients d’atteindre cet objectif.

Dans ce scénario, les clients doivent projeter les ressources Azure Arc pour leur application dans le même abonnement de zone d’atterrissage d’application dans lequel ils déploient des ressources Azure. Les clients peuvent ensuite appliquer un ensemble de contrôles à toutes les ressources à partir d’un seul plan de contrôle, quel que soit l’emplacement de ces ressources.

Exemple 4 : Projection de serveurs locaux ayant atteint la fin de la prise en charge dans Azure pour utiliser les correctifs de sécurité étendus fournis via Azure Arc

De nombreux clients ont des versions de Windows Server qui approchent de la fin du support et ne peuvent pas respecter la date de fin de support, mais doivent rester en local. Dans ce scénario, ils cherchent à acheter des correctifs de sécurité étendus activés par Azure Arc.

Si les clients déploient une zone d’atterrissage Azure ou en ont déjà une, ils peuvent traiter leurs centres de données locaux comme des zones d’atterrissage normales et les placer dans des zones d’atterrissage nouvelles ou existantes comme bon leur semble. Il existe différentes approches courantes :

Déplacement des ressources de projet dans des abonnements de zone d’atterrissage dédiés pour les ressources de centre de données locales.
Dans des environnements plus grands dotés de plusieurs centres de données dans le monde entier, les clients peuvent avoir une zone d’atterrissage par région géopolitique. Ces zones d’atterrissage contiennent également les ressources de cette région pour fournir une séparation logique des centres de données locaux dans Azure.
Cette approche peut également faciliter le respect les exigences de sécurité, de gouvernance et de conformité pour différents centres de données locaux.
Déplacement des ressources de projet dans des abonnements de zone d’atterrissage distincts en fonction d’autres ressources Azure qui prennent en charge la même application ou le même service.
Les clients doivent consulter les conseils sur l’accélérateur de zone d’atterrissage des serveurs avec Azure Arc pour passer en revue les considérations et recommandations de conception dans les domaines de conception critiques.

Si les clients n’ont pas déployé, ou ne prévoient pas de déployer, une zone d’atterrissage Azure pour le moment :

Les clients doivent consulter les conseils sur l’accélérateur de zone d’atterrissage des serveurs avec Azure Arc pour passer en revue les considérations et recommandations de conception dans les domaines de conception critiques.

Étapes suivantes

Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants.

Partager via