Tester des points de terminaison privés en déployant le Test de charge Azure dans un réseau virtuel Azure

Dans cet article, découvrez comment tester des points de terminaison d’application privés avec Azure Load Testing. Vous créez une ressource Azure Load Testing et vous l’activez pour générer la charge à partir de votre réseau virtuel (injection de réseau virtuel).

Cette fonctionnalité permet les scénarios d’utilisation suivants :

• Générez la charge sur un point de terminaison déployé dans un réseau virtuel Azure.
• Générez une charge sur un point de terminaison public avec des restrictions d’accès, comme la restriction des adresses IP du client.
• Générez la charge sur un service local, non accessible publiquement, qui est connecté à Azure via ExpressRoute.

En savoir plus sur les scénarios de déploiement du Test de charge Azure dans votre réseau virtuel.

Le schéma suivant donne un aperçu technique :

Lorsque vous démarrez le test de charge, le service 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.

Ces ressources sont éphémères et existent uniquement pendant l’exécution du test de charge. Si vous avez des restrictions sur le déploiement d’une adresse IP publique, d’un équilibreur de charge Azure ou d’un groupe de sécurité réseau dans votre sous-réseau, vous pouvez désactiver le déploiement de ces ressources. Pour plus d’informations, consultez Configurer votre test de charge.

Si vous limitez l’accès à votre réseau virtuel, vous devez configurer votre réseau virtuel pour permettre la communication entre ces tests de charge Azure et les machines virtuelles injectées.

Prérequis

• Votre compte Azure a le rôle Contributeur réseau ou parent de ce rôle sur le réseau virtuel. Consultez Vérifier l’accès d’un utilisateur aux ressources Azure pour vérifier vos autorisations.
• 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. En savoir plus sur la configuration de votre test pour une charge à grande échelle.
• Le sous-réseau ne doit pas être délégué à un autre service Azure. Par exemple, il ne doit pas être délégué à Azure Container Instances (ACI). En savoir plus sur la délégation de sous-réseau.
• Azure CLI version 2.2.0 ou ultérieure (si vous utilisez CI/CD). Exécutez az --version pour rechercher la version installée sur votre ordinateur local. Si vous devez installer ou mettre à niveau Azure CLI, consultez Installer Azure CLI 2.0.

Configurer un réseau virtuel

Pour tester des points de terminaison privés, vous connectez Azure Load Testing à un réseau virtuel Azure. Le réseau virtuel doit avoir au moins un sous-réseau et autoriser le trafic sortant vers le service Azure Load Testing.

Si vous n’avez pas encore de réseau virtuel, procédez comme suit pour créer un réseau virtuel Azure dans le Portail Azure.

Important

Le réseau virtuel doit se trouver dans le même abonnement et la même région que la ressource de test de charge.

Créer un sous-réseau

Lorsque vous déployez le Test de charge Azure dans votre réseau virtuel, il est recommandé d’utiliser des sous-réseaux séparés pour le Test de charge Azure et le point de terminaison de l’application. Cette approche vous permet de configurer spécifiquement les stratégies de l’accès au trafic réseau pour chaque objectif. En savoir plus sur l’ajout d’un sous-réseau à un réseau virtuel.

(Facultatif) Configurer des règles de trafic

Azure Load Testing nécessite que les machines virtuelles injectées dans votre réseau virtuel soient autorisées à accéder sortant au service Azure Load Testing. Par défaut, lorsque vous créez un réseau virtuel, l’accès sortant est déjà autorisé.

Si vous envisagez de restreindre davantage l’accès à votre réseau virtuel avec un groupe de sécurité réseau ou si vous disposez déjà d’un groupe de sécurité réseau, vous devez configurer une règle de sécurité sortante pour autoriser le trafic des machines virtuelles du moteur de test vers le service Azure Load Testing.

Pour configurer l’accès sortant pour le test de charge Azure :

1. Connectez-vous au portail Azure.

2. Accédez à votre groupe de sécurité réseau.

   Si vous n’avez pas encore de groupe de sécurité réseau, suivez ces étapes pour créer un groupe de sécurité réseau.

   Créez le groupe de sécurité réseau dans la même région que votre réseau virtuel et associez-le à votre sous-réseau.

3. Sélectionnez Règles de sécurité sortantes dans le volet de navigation de gauche.

   

