Planification de la capacité d'App-V 5.1
Les recommandations suivantes peuvent être utilisées comme base de référence pour vous aider à déterminer les informations de planification de la capacité appropriées à l’infrastructure App-V 5.1 de votre organisation.
Important
Utilisez les informations de cette section uniquement comme guide général pour la planification de votre déploiement App-V 5.1. La capacité requise de votre système dépend des détails spécifiques de votre environnement matériel et d’application. En outre, les numéros de performances affichés dans ce document sont des exemples et vos résultats peuvent varier.
Déterminer l’étendue du projet
Avant de concevoir l’infrastructure App-V 5.1, vous devez déterminer l’étendue du projet. L’étendue consiste à déterminer quelles applications seront disponibles virtuellement et à identifier également les utilisateurs cibles et leurs emplacements. Ces informations vous aideront à déterminer quel type d’infrastructure App-V 5.1 doit être implémenté. Les décisions relatives à l’étendue du projet doivent être basées sur les besoins spécifiques de votre organisation.
| Tâche | Plus d’informations |
|---|---|
| Déterminer l’étendue de l’application | Selon les applications à virtualiser, l’infrastructure App-V 5.1 peut être configurée de différentes manières. La première tâche consiste à définir les applications que vous souhaitez virtualiser. |
| Déterminer l’étendue de l’emplacement | L’étendue de l’emplacement fait référence aux emplacements physiques (par exemple, à l’échelle de l’entreprise ou à un emplacement géographique spécifique) où vous prévoyez d’exécuter les applications virtualisées. Il peut également faire référence à la population d’utilisateurs (par exemple, un seul service) qui exécutera les applications virtuelles. Vous devez obtenir une carte réseau qui inclut les chemins de connexion ainsi que la bande passante disponible pour chaque emplacement et le nombre d’utilisateurs utilisant des applications virtualisées et la vitesse de liaison WAN. |
Déterminer l’infrastructure App-V 5.1 requise
Important
Les deux modèles suivants nécessitent l’installation du client App-V 5.1 sur l’ordinateur sur lequel vous prévoyez d’exécuter des applications virtuelles.
Vous pouvez également gérer votre environnement App-V 5.1 à l’aide d’une solution de distribution électronique de logiciels (ESD) telle que Microsoft Systems Center Configuration Manager. Pour plus d’informations, consultez Guide pratique pour déployer des packages App-V 5.1 à l’aide de la distribution électronique de logiciels.
Modèle autonome : le modèle autonome permet aux applications virtuelles d’être compatibles avec Windows Installer pour la distribution sans diffusion en continu. App-V 5.1 en mode autonome se compose du séquenceur et du client ; aucun composant supplémentaire n’est requis. Les applications sont préparées pour la virtualisation à l’aide d’un processus appelé séquencement. Pour plus d’informations, consultez Planning for the App-V 5.1 Sequencer and Client Deployment. Le modèle autonome est recommandé pour les scénarios suivants :
Avec des utilisateurs distants déconnectés qui ne peuvent pas se connecter à l’infrastructure App-V 5.1.
Lorsque vous exécutez un système de gestion logicielle, tel que Configuration Manager 2012.
Lorsque les limitations de bande passante réseau empêchent la distribution électronique de logiciels.
Modèle d’infrastructure complète : le modèle d’infrastructure complète fournit des fonctionnalités de distribution, de gestion et de création de rapports de logiciels. il inclut également la diffusion en continu d’applications sur le réseau. Le modèle d’infrastructure complète App-V 5.1 se compose d’un ou plusieurs serveurs d’administration App-V 5.1. Le serveur d’administration peut être utilisé pour publier des applications sur tous les clients. Le processus de publication place les icônes et raccourcis de l’application virtuelle sur l’ordinateur cible. Il peut également diffuser en continu des applications vers des utilisateurs locaux. Pour plus d’informations sur l’installation du serveur d’administration, consultez Planification du déploiement du serveur App-V 5.1. Le modèle d’infrastructure complet est recommandé pour les scénarios suivants :
Important
Le modèle d’infrastructure complète App-V 5.1 nécessite que Microsoft SQL Server stocke les données de configuration. Pour plus d’informations, consultez Configurations prises en charge par App-V 5.1.
Lorsque vous souhaitez utiliser le serveur d’administration pour publier l’application sur les ordinateurs cibles.
Pour l’approvisionnement rapide des applications sur les ordinateurs cibles.
Lorsque vous souhaitez utiliser la création de rapports App-V 5.1.
Guide de dimensionnement de serveur de bout en bout
La section suivante fournit des informations sur le dimensionnement et la planification d’App-V 5.1 de bout en bout. Pour plus d’informations, reportez-vous aux sections suivantes.
Remarque
Le temps de réponse aller-retour sur le client est le temps pris par l’ordinateur exécutant le client App-V 5.1 pour recevoir une notification réussie du serveur de publication. Le temps de réponse aller-retour sur le serveur de publication est le temps pris par l’ordinateur exécutant le serveur de publication pour recevoir une mise à jour réussie des métadonnées de package du serveur d’administration.
20 000 clients peuvent cibler un serveur de publication unique pour obtenir les actualisations du package dans un délai d’aller-retour acceptable. (<3 secondes)
Un serveur d’administration unique peut prendre en charge jusqu’à 50 serveurs de publication pour les actualisations des métadonnées de package dans un délai d’aller-retour acceptable. (<5 secondes)
Recommandations de planification de la capacité du serveur d’administration App-V 5.1
Les serveurs de publication App-V 5.1 nécessitent le serveur d’administration pour les demandes d’actualisation de package et les réponses d’actualisation de package. Le serveur d’administration envoie ensuite les informations à la base de données de gestion pour récupérer des informations. Pour plus d’informations sur les configurations prises en charge par le serveur d’administration App-V 5.1, consultez Configurations prises en charge par App-V 5.1.
Remarque
La durée d’actualisation par défaut sur le serveur de publication App-V 5.1 est de dix minutes.
Lorsque plusieurs serveurs de publication simultanés contactent un seul serveur d’administration pour les actualisations des métadonnées du package, les trois facteurs suivants influencent le temps de réponse aller-retour sur le serveur de publication :
Nombre de serveurs de publication effectuant des requêtes simultanées.
Nombre de groupes de connexions configurés sur le serveur d’administration.
Nombre de groupes d’accès configurés sur le serveur d’administration.
Le tableau suivant présente plus d’informations sur chaque facteur qui a un impact sur le temps aller-retour.
Remarque
Le temps de réponse aller-retour est le temps nécessaire par l’ordinateur exécutant le serveur de publication App-V 5.1 pour recevoir une mise à jour réussie des métadonnées du package du serveur d’administration.
| Facteurs ayant un impact sur le temps de réponse aller-retour | Plus d’informations |
|---|---|
| Nombre de serveurs de publication demandant simultanément des actualisations des métadonnées de package. | - Un serveur d’administration unique peut répondre à jusqu’à 320 serveurs de publication demandant la publication de métadonnées simultanément. |
| - Le temps de réponse aller-retour pour 320 serveurs pub est d’environ 40 secondes. | |
| - Pour <50 serveurs de publication demandant des métadonnées simultanément, le temps de réponse aller-retour est <de 5 secondes. | |
| - De 50 à 320 serveurs de publication, le temps de réponse augmente de façon linéaire (environ 2x). | |
| Nombre de groupes de connexions configurés sur le serveur d’administration. | - Pour jusqu’à 100 groupes de connexions, il n’y a aucune modification significative du temps de réponse aller-retour sur le serveur de publication. |
| - Pour 100 à 400 groupes de connexion, il y a une augmentation linéaire mineure du temps de réponse aller-retour. | |
| Nombre de groupes d’accès configurés sur le serveur d’administration. | - Pour jusqu’à 40 groupes d’accès, il y a une augmentation linéaire (environ 3 fois) du temps de réponse aller-retour sur le serveur de publication. |
Le tableau suivant affiche des exemples de valeurs pour chacun des facteurs précédents. Dans chaque variante, 120 packages sont actualisés à partir du serveur d’administration App-V 5.1.
| Scénario | Variante | Nombre de groupes de connexions | Nombre de groupes d’accès | Nombre de serveurs de publication | Type de connexion réseau serveur de publication/serveur d’administration | Temps de réponse aller-retour sur le serveur de publication (en secondes) | Utilisation du processeur sur le serveur d’administration |
|---|---|---|---|---|---|---|---|
| Les serveurs de publication contactent simultanément le serveur d’administration pour publier des métadonnées. | Nombre de serveurs de publication | 0 | 1 | 50 | Réseau local | 5 | 17 |
| 0 | 1 | 100 | Réseau local | 10 | 17 | ||
| 0 | 1 | 200 | Réseau local | 19 | 17 | ||
| 0 | 1 | 300 | Réseau local | 32 | 15 | ||
| 0 | 1 | 315 | Réseau local | 30 | 17 | ||
| 0 | 1 | 320 | Réseau local | 37 | 15 | ||
| La publication de métadonnées contient des groupes de connexions | Nombre de groupes de connexions | 10 | 1 | 100 | Réseau local | 10 | 17 |
| 50 | 1 | 100 | Réseau local | 11 | 19 | ||
| 100 | 1 | 100 | Réseau local | 11 | 22 | ||
| 150 | 1 | 100 | Réseau local | 16 | 19 | ||
| 300 | 1 | 100 | Réseau local | 22 | 20 | ||
| 400 | 1 | 100 | Réseau local | 25 | 20 | ||
| La publication de métadonnées contient des groupes d’accès | Nombre de groupes d’accès | 0 | 1 | 100 | Réseau local | 10 | 17 |
| 0 | 10 | 100 | Réseau local | 43 | 26 | ||
| 0 | 20 | 100 | Réseau local | 153 | 24 | ||
| 0 | 40 | 100 | Réseau local | 535 | 24 |
L’utilisation du processeur de l’ordinateur exécutant le serveur d’administration est d’environ 25 %, quel que soit le nombre de serveurs de publication qui le ciblent. Les transactions de base de données Microsoft SQL Server/s, les requêtes par lots/s et les connexions utilisateur sont identiques, quel que soit le nombre de serveurs de publication. Par exemple : Transactions/s est d’environ 30, demandes de lot ~200 et connexion utilisateur ~6.
À l’aide d’un déploiement distribué géographiquement, où le serveur d’administration & serveurs de publication utilisent un réseau de liaison lente entre eux, le temps de réponse aller-retour sur les serveurs de publication est dans des limites de temps acceptables (<5 secondes), même pour 100 demandes simultanées sur un serveur d’administration unique.
| Scénario | Variante | Nombre de groupes de connexions | Nombre de groupes d’accès | Nombre de serveurs de publication | Type de connexion réseau serveur de publication/serveur d’administration | Temps de réponse aller-retour sur le serveur de publication (en secondes) | Utilisation du processeur sur le serveur d’administration |
|---|---|---|---|---|---|---|---|
| Connexion réseau entre le serveur de publication et le serveur d’administration | Réseau de liaison lente de 1,5 Mbits/s | 0 | 1 | 50 | DSL câble de 1,5 Mbits/s | 4 | 1 |
| 0 | 1 | 100 | DSL câble de 1,5 Mbits/s | 5 | 2 | ||
| Connexion réseau entre le serveur de publication et le serveur d’administration | Réseau LAN/WI-FI | 0 | 1 | 100 | Wi-Fi | 11 | 15 |
| 0 | 1 | 200 | Wi-Fi | 20 | 17 |
Que le serveur d’administration et les serveurs de publication soient connectés via un réseau à liaison lente ou un réseau à haut débit, le serveur d’administration peut gérer environ 15 000 demandes d’actualisation de package en 30 minutes.
Recommandations relatives à la planification de la capacité du serveur de rapports App-V 5.1
Les clients App-V 5.1 envoient des données de création de rapports au serveur de rapports. Le serveur de rapports enregistre ensuite les informations dans la base de données Microsoft SQL Server et retourne une notification réussie à l’ordinateur exécutant le client App-V 5.1. Pour plus d’informations sur les configurations prises en charge par App-V 5.1 Reporting Server, consultez Configurations prises en charge par App-V 5.1.
Remarque
Le temps de réponse aller-retour est le temps pris par l’ordinateur exécutant le client App-V 5.1 pour envoyer les informations de création de rapports au serveur de rapports et recevoir une notification réussie de la part du serveur de rapports.
| Scénario | Résumé |
|---|---|
| Plusieurs clients App-V 5.1 envoient simultanément des informations de création de rapports au serveur de rapports. | - Le temps de réponse aller-retour du serveur de rapports est de 2,6 secondes pour 500 clients. |
| - Le temps de réponse aller-retour du serveur de rapports est de 5,65 secondes pour 1 000 clients. | |
| - Le temps de réponse aller-retour augmente de façon linéaire en fonction du nombre de clients. | |
| Demandes par seconde traitées par le serveur de rapports. | - Un serveur de rapports unique et une base de données unique peuvent traiter un maximum de 139 demandes par seconde. La moyenne est de 121 demandes par seconde. |
| - En utilisant deux serveurs de rapports pour la même base de données Microsoft SQL Server, la moyenne des requêtes/seconde est similaire à un serveur de rapports unique = ~127, avec un maximum de 278 requêtes/seconde. | |
| - Un serveur de rapports unique peut traiter 500 connexions simultanées/actives. | |
| - Un serveur de rapports unique peut traiter un maximum de 1 500 connexions simultanées. | |
| Base de données de création de rapports. | - La contention de verrous sur l’ordinateur exécutant Microsoft SQL Server est le facteur limitant pour les demandes/secondes. |
| - Le débit et le temps de réponse sont indépendants de la taille de la base de données. |
Calcul du délai aléatoire
Le délai aléatoire spécifie le délai maximal (en minutes) pour l’envoi des données au serveur de rapports. Lorsque la tâche planifiée est démarrée, le client génère un délai aléatoire compris entre 0 et ReportingRandomDelay et attend la durée spécifiée avant d’envoyer des données.
Délai aléatoire = 4 * nombre de clients / demandes moyennes par seconde.
Exemple : Pour 500 clients, avec 120 demandes par seconde, le délai aléatoire est de 4 * 500 / 120 = ~17 minutes.
Recommandations de planification de la capacité du serveur de publication App-V 5.1
Les ordinateurs exécutant le client App-V 5.1 se connectent au serveur de publication App-V 5.1 pour envoyer une demande d’actualisation de publication et recevoir une réponse. Le temps de réponse aller-retour est mesuré sur l’ordinateur exécutant le client App-V 5.1. La durée du processeur est mesurée sur le serveur de publication. Pour plus d’informations sur les configurations prises en charge par Le serveur de publication App-V 5.1, consultez Configurations prises en charge par App-V 5.1.
La liste suivante présente les principaux facteurs à prendre en compte lors de la configuration du serveur de publication App-V 5.1 :
Nombre de clients se connectant simultanément à un serveur de publication unique.
Nombre de packages dans chaque actualisation.
Bande passante réseau disponible dans votre environnement entre le client et le serveur de publication App-V 5.1.
| Scénario | Résumé |
|---|---|
| Plusieurs clients App-V 5.1 se connectent simultanément à un serveur de publication unique. | - Un serveur de publication exécutant des processeurs double cœur peut répondre à au plus 5 000 clients demandant une actualisation simultanément. |
| - Pour 5 000 à 10 000 clients, le serveur de publication nécessite un minimum de quatre cœurs. | |
| - Pour 10 000 à 20 000 clients, le serveur de publication doit avoir deux quatre cœurs pour des temps de réponse plus efficaces. | |
| - Un serveur de publication avec quatre cœurs peut actualiser jusqu’à 10 000 packages en 3 secondes. (Prise en charge de 10 000 clients simultanés) | |
| Nombre de packages dans chaque actualisation. | - L’augmentation du nombre de packages augmente le temps de réponse d’environ 40 % (jusqu’à 1 000 packages). |
| Réseau entre le client App-V 5.1 et le serveur de publication. | - Sur un réseau lent (bande passante de 1,5 Mbits/s), le temps de réponse augmente de 97 % par rapport au réseau local (jusqu’à 1 000 utilisateurs). |
Remarque
L’utilisation du processeur du serveur de publication est toujours élevée pendant l’intervalle de temps où il doit traiter des demandes simultanées (>90 % dans la plupart des cas). Le serveur de publication peut gérer environ 1 500 demandes clientes en 1 seconde.
| Scénario | Variante | Nombre de clients App-V 5.1 | Nombre de packages | Configuration du processeur sur le serveur de publication | Type de connexion réseau serveur de publication / client App-V 5.1 | Temps aller-retour sur le client App-V 5.1 (en secondes) | Utilisation du processeur sur le serveur de publication (en %) |
|---|---|---|---|---|---|---|---|
| Le client App-V 5.1 envoie une demande d’actualisation de publication & reçoit une réponse, chaque requête contenant 120 packages | Nombre de clients | 100 | 120 | Double cœur | Réseau local | 1 | 100 |
| 1000 | 120 | Double cœur | Réseau local | 2 | 99 | ||
| 5000 | 120 | Quad Core | Réseau local | 2 | 89 | ||
| 10000 | 120 | Quad Core | Réseau local | 3 | 77 | ||
| Plusieurs packages dans chaque actualisation | Nombre de packages | 1000 | 500 | Quad Core | Réseau local | 2 | 92 |
| 1000 | 1000 | Quad Core | Réseau local | 3 | 91 | ||
| Réseau entre le client et le serveur de publication | Réseau de liaison lente de 1,5 Mbits/s | 100 | 120 | Quad Core | 1,5 Mbits/s Intra-Continental réseau | 3 | |
| 500 | 120 | Quad Core | 1,5 Mbits/s Intra-Continental réseau | 10 (avec un taux d’échec de 0,2 %) | |||
| 1000 | 120 | Quad Core | 1,5 Mbits/s Intra-Continental réseau | 17 (avec un taux d’échec de 1 %) |
Recommandations relatives à la planification de la capacité de streaming App-V 5.1
Les ordinateurs exécutant le client App-V 5.1 diffusent en continu le package d’application virtuelle à partir du serveur de streaming. Le temps de réponse aller-retour est mesuré sur l’ordinateur exécutant le client App-V 5.1 et correspond au temps nécessaire pour diffuser en continu l’intégralité du package.
La liste suivante identifie les principaux facteurs à prendre en compte lors de la configuration du serveur de streaming App-V 5.1 :
Nombre de clients qui diffusent en continu des packages d’application simultanément à partir d’un serveur de streaming unique.
Taille du package en cours de diffusion en continu.
Bande passante réseau disponible dans votre environnement entre le client et le serveur de streaming.
| Scénario | Résumé |
|---|---|
| Plusieurs clients App-V 5.1 diffusent simultanément des applications à partir d’un même serveur de streaming. | - Si le nombre de clients en streaming simultané à partir du même serveur augmente, il existe une relation linéaire avec le temps de téléchargement/diffusion en continu du package. |
| Taille du package en cours de diffusion en continu. | - La taille du package a un impact significatif sur le temps de streaming/téléchargement uniquement pour les packages plus volumineux d’une taille d’environ 1 Go. Pour les tailles de package comprises entre 3 Mo et 100 Mo, le temps de diffusion en continu est compris entre 20 secondes et 100 secondes, avec 100 clients simultanés. |
| Réseau entre le client App-V 5.1 et le serveur de streaming. | - Sur un réseau lent (bande passante de 1,5 Mbits/s), le temps de réponse augmente de 70 à 80 % par rapport au réseau local (jusqu’à 100 utilisateurs). |
Le tableau suivant affiche des exemples de valeurs pour chacun des facteurs de la liste précédente :
| Scénario | Variante | Nombre de clients App-V 5.1 | Taille de chaque package | Type de connexion réseau serveur de streaming / client App-V 5.1 | Temps aller-retour sur le client App-V 5.1 (en secondes) |
|---|---|---|---|---|---|
| Plusieurs clients App-V 5.1 diffusent en continu des packages d’applications virtuelles à partir d’un serveur de streaming. | Nombre de clients. | 100 | 3,5 Mo | Réseau local | 29 |
| 200 | 3,5 Mo | Réseau local | 39 | ||
| 1000 | 3,5 Mo | Réseau local | 391 | ||
| 100 | 5 Mo | Réseau local | 35 | ||
| 200 | 5 Mo | Réseau local | 68 | ||
| 1000 | 5 Mo | Réseau local | 461 | ||
| Taille de chaque package en cours de diffusion en continu. | Taille de chaque package. | 100 | 21 Mo | Réseau local | 33 |
| 200 | 21 Mo | Réseau local | 83 | ||
| 100 | 109 Mo | Réseau local | 100 | ||
| 200 | 109 Mo | Réseau local | 160 | ||
| Connexion réseau entre le client et le serveur de streaming App-V 5.1. | Réseau de liaison lente de 1,5 Mbits/s. | 100 | 3,5 Mo | 1,5 Mbits/s Intra-Continental réseau | 102 |
| 100 | 5 Mo | 1,5 Mbits/s Intra-Continental réseau | 121 |
Chaque serveur de streaming App-V 5.1 doit être en mesure de gérer au moins 200 clients simultanément en streaming d’applications virtualisées.
Remarque
Le temps réel nécessaire au streaming est déterminé principalement par le nombre de clients en streaming simultané, le nombre de packages, la taille du package, l’activité réseau du serveur et les conditions réseau.
Par exemple, un utilisateur moyen peut diffuser en continu un package de 100 Mo en moins de 2 minutes, lorsque 100 clients simultanés sont diffusés en continu à partir du serveur. Toutefois, un package d’une taille de 1 Go peut prendre jusqu’à 30 minutes. Dans la plupart des environnements réels, la demande de diffusion en continu n’est pas distribuée uniformément, vous devez comprendre les exigences approximatives de diffusion en continu maximale présentes dans votre environnement afin de dimensionner correctement le nombre de serveurs de diffusion en continu requis.
Le nombre de clients qu’un serveur de streaming peut prendre en charge peut être considérablement augmenté et les pics de streaming requis réduits si vous pré-mettez en cache vos applications. Vous pouvez également augmenter le nombre de clients qu’un serveur de streaming peut prendre en charge à l’aide de la distribution de streaming à la demande et de packages optimisés pour le flux.
Combinaison de rôles de serveur App-V 5.1
En réduisant les exigences de mise à l’échelle et de tolérance de panne, le nombre minimal de serveurs nécessaires pour un emplacement avec connectivité à Active Directory en est un. Ce serveur hébergera le serveur d’administration, le service de serveur d’administration et les rôles Microsoft SQL Server. Par conséquent, les rôles serveur peuvent être organisés dans n’importe quelle combinaison souhaitée, car ils ne sont pas en conflit les uns avec les autres.
En ignorant les exigences de mise à l’échelle, le nombre minimal de serveurs nécessaires pour fournir une implémentation à tolérance de panne est de quatre. Le serveur d’administration et les rôles Microsoft SQL Server prennent en charge les configurations à tolérance de panne. Le service de serveur d’administration peut être combiné avec n’importe quel rôle, mais reste un point de défaillance unique.
Bien qu’il existe un certain nombre de stratégies et de technologies de tolérance de panne disponibles, toutes ne sont pas applicables à un service donné. En outre, si des rôles App-V 5.1 sont combinés, certaines options de tolérance de panne peuvent ne plus s’appliquer en raison d’incompatibilités.