Considérations relatives au déploiement dans Azure MEC public
Les sites Azure Multi-Access Edge Compute (MEC) public sont des extensions Azure qui ont une petite empreinte mémoire. Ils sont placés à l’intérieur ou à proximité de centres de données d’opérateurs mobiles dans des zones métropolitaines, et sont conçus pour exécuter des charges de travail qui nécessitent une faible latence lors de leur attachement au réseau mobile. Cet article se concentre sur les points que les clients doivent envisager avant de déployer des applications dans Azure MEC public.
Prérequis
Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Ajoutez un abonnement sur liste d’autorisation à votre compte Azure, ce qui vous permet de déployer des ressources dans Azure MEC public. Si vous n’avez pas d’abonnement autorisé actif, contactez l’équipe produit d’Azure MEC public.
Bonnes pratiques
Pour Azure MEC public, suivez les bonnes pratiques suivantes :
Déployez dans Azure MEC public uniquement les composants d’application qui sont sensibles à la latence ou qui nécessitent un calcul à faible latence sur Azure MEC public. Déployez dans la région Azure parente les composants d’application qui exécutent le plan de contrôle et les fonctionnalités du plan de gestion.
Pour accéder aux machines virtuelles déployées dans le réseau virtuel Azure public, déployez des machines virtuelles ou Azure Bastion dans un réseau virtuel dans la région parente.
Pour les ressources de calcul dans Azure MEC public, déployez Azure Key Vault dans la région Azure pour fournir des services de gestion des secrets et des clés.
Utilisez le peering de réseaux virtuels entre les réseaux virtuels d’Azure MEC public et les réseaux virtuels dans la région parente. Les ressources IaaS peuvent communiquer en privé via le réseau Microsoft et n’ont pas besoin d’accéder à l’Internet public.
Architecture d’Azure MEC public
Déployez des composants d’application qui nécessitent une faible latence dans Azure MEC public et les composants qui moins sensibles à la latence dans la région Azure. Pour plus d’informations, consultez Déploiement Azure Multi-Access Edge Compute public.
Région Azure
La région Azure doit exécuter les composants de l’application qui effectuent les fonctions de contrôle et de plan de gestion et ne sont pas sensibles à la latence.
Les sections suivantes vous montrent quelques exemples.
Stockage et base de données Azure
- Bases de données Azure : Azure SQL, Azure Database pour MySQL, etc.
- Comptes de stockage
- Stockage Blob Azure
IA et analyse
- Azure Machine Learning Services
- Services d’analytique Azure
- Power BI
- Azure Stream Analytics
Services d’identité
- Microsoft Entra ID
Gestion des secrets
- Azure Key Vault
MEC public Azure
Azure MEC public doit exécuter les composants qui sont sensibles à la latence et nécessitent des temps de réponse plus rapides des ressources de calcul. Pour ce faire, exécutez votre application sur les services de calcul, comme les machines virtuelles Azure et le service Azure Kubernetes dans MEC public.
Disponibilité et résilience
Les applications que vous déployez dans Azure MEC public peuvent être rendues disponibles et résilientes à l’aide des méthodes suivantes :
Déployer des ressources en mode actif/de secours, avec les ressources principales dans Azure MEC public et celles de secours dans la région Azure parente. En cas de défaillance dans Azure MEC public, les ressources de la région parente deviennent actives.
Utilisez la solution de sauvegarde et récupération d’urgence Azure, qui fournit Azure Site Recovery et les fonctionnalités de la sauvegarde Azure. Cette solution :
- Réplique activement les machines virtuelles d’Azure MEC public vers 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 la corruption ou la perte de données.
Remarque
La solution de sauvegarde et de récupération d’urgence Azure pour Azure MEC public ne prend en charge que les machines virtuelles Azure.
Il y a un compromis entre la disponibilité et la latence. Même si le basculement de l’application depuis Azure MEC public vers la région Azure garantit que l’application est disponible, cela peut augmenter la latence de l’application.
Concevez vos applications de périphérie en utilisant la région Azure pour les composants qui sont moins sensibles à la latence, doivent être persistants ou doivent être partagés entre les sites MEC publics. Cela permettra aux applications d’être plus résilientes et rentables. Le MEC public peut héberger les composants sensibles à la latence.
Résidence des données
Important
Azure public MEC ne stocke pas ni ne traite les données client en dehors de la région dans laquelle vous déployez l’instance de service.
Étapes suivantes
Pour déployer une machine virtuelle dans Azure MEC public à l’aide d’un modèle Azure Resource Manager (ARM), passez à l’article suivant :