Condividi tramite


Pianificazione della capacità di App-V 5.0

Aggiornamento: febbraio 2014

Si applica a: Application Virtualization 5.0, Application Virtualization 5.0 SP1, Application Virtualization 5.0 SP2, Application Virtualization 5.0 SP3

Le indicazioni riportate di seguito possono essere usate come riferimento per individuare più agevolmente le informazioni di pianificazione della capacità appropriate per l'infrastruttura App-V 5.0 della propria organizzazione.

Importante

Usare le informazioni contenute in questa sezione soltanto come guida generale per la pianificazione della distribuzione di App-V 5.0. La capacità necessaria per il sistema dipenderà dai dettagli specifici dell'ambiente hardware e applicativo di cui si dispone. I valori relativi alle prestazioni indicati in questo documento sono inoltre semplici esempi, pertanto i risultati ottenuti possono variare.

Determinazione dell'ambito del progetto

Prima di progettare l'infrastruttura App-V 5.0, è necessario determinare l'ambito del progetto, stabilendo quali applicazioni saranno virtualmente disponibili e identificando gli utenti di destinazione con le relative posizioni. Tali informazioni saranno utili per scegliere il tipo di infrastruttura App-V 5.0 da implementare. Le decisioni relative all'ambito del progetto devono basarsi sulle esigenze specifiche dell'organizzazione.

Attività Altre informazioni

Determinazione dell'ambito delle applicazioni

L'infrastruttura App-V 5.0 può essere impostata in diversi modi a seconda delle applicazioni da virtualizzare. Come prima attività è pertanto necessario definire quali applicazioni devono essere virtualizzate.

Determinazione dell'ambito delle posizioni

L'ambito delle posizioni corrisponde alle posizioni fisiche, ad esempio un'ubicazione all'interno dell'azienda o una località geografica specifica, in cui si intende eseguire le applicazioni virtualizzate. Può anche indicare la popolazione di utenti, ad esempio un singolo reparto, che eseguirà le applicazioni virtuali. È consigliabile ottenere una mappa della rete in cui siano riportati i percorsi di connessione, la larghezza di banda disponibile per ogni posizione e il numero di utenti che si avvalgono delle applicazioni virtualizzate, nonché la velocità del collegamento WAN.

Determinazione dell'infrastruttura App-V 5.0 necessaria

Importante

In entrambi i modelli descritti di seguito è necessario che il client App-V 5.0 sia installato nel computer in cui si intende eseguire le applicazioni virtuali.

È possibile gestire l'ambiente App-V 5.0 anche mediante una soluzione di distribuzione elettronica del software (ESD, Electronic Software Distribution) come Microsoft System Center Configuration Manager. Per altre informazioni, vedere Distribuzione di pacchetti App-V 5.0 mediante una soluzione di distribuzione elettronica del software.

  • Modello autonomo: questo modello consente di abilitare le applicazioni virtuali per Windows Installer in modo che possano essere distribuite senza trasmissione in flusso. App-V 5.0 in modalità autonoma prevede il sequencer e il client. Non sono necessari ulteriori componenti. Le applicazioni vengono preparate per la virtualizzazione mediante un processo denominato sequenziazione. Per altre informazioni, vedere Pianificazione per la distribuzione di App-V 5.0 Sequencer e del client. Il modello autonomo è consigliato per i seguenti scenari:

    • Con utenti remoti disconnessi che non possono connettersi all'infrastruttura App-V 5.0

    • Quando si esegue un sistema di gestione software, come ad esempio Configuration Manager 2012

    • Quando limitazioni della larghezza di banda di rete impediscono la distribuzione elettronica del software

  • Modello con infrastruttura completa: questo modello fornisce funzionalità per la distribuzione e gestione del software e per la creazione di report, nonché la possibilità di trasmettere in flusso le applicazioni nella rete. Il modello con infrastruttura completa di App-V 5.0 prevede uno o più server di gestione App-V 5.0, che è possibile usare per pubblicare le applicazioni in tutti i client. Mediante il processo di pubblicazione, le icone e i collegamenti delle applicazioni virtuali vengono inseriti nel computer di destinazione. Le applicazioni vengono inoltre trasmesse in flusso agli utenti locali. Per altre informazioni sull'installazione del server di gestione, vedere Pianificazione della distribuzione del server APP-V 5.0. Il modello con infrastruttura completa è consigliato per i seguenti scenari:

    Importante

    Nel modello con infrastruttura completa di App-V 5.0 è necessario Microsoft SQL Server per archiviare i dati di configurazione. Per altre informazioni, vedere Configurazioni di App-V 5.0 supportate.

    • Quando si desidera usare il server di gestione per pubblicare l'applicazione nei computer di destinazione

    • Per effettuare rapidamente il provisioning delle applicazioni nei computer di destinazione

    • Quando si desidera usare la funzionalità di creazione report di App-V 5.0

