Exemple d'estimation de la puissance de traitement

Cette section illustre une méthode d'estimation de la puissance de traitement requise pour un exemple de déploiement. Cet exemple est fondé sur l'architecture logique d'une solution de communications basées sur les identités pour une entreprise de taille moyenne d'environ 1 000 à 5 000 salariés, tel que décrit dans la section Exemple de communications basées sur les identités.

Les estimations mentionnées pour les CPU et la mémoire sont arbitraires et fournies à titre d'exemple uniquement. Elles sont fondées sur les données arbitraires sur lesquelles s'appuie l'exemple. Seule une analyse exhaustive de divers facteurs permet d'établir les besoins en termes de puissance de traitement. Cette analyse porte notamment sur les éléments suivants :

• cas d'utilisation détaillés et analyse d'utilisation fondée sur une analyse d'exploitation exhaustive ;

• exigences de qualité de service déterminée par l'analyse des exigences de l'entreprise ;

• coûts particuliers et spécifications du matériel réseau et de traitement ;

• expérience acquise lors de déploiements similaires.

---

Attention –

Les informations présentées dans les exemples ci-après ne constituent pas des conseils d'implémentation à proprement parler. Elles sont uniquement destinées à illustrer un processus que vous serez peut-être amené à utiliser lors de la conception d'un système.

---

Estimation du nombre de CPU requises pour les points d'entrée utilisateur

Commencez par évaluer le nombre de CPU nécessaires pour gérer la charge incombant à chaque composant représentant un point d'entrée utilisateur. Le schéma ci-dessous illustre l'architecture logique d'un scénario de communications basées sur les identités décrit dans la section Exemple de communications basées sur les identités.

Figure 5–1 Architecture logique d'un scénario de communications basées sur les identités

Le tableau ci-dessous répertorie les composants du niveau présentation de l'architecture logique qui fournissent une interface directe aux utilisateurs finals du déploiement. Il présente une estimation de base du nombre de CPU requises, obtenue à partir de l'analyse des exigences techniques, des cas d'utilisation, de l'analyse d'utilisation spécifique et de l'expérience acquise grâce à des déploiements similaires.

Tableau 5–1 Estimation du nombre de CPU pour les composants contenant des points d'entrée utilisateur

Composant	Nombre de CPU	Description
Portal Server	4	Composant constituant un point d'entrée utilisateur.
Communications Express	2	Achemine les données vers les canaux de messagerie et de calendrier de Portal Server.

Inclusion du nombre de CPU estimé pour les services dépendants

Les composants fournissant des points d'entrée utilisateur doivent être secondés par d'autres composants Java Enterprise System. Au cours de la définition des exigences de performances, incluez les estimations de performances requises pour les composants de support. Les types d'interactions entre composants doivent être décrits en détail lors de la conception de l'architecture logique, comme le montrent les exemples d'architecture logique présentés à la section Exemple d'architecture logique.

Tableau 5–2 Estimation du nombre de CPU pour les composants de support

