Cet exemple de scénario s’applique à tout secteur d’activité ayant besoin de déployer des applications multiniveaux résilientes conçues pour la haute disponibilité et la reprise d’activité. Dans ce scénario, l’application se compose de trois couches.
- Couche web : couche supérieure comprenant l’interface utilisateur. Cette couche analyse les interactions utilisateur et transmet les actions à la couche suivante pour le traitement.
- Couche métier : traite les interactions utilisateur et prend des décisions logiques concernant les étapes suivantes. Cette couche relie la couche web et la couche données.
- Couche données : stocke les données d’application. Vous utilisez généralement une base de données, un stockage d’objets ou un stockage de fichiers.
Les applications stratégiques s’exécutant sur Windows ou Linux font partie des scénarios d’application courants. Il peut s’agir d’une application du commerce comme SAP et SharePoint, ou une application métier personnalisée.
Cas d’usage potentiels
Les autres cas d’usage appropriés sont les suivants :
- Déploiement d’applications hautement résilientes comme SAP et SharePoint
- Conception d’un plan de continuité d’activité et de reprise d’activité pour les applications métier
- Configurer la reprise d’activité et effectuer les exercices associés à des fins de conformité
Architecture
Téléchargez un fichier Visio de cette architecture.
Workflow
- Distribuez les machines virtuelles dans chaque niveau sur deux zones de disponibilité dans les régions qui prennent en charge les zones. Dans les autres régions, déployez les machines virtuelles dans chaque niveau au sein d’un groupe à haute disponibilité.
- La couche Données peut être configurée pour utiliser des groupes de disponibilité Always On. Avec cette configuration SQL Server, un réplica principal en lecture/écriture au sein d’un groupe de disponibilité est configuré avec jusqu’à huit réplicas secondaires en lecture seule. Si un problème se produit avec le réplica principal, le groupe de disponibilité bascule l’activité de lecture/écriture principale sur l’un des réplicas secondaires, ce qui permet à l’application de rester disponible. Pour plus d’informations, consultez Vue d’ensemble des groupes de disponibilité AlwaysOn pour SQL Server.
- Pour les scénarios de reprise d’activité, vous pouvez configurer la réplication asynchrone native SQL Always On sur la région cible utilisée pour la reprise d’activité. Vous pouvez aussi configurer la réplication Azure Site Recovery sur la région cible si le taux de changement des données est dans les limites prises en charge par Azure Site Recovery.
- Les utilisateurs accèdent à la couche web ASP.NET front-end via le point de terminaison Traffic Manager.
- Traffic Manager redirige le trafic vers le point de terminaison de l’adresse IP publique principale dans la région source principale.
- L’adresse IP publique redirige l’appel vers l’une des instances de machine virtuelle de la couche web par le biais d’un équilibreur de charge public. Toutes les instances de machine virtuelle de la couche web se trouvent dans un seul sous-réseau.
- À partir de la machine virtuelle de la couche web, chaque appel est routé vers une des instances de machine virtuelle de la couche métier à travers un équilibreur de charge interne pour le traitement. Toutes les machines virtuelles de la couche métier sont dans un sous-réseau distinct.
- L’opération est traitée dans la couche métier et l’application ASP.NET se connecte au cluster Microsoft SQL Server dans une couche back-end via un équilibreur de charge interne Azure. Ces instances SQL Server back-end sont dans un sous-réseau distinct.
- Le point de terminaison secondaire de Traffic Manager est configuré comme l’adresse IP publique dans la région cible utilisée pour la reprise d’activité.
- En cas de perturbation de la région principale, vous appelez le basculement d’Azure Site Recovery et l’application devient active dans la région cible.
- Le point de terminaison Traffic Manager redirige automatiquement le trafic client vers l’adresse IP publique de la région cible.
Components
- Les groupes à haute disponibilité garantissent que les machines virtuelles que vous déployez sur Azure sont distribuées sur plusieurs nœuds matériels isolés dans un cluster. En cas de défaillance matérielle ou logicielle dans Azure, seule une partie de vos machines virtuelles est affectée et votre solution globale reste disponible et opérationnelle.
- Les zones de disponibilité protègent les applications et les données contre les défaillances de centre de données. Les zones de disponibilité sont des emplacements physiques individuels au sein d’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.
- Azure Site Recovery (ASR) vous permet de répliquer des machines virtuelles sur une autre région Azure pour assurer la continuité d’activité et la reprise d’activité. Vous pouvez effectuer régulièrement des exercices de reprise d’activité pour garantir que vous répondez aux besoins de conformité. La machine virtuelle est répliquée avec les paramètres spécifiés dans la région sélectionnée afin que vous puissiez récupérer vos applications en cas de panne dans la région source.
- Azure Traffic Manager est un équilibreur de charge du trafic DNS qui distribue le trafic de manière optimale aux services dans toutes les régions Azure du monde, tout en offrant réactivité et haute disponibilité.
- Azure Load Balancer distribue le trafic entrant en fonction des règles définies et des sondes d’intégrité. Un équilibreur de charge offre une latence faible et un débit élevé, et peut gérer jusqu’à des millions de flux pour toutes les applications TCP et UDP. Un équilibreur de charge public est utilisé dans ce scénario pour distribuer le trafic client entrant à la couche web. Dans ce scénario, un équilibreur de charge interne est utilisé pour distribuer le trafic de la couche métier au cluster SQL Server back-end.
Autres solutions
- Vous pouvez remplacer Windows par d’autres systèmes d’exploitation, car rien dans l’infrastructure ne dépend du système d’exploitation.
- SQL Server pour Linux peut remplacer le magasin de données back-end.
- Vous pouvez remplacer la base de données par n’importe quelle application de base de données standard disponible.
Détails du scénario
Ce scénario présente une application multiniveau qui utilise ASP.NET et Microsoft SQL Server. Dans les régions Azure qui prennent en charge les zones de disponibilité, vous pouvez déployer vos machines virtuelles dans une région source sur diverses zones de disponibilité et répliquer les machines virtuelles sur la région cible utilisée pour la reprise d’activité. Dans les régions Azure ne prenant pas en charge les zones de disponibilité, vous pouvez déployer vos machines virtuelles dans un groupe à haute disponibilité et répliquer les machines virtuelles dans la région cible.
Pour acheminer le trafic entre les régions, vous avez besoin d’un équilibreur de charge global. Deux offres Azure principales sont disponibles :
- Azure Front Door
- Azure Traffic Manager
Lorsque vous choisissez un équilibreur de charge, vous devez tenir compte de vos exigences et de l’ensemble des fonctionnalités des deux offres. Avec quelle rapidité voulez-vous procéder au basculement ? Pouvez-vous assumer la charge que représente la gestion TLS ? Existe-t-il des contraintes de coût organisationnelles ?
Front Door inclut des fonctionnalités de couche 7, telles que le déchargement SSL, le routage basé sur le chemin, le basculement rapide, la mise en cache pour améliorer les performances et la disponibilité de vos applications. L’intégration précoce de l’infrastructure au réseau Azure peut réduire le temps de trajet des paquets.
Comme Front Door ajoute un nouveau tronçon, des opérations de sécurité supplémentaires sont ajoutées. Si l’architecture est conforme aux exigences réglementaires, il peut y avoir des restrictions concernant le point de terminaison TLS du trafic supplémentaire. Les suites de chiffrement TLS sélectionnées par Front Door doivent être conformes à la barre de sécurité de votre organisation. Par ailleurs, Front Door s’attend à ce que les services principaux utilisent des certificats utilisés par Microsoft.
Il faut également tenir compte du coût. L’architecture doit tirer parti de l’ensemble étendu de fonctionnalités (pas seulement du basculement) pour justifier le coût supplémentaire.
Traffic Manager est un service d’équilibrage de charge basé sur DNS. Il ne procède à l’équilibrage et au basculement qu’au niveau du DNS. Pour cette raison, il ne peut pas basculer aussi rapidement que Front Door, en raison de défis courants concernant la mise en cache DNS et les systèmes qui ne respectent pas DNS TTLS.
Vous pouvez combiner les deux équilibreurs de charge, si nécessaire. Par exemple, vous souhaitez un basculement basé sur DNS, mais vous souhaitez ajouter une expérience POP devant l’infrastructure gérée par le trafic.
Cette architecture utilise Traffic Manager, car elle est légère. Le délai du basculement est suffisant en guise d’exemple.
Considérations
Extensibilité
Vous pouvez ajouter ou supprimer des machines virtuelles dans chaque niveau selon vos besoins de mise à l’échelle. Comme ce scénario utilise des équilibreurs de charge, vous pouvez ajouter davantage de machines virtuelles à un niveau sans affecter la durée de fonctionnement des applications.
Pour plus d’informations sur la scalabilité, consultez la liste de contrôle d’efficacité des performances dans le Centre des architectures Azure.
Sécurité
Tout le trafic de réseau virtuel dans la couche Application front-end est protégé par des groupes de sécurité réseau. Des règles limitent le flux du trafic afin que seules les instances de machine virtuelle au niveau de la couche Application frontale puissent accéder à la couche Données principale. Aucun trafic Internet sortant n’est autorisé à partir de la couche métier ou de la couche base de données. Pour réduire l’encombrement de l’attaque, aucun port de gestion à distance directe n’est ouvert. Pour plus d’informations, consultez Groupes de sécurité réseau Azure.
Pour obtenir des conseils d’ordre général sur la conception de scénarios sécurisés, consultez la documentation sur la sécurité Azure.
Tarifs
La configuration de la reprise d’activité pour les machines virtuelles Azure à l’aide d’Azure Site Recovery entraîne les frais suivants en continu.
- Coût de licence Azure Site Recovery par machine virtuelle.
- Coût de sortie réseau pour répliquer les changements de données des disques de machine virtuelle sources sur une autre région Azure. Azure Site Recovery utilise la compression intégrée pour réduire les besoins de transfert de données d’environ 50 %.
- Coût de stockage sur le site de récupération. Ce coût est généralement le même que celui du stockage de la région source plus tout stockage supplémentaire nécessaire pour conserver les points de récupération sous forme d’instantanés pour la récupération.
Nous avons fourni un exemple de calculatrice des coûts afin de configurer la reprise d’activité pour une application à trois niveaux à l’aide de six machines virtuelles. Tous les services sont préconfigurés dans le calculateur de coût. Pour voir les tarifs dans votre cas d’usage en particulier, changez les variables appropriées pour estimer le coût.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Sujay Talasila | Responsable de produit principal
Étapes suivantes
- Déployer Traffic Manager dans Azure
- Configurer la récupération d’urgence pour les machines virtuelles Azure
Ressources associées
Pour d’autres architectures de référence en lien avec la haute disponibilité et la récupération d’urgence, consultez :