Planification de la capacité pour la mobilité
Dernière rubrique modifiée : 2011-12-05
La détermination de la capacité nécessaire à la mobilité est un processus itératif d’estimation de votre utilisation de la mobilité, de mesure de votre capacité actuelle, de planification de capacité supplémentaire et de contrôle d’indicateurs de performance clés. La figure suivante illustre les phases impliquées dans la planification de la capacité et les facteurs impliqués dans chaque phase.
Flux de travail Planification de la capacité pour la mobilité
.jpg "015701c0-77a2-4622-9c01-76576dea0140")
Cette section décrit les facteurs à considérer pour estimer votre utilisation de la mobilité et fournit des instructions permettant de déterminer le dimensionnement dont vous avez besoin pour déployer la mobilité.
Pour plus d’informations sur la surveillance des indicateurs d’utilisation et de performance, voir ce qui suit :
Pour plus d’informations sur la surveillance de la mémoire du serveur, voir Surveillance des limites de capacité de mémoire des serveurs.
Pour plus d’informations sur la surveillance de l’utilisation de la mobilité, voir Surveillance de l’utilisation du service de mobilité.
Pour plus d’informations sur la surveillance des fichiers journaux de suivi des services Internet (IIS), voir Surveillance des fichiers journaux de suivi des demandes IIS.
Pour plus d’informations sur les compteurs de performances que vous pouvez utiliser pour surveiller la mobilité, voir Compteurs de performances de mobilité.
Pour plus d’informations sur la configuration du service de mobilité à des fins de hautes performances, voir Configuration du service de mobilité pour de hautes performances.
Facteurs influant sur la capacité
Trois facteurs influencent votre planification de capacité pour les serveurs frontaux exécutant le service de mobilité Microsoft Lync Server 2010 :
Modèle utilisateur
Caractéristiques de l’appareil mobile
Mémoire vive disponible
Modèle utilisateur
Le modèle utilisateur présenté dans cette section sert de base pour les mesures de planification de capacité et les recommandations en matière de mobilité.
Nombre moyen de contacts par utilisateur
| Catégorie de contacts | Nombre moyen par utilisateur |
|---|---|
Tous les contacts |
80 |
Contacts d’entreprise |
64 |
Contacts fédérés |
8 |
Contacts PIC |
6 |
Groupes de distribution |
2 |
Contacts le plus souvent utilisés |
15 |
Derniers contacts utilisés |
10 |
Activité quotidienne par utilisateur
| Activité quotidienne | Nombre pendant les heures de travail | Nombre en dehors des heures de travail |
|---|---|---|
Connexions à une application mobile |
10 |
2 |
Appels téléphoniques (nombre) |
10 |
2 |
Appels téléphoniques (durée) |
2 minutes par appel |
2 minutes par appel |
Conférences |
1 par semaine |
0 |
Participants par conférence |
<10 |
0 |
Modifications de note de statut |
1 |
0 |
Affichages de carte de visite |
6 |
1 |
Affichage de la liste des contacts |
9 |
1 |
Défilements de la liste des contacts |
3 |
0 |
Recherches dans la liste d’adresses globale |
5* |
- |
Mises à jour manuelles de la présence |
0.5 |
0 |
Nombre total de mises à jour de la présence par contact |
6 |
0 |
Transfert d’appel |
0.5 |
0 |
Sessions de messagerie instantanée (nombre) |
3 |
1 |
Sessions de messagerie instantanée (durée) |
6 minutes par session ; 1 message toutes les 30 secondes |
6 minutes par session ; 1 message toutes les 30 secondes |
Consultations du calendrier (connexions aux services Web Exchange) |
11 |
3 |
* Nombre de recherches dans la liste d’adresses globale = 1 recherche manuelle par jour + recherches automatiques sur la moitié des messages instantanés et appels sortants. Soit, 1 + 2 (messages instantanés) + 2 (appels) = 5.
Caractéristiques de l’appareil mobile
Les appareils mobiles pris en charge pour la mobilité exécutent une diversité de systèmes d’exploitation. La façon dont un système d’exploitation gère les applications lorsqu’un utilisateur bascule vers une autre application a des répercussions sur la planification de la capacité. Il est possible de diviser les systèmes d’exploitation dans les deux catégories suivantes pour la planification de la capacité :
Compatibles avec l’arrière-plan Lorsqu’un utilisateur bascule vers une autre application mobile sur des appareils mobiles Apple et Windows Phone, l’application mobile Lync 2010 passe à l’arrière-plan et perd la connexion à Lync Server 2010. L’application mobile est réactivée par une notification push ou lorsque l’utilisateur la fait passer manuellement au premier plan.
Toujours connectés Lorsqu’un utilisateur bascule vers une autre application mobile sur des appareils mobiles Android et Nokia, l’application mobile Lync 2010 maintient la connexion à Lync Server 2010 tant que l’utilisateur reste connecté.
Les appareils mobiles Android et Nokia créent une charge plus importante sur les serveurs car ils maintiennent la connexion au serveur même lorsque l’utilisateur n’est pas en train d’utiliser activement l’application mobile.
Mémoire disponible
Les instructions de dimensionnement décrites ultérieurement dans cette section vous aideront à définir la quantité de mémoire dont vous avez besoin pour la mobilité. Pour déterminer la quantité de mémoire physique disponible sur vos serveurs, utilisez le compteur de performances Mémoire, Mégaoctets disponibles. Ce dernier indique la quantité de mémoire physique, en mégaoctets, disponible pour exécuter des processus. Si cette quantité est inférieure à cinq pour cent (5 %) de la mémoire physique totale, le serveur n’a pas assez de mémoire, ce qui peut augmenter la pagination.
Instructions de dimensionnement
Le service de mobilité utilise une quantité supplémentaire de mémoire, de ressources processeur et de ressources réseau sur les serveurs frontaux. Lorsque vous planifiez la capacité, vous devez comprendre l’impact de la charge de la mobilité sur le pool de serveurs frontaux afin de décider si vous avez besoin de matériel supplémentaire pour cette charge de la mobilité. Utilisez les exemples de dimensionnement présentés dans le tableau ci-après afin de déterminer si du matériel supplémentaire est nécessaire, et lequel.
Les exemples mentionnés dans le tableau se basent sur des formules et hypothèses. Celles-ci utilisent les définitions suivantes :
TC représente le nombre d’applications mobiles toujours connectées dans le modèle utilisateur.
CAP représente le nombre d’applications mobiles compatibles avec l’arrière-plan dans le modèle utilisateur.
Les formules et hypothèses sont les suivantes :
Mémoire cible en mégaoctets = 164 + (TC * 534 + CAP * 400) / 1024.
La mémoire cible correspond à la quantité de mémoire minimale requise.
Avec le modèle utilisateur décrit précédemment, le nombre de connexions au pool de serveurs frontaux s’élève à TC * 2 + CAP * 0,20.
La mémoire mesurée peut être supérieure (jusqu’à 1 Mo par point de terminaison) en cas d’absence de sollicitation de la mémoire sur le serveur. La mémoire cible peut être supérieure si votre modèle utilisateur est plus agressif, notamment lorsque le nombre d’appels ou de contacts audio/vidéo est plus élevé, et ainsi de suite.
Le nombre de connexions créées par seconde est inférieur ou égal à 30/seconde pour 1 000 utilisateurs. Ce nombre dépend des paramètres de regroupement de connexions définis sur le programme d’équilibrage de la charge matérielle et des paramètres de persistance.
Le tableau suivant présente des exemples de dimensionnement pour 50 % d’utilisateurs toujours connectés dans le modèle utilisateur.
Exemples de dimensionnement
| Nombre d’utilisateurs | Mémoire (Mo) | UC moyenne | UC maximale |
|---|---|---|---|
1 000 |
620,05 |
1 % |
2,5 % |
2 000 |
1076,11 |
6 % |
8 % |
3 000 |
1532,16 |
14 % |
18 % |
4 000 |
1988,22 |
14 % |
18 % |
5 000 |
2444,27 |
14 % |
18 % |
Exemples de scénarios
Les exemples suivants illustrent la façon d’appliquer les instructions de dimensionnement à une grande entreprise fictive et à un pool de serveurs frontaux qui inclut deux serveurs.
Grande entreprise
Contoso a déployé 75 000 utilisateurs sur trois pools avec quatre serveurs frontaux dans chaque pool. L’entreprise envisage d’activer les services de mobilité pour 30 000 utilisateurs.
Pendant la phase de planification, les administrateurs Contoso capturent les données suivantes :
Chaque serveur frontal possède 3 Go de mémoire disponible.
L’utilisation UC est inférieure à 60 %.
Tous les utilisateurs possèdent un appareil mobile iPhone ou Windows Phone.
Le modèle utilisateur de Contoso est similaire au modèle utilisateur de planification de la capacité décrit précédemment dans cette section.
La quantité minimale de mémoire requise pour chaque serveur s’élève à 164 + 2500 * 400 / 1024 = 1133 Mo. Lorsqu’il existe de la mémoire disponible, il est possible d’allouer davantage de mémoire aux applications mobiles car la mémoire est libérée en fonction des besoins, jusqu’à 2,7 Go. Dans les deux cas, Contoso n’a pas besoin de mettre à niveau le matériel du serveur frontal.
.gif "note") Remarque : |
|---|
| L’objectif de l’utilisation UC par la mobilité s’élève à 10 % en moyenne. Contoso a besoin de surveiller le temps processeur lorsqu’il approche la limite du serveur s’élevant à 70 %. |
pool de serveurs frontaux avec deux serveurs
Contoso a déployé 8 000 utilisateurs dans un pool de serveurs frontaux comprenant deux serveurs. L’entreprise envisage d’activer les services de mobilité pour tous les utilisateurs.
Pendant la phase de planification, les administrateurs Contoso capturent les données suivantes :
Chaque serveur frontal possède 2,5 Go de mémoire disponible.
L’utilisation UC est inférieure à 60 %.
Tous les utilisateurs possèdent un appareil mobile Nokia ou Android.
Le modèle utilisateur de Contoso est similaire au modèle utilisateur de planification de la capacité décrit précédemment dans cette section.
La quantité minimale de mémoire requise pour chaque serveur s’élève à 164 + 4000 * 534 / 1024 = 2242 Mo. En théorie, un serveur peut supporter la charge. Toutefois, il ne la supportera pas si un basculement se produit entre les deux serveurs. En outre, l’utilisation UC par la mobilité dépassera 10 % et la limite UC du serveur définie à 70 % sera atteinte.
Dans ce scénario, il est recommandé d’ajouter un serveur au pool. La nouvelle distribution de la charge s’élève à 2667 (soit, 8000/3) utilisateurs par serveur frontal. Le coût de mobilité supplémentaire s’élève à 2667 * 534 / 1024 = 1390 Mo.
En ajoutant un serveur, en cas de panne d’un serveur, chacun des trois serveurs du pool acceptera 1 300 utilisateurs supplémentaires et l’augmentation de la charge s’élèvera à 600 Mo. Avec la nouvelle distribution de la charge, l’utilisation UC restera aussi en dessous de la limite du serveur définie à 70 %.