VENTAS: 1-800-867-1389

Ejecutar pruebas de carga en entornos mixtos

En este tema se abordan las pruebas de carga de Visual Studio que se ejecutan en entornos mixtos. Un “entorno mixto” es un entorno donde se hospedan los componentes de la prueba de carga en varios contextos, como por ejemplo, local como roles de trabajador de Windows Azure. Por ejemplo, un entorno mixto sería aquel en el que los agentes de prueba se ejecutan de forma local y el repositorio de datos se encuentra en un servidor de Base de datos SQL de Windows Azure. Esto contrasta con el sistema descrito en Pruebas de carga de Visual Studio en información general de Windows Azure. En este tema, todos los componentes, salvo la estación de trabajo se ejecutan como roles de trabajador de Windows Azure.

Ejecutar pruebas de carga en estos entornos mixtos puede resultar necesario por razones normativas o por razones específicas de la aplicación. En cualquier caso, en este tema se abordan las opciones disponibles y cómo configurar estos escenarios variados.

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

Descargar

Los archivos necesarios para estos procedimientos se encuentran aquí: VSLoadTestInMixedEnvironments

Simultaneidad

Un factor utilizado a la hora de sopesar las distintas configuraciones es la simultaneidad incrementada por ejecutar muchos procesos en un centro de datos grande. La simultaneidad se define como una propiedad del sistema, donde varias tareas se ejecutan simultáneamente y probablemente estén interactuando. Un factor que restringe la simultaneidad es el número de direcciones IP disponibles. Cuantas más direcciones IP aproveche el sistema, mayor será el procesamiento simultáneo. Normalmente, el número de direcciones disponibles depende del tamaño del proveedor IP. Si el contrato de nivel de servicio es amplio, normalmente se asigna una gran cantidad de direcciones IP. Pero tales acuerdos no son habituales. Sin embargo, cuando se utiliza Windows Azure como plataforma, se disfrutará de la ventaja de utilizar un centro de datos de Microsoft y sus recursos. Esto incluye un grupo nutrido de direcciones IP. A los servicios hospedados en Windows Azure se les asignan direcciones IP virtuales. En esta documentación, las direcciones IP las utiliza el equilibrador de carga (no los servicios hospedados) que mira hacia fuera (Internet). Y disponer de una gran cantidad es una ventaja que ofrece el centro de datos de Microsoft. Por otra parte, tenga en cuenta que no todos los sistemas requieren este nivel de simultaneidad.

Esta capacidad para mejorar la simultaneidad es otra gran ventaja a la hora de ejecutar pruebas de carga en Windows Azure. Este nivel de simultaneidad también es el más difícil de reproducir fuera de un centro de datos grande.

Factores

Hay seis factores que afectan a la simultaneidad. Los primeros dos factores son los contextos en los que se ejecuta la prueba de carga: la nube y local.

  • Local

  • Nube

Los otros cuatro factores son los componentes de la prueba de carga. Son los siguientes:

  • Controlador de pruebas

  • Agentes de pruebas

  • Repositorio de resultados

  • Sistema probado

Los cuatro componentes se muestran a continuación:

Factores de la prueba de carga

En el gráfico, los anchos relativos de las líneas representan la cantidad de datos transferidos; cuanto más gruesa sea la línea, mayor es la cantidad de datos. La transferencia de datos más voluminosa se produce entre el controlador de pruebas y el repositorio de resultados. La carga menos pesada se produce entre el sistema probado y el controlador. (Sin embargo, la carga real depende de la cantidad de registros que produce el sistema probado). A modo de referencia, vea gráfico en Pruebas de carga de Visual Studio en información general de Windows Azure.

noteNota
En pos de la claridad, el gráfico da por sentado que la estación de trabajo que hospeda Visual Studio también hospeda el controlador de pruebas. Esta configuración facilita la comunicación entre Visual Studio y el controlador de pruebas. Durante una prueba de carga, el controlador emite grandes cantidades de datos de vuelta a Visual Studio para la supervisión del rendimiento en tiempo real.

Topologías

Dados los cuatro componentes, y los dos contextos, se hacen evidentes diversas opciones topológicas. Los cuatro componentes de la prueba de carga pueden existir en uno u otro contexto. Por ejemplo, las dos topologías más sencillas se describen aquí.

  1. Todos los componentes de la nube.

  2. Todos los componentes locales.

Para facilitar su comprensión, las dos opciones más sencillas se muestran en esta tabla.

 

Controlador Agentes Repositorio Sistema probado Notas

Local

Local

Local

Local

