Application multiniveau Windows dans Azure

Cette architecture de référence montre comment déployer des machines virtuelles et un réseau virtuel configuré pour une application multiniveau à l'aide de SQL Server sous Windows pour la couche Données.

Architecture

Téléchargez un fichier Visio de cette architecture.

Workflow

L’architecture possède les composants suivants :

Général

• Groupe de ressources. Les groupes de ressources permettent de regrouper des ressources Azure afin de pouvoir les gérer selon leur durée de vie, leur propriétaire ou d'autres critères.

• Zones de disponibilité. Les zones de disponibilité sont des emplacements physiques situés dans une région Azure. Chaque zone est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. L'installation de machines virtuelles dans différentes zones permet à l'application de résister aux défaillances qui surviennent au sein d'une zone.

Mise en réseau et équilibrage de charge

• Réseau virtuel et sous-réseaux. Chaque machine virtuelle Azure est déployée dans un réseau virtuel qui peut être segmenté en sous-réseaux. Créez un sous-réseau distinct pour chaque niveau.

• Passerelle d’application. Application Gateway est un équilibreur de charge de couche 7. Dans cette architecture, il achemine les requêtes HTTP vers le serveur web frontal. La passerelle Application Gateway fournit également un pare-feu d’applications web (WAF) qui protège l’application contre les vulnérabilités et exploitations courantes.

• Équilibreurs de charge : Utilisez Azure Standard Load Balancer pour répartir le trafic réseau de la couche Web vers la couche Entreprise, et de la couche Entreprise vers SQL Server.

• Groupes de sécurité réseau (NSG) : Utilisez des groupes de sécurité réseau pour limiter le trafic réseau au sein du réseau virtuel. Par exemple, dans l’architecture à trois niveaux illustrée ici, le niveau base de données n’accepte pas le trafic en provenance du serveur web frontal, mais uniquement du niveau Business et du sous-réseau de gestion.

• Protection DDOS. Bien que la plateforme Azure offre une protection de base contre les attaques par déni de service distribué (DDoS), nous vous recommandons d’utiliser Azure DDoS Network Protection, qui comporte des fonctionnalités améliorées d’atténuation de ce type de risques. Consultez Considérations relatives à la sécurité.

• Azure DNS. Azure DNS est un service d’hébergement pour les domaines DNS. Il offre une résolution de noms à l’aide de l’infrastructure Microsoft Azure. En hébergeant vos domaines dans Azure, vous pouvez gérer vos enregistrements DNS avec les mêmes informations d’identification, les mêmes API, les mêmes outils et la même facturation que vos autres services Azure.

Machines virtuelles

• Groupe de disponibilité SQL Server Always On. Fournit une haute disponibilité du niveau Données, en activant la réplication et le basculement. Il utilise la technologie du WSFC (Cluster de basculement Windows Server) pour le basculement.

• Serveurs AD DS (Active Directory Domain Services) . Les objets ordinateur pour le cluster de basculement et ses rôles en cluster associés sont créés dans AD DS (Active Directory Domain Services).

• Témoin de cloud. Un cluster de basculement nécessite plus de la moitié de ses nœuds pour fonctionner, on dit alors qu’il a un quorum. Si le cluster ne contient que deux nœuds, une partition réseau peut mener chaque nœud à penser qu’il est le nœud principal. Dans ce cas, vous avez besoin d’un témoin pour arbitrer et établir le quorum. Un témoin est une ressource telle qu’un disque partagé qui peut arbitrer pour établir le quorum. Le témoin de cloud est un type de témoin qui utilise le stockage Blob Azure. Pour en savoir plus sur le concept de quorum, consultez Comprendre les quorums de cluster et de pool. Pour plus d’informations sur les témoins de cloud, consultez Déployer un témoin de cloud pour un cluster de basculement.

