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

Estimation de la puissance de traitement requise pour les transactions sécurisées

Le transport sécurisé de données implique le traitement des transactions par le biais d'un protocole de transport sécurisé tel SSL (Secure Sockets Layer) ou TLS (Transport Layer Security). Ces transactions exigent généralement une puissance de traitement supplémentaire pour établir une session sécurisée (handshake), puis pour chiffrer et déchiffrer les données transportées. Selon l'algorithme de chiffrement utilisé (40 ou 128 bits, par exemple), cette puissance supplémentaire peut être significative.

Pour que les transactions sécurisées puissent s'exécuter au même niveau que les transactions non sécurisées, vous devez prévoir une puissance de traitement supplémentaire. Selon leur nature et les services Sun JavaTM Enterprise System qui les gèrent, les transactions sécurisées peuvent exiger une puissance de traitement jusqu'à quatre fois supérieure à celle des transactions non sécurisées.

Lors de l'évaluation de la puissance de traitement destinée à gérer les transactions sécurisées, analysez les cas d'utilisation afin de déterminer le pourcentage de transactions nécessitant un transport sécurisé. Si les exigences de performances des transactions sécurisées sont identiques à celles des transactions non sécurisées, modifiez l'estimation du nombre de CPU en tenant compte de la puissance de traitement supplémentaire requise par les transactions sécurisées.

Dans certains scénarios d'utilisation, le transport sécurisé est requis uniquement pour l'authentification. Une fois l'utilisateur authentifié sur le système, aucune mesure de sécurité supplémentaire n'est appliquée au transport des données. Dans d'autres scénarios, le transport sécurisé est exigé pour toutes les transactions.

Par exemple, lors de la consultation d'un catalogue de produits sur un site d'e-commerce en ligne, il n'est pas nécessaire de sécuriser les transactions tant que le client n'a pas choisi tous ses articles et qu'il n'est pas prêt à effectuer le paiement. Toutefois, dans certains scénarios de déploiement appliqués à des banques ou à des agences immobilières, par exemple, la plupart des transactions doivent être sécurisées et les mêmes performances sont attendues de toutes les transactions, qu'elles soient ou non sécurisées.

Estimation du nombre de CPU pour les transactions sécurisées

Cette section utilise le même exemple de déploiement pour illustrer le mode de calcul du nombre de CPU nécessaires pour un cas d'utilisation hypothétique mettant en œuvre à la fois des transactions sécurisées et non sécurisées.

Pour estimer le nombre de CPU requises pour les transactions sécurisées, effectuez les calculs suivants :

  1. Partez d'une estimation du nombre de CPU requises (voir la section précédente, Exemple d'estimation de la puissance de traitement).

  2. Calculez le pourcentage de transactions exigeant un transport sécurisé, puis le nombre de CPU nécessaires pour ces transactions.

  3. Comptez un nombre de CPU inférieur pour les transactions non sécurisées.

  4. Additionnez les valeurs obtenues pour parvenir à une estimation du nombre total de CPU nécessaires.

  5. Arrondissez cette estimation à une valeur paire.

La section Estimation du nombre de CPU pour les transactions sécurisées montre un exemple de calcul fondé sur des cas d'utilisation et une analyse d'utilisation pour Portal Server et tenant compte des hypothèses suivantes :

Tableau 5–5 Modification du nombre de CPU estimé pour les transactions sécurisées

Étape 

Description 

Calcul 

Résultat 

Partez d'une estimation de base pour toutes les transactions Portal Server. 

Cette estimation, issue de la section Étude des cas d'utilisation pour les charges de pointe est de 4 CPU.

- - - - - 

Calculez l'estimation du nombre de CPU supplémentaires pour les transactions sécurisées. Supposez que celles-ci exigent une puissance de traitement quatre fois supérieure à celle des transactions non sécurisées. 

10% des transactions (estimation de base) doivent faire l'objet d'un transport sécurisé : 

 

0.10 x 4 CPUs = 0.4 CPUs

 

Augmentez la puissance de traitement pour les transactions sécurisées selon un facteur de 4 : 

 

4 x 0.4 = 1.6 CPUs

1,6 CPU 

Comptez un nombre de CPU inférieur pour les transactions non sécurisées. 

90% des transactions (estimation de base) ne sont pas sécurisées : 

 

0.9 x 4 CPUs = 3.6 CPUs

3,6 CPU 

Calculez le nombre total de CPU estimé pour les transactions sécurisées et non sécurisées.  

Transactions sécurisées + non sécurisées = total : 

 

1.6 CPUs + 3.6 CPUs = 5.2 CPUs

5,2 CPU 

Arrondissez le résultat à une valeur paire.  

5.2 CPUs ==> 6 CPUs

6 CPU 

Sur la base des calculs effectués pour les transactions sécurisées dans cet exemple, vous devez modifier le nombre total de CPU estimé à la section Estimation du nombre de CPU pour les transactions sécurisées en ajoutant deux CPU et quatre gigaoctets de mémoire afin de parvenir au total ci-dessous pour Portal Server :

Composant 

Nombre de CPU 

Mémoire 

Portal Server 

12 Go 

Matériel dédié au traitement des transactions SSL

Du matériel spécialisé, tel des cartes d'accélération SSL et d'autres équipements, est disponible pour fournir la puissance de traitement nécessaire à l'établissement de sessions sécurisées et au chiffrement/déchiffrement des données. Lorsque ce type de matériel est utilisé, une partie de la puissance de traitement est consacrée à certains calculs SSL, notamment l'opération de « handshake » permettant d'établir la session sécurisée.

L'utilisation de ce type de matériel peut être un avantage pour votre architecture de déploiement. Toutefois, en raison de son caractère spécialisé, il est préférable d'estimer les exigences de performances des transactions sécurisées d'abord en termes de puissance de traitement, puis d'envisager les avantages liés à l'utilisation de ce matériel pour gérer la charge supplémentaire.

Avant d'utiliser ce type de matériel, vous devez déterminer s'il est pris en charge par les cas d'utilisation (ceux qui nécessitent un grand nombre d'opérations de handshake SSL, par exemple) et tenir compte du surcroît de complexité qu'il engendre en termes de conception. Cette complexité se retrouve dans les opérations d'installation, de configuration, de test et d'administration du matériel.