Internet Data Center : Conception de Commerce Server

Sur cette page

Microsoft Internet Data Center : Conception de Commerce Server
Résumé
Introduction
À qui s'adresse ce chapitre ?
Portée
Questions de conception
Ressources nécessaires
Configuration requise
Architecture
Planification d'une infrastructure pour Commerce Server
Ressources Commerce Server
Configuration et déploiement des ressources Commerce Server
Planification de la couche Web
Planification de l'emplacement des composants COM+
Planification des pipelines
Planification de l'intégration de BizTalk Server
Jeu d'outils Supplier Enablement
Message Queuing
Publications MSXML et HTTP
Planification de la configuration de la base de données Commerce Server
Questions de conception de base de données
Implémentation d'une solution de base de données en clusters
Planification des stratégies de mise à l'échelle
Serveurs de base de données en lecture seule avec équilibrage de charge
Serveurs fédérés
Planification de la sécurité de la base de données
Planification de Data Warehouse et du service Predictor
Emplacement du data warehouse (magasin de données)
Planification de la configuration du service Predictor
Planification de la configuration du service Direct Mailer
Emplacement du service Direct Mailer
Planification de la configuration du serveur Business Desk
Emplacement de Business Desk
Environnement des tests de perfomances et résultats
Environnement test
Performance des serveurs de base de données
Performance du serveur Web
Résumé
Informations complémentaires

Microsoft Internet Data Center : Conception de Commerce Server

Cet article est tiré du Guide de référence Internet Data Center

Résumé

Ce chapitre décrit les problèmes posés par la conception d'une implémentation e-commerce Microsoft® Commerce Server 2000 dans l'infrastructure du Centre de données Internet Microsoft IDC. Une solution Commerce Server se compose de plusieurs parties, notamment les sites Web Microsoft IIS (Internet Information Services), les composants entreprise et les bases de données. Ce chapitre décrit les options disponibles lors du déploiement de chacune des parties d'une solution et traite des décisions à prendre en matière de conception lorsque vous envisagez une implémentation Commerce Server.

Introduction

Microsoft® Commerce Server 2000 est une plate-forme pour les solutions de commerce électronique telles que les sites de vente entreprise-consommateur (BtoC) et les portails partenaire (BtoB) entreprise-entreprise. Commerce Server fournit une infrastructure de développement d'applications et un ensemble complet d'objets programmables pour accélérer le développement d'applications de commerce électronique, ainsi que des outils de gestion pour l'administration de l'infrastructure du site et la gestion et l'analyse de l'entreprise.

Ce chapitre décrit les problèmes posés par la conception d'une implémentation e-commerce Commerce Server 2000 à intégrer dans l'infrastructure du Centre de données Internet Microsoft IDC.

À qui s'adresse ce chapitre ?

Ce chapitre fournit aux responsables informatiques (IT) les directives permettant de planifier et de concevoir l'installation d'un site Commerce Server. Les fonctions suivantes sont les plus concernées :

• Architectes de commerce électronique

• Administrateurs réseau

• Administrateurs de bases de données de site de commerce électronique

Portée

Ce chapitre décrit les questions de conception liées à la création d'une infrastructure pour la prise en charge du site de solution de vente Commerce Server 2000.

Il n'aborde pas l'authentification Windows Commerce Server à l'aide du service d'annuaire Active Directory™. L'authentification par défaut utilisée par le site de solution de vente n'a pas changé. Ce chapitre ne prend pas en compte les exigences en matière de gestion liées à l'analyse commerciale Commerce Server. De plus, il ne fournit pas les directives sur le développement d'un site Commerce Server. Pour plus d'informations concernant la conception et la création d'un site Commerce Server à l'aide des pages ASP (Active Server Pages), consultez la documentation Commerce Server 2000 et le Kit de développement logiciel Commerce Server 2000.

Questions de conception

La solution décrite dans ce chapitre fournit une implémentation de commerce électronique BtoC totalement évolutive, gérable et rentable pour les opérations de commerce électronique de taille moyenne utilisant l'infrastructure IDC. Ces sites contiennent généralement des systèmes de développement, de test/simulation, des systèmes ERP (enterprise resource planning) et des environnements de production, avec 20 serveurs ou plus dans l'environnement de production et de 10 à 20 serveurs dans chacun des autres environnements. Ce type de site héberge en général un volume de contenu moyen (plus de 2 Go) et connaît un renouvellement de contenu de quantité moyenne.

Parce que les exigences des applications varient, la conception doit être considérée comme un point de départ solide pouvant être adapté à vos besoins. Vous pouvez adapter la conception décrite dans ce chapitre pour fournir une évolutivité appropriée à la plupart des opérations de commerce électronique.

Ressources nécessaires

Pour concevoir l'installation d'une solution Commerce Server efficace, vous devez disposer d'une équipe avec des connaissances et des compétences dans les domaines suivants :

• infrastructure de réseau et sécurité pour le système d'exploitation Microsoft Windows® 2000

• installation de base de données et configuration de Microsoft SQL Server™

• cluster de basculement dans Windows 2000 et SQL Server 2000

• configuration d'un pare-feu

• installation et configuration de Commerce Server 2000

Configuration requise

La conception décrite dans ce chapitre suppose que vous avez créé une infrastructure de commerce électronique selon la conception présentée dans les chapitres précédents de ce guide.

Pour choisir la meilleure façon de déployer votre solution Commerce Server 2000, consultez le Kit de ressources Commerce Server 2000 afin d'obtenir des informations concernant la planification de votre site selon les modèles d'utilisation, vos objectifs commerciaux et d'autres critères.

La conception décrite dans ce chapitre présuppose que vous avez développé un site Commerce Server dans un environnement de développement et que vous l'avez "empaqueté" dans un fichier *.pup. Le site de solution de vente est utilisé comme site exemple dans ce chapitre.