Informazioni sul dimensionamento dei server end-to-end

Nella seguente sezione vengono fornite informazioni sul dimensionamento e sulla pianificazione di App-V 5.0 end-to-end. Per informazioni più specifiche, fare riferimento alle sezioni successive.

Nota

Il tempo di risposta round trip nel client è il tempo impiegato dal computer che esegue il client App-V 5.0 per ricevere una notifica di esito positivo dal server di pubblicazione. Il tempo di risposta round trip nel server di pubblicazione è il tempo impiegato dal computer che esegue tale server per ricevere un aggiornamento corretto dei metadati del pacchetto dal server di gestione.

  • 20.000 client possono avere come destinazione un unico server di pubblicazione per ottenere gli aggiornamenti pacchetto in un tempo di round trip accettabile (<3 secondi)

  • Un singolo server di gestione può supportare fino a 50 server di pubblicazione per gli aggiornamenti dei metadati del pacchetto in un tempo di round trip accettabile (<5 secondi)

Indicazioni per la pianificazione della capacità del server di gestione App-V 5.0

I server di pubblicazione App-V 5.0 necessitano del server di gestione per le richieste di aggiornamento pacchetto e le relative risposte. Il server di gestione quindi invia le informazioni al database di gestione per recuperare i dati. Per altre informazioni sulle configurazioni supportate per il server di gestione App-V 5.0, vedere Configurazioni di App-V 5.0 supportate.

Nota

Il tempo di aggiornamento predefinito nel server di pubblicazione App-V 5.0 è dieci minuti.

Quando più server di pubblicazione contattano contemporaneamente uno stesso server di gestione per gli aggiornamenti dei metadati del pacchetto, sul tempo di risposta round trip nel server di pubblicazione incidono i tre fattori seguenti:

  1. Numero di server di pubblicazione che effettuano richieste simultanee

  2. Numero di gruppi di connessione configurati nel server di gestione

  3. Numero di gruppi di accesso configurati nel server di gestione

Nella tabella riportata di seguito vengono fornite ulteriori informazioni sui singoli fattori che influiscono sul tempo di round trip.

Nota

Il tempo di risposta round trip è il tempo impiegato dal computer che esegue il server di pubblicazione App-V 5.0 per ricevere un aggiornamento corretto dei metadati del pacchetto dal server di gestione.

Fattori che incidono sul tempo di risposta round trip Altre informazioni

Numero di server di pubblicazione che richiedono contemporaneamente aggiornamenti dei metadati del pacchetto

  • Un singolo server di gestione può rispondere a un massimo di 320 server di pubblicazione che richiedono contemporaneamente metadati di pubblicazione.

  • Il tempo di risposta round trip per 320 server di pubblicazione è ~40 secondi.

  • Per meno di 50 server di pubblicazione che richiedono contemporaneamente i metadati, il tempo di risposta round trip è <5 secondi.

  • Da 50 a 320 server di pubblicazione, il tempo di risposta aumenta in modo lineare (approssimativamente 2x).

Numero di gruppi di connessione configurati nel server di gestione

  • Per un massimo di 100 gruppi di connessione, non si verifica alcuna variazione significativa del tempo di risposta round trip nel server di pubblicazione.

  • Da 100 a 400 gruppi di connessione, si verifica un lieve aumento lineare del tempo di risposta round trip.

