Planification de la capacité d’App-V
S’applique à : Windows Server 2016
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 pour l’infrastructure App-V de votre organization.
Important
Utilisez les informations de cette section uniquement comme guide général pour planifier votre déploiement App-V. 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, déterminez quelles applications seront disponibles virtuellement et identifiez également les utilisateurs cibles et leurs emplacements. Ces informations déterminent le type d’infrastructure App-V que votre projet doit implémenter. Vous devez baser vos décisions sur l’étendue de votre projet en fonction des besoins spécifiques de votre organization.
| Tâche | Plus d’informations |
|---|---|
| Déterminer l’étendue de l’application | L’infrastructure App-V peut être configurée de différentes façons en fonction des applications que vous souhaitez virtualiser. Cette personnalisation dans la configuration signifie que votre première tâche consiste à définir les applications que vous souhaitez virtualiser. |
| Déterminer l’étendue de l’emplacement | « Étendue de l’emplacement » fait référence aux emplacements physiques où vous prévoyez d’exécuter les applications virtualisées (par exemple, à l’échelle de l’entreprise ou à un emplacement géographique spécifique). Il peut également faire référence à la population d’utilisateurs qui exécutera les applications virtuelles (par exemple, un seul service). Vous devez obtenir une carte réseau qui inclut les chemins de connexion, la bande passante disponible pour chaque emplacement, le nombre d’utilisateurs utilisant des applications virtualisées et la vitesse de liaison WAN. |
Déterminer l’infrastructure App-V requise
Vous pouvez également gérer votre environnement App-V à 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 à 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 en mode autonome n’a besoin que du séquenceur et du client ; aucun composant supplémentaire n’est nécessaire. 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 Sequencer and Client deployment. Le modèle autonome est recommandé pour les scénarios suivants :
- Lorsqu’il existe des utilisateurs distants déconnectés qui ne peuvent pas se connecter à l’infrastructure App-V.
- Lorsque vous exécutez un système de gestion de logiciels, tel que Configuration Manager.
- 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 se compose d’un ou plusieurs serveurs d’administration App-V qui peuvent être utilisés pour publier des applications sur tous les clients. La publication place les icônes d’application virtuelle et les raccourcis 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 d’App-V Server. Le modèle d’infrastructure complet est recommandé pour les scénarios suivants :
- 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.
Important
Le modèle d’infrastructure complète App-V nécessite microsoft SQL Server pour stocker les données de configuration. Pour plus d’informations, consultez Configurations prises en charge par App-V.
Guide de dimensionnement de serveur de bout en bout
La section suivante décrit le dimensionnement et la planification d’App-V 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 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 temps d’aller-retour acceptable (<5 secondes).
Recommandations relatives à la planification de la capacité app-V Management Server
Les serveurs de publication App-V 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, consultez Configurations prises en charge par App-V.
Remarque
La durée d’actualisation par défaut sur le serveur de publication App-V 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 du serveur de publication :
- Nombre de serveurs de publication effectuant des demandes 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 décrit plus en détail 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 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 | Description |
|---|---|
| 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 simultanément des métadonnées de publication. Par exemple, dans un cas où 30 serveurs de publication demandent simultanément des métadonnées de publication, le temps de réponse aller-retour est d’environ 40 secondes, tandis que pour moins de 50 serveurs, il est inférieur à 5 secondes. De 50 à 320 serveurs de publication, l’équipe de réponse augmente de façon linéaire (environ 2×). |
| Nombre de groupes de connexions configurés sur le serveur d’administration. | Pour un maximum de 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 connexions, 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 un maximum de 40 groupes d’accès, il y a une augmentation linéaire (environ 3×) 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.
| Scénario | Variante | Nombre de groupes de connexions | Nombre de groupes d’accès | Nombre de serveurs de publication | Type de connexion réseau | Temps de réponse aller-retour (secondes) | Utilisation du processeur du serveur d’administration |
|---|---|---|---|---|---|---|---|
| Les serveurs de publication contactent le serveur d’administration pour publier des métadonnées en même temps | Nombre de serveurs de publication. | 0 0 0 0 0 0 |
1 1 1 1 1 1 |
50 100 200 300 315 320 |
Réseau local | 5 10 19 32 30 37 |
17 17 17 15 17 15 |
| La publication de métadonnées contient des groupes de connexions | Nombre de groupes de connexions | 10 20 100 150 300 400 |
1 1 1 1 1 1 |
100 100 100 100 100 100 |
Réseau local | 10 11 11 16 22 25 |
17 19 22 19 20 20 |
| La publication de métadonnées contient des groupes d’accès | Nombre de groupes d’accès | 0 0 0 0 |
1 10 20 40 |
100 100 100 100 |
Réseau local | 10 43 153 535 |
17 26 24 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. Microsoft SQL Server les transactions de base de données/s, les demandes de lots/s et les connexions utilisateur sont identiques, quel que soit le nombre de serveurs de publication. Par exemple, les transactions/s sont d’environ 30, les demandes de lot environ 200 et l’utilisateur se connecte environ six.
Par le biais d’un déploiement géographiquement distribué, où le serveur d’administration et les 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 | Temps de réponse aller-retour (secondes) | Utilisation du processeur du serveur d’administration (en %) |
|---|---|---|---|---|---|---|---|
| Connexion réseau entre le serveur de publication et le serveur d’administration | Réseau de liaison lente de 1,5 Mbits/s | 0 0 |
1 1 |
50 100 |
DSL de câble 1,5 Mbits/s | 4 5 |
1 2 |
| Connexion réseau entre le serveur de publication et le serveur d’administration | Réseau LAN/WiFi | 0 0 |
1 1 |
100 200 |
WiFi | 11 20 |
15 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é App-V Reporting Server
Les clients App-V 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. Pour plus d’informations sur les configurations prises en charge par App-V Reporting Server, consultez Configurations prises en charge par App-V.
Remarque
Le temps de réponse aller-retour est le temps pris par l’ordinateur exécutant le client App-V 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 envoient des informations de création de rapports au serveur de rapports simultanément. | 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 linéairement 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. Avec l’aide de deux serveurs de rapports qui rendent compte à la même base de données Microsoft SQL Server, la moyenne des demandes/seconde, comme un serveur de rapports unique, est d’environ 127, avec un maximum de 278 requêtes/seconde. Un serveur de rapports unique peut traiter 500 connexions actives/simultanées. 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 : Le délai aléatoire pour 500 clients avec 120 demandes par seconde est de 4 × 500/120 = environ 17 minutes.
Recommandations relatives à la planification de la capacité du serveur de publication App-V
Les ordinateurs exécutant le client App-V se connectent au serveur de publication App-V 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, tandis que le temps processeur est mesuré sur le serveur de publication. Pour plus d’informations sur les configurations prises en charge par le serveur de publication App-V, consultez Configurations prises en charge par App-V.
Important
La liste suivante affiche les facteurs main à prendre en compte lors de la configuration du serveur de publication App-V :
- 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.
| Scénario | Résumé |
|---|---|
| Plusieurs clients App-V se connectent simultanément à un seul serveur de publication. | 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 trois secondes. (Prend en charge 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 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 une seconde.
| Scénario | Variante | Nombre de clients App-V | Nombre de packages | Configuration du processeur sur le serveur de publication | Type de connexion réseau | Durée d’aller-retour du client App-V (en secondes) | Utilisation du processeur du serveur de publication (en %) |
|---|---|---|---|---|---|---|---|
| Le client App-V envoie une demande d’actualisation de publication et reçoit une réponse, chaque requête contenant 120 packages | Nombre de clients | 100 1,000 5,000 10,000 |
120 120 120 120 |
Double cœur Double cœur Quad Core Quad Core |
Réseau local | 1 2 2 3 |
100 99 89 77 |
| Plusieurs packages dans chaque actualisation. | Nombre de packages | 1,000 1,000 |
500 1,000 |
Quad Core | Réseau local | 2 3 |
92 91 |
| Réseau entre le client et le serveur de publication. | Réseau de liaison lente de 1,5 Mbits/s | 100 500 1,000 |
120 120 120 |
Quad Core | Réseau intra-continental de 1,5 Mbits/s | 3 10 (taux d’échec de 0,2 %) 7 (taux d’échec de 1 %) |
Recommandations de planification de la capacité de streaming App-V
Les ordinateurs exécutant le client App-V 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. Il s’agit du temps nécessaire pour diffuser en continu l’intégralité du package.
Important
La liste suivante identifie les facteurs main à prendre en compte lors de la configuration du serveur de streaming App-V :
- 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 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 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 | Taille de chaque package | Type de connexion réseau | Temps aller-retour sur le client App-V (en secondes) |
|---|---|---|---|---|---|
| Plusieurs clients App-V diffusent en continu des packages d’applications virtuelles à partir d’un serveur de streaming. | Nombre de clients. | 100 200 1,000 100 200 1,000 |
3,5 Mo 3,5 Mo 3,5 Mo 5 Mo 5 Mo 5 Mo |
Réseau local | 29 39 391 35 68 461 |
| Taille de chaque package en cours de diffusion en continu. | Taille de chaque package. | 100 200 100 200 |
21 Mo 21 Mo 109 Mo 109 Mo |
Réseau local | 33 83 100 160 |
| Connexion réseau entre le client et le serveur de streaming App-V. | Réseau de liaison lente de 1,5 Mbits/s. | 100 100 |
3,5 Mo 5 Mo |
Réseau intra-continental de 1,5 Mbits/s | 102 121 |
Chaque serveur de streaming App-V doit être en mesure de gérer un minimum de 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 streaming n’est pas distribuée uniformément. Vous devez comprendre les exigences approximatives de diffusion en continu maximale présentes dans votre environnement pour 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 augmenté et les exigences de diffusion en continu maximale réduites 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
Si l’on tient compte des exigences de mise à l’échelle et de tolérance de panne, le nombre minimal de serveurs dont un emplacement disposant d’une connectivité Active Directory doit fonctionner est 1. Ce serveur hébergera le serveur d’administration, le service de serveur d’administration et les rôles Microsoft SQL Server. Cette couverture signifie que vous pouvez organiser les rôles de serveur dans n’importe quelle combinaison de votre choix, car ils ne sont pas en conflit les uns avec les autres.
En dépit des exigences de mise à l’échelle, le nombre minimal de serveurs dont une implémentation à tolérance de panne doit fonctionner est de quatre. Le serveur d’administration et les rôles Microsoft SQL Server prennent en charge le placement dans 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 de nombreuses stratégies et technologies de tolérance de panne que vous pouvez utiliser, toutes ne sont pas applicables à un service donné. En outre, si des rôles App-V sont combinés, les incompatibilités qui en résultent peuvent entraîner l’arrêt de certaines options de tolérance de panne.