Architecture

La figure suivante montre les éléments spécifiques à Commerce Server de l'architecture IDC.

Figure 1 Éléments Commerce Server dans l'architecture du Centre de données Internet

Planification d'une infrastructure pour Commerce Server

Lorsque vous concevez une infrastructure pour votre site Commerce Server, vous devez vous assurer que l'environnement planifié convient aux besoins de vos applications. Parce que les applications peuvent varier considérablement, l'architecture choisie dépend de la fonctionnalité fournie par votre application et des priorités de votre organisation en termes d'évolutivité, de disponibilité, de sécurité et de gestion.

Les solutions Commerce Server se composent de plusieurs parties. Pour garantir l'implémentation de votre solution de commerce électronique la plus appropriée dans l'architecture du Centre de données Internet, vous devez soigneusement planifier l'installation et la configuration de chacune des parties.

Vous pouvez envisager une installation Commerce Server avec deux ensembles principaux de composants : les ressources générales requises par Commerce Server (ressources globales) et les ressources appartenant à un site Commerce Server individuel (ressources spécifiques au site). L'installation des deux ensembles de ressources sur les serveurs les plus appropriés et avec la configuration adéquate est cruciale pour l'optimisation d'un site Commerce Server. Ce chapitre fournit des recommandations pour la planification et le déploiement de ces ressources afin d'obtenir une solution Commerce Server optimale au sein de l'architecture du Centre de données Internet. Pour obtenir des informations détaillées concernant les composants Commerce Server et les directives d'installation générales, consultez la documentation Commerce Server 2000.

Ressources Commerce Server

Les sites Commerce Server requièrent les ressources globales suivantes :

• Base de données Admin. Une base de données SQL Server qui stocke toutes les données de configuration globales.

• Outils de gestion. Les outils requis incluent Commerce Server Manager MMC (Microsoft Management Console), Pipeline Editor et Commerce Server Site Packager.

• Composants de sites Web. Les objets commerciaux résidant sur un serveur Microsoft Internet Information Services (IIS) et pouvant être utilisés pour gérer la navigation du catalogue, la création de profils utilisateur, l'authentification et d'autres fonctionnalités.

• Service Direct Mailer. Commerce Server utilise ce service Windows 2000 pour envoyer des messages électroniques à un grand nombre d'adresses.

• Service Predictor. Un service Windows 2000 qui utilise les données du data warehouse (magasin de données) pour prédire de façon dynamique des corrélations contextuelles basées sur un modèle de données.

• Composants d'analyse. Un ensemble de processus qu'un administrateur système utilise pour importer et conserver des données dans une combinaison de bases de données SQL Server et OLAP (Online Analytical Processing).

Les sites Commerce Server requièrent également des ressources spécifiques au site :

• Applications Web. Les applications IIS de gestion Business Desk et de commerce électronique sont requises.

• Pipelines Commerce Server. Séquences de composants COM utilisées pour implémenter la logique commerciale d'un site.

• Bases de données de ressources de site. Bases de données qui stockent des données de ressources requises par un site Commerce Server. Celles-ci incluent les bases de données Catalogues, Profils utilisateur, Campagnes, Configurations de transaction, Transactions et Data Warehouse.

• Base de données d'analyse. Base de données OLAP utilisée pour l'analyse des données.

Configuration et déploiement des ressources Commerce Server

L'implémentation d'une solution Commerce Server BtoC efficace dans une architecture du Centre de données Internet requiert une analyse minutieuse du type d'usage prévu, l'établissement d'objectifs commerciaux et le respect des directives de l'infrastructure recommandée. Pour plus d'informations concernant les objectifs spécifiques de cette infrastructure, consultez les chapitres précédents de ce guide. Ceci vous permet de concevoir un site de commerce électronique BtoC avec une évolutivité, une gestion et une rentabilité élevées.

Les sections suivantes abordent de façon détaillée la configuration et le plan de déploiement pour Commerce Server 2000 dans l'architecture du Centre de données Internet.

Planification de la couche Web

La couche Web, désignée sous le nom de zone démilitarisée (DMZ) dans l'architecture du Centre de données Internet, héberge le site Commerce Server qui est exposé sur Internet. Les serveurs IIS (Internet Information Services) sont situés dans la zone DMZ.

La planification de la couche Web a comme objectif de conception de maximiser l'évolutivité du site. Pour cela, suivez les recommandations ci-après :

• Utilisez des techniques de mise à l'échelle pour implémenter la couche Web comme une ferme de serveurs IIS de configurations identiques dont la charge est équilibrée par NLB (Network Load Balancing).

• Créez une application sans état. L'équilibrage de charge sans état fournit la meilleure évolutivité car chaque requête effectuée par un client peut être envoyée au serveur pour traitement. Lorsque les informations d'état sont stockées dans des variables de session ASP, le client doit être renvoyé au même serveur IIS pour le traitement de chaque requête de protocole HTTP (Hypertext Transfer Protocol). Le stockage de références aux objets COM Microsoft Visual Basic® dans des variables de session ASP réduit considérablement l'évolutivité de vos serveurs Web. Vous devez éviter cette pratique pour le développement de toute application de commerce électronique, y compris les sites Commerce Server 2000.

  Remarque : Pour obtenir des informations concernant l'utilisation de la conception sans état, consultez le Kit de développement logiciel (SDK) Commerce Server 2000 et les articles de la Base de connaissances Q243548 ("Design Guidelines for VB Components Under ASP – Directives de conception pour les composants VB sous ASP") et Q243543 ("Do Not Store STA Objects in Session or Application – Ne stockez pas les objets STA dans une session ou une application").

