Esecuzione di test di carico in ambienti misti

In questo argomento vengono illustrati i test di carico di Visual Studio eseguiti in un ambiente misto. È definito "ambiente misto" un ambiente in cui i componenti del test di carico sono ospitati in contesti diversi, ad esempio in locale, o come ruoli di lavoro di Windows Azure. È un ambiente misto, ad esempio, quello in cui gli agenti di test vengono eseguiti in locale e il repository dei dati si trova su un server di Database SQL di Windows Azure, un concetto opposto rispetto al sistema descritto in Panoramica del test di carico di Visual Studio in Windows Azure. In tale argomento tutti i componenti, a eccezione della workstation, vengono eseguiti come ruoli di lavoro di Windows Azure.

L'esecuzione di test di carico in questi ambienti misti può rendersi necessaria per ragioni normative o per motivi specifici dell'applicazione in uso. In ogni caso, in questo argomento vengono descritte le scelte disponibili e la modalità di configurazione di tali scenari diversi.

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

Download

I file necessari per queste procedure sono disponibili qui: VSLoadTestInMixedEnvironments

Concorrenza

Un fattore utilizzato nel valutare le diverse configurazioni è la maggiore concorrenza derivante dalla gestione di molti processi in un data center di grandi dimensioni. La concorrenza viene definita come una proprietà di sistema in cui diverse attività vengono eseguite contemporaneamente e possibilmente interagiscono. Un fattore che limita la concorrenza è il numero di indirizzi IP disponibili. A un maggior numero di IP utilizzati dal sistema corrisponde un livello di elaborazione simultanea più elevato. In genere, il numero di indirizzi disponibile dipende dalle dimensioni del provider IP. Se il contratto di servizio in uso è consistente, viene solitamente allocato un numero elevato di indirizzi IP, benché tali contratti non siano comuni. L'utilizzo di Windows Azure come piattaforma offre tuttavia il vantaggio di utilizzare una data center di Microsoft e le relative risorse, incluso un ampio pool di indirizzi IP. Ai servizi ospitati in Windows Azure vengono assegnati indirizzi IP virtuali. In questa discussione gli indirizzi IP vengono utilizzati dal servizio di bilanciamento del carico rivolto verso l'esterno, ovvero Internet (non i servizi ospitati). La disponibilità di un numero elevato di indirizzi IP costituisce un vantaggio offerto dal data center di Microsoft. Si noti inoltre che non tutti i sistemi richiedono questo livello di concorrenza.

La maggiore capacità in funzione della concorrenza è un altro grande vantaggio legato all'esecuzione di test di carico in Windows Azure. Questo livello di concorrenza è inoltre più difficile da riprodurre all'esterno di un data center di grandi dimensioni.

Fattori

Sulla concorrenza incidono sei fattori. I primi due sono i contesti in cui viene eseguito il test di carico: nel cloud e in locale.

  • Locale

  • Cloud

Gli altri quattro fattori sono i componenti del test di carico, elencati di seguito:

  • Controller di test

  • Agenti di test

  • Repository dei risultati

  • Sistema testato

I quattro componenti sono illustrati qui:

Fattori test di carico

Nel grafico gli spessori relativi delle linee rappresentano la quantità di dati trasferiti. Più è spessa la linea, maggiore è la quantità di dati. Il trasferimento di dati più consistente si verifica tra il controller di test e il repository dei risultati, mentre il carico inferiore avviene tra il sistema testato e il controller. Il carico effettivo dipende tuttavia dalla quantità di registrazione prodotta dal sistema testato. Per riferimento, vedere il grafico in Panoramica del test di carico di Visual Studio in Windows Azure.

noteNota
Per chiarezza, nel grafico si presuppone che la workstation che ospita Visual Studio ospiti anche il controller di test. Questa configurazione facilita la comunicazione tra Visual Studio e il controller di test. Durante un test di carico il controller ritrasmette una grande quantità di dati a Visual Studio per il monitoraggio delle prestazioni in tempo reale.

Topologie

Dati i quattro componenti e i due contesti, diventa evidente la possibilità di utilizzare varie topologie. I quattro componenti del test di carico possono essere presenti in uno qualsiasi dei due contesti. Di seguito sono riportate, ad esempio, le due topologie più semplici.

  1. Tutti i componenti nel cloud.

  2. Tutti i componenti in locale.

Per chiarezza, in questa tabella sono illustrate le due opzioni più semplici.

 

Controller Agenti Repository Sistema testato Note

Locale

Locale

Locale

Locale