Numero di gruppi di accesso configurati nel server di gestione

  • Per un massimo di 40 gruppi di accesso, si verifica un aumento lineare (approssimativamente 3x) del tempo di risposta round trip nel server di pubblicazione.

Nella tabella riportata di seguito vengono indicati valori di esempio per ognuno dei fattori precedenti. In ogni variante vengono aggiornati 120 pacchetti dal server di gestione App-V 5.0.

Scenario Variante Numero di gruppi di connessione Numero di gruppi di accesso Numero di server di pubblicazione Tipo di connessione di rete server di pubblicazione/server di gestione Tempo di risposta round trip nel server di pubblicazione (in secondi) Utilizzo della CPU nel server di gestione

Server di pubblicazione che contattano simultaneamente il server di gestione per i metadati di pubblicazione

Numero di server di pubblicazione

  • 0

  • 0

  • 0

  • 0

  • 0

  • 0

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 50

  • 100

  • 200

  • 300

  • 315

  • 320

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 5

  • 10

  • 19

  • 32

  • 30

  • 37

  • 17

  • 17

  • 17

  • 15

  • 17

  • 15

Metadati di pubblicazione con gruppi di connessione

Numero di gruppi di connessione

  • 10

  • 50

  • 100

  • 150

  • 300

  • 400

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 100

  • 100

  • 100

  • 100

  • 100

  • 100

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 10

  • 11

  • 11

  • 16

  • 22

  • 25

  • 17

  • 19

  • 22

  • 19

  • 20

  • 20

Metadati di pubblicazione con gruppi di accesso

Numero di gruppi di accesso

  • 0

  • 0

  • 0

  • 0

  • 1

  • 10

  • 20

  • 40

  • 100

  • 100

  • 100

  • 100

  • LAN

  • LAN

  • LAN

  • LAN

  • 10

  • 43

  • 153

  • 535

  • 17

  • 26

  • 24

  • 24

L'utilizzo della CPU del computer che esegue il server di gestione è all'incirca del 25% indipendentemente dal numero di server di pubblicazione che se ne avvalgono come destinazione. I valori Transazioni/sec, Richieste batch/sec e Connessioni utente per database di Microsoft SQL Server sono uguali indipendentemente dal numero dei server di pubblicazione. Ad esempio: Transazioni/sec ~30, richieste batch/sec ~200 e connessioni utente ~6.

Usando una distribuzione distribuita geograficamente, in cui il server di gestione e quelli di pubblicazione usano tra loro una rete a collegamento lento, il tempo di risposta round trip nei server di pubblicazione rientra nei limiti accettabili (<5 secondi), persino per 100 richieste simultanee in un unico server di gestione.

Scenario Variante Numero di gruppi di connessione Numero di gruppi di accesso Numero di server di pubblicazione Tipo di connessione di rete server di pubblicazione/server di gestione Tempo di risposta round trip nel server di pubblicazione (in secondi) Utilizzo della CPU nel server di gestione

Connessione di rete tra il server di pubblicazione e il server di gestione

Rete a collegamento lento a 1,5 Mbps

  • 0

  • 0

  • 1

  • 1

  • 50

  • 100

  • DSL via cavo a 1,5 Mbps

  • DSL via cavo a 1,5 Mbps

  • 4

  • 5

  • 1

  • 2

Connessione di rete tra il server di pubblicazione e il server di gestione

Rete LAN/Wi-Fi

  • 0

  • 0

  • 1

  • 1

  • 100

  • 200

  • Wi-Fi

  • Wi-Fi

  • 11

  • 20

  • 15

  • 17

Indipendentemente dal fatto che il server di gestione e i server di pubblicazione siano connessi tramite rete a collegamento lento o ad alta velocità, il server di gestione può gestire approssimativamente 15.000 richieste di aggiornamento pacchetto in 30 minuti.

Indicazioni per la pianificazione della capacità del server di report App-V 5.0