Simultaneidad limitada sin tráfico de red fuera del ámbito local.

Nube

Nube

Nube

Nube

Gran simultaneidad (más direcciones IP) y sin tráfico de red fuera de la nube.

Las topologías son ahora más complejas. Para no complicar las cosas, esta tabla muestra una división importante. En esta tabla, el controlador se ejecuta localmente.

El tráfico de los agentes hacia el sistema probado no se tiene en cuenta, ya que se supone que forma parte del costo de cualquier prueba. Observe asimismo que el tráfico de red en las siguientes tablas tiene un costo económico. Se cargan los datos transferidos fuera del centro de datos. El tráfico interno no se carga. Para obtener detalles sobre el establecimiento de precios, vea Información detallada sobre precios y busque el tema sobre transferencias de datos medidas en GB.

Esta tabla a continuación muestra un punto de división importante: cuando el controlador de pruebas se ejecuta localmente. En ese caso, el tráfico entre los componentes debe cruzar el límite, con consecuencias de diferentes grados, dependiendo del componente y su consumo de ancho de banda.

El controlador se ejecuta localmente

Controlador Agentes Repositorio Sistema probado Notas

Local

Local

Local

Nube

Simultaneidad limitada, tráfico de red desde el sistema probado al controlador.

Local

Local

Nube

Local

Simultaneidad limitada, tráfico de red desde el controlador al repositorio.

Local

Local

Nube

Nube

Simultaneidad limitada, tráfico de red desde el sistema probado al controlador y de vuelta al repositorio.

Local

Nube

Local

Local

Mayor simultaneidad, tráfico de red desde los agentes al controlador.

Local

Nube

Local

Nube

Mayor simultaneidad, tráfico de red desde los agentes y el sistema probado al controlador.

Local

Nube

Nube

Local

Mayor simultaneidad, tráfico de red desde los agentes al controlador y de vuelta al repositorio.

Local

Nube

Nube

Nube

Mayor simultaneidad, tráfico de red desde el agente y el sistema probado al controlador y de vuelta al repositorio.

Esta tabla muestra la segunda división más importante. En esta tabla, el controlador se ejecuta en la nube.

El controlador se ejecuta en la nube

Controlador Agentes Repositorio Sistema probado Notas

Nube

Local

Local

Local

Simultaneidad limitada, tráfico de red desde el agente y el sistema probado al controlador y de vuelta al repositorio.

Nube

Local

Local

Nube

Simultaneidad limitada, tráfico de red desde el agente al controlador y de vuelta al repositorio.

Nube

Local

Nube

Local

Simultaneidad limitada, tráfico de red desde el agente y sistema probado al controlador.

Nube

Nube

Nube

Nube

Mayor simultaneidad, tráfico de red desde los agentes al controlador.

Nube

Nube

Local

Local

Mayor simultaneidad, tráfico de red desde el sistema probado al controlador y de vuelta al repositorio.

Nube

Nube

Local

Nube

Mayor simultaneidad, tráfico de red desde el controlador al repositorio.

Nube

Nube

Nube

Local

Mayor simultaneidad, tráfico de red desde sistema probado al controlador.

Nube

Varias nubes

Nube

Nube

Simultaneidad más alta, al menos desde el sistema probado en DC1 al controlador en DC2 (posiblemente más, en función de la configuración).

Recomendaciones

Se muestran las topologías al objeto de dar una información lo más completa posible. Es posible que usted no puede elegir la topología. Por ejemplo, si necesita más de 100 GB de almacenamiento de datos para SQL Server, es preciso que los almacene localmente; actualmente, 100 GB es el límite para Base de datos SQL. Sin embargo, si tiene algo de margen, estas son las mejores topologías. Estas recomendaciones son las más eficaces y proporcionan los máximos niveles de simultaneidad de las dos divisiones principales (controlador local o en la nube).

Mejor si el controlador se ejecuta localmente

Controlador Agentes Repositorio Sistema probado Notas

Local

Nube

Local

Local

Mayor simultaneidad, tráfico de red desde los agentes al controlador.

Local

Nube

Local

Nube

Mayor simultaneidad, tráfico de red desde los agentes y el sistema probado al controlador.

Mejor si el controlador se ejecuta en la nube

Controlador Agentes Repositorio Sistema probado Notas

Nube

Local

Nube

Local

Simultaneidad limitada, tráfico de red desde el agente y sistema probado al controlador.

Nube

Nube

Nube

Nube

Mayor simultaneidad, tráfico de red desde los agentes al controlador.

Nube

Varias nubes

Nube

Nube