Concorrenza limitata, nessun traffico di rete esterno all'ambiente locale.

Cloud

Cloud

Cloud

Cloud

Ampia concorrenza (più indirizzi IP) e nessun traffico di rete esterno al cloud.

Ora le topologie sono più complesse. Per semplicità, in questa tabella viene illustrata una divisione importante, il controller viene eseguito in locale.

Il traffico dagli agenti al sistema testato non viene considerato, in quanto si presuppone che faccia parte del costo di qualsiasi test. Si noti inoltre che il traffico di rete nelle tabelle seguenti ha un costo monetario: vengono addebitati i dati trasferiti all'esterno del data center, mentre il traffico interno non viene fatturato. Per dettagli sui prezzi, vedere la pagina relativa ai dettagli sui prezzi e cercare la sezione relativa al "trasferimento di dati misurati in GB".

Nella tabella successiva viene illustrato un punto di divisione importante, ovvero quando il controller di test viene eseguito in locale. In tal caso, il traffico tra i componenti deve superare il limite, con conseguenze di vario grado a seconda del componente e del relativo livello di "verbosità".

Controller eseguito in locale

Controller Agenti Repository Sistema testato Note

Locale

Locale

Locale

Cloud

Concorrenza limitata, traffico di rete dal sistema testato al controller.

Locale

Locale

Cloud

Locale

Concorrenza limitata, traffico di rete dal controller al repository.

Locale

Locale

Cloud

Cloud

Concorrenza limitata, traffico di rete dal sistema testato al controller e di nuovo al repository.

Locale

Cloud

Locale

Locale

Concorrenza maggiore, traffico di rete dagli agenti al controller.

Locale

Cloud

Locale

Cloud

Concorrenza maggiore, traffico di rete da agenti e sistema testato al controller.

Locale

Cloud

Cloud

Locale

Concorrenza maggiore, traffico di rete dagli agenti al controller e di nuovo al repository.

Locale

Cloud

Cloud

Cloud

Concorrenza maggiore, traffico di rete da agente e sistema testato al controller e di nuovo al repository.

In questa tabella viene illustrata la seconda divisione importante, il controller viene eseguito nel cloud.

Controller eseguito nel cloud

Controller Agenti Repository Sistema testato Note

Cloud

Locale

Locale

Locale

Concorrenza limitata, traffico di rete da agente e sistema testato al controller e di nuovo al repository.

Cloud

Locale

Locale

Cloud

Concorrenza limitata, traffico di rete da agente a controller e di nuovo al repository.

Cloud

Locale

Cloud

Locale

Concorrenza limitata, traffico di rete da agente e sistema testato al controller.

Cloud

Cloud

Cloud

Cloud

Concorrenza maggiore, traffico di rete dagli agenti al controller.

Cloud

Cloud

Locale

Locale

Concorrenza maggiore, traffico di rete dal sistema testato al controller e di nuovo al repository.

Cloud

Cloud

Locale

Cloud

Concorrenza maggiore, traffico di rete dal controller al repository.

Cloud

Cloud

Cloud

Locale

Concorrenza maggiore, traffico di rete dal sistema testato al controller.

Cloud

Multicloud

Cloud

Cloud

Concorrenza massima, almeno da sistema testato in DC1 al controller in DC2 (probabilmente superiore, a seconda della configurazione).

Indicazioni

Le topologie sono illustrate ai fini della completezza. La scelta di una topologia potrebbe non competere all'utente. Se ad esempio sono necessari oltre 100 GB di archiviazione dati di SQL Server, attualmente è necessario archiviarli in locale in quanto 100 GB è il limite del Database SQL. Se tuttavia è possibile una certa flessibilità, ecco le migliori topologie. Queste indicazioni risultano più efficienti e forniscono i livelli di concorrenza maggiori nelle due divisioni principali (controller in locale o controller nel cloud).

Topologia migliore quando il controller viene eseguito in locale

Controller Agenti Repository Sistema testato Note

Locale

Cloud

Locale

Locale

Concorrenza maggiore, traffico di rete dagli agenti al controller.

Locale

Cloud

Locale

Cloud

Concorrenza maggiore, traffico di rete da agenti e sistema testato al controller.

Topologia migliore quando il controller viene eseguito nel cloud

Controller Agenti Repository Sistema testato Note

Cloud

Locale

Cloud

Locale

Concorrenza limitata, traffico di rete da agente e sistema testato al controller.

Cloud

Cloud

Cloud

Cloud

Concorrenza maggiore, traffico di rete dagli agenti al controller.

Cloud

Multicloud

Cloud

Cloud