I client App-V 5.0 inviano dati di report al server di report, che quindi registra le informazioni nel database di Microsoft SQL Server e restituisce una notifica di esito positivo al computer che esegue il client App-V 5.0. Per altre informazioni sulle configurazioni supportate per il server di report App-V 5.0, vedere Configurazioni di App-V 5.0 supportate.

Nota

Il tempo di risposta round trip è il tempo impiegato dal computer che esegue il client App-V 5.0 per inviare le informazioni di report al server di report e ricevere una notifica di esito positivo da tale server.

Scenario Riepilogo

Più client App-V 5.0 che inviano contemporaneamente informazioni di report al server di report

  • Il tempo di risposta round trip dal server di report è di 2,6 secondi per 500 client.

  • Il tempo di risposta round trip dal server di report è di 5.65 secondi per 1000 client.

  • Il tempo di risposta round trip aumenta in modo lineare in base al numero dei client.

Richieste al secondo elaborate dal server di report

  • Un server di report e un database possono elaborare al massimo 139 richieste al secondo. La media è di 121 richieste al secondo.

  • Usando due server di report che fanno riferimento allo stesso database di Microsoft SQL Server, la media di richieste al secondo è analoga a quella di un solo server di report (~127), con un massimo di 278 richieste al secondo.

  • Un solo server di report può elaborare 500 connessioni attive/simultanee.

  • Un solo server di report può elaborare al massimo 1500 connessioni simultanee.

Database di report

  • Il conflitto di blocco nel computer che esegue Microsoft SQL Server rappresenta il fattore che limita le richieste al secondo.

  • La velocità effettiva e il tempo di risposta non dipendono dalle dimensioni del database.

Calcolo del ritardo casuale:

Il ritardo casuale specifica il ritardo massimo (in minuti) per l'invio dei dati al server di report. Quando l'attività pianificata viene avviata, il client genera un ritardo casuale compreso tra 0 e il valore ReportingRandomDelay e attende il periodo di tempo specificato prima di inviare i dati.

Ritardo casuale = 4 * numero di client / media di richieste al secondo.

Esempio: per 500 client, con 120 richieste al secondo, il ritardo casuale è 4 * 500 / 120 = ~17 minuti.

Indicazioni per la pianificazione della capacità del server di pubblicazione App-V 5.0

I computer che eseguono il client App-V 5.0 si connettono al server di pubblicazione App-V 5.0 per inviare una richiesta di aggiornamento pubblicazione e ricevere una risposta. Il tempo di risposta round trip viene misurato nel computer che esegue il client App-V 5.0. Il tempo del processore viene misurato nel server di pubblicazione. Per altre informazioni sulle configurazioni supportate per il server di pubblicazione App-V 5.0, vedere Configurazioni di App-V 5.0 supportate.

Importante

Di seguito sono elencati i principali fattori da considerare quando si configura il server di pubblicazione App-V 5.0:

  • Il numero di client che si connettono contemporaneamente allo stesso server di pubblicazione

  • Il numero di pacchetti in ogni aggiornamento

  • La larghezza di banda di rete disponibile nell'ambiente in uso tra il client e il server di pubblicazione App-V 5.0

Scenario Riepilogo

Più client App-V 5.0 che si connettono contemporaneamente a uno stesso server di pubblicazione

  • Un server di pubblicazione con processori dual core può rispondere al massimo a 5000 client che richiedono contemporaneamente un aggiornamento.

  • Da 5000 a 10000 client, il server di pubblicazione richiede almeno un processore quad core.

  • Da 10000 a 20000 client, il server di pubblicazione dovrebbe disporre di un processore quad core doppio per avere tempi di risposta più efficienti.

  • Un server di pubblicazione con un processore quad core può aggiornare fino a 10000 pacchetti in 3 secondi (sono supportati 10000 client simultanei).

Numero di pacchetti in ogni aggiornamento

  • Con l'aumentare del numero dei pacchetti, anche il tempo di risposta aumenterà per ~40% (fino a 1000 pacchetti).

