Partager via


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é

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 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.

noteRemarque :
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 %.