4. Sélectionnez + Ajouter pour ajouter une nouvelle règle de sécurité sortante. Entrez les informations suivantes pour créer une règle.

   Champ	Valeur
   Source	N’importe lequel/laquelle
   Plages de ports source	*
   Destination	N’importe lequel/laquelle
   Plages de ports de destination	*
   Nom	azure-load-testing-outbound
   Description	Utilisé pour diverses opérations impliquées dans l’orchestration d’un test de charge.

5. Sélectionnez Ajouter pour ajouter la règle de sécurité sortante au groupe de sécurité réseau.

Configurer votre script de test de charge

Les machines virtuelles du moteur de test, qui exécutent le script JMeter, sont injectées dans le réseau virtuel qui contient le point de terminaison de l’application. Vous pouvez désormais faire référence directement au point de terminaison dans le fichier JMX à l’aide de l’adresse IP privée ou utiliser la résolution de noms dans votre réseau.

Par exemple, pour un point de terminaison avec l’adresse IP 10.179.0.7, dans un réseau virtuel avec une plage de sous-réseau 10.179.0.0/18, le fichier JMX peut avoir ces informations :

<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy" testname="Internal service homepage" enabled="true">
  <elementProp name="HTTPsampler.Arguments" elementType="Arguments" guiclass="HTTPArgumentsPanel" testclass="Arguments" testname="Service homepage" enabled="true">
    <collectionProp name="Arguments.arguments"/>
  </elementProp>
  <stringProp name="HTTPSampler.domain">10.179.0.7</stringProp>
  <stringProp name="HTTPSampler.port">8081</stringProp>
  <stringProp name="HTTPSampler.protocol"></stringProp>
  <stringProp name="HTTPSampler.contentEncoding"></stringProp>
  <stringProp name="HTTPSampler.path"></stringProp>
  <stringProp name="HTTPSampler.method">GET</stringProp>
</HTTPSamplerProxy>

Configurer votre test de charge :

Pour inclure des points de terminaison hébergés en privé dans votre test de charge, vous devez configurer les paramètres du réseau virtuel pour le test de charge. Vous pouvez configurer les paramètres de réseau virtuel dans le Portail Azure, ou les spécifier dans le fichier de configuration de test YAML pour les pipelines CI/CD.

Important

Lorsque vous déployez le test de charge Azure dans un réseau virtuel, vous aurez des frais supplémentaires. Le Test de charge Azure déploie un Azure Load Balancer et une adresse IP publique dans votre abonnement, et il peut y avoir un coût pour le trafic généré. Pour plus d’informations, consultez les Informations de tarification des réseaux virtuels.

Configurer le réseau virtuel dans le Portail Azure

Vous pouvez spécifier les paramètres de configuration du réseau virtuel dans l’Assistant Création/mise à jour du test de charge.

1. Connectez-vous au Portail Azure à l’aide des informations d’identification de votre abonnement Azure.

2. Accédez à votre ressource de Test de charge Azure, puis, dans le volet gauche, sélectionnez Tests.

3. Ouvrez l’Assistant Création/mise à jour du test de charge de deux façons :

   • Sélectionnez + Créer > un script JMeter, si vous souhaitez créer un nouveau test.

     

   • Sélectionnez un test existant à partir de la liste, puis sélectionnez Modifier.

     

4. Sous l’onglet Charger, sélectionnez le mode de trafic Privé, puis votre réseau virtuel et votre sous-réseau.

   Si vous avez plusieurs sous-réseaux dans votre réseau virtuel, veillez à sélectionner le sous-réseau qui hébergera les machines virtuelles du moteur de test injecté.

   

   Important

   Vérifiez que vous disposez des autorisations suffisantes pour gérer des réseaux virtuels. Vous avez besoin du rôle de Contributeur de réseau.

5. (Facultatif) Activez la case à cocher Désactiver le déploiement d’adresses IP publiques si vous ne souhaitez pas déployer d’adresse IP publique, d’équilibreur de charge et de groupe de sécurité réseau dans votre sous-réseau.

   Lorsque vous sélectionnez cette option, vérifiez qu’il existe un autre mécanisme comme la passerelle NAT Azure, Pare-feu Azure ou une appliance virtuelle réseau (NVA) pour activer le routage du trafic sortant à partir du sous-réseau.

6. Passez en revue ou remplissez les informations de test de charge. Suivez ces étapes pour créer ou gérer un test.

