Haute disponibilité dans le MEC public Azure

Le Multi-Access Edge Computing (MEC) public Azure est une plateforme idéale pour héberger des applications à la périphérie et les rendre plus réactives, mais il ne prend actuellement pas en charge les fonctionnalités de haute disponibilité. Cet article décrit comment déployer des charges de travail en mode actif/veille pour obtenir la haute disponibilité et la reprise d’activité.

Apache®, Apache Ignite, Ignite et le logo de la flamme sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.

Architecture

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

Workflow

• Azure Traffic Manager. Configurez Traffic Manager pour utiliser le routage prioritaire. Définissez l’adresse IP de l’équilibreur de charge dans la région MEC public Azure (principale) sur Priorité 1. Définissez celle de la région secondaire sur Priorité 2. Cette configuration envoie tout le trafic vers le MEC public Azure dans les scénarios sans basculement.

  Notes

  Traffic Manager pour le MEC public Azure ne prend actuellement pas en charge le routage des performances, qui pourrait déterminer de façon dynamique le routage décrit précédemment en fonction de la plus petite latence sur le point de terminaison.

  Dans cette architecture, la restauration automatique s’effectue automatiquement après le retour en ligne des machines virtuelles et/ou de l’équilibreur de charge standard. Traffic Manager détermine que les charges de travail sont opérationnelles et reroute le trafic sur la région MEC public Azure principale.

• Équilibreur de charge public. Cet équilibreur de charge est situé avant la couche Application et équilibre le trafic sur le pool de machines virtuelles du groupe de machines virtuelles identiques.

• Équilibreur de charge interne. Cet équilibreur de charge est utilisé pour accéder à la couche Base de données. Selon le type de base de données que vous utilisez pour votre application, vous n’avez peut-être pas besoin d’un équilibreur de charge ici, en supposant que les autres services PaaS (platform as a service) ont leur propre équilibreur de charge.

• Azure Virtual Machine Scale Sets. La plupart des déploiements de production utilisent Virtual Machine Scale Sets pour mettre à l’échelle dynamiquement leurs charges de travail en fonction de la charge du trafic. Le MEC public Azure prend également en charge Azure Kubernetes Service pour les applications natives cloud et basées sur des conteneurs.

• Couche Base de données. Le MEC public Azure ne prend actuellement pas en charge les services PaaS SQL Database, comme SQL Server sur les machines virtuelles Azure et Azure SQL Managed Instance. Il ne prend pas non plus en charge les services PaaS NoSQL comme Azure Cosmos DB et Azure Managed Instance pour Apache Cassandra. Vous pouvez déployer des solutions tierces qui prennent en charge les services SQL ou NoSQL, ainsi que la réplication des données sur leurs clusters géodistribués.

Composants

• Le MEC public Azure est une solution de computing en périphérie qui regroupe un portefeuille de services Microsoft pour le calcul, les réseaux et les applications gérés à partir du cloud.
• Azure Traffic Manager est un équilibreur de charge de trafic DNS. Vous pouvez l’utiliser pour diriger les demandes DNS entrantes sur une méthode de routage que vous choisissez.
• Azure Load Balancer offre la haute disponibilité et des hautes performances pour vos applications.
• Azure Virtual Machine Scale sets vous permet de gérer et mettre à l’échelle des milliers de machines virtuelles.

Autres solutions

Sauvegarde et reprise d’activité Azure, qui fournit Azure Site Recovery et des fonctionnalités de sauvegarde :

• Réplique activement les machines virtuelles du MEC public Azure sur la région parente, et les rend disponibles pour le basculement et la restauration automatique en cas de panne.
• Sauvegarde les machines virtuelles pour empêcher l’altération ou la perte de données.

Cette approche a un coût inférieur par rapport à celle décrite précédemment, car il n’y a pas de ressources inactives. Cette alternative convient uniquement aux applications qui autorisent des RTO plus élevés.

Détails du scénario

Cas d’usage potentiels

Utilisez cette architecture quand vous voulez déployer des charges de travail en mode actif/veille pour obtenir la haute disponibilité et la reprise d’activité. Ce scénario est idéal pour le secteur des télécommunications.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Contrat SLA

Microsoft prend en charge les contrats de niveau de service (SLA) pour les infrastructures de plus grande taille, telles qu’Azure et les régions Azure. Azure MEC public est une extension d’empreinte plus petite d’Azure, et ne prend donc pas en charge de contrat SLA.

Performances

Le MEC public Azure est conçu afin d’héberger des applications pour lesquelles la latence est critique. Comme le basculement vers une région secondaire augmente la latence des charges de travail, il peut ne pas fournir le même niveau de performances. En fonction de l’application et de sa sensibilité à cette augmentation de latence, vous devez choisir les services, le cas échéant, qui doivent basculer vers la région.

Bases de données

La réplication et la sauvegarde des données sont importantes quand vous utilisez des basculements de base de données. La plupart des services Azure PaaS bénéficient d’une prise en charge intégrée de la géoréplication et de la création de réplicas en lecture dans différentes régions et zones géographiques.

Traffic Manager

Options de basculement

Traffic Manager prend en charge plusieurs méthodes de routage : selon les performances, la zone géographique, la priorité, etc. Pour mieux prendre en charge les applications à faible latence, envoyez dynamiquement les données à la région/le MEC public Azure les plus proches de l’utilisateur. Le routage des performances n’est actuellement pas pris en charge sur le MEC public Azure. La meilleure deuxième option est de hiérarchiser de manière statique la meilleure localisation pour une application.

Pour une application distribuée dans le monde entier qui a des charges de travail réparties sur plusieurs MEC publics et régions Azure, utilisez une méthode de routage imbriquée. Utilisez le routage géographique pour répartir le trafic sur la région appropriée, puis utilisez le routage prioritaire pour répartir encore le trafic.

Restauration automatique

Après la sauvegarde des charges de travail dans le MEC public Azure, les sondes Traffic Manager détectent qu’il peut prendre des demandes et rerouter automatiquement le trafic sur le MEC public Azure.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Le MEC public Azure est principalement utilisé dans les scénarios de calcul à faible latence en temps réel. Les données sont traitées par les instances de calcul qui s’exécutent dans le MEC public Azure. Cette architecture utilise un mode actif/veille avec un serveur de secours. Autrement dit, les charges de travail dans la région secondaire ne sont pas utilisées, sauf en cas de basculement.

Cette approche du déploiement des charges de travail sous forme de serveur de secours entraîne des frais de déploiement Azure, même si les charges de travail ne sont pas utilisées.

Pour plus d’informations sur les tarifs :

• Consultez la page Tarification Azure.
• Utilisez la Calculatrice de prix Azure pour estimer le coût de l’implémentation de cette solution.

Pour plus d’informations sur la création d’une charge de travail rentable, consultez Vue d’ensemble du pilier d’optimisation des coûts dans la documentation Azure Well-Architected Framework.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Adhip Gupta | Responsable de programme senior

Étapes suivantes

• MEC public Azure
• Qu’est-ce que Traffic Manager ?
• Qu’est-ce que Azure Load Balancer ?
• Que sont les groupes de machines virtuelles identiques ?

Ressources associées

• Déploiement du calcul de périphérie multi-accès public Azure
• Conception d’une architecture hybride
• Connexions réseau à faible latence pour l’industrie
• Capture vidéo et analytique pour la vente
• Connectivité d’appareils IoT pour établissements de santé