Chapitre 5 Conception du déploiement
Au cours de la phase de conception du déploiement de la solution, vous préparez une architecture de déploiement de haut niveau et une spécification d'implémentation de bas niveau, et élaborez un ensemble de plans et de spécifications nécessaires à l'implémentation de la solution. L'approbation du projet intervient au cours de cette phase.
Il se compose des sections suivantes:
À propos de la conception du déploiement
La conception du déploiement se fonde sur le scénario de déploiement créé au cours des phases de conception logique et de spécifiation technique du cycle de vie de la solution. Un scénario de déploiement présente l'architecture logique associée aux exigences de qualité de service (QoS) pour cette solution. Pour créer une architecture de déploiement, vous mappez les composants identifiés dans l'architecture logique sur les serveurs physiques et les autres périphériques réseau. Les exigences de qualité de service permettent de configurer le matériel en vue d'obtenir des performances, une disponibilité et une évolutivité optimales.
La conception de l'architecture de déploiement est un processus itératif. Celui-ci consiste généralement à réexaminer les exigences de qualité de service et les conceptions préliminaires. Vous devez tenir compte des relations existant entre les différentes exigences de qualité de service ainsi que des problèmes liés aux coûts de possession et, après avoir évalué les avantages et les inconvénients, parvenir à une solution optimale permettant d'atteindre les objectifs d'exploitation du projet.
Approbation du projet
L'approbation du projet intervient au cours de la phase de conception du déploiement, généralement après la création de l'architecture de déploiement. À l'aide de l'architecture de déploiement et, éventuellement, des spécifications d'implémentation décrites ci-dessous, le coût réel du déploiement est estimé et soumis aux parties prenantes pour approbation. Une fois le projet approuvé, les contrats relatifs à l'exécution du déploiement sont signés et les ressources destinées à l'implémentation du projet sont acquises et allouées.
Résultats de la conception du déploiement
Lors de la phase de conception du déploiement, vous pouvez préparer les spécifications et les plans suivants :
-
Architecture de déploiement : architecture de haut niveau qui décrit le mappage d'une architecture logique sur un environnement physique. Celui-ci comprend les nœuds de traitement dans un environnement intranet ou Internet, les processeurs, la mémoire, les périphériques de stockage et tout autre type de matériel et de périphérique réseau.
-
Spécifications d'implémentation : spécifications détaillées servant à la planification du déploiement. Elles décrivent le matériel à acheter et la structure du réseau. Elles définissent également les services d'annuaire, y compris l'arborescence d'informations d'annuaire, et les groupes et rôles définis pour l'accès à l'annuaire.
-
Plans d'implémentation : groupe de plans couvrant divers aspects de l'implémentation d'une solution logicielle d'entreprise. Ces plans sont les suivants :
-
Plan de migration : décrit les stratégies et les processus de migration des données et de mise à niveau des logiciels de l'entreprise. Les données migrées doivent respecter les formats et les standards des nouvelles applications installées. Tous les logiciels de l'entreprise doivent avoir un niveau de version leur permettant d'interagir les uns avec les autres.
-
Plan d'installation : issu de l'architecture de déploiement, il spécifie les noms des serveurs matériels, les répertoires d'installation, la séquence d'installation, le type d'installation de chaque nœud ainsi que les informations de configuration requises pour installer et configurer un déploiement distribué.
-
Plan de gestion des utilisateurs : comprend des stratégies de migration pour les données des répertoires et des bases de données existants, des spécifications de structure des répertoires prenant en compte les mécanismes de réplication définis dans l'architecture de déploiement, ainsi que des procédures permettant d'alimenter les répertoires par un nouveau contenu.
-
Plan de test : décrit les procédures de test des logiciels déployés, y compris les plans permettant de développer des implémentations de prototypes et de pilotes, les tests destinés à mesurer la capacité du système à traiter la charge de travail, ainsi que les tests permettant de déterminer si une fonctionnalité se comporte comme prévu.
-
Plan de déploiement : présente les procédures et le planning utilisés pour faire passer l'implémentation de l'environnement de planification et de test à l'environnement de production. Cette opération se déroule généralement en plusieurs phases. La première phase peut par exemple consister à déployer le logiciel auprès d'un groupe réduit d'utilisateurs, puis d'augmenter progressivement le nombre de ces utilisateurs jusqu'à ce que le déploiement soit terminé. L'implémentation par phases peut également prévoir le déploiement progressif de logiciels spécifiques.
-
Plan de reprise sur sinistre : décrit les procédures de restauration du système après une panne. Ces procédures s'appliquent à tous les types de pannes, quelle que soit leur gravité.
-
Plan de fonctionnement (manuel d'exploitation) : manuel décrivant les procédures de contrôle, de maintenance, d'installation et de mise à niveau.
-
Plan de formation : contient les processus et les procédures de formation des opérateurs, des administrateurs et des utilisateurs finals sur le nouveau logiciel de l'entreprise.
-
Facteurs influant sur la conception du déploiement
Les décisions prises lors de la conception du déploiement sont influencées par un certain nombre de facteurs. Ces facteurs sont les suivants :
-
Architecture logique : décrit en détail les services fonctionnels d'une solution possible et les relations existant entre les composants fournissant ces services. Servez-vous de l'architecture logique pour déterminer la meilleure manière de distribuer les services. Un scénario de déploiement présente l'architecture logique ainsi que les exigences en termes de qualité de service (décrites ci-dessous).
-
Exigences de qualité de service :ces exigences précisent divers aspects du fonctionnement d'une solution. Utilisez-les pour développer des stratégies permettant d'atteindre les objectifs de qualité de service en termes de performances, de disponibilité, d'évolutivité, d'entretien, etc. Un scénario de déploiement présente l'architecture logique (décrite ci-dessus) ainsi que les exigences en termes de qualité de service.
-
Analyse d'utilisation : l'analyse d'utilisation, développée au cours de la phase de spécification technique du cycle de vie de la solution, fournit des informations sur les types d'utilisation permettant d'évaluer la charge de travail d'un système déployé. Utilisez-la pour identifier les goulots d'étranglement des performances et élaborer des stratégies permettant de satisfaire les exigences de qualité de service.
-
Cas d'utilisation : ces cas sont développés au cours de la phase de spécification technique du cycle de vie de la solution et répertorient les différentes interactions utilisateur identifiées au cours d'un déploiement. Bien qu'ils soient intégrés à l'analyse d'utilisation, vous devez examiner ces cas lors de l'évaluation de la conception d'un déploiement afin de vous assurer qu'ils sont bien pris en compte.
-
Accords de niveau de service : un accord de niveau de service précise les performances minimales exigées et, au cas où ces exigences ne seraient pas satisfaites, le niveau et l'étendue du support client devant être fourni. Une conception de déploiement doit répondre aux exigences de performances définies dans un accord de niveau de service.
-
Coût total de possession : lors de la conception du déploiement, vous analysez les solutions susceptibles de répondre aux exigences de qualité de service en termes de disponibilité, de performances, d'évolutivité, etc. Toutefois, pour chaque solution envisagée, vous devez également tenir compte du coût de cette solution et de son impact sur le coût total de possession. Veillez à prendre en compte les compromis qu'impliquent vos choix et à optimiser vos ressources de manière à répondre aux exigences de l'entreprise dans le respect des contraintes d'exploitation.
-
Objectifs d'exploitation :ces objectifs sont définis au cours de la phase d'analyse d'exploitation de la solution. Ils tiennent compte des exigences de l'entreprise et des contraintes d'exploitation liées à leur réalisation. La capacité d'une conception de déploiement à répondre aux objectifs d'exploitation est la meilleure preuve de sa qualité.
Méthodologie de conception du déploiement
Au même titre que les autres aspects du déploiement, la conception ne relève pas uniquement de la science pure ; c'est pourquoi elle ne peut faire l'objet de procédures et de processus systématiques. L'expérience en matière de conception, une connaissance de l'architecture des systèmes, la compréhension du domaine et un effort de réflexion créative constituent autant de facteurs contribuant à la réussite d'un déploiement.
L'objectif principal de la conception du déploiement consiste à répondre aux exigences de performances tout en satisfaisant celles relatives à la qualité de service. Les stratégies adoptées doivent présenter des avantages malgré les compromis impliqués par vos décisions de conception afin d'optimiser la solution. La méthodologie utilisée comprend généralement les étapes suivantes :
-
Estimation de la puissance de traitement : la conception du déploiement commence normalement par l'estimation du nombre de CPU requises pour chaque composant de l'architecture logique. Commencez par les cas d'utilisation correspondant à la charge la plus importante et poursuivez avec les autres cas. Considérez la charge incombant à tous les composants prenant en charge les cas d'utilisation et modifiez vos estimations en conséquence. Tenez également compte de vos expériences précédentes en matière de conception de systèmes d'entreprise.
-
Estimation de la puissance de traitement requise pour le transport sécurisé : étudiez les cas nécessitant un transport sécurisé et modifiez le nombre de CPU requises en conséquence.
-
Réplication des services pour la disponibilité et l'évolutivité : une fois la puissance de traitement estimée, modifiez la conception en fonction des exigences de qualité de service en termes de disponibilité et d'évolutivité. Envisagez de mettre en œuvre des solutions d'équilibrage de charge pour résoudre les problèmes de disponibilité et de basculement.
Au cours de l'analyse, tenez compte des implications que présentent vos décisions de conception. Par exemple, demandez-vous quel impact les stratégies de disponibilité et d'évolutivité peuvent avoir sur la maintenance du système. Renseignez-vous également sur les autres coûts induits par ces stratégies.
-
Identification des goulots d'étranglement : dans les phases suivantes de votre analyse, examinez la conception du déploiement afin d'identifier les goulots d'étranglement susceptibles de nuire aux performances de transmission des données et apportez les modifications nécessaires.
-
Optimisation des ressources : étudiez la conception du déploiement sous l'angle de la gestion des ressources et envisagez des solutions permettant de réduire les coûts tout en répondant aux exigences formulées.
-
Gestion des risques : réexaminez vos analyses d'exploitation et vos analyses techniques et modifiez votre conception en fonction d'éventuels événements ou situations qui n'auraient pas été envisagés lors des phases précédentes de la planification.
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 :
-
les composants logiques et leurs interactions (définies par les dépendances entre composants dans l'architecture logique) ;
-
l'analyse des cas d'utilisation identifiés ;
-
les exigences en termes de qualité de service ;
-
l'expérience acquise en matière de conception de déploiements et avec Java Enterprise System ;
-
les conseils des services professionnels de Sun, familiarisés avec la conception et l'implémentation de divers types de scénarios de déploiement.
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.
-
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.
-
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.
-
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.
-
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 :
-
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. |
|
1 |
Accède à la mémoire des messages de Messaging Server pour les clients de messagerie. |
|
|
1 |
Extrait et stocke les messages. |
|
|
2 |
Fournit des services d'authentification et d'autorisation. |
|
|
2 |
Extrait et stocke les données de calendrier pour Communications Express, composant frontal de Calendar Server. |
|
|
2 |
Fournit les services d'annuaire LDAP. |
|
|
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 |
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 :
-
Partez d'une estimation du nombre de CPU requises (voir la section précédente, Exemple d'estimation de la puissance de traitement).
-
Calculez le pourcentage de transactions exigeant un transport sécurisé, puis le nombre de CPU nécessaires pour ces transactions.
-
Comptez un nombre de CPU inférieur pour les transactions non sécurisées.
-
Additionnez les valeurs obtenues pour parvenir à une estimation du nombre total de CPU nécessaires.
-
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 :
-
Toutes les connexions exigent une authentification sécurisée.
-
Les connexions représentent 10% de la charge totale de Portal Server.
-
Les exigences de performances relatives aux transactions sécurisées et non sécurisées sont identiques.
Le nombre de CPU requises sera multiplié par quatre afin de fournir la puissance de traitement supplémentaire pour les transactions sécurisées. Comme les autres valeurs citées dans cet exemple, ce facteur est arbitraire et fourni à titre d'exemple uniquement.
|
Étape |
Description |
Calcul |
Résultat |
|---|---|---|---|
|
1 |
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. |
- - - - - |
|
2 |
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 |
|
3 |
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 |
|
4 |
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 |
|
5 |
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 |
6 |
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.
Identification des stratégies de disponibilité
Lors de l'établissement d'une stratégie relative aux exigences de disponibilité, examinez les interactions entre composants et l'analyse d'utilisation pour identifier les solutions de disponibilité à envisager. Effectuez cette analyse composant par composant pour trouver la solution répondant le mieux aux exigences de disponibilité et de basculement.
Vous pouvez par exemple vous poser les questions suivantes pour mettre en place votre stratégie de disponibilité :
-
Quel est le degré de disponibilité spécifié (quatre ou cinq neuf, par exemple) ?
-
Quelles sont les spécifications de performances en cas de basculement (50 %, par exemple) ?
-
L'analyse d'utilisation identifie-t-elle des périodes d'utilisation de pointe ?
-
Quelles sont les considérations géographiques à prendre en compte ?
La stratégie de disponibilité choisie doit également tenir compte des exigences en termes d'entretien (voir section Conception pour une utilisation optimale des ressources). Évitez les solutions complexes exigeant des efforts de maintenance et d'administration importants.
Stratégies de disponibilité
Les stratégies de disponibilité possibles pour les déploiements Java Enterprise System sont les suivantes :
-
Équilibrage de charge : utilisez des composants matériels et logiciels redondants pour répartir la charge de traitement. Un équilibreur de charge dirige une demande de service vers une des instances symétriques de ce service. Si une instance échoue, les autres peuvent assumer sa charge de travail.
-
Basculement : implique la gestion de matériels et de logiciels redondants afin que l'accès aux services et que la sécurité des données essentielles ne soient pas compromis en cas de problème lié à un composant.
Le logiciel Sun Cluster propose une solution de basculement pour les données essentielles gérées par des composants d'arrière-plan tels la mémoire des messages pour Messaging Server et les données de calendrier pour Calendar Server.
-
Réplication des services : cette fonction fournit plusieurs sources d'accès aux même données. Directory Server propose de nombreuses stratégies de réplication et de synchronisation pour l'accès aux annuaires LDAP.
Les sections ci-après décrivent des exemples de solutions de disponibilité fournissant divers niveaux d'équilibrage de charge, de basculement et de réplication des services.
Système à serveur unique
Toutes les ressources de traitement d'un service sont placées sur un seul serveur. Si ce dernier tombe en panne, le service ne peut plus fonctionner.
Figure 5–2 Système à serveur unique
Sun fournit des serveurs haut de gamme permettant de bénéficier des avantages suivants :
-
remplacement et reconfiguration des composants matériels en cours d'exécution du système ;
-
possibilité d'exécuter plusieurs applications dans des domaines sécurisés sur le serveur ;
-
possibilité de mettre à niveau la capacité, les performances et la configuration des E/S sans redémarrer le système.
Un serveur haut de gamme coûte généralement plus cher qu'un système multiserveur comparable. Toutefois, il se révèle plus économique en termes d'administration, de contrôle et d'hébergement. Les systèmes multiserveurs offrent une plus grande souplesse en termes d'équilibrage de charge, de basculement et de suppression de points de panne uniques.
Systèmes à redondance horizontale
Les serveurs redondants parallèles offrant des fonctions d'équilibrage de charge et de basculement, ils permettent d'améliorer la disponibilité de plusieurs façons. Le schéma ci-dessous montre deux serveurs répliqués constituant un système à basculement N+1. Dans ce type de système, un serveur supplémentaire est destiné à assumer 100 % de la charge en cas de panne de l'autre serveur.
Figure 5–3 Système à basculement N+1 avec deux serveurs
La puissance de traitement de chaque serveur dans des Systèmes à redondance horizontale (voir ci-dessus) est identique. Un serveur peut à lui seul satisfaire les exigences de performances. L'autre serveur offre exactement les mêmes performances lorsqu'il est utilisé en tant que serveur de rechange.
Dans ce type de conception, 100% des performances sont assurées en cas de basculement. En revanche, les investissements matériels élevés sans amélioration des performances (puisque l'un des serveurs est utilisé en cas de basculement uniquement) représentent un inconvénient majeur.
Le schéma suivant illustre un système mettant en œuvre l'équilibrage de charge et le basculement, et répartissant les performances entre deux serveurs.
Figure 5–4 Équilibrage de charge et basculement entre deux serveurs
Dans le système représenté à la section Systèmes à redondance horizontale, si un serveur tombe en panne, tous les services restent disponibles, mais pas à 100 %. En effet, le second serveur comporte six CPU qui permettent de prendre en charge 60 % de la charge totale (10 CPU).
Cette conception offre l'avantage d'autoriser une capacité latente (deux CPU) lorsque les deux serveurs sont disponibles.
Le schéma ci-dessous illustre une répartition des performances et de l'équilibrage de charge entre plusieurs serveurs.
Figure 5–5 Répartition de la charge entre n serveurs
La conception illustrée à la section Systèmes à redondance horizontale comportant cinq serveurs, si l'un d'eux tombe en panne, les autres fournissent un total de huit CPU, soit 80 % des exigences de performances (10 CPU). Si vous ajoutez un serveur doté de deux CPU, vous obtenez une conception N+1. En cas de panne de l'un des serveurs, 100 % des performances sont maintenues grâce aux autres serveurs.
Cette solution offre les avantages suivants :
-
performance accrue en cas de panne d'un serveur ;
-
disponibilité même en cas de panne de plusieurs serveurs ;
-
possibilité de mettre les serveurs hors service pour la maintenance et les mises à niveau ;
-
dépenses réduites, car plusieurs serveurs d'entrée de gamme coûtent moins cher qu'un seul serveur haut de gamme.
Toutefois, plus le nombre de serveurs augmente, plus les coûts d'administration et de maintenance sont élevés, sans compter les frais d'hébergement des serveurs dans un centre de données. De plus, il arrive un moment où l'ajout de serveurs finit par entraîner plus d'inconvénients que d'avantages.
Logiciel Sun Cluster
Dans les situations exigeant un degré élevé de disponibilité (quatre ou cinq neuf), vous pouvez envisager d'intégrer le logiciel Sun Cluster dans votre conception de déploiement. Un cluster associe des serveurs redondants à des ressources de stockage et d'autres ressources réseau. Les serveurs d'un cluster sont en communication permanente les uns avec les autres. En cas de mise hors ligne d'un serveur, les autres dispositifs du cluster l'isolent et font basculer les applications ou les données du nœud en panne vers un autre nœud. Le basculement s'effectue rapidement sans que les utilisateurs du système aient à subir une longue interruption des services.
Sun Cluster exige du matériel supplémentaire spécialisé et des connaissances particulières en matière de configuration, d'administration et de maintenance.
Exemples de conceptions de disponibilité
Cette section présente deux exemples de stratégies de disponibilité appliqués à une solution de communications basées sur les identités pour une entreprise de taille moyenne de 1 000 à 5 000 salariés, tel que décrit dans la section Exemple de communications basées sur les identités. La première stratégie illustre l'équilibrage de charge pour Messaging Server. La seconde illustre une solution de basculement faisant appel au logiciel Sun Cluster.
Exemple d'équilibrage de charge pour Messaging Server
Le tableau ci-dessous présente le nombre de CPU requises estimé pour chaque composant logique de Messaging Server dans l'architecture logique. Il reprend l'estimation finale calculée dans la section Mise à jour du nombre de CPU estimé .
Tableau 5–6 Ajustement de l'estimation du nombre de CPU pour les composants de support|
Composant |
Nombre de CPU |
Mémoire |
|---|---|---|
|
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 |
Pour cet exemple, supposons qu'au cours de la phase de spécification technique, les exigences de qualité de service suivantes aient été formulées :
-
Disponibilité : la disponibilité globale du système doit être de 99,99% (hors périodes d'indisponibilité planifiées). Une panne d'un seul système ne doit pas entraîner d'interruption des services.
-
Évolutivité : aucun serveur ne doit être utilisé à plus de 80% au cours des périodes de charge de pointe et le système doit pouvoir assumer une croissance à long terme de 10% par an.
Pour répondre aux exigences de disponibilité, prévoyez deux instances de chaque composant de Messaging Server, une sur chaque serveur. Si un serveur ou un composant ne fonctionne plus, l'autre le remplace. Le schéma ci-dessous présente un diagramme du réseau correspondant à cette stratégie de disponibilité.
Sur le schéma ci-dessus, le nombre de CPU a doublé par rapport à l'estimation initiale. Cette augmentation est intervenue pour les raisons suivantes :
-
En cas de panne d'un serveur, l'autre fournit la puissance de traitement nécessaire à la gestion de la charge.
-
La puissance de traitement supplémentaire fournit la marge de sécurité nécessaire pour répondre à l'exigence selon laquelle aucun serveur ne doit être utilisé à plus de 80% au cours des périodes de charge de pointe.
-
En ce qui concerne l'exigence d'évolutivité impliquant une croissance annuelle de la charge de 10%, la puissance de traitement supplémentaire permet d'ajouter la capacité latente requise.
Exemple de basculement à l'aide du logiciel Sun Cluster
Le schéma ci-dessous montre un exemple de stratégie de basculement pour le composant d'arrière-plan Calendar Server et la mémoire de messages de Messaging Server. Le composant d'arrière-plan Calendar Server et la mémoire de messages sont répliqués sur des serveurs matériels différents et configurés pour le basculement à l'aide du logiciel Sun Cluster. Le nombre de CPU et la mémoire correspondante sont répliqués sur chaque serveur dans Sun Cluster.
Figure 5–6 Conception avec basculement utilisant le logiciel Sun Cluster
Exemple de réplication des services d'annuaire
Les services d'annuaire peuvent être répliqués de sorte que les transactions soient réparties sur différents serveurs, ce qui accroît la disponibilité. Directory Server fournit diverses stratégies de réplication des services, dont les suivants :
-
Bases de données multiples : les différentes parties d'une arborescence d'annuaire sont stockées dans des bases de données distinctes.
-
Chaînage et références : relie les données distribuées dans une même arborescence d'annuaire.
-
Réplication monomaître : fournit une source centrale pour la base de données maître, qui est ensuite distribuée aux répliques consommateur.
-
Réplication multimaître : répartit la base de données maître entre plusieurs serveurs. Chacun d'eux répartit ensuite sa base de données entre les répliques consommateur.
Les stratégies de disponibilité pour Directory Server sont un sujet complexe que le présent manuel ne traite pas. Les sections Réplication monomaître et Réplication multimaître fournissent une présentation générale des stratégies de réplication de base. Pour plus d'informations, reportez-vous au chapitre 12, Designing a Highly Available Deployment, dans Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide.
Réplication monomaître
Le schéma ci-dessous représente une stratégie de réplication monomaître illustrant les concepts de réplication de base.
Figure 5–7 Exemple de réplication monomaître
Dans le cadre de la réplication monomaître, une instance de Directory Server gère la base de données d'annuaire maître et consigne toutes les modifications. La base de données maître est répliquée sur un certain nombre de bases de données consommateur. Les instances consommateur de Directory Server sont optimisées pour les opérations de lecture et de recherche. Toute opération d'écriture reçue par un consommateur est renvoyée vers le maître, et celui-ci met à jour les bases de données consommateur de manière régulière.
Les avantages de la réplication monomaître sont les suivants :
-
instance unique de Directory Server optimisée pour les opérations de lecture et d'écriture dans la base de données ;
-
nombre quelconque d'instances consommateur de Directory Server optimisées pour les opérations de lecture et de recherche ;
-
évolutivité horizontale pour les instances consommateur de Directory Server.
Réplication multimaître
Le schéma ci-dessous illustre une stratégie de réplication multimaître permettant une distribution globale des accès à l'annuaire.
Avec la réplication multimaître, une ou plusieurs instances de Directory Server gèrent la base de données d'annuaire maître. Chacun de ces maîtres dispose d'un contrat de réplication décrivant les procédures de synchronisation des bases de données maître. Chaque maître est répliqué sur un nombre quelconque de bases de données consommateur. Comme dans le cadre de la réplication monomaître, les instances consommateur de Directory Server sont optimisées pour l'accès en lecture et en recherche. Toute opération d'écriture reçue par un consommateur est renvoyée vers le maître, et celui-ci met à jour les bases de données consommateur de manière régulière.
Figure 5–8 Exemple de réplication multimaître
La stratégie de réplication multimaître présente les mêmes avantages que la réplication monomaître, auxquels vient s'ajouter une disponibilité permettant l'équilibrage de charge lors des mises à jour du maître. Vous pouvez également implémenter une stratégie de disponibilité fournissant un contrôle local des opérations d'annuaire, importante pour les entreprises utilisant des centres de données distribués.
Identification des stratégies d'évolutivité
L'évolutivité se définit comme la possibilité d'augmenter la capacité du système, généralement via l'ajout de ressources système, sans pour autant modifier l'architecture de déploiement. Au cours de l'analyse des exigences, vous planifiez la croissance prévue du système en fonction des exigences de l'entreprise et des analyses d'utilisation correspondantes. Ces estimations du nombre d'utilisateurs et de la capacité du système à répondre à leurs besoins peuvent être très différentes des chiffres réels observés sur le système déployé. Votre conception doit fournir la souplesse nécessaire pour prendre en compte les différences par rapport aux estimations.
Une conception évolutive prévoit une capacité latente suffisante pour gérer les augmentations de charge de travail, jusqu'à ce que des ressources supplémentaires soient ajoutées au système. Elle doit pouvoir être adaptée sans être entièrement repensée.
Capacité latente
La capacité latente est un aspect de l'évolutivité consistant à ajouter des ressources de performances et de disponibilité au système de sorte que celui-ci soit en mesure de faire face aux charges de pointe. Dans un système déployé, vous pouvez également contrôler son utilisation afin de déterminer le moment où des ressources doivent être ajoutées au système. La capacité latente est un facteur de sécurité de votre conception.
L'analyse des cas d'utilisation peut permettre d'identifier les scénarios susceptibles d'entraîner des charges de pointe inhabituelles. Utilisez cette analyse et un facteur représentant la croissance imprévue du système pour définir la capacité latente et améliorer la sécurité du système.
La conception du système doit permettre de gérer la capacité prévue pendant un délai raisonnable, c'est-à-dire pendant les 6 à 12 premiers mois d'utilisation. Les cycles de maintenance peuvent être utilisés pour ajouter des ressources ou augmenter la capacité en cas de besoin. Idéalement, vous devriez pouvoir planifier des mises à niveau régulières du système, mais il est généralement difficile de prévoir les augmentations de capacité nécessaires. Pour savoir quand le système doit être mis à niveau, contrôlez attentivement vos ressources et fondez-vous sur les prévisions d'exploitation.
Si vous envisagez d'implémenter votre solution par phases incrémentielles, vous pouvez planifier les augmentations de capacité du système en même temps que les modifications prévues lors de chaque phase incrémentielle.
Exemple d'évolutivité
L'exemple de cette section illustre une mise à l'échelle horizontale et verticale pour une solution implémentant Messaging Server. La mise à l'échelle verticale consiste à ajouter des CPU à un serveur afin de gérer les augmentations de charge. La mise à l'échelle horizontale consiste à ajouter des serveurs supplémentaires afin de répartir la charge.
Cet exemple s'appuie sur une hypothèse de 50 000 utilisateurs et de deux instances de mémoire de messages réparties pour l'équilibrage de charge. Chaque serveur est équipé de deux CPU, pour un total de quatre. Le schéma ci-dessous montre comment ce système peut être mis à l'échelle pour gérer des charges de 250 000 et de 2 000 000 d'utilisateurs.
Remarque –
L'Exemple d'évolutivité met en évidence les différences existant entre une mise à l'échelle verticale et une mise à l'échelle horizontale. Ce schéma ne prend pas en compte les autres facteurs à considérer lors de la mise à l'échelle, tels l'équilibrage de charge, le basculement et les changements de types d'utilisation.
Figure 5–9 Exemples de mise à l'échelle horizontale et verticale
Identification des goulots d'étranglement des performances
Pour bien réussir votre déploiement, vous devez identifier les goulots d'étranglement de performances potentiels et établir une stratégie permettant de les éviter. On appelle goulot d'étranglement le moment où la vitesse d'accès aux données dépasse les exigences système spécifiées.
Les goulots d'étranglement peuvent être classés selon différentes catégories de matériel, comme le montre le tableau ci-dessous répertoriant les points d'accès aux données d'un système. Ce tableau fournit également des solutions permettant d'éviter les goulots d'étranglement pour chaque catégorie de matériel.
Tableau 5–7 Points d'accès aux données|
Catégorie de matériel |
Vitesse d'accès relative |
Solutions pour améliorer les performances |
|---|---|---|
|
Processeur |
Nanosecondes |
Mise à l'échelle verticale : ajoutez de la puissance de traitement, augmentez le cache du processeur. Mise à l'échelle horizontale : ajoutez de la puissance de traitement parallèle pour l'équilibrage de charge. |
|
Mémoire système (RAM) |
Microsecondes |
Allouez de la mémoire système à des tâches spécifiques. Mise à l'échelle verticale : ajoutez de la mémoire supplémentaire. Mise à l'échelle horizontale : créez des instances supplémentaires pour le traitement parallèle et l'équilibrage de charge. |
|
Lecture et écriture sur les disques |
Millisecondes |
Optimisez l'accès aux disques à l'aide de baies de disques (RAID). Limitez l'accès aux disques à des fonctions spécifiques (lecture ou écriture seule). Mettez en cache les données fréquemment utilisées. |
|
Interface réseau |
Varie selon la bande passante et la vitesse d'accès des nœuds du réseau. |
Augmentez la bande passante. Ajoutez du matériel d'accélération pour le transport des données sécurisées. Améliorez les performances des nœuds du réseau de sorte que l'accès aux données soit plus rapide. |
Remarque –
À la section Identification des goulots d'étranglement des performances, les catégories de matériel sont répertoriées en fonction de leur vitesse d'accès relative. Les points d'accès lents, tels les disques par exemple, sont plus susceptibles de provoquer des goulots d'étranglement. Toutefois, les processeurs dont la puissance ne permet pas de traiter les charges importantes représentent également des sources probables de goulots d'étranglement.
La conception du déploiement commence généralement par une estimation de la puissance de traitement requise pour chaque composant et leurs éléments dépendants. Vous déterminez ensuite la façon d'éviter les goulots d'étranglement liés à la mémoire système et à l'accès aux disques. Ensuite, vous examinez l'interface réseau pour identifier les éventuels goulots d'étranglement et élaborer des stratégies destinées à les surmonter.
Optimisation de l'accès aux disques
La vitesse d'accès aux disques contenant les données fréquemment utilisées, telles que les annuaires LDAP, est un élément essentiel de la conception du déploiement. L'accès aux disques est le mode d'accès aux données le plus lent et il constitue une source possible de goulots d'étranglement.
Pour optimiser l'accès aux disques, vous pouvez séparer les opérations d'écriture des opérations de lecture. En effet, les opérations d'écriture coûtent plus cher que les opérations de lecture et ces dernières (recherches dans les annuaires LDAP) sont beaucoup plus fréquentes que les premières (mises à jour des données des annuaires LDAP).
Vous pouvez également consacrer l'utilisation des disques à différents types d'opérations d'E/S. Par exemple, prévoyez des accès séparés pour les opérations de journalisation de Directory Server dans les journaux de transactions et d'événements, par exemple, et pour les opérations de lecture et d'écriture LDAP.
Enfin, vous pouvez envisager d'implémenter une ou plusieurs instances de Directory Server dédiées aux opérations de lecture et d'écriture et d'utiliser des instances répliquées, distribuées sur les serveurs locaux pour les accès en lecture et en recherche. Les fonctions de chaînage et de liaison sont également disponibles pour optimiser l'accès aux services d'annuaire.
Le chapitre Defining System Characteristics du manuel Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide présente divers facteurs à prendre en compte lors de la planification de l'accès aux disques. Les sujets traités sont les suivants :
-
Mémoire minimale et espace disque requis : permet d'estimer l'espace disque et la quantité de mémoire requis en fonction de la taille des annuaires.
-
Dimensionnement de la mémoire physique pour l'accès au cache : fournit des instructions pour estimer la taille du cache en fonction de l'utilisation prévue de Directory Server et pour planifier l'utilisation totale de la mémoire.
-
Dimensionnement des sous-systèmes de disques : fournit des informations sur la planification de l'espace disque requis en fonction du suffixe des annuaires et de facteurs liés à Directory Server influant sur l'utilisation des disques ainsi que sur la répartition des fichiers entre les disques. Présente également des solutions utilisant des baies de disques.
Conception pour une utilisation optimale des ressources
La conception du déploiement ne consiste pas simplement à évaluer les ressources nécessaires pour répondre aux exigences de qualité de service. Au cours de cette phase, vous devez également analyser toutes les solutions disponibles et choisir celle qui vous permettra de répondre aux exigences de qualité de service tout en minimisant les coûts. Vous devez analyser tous les compromis impliqués par vos décisions de conception afin de vous assurer qu'un bénéfice dans un domaine n'est pas annulé par un coût dans un autre.
Par exemple, la mise à l'échelle horizontale peut améliorer la disponibilité globale mais engendrer des coûts supplémentaires en termes de maintenance et de service. De même, la mise à l'échelle verticale peut accroître la puissance de traitement à moindres frais mais cette puissance supplémentaire risque de ne pas être utilisée de manière efficace par certains services.
Avant de mettre au point votre stratégie de conception, revoyez vos décisions pour vérifier que les avantages financiers offerts par la solution proposée compensent suffisamment l'utilisation des ressources. Au cours de cette analyse, il vous faut étudier l'impact des avantages du système dans un domaine sur les avantages du système dans d'autres domaines. Le tableau ci-dessous répertorie certains avantages du système et les éléments à prendre en compte en termes de gestion des ressources.
Tableau 5–8 Gestion des ressources|
Qualité du système |
Description |
|---|---|
|
Si vous optez pour une solution dans laquelle les CPU sont rassemblés sur des serveurs individuels, les services pourront-ils utiliser efficacement la puissance de traitement ? En effet, pour certains services, le nombre de CPU pouvant être utilisés de manière efficace est limité. |
|
|
Capacité latente |
Votre stratégie peut-elle gérer les charges dépassant les estimations de performances ? Les charges excessives sont-elles gérées par mise à l'échelle verticale sur les serveurs, par équilibrage de charge vers d'autres serveurs ou les deux ? La capacité latente est-elle suffisante pour gérer les charges de pointe jusqu'à la prochaine étape de mise à l'échelle du déploiement ? |
|
Avez-vous pris en compte les performances supplémentaires nécessaires au traitement des transactions sécurisées? |
|
|
Dans le cas des solutions à redondance horizontale, avez-vous estimé correctement les coûts de maintenance à long terme ? Avez-vous pris en compte les temps d'indisponibilité planifiés nécessaires aux opérations de maintenance du système ? Avez-vous comparé les coûts de serveurs haut de gamme et de serveurs d'entrée de gamme ? |
|
|
Avez-vous prévu des étapes de mise à l'échelle du déploiement ? Avez-vous établi une stratégie fournissant une capacité latente suffisante pour gérer les augmentations de charge prévues entre chaque étape de mise à l'échelle du déploiement ? |
|
|
Votre conception de disponibilité tient-elle compte des coûts d'administration, de contrôle et de maintenance ? Avez-vous envisagé des solutions de délégation permettant aux utilisateurs finals d'effectuer certaines tâches d'administration afin de réduire les coûts ? |
Gestion des risques
La plupart des données sur lesquelles repose la conception du déploiement (exigences de qualité de service, analyse d'utilisation) ne sont pas empiriques. Il s'agit d'estimations et de projections issues des analyses d'exploitation. Bien des facteurs peuvent fausser ces projections, comme des situations imprévues liées au contexte économique, des méthodes de collecte des données inadaptées ou simplement des erreurs humaines. Avant de terminer une conception de déploiement, réexaminez les analyses sur lesquelles elle est fondée et vérifiez qu'elle prend en compte une marge d'erreur raisonnable par rapport aux estimations et aux projections.
Par exemple, si l'analyse d'utilisation sous-estime l'utilisation réelle du système, celui-ci risque d'être incapable de faire face au trafic auquel il est soumis. Une conception dont les performances ne sont pas satisfaisantes sera probablement considérée comme un échec.
A contrario, si la puissance de votre système est supérieure aux exigences, des ressources qui pourraient être utilisées à d'autres fins sont monopolisées inutilement. La bonne méthode consiste à prévoir une marge de sécurité suffisante tout en utilisant les ressources à bon escient.
Une utilisation inadaptée des ressources entraîne un échec de la conception car les ressources sous-utilisées auraient pu être employées pour d'autres activités. En outre, des solutions jugées inappropriées risquent d'être considérées par les parties prenantes comme ne respectant pas les termes du contrat.
Exemple d'architecture de déploiement
Le schéma ci-dessous représente une architecture de déploiement complète correspondant à l'exemple décrit plus haut dans ce document. Il donne un aperçu de la manière dont une architecture de déploiement peut se présenter.
Attention – L'architecture de déploiement illustrée par le schéma ci-dessous est fournie à titre d'exemple uniquement. Il ne s'agit pas d'un déploiement ayant été conçu, mis en place et testé en conditions réelles et ne doit donc pas être considéré comme une recommandation.
Figure 5–10 Exemple d'architecture de déploiement
- © 2010, Oracle Corporation and/or its affiliates