Rete tra il client App-V 5.0 e il server di pubblicazione

  • Su una rete lenta (1,5 Mbps di larghezza di banda) il tempo di risposta aumenta del 97% rispetto a una rete LAN (fino a 1000 utenti).

Nota

L'utilizzo della CPU del server di pubblicazione è sempre elevato nell'intervallo di tempo in cui devono essere elaborate richieste simultanee (>90% nella maggior parte dei casi). Il server di pubblicazione può gestire ~1500 richieste client in un secondo.

Scenario Variante Numero di client App-V 5.0 Numero di pacchetti Configurazione del processore nel server di pubblicazione Tipo di connessione di rete server di pubblicazione/client App-V 5.0 Tempo di round trip nel client App-V 5.0 (in secondi) Utilizzo della CPU nel server di pubblicazione (in %)

Client App-V 5.0 che invia una richiesta di aggiornamento pubblicazione e riceve una risposta; ogni richiesta contiene 120 pacchetti

Numero di client

  • 100

  • 1000

  • 5000

  • 10000

  • 120

  • 120

  • 120

  • 120

  • Dual core

  • Dual core

  • Quad core

  • Quad core

  • LAN

  • LAN

  • LAN

  • LAN

  • 1

  • 2

  • 2

  • 3

  • 100

  • 99

  • 89

  • 77

Più pacchetti in ogni aggiornamento

Numero di pacchetti

  • 1000

  • 1000

  • 500

  • 1000

  • Quad core

  • Quad core

  • LAN

  • LAN

  • 2

  • 3

  • 92

  • 91

Rete tra il client e il server di pubblicazione