Simultaneidad más alta, al menos desde el sistema probado en DC1 al controlador en DC2 (posiblemente más, en función de la configuración).

Exigencias de una mayor complejidad

En el mundo real, el diseño de componentes puede ser complejo. Un sistema en pruebas puede tener varios subcomponentes, cada uno ejecutándose como rol de trabajador o web o utilizando los servicios locales. Por ejemplo, un componente inicializa el sistema o proporciona servicios de validación. Es probable que muchos de los componentes deban comunicarse con otras partes del sistema. Este conjunto de componentes es además del sistema de prueba de carga en sí (consiste en un controlador, agentes y un repositorio). El gráfico siguiente muestra un sistema con muchas partes. Se ha diseñado solo para mostrar que una solución real puede tener muchos componentes y muchos requisitos de comunicación. Los detalles del sistema no constituyen la cuestión principal.

Ejemplo de configuración compleja

Con toda esta complejidad, resulta todavía posible emplazar varios componentes en Windows Azure o localmente, según sea necesario. La sección siguiente describe los pasos necesarios.

Configuración

La configuración en este caso contempla un conjunto de alternativas respecto a la configuración básica que se puede consultar en este documento: Aprovisionar Windows Azure para pruebas de carga. Los procedimientos que se abordan especifican cómo configurar el Portal de administración con los elementos correctos. Por ejemplo, explica cómo configurar una cuenta de almacenamiento y cómo configurar un grupo de Connect de Windows Azure.

Esta primera alternativa le permite utilizar Base de datos SQL como repositorio de resultados. La segunda alternativa indica cómo configurar extremos en cada rol de trabajador. Los extremos habilitan la comunicación entre los agentes, el sistema probado, el controlador de pruebas y (si es necesario) con un factor complementario: la estación que hospeda a Visual Studio. El método idóneo es que el equipo sea local. Pero si la aplicación requiere utilizarlo durante la ejecución de la prueba, también puede estar hospedado como un rol de trabajador de Windows Azure.

Requisitos previos

Se requiere lo siguiente:

  • Descargue el archivo LoadTest2010.bacpac.

  • Opcional. Instale Visual Studio 2010 Ultimate en un rol de trabajador.

    Si tiene previsto ejecutar el controlador de pruebas en un rol de trabajador, instale Visual Studio 2010 Ultimate en el rol de trabajador. Agregue un rol de trabajador al proyecto de Windows Azure en Visual Studio. Asegúrese de que está habilitado Escritorio remoto. Agregue el rol de trabajo a un grupo de Connect para conectarlo al sitio local. Utilice Escritorio remoto para conectarse al rol de trabajador y, después, instale Visual Studio 2010 Ultimate.

Usar SQL BACPAC para aprovisionar Base de datos SQL de Windows Azure

Utilice este método para almacenar resultados en Base de datos SQL con el fin de guardar los datos de la prueba de carga. Cargue el archivo denominado LoadTest2010.bacpac en su cuenta de Almacenamiento de Windows Azure. Además debe cumplir los siguientes requisitos previos:

  1. Una cuenta de Base de datos SQL.

  2. Una instancia de servidor SQL creada en una suscripción. Para obtener más información, vea el artículo sobre cómo crear un servidor de Base de datos SQL de Windows Azure.

  3. Un nombre de inicio de sesión y una contraseña con permiso para modificar la instancia de servidor.

Para aprovisionar Base de datos SQL con un BACPAC

  1. Cargue el archivo con el nombre LoadTest2010.bacpac en la cuenta de Almacenamiento de Windows Azure.

    Utilice StorageServicesSmartClient para cargar el archivo en un contenedor público. Una vez que el archivo .dacpac se carga, puede utilizar la función de importación del Portal de administración para crear la base de datos.

  2. En el Portal de administración, haga clic en Base de datos.

  3. Expanda la suscripción que contiene el servidor de Base de datos SQL que utilice y seleccione el servidor.

  4. En la sección Base de datos de la cinta de opciones, haga clic en Importar.

  5. Siga las instrucciones del documento siguiente para importar el archivo LoadTest2010.bacpac: Importar una aplicación de capa de datos (Base de datos SQL de Windows Azure).