• Jumpbox. Également appelée hôte bastion. Il s’agit généralement d’une machine virtuelle sécurisée sur le réseau, utilisée par les administrateurs pour se connecter aux autres machines virtuelles. La jumpbox a un groupe de sécurité réseau qui autorise le trafic distant provenant uniquement d’adresses IP publiques figurant sur une liste verte. Le groupe de sécurité réseau doit autoriser le trafic RDP (Remote Desktop Protocol). Azure propose la solution gérée Azure Bastion pour répondre à ce besoin.

Recommandations

Vos exigences peuvent différer de celles de l’architecture décrite ici. Utilisez ces recommandations comme point de départ.

Machines virtuelles

Pour obtenir des recommandations sur la configuration des machines virtuelles, consultez Exécuter une machine virtuelle Windows sur Azure.

Réseau virtuel

Lorsque vous créez le réseau virtuel, déterminez le nombre d'adresses IP dont vos ressources ont besoin sur chaque sous-réseau. Spécifiez un masque de sous-réseau et une plage d'adresses de réseau suffisamment large pour les adresse IP requises, à l'aide de la notation CIDR. Utilisez un espace d'adressage conforme aux blocs d'adresses IP privées standard, à savoir 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16.

Choisissez une plage d'adresses qui ne se chevauche pas avec votre réseau local, au cas où vous auriez ultérieurement besoin de configurer une passerelle entre le réseau virtuel et votre réseau local. Une fois le réseau virtuel créé, vous ne pouvez plus modifier la plage d'adresses.

Concevez les sous-réseaux en tenant compte des exigences en matière de sécurité et de fonctionnalités. Toutes les machines virtuelles du même niveau ou rôle doivent être placées sur le même sous-réseau, qui peut constituer une limite de sécurité. Pour plus d'informations sur la conception de réseaux virtuels et de sous-réseaux, consultez Planifier et concevoir des réseaux virtuels Azure.

Application Gateway

Pour plus d'informations sur la configuration de la passerelle Application Gateway, consultez Présentation de la configuration d'Application Gateway.

Équilibreurs de charge

N’exposez pas les machines virtuelles directement à Internet. Attribuez plutôt à chaque machine virtuelle une adresse IP privée. Les clients se connectent à l’aide de l’adresse IP publique associée à la passerelle Application Gateway.

Définissez des règles d’équilibreur de charge pour diriger le trafic réseau vers les machines virtuelles. Par exemple, pour activer le trafic HTTP, mappez le port 80 de la configuration du serveur frontal au port 80 dans le pool d’adresses principales. Lorsqu'un client envoie une requête HTTP au port 80, l'équilibreur de charge sélectionne une adresse IP principale à l'aide d'un algorithme de hachage qui inclue l'adresse IP source. Les requêtes des clients sont réparties entre toutes les machines virtuelles dans le pool d’adresses principales.

Groupes de sécurité réseau

Utilisez des règles de groupe de sécurité réseau pour limiter le trafic entre les niveaux. Par exemple, dans l’architecture à trois niveaux ci-dessus, le niveau Web ne communique pas directement avec le niveau Base de données. Pour appliquer cette règle, la couche Base de données doit bloquer le trafic entrant provenant du sous-réseau de la couche Web.

1. Interdisez tout le trafic entrant provenant du réseau virtuel. (Utilisez la balise VIRTUAL_NETWORK dans la règle.)
2. Autorisez le trafic entrant à partir du sous-réseau du niveau Business.
3. Autorisez le trafic entrant à partir du sous-réseau du niveau Base de données. Cette règle autorise la communication entre les machines virtuelles de la base de données, qui est nécessaire pour la réplication de base de données et le basculement.
4. Autorisez le trafic RDP (port 3389) à partir du sous-réseau du serveur de rebond. Cette règle permet aux administrateurs de se connecter au niveau Base de données à partir du serveur de rebond.

Créez les règles 2 à 4 en leur attribuant une priorité plus élevée qu'à la première règle afin qu'elles l'ignorent.

Groupes de disponibilité SQL Server Always On

Nous vous recommandons d'utiliser des groupes de disponibilité AlwaysOn pour la haute disponibilité de SQL Server. Avec les versions antérieures à Windows Server 2016, les groupes de disponibilité AlwaysOn nécessitent un contrôleur de domaine et tous les nœuds du groupe de disponibilité doivent être dans le même domaine Active Directory.

