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:
Numero di server di pubblicazione che effettuano richieste simultanee
Numero di gruppi di connessione configurati nel server di gestione
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 |
|
Numero di gruppi di connessione configurati nel server di gestione |
|
Numero di gruppi di accesso configurati nel server di gestione |
|
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 |
|
|
|
|
|
|
Metadati di pubblicazione con gruppi di connessione |
Numero di gruppi di connessione |
|
|
|
|
|
|
Metadati di pubblicazione con gruppi di accesso |
Numero di gruppi di accesso |
|
|
|
|
|
|
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 |
|
|
|
|
|
|
Connessione di rete tra il server di pubblicazione e il server di gestione |
Rete LAN/Wi-Fi |
|
|
|
|
|
|
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 |
|
Richieste al secondo elaborate dal server di report |
|
Database di report |
|
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 |
|
Numero di pacchetti in ogni aggiornamento |
|
Rete tra il client App-V 5.0 e il server di pubblicazione |
|
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 |
|
|
|
|
|
|
Più pacchetti in ogni aggiornamento |
Numero di pacchetti |
|
|
|
|
|
|
Rete tra il client e il server di pubblicazione |
Rete a collegamento lento a 1,5 Mbps |
|
|
|
|
|
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 |
|
Dimensione del pacchetto da trasmettere in flusso |
|
Rete tra il client App-V 5.0 e il server di flusso |
|
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 |
|
|
|
|
Dimensione di ogni pacchetto da trasmettere in flusso |
Dimensione di ogni pacchetto |
|
|
|
|
Connessione di rete tra il client e il server di flusso App-V 5.0 |
Rete a collegamento lento a 1,5 Mbps |
|
|
|
|
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.
-----