• Partitionnez le travail réalisé par votre site Commerce Server en plusieurs fermes Web. Par exemple, la plupart du trafic sur les sites de commerce électronique se caractérise par la navigation et la recherche, avec une faible partie réservée à des opérations plus complexes, telles que le traitement et l'extraction du contenu du panier. En séparant ces fonctions en plusieurs fermes Web, vous pouvez optimiser leurs performances indépendamment. Pour plus d'informations, consultez le Kit de ressources Commerce Server 2000.

Vous devez également prendre en compte la mise à l'échelle des serveurs individuels qui forment la couche Web. Les sections suivantes abordent les objectifs de conception pour les composants et pipelines COM+.

Planification de l'emplacement des composants COM+

En général, vous devez placer les composants COM+ sur les serveurs Web. Cette configuration permet d'obtenir de meilleures performances et une meilleure capacité de gestion pour la plupart des applications Commerce Server.

Les composants COM+ peuvent ralentir votre application Commerce Server de deux façons. La première cause de ralentissement est liée à la création et à l'accès des composants COM+. Elle peut être provoquée par des sauts du réseau vers d'autres couches physiques ou par des appels aux composants COM+ dans un autre processus sur le même serveur. ASP fournit un nombre limité de threads pour traiter toutes les requêtes de page ASP entrantes. Lorsque ces threads sont bloquées et attendent des composants COM+ pour finir de traiter les requêtes, elles ne peuvent pas traiter les nouvelles requêtes entrantes du serveur Web. Cela limite le débit général du serveur Web.

Le second ralentissement se produit lorsque les composants COM+ qui requièrent des ressources UC importantes utilisent la capacité de traitement des serveurs IIS et limitent le débit général.

Lorsque vous choisissez l'emplacement approprié pour vos objets COM+, vous devez doser soigneusement le besoin en capacité UC, le coût de maintien des données et la complexité de la logique commerciale.

Les composants COM+ sont couramment déployés dans les deux emplacements suivants sur un site Commerce Server :

• Les serveurs IIS dans la zone DMZ

• Les serveurs d'applications sur le réseau local virtuel (VLAN)

Pour optimiser le débit d'appel de composants COM+ :

• Placez autant de composants COM+ que possible directement sur les serveurs IIS. Cela permet de minimiser le blocage des threads ASP lors du traitement des appels de composants COM+.

• Placez les composants COM+ utilisant une grande partie de la capacité de l'UC sur un réseau physique séparé.

Les composants COM+ présentant les caractéristiques suivantes constituent d'excellents candidats pour le déploiement sur un réseau physique séparé :

• Les composants qui réalisent le cryptage de clé publique.

• Les composants qui génèrent du contenu crypté ou compressé téléchargeable.

• Les composants qui incluent une logique commerciale extrêmement complexe.

• Les composants qui implémentent des tâches à exécution longue telles que la communication avec une application principale. Ce type de tâches qui occasionnent un ralentissement important requiert souvent la thread exécutée pour attendre des périodes de temps étendues. Des tâches telles que celles-ci devraient tirer profit de l'équilibrage CLB (Component Load Balancing) de Application Center 2000 pour répartir la charge de traitement entre plusieurs serveurs d'application. Cela vous permet de faire évoluer les serveurs CLB indépendamment de la couche Web pour obtenir des performances optimales.

La conception IDC distribue les composants COM+ à la fois sur la zone DMZ et les couches du réseau d'infrastructure. Cette implémentation utilise les caractéristiques susmentionnées pour déterminer quelles couches de composants COM+ conviennent le mieux.

Planification des pipelines

Les pipelines Commerce Server sont des groupes de composants COM+ appelés en séquence. En général, vous devez planifier les pipelines de la même façon que les composants COM+.

Tout comme pour les composants COM+, vous devez exécuter vos pipelines sur des serveurs IIS à moins que vous ayez la preuve que ce sont des goulets d'étranglement. Si les pipelines contiennent des composants qui ont des caractéristiques similaires à ceux cités dans la section précédente, envisagez d'exécuter ces pipelines sur des serveurs d'application séparés. La séparation des pipelines dans une autre couche physique est très avantageuse dans le cas de l'exécution de pipelines qui requièrent un temps de traitement élevé ou une quantité importante des ressources UC.

Planification de l'intégration de BizTalk Server

Lorsque vous envisagez d'intégrer Microsoft BizTalk Server dans une solution Commerce Server, vos objectifs doivent être :

• Minimiser la durée requise pour l'envoi de commandes à BizTalk Server.

• Fournir un mécanisme à disponibilité élevée et souple pour l'envoi de commandes à BizTalk Server.

• Utiliser un traitement asynchrone pour maximiser le débit.

Vous pouvez utiliser l'une des techniques suivantes pour intégrer Commerce Server et BizTalk Server :

• Utiliser le jeu d'outils Supplier Enablement.

• Utiliser Message Queuing (aussi appelé MSMQ) pour lier le processus d'extraction et BizTalk Server.

• Utiliser l'analyseur XML de Microsoft (MSXML) pour publier des commandes sur BizTalk Server à l'aide de HTTP.

Dans tous les cas, vous devez exécuter Commerce Server Service Pack 1. Ce Service Pack modifie le schéma du catalogue et simplifie le mappage des catalogues Commerce Server vers d'autres formats.

Jeu d'outils Supplier Enablement

Le jeu d'outils Supplier Enablement permet d'intégrer de façon unique Commerce Server et BizTalk Server. Il fournit les spécifications sur document, les mappages et les directives BizTalk Server nécessaires pour lier les deux produits serveur très rapidement.

Message Queuing