Les autres couches se connectent à la base de données par le biais d'un écouteur de groupe de disponibilité. L’écouteur permet à un client SQL de se connecter sans connaître le nom de l’instance physique de SQL Server. Les machines virtuelles qui accèdent à la base de données doivent être jointes au domaine. Le client (dans ce cas, un autre niveau) utilise le système DNS pour résoudre le nom du réseau virtuel de l’écouteur en adresses IP.

Configurez le groupe de disponibilité SQL Server AlwaysOn comme suit :

1. Créez un cluster WSFC (clustering de basculement Windows Server), un groupe de disponibilité SQL Server AlwaysOn et un réplica principal. Pour plus d'informations, consultez Prise en main des groupes de disponibilité AlwaysOn.

2. Créez un équilibreur de charge interne avec une adresse IP privée statique.

3. Créez un écouteur de groupe de disponibilité et mappez le nom DNS de l’écouteur à l’adresse IP d’un équilibreur de charge interne.

4. Créez une règle d’équilibreur de charge pour le port d’écoute SQL Server (port TCP 1433 par défaut). La règle d’équilibreur de charge doit activer l’adresse IP flottante, également appelé Retour direct du serveur. Cela force la machine virtuelle à répondre directement au client, ce qui permet de bénéficier d’une connexion directe au réplica principal.

   Notes

   Quand l’adresse IP flottante est activée, le numéro de port frontend doit être identique au numéro de port backend dans la règle d’équilibreur de charge.

Quand un client SQL tente de se connecter, l’équilibreur de charge achemine la demande de connexion au réplica principal. En cas de basculement vers un autre réplica, l’équilibreur de charge achemine automatiquement les nouvelles requêtes à un nouveau réplica principal. Pour plus d'informations, consultez Configurer un écouteur à équilibrage de charge interne pour des groupes de disponibilité SQL Server AlwaysOn.

Lors d’un basculement, les connexions clientes existantes sont fermées. Une fois le basculement terminé, les nouvelles connexions sont acheminées vers le nouveau réplica principal.

Si votre application effectue beaucoup plus de lectures que d’écritures, vous pouvez décharger certaines des requêtes en lecture seule vers un réplica secondaire. Voir Utilisation d'un écouteur pour se connecter à un réplica secondaire en lecture seule (routage en lecture seule).

Testez votre déploiement en forçant un basculement manuel du groupe de disponibilité.

Serveur de rebond

Lorsque vous exécutez des machines virtuelles dans un réseau virtuel privé, comme dans cette architecture, il est nécessaire d’accéder aux machines virtuelles pour l’installation de logiciels, les mises à jour correctives, etc. Toutefois, rendre ces machines accessibles à l’Internet public n’est pas une bonne idée, car cela augmente considérablement la surface d’attaque. Au lieu de cela, un serveur de rebond (jumpbox) est utilisé comme couche d’accès intermédiaire.

Dans le passé, une machine virtuelle gérée par le client pouvait être utilisée en tant que serveur de rebond. Dans ce scénario, les recommandations suivantes s’appliquent :

• N’autorisez pas l’accès RDP à partir de l’Internet public aux machines virtuelles qui exécutent la charge de travail d’application. Au lieu de cela, tous les accès RDP à ces machines virtuelles doivent transiter par le serveur de rebond. Un administrateur se connecte au serveur de rebond, puis se connecte à l’autre machine virtuelle à partir du serveur de rebond. Le serveur de rebond autorise le trafic SSH à partir d’Internet, mais uniquement à partir d’adresses IP connues et sûres.
• Le serveur de rebond a des exigences de performances minimales, donc sélectionnez une machine virtuelle de petite taille. Créez-lui une adresse IP publique. Placez-le sur le même réseau virtuel que les autres machines virtuelles, mais sur un sous-réseau de gestion distinct.
• Pour sécuriser le serveur de rebond, ajoutez une règle de groupe de sécurité réseau qui autorise les connexions RDP provenant uniquement d’un ensemble sûr d’adresses IP publiques. Configurez les groupes de sécurité réseau pour les autres sous-réseaux de façon à autoriser le trafic RDP provenant du sous-réseau de gestion.