Composant	Nombre de CPU	Description
Messaging Server MTA (entrant)	1	Achemine les messages entrants depuis Communications Express et les clients de messagerie.
Messaging Server MTA (sortant)	1	Achemine les messages sortants vers les destinataires.
Messaging Server MMP	1	Accède à la mémoire des messages de Messaging Server pour les clients de messagerie.
Messaging Server STR (Message Store)	1	Extrait et stocke les messages.
Access Manager	2	Fournit des services d'authentification et d'autorisation.
Calendar Server (arrière-plan)	2	Extrait et stocke les données de calendrier pour Communications Express, composant frontal de Calendar Server.
Directory Server	2	Fournit les services d'annuaire LDAP.
Web Server	0	Fournit la prise en charge de conteneur Web pour Portal Server et Access Manager.  (Aucun cycle de CPU supplémentaire n'est nécessaire.)

Étude des cas d'utilisation pour les charges de pointe

Revenez aux cas d'utilisation et à l'analyse d'utilisation pour identifier les situations de charge de pointe et modifiez vos estimations en conséquence.

Toujours dans le cadre de notre exemple, supposons que vous releviez les conditions de charge de pointe suivantes :

• pic de trafic initial lorsque les utilisateurs se connectent simultanément ;

• échanges de messages au cours de certaines périodes.

Pour prendre en compte ces conditions, vous devez effectuer des ajustements pour les composants fournissant ces services. Le tableau ci-dessous décrit les ajustements à effectuer.

Tableau 5–3 Ajustement de l'estimation du nombre de CPU pour les charges de pointe

Composant	Nombre de CPU (ajusté)	Description
Messaging Server MTA (entrant)	2	Ajoutez une CPU pour les messages entrants supplémentaires
Messaging Server MTA (sortant)	2	Ajoutez une CPU pour les messages sortants supplémentaires
Messaging Server MMP	2	Ajoutez une CPU pour la charge supplémentaire
Messaging Server STR (Message Store)	2	Ajoutez une CPU pour la charge supplémentaire
Directory Server	3	Ajoutez une CPU pour les recherches LDAP supplémentaires

Modification des estimations pour les autres conditions de charge

Poursuivez votre estimation du nombre de CPU en tenant compte des autres exigences de qualité de service susceptibles d'avoir un impact sur la charge :

• Securité : au cours de la phase de spécification technique, déterminez si le transport sécurisé des données peut affecter les exigences de charge et modifiez vos estimations en conséquence. La section Estimation de la puissance de traitement requise pour les transactions sécurisées explique comment procéder à ces modifications.

• Réplication des services : ajustez vos estimations en tenant compte de la réplication des services à des fins de disponibilité, d'équilibrage de charge et d'évolutivité. La section suivante, Identification des stratégies de disponibilité, décrit le concept de dimensionnement dans le cadre des solutions de disponibilité. La section Identification des stratégies d'évolutivité décrit les solutions permettant un accès efficace aux services d'annuaire.

• Capacité latente et évolutivité : modifiez le nombre de CPU estimé en fonction de la capacité latente requise pour faire face aux charges importantes et imprévues. Examinez les étapes de mise à l'échelle et l'augmentation de la charge prévues et assurez-vous que toutes les dates planifiées pour la mise à l'échelle horizontale ou verticale du système pourront être respectées.

Mise à jour du nombre de CPU estimé

Il est généralement préférable d'avoir un nombre pair de CPU. Cela permet de diviser équitablement le nombre de CPU entre deux serveurs physiques et d'ajouter un petit facteur pour la capacité latente. Toutefois, lorsque vous définissez le nombre de CPU, tenez compte de vos besoins spécifiques en matière de réplication des services.

Comptez normalement deux gigaoctets de mémoire pour chaque CPU. La quantité réelle de mémoire requise dépend de vos besoins spécifiques. Elle peut être déterminée en phase de test.

Le tableau ci-dessous indique les estimations finales pour l'exemple de communications basées sur les identités. Ces estimations ne tiennent pas compte de la puissance de traitement éventuellement ajoutée à des fins de sécurité et de disponibilité. Ces valeurs seront ajoutées dans les sections qui suivent.

Tableau 5–4 Ajustement de l'estimation du nombre de CPU pour les composants de support

Composant	Nombre de CPU	Mémoire
Portal Server	4	8 Go
Communications Express	2	4 Go
Messaging Server (MTA, entrant)	2	4 Go
Messaging Server (MTA, sortant)	2	4 Go
Messaging Server (MMP)	2	4 Go
Messaging Server (Message Store)	2	4 Go
Access Manager	2	4 Go
Calendar Server	2	4 Go
Directory Server	4	8 Go (valeur arrondie à partir de 3 CPU pour 6 Go de mémoire)
Web Server	0	0