Message Queuing dissocie le traitement des commandes Commerce Server de celui de BizTalk Server. Lorsqu'un utilisateur réalise une commande dans Commerce Server, Commerce Server laisse les informations contenues dans le formulaire de commande dans Message Queue pendant le processus d'extraction. Cette opération est efficace et place seulement une petite charge sur les serveurs exécutant Commerce Server. Les serveurs exécutant BizTalk Server sont ensuite configurés pour contrôler la file d'attente et traiter la commande en mode asynchrone.

Message Queuing version 2.0 a une limite minimale de taille de 2 mégaoctets (Mo) par message pour les chaînes de caractères d'un octet et 4 Mo pour les chaînes Unicode. Les messages vers BizTalk doivent être au format Unicode, qui requiert deux octets pour stocker chaque caractère. Cette taille limite pose rarement problème lors du traitement de commandes individuelles à l'aide des techniques décrites précédemment. Vous devez configurer le pare-feu interne pour autoriser le trafic Message Queuing à passer de la zone DMZ à l'infrastructure VLAN. Vous devez pour cela autoriser le trafic sur le port 1801.

Selon les besoins de disponibilité de votre site Commerce Server, vous devez peut-être fournir un environnement Message Queuing entièrement redondant. Pour cela, vous devez installer Message Queuing sur un cluster de basculement en utilisant les technologies Windows Clustering.

Publications MSXML et HTTP

L'autre technique d'intégration de Commerce Server et BizTalk Server consiste à utiliser le mécanisme de publication HTTP du serveur MSXML pour envoyer les informations concernant la commande sur les ordinateurs BizTalk Server en utilisant le protocole HTTP et le port 80. Les ordinateurs BizTalk Server sont équilibrés au niveau de la charge à l'aide de Network Load Balancing. Cette solution contourne les contraintes liées à la taille de la solution Message Queuing, mais fournit des performances inférieures car BizTalk doit traiter complètement l'envoi avant de retourner le contrôle à l'application d'envoi. Message Queuing exécute cette tâche une fois que le message est en attente.

Planification de la configuration de la base de données Commerce Server

Les sites Commerce Server dépendent considérablement des données commerciales et de configuration stockées dans les bases de données Commerce Server. La configuration de ces bases de données est l'un des éléments les plus importants d'une solution Commerce Server efficace. Selon le volume et les modèles d'utilisation de votre site Commerce Server, la configuration de la base de données peut varier de façon significative.

Questions de conception de base de données

Pour planifier la configuration de la base de données de votre solution, suivez ces étapes :

1. Faites une estimation des modèles d'utilisation et déterminez la façon dont ces modèles affectent chacune des bases de données Commerce Server.

2. Testez les capacités de charge de votre site et enregistrez les performances des bases de données.

3. Remontez les serveurs de base de données de manière à optimiser les performances.

Pour plus d'informations concernant la planification d'un site Commerce Server, consultez le Kit de ressources Commerce Server 2000.

Vous devez considérer le niveau d'évolutivité de la base de données requis par votre site. Ci-après, quelques exemples de configurations possibles.

• Un serveur de base de données à un seul cluster avec une configuration de basculement à instances multiples (active/active) ou à instance unique (active/passive). Dans ce cas, un seul cluster peut prendre en charge toutes les bases de données requises par votre site Commerce Server.

• Des serveurs de base de données à plusieurs clusters avec une configuration de basculement à instances multiples ou à instance unique. Dans ce cas, la charge combinée de toutes les bases de données dépasse la capacité d'un seul cluster. Vous devez donc répartir les bases de données Commerce Server sur plusieurs clusters.

• Des bases de données en lecture seule identiques en clusters à l'aide de l'équilibrage de la charge réseau. Dans ce cas, une seule base de données telle que le catalogue Commerce Server connaît les modèles d'utilisation qui sont plus nombreux que ce qu'un seul serveur peut prendre en charge. Avec NLB, les requêtes sont distribuées entre plusieurs serveurs identiques pour regrouper leurs capacités.

• Des vues partitionnées avec SQL Server 2000. Dans ce cas, les modèles d'utilisation pour une seule base de données sont trop nombreux pour qu'un seul serveur puisse assurer la prise en charge. Les données doivent être partitionnées sur plusieurs serveurs. Cette configuration prend également en charge les mises à jour de base de données.

Les deux premiers scénarios de la liste sont les plus faciles à implémenter dans l'architecture du Centre de données Internet et couvrent la plupart des sites Commerce Server sur Internet. Seuls les très grands sites ou ceux qui ont des exigences particulières nécessitent les deux derniers scénarios de configuration. De tels sites sont plus difficiles à concevoir, à créer et à gérer que ceux correspondant aux deux premiers scénarios.

Les données utilisées par un site Commerce Server sont stockées dans une ou plusieurs bases de données. Nous vous recommandons de stocker chaque ressource dans une base de données séparée. En distribuant les ressources dans des bases de données séparées, vous pouvez mesurer les performances de la base de données et déplacer les ressources avec le moins d'effort.

Implémentation d'une solution de base de données en clusters

La solution décrite dans ce chapitre utilise une configuration de cluster de basculement à instances multiples dans laquelle les bases de données OLTP (Online transaction processing) sont distribuées sur les nœuds du cluster en fonction de l'utilisation. Cette configuration garantit une distribution équitable du trafic de la base de données sur chaque nœud, chaque serveur de base de données étant le nœud de basculement pour l'autre. La figure 2 illustre cette configuration.

Figure 2 Cluster SQL Server de basculement à instances multiples

Cette configuration fournit une solution rentable car elle utilise tous les matériels disponibles. Vous devez cependant vous assurer que l'un des serveurs peut gérer la charge des deux serveurs de base de données en cas de défaillance. Pour cela, testez soigneusement les performances de basculement avec des charges estimées se rapprochant le plus des charges relevées lors des périodes de pointe sur votre site.