Concorrenza massima, almeno da sistema testato in DC1 al controller in DC2 (probabilmente superiore, a seconda della configurazione).

Maggiori esigenze di complessità

Nel mondo reale, il layout effettivo dei componenti può essere complesso. Un sistema sottoposto a test può avere molti componenti secondari, ognuno eseguito come un ruolo di lavoro o un ruolo Web o tramite servizi locali. Ad esempio, un componente inizializza il sistema o fornisce servizi di convalida. È quindi probabile che molti componenti debbano comunicare con altre parti del sistema. Questo set di componenti va ad aggiungersi allo stesso sistema sottoposto a test di carico (costituito da controller, agenti e repository). Nel grafico seguente viene illustrato un sistema con molte parti. È destinato esclusivamente a illustrare che una soluzione reale può includere molte parti e avere molti requisiti di comunicazione. I dettagli del sistema non sono il punto principale.

Esempio di una configurazione complessa

Dato questo livello di complessità, è comunque possibile collocare vari componenti in Windows Azure o in locale, secondo le esigenze. Nella sezione successiva vengono delineati i passaggi richiesti.

Configurazione

In questo caso, è un set di alternative alla configurazione di base presente nel documento Provisioning di Windows Azure per test di carico, nelle cui procedure viene specificato come configurare il portale di gestione con gli elementi corretti. Viene ad esempio descritto come configurare un account di archiviazione e un gruppo di Windows Azure Connect.

La prima alternativa consente di utilizzare il Database SQL come repository dei risultati. Per la seconda alternativa viene descritto come configurare endpoint in ogni ruolo di lavoro. Gli endpoint abilitano la comunicazione tra gli agenti, il sistema testato, il controller di test e, se necessario, un fattore ausiliare, ovvero la workstation che ospita Visual Studio. Nella modalità più semplice, il computer è installato in locale. Se tuttavia l'applicazione ne richiede l'utilizzo durante l'esecuzione del test, può essere ospitato anche come ruolo di lavoro di Windows Azure.

Prerequisiti

È necessario effettuare le operazioni seguenti:

  • Scaricare il file LoadTest2010.bacpac.

  • Facoltativo. Installare Visual Studio 2010 Ultimate in un ruolo di lavoro.

    Se si prevede di eseguire il controller di test in un ruolo di lavoro, installare Visual Studio 2010 Ultimate nel ruolo di lavoro. Aggiungere un ruolo di lavoro al progetto Windows Azure in Visual Studio. Assicurarsi che Desktop remoto sia abilitato. Aggiungere il ruolo di lavoro a un gruppo Connect per connetterlo al sito locale. Utilizzare Desktop remoto per connettersi al ruolo di lavoro e installare Visual Studio 2010 Ultimate.

Utilizzo di un file BACPAC SQL per il provisioning del database SQL di Windows Azure

Utilizzare questo metodo per archiviare i dati relativi ai risultati del test di carico in un Database SQL. Caricare il file denominato LoadTest2010.bacpac nell'account di archiviazione di Azure. È necessario disporre anche dei seguenti prerequisiti:

  1. Account del Database SQL.

  2. Istanza di SQL Server creata in una sottoscrizione. Per ulteriori informazioni, vedere la pagina relativa alla procedura di creazione di un server di database SQL di Windows Azure.

  3. Nome e password di accesso con l'autorizzazione per la modifica dell'istanza del server.

Per eseguire il provisioning di un database SQL con un file BACPAC

  1. Caricare il file LoadTest2010.bacpac nell'account di archiviazione di Azure.

    Utilizzare StorageServicesSmartClient per caricare il file in un contenitore pubblico. Una volta caricato il file con estensione dacpac, è possibile utilizzare la funzione di importazione del portale di gestione per creare il database.

  2. Nel portale di gestione fare clic su Database.

  3. Espandere la sottoscrizione che contiene il server di Database SQL utilizzato e selezionarlo.

  4. Nella sezione Database della barra multifunzione fare clic su Importa.

  5. Seguire le istruzioni relative all'importazione del file LoadTest2010.bacpac disponibili nella pagina Procedura: Importare un'applicazione livello dati (database SQL di Windows Azure).