Pour une machine virtuelle gérée par le client, toutes ces règles s’appliquent. Toutefois, la recommandation actuelle consiste à utiliser Azure Bastion, une solution de serveur de rebond gérée qui permet l’accès HTML5 à RDP ou SSH derrière la protection fournie par Azure AD. Il s’agit d’une solution bien plus simple qui a finalement un coût total de possession inférieur pour le client.

Considérations

Scalabilité

Groupes identiques

Pour les couches Web et Entreprise, envisagez d’utiliser Virtual Machine Scale Sets au lieu de déployer des machines virtuelles distinctes. Un groupe identique simplifie le déploiement et la gestion d’un ensemble de machines virtuelles identiques, et effectue la mise à l’échelle des machines virtuelles en fonction des métriques de performances. À mesure que la charge sur les machines virtuelles augmente, des machines virtuelles supplémentaires sont ajoutées automatiquement à l’équilibreur de charge. Les groupes identiques sont parfaits si vous devez rapidement effectuer un scale-out des machines virtuelles, ou si vous avez besoin d’une mise à l’échelle automatique.

Il existe deux façons de configurer des machines virtuelles déployées dans un groupe identique :

• Utiliser des extensions pour configurer la machine virtuelle après son déploiement. Avec cette approche, le démarrage des nouvelles instances de machine virtuelle peut être plus long que pour une machine virtuelle sans extension.

• Déployer un disque managé avec une image de disque personnalisée. Cette option peut être plus rapide à déployer. Toutefois, elle vous oblige à tenir l’image à jour.

Pour plus d'informations, consultez Considérations relatives à la conception des groupes de machines virtuelles identiques.

Limites d’abonnement

Chaque abonnement Azure a des limites par défaut, notamment une quantité maximale de machines virtuelles par région. Vous pouvez augmenter la limite en créant une demande de support. Pour plus d’informations, consultez Abonnement Azure et limites, quotas et contraintes de service.

Application Gateway

Application Gateway prend en charge le mode de capacité fixe ou le mode de mise à l'échelle automatique. Le mode de capacité fixe est utile pour les scénarios avec des charges de travail cohérentes et prévisibles. Envisagez d'utiliser le mode de mise à l'échelle automatique pour les charges de travail à trafic variable. Pour plus d'informations, consultez Application Gateway v2 avec mise à l'échelle automatique et redondance interzone.

Disponibilité

Les zones de disponibilité offrent une résilience inégalée au sein d'une même région. Si vous avez besoin de davantage de disponibilité, vous pouvez répliquer l'application dans deux régions en utilisant Azure Traffic Manager pour le basculement. Pour plus d'informations, consultez Application multiniveau multirégion pour une haute disponibilité.

Toutes les régions ne prennent pas en charge les zones de disponibilité, et certaines tailles de machines virtuelles ne sont pas disponibles dans toutes les zones. Exécutez la commande Azure CLI suivante afin de rechercher les zones prises en charge pour chaque taille de machine virtuelle au sein d'une région :

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Si vous déployez cette architecture dans une région qui ne prend pas en charge les zones de disponibilité, placez les machines virtuelles de chaque niveau dans un groupe à haute disponibilité. Les machines virtuelles du même groupe à haute disponibilité sont déployées sur plusieurs serveurs physiques, racks de calcul, unités de stockage et commutateurs réseau à des fins de redondance. Les groupes identiques utilisent automatiquement des groupes de placement, agissant comme des groupes à haute disponibilité implicites.

Lors du déploiement dans les zones de disponibilité, utilisez la référence SKU Standard d'Azure Load Balancer et la référence SKU v2 d'Application Gateway. Ces références SKU prennent en charge la redondance interzone. Pour plus d'informations, consultez les pages suivantes :