Les sites Commerce Server requièrent au minimum une base de données MSCS_Admin, une base de données Data Warehouse, et au moins une base de données dans laquelle stocker les données du site. Comme nous l'avons vu précédemment, vous devez séparer chaque ressource dans des bases de données distinctes pour pouvoir maintenir chaque ressource selon ses besoins. La solution décrite dans ce chapitre divise les ressources du site de solution de vente Commerce Server entre les bases de données suivantes :

• MSCS_Admin

• Catalogue

• Profils

• Campagnes

• Configurations des transactions

• Transactions

• Data Warehouse

Pour les sites Commerce Server qui ont un faible volume de modèles d'utilisation, il est possible d'utiliser un seul serveur de base de données pour héberger toutes ces bases de données. Cependant, pratiquement tous les sites Commerce Server utilisent plusieurs serveurs de base de données pour des raisons de performance. Le nombre de serveurs requis dépend du niveau prévu d'utilisation du site et du budget disponible.

La solution décrite dans ce chapitre déploie le site de solution de vente sur le serveur et dans la configuration de base de données présentée à la figure 2. Les bases de données Catalogue, MSCS_Admin, Campagnes et Configurations des transactions de Commerce Server sont placées sur un serveur séparé afin de répartir la charge du site sur deux serveurs. Ces bases de données ont une activité de lecture élevée contrairement à l'activité lecture/écriture qui caractérise les bases de données Transactions et Profils. La séparation de ces bases de données sur des serveurs distincts permet l'optimisation de chacun des serveurs en fonction du type d'activité de la base de données qu'il héberge. Si des bases de données de support ou des objets personnalisés sont crées en plus des objets de base de données par défaut, ils doivent être placés à côté des bases de données Commerce Server correspondantes pour éliminer les jointures entre les serveurs. On peut prendre pour exemple une base de données de support qui contient tous les autres objets personnalisés, tels que ceux contenant des informations de connexion et d'erreurs.

Si les tests de performance indiquent qu'une base de données présente une charge excessive par rapport à ce qu'une seule paire de serveurs de base de données peut prendre en charge, vous devez utiliser des clusters de basculement à instance unique dans lesquels chaque cluster inclut un serveur à l'arrêt redondant. Vous répartissez ensuite les bases de données Commerce Server sur les clusters supplémentaires. La figure 3 illustre une configuration de basculement à instance unique.

Figure 3 Cluster SQL Server de basculement à instance unique

Cette configuration est plus coûteuse, car chaque ordinateur SQL Server en clusters requiert un serveur à l'arrêt redondant. Cependant, dans le cas d'une défaillance, le serveur à l'arrêt peut consacrer toutes ses ressources à la gestion de la charge de la base de données.

Planification des stratégies de mise à l'échelle

Dans la plupart des solutions Commerce Server, la mise à l'échelle des bases de données individuelles Commerce Server dans des serveurs de base de données individuels supporte sans problème la plupart des modèles d'utilisation tout en fournissant des niveaux élevés de performance et de disponibilité. Cependant, sur un site avec un débit exceptionnellement élevé ou avec des modèles d'utilisation exceptionnels, vous devez envisager la mise à l'échelle d'une seule base de données à travers plusieurs serveurs de base de données. Par exemple, de nombreux utilisateurs souhaitent parcourir le catalogue en même temps. Dans ce cas, vous pouvez répliquer la base de données Catalogue sur plusieurs serveurs de base de données en lecture seule. Si le nombre de clients actifs est particulièrement élevé, vous pouvez partitionner vos données de profils sur plusieurs serveurs.

Remarque : Avec toutes les stratégies de mise à l'échelle de base de données, il est recommandé d'accroître autant que possible les capacités avant d'envisager la mise à l'échelle. Ceci permet d'éviter les problèmes d'application et de gestion inhérentes à la conservation de données cohérentes lorsque les données sont distribuées.

Serveurs de base de données en lecture seule avec équilibrage de charge

L'autre approche pour la mise à l'échelle du catalogue Commerce Server ou d'autres données en lecture seule consiste à répliquer le contenu des bases de données sur plusieurs serveurs et à utiliser Network Load Balancing (NLB) pour distribuer les requêtes sur des serveurs de base de données individuels. Cela diffère de l'utilisation de serveurs fédérés car toute la base de données est répliquée sur chaque serveur et les requêtes entrantes sont réparties sur n'importe lesquels des serveurs. Par exemple, vous pouvez répliquer les données du catalogue sur plusieurs ordinateurs SQL Server comme indiqué dans la Figure 4.

Figure 4 Réplication SQL Server

Il s'agit de l'approche recommandée pour mettre à l'échelle le catalogue Commerce Server.

Les serveurs de base de données sont installés dans la ferme de stockage et ont un accès Fiber Channel au réseau SAN (Storage Area Network). Tous les serveurs de base de données sont requis pour partager une adresse IP virtuelle. Network Load Balancing équilibre la charge sur ces serveurs de base de données.

Dans cette configuration, le pool de connexion OLEDB est désactivé. Les connexions à la base de données ne sont donc pas réutilisées. Cela permet d'équilibrer la charge plus efficacement sur plusieurs serveurs.

L'un des serveurs de catalogue est configuré comme serveur unique pour recevoir les mises à jour du catalogue. La réplication est ensuite configurée pour passer ces mises à jour aux serveurs restants.

Serveurs fédérés

