VENTES: 1-800-867-1389

Exécution de tests de charge dans des environnements mixtes

Cette rubrique traite de l'exécution des tests de charge de Visual Studio dans un environnement mixte. Un « environnement mixte » est un environnement dans lequel les composants du test de charge sont hébergés dans différents contextes, tels que sur site, ou en tant que rôles de travail Windows Azure. Par exemple, un environnement mixte correspond à un environnement où les agents de test s'exécutent sur site et dans lequel le référentiel de données se trouve sur un serveur Base de données SQL Windows Azure. Ce comportement diffère du système décrit dans Vue d'ensemble des tests de charge Visual Studio dans Windows Azure. Dans cette rubrique, tous les composants, à l'exception de la station de travail, sont exécutés en tant que rôles de travail Windows Azure.

L'exécution du test de charge dans ces environnements mixtes peut être nécessaire pour des raisons réglementaires ou spécifiques à votre application. Quoi qu'il en soit, cette rubrique traite des choix dont vous disposez et de la manière de configurer des scénarios aussi divers.

Auteurs : Jaimie Alva Bravo, Sidney Higa, Paolo Salvatori.

Télécharger

Les fichiers requis pour ces procédures se trouvent ici : VSLoadTestInMixedEnvironments

Concurrence

L'un des facteurs utilisés dans la pondération des différentes configurations est la concurrence accrue due à l'exécution de nombreux processus dans un centre de données de grande envergure. La concurrence est définie comme une propriété du système où plusieurs tâches s'exécutent simultanément, et interagissent éventuellement les unes avec les autres. Un facteur qui limite la concurrence est le nombre d'adresses IP disponibles. Plus le système doit gérer d'adresses IP, plus le traitement concurrentiel s'accroît. En général, le nombre d'adresses disponibles dépend de la taille de votre fournisseur IP. Si votre contrat de qualité de service est substantiel, il bénéficie généralement d'un grand nombre d'adresses IP. Mais de tels contrats ne sont pas courants. Toutefois, lorsque vous utilisez Windows Azure comme plateforme, vous avez l'avantage d'utiliser un centre de données Microsoft et ses ressources. Vous disposez ainsi d'un pool d'adresses IP important. Les services hébergés dans Windows Azure reçoivent des adresses IP virtuelles. Dans cette discussion, les adresses IP sont utilisées par le programme d'équilibrage de charge à l'extérieur (Internet) (et non par les services hébergés). Le fait de disposer d'un grand nombre d'adresses IP est un avantage qu'offre le centre de données Microsoft. Notez également que tous les systèmes ne nécessitent pas ce niveau de concurrence.

Cette possibilité accrue de concurrence est un autre avantage important de l'exécution de tests de charge dans Windows Azure. Il est également très difficile de reproduire ce niveau de concurrence en dehors d'un grand centre de données.

Facteurs

Il existe six facteurs qui ont une incidence sur la concurrence. Les deux premiers facteurs sont les contextes où vous effectuez le test de charge : cloud et sur site.

  • Sur site

  • Nuage

Les quatre autres facteurs sont les composants du test de charge. Il s'agit des facteurs suivants :

  • Contrôleur de test

  • Agents de test

  • Référentiel de résultats

  • Système testé

Les quatre composants sont illustrés ici :

Facteurs Testez la charge