7. Sélectionnez Vérifier + créer, puis Créer (ou Appliquer, lors de la mise à jour d’un test existant).

   Lorsque le test de charge démarre, le Test de charge Azure injecte les machines virtuelles du moteur de test dans votre réseau virtuel et votre sous-réseau. Le script de test peut désormais accéder au point de terminaison d’application hébergé en privé dans votre réseau virtuel.

Configurer le réseau virtuel pour les pipelines CI/CD

Pour configurer le test de charge avec vos paramètres de réseau virtuel, mettez à jour le fichier de configuration du test YAML.

1. Ouvrez un terminal et utilisez Azure CLI pour vous connecter à votre abonnement Azure :

   az login
   az account set --subscription <your-Azure-Subscription-ID>
   

2. Récupérez l’ID de sous-réseau et copiez la valeur résultante :

   az network vnet subnet show -g <your-resource-group> --vnet-name <your-vnet-name> --name <your-subnet-name> --query id
   

3. Ouvrez votre fichier de configuration de test YAML dans votre éditeur favori.

4. Ajoutez la propriété subnetId au fichier de configuration et fournissez l’ID de sous-réseau que vous avez copié précédemment :

   version: v0.1
   testName: SampleTest
   testPlan: SampleTest.jmx
   description: 'Load test the website home page'
   engineInstances: 1
   subnetId: <your-subnet-id>
   publicIPDisabled: False
   

   Si vous le souhaitez, vous pouvez définir la publicIPDisabled propriété sur True. Pour plus d’informations sur la configuration YAML, consultez la documentation de référence YAML sur la configuration de test.

   Important

   Vérifiez que vous disposez des autorisations suffisantes pour gérer des réseaux virtuels. Vous avez besoin du rôle de Contributeur de réseau.

5. Enregistrez le fichier de configuration YAML et validez vos modifications dans le référentiel de code source.

6. Une fois le flux de travail CI/CD déclenché, votre test de charge démarre et peut désormais accéder au point de terminaison d’application hébergé en privé dans votre réseau virtuel.

Dépannage

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.

   Exécutez la commande Azure CLI suivante pour vérifier l’état. 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, vérifiez à nouveau 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 azure Load Testing 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.

   Exécutez la commande Azure CLI suivante pour vérifier l’état. 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.

   Exécutez la commande Azure CLI suivante pour vérifier l’état. 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, vérifiez à nouveau 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 Inbound not allowed from AzureLoadTestingInstanceManagement service tag (ALTVNET008)

L’accès entrant depuis l’étiquette de service AzureLoadTestingInstanceManagement vers le réseau virtuel n’est pas autorisé.

Procédez comme suit pour activer l’accès au trafic pour l’étiquette de service AzureLoadTestingInstanceManagement.

La création ou la mise à jour du test de charge échoue avec Inbound not allowed from BatchNodeManagement service tag (ALTVNET009)

L’accès entrant depuis l’étiquette de service BatchNodeManagement vers le réseau virtuel n’est pas autorisé.

Procédez comme suit pour activer l’accès entrant pour l’étiquette de service BatchNodeManagement.

La création ou la mise à jour du test de charge échoue avec Route Table has next hop set for address prefix 0.0.0.0/0

La table de routage de votre sous-réseau a le type de tronçon suivant défini sur Appliance virtuelle pour la route 0.0.0.0/0. Cette configuration entraînerait un routage asymétrique pour les paquets réseau lors du provisionnement des machines virtuelles dans le sous-réseau.

Effectuez l’une des deux actions suivantes pour résoudre cette erreur :

• Utilisez un sous-réseau différent qui n’a pas de routes personnalisées.
• Modifiez la table de routage du sous-réseau et définissez le type de tronçon suivant pour la route 0.0.0.0/0 sur Internet.

Apprenez-en davantage sur le routage du trafic de réseau virtuel.

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, de l’équilibreur de charge Azure ou du 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.

   Exécutez la commande Azure CLI suivante pour vérifier l’état. 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, vérifiez à nouveau 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 le réseau virtuel, le service ne peut pas injecter les machines virtuelles du moteur de test dans votre réseau virtuel. Supprimez le verrou de gestion avant d’exécuter 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, Azure Load Testing injecte les ressources Azure suivantes dans le réseau virtuel qui contient le point de terminaison de l’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 disposez d’un 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 le test de charge Azure. Sélectionnez un autre sous-réseau pour votre test de charge.

Étapes suivantes

• En savoir plus sur les scénarios de déploiement du Test de charge Azure dans un réseau virtuel.
• Découvrez comment Surveiller les métriques d’application côté serveur.