Guide de planification du déploiement de Sun Java Enterprise System 2005Q4

Estimation de la puissance de traitement

Cette section décrit un processus permettant d'estimer le nombre de processeurs et la quantité de mémoire nécessaires pour prendre en charge les services d'une conception de déploiement. Elle présente un exemple de processus appliqué à un déploiement dans le secteur des communications.

L'estimation de la puissance de traitement des CPU est un processus itératif prenant en compte les éléments suivants :

Le processus d'estimation s'articule autour des étapes décrites ci-dessous. Bien qu'il ne soit pas essentiel, l'ordre de ces étapes fournit un exemple de méthode à suivre lors de la prise en compte des facteurs susceptibles d'influencer le résultat final.

  1. Définissez une estimation du nombre de CPU requises pour les composants identifiés en tant que points d'entrée utilisateur dans le système.

    Vous devez décider si les CPU doivent supporter une charge complète ou partielle. Une charge complète augmente la capacité du système. L'augmentation de la capacité vous expose néanmoins à une hausse des coûts de maintenance et à des temps d'indisponibilité dus à l'ajout de CPU. Dans certains cas, vous pouvez décider d'ajouter des machines pour répondre à l'augmentation des exigences en matière de performances.

    Une charge partielle permet de faire face aux exigences de performances supplémentaires sans hausse immédiate des coûts de maintenance. Toutefois, un système sous-utilisé entraîne une augmentation des frais directs.

  2. Modifiez l'estimation du nombre de CPU requises en fonction des interactions entre composants.

    Examinez ces interactions dans l'architecture logique afin de déterminer la charge supplémentaire entraînée par les dépendances entre composants.

  3. Dans l'analyse d'utilisation, examinez les cas d'utilisation afin d'identifier les charges de pointe, puis effectuez les ajustements nécessaires pour les composants qui gèrent ces charges.

    Commencez par les cas pour lesquels la charge est la plus importante, puis passez en revue tous les autres cas pour prendre en compte l'intégralité des scénarios d'utilisation prévus.

  4. Modifiez le nombre de CPU estimé en fonction des exigences de sécurité, de disponibilité et d'évolutivité.

Les estimations établies constituent un point départ à partir duquel déterminer la puissance de traitement réelle dont vous avez besoin. Elles vous permettront également de créer des prototypes de déploiement, que vous soumettrez à des tests rigoureux en fonction des cas d'utilisation prévus. Seul un test itératif vous permettra de déterminer les besoins réels d'une conception de déploiement en termes de puissance de traitement.

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 :


Attention – 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

Diagramme montrant les composants logiques d'un scénario de communications basées sur les identités déployé dans une architecture à plusieurs niveaux.

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 

Composant constituant un point d'entrée utilisateur. 

Communications Express 

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) 

Achemine les messages entrants depuis Communications Express et les clients de messagerie. 

Messaging Server MTA (sortant) 

Achemine les messages sortants vers les destinataires. 

Messaging Server MMP

Accède à la mémoire des messages de Messaging Server pour les clients de messagerie. 

Messaging Server STR (Message Store)

Extrait et stocke les messages. 

Access Manager

Fournit des services d'authentification et d'autorisation. 

Calendar Server (arrière-plan)

Extrait et stocke les données de calendrier pour Communications Express, composant frontal de Calendar Server.  

Directory Server

Fournit les services d'annuaire LDAP. 

Web Server

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 :

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) 

Ajoutez une CPU pour les messages entrants supplémentaires 

Messaging Server MTA (sortant) 

Ajoutez une CPU pour les messages sortants supplémentaires 

Messaging Server MMP 

Ajoutez une CPU pour la charge supplémentaire 

Messaging Server STR (Message Store) 

Ajoutez une CPU pour la charge supplémentaire 

Directory Server 

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 :

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 

8 Go 

Communications Express 

4 Go 

Messaging Server (MTA, entrant) 

4 Go 

Messaging Server (MTA, sortant) 

4 Go 

Messaging Server (MMP) 

4 Go 

Messaging Server (Message Store) 

4 Go 

Access Manager 

4 Go 

Calendar Server 

4 Go 

Directory Server 

8 Go (valeur arrondie à partir de 3 CPU pour 6 Go de mémoire) 

Web Server