Les serveurs fédérés sont nécessaires lorsque la charge requise pour une seule base de données dépasse la capacité d'un serveur de base de données remonté verticalement. Dans ce cas, vous devez répartir les tables de la base de données entre plusieurs serveurs de base de données. Les serveurs fédérés sont implémentés à l'aide de la prise en charge fournie par SQL Server 2000 pour les vues partitionnées actualisables. Les vues partitionnées permettent de distribuer une seule table sur plusieurs serveurs indépendants selon une clé de partition. Chaque serveur contient un sous-ensemble de données et une vue SQL Server utilisée pour regrouper les données distribuées en un seul objet. Par exemple, vous pouvez partitionner les données du panier et de la commande en fonction du champ CustomerID et utiliser une vue partitionnée sur chaque serveur pour autoriser les requêtes par rapport à toutes les données du panier et de la commande. Normalement, les données du panier et de la commande sont stockées sur une seule base de données Transactions Commerce Server 2000. Vous pouvez cependant atteindre un niveau d'évolutivité supérieur en répartissant les données à travers plusieurs serveurs comme indiqué dans la Figure 5.

Figure 5 Fédération SQL Server

Le moteur de requête SQL Server analyse l'instruction utilisée pour accéder aux données et utilise le critère de la clause WHERE SQL pour déterminer si une requête distante est requise. Cela réduit le nombre de requêtes distantes utilisées (et par conséquent améliore les performances). Cependant, pour éliminer toutes les requêtes distantes inutiles, l'application client (ici, le site Commerce Server) doit inclure une logique de routage dépendant des données pour que la connexion initiale à la base de données soit effectuée sur le serveur dans la fédération contenant la plupart (si ce n'est pas toutes) des données requises. Ceci affecte la conception de l'application car la logique de routage doit être utilisée pour déterminer la chaîne de connexion à la banque de données de transactions pour chaque requête.

Les serveurs de base de données fédérés doivent être installés dans la ferme de stockage et utiliser des connexions Fiber Channel au réseau SAN (Storage Area Network). Le réseau SAN stocke tous les fichiers de données utilisés par les serveurs SQL.

Planification de la sécurité de la base de données

Lorsque vous envisagez d'installer SQL Server pour l'utiliser avec Commerce Server, n'oubliez pas que Commerce Server ne peut pas utiliser la sécurité intégrée de Windows pour se connecter à SQL Server. Vous devez configurer vos ordinateurs SQL Server de sorte qu'ils utilisent l'authentification Mode mixte et créer un compte de connexion SQL Server pour Commerce Server (n'utilisez pas le compte Administrateur système dans un environnement de production).

Vous pouvez définir le mode de sécurité pour SQL Server pendant l'installation ou vous pouvez utiliser l'outil SQL Server Enterprise Manager pour le modifier.

Planification de Data Warehouse et du service Predictor

En plus des bases de données OLTP requises par votre site Commerce Server, celui-ci va utiliser une base de données OLAP (analytical processing) pour réaliser l'analyse des données. Vous créez cette base de données en utilisant les services d'analyse SQL Server 2000. La base de données regroupe les données provenant du data warehouse dans des cubes OLAP pour générer des rapports de données résumés efficaces. Pour maximiser les performances de l'analyse des données, vous devez planifier soigneusement l'installation de la base de données OLAP.

Emplacement du data warehouse (magasin de données)

Le data warehouse doit être installé sur un serveur qui n'est pas en clusters et qui est indépendant des bases de données Commerce Server traitées précédemment. Un serveur dédié fournit un maximum de flexibilité pour la gestion et la conservation de la configuration Commerce Server. Les exigences d'évolutivité du data warehouse diffèrent de façon significative des besoins des autres bases de données Commerce. En séparant ces environnements physiquement, vous pouvez les gérer et les faire évoluer de façon indépendante.

Le programme d'installation de SQL Server 2000 pour les services d'analyse ne reconnaît pas les clusters et ne prend pas en charge les installations en clusters des services d'analyse. Le data warehouse est une fonction non critique qui prend en charge principalement les rapports et qui ne requiert pas la disponibilité élevée fournie par le cluster de basculement. Par conséquent, une installation des services d'analyse non ordonnée en clusters répond aux exigences des sites Commerce Server.

Si votre site Commerce Server requiert une disponibilité maximum du data warehouse, vous pouvez effectuer l'installation en clusters manuellement. Cependant, les services de support technique de Microsoft (PSS) ne prennent pas en charge officiellement un environnement en clusters pour les services d'analyse (pour plus d'informations, consultez l'article de la Base de connaissances Q294454). Si vous rencontrez des difficultés lors de l'exécution du data warehouse, PSS vous fournit toute l'aide disponible, mais le service technique peut vous demander de supprimer le data warehouse pour émettre un diagnostic.

Planification de la configuration du service Predictor

Le service Predictor de Commerce Server 2000 utilise des données du data warehouse pour identifier les segments du marché et prévoir des opportunités de vente. En général, vous devez exécuter le service Predictor sur le même serveur que celui du data warehouse. Le service Predictor utilise énormément les données stockées dans le data warehouse. L'exécution du service Predictor et du data warehouse sur le même serveur élimine le trafic du réseau. Cela fonctionne de façon acceptable dans la plupart des circonstances ; cependant, si votre data warehouse est très utilisé et dépasse la capacité de votre serveur, vous devez envisager de répartir les fonctions suivantes sur des serveurs dédiés :

• Data warehouse

• Service Predictor

• Traitement du cube OLAP

Tous ces processus doivent être placés dans la ferme de stockage VLAN pour réduire les problèmes de performance causés par un trafic réseau excessif. Le serveur hébergeant le data warehouse doit également être connecté au réseau SAN à l'aide de Fiber Channel.

Pour que le service Predictor fonctionne correctement, le data warehouse doit être peuplé avec des données provenant de fichiers journal de chaque ordinateur Commerce Server situé dans la zone DMZ. Vous pouvez utiliser les outils mis en place par l'architecture du Centre de données Internet pour rassembler ces fichiers journal et les charger dans une base de données. Vous pouvez également établir une stratégie IPSec entre les serveurs exécutant Commerce Server dans la zone DMZ et le serveur rassemblant les fichiers journaux. Le port 500 du pare-feu doit être ouvert pour autoriser le trafic IPSec à circuler entre les réseaux VLAN.

