Cette architecture de référence montre comment déployer des machines virtuelles et un réseau virtuel configuré pour une application multiniveau en utilisant Apache Cassandra sur Linux pour le niveau 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 l'Azure Standard Load Balancer pour distribuer le trafic réseau du niveau Web vers le niveau Business.
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
Base de données Apache Cassandra. Fournit une haute disponibilité du niveau Données, en activant la réplication et le basculement.
OpsCenter. Déployez une solution de supervision telle que DataStax OpsCenter pour superviser le cluster Cassandra.
Jumpbox. Également appelée hôte bastion. 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 (Bureau à distance).
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 Linux 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 chevauche pas votre réseau local, au cas où vous devriez configurer ultérieurement 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 des réseaux virtuels et des 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. Donnez plutôt une adresse IP privée à chaque machine virtuelle. Les clients se connectent à l'aide de l'adresse IP 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, créez une règle qui mappe le port 80 de la configuration frontend au port 80 dans le pool d’adresses backend. 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.
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 recommandation, le niveau Base de données doit bloquer le trafic entrant provenant du sous-réseau du niveau Web.
- Interdisez tout le trafic entrant provenant du réseau virtuel. (Utilisez la balise
VIRTUAL_NETWORKdans la règle.) - Autorisez le trafic entrant à partir du sous-réseau du niveau Business.
- 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.
- Autorisez le trafic SSH (port 22) à 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.
Cassandra
Nous vous recommandons d'utiliser DataStax Enterprise pour la production, mais ces recommandations s'appliquent à toute édition de Cassandra. Pour plus d'informations sur l'exécution de DataStax dans Azure, consultez le Guide de déploiement de DataStax Enterprise pour Azure.
Configurez les nœuds en mode rack. Mappez les domaines d’erreur à des racks dans le fichier cassandra-rackdc.properties.
Vous n’avez pas besoin d’équilibreur de charge devant le cluster. Le client se connecte directement à un nœud dans le cluster.
Les scripts de déploiement de cette architecture utilisent la résolution de noms afin d'initialiser le nœud initial pour la communication entre les clusters (gossip). Pour activer la résolution de noms, le déploiement crée une zone DNS privée Azure avec des enregistrements A pour les nœuds Cassandra. En fonction de vos scripts d'initialisation, vous serez peut-être en mesure d'utiliser l'adresse IP statique à la place.
Notes
Azure Private DNS est actuellement disponible en préversion publique.
Serveur de rebond
N’autorisez pas l’accès SSH à partir de l’Internet public vers les machines virtuelles qui exécutent la charge de travail d’application. Au lieu de cela, tout l’accès SSH à ces machines virtuelles doit 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 SSH 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 SSH provenant du sous-réseau de gestion.
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 dans un groupe à haute disponibilité. 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.
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.
Conseil
Quand vous utilisez une solution de mise à l’échelle automatique, testez-la bien à l’avance avec des charges de travail de niveau production.
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.
Efficacité des performances
Pour tirer le meilleur parti de Cassandra sur les machines virtuelles Azure, consultez les recommandations de l'article Exécuter Apache Cassandra sur des machines virtuelles Azure.
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.
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.
Cluster Cassandra
Pour le cluster Cassandra, les scénarios de basculement dépendent des niveaux de cohérence utilisés par l’application et du nombre de réplicas. Pour plus d’informations sur l’utilisation et les niveaux de cohérence dans Cassandra, consultez Configuration de la cohérence des données et Cassandra : quel est le nombre de nœuds en communication avec le quorum ? La disponibilité des données dans Cassandra est déterminée par le niveau de cohérence utilisé par l’application et le mécanisme de réplication. Pour plus d'informations sur la réplication dans Cassandra, consultez Explication de la réplication des données dans les bases de données NoSQL.
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 :
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 Linux. Vous n'êtes facturé que pour les machines virtuelles Azure que vous déployez, ainsi que 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 Virtual Machine Scale Sets proprement dit.
Pour connaître les options tarifaires des machines virtuelles individuelles, consultez Tarification des machines virtuelles Linux.
É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. Les machines virtuelles d’un réseau virtuel ne peuvent pas communiquer directement avec celles d’un autre réseau virtuel. Les machines virtuelles situées sur un même réseau virtuel peuvent communiquer, sauf si vous créez des groupes de sécurité réseau (NSG) pour limiter le trafic. Pour plus d'informations, consultez Services de cloud computing Microsoft et sécurité réseau.
Pour le trafic Internet entrant, les règles d’équilibreur de charge définissent le trafic qui peut atteindre le backend. Toutefois, les règles d’équilibreur de charge ne prennent pas en charge les listes de sécurité IP. Par conséquent, si vous souhaitez ajouter certaines adresses IP publiques à une liste verte, ajoutez un groupe de sécurité réseau au sous-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). 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. L’isolation des charges de travail facilite l’association des ressources spécifiques de la charge de travail à une équipe DevOps afin que cette dernière puisse gérer de manière indépendante tous les aspects de ces ressources. Cet isolement permet aux équipes et services 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 Apache Cassandra. L'extension de script personnalisé permet le téléchargement et l'exécution de code arbitraire sur une machine virtuelle, pour une personnalisation illimitée du système d'exploitation d'une machine virtuelle Azure. 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. Pour résoudre ce problème, les outils de gestion de la configuration peuvent être utilisés.
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 de Microsoft Azure Well-Architecture Framework.