• Équilibreur de charge standard et zones de disponibilité
• Application Gateway v2 avec mise à l'échelle automatique et redondance interzone
• Comment Application Gateway prend-il en charge la haute disponibilité et la scalabilité ?

Un même déploiement Application Gateway peut exécuter plusieurs instances de la passerelle. Pour les charges de travail de production, exécutez au moins deux instances.

Sondes d’intégrité

App Gateway et Load Balancer utilisent tous les deux des sondes d'intégrité pour superviser la disponibilité des instances de machine virtuelle.

• Application Gateway utilise toujours une sonde HTTP.
• Load Balancer peut tester le protocole TCP ou HTTP. En général, si une machine virtuelle exécute un serveur HTTP, vous devez utiliser une sonde HTTP. Sinon, utilisez TCP.

Si une sonde ne peut pas atteindre une instance dans le délai imparti, la passerelle ou l'équilibreur de charge cesse d'acheminer le trafic vers cette machine virtuelle. La sonde poursuit les vérifications et renvoie la machine virtuelle au pool back-end si elle redevient disponible.

Les sondes HTTP envoient une requête HTTP GET à un chemin spécifié et écoutent une réponse HTTP 200. Ce chemin peut être un chemin racine (« / ») ou d’un point de terminaison de surveillance de l’intégrité qui implémente une logique personnalisée afin de vérifier l’intégrité de l’application. Le point de terminaison doit autoriser les requêtes HTTP anonymes.

Pour plus d'informations sur les sondes d'intégrité, consultez :

• Sondes d'intégrité Load Balancer
• Vue d'ensemble de l'analyse d'intégrité Application Gateway

Pour plus d'informations sur la conception d'un point de terminaison de sonde d'intégrité, consultez Modèle Supervision de point de terminaison d'intégrité.

Optimisation des coûts

Utilisez la Calculatrice de prix Azure pour estimer les coûts. Voici quelques autres éléments à prendre en compte :

Groupes identiques de machines virtuelles

Les groupes de machines virtuelles identiques sont disponibles sur toutes les tailles de machines virtuelles Windows. Vous n'êtes facturé que pour les machines virtuelles Azure que vous déployez, et pour toutes les ressources d'infrastructure sous-jacentes supplémentaires consommées, comme le stockage et la mise en réseau. Il n'y a pas de frais supplémentaires pour le service des Virtual Machine Scale Sets.

Pour connaître les options tarifaires des machines virtuelles individuelles, consultez Tarification des machines virtuelles Windows.

Serveur SQL

Si vous choisissez Azure SQL DBaas, vous pouvez réaliser des économies car vous n'avez pas besoin de configurer un groupe de disponibilité AlwaysOn et des machines contrôleurs de domaine. Différentes options de déploiement sont disponibles, de la base de données unique à l'instance gérée, en passant par les pools élastiques. Pour plus d'informations, consultez Tarification d'Azure SQL.

Pour connaître les options de tarification des machines virtuelles SQL Server, consultez Tarification des machines virtuelles SQL.

Équilibreurs de charge

Vous n'êtes facturé que pour le nombre de règles de trafic sortant et d'équilibrage de la charge configurées. Les règles NAT entrantes sont gratuites. Il n'y a pas de frais horaires pour l'équilibreur de charge Standard Load Balancer lorsqu'aucune règle n'est configurée.

Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.

Sécurité

Les réseaux virtuels sont une limite d’isolation du trafic dans Azure. Par défaut, les machines virtuelles d'un réseau virtuel ne peuvent pas communiquer directement avec celles d'un autre réseau virtuel. Cependant, vous pouvez explicitement connecter des réseaux virtuels à l'aide de l'appairage de réseaux virtuels.

NSG. Utilisez des groupes de sécurité réseau (NSG) pour limiter le trafic vers et depuis Internet. Pour plus d'informations, consultez Services de cloud computing Microsoft et sécurité réseau.

DMZ. Ajoutez une appliance virtuelle réseau (NVA) pour créer un réseau de périmètre (DMZ) entre Internet et le réseau virtuel Azure. NVA est un terme générique décrivant une appliance virtuelle qui peut effectuer des tâches liées au réseau, telles que pare-feu, inspection des paquets, audit et routage personnalisé. Pour plus d'informations, consultez Implémentation d'un réseau de périmètre entre Azure et Internet.