Planification de la configuration du service Direct Mailer

Le service Direct Mailer de Commerce Server 2000 offre la possibilité d'envoyer des messages électroniques publicitaires sur Internet, vous permettant ainsi d'implémenter des campagnes de marketing directes à travers votre site.

Pour la plupart des sites Commerce Server, le service Direct Mailer est jugé important mais pas fondamental. Bien qu'il soit possible d'exécuter le service Direct Mailer sur plusieurs serveurs, nous vous recommandons de l'installer sur un seul serveur. Dans l'architecture IDC, ce service est placé sur un serveur de l'infrastructure VLAN. Vous devez remonter le service Direct Mailer verticalement pour gérer les exigences de trafic du site. Si votre serveur exécutant le service Direct Mailer est surchargé et retarde l'envoi des messages électroniques Direct Mailer sortants mais cela n'affecte pas votre site. Le serveur rattrapera finalement le retard et fonctionnera de nouveau normalement.

Si vous devez étendre horizontalement le service Direct Mailer, vous pouvez inclure plus d'une ressource Direct Mailer dans votre implémentation Commerce Server en définissant plusieurs instances au niveau des ressources globales. Les ressources globales sont utilisables par tous les sites. Les ressources globales exposent un objet au niveau global dans le Gestionnaire Commerce Server et au niveau du site pour les sites qui utilisent des ressources globales. Pour plus d'informations concernant l'exécution de plusieurs serveurs avec le service Direct Mailer, consultez le Kit de ressources Commerce Server 2000.

Emplacement du service Direct Mailer

Si vous utilisez également BizTalk Server et que vous avez configuré un serveur Microsoft Exchange Server pour traiter les messages électroniques entrants, nous vous recommandons de placer le service Direct Mailer sur le même serveur.

Le service Direct Mailer doit être configuré pour l'envoi de messages SMTP (Simple Mail Transfer Protocol) aux serveurs de relais SMTP dans la zone DMZ. Ces serveurs relaient à la fois les messages SMTP entrants et sortants. Le service Direct Mailer et Exchange Server doivent être placés dans l'infrastructure VLAN derrière le deuxième pare-feu. Cette configuration est identique à celle requise par BizTalk Server. Si votre environnement prend en charge Commerce Server 2000 et BizTalk Server 2000, vous devez utiliser la même solution SMTP pour les deux applications.

Si votre site requiert que le service Direct Mailer soit disponible, vous pouvez exécuter le service dans un cluster de basculement. Le service Direct Mailer requiert que la base de données soit placée sur le même serveur. Il est possible d'installer le service Direct Mailer sur une configuration de basculement à instance unique, mais une configuration de cluster de basculement à instances multiples ne fonctionne pas.

Pour installer le service Direct Mailer sur un cluster, vous devez en premier lieu installer la base de données Direct Mailer sur une instance locale de SQL Server en utilisant le programme d'installation d'instance locale SQL Server 2000. Une fois le service Direct Mailer installé, vous pouvez déplacer la base de données vers l'instance SQL Server sur le cluster virtuel. L'agent SQL Server reconnaît le cluster. Par conséquent, vous pouvez installer la base de données Direct Mailer dans une configuration Windows Clustering. Vous devez installer le service Direct Mailer sur le même serveur que celui de sa base de données. Dans une configuration en clusters, vous devez installer le service Direct Mailer deux fois. Pour plus d'informations, consultez la section "Haute disponibilité" dans le Kit de ressources Commerce Server.

Planification de la configuration du serveur Business Desk

Business Desk est une application Web utilisée pour gérer le site Commerce Server selon un modèle commercial.

Pour que Business Desk fonctionne correctement, il requiert un équilibrage complet de la charge. Business Desk stocke un nombre significatif de références objet dans des variables de session et par conséquent connaît toutes les défaillances en matière de performance de toutes les applications utilisant ces techniques. Pour réaliser tout travail significatif à l'aide de Business Desk, vous devez configurer une ferme Web pour traiter ces requêtes.

Comme stratégie, vous devez planifier pour chaque serveur Business Desk la prise en charge de 5 à 10 utilisateurs concurrents. Vous devez configurer Network Load Balancing pour prendre en charge les affinités lors de la création de votre ferme Business Desk pour répondre à son besoin de connexions fiables.

Emplacement de Business Desk

Les serveurs hébergeant Business Desk doivent être situés sur un réseau sécurisé, car les informations auxquelles il permet d'accéder peuvent présenter un risque sérieux pour la sécurité si elles font l'objet d'une attaque. Dans l'architecture IDC, ces serveurs sont placés sur le réseau VLAN du groupe de stockage, qui est sécurisé derrière le pare-feu de périmètre et le pare-feu interne. Les facteurs suivants ont été envisagés lors de la décision de placer Business Desk sur le réseau VLAN du groupe de stockage :

• Les exigences d'équilibrage de la charge pour l'exécution d'une ferme de serveurs Business Desk sont différentes de celles du site de solution de vente. Pour conserver l'état de la session, Business Desk requiert que NLB conserve les affinités au serveur auquel vous vous êtes connecté à l'origine.

• Le réseau VPN (virtual private network) fournit un mécanisme par lequel les employés de votre société peuvent se connecter au réseau VLAN du groupe de stockage et modifier Business Desk sur Internet.

Environnement des tests de perfomances et résultats

Cette section traite de l'environnement de base utilisé pour les tests des résultats de tests exécutés sur l'architecture IDC avec Commerce Server 2000. Les tests se concentrent sur les serveurs IIS dans la couche Web.

