Professionnels Azure pour Google Cloud
Cet article aide les experts Google Cloud à comprendre les bases des comptes, de la plateforme et des services Microsoft Azure. Il décrit également les similitudes et différences clés entre les plateformes Google Cloud et Azure. (Notez que Google Cloud s’appelait Google Cloud Platform (GCP) avant.)
Vous apprendrez ce qui suit :
- Comment les comptes et les ressources sont organisés dans Azure.
- Comment les solutions disponibles sont structurées dans Azure.
- Comment les principaux services Azure diffèrent des services Google Cloud.
Azure et Google Cloud ont développé leurs fonctionnalités indépendamment, de sorte qu’ils ont des différences importantes de conception et d’implémentation.
Vue d’ensemble d’Azure pour Google Cloud
Comme Google Cloud, Microsoft Azure s’articule autour d’un noyau dur de services de calcul, de stockage, de base de données et de réseau. Dans de nombreux cas, les deux plateformes offrent une équivalence de base entre les produits et services qu’elles proposent. Google Cloud et Azure permettent de concevoir des solutions hautement disponibles basées sur des hôtes Linux ou Windows. Par conséquent, si vous êtes habitué au développement à l’aide de Linux et de la technologie OSS, les deux plateformes peuvent faire le travail.
Si les fonctionnalités de ces deux plateformes sont similaires, les ressources fournissant ces fonctionnalités sont souvent organisées différemment. Les relations exactes un à un entre les services requis pour générer une solution ne sont pas toujours claires. Dans d’autres cas, un service particulier peut être proposé sur une plateforme, mais pas sur l’autre.
Gestion des comptes et des abonnements
Azure dispose d’une hiérarchie de groupes d’administration, d’abonnements et de groupes de ressources pour gérer efficacement les ressources. Elle est semblable à la hiérarchie des dossiers et des projets pour les ressources dans Google Cloud.
Étendue des niveaux d’administration Azure
- Groupes d’administration : Ces groupes sont des conteneurs qui vous permettent de gérer plus facilement l’accès, la stratégie et la conformité pour plusieurs abonnements. Tous les abonnements dans un groupe d’administration héritent automatiquement des conditions appliquées à ce groupe d’administration.
- Abonnements : Un abonnement associe de façon logique les comptes d’utilisateur et les ressources qui ont été créées par ces derniers. Chaque abonnement a des limites ou quotas sur la quantité de ressources que vous pouvez créer et utiliser. Les organisations peuvent utiliser des abonnements pour gérer les coûts et les ressources qui sont créées par les utilisateurs, les équipes ou les projets.
- Groupes de ressources : Un groupe de ressources est un conteneur logique dans lequel les ressources Azure comme les applications web, les bases de données et les comptes de stockage sont déployées et gérées.
- Ressources : les ressources sont des instances de services que vous créez, telles que des machines virtuelles, un stockage ou des bases de données SQL.
Vous pouvez acheter des services Azure à l’aide de plusieurs options de tarification, en fonction de la taille et des besoins de votre organisation. Consultez la page Vue d’ensemble de la tarification pour plus d’informations.
Les abonnements Azure sont un regroupement de ressources avec un propriétaire attribué, responsable de la facturation et de la gestion des autorisations.
Un projet Google Cloud est conceptuellement similaire à l’abonnement Azure en termes de facturation, de quotas et de limites. Cependant, d’un point de vue fonctionnel, un projet Google Cloud se rapproche davantage d’un groupe de ressources dans Azure. Il s’agit d’une unité logique sur laquelle les ressources cloud sont déployées.
Notez que contrairement à Google Cloud, il n’y a pas de nombre maximal d’abonnements Azure. Chaque abonnement Azure est lié à un seul locataire Microsoft Entra (un compte dans le vocabulaire de Google Cloud). Un locataire Microsoft Entra peut contenir un nombre illimité d’abonnements, alors que Google Cloud a une limite par défaut de 30 projets par compte.
Les abonnements sont attribués à trois types de comptes d’administrateur :
- Administrateur de comptes. Propriétaire de l’abonnement et compte facturé pour les ressources utilisées dans l’abonnement. L’administrateur de compte ne peut être modifié qu’en transférant la propriété de l’abonnement.
- Administrateur de services. Ce compte dispose des droits pour créer et gérer des ressources dans l’abonnement, mais il n’est pas responsable de la facturation. Par défaut, les statuts Administrateur de compte et Administrateur de service sont attribués au même compte. L’administrateur de compte peut attribuer le statut Administrateur de service à un utilisateur distinct afin qu’il gère les aspects techniques et opérationnels d’un abonnement. Un seul administrateur de service est affecté par abonnement.
- Coadministrateur. Il peut y avoir plusieurs comptes de coadministrateur affectés à un abonnement. Les coadministrateurs ne peuvent pas changer l’administrateur de service, autrement, ils ont un contrôle total sur les utilisateurs et les ressources de l’abonnement.
Pour une gestion précise des accès aux ressources Azure, vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC Azure), qui comprend plus de 70 rôles intégrés. Vous pouvez également créer vos propres rôles personnalisés.
Dans un abonnement, des rôles de niveau d’utilisateur et des autorisations individuelles peuvent également être attribués à des ressources spécifiques. Dans Azure, tous les comptes d'utilisateurs sont associés à un compte Microsoft ou à un compte organisationnel (un compte géré via Microsoft Entra ID).
Les abonnements ont des quotas et des limites de service par défaut. Pour connaître la liste complète de ces limites, consultez Abonnement Azure et limites, quotas et contraintes du service. Ces limites peuvent être augmentées jusqu’à la limite maximale grâce au dépôt d’une requête de support dans le portail de gestion.
Voir aussi
- Ajout ou modification de rôles d’administrateur Azure
- Comment télécharger votre facture Azure et vos données d’utilisation quotidienne
Gestion des ressources
Dans Azure, le terme « ressource » désigne n’importe quel objet de stockage, instance de calcul, appareil réseau ou toute autre entité que vous pouvez créer ou configurer au sein de la plateforme.
Les ressources Azure sont déployées et gérées à l’aide de l’un des deux modèles : Azure Resource Manager ou le modèle de déploiement Azure Classic, plus ancien. Chaque nouvelle ressource est créée à l’aide du modèle de gestionnaire des ressources.
Groupes de ressources
Azure dispose en plus d’une entité appelée « groupes de ressources »qui organise des ressources telles que les machines virtuelles, le stockage et les appareils de réseau virtuel. Une ressource Azure est toujours associée à un groupe de ressources. Une ressource créée dans un groupe de ressources peut être déplacée dans un autre groupe, mais elle ne peut appartenir à un seul groupe de ressources à la fois. Pour plus d’informations, consultez Déplacer des ressources Azure entre des groupes de ressources, des abonnements ou des régions. Les groupes de ressources constituent le regroupement de base utilisé par Azure Resource Manager.
Les ressources peuvent également être organisées à l’aide de balises. Les balises sont des paires clé-valeur qui vous permettent de regrouper des ressources dans votre abonnement, quel que soit leur groupe de ressources.
Interfaces de gestion
Azure propose plusieurs façons de gérer vos ressources :
- Interface Web. Le portail Azure fournit une interface de gestion web complète pour les ressources Azure.
- API REST. L’API REST de Azure Resource Manager fournit un accès par programme à la plupart des fonctionnalités disponibles depuis le portail Azure.
- Ligne de commande. Azure CLI fournit une interface de ligne de commande capable de créer et de gérer des ressources Azure. Azure CLI est disponible pour Windows, Linux et macOS.
- PowerShell. Les modules Azure pour PowerShell permettent d’exécuter des tâches de gestion automatisées à l’aide d’un script. PowerShell est disponible pour Windows, Linux et macOS.
- Modèles. Les modèles Azure Resource Manager fournissent des fonctionnalités de gestion de ressources basées sur le modèle JSON.
- SDK. Les kits SDK sont un ensemble de bibliothèques qui permettent aux utilisateurs de gérer et d’interagir programmatiquement avec les services Azure.
Dans chacune de ces interfaces, le groupe de ressources est essentiel pour la création, le déploiement et les modifications des ressources Azure.
De plus, plusieurs outils de gestion tiers, comme Terraform de Hashicorp et Netflix Spinnaker, sont également disponibles sur Azure.
Voir aussi
Régions et zones de disponibilité
Les défaillances n’ont pas toutes la même incidence. Certaines défaillances matérielles, comme une panne de disque, peuvent affecter un seul ordinateur hôte. Un commutateur réseau défaillant peut impacter un rack entier de serveurs. Vous déplorerez moins fréquemment des défaillances perturbant un centre de données tout entier, comme une panne d’alimentation. Dans de rares cas, toute une région peut devenir indisponible.
La redondance est l’un des moyens de rendre une application résiliente. Toutefois, vous devez planifier en fonction de cette redondance lorsque vous concevez l’application. De plus, le niveau de redondance dont vous avez besoin dépend des besoins de votre entreprise. Les applications n’ont pas toutes besoin d’une redondance interrégion pour se protéger contre une panne régionale. En général, il existe un compromis entre redondance et fiabilité supérieures d’un côté contre complexité et coûts plus élevés de l’autre.
Dans Google Cloud, une région a au moins deux zones de disponibilité. Une zone de disponibilité correspond à un centre de données physiquement isolé dans la région géographique. Azure offre un grand nombre de fonctionnalités pour fournir une redondance des applications à tous les niveaux de défaillances potentielles, dont les groupes de disponibilité, les zones de disponibilité et les régions jumelées.
Le tableau suivant récapitule chaque option.
| Groupe à haute disponibilité | Zone de disponibilité | Région jumelée | |
|---|---|---|---|
| Étendue de la défaillance | Rack | Centre de données | Région |
| Routage des requêtes | Load Balancer | Équilibreur de charge entre les zones | Traffic Manager |
| Latence du réseau | Très faible | Faible | Moyenne à élevée |
| Réseau virtuel | Réseau virtuel | Réseau virtuel | Peering de réseaux virtuels entre régions |
Groupes à haute disponibilité
Pour vous protéger contre les défaillances matérielles localisées, comme une panne de disque ou de commutateur réseau, déployez au moins deux machines virtuelles dans un groupe à haute disponibilité. Un groupe à haute disponibilité se compose d’au moins deux domaines d’erreur qui partagent une source d’alimentation et un commutateur réseau. Les machines virtuelles d’un groupe à haute disponibilité sont distribuées entre les domaines d’erreur. Ainsi, si une défaillance matérielle affecte un domaine d’erreur, le trafic réseau peut toujours être acheminé vers les machines virtuelles des autres domaines d’erreur. Pour plus d’informations sur les groupes à haute disponibilité, consultez la section Gestion de la disponibilité des machines virtuelles Windows dans Azure.
Lorsque des instances de machine virtuelle sont ajoutées aux groupes à haute disponibilité, un domaine de mise à jour leur est également attribuées. Un domaine de mise à jour est un groupe de machines virtuelles définies pour des événements de maintenance planifiée en même temps. La distribution de machines virtuelles sur plusieurs domaines de mise à jour garantit qu’une mise à jour planifiée et des événements de mise à jour corrective affectent uniquement un sous-ensemble de ces machines virtuelles à un moment donné.
Les groupes à haute disponibilité devraient être organisés en fonction du rôle de l’instance dans votre application pour garantir qu’une instance de chaque rôle est opérationnelle. Par exemple, dans une application web à trois couches, créez des groupes à haute disponibilité distincts pour les couches frontales, d’application et de données.
Groupes à haute disponibilité
Zones de disponibilité
Comme Google Cloud, les régions Azure peuvent avoir des zones de disponibilité. Une zone de disponibilité est une zone physiquement séparée au sein d’une région Azure. Chaque zone de disponibilité possède une source d’alimentation, un réseau et un système de refroidissement propres. Le déploiement des machines virtuelles entre les zones de disponibilité aide à protéger une application contre les défaillances à l’échelle du centre de données.
Déploiement de machines virtuelles redondantes interzones sur Azure
Pour plus d'informations, consultez Recommandations pour l'utilisation des zones de disponibilité et des régions.
Régions jumelées
Pour protéger une application contre une panne régionale, vous pouvez la déployer dans plusieurs régions, en vous appuyant sur Azure Traffic Manager pour distribuer le trafic Internet entre les différentes régions. Chaque région Azure est jumelée à une autre région. Ensemble, elles forment une paire régionale. Une région se trouve dans la même zone géographique que la région avec laquelle elle est jumelée (à l’exception de Brésil Sud) pour répondre aux exigences de la résidence de données en termes d’impôts et d’application de la loi.
Contrairement aux zones de disponibilité, physiquement séparées des centres de données mais pouvant être dans des zones géographiques relativement proches, les régions jumelées associées sont généralement séparées de plusieurs centaines de kilomètres. Cette conception permet de s’assurer que les sinistres importants n’affectent que l’une des régions jumelées. Les paires voisines peuvent être définies pour synchroniser une base de données et des données de service de stockage, et elle sont configurées de sorte que les mises à jour de plateforme soient déployées sur une région de la paire à la fois.
Le stockage géo-redondant de Azure est automatiquement sauvegardé vers la région jumelée appropriée. Pour toutes les autres ressources, la création d’une solution entièrement redondante à l’aide de régions jumelées implique la création d’une copie complète de votre solution dans les deux régions.
Paires de régions dans Azure
Voir aussi
- Régions pour les machines virtuelles dans Azure
- Options de disponibilité pour les machines virtuelles dans Azure
- Haute disponibilité des applications Azure
- Défaillances et reprise d’activité après sinistre pour les applications Azure
- Maintenance planifiée des machines virtuelles Linux dans Azure
Services
Pour obtenir la liste des correspondances des services entre les plateformes, consultez Comparaison des services Google Cloud et Azure.
Tous les produits et les services Azure ne sont pas disponibles dans toutes les régions. Consultez la page Produits par région pour plus d’informations. Vous pouvez trouver les garanties de temps d’activité et les stratégies de crédit de temps d’arrêt pour chaque produit ou service Azure sur la page Contrats de niveau de service.