Rete a collegamento lento a 1,5 Mbps

  • 100

  • 500

  • 1000

  • 120

  • 120

  • 120

  • Quad core

  • Quad core

  • Quad core

  • Rete intracontinentale a 1,5 Mbps

  • 3

  • 10 (con una percentuale di errori dell'0,2%)

  • 17 (con una percentuale di errori dell'1%)

Indicazioni per la pianificazione della capacità del server di flusso App-V 5.0

I computer che eseguono il client App-V 5.0 trasmettono in flusso il pacchetto dell'applicazione virtuale dal server di flusso. Il tempo di risposta round trip viene misurato nel computer che esegue il client App-V 5.0 e corrisponde al tempo impiegato per trasmettere in flusso l'intero pacchetto.

Importante

Di seguito sono elencati i principali fattori da considerare quando si configura il server di flusso App-V 5.0:

  • Il numero di client che trasmettono contemporaneamente pacchetti delle applicazioni in flusso da uno stesso server di flusso

  • La dimensione del pacchetto da trasmettere in flusso

  • La larghezza di banda di rete disponibile nell'ambiente in uso tra il client e il server di flusso

Scenario Riepilogo

Più client App-V 5.0 che trasmettono contemporaneamente applicazioni in flusso da uno stesso server di flusso

  • Se aumenta il numero dei client che trasmettono in flusso contemporaneamente dallo stesso server, viene stabilita una relazione lineare con il tempo di download o di trasmissione in flusso dei pacchetti.

Dimensione del pacchetto da trasmettere in flusso

  • La dimensione del pacchetto incide in modo significativo sul tempo di trasmissione in flusso o di download solo per i pacchetti più grandi con una dimensione ~ 1GB. Per i pacchetti con una dimensione compresa fra 3 MB e 100 MB, il tempo di trasmissione in flusso va da 20 secondi a 100 secondi, con 100 client simultanei.

Rete tra il client App-V 5.0 e il server di flusso

  • Su una rete lenta (1,5 Mbps di larghezza di banda) il tempo di risposta aumenta del 70-80% rispetto a una rete LAN (fino a 100 utenti).

Nella tabella riportata di seguito vengono indicati valori di esempio per ognuno dei fattori sopra elencati.

Scenario Variante Numero di client App-V 5.0 Dimensione di ogni pacchetto Tipo di connessione di rete server di flusso/client App-V 5.0 Tempo di round trip nel client App-V 5.0 (in secondi)

Più client App-V 5.0 che trasmettono pacchetti di applicazioni virtuali in flusso da un server di flusso

Numero di client

  • 100

  • 200

  • 1000



  • 100

  • 200

  • 1000

  • 3,5 MB

  • 3,5 MB

  • 3,5 MB



  • 5 MB

  • 5 MB

  • 5 MB

  • LAN

  • LAN

  • LAN



  • LAN

  • LAN

  • LAN

  • 29

  • 39

  • 391



  • 35

  • 68

  • 461

Dimensione di ogni pacchetto da trasmettere in flusso

Dimensione di ogni pacchetto

  • 100

  • 200



  • 100

  • 200

  • 21 MB

  • 21 MB



  • 109

  • 109

  • LAN

  • LAN



  • LAN

  • LAN

  • 33

  • 83



  • 100

  • 160

Connessione di rete tra il client e il server di flusso App-V 5.0

Rete a collegamento lento a 1,5 Mbps

  • 100



  • 100

  • 3,5 MB



  • 5 MB

  • Rete intracontinentale a 1,5 Mbps

  • 102



  • 121

Ogni server di flusso App-V 5.0 dovrebbe essere in grado di gestire almeno 200 client che trasmettono contemporaneamente applicazioni virtualizzate in flusso.

Nota

Il tempo effettivamente necessario per la trasmissione in flusso dipende principalmente dal numero dei client che trasmettono in flusso contemporaneamente, dal numero dei pacchetti, dalla dimensione dei pacchetti, dall'attività di rete del server e dalle condizioni della rete.

Ad esempio, un utente medio può trasmettere in flusso un pacchetto da 100 MB in meno di 2 minuti quando 100 client simultanei trasmettono in flusso dal server. Un pacchetto da 1 GB potrebbe tuttavia richiedere fino a 30 minuti. Nella maggior parte degli ambienti del mondo reale la richiesta di trasmissione in flusso non è distribuita in modo uniforme, pertanto sarà necessario individuare approssimativamente i requisiti di trasmissione in flusso di picco del proprio ambiente per decidere correttamente il numero di server di flusso da usare.

Il numero di client che un server di flusso è in grado di supportare può aumentare in modo considerevole e i requisiti di trasmissione in flusso di picco possono diminuire se le applicazioni vengono memorizzate nella cache. È possibile aumentare il numero dei client che un server di flusso può supportare anche mediante il recapito su richiesta del flusso e la trasmissione in flusso di pacchetti ottimizzati.

Combinazione dei ruoli server App-V 5.0

Riducendo i requisiti di dimensionamento e tolleranza di errore, il numero minimo di server necessari per una posizione con connettività ad Active Directory è pari a uno. In tale server saranno ospitati il server di gestione, il relativo servizio e i ruoli di Microsoft SQL Server. Tali ruoli possono pertanto essere organizzati in qualsiasi combinazione desiderata perché non sono in conflitto tra loro.

Se si ignorano i requisiti di scalabilità, il numero minimo di server necessari per offrire un'implementazione con tolleranza di errore è pari a quattro. Il server di gestione e i ruoli di Microsoft SQL Server possono essere usati in configurazioni con tolleranza di errore. Il servizio del server di gestione può essere combinato con qualsiasi ruolo, ma rimane un punto di errore singolo.

Benché siano disponibili diverse strategie e tecnologie per la tolleranza di errore, non tutte sono applicabili a un determinato servizio. Inoltre, se i ruoli App-V 5.0 vengono combinati, alcune opzioni di tolleranza di errore potrebbero non essere più applicabili per incompatibilità.

Come inviare suggerimenti per App-V?

Aggiungere o votare i suggerimenti qui. Per problemi relativi ad App-V, usare il forum di TechNet su App-V.

Vedere anche

Concetti

Configurazioni di App-V 5.0 supportate
Pianificazione della disponibilità elevata con App-V 5.0

Altre risorse

Pianificazione della distribuzione di App-V

-----
Per ulteriori informazioni su MDOP, è possibile accedere alla libreria TechNet, cercare contenuto sulla risoluzione di problemi in TechNet Wiki o tenersi informati tramite Facebook o Twitter.
-----