Environnement test

Voici un résumé du matériel utilisé pour tester les serveurs IIS :

• Deux serveurs équipés de processeurs Pentium III 800 MHz, 640 Mo de mémoire et deux disques durs de 18 Go ont été utilisés pour exécuter IIS et Commerce Server 2000.

• Les ordinateurs de base de données SQL Server 2000 possèdent des processeurs Pentium III 800 MHz, 3 Go de mémoire et un réseau SAN (Storage Area Network).

• Deux ordinateurs de bureau clients standard ont été utilisés pour générer de la charge à l'aide de l'outil Web Application Stress. Les caractéristiques techniques exactes de ces ordinateurs ne sont pas importantes, tant qu'ils sont en mesure d'exécuter l'outil de stress.

Les tests de stress sont effectués sur une période de vingt-quatre heures sur une base de données test contenant un catalogue de 100 000 produits. Chaque client de stress a utilisé 2 000 utilisateurs quelconques et a été configuré pour exécuter 40 threads sans temps de réflexion. La charge générée par ces clients a été configurée de manière à se répartir de la manière suivante :

• 74 % pour les activités de navigation et de recherche.

• 25 % sur la page d'accueil.

• 1 % pour l'extraction

Performance des serveurs de base de données

La charge créée sur les serveurs de bases de données pendant le cycle de test a été faible, la charge du processeur n'excédant jamais 40 % sur chaque serveur. En raison des restrictions imposées par le labo de test, le matériel n'a pas pu remonter la couche Web pour créer une charge supplémentaire sur les serveurs de base de données. Des tests complémentaires doivent être effectués si des performances maximales de la part des serveurs de bases de données sont obligatoires pour votre implémentation de l'architecture IDC.

Performance du serveur Web

Les serveurs Web ont pratiquement été utilisés au maximum de leur capacité. Lors de la navigation du site à partir d'un autre client, les serveurs ont toujours réagi, avec uniquement quelques retards pour se déplacer dans le site. Le tableau suivant présente les résultats de chaque compteur de performance.

Compteurs de performance	Premier serveur Web	Deuxième serveur Web
Requêtes ASP/sec.	Moyenne de 55 pages/sec	Moyenne de 55 pages/sec
Utilisation du processeur	95 % en moyenne avec des pics de 100 %	90 % en moyenne avec des pics de 100 %
Temps d'attente des requêtes ASP	17 min en moyenne et 906 min maximum	16 min en moyenne et 2282 min maximum
Temps d'exécution des requêtes ASP	493 min en moyenne et 18 secondes maximum	335 min en moyenne et 4 secondes maximum
Échec des requêtes ASP	1	0
Évaluations des expressions/sec	De 45 à 55/sec	De 45 à 55/sec
Exécutions des annonces publicitaires/sec	De 25 à 30/sec	De 25 à 30/sec
Exécution des rabais/sec	15/sec environ	15/sec environ
Exécution du panier/sec	5/sec environ	5/sec environ
Exécution de l'extraction/sec	< 1/sec	< 1/sec
Extractions totales	9 483	9 140
Nombre de paniers total	432 027	420 815

Résumé

Microsoft Commerce Server 2000 permet de créer des solutions de commerce électronique à évolutivité, disponibilité, sécurité et gestion élevées. Lorsque vous envisagez d'implémenter une application Commerce Server 2000 dans l'architecture du Centre de données Internet, vous devez déterminer soigneusement l'emplacement de chacune des ressources utilisées par la solution. Le site de solution de vente a été déployé de la façon suivante :

1. La couche Web a été implémentée à l'aide de Network Load Balancing pour équilibrer la charge de plusieurs fermes de serveurs IIS dans la zone DMZ.

2. Les serveurs IIS ont été configurés pour exécuter tous les composants et pipelines COM+ directement sur la couche Web.

3. Les bases de données Commerce Server ont été déployées sur un seul cluster de basculement à instances multiples connecté au réseau SAN.

4. Le service Predictor et les services d'analyse ont été déployés sur un serveur de base de données séparé qui n'est pas en clusters et qui est connecté au réseau SAN.

5. Le service Direct Mailer a été déployé sur un seul serveur exécutant à la fois le service Direct Mailer et Exchange 2000 Server. Le serveur prend en charge les messages électroniques entrants pour BizTalk Server et héberge les boîtes aux lettres destinées aux messages entrants.

6. Les serveurs de relais SMTP redondants dans la zone DMZ ont été configurés pour relayer à la fois les messages électroniques entrants et sortants.

7. Business Desk a été installé sur le réseau VLAN de gestion derrière le deuxième pare-feu et le trafic Internet a été autorisé pour accéder à ces serveurs uniquement à travers une connexion VPN.

Les modifications que vous êtes susceptible d'effectuer pour répondre aux exigences de votre site sont :

• La mise à l'échelle des bases de données Commerce Server 2000 pour prendre en charge plusieurs clusters de basculement à instance unique.

• La mise à l'échelle du catalogue Commerce Server 2000 en installant plusieurs serveurs de catalogue en lecture seule équilibrés derrière NLB.

• L'exécution des traitements UC complexes (par exemple, la génération de documents volumineux compressés ou cryptés) sur une couche physique séparée dans l'infrastructure VLAN.

• La séparation du data warehouse et du service Predictor en plusieurs serveurs distincts.

Informations complémentaires

Pour plus d'informations concernant la conception et l'implémentation d'une solution Commerce Server 2000, consultez la documentation Commerce Server et le Kit de ressources Commerce Server 2000.

<< 1 2 3 4 5 6 7 8 9 >>

Dernière mise à jour le vendredi 1 mars 2002

Pour en savoir plus

• Lire la version US de cet article

• Ressources techniques sur Commerce Server 2000