Una vez se haya creado el repositorio en Base de datos SQL, configure el controlador de pruebas. En concreto, establezca la cadena de conexión para el almacén de resultados. El cuadro de diálogo para establecer el valor aparece solo en Visual Studio Ultimate. Sin embargo antes de continuar, tiene que tomar una decisión. Decida si ejecuta el controlador de pruebas:

  1. Desde un equipo local.

    Si opta por esta alternativa, desde un equipo local, siga el conjunto siguiente de instrucciones.

  2. Ejecutar una instancia de Visual Studio desde un rol de trabajador de Windows Azure.

    Si ha decidido ejecutar el controlador de pruebas desde un rol de trabajador de Windows Azure:

    1. Cree el grupo de Connect de Windows Azure.

    2. Agregue la estación de trabajo local al grupo.

    3. Después de implementar el servicio hospedado, utilice Escritorio remoto para conectarse al rol de trabajador donde se hospedará Visual Studio.

    4. Instale Visual Studio 2010 Ultimate desde un archivo de instalación (.msi) en la red

Para configurar la instancia local del controlador de pruebas

  1. Ejecute Visual Studio 2010 como administrador.

  2. En Visual Studio, en el menú Probar, haga clic en Administrar controladores de pruebas.

  3. Bajo el texto Almacén de resultados de pruebas de carga, haga clic en los puntos suspensivos.

  4. En el cuadro de diálogo Propiedades de conexión, pegue el nombre del servidor de Base de datos SQL.

  5. Bajo el texto Iniciar sesión en el servidor, seleccione la opción de Utilizar la autenticación de SQL Server.

  6. Establezca el valor Nombre de usuario según el nombre de inicio de sesión para el administrador de Base de datos SQL.

  7. Establezca el valor del campo Contraseña según el valor de contraseña para el administrador de Base de datos SQL.

  8. En la sección Conectar con una base de datos, seleccione la base de datos LoadTest2010.

    Si la cadena de conexión y las credenciales son correctas, examine el cuadro de diálogo Configurar controlador de pruebas. El cuadro de diálogo se rellena con los valores correctos.

Usar extremos en lugar de un grupo de Connect de Windows Azure

Existe una alternativa a usar el grupo de Connect: configurar los extremos en cada rol de trabajador para establecer la comunicación entre instancias. Las ventajas de esta opción es que la conexión es más fiable. Siga los siguientes pasos para intentar aplicar esta alternativa.

Para configurar extremos en instancias de rol de trabajador

  1. En Visual Studio, abra el proyecto de prueba de carga.

  2. Configure cada rol de trabajador con extremos internos de TCP. Para obtener instrucciones generales sobre cómo agregar extremos a un rol, vea Definir extremos internos para un rol. Para cada extremo, especifique un número de puerto privado diferente. La tabla siguiente muestra las configuraciones del extremo para cada rol. Observe que todos estos extremos son puertos privados que utilizan el protocolo TCP:

     

    Nombre de rol Nombre del puerto Número de puerto

    Agente

    SQL

    1433

    Agente

    WFS

    137-445

    Agente

    Puerto de agente de escucha del agente

    6910

    Agente

    AgentDownload

    80

    Controlador

    SQL

    1433

    Controlador

    WFS

    137-445

    Controlador

    Controlador

    6910

    Controlador

    AgentDownload

    80

    Controlador

    Puerto del agente de escucha del controlador

    6901

    Controlador

    Agente

    6910

    Controlador y estación de trabajo

    Intercomunicación

    49152

  3. Configure un puerto específico para que el controlador envíe mensajes a los agentes. Utilice la siguiente clave del Registro en el rol del trabajador que hospeda al controlador:

    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. Al iniciar el rol de trabajador, ejecute el archivo setupwfw.cmd.

  5. Establezca Escritorio remoto para cada rol y haga lo siguiente:

    1. Abra el directorio siguiente: \Windows\System32\drivers\etc\

      Abra el archivo hosts para modificarlo. El archivo se puede abrir con Notepad.exe. Coloque el archivo “hosts” en cada sistema con el nombre de host y la dirección IP. La modificación del archivo es un proceso manual. Para buscar la dirección IP de un rol, abra una ventana de comandos de cada rol y escriba IPCONFIG. Un ejemplo de archivo host:

    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. Cada rol puede comunicarse y usted puede instalar los archivos binarios de cada sistema. Para acelerar el proceso, coloque los archivos binarios en el almacén de blobs. Por otra parte, ejecute los comandos adicionales que formen parte de la tarea de inicio. Para obtener más información, vea Definir las tareas de inicio de un rol).

  7. En SQL Server, cree una cuenta de SQL para el controlador y estación de trabajo con el fin de tener acceso a la base de datos de los resultados. Después, configure el repositorio para utilizar esas cuentas. Cree la base de datos cuando configure el controlador y, después, configúrelo para que utilice la cuenta desde el IDE.


Fecha de compilación:

2013-07-25
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

Mostrar:
© 2014 Microsoft