Chiffrement. Chiffrez les données sensibles au repos et utilisez Azure Key Vault pour gérer les clés de chiffrement de base de données. Key Vault peut stocker des clés de chiffrement dans des modules de sécurité matériel (HSM). Pour plus d’informations, consultez Configurer l’intégration d’Azure Key Vault pour SQL Server sur des machines virtuelles Azure. Il est également recommandé pour stocker des secrets de l’application, comme des chaînes de connexion de base de données, dans le coffre de clés.

Protection DDOS. La plateforme Azure fournit par défaut une protection DDoS de base. Cette protection de base est destinée à protéger l’infrastructure Azure dans sa globalité. Bien que cette protection DDoS de base soit activée automatiquement, nous vous recommandons d’utiliser Azure DDoS Network Protection. Network Protection utilise un réglage adaptatif basé sur les modèles de trafic réseau de votre application afin de détecter les menaces. Cela lui permet d’appliquer des atténuations contre les attaques DDoS pouvant passer inaperçues aux yeux des stratégies de DDoS à l’échelle de l’infrastructure. Network Protection fournit également des alertes, une télémétrie et une analytique par le biais d’Azure Monitor. Pour plus d’informations, consultez Azure DDoS Protection : Bonnes pratiques et architectures de référence.

Excellence opérationnelle

Dans cette architecture, toutes les ressources principales et leurs dépendances se trouvant dans le même réseau virtuel, elles sont isolées au sein de la même charge de travail de base. Cela facilite l’association des ressources spécifiques de la charge de travail à une équipe afin que cette dernière puisse gérer de manière indépendante tous les aspects de ces ressources. Cet isolement permet à DevOps d'effectuer une intégration et une livraison continues (CI/CD).

En outre, vous pouvez utiliser différents modèles de déploiement et les intégrer à Azure DevOps Services pour approvisionner différents environnements en quelques minutes, par exemple pour répliquer des scénarios de production ou des environnements de test de charge uniquement lorsque cela s'avère nécessaire, ce qui permet de réduire les coûts.

Dans ce scénario, vos machines virtuelles sont configurées à l’aide d’extensions de machine virtuelle, car celles-ci permettent d’installer certains logiciels supplémentaires, comme des agents anti-programmes malveillants et des agents de sécurité. Les extensions de machine virtuelle ne sont installées et exécutées qu'au moment de la création de la machine virtuelle. Par conséquent, si le système d'exploitation est mal configuré à un stade ultérieur, une intervention manuelle sera nécessaire pour rétablir son état.

Les outils de gestion de la configuration, en particulier DSC (Desired State Configuration), sont utilisés dans cette architecture pour configurer Active Directory et un groupe de disponibilité SQL Server Always On.

Pensez à utiliser Azure Monitor pour analyser et optimiser les performances de votre infrastructure, et pour superviser et diagnostiquer les problèmes de réseau sans vous connecter à vos machines virtuelles. Application Insights est un composant d'Azure Monitor. Il vous fournit des journaux et des métriques enrichies pour vérifier l'état de votre environnement Azure dans sa globalité. Azure Monitor vous aidera à suivre l'état de votre infrastructure.

Vous devez non seulement superviser les éléments de calcul qui prennent en charge le code de votre application, mais également votre plateforme de données, en particulier vos bases de données, car des performances médiocres de la couche Données d'une application peuvent avoir de graves conséquences.

Afin de tester l'environnement Azure où les applications sont exécutées, celui-ci doit être soumis à un contrôle de version et être déployé via les mêmes mécanismes que le code d'application. Il pourra ensuite être testé et validé en utilisant les paradigmes de test DevOps.

Pour plus d'informations, consultez la section Excellence opérationnelle d'Azure Well-Architecture Framework.

Étapes suivantes

• Module Microsoft Learn : Visite guidée du style d’architecture multiniveau