Dans le graphique, les largeurs relatives des lignes représentent la quantité de données transférées ; plus la ligne est épaisse, plus la quantité de données est importante. Le transfert de données le plus important se produit entre le contrôleur de test et le référentiel de résultats. La charge la plus légère se produit entre le système testé et le contrôleur. (Toutefois, la charge réelle dépend de la quantité d'enregistrements consignés par le système testé.) Pour référence, consultez le graphique dans Vue d'ensemble des tests de charge Visual Studio dans Windows Azure.

noteRemarque
Par souci de clarté, le graphique suppose que la station de travail qui héberge Visual Studio héberge également le contrôleur de test. Cette configuration facilite la communication entre Visual Studio et le contrôleur de test. Pendant un test de charge, le contrôleur transmet en continu de gros volumes de données vers Visual Studio pour l'analyse des performances en temps réel.

Topologies

Compte tenu des quatre composants et des deux contextes, plusieurs options topologiques se dessinent. Les quatre composants du test de charge peuvent exister dans l'un ou l'autre contexte. Par exemple, les deux topologies les plus simples sont décrites ici.

  1. Tous les composants sur le cloud.

  2. Tous les composants sur site.

Par souci de clarté, les deux options les plus simples sont illustrées dans ce tableau.

 

Contrôleur Agents Référentiel Système testé Remarques

Sur site

Sur site

Sur site

Sur site

Concurrence réduite, pas de trafic réseau en dehors du site.

Nuage

Nuage

Nuage

Nuage

Concurrence plus grande (plus d'adresses IP) et pas de trafic réseau en dehors du cloud.

Maintenant, les topologies sont plus compliquées. Pour simplifier, ce tableau montre une division principale. Dans ce tableau, le contrôleur s'exécute sur site.

Le trafic des agents vers le système testé n'est pas pris en compte, car il est censé faire partie de tout coût de test. Notez également que le trafic réseau dans les tableaux suivants présente un coût monétaire. Vous êtes facturé pour les données transférées hors du centre de données. Le trafic interne n'est pas facturé. Pour plus d'informations sur la facturation, consultez Détails de facturation et recherchez la rubrique relative aux transferts de données mesurés en Go.

Le tableau suivant illustre un point de fractionnement important : lorsque le contrôleur de test s'exécute sur site. Dans ce cas, le trafic entre les composants doit franchir la limite, avec des niveaux de conséquences variés, en fonction du composant et de son niveau de « verbosité ».

Le contrôleur s'exécute sur site

Contrôleur Agents Référentiel Système testé Remarques

Sur site

Sur site

Sur site

Nuage

Concurrence réduite, trafic réseau du système testé vers le contrôleur.

Sur site

Sur site

Nuage

Sur site

Concurrence réduite, trafic réseau du contrôleur vers le référentiel.

Sur site

Sur site

Nuage

Nuage

Concurrence réduite, trafic réseau du système testé vers le contrôleur, puis retour vers le référentiel.

Sur site

Nuage

Sur site

Sur site

Concurrence plus grande, trafic réseau des agents vers le contrôleur.

Sur site

Nuage

Sur site

Nuage

Concurrence plus grande, trafic réseau des agents et du système testé vers le contrôleur.

Sur site

Nuage

Nuage

Sur site

Concurrence plus grande, trafic réseau des agents vers le contrôleur et retour vers le référentiel.

Sur site

Nuage

Nuage

Nuage

Concurrence plus grande, trafic réseau de l'agent et du système testé vers le contrôleur et retour vers le référentiel.

Ce tableau montre la deuxième division principale. Dans ce tableau, le contrôleur s'exécute sur le cloud.

Le contrôleur s'exécute sur le cloud

Contrôleur Agents Référentiel Système testé Remarques

Nuage

Sur site

Sur site

Sur site

Concurrence réduite, trafic réseau de l'agent et du système de test vers le contrôleur et retour vers le référentiel.

Nuage

Sur site

Sur site

Nuage

Concurrence réduite, trafic réseau de l'agent vers le contrôleur et retour vers le référentiel.

Nuage

Sur site

Nuage

Sur site

Concurrence réduite, trafic réseau de l'agent et du système de test vers le contrôleur.

Nuage

Nuage

Nuage

Nuage

Concurrence plus grande, trafic réseau des agents vers le contrôleur.

Nuage

Nuage

Sur site

Sur site

Concurrence plus importante, trafic réseau du système testé vers le contrôleur et retour vers le référentiel.

Nuage

Nuage

Sur site

Nuage

Concurrence plus importante, trafic réseau du contrôleur vers le référentiel.

Nuage

Nuage

Nuage

Sur site

Concurrence plus grande, trafic réseau du système testé vers le contrôleur.

Nuage

Plusieurs clouds

Nuage

Nuage

Concurrence la plus grande, au moins du système testé dans DC1 vers le contrôleur dans DC2 (probablement plus, selon l'installation).

Recommandations

Les topologies sont illustrées par souci d'exhaustivité. Le choix d'une topologie peut ne pas vous correspondre. Par exemple, si vous avez besoin de plus de 100 Go de stockage de données SQL Server, vous devez les stocker sur site ; actuellement, 100 Go représentent la limite de Base de données SQL. Toutefois, si vous avez une certaine marge de manœuvre, voici les meilleures topologies. Ces recommandations sont plus efficaces et offrent les niveaux de concurrence les plus élevés dans les deux divisions principales (contrôleur sur site ou contrôleur sur le cloud).

Idéal lorsque le contrôleur s'exécute sur site

Contrôleur Agents Référentiel Système testé Remarques

Sur site

Nuage

Sur site

Sur site

Concurrence plus grande, trafic réseau des agents vers le contrôleur.

Sur site

Nuage

Sur site

Nuage

Concurrence plus grande, trafic réseau des agents et du système testé vers le contrôleur.

Idéal lorsque le contrôleur s'exécute dans le cloud

Contrôleur Agents Référentiel Système testé Remarques

Nuage

Sur site

Nuage

Sur site

Concurrence réduite, trafic réseau de l'agent et du système de test vers le contrôleur.

Nuage

Nuage

Nuage

Nuage

Concurrence plus grande, trafic réseau des agents vers le contrôleur.

Nuage

Plusieurs clouds

Nuage

Nuage

La plus grande concurrence, au moins du système testé dans DC1 vers le contrôleur dans DC2 (probablement plus, selon l'installation).

Augmentation des exigences de complexité

En réalité, la disposition réelle de vos composants peut être complexe. Un système en cours de test peut compter de nombreux sous-composants, chacun s'exécutant en tant que rôle de travail ou rôle Web, ou utilisant les services sur site. Par exemple, un composant initialise le système ou fournit des services de validation. Il est probable que la plupart des composants doivent communiquer avec d'autres parties du système. Cet ensemble de composants s'ajoute au système de test de charge proprement dit (lui-même composé du contrôleur, des agents et du référentiel). Le graphique suivant illustre un système qui contient plusieurs parties. Il ne sert qu'à illustrer le fait qu'une vraie solution peut comporter un grand nombre de composants et impliquer plusieurs conditions de communication. Les détails du système ne sont pas le sujet majeur.

Exemple de configuration complexe

Compte tenu de cette complexité, il est toujours possible de localiser des composants dans Windows Azure ou sur site, si nécessaire. La section suivante présente les étapes nécessaires.

Programme d'installation

Ici, la configuration consiste en un ensemble de méthodes pouvant être utilisées en lieu et place de la configuration de base décrite dans ce document : Mise en service de Windows Azure en vue d'un test de charge. Les procédures décrites ici spécifient comment configurer le portail de gestion avec les éléments corrects. Par exemple, on y explique comment configurer un compte de stockage et comment installer un groupe Connect de Windows Azure.

La première solution ici vous permet d'utiliser Base de données SQL en tant que référentiel de résultats. La deuxième solution indique comment configurer des points de terminaison sur chaque rôle de travail. Les points de terminaison permettent la communication entre les agents, le système testé, le contrôleur de test, et (si nécessaire) un facteur auxiliaire, la station de travail qui héberge Visual Studio. Dans le mode le plus épuré, l'ordinateur se trouve sur site. Mais si votre application vous demande de l'utiliser lors de l'exécution du test, il peut également être hébergé en tant que rôle de travail Windows Azure.

Configuration requise

Les étapes suivantes sont nécessaires :

  • Téléchargez le fichier LoadTest2010.bacpac.

  • Facultatif. Installez Visual Studio 2010 Ultimate sur un rôle de travail.

    Si vous envisagez d'exécuter le contrôleur de test sur un rôle de travail, installez Microsoft Visual Studio 2010 Ultimate sur le rôle de travail. Ajoutez un rôle de travail au projet Windows Azure dans Visual Studio. Vérifiez que Bureau à distance est activé. Ajoutez le rôle de travail dans un groupe Connect pour la connexion à votre emplacement sur site. Utilisez le bureau à distance pour vous connecter au rôle de travail, puis installez Microsoft Visual Studio 2010 Ultimate.

Utilisation d'un fichier SQL BACPAC pour mettre en service Base de données SQL Windows Azure

Utilisez cette méthode pour stocker les résultats dans Base de données SQL, ainsi que les données de test de charge. Téléchargez le fichier nommé LoadTest2010.bacpac dans votre compte de stockage Azure. Vous devez également disposer des éléments suivants :

  1. Compte Base de données SQL.

  2. Instance de serveur SQL créée dans un abonnement. Pour plus d'informations, consultez Procédure de création d'un serveur de base de données SQL Windows Azure.

  3. Un nom de connexion et un mot de passe disposant de l'autorisation de modifier l'instance de serveur.

Pour mettre en service Base de données SQL avec un fichier BACPAC

  1. Téléchargez le fichier LoadTest2010.bacpac dans votre compte de stockage Azure.

    Utilisez StorageServicesSmartClient pour télécharger le fichier vers un conteneur public. Une fois le fichier .dacpac téléchargé, vous pouvez utiliser la fonction d'importation du portail de gestion pour créer la base de données.

  2. Dans le portail de gestion, cliquez sur Base de données.

  3. Développez l'abonnement qui contient le serveur Base de données SQL que vous utilisez, puis sélectionnez le serveur.

  4. Dans la section Base de données du ruban, cliquez sur Importer.

  5. Suivez les instructions d'importation du fichier LoadTest2010.bacpac : Procédure : importer une application de la couche Données (Base de données SQL Windows Azure).

Une fois le référentiel créé dans Base de données SQL, configurez le contrôleur de test. En particulier, définissez la chaîne de connexion du magasin de résultats. La boîte de dialogue permettant de définir la valeur se trouve uniquement dans Visual Studio Ultimate. Mais avant de continuer, vous devez faire un choix. Décidez si vous souhaitez exécuter le contrôleur de test :

  1. À partir d'un ordinateur sur site.

    Si vous choisissez cette option, à partir d'un ordinateur sur site, suivez les instructions ci-dessous.

  2. Depuis un rôle de travail dans Windows Azure exécutant une instance de Visual Studio.

    Si vous avez choisi d'exécuter le contrôleur de test à partir d'un rôle de travail dans Windows Azure :

    1. Créez le groupe Connect de Windows Azure.

    2. Ajoutez la station de travail sur site dans le groupe.

    3. Après avoir déployé le service hébergé, utilisez le bureau à distance pour la connexion au rôle de travail qui hébergera Visual Studio.

    4. Installez Microsoft Visual Studio 2010 Ultimate à partir d'un fichier d'installation (.msi) sur votre réseau

Pour configurer l'instance sur site du contrôleur de test

  1. Exécutez Visual Studio en tant qu'administrateur.

  2. Dans Visual Studio, dans le menu Test, cliquez sur Gérer les contrôleurs de test.

  3. Sous le texte Magasin des résultats des tests de charge, cliquez sur le bouton de sélection.

  4. Dans la boîte de dialogue Propriétés de connexion, collez le nom du serveur Base de données SQL.

  5. Sous le texte Connexion au serveur, sélectionnez l'option Utiliser l'authentification SQL Server.

  6. Définissez la valeur Nom d'utilisateur sur le nom de connexion de l'administrateur Base de données SQL.

  7. Définissez la valeur du champ Mot de passe avec la valeur de mot de passe de l'administrateur Base de données SQL.

  8. Dans la section Connexion à une base de données, sélectionnez la base de données LoadTest2010.

    Si la chaîne de connexion et les informations d'identification sont correctes, examinez la boîte de dialogue Configurer le contrôleur de test. La boîte de dialogue contient les valeurs correctes.

Utilisation des points de terminaison au lieu d'un groupe Connect de Windows Azure

Il existe une alternative à l'utilisation du groupe Connect : la configuration des points de terminaison sur chaque rôle de travail pour communiquer entre les instances. Cela présente plusieurs avantages dans ce cas parce que la connexion est plus fiable. Procédez comme suit pour essayer cette solution.

Pour configurer les points de terminaison sur les instances de rôle de travail

  1. Dans Visual Studio, ouvrez le projet de test de charge.

  2. Configurez chaque rôle de travail avec des points de terminaison TCP internes. Pour obtenir des instructions générales sur l'ajout de points de terminaison à un rôle, consultez Procédure de définition de points de terminaison internes pour un rôle. Pour chaque point de terminaison, spécifiez un numéro de port privé différent. Le tableau suivant contient les configurations de points de terminaison pour chaque rôle. Notez que tous ces points de terminaison sont des ports privés qui utilisent le protocole TCP :

     

    Nom du rôle Nom du port Numéro de port

    Agent

    SQL

    1433

    Agent

    WFS

    137-445

    Agent

    Port d'écoute de l'agent

    6910

    Agent

    AgentDownload

    80

    Contrôleur

    SQL

    1433

    Contrôleur

    WFS

    137-445

    Contrôleur

    Contrôleur

    6910

    Contrôleur

    AgentDownload

    80

    Contrôleur

    Port d'écoute du contrôleur

    6901

    Contrôleur

    Agent

    6910

    Contrôleur/Station de travail

    Réponse

    49152

  3. Configurez un port spécifique pour permettre au contrôleur d'envoyer des messages aux agents. Utilisez la clé de Registre suivante sur le rôle de travail qui héberge le contrôleur :

    1. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeStart

    2. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeEnd

  4. Lors du démarrage du rôle de travail, exécutez le fichier setupwfw.cmd.

  5. Définissez le bureau à distance pour chaque rôle et procédez comme suit :

    1. Ouvrez le répertoire suivant : \Windows\System32\drivers\etc\

      Ouvrez le fichier hosts pour le modifier. Le fichier peut s'ouvrir à l'aide de Notepad.exe. Placez le fichier « hosts » sur chaque système qui contient le nom d'hôte et l'adresse IP. La modification du fichier est un processus manuel. Pour rechercher l'adresse IP d'un rôle, ouvrez une fenêtre de commande sur chaque rôle et tapez IPCONFIG. Exemple de fichier Hosts :

    2. 
      # Copyright (c) 1993-2009 Microsoft Corp.
      #
      # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
      #
      # This file contains the mappings of IP addresses to host names. Each
      # entry should be kept on an individual line. The IP address should
      # be placed in the first column followed by the corresponding host name.
      # The IP address and the host name should be separated by at least one
      # space.
      #
      # Additionally, comments (such as these) may be inserted on individual
      # lines or following the machine name denoted by a '#' symbol.
      #
      # For example:
      #
      #      102.54.94.97     rhino.acme.com          # source server
      #       38.25.63.10     x.acme.com              # x client host
      
      # localhost name resolution is handled within DNS itself.
      #127.0.0.1       localhost
      #::1             localhost
      10.115.222.131 RD00155D317984    # workstation
      10.115.218.125 RD00155D3175BF    # Controller
      10.115.222.142 RD001455316FEE    # Agent00
      10.115.196.26 RD00D32D6747       # Agent01
      10.115.228.52  RD000155D317EBD  # Agent02
      10.115.222.131 RD00155D317984    # Agent03
      
      
  6. Chaque rôle peut communiquer et vous pouvez installer les binaires sur chaque système. Pour accélérer le processus, placez les binaires dans le magasin d'objets blob. Exécutez également des commandes supplémentaires dans le cadre de la tâche de démarrage. Pour plus d'informations, consultez Procédure de définition des tâches de démarrage pour un rôle.)

  7. Dans SQL Server, créez un compte SQL local pour le contrôleur et la station de travail afin d'accéder à la base de données de résultats. Puis, configurez le référentiel de manière à utiliser ces comptes. Créez la base de données lorsque vous installez le contrôleur, puis configurez-le de manière à utiliser le compte depuis l'environnement de développement intégré.


Date de génération :

2013-07-25
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

Afficher:
© 2015 Microsoft