Una volta creato il repository nel Database SQL, configurare il controller di test. In particolare, impostare la stringa di connessione per l'archivio dei risultati. La finestra di dialogo per l'impostazione del valore è disponibile solo in Visual Studio Ultimate. Prima di procedere è tuttavia necessario effettuare una scelta, ovvero decidere se eseguire il controller di test:

  1. Da un computer locale.

    Se si sceglie questa opzione per l'esecuzione da un computer locale, seguire il set di istruzioni successivo.

  2. Da un ruolo di lavoro in Windows Azure, eseguendo un'istanza di Visual Studio.

    Se si decide di eseguire il controller di test da un ruolo di lavoro in Windows Azure:

    1. Creare il gruppo di Windows Azure Connect.

    2. Aggiungere la workstation locale al gruppo.

    3. Dopo avere distribuito il servizio ospitato, utilizzare Desktop remoto per connettersi al ruolo di lavoro che ospiterà Visual Studio.

    4. Installare Visual Studio 2010 Ultimate da un file di installazione (con estensione msi) disponibile nella rete.

Per configurare l'istanza locale del controller di test

  1. Eseguire Visual Studio come amministratore.

  2. In Visual Studio scegliere Gestisci controller test dal menu Test.

  3. Sotto il testo Archivio risultati test di carico fare clic sul pulsante con i puntini di sospensione.

  4. Nella finestra di dialogo Proprietà connessione incollare il nome del server di Database SQL.

  5. Sotto il testo Accesso al server selezionare l'opzione Usa autenticazione di SQL Server.

  6. Impostare il valore di Nome utente sul nome di accesso dell'amministratore del Database SQL.

  7. Impostare il valore del campo Password sul valore della password per l'amministratore del Database SQL.

  8. Nella sezione Connessione al database selezionare il database LoadTest2010.

    Se la stringa di connessione e le credenziali sono corrette, esaminare la finestra di dialogo Configura controller di test, che sarà popolata con i valori corretti.

Utilizzo di endpoint anziché di un gruppo di Azure Connect

Esiste un'alternativa all'utilizzo del gruppo Connect, ovvero configurare endpoint in ogni ruolo di lavoro per la comunicazione tra le istanze, un approccio che offre il vantaggio di avere una connessione più affidabile. Per provare questa alternativa, utilizzare i passaggi seguenti.

Per configurare endpoint nelle istanze del ruolo di lavoro

  1. In Visual Studio aprire il progetto relativo al test di carico.

  2. Configurare ogni ruolo di lavoro con endpoint TCP interni. Per istruzioni generali sull'aggiunta di endpoint a un ruolo, vedere Come definire gli endpoint interni per un ruolo. Per ogni endpoint specificare un diverso numero di porta privato. Nella tabella seguente vengono illustrate le configurazioni di endpoint per ogni ruolo. Si noti che tutti questi endpoint sono porte private che utilizzano il protocollo TCP:

     

    Nome ruolo Nome porta Numero di porta

    Agente

    SQL

    1433

    Agente

    WFS

    137-445

    Agente

    Porta di attesa agente

    6910

    Agente

    AgentDownload

    80

    Controller

    SQL

    1433

    Controller

    WFS

    137-445

    Controller

    Controller

    6910

    Controller

    AgentDownload

    80

    Controller

    Porta di attesa controller

    6901

    Controller

    Agente

    6910

    Controller/Workstation

    Talkback

    49152

  3. Configurare una porta specifica per consentire al controller di inviare messaggi agli agenti. Utilizzare la chiave del Registro di sistema seguente nel ruolo di lavoro che ospita il controller:

    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. All'avvio del ruolo di lavoro eseguire il file setupwfw.cmd.

  5. Utilizzare Desktop remoto per ogni ruolo ed effettuare le seguenti operazioni:

    1. Aprire la directory \Windows\System32\drivers\etc\

      Aprire il file hosts per modificarlo. Il file può essere aperto tramite Notepad.exe. Inserire il file "hosts" in ogni sistema con il nome host e l'indirizzo IP. Il processo di modifica del file è manuale. Per individuare l'indirizzo IP di un ruolo, aprire una finestra di comando in ogni ruolo e digitare IPCONFIG. Di seguito è riportato un esempio di file 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. Ogni ruolo è in grado di comunicare ed è possibile installare i file binari in ogni sistema. Per velocizzare il processo, inserire i file binari nell'archivio BLOB. Eseguire inoltre i comandi aggiuntivi che fanno parte dell'attività di avvio. Per ulteriori informazioni, vedere Come definire attività di avvio per un ruolo.

  7. In SQL Server creare un account SQL locale per consentire al controller e alla workstation di accedere al database dei risultati, quindi configurare il repository per l'utilizzo di tali account. Creare il database durante la configurazione del controller, quindi configurarlo in modo che utilizzi l'account dall'IDE.


Data di compilazione:

2013-07-25

Aggiunte alla community

Mostra: