Partage via


Résoudre des problèmes d’exécution de tests de charge sur des points de terminaison privés.

Cet article aborde les problèmes pouvant éventuellement se produire lorsque vous exécutez vos tests de charge sur des points de terminaison d’application privés en utilisant Test de charge Azure. Le service Test de charge Azure injecte les ressources Azure requises pour générer une charge dans le réseau virtuel qui contient le point de terminaison d’application. Lors de ce processus, il est possible que vous rencontriez des problèmes liés à la configuration de réseau virtuel et aux autorisations de contrôle d’accès en fonction du rôle (RBAC).

Le service Test de charge Azure nécessite une connectivité sortante à partir du réseau virtuel vers les destinations suivantes.

Destination Besoin pour la connectivité
*.azure.com L’accès à cette destination est requis pour que le service Test de charge Azure communique avec le service Azure Batch.
*.windows.net L’accès à cette destination est requis pour que le service Test de charge Azure communique avec Azure Service Bus, Azure Event Grids et Stockage Azure. Pour découvrir plus d’informations sur la configuration du pare-feu dans ces services, consultez
  • Forum Aux Questions (FAQ) sur Azure Service Bus
  • Règles de pare-feu Azure Event Hubs
  • Configurer des pare-feux et des réseaux virtuels dans Stockage Azure
  • *.azurecr.io L’accès à cette destination est requis pour que le service Test de charge Azure communique avec Azure Container Registry. Pour découvrir plus d’informations sur la configuration du pare-feu dans Azure Container Registry, consultez
  • Règles de pare-feu – Azure Container Registry
  • Le cas échéant, la connectivité sortante est nécessaire pour que *.maven.org et *.github.com télécharge les plug-ins inclus dans votre configuration de test.

    Remarque

    Pour les régions Azure Government, vérifiez la connectivité sortante à *.azure.us, *.usgovcloudapi.net et *.azurecr.us. Pour plus d'informations sur les points de terminaison d'Azure Government, voir Conseils aux développeurs.

    Résoudre des problèmes de connectivité à partir du réseau virtuel en déployant une machine virtuelle Azure

    Pour tester la connectivité de votre réseau virtuel :

    1. Créez une machine virtuelle avec une IP publique dans le sous-réseau que vous utilisez dans la configuration de votre test dans Test de charge Azure. Cette machine virtuelle est uniquement utilisée pour diagnostiquer la connectivité réseau et peut être supprimée après la résolution des problèmes. Le service Test de charge Azure n’utilise pas cette machine virtuelle pour générer une charge.

      Exécutez la commande Azure CLI suivante pour créer une machine virtuelle.

      az vm create --resource-group <your-resource-group> --name <your-virtual-machine-name> --image UbuntuLTS --generate-ssh-keys --subnet <your-subnet>
      

      La machine virtuelle peut être de n’importe quel type.

    2. Connectez-vous à la machine virtuelle en utilisant Azure Bastion.

    3. Testez la connectivité sortante à partir de la machine virtuelle vers azure.com

      • Pour valider la recherche DNS (Domain Name System), exécutez la commande suivante

        nslookup azure.com
        

        Une réponse avec des adresses IP associées à azure.com indique une connexion réussie.

        Capture d’écran montrant une réponse réussie pour la validation DNS.

      • Pour valider la connectivité à « azure.com », exécutez la commande suivante

        curl azure.com -I
        

        Une réponse HTTP indique une connectivité réussie.

        Capture d’écran montrant une réponse réussie pour la validation de la connectivité.

      1. Répétez l’étape 3 pour « windows.net » et « azurecr.io » pour valider la recherche DNS et la connectivité vers ces destinations.

    Vous pouvez également utiliser une autre approche pour veiller à la connectivité à partir du sous-réseau vers *.azure.com, *.windows.net et *.azurecr.io.

    Pendant que vous effectuez les tests de connectivité, vous pouvez rencontrer des problèmes en raison des contraintes d’une stratégie ou de restrictions du pare-feu. Suivez les messages d’erreur pour prendre toute action corrective requise et effectuer une nouvelle tentative des tests de connectivité.

    Résoudre des problèmes en utilisant les messages d’erreur actionnables

    La création ou la mise à jour du test de charge échoue avec Subscription not registered with Microsoft.Batch (ALTVNET001)

    Quand vous configurez un test de charge dans un réseau virtuel, l’abonnement doit être inscrit auprès de Microsoft.Batch.

    1. Réessayez de créer ou de mettre à jour le test de charge après quelques minutes.

    2. Si l’erreur persiste, procédez comme suit pour inscrire votre abonnement manuellement auprès du fournisseur de ressources Microsoft.Batch.

    La création ou la mise à jour du test de charge échoue avec Subnet is not in the Succeeded state (ALTVNET002)

    Le sous-réseau que vous utilisez pour le test de charge n’est pas dans l’état Succeeded et n’est pas prêt à y déployer votre test de charge.

    1. Vérifiez l’état du sous-réseau.

      Pour vérifier l’état, exécutez la commande Azure CLI suivante. Le résultat devrait être Succeeded.

      az network vnet subnet show -g MyResourceGroup -n MySubnet --vnet-name MyVNet
      
    2. Résolvez les éventuels problèmes liés au sous-réseau. Si vous venez de créer le sous-réseau, revérifiez l’état après quelques minutes.

    3. Vous pouvez aussi sélectionner un autre sous-réseau pour le test de charge.

    La création ou la mise à jour du test de charge échoue avec Subnet is delegated to other service (ALTVNET003)

    Le sous-réseau que vous utilisez pour déployer le test de charge ne peut pas être délégué à un autre service Azure. Supprimez la délégation existante ou sélectionnez un autre sous-réseau qui n’est pas délégué à un service.

    En savoir plus sur l’ajout ou la suppression d’une délégation de sous-réseau.

    La mise à jour ou le démarrage du test de charge échoue avec User doesn't have subnet/join/action permission on the virtual network (ALTVNET004)

    Pour mettre à jour ou démarrer un test de charge, vous devez disposer des autorisations suffisantes pour déployer Test de charge Azure sur le réseau virtuel. Vous avez besoin du rôle Contributeur réseau ou d’un parent de ce rôle sur le réseau virtuel.

    1. Consultez Vérifier l’accès d’un utilisateur aux ressources Azure pour vérifier vos autorisations.

    2. Procédez comme suit pour attribuer le rôle Contributeur réseau à votre compte.

    La création ou la mise à jour du test de charge échoue avec IPv6 enabled subnet not supported (ALTVNET005)

    Test de charge Azure ne prend pas en charge les sous-réseaux où IPv6 est activé. Sélectionnez un autre sous-réseau pour lequel IPv6 n’est pas activé.

    La création ou la mise à jour du test de charge échoue avec NSG attached to subnet is not in Succeeded state (ALTVNET006)

    Le groupe de sécurité réseau attaché au sous-réseau n’est pas dans l’état Succeeded.

    1. Vérifiez l’état du groupe de sécurité réseau.

      Pour vérifier l’état, exécutez la commande Azure CLI suivante. Le résultat devrait être Succeeded.

      az network nsg show -g MyResourceGroup -n MyNsg
      
    2. Résolvez les éventuels problèmes liés au groupe de sécurité réseau. Si vous venez de créer le groupe de sécurité réseau, revérifiez l’état après quelques minutes.

    3. Vous pouvez aussi sélectionner un autre groupe de sécurité réseau.

    La création ou la mise à jour du test de charge échoue avec Route Table attached to subnet is not in Succeeded state (ALTVNET007)

    La table de routage attachée au sous-réseau n’est pas dans l’état Succeeded.

    1. Vérifiez l’état de la table de routage.

      Pour vérifier l’état, exécutez la commande Azure CLI suivante. Le résultat devrait être Succeeded.

      az network route-table show -g MyResourceGroup -n MyRouteTable
      
    2. Résolvez les éventuels problèmes liés à la table de routage. Si vous venez de créer la table de routage ou le sous-réseau, revérifiez l’état après quelques minutes.

    3. Vous pouvez aussi sélectionner une autre table de routage.

    La création ou la mise à jour du test de charge échoue avec Subnet is in a different subscription than resource (ALTVNET011)

    Le réseau virtuel n’est pas dans le même abonnement et la même région que votre ressource de test de charge Azure. Déplacez ou recréez le réseau virtuel Azure ou la ressource de test de charge Azure dans le même abonnement et la même région.

    Échec du provisionnement avec An azure policy is restricting engine deployment to your subscription (ALTVNET012)

    Une stratégie Azure limite le déploiement du moteur de test de charge à votre abonnement. Vérifiez les restrictions de votre stratégie, puis réessayez. Si vous avez des restrictions de stratégie sur le déploiement de l’adresse IP publique, l’équilibreur de charge Azure ou le groupe de sécurité réseau, vous pouvez désactiver le déploiement de ces ressources. Consultez Configurer votre test de charge.

    Échec du provisionnement avec Engines could not be deployed due to an error in subnet configuration (ALTVNET013)

    Les instances du moteur de test de charge n’ont pas pu être déployées en raison d’une erreur dans la configuration du sous-réseau. Vérifiez la configuration de votre sous-réseau. Si le problème persiste, ouvrez un ticket auprès du support en indiquant l’ID d’exécution du test.

    1. Vérifiez l’état du sous-réseau.

      Pour vérifier l’état, exécutez la commande Azure CLI suivante. Le résultat devrait être Succeeded.

      az network vnet subnet show -g MyResourceGroup -n MySubnet --vnet-name MyVNet
      
    2. Résolvez les éventuels problèmes liés au sous-réseau. Si vous venez de créer le sous-réseau, revérifiez l’état après quelques minutes.

    3. Si le problème persiste, ouvrez une demande de support client en ligne.

      Spécifiez l’ID d’exécution du test de charge dans la demande de support.

    Le démarrage du test de charge échoue avec Subnet has {0} free IPs, {1} more free IP(s) required to run {2} engine instance load test (ALTVNET014)

    Le sous-réseau que vous utilisez pour le Test de charge Azure doit avoir suffisamment d’adresses IP non attribuées pour prendre en charge le nombre de moteurs de test de charge pour votre test.

    Suivez ces étapes pour mettre à jour les paramètres du sous-réseau et augmenter la plage d’adresses IP.

    Le démarrage du test de charge échoue avec Management Lock is enabled on Resource Group of VNET (ALTVNET015)

    S’il existe un verrou sur le groupe de ressources qui contient la machine virtuelle, le service ne peut pas injecter les machines virtuelles de moteur test dans votre réseau virtuel. Supprimez le verrou de gestion avant d’effectuer le test de charge. Découvrez comment configurer des verrous dans le Portail Azure.

    Le démarrage du test de charge échoue avec Insufficient public IP address quota in VNET subscription (ALTVNET016)

    Lorsque vous démarrez le test de charge, Test de charge Azure injecte les ressources Azure suivantes dans le réseau virtuel qui contient le point de terminaison d’application :

    • Machines virtuelles du moteur de test. Ces machines virtuelles appellent votre point de terminaison d’application pendant le test de charge.
    • Adresse IP publique.
    • Un groupe de sécurité réseau (NSG).
    • Une instance Azure Load Balancer.

    Vérifiez que vous avez le quota pour au moins une adresse IP publique disponible dans votre abonnement à utiliser dans le test de charge.

    Le démarrage du test de charge échoue avec Subnet with name "AzureFirewallSubnet" cannot be used for load testing (ALTVNET017)

    Le sous-réseau AzureFirewallSubnet est réservé et vous ne pouvez pas l’utiliser pour Test de charge Azure. Sélectionnez un autre sous-réseau pour votre test de charge.

    Étapes suivantes