Par Shaun Hirschman, Mathew Baldwin, Tito Leverette et Michael Johnson

Résumé : L'évolutivité et la haute disponibilité sont des propriétés essentielles mais contradictoires des infrastructures d'hébergement. Que vous soyez ingénieur Open Source, utilisateur de solutions commerciales ou ingénieur informatique Microsoft, aucune solution miracle ne semble exister. Cet article se concentre sur les composants requis pour créer un environnement ultime qui soit évolutif, fiable, sécurisé et facile à gérer, tout en garantissant une haute disponibilité (HA). (9 pages imprimées)

Sommaire

Introduction
Historique de l'industrie de l'hébergement et problèmes actuels
Éléments à prendre en compte lors de la planification d'architectures haute disponibilité pour l'hébergement de masse
Modèles de distribution de charge
Évolutivité de Microsoft IIS pour l'hébergement de masse
Tendances : isolement contre évolutivité
Scénario de pool d'applications partagé
Planification de vos pools d'applications pour une haute disponibilité
Réplication de configuration
Stockage de contenu
Cluster SQL
Conclusion

Introduction

L'évolutivité et la haute disponibilité sont des propriétés essentielles mais contradictoires des infrastructures d'hébergement. Que vous soyez ingénieur Open Source, utilisateur de solutions commerciales ou ingénieur informatique Microsoft, aucune solution miracle ne semble exister.

En explorant les différents aspects d'une infrastructure d'hébergement, nous pourrions peut-être trouver des technologies existantes qu'il serait possible de réunir pour créer une solution miracle. Ce processus permettra également d'exposer les lacunes à combler. La plate-forme miracle doit fournir une infrastructure pouvant autoriser une certaine densité du nombre de comptes client, tout en étant évolutive et extrêmement redondante.

Cet article se concentre sur les composants requis pour créer un environnement ultime qui soit évolutif, fiable, sécurisé et facile à gérer, tout en garantissant une haute disponibilité (HA). Tant les fournisseurs d'applications solitaires que les hébergeurs d'applications partagées de haute densité profiteraient tous d'une telle solution. Mais existe-t-elle vraiment ? Si elle n'existe pas, quels sont les difficultés qui nous bloquent aujourd'hui et jusqu'à quel point pouvons-nous nous en approcher ?

Historique de l'industrie de l'hébergement et problèmes actuels

Pour parfaitement comprendre les complexités d'une plate-forme d'hébergement Web, nous devons tout d'abord comprendre comment le marché de l'hébergement a démarré et comment il a évolué jusqu'à son état actuel. Avant que l'hébergement traditionnel n'ait commencé à prendre forme, les sites Web statiques simples étaient très répandus et relativement nouveaux pour le grand public. L'infrastructure créée pour supporter ce mouvement était également basique et visait plus à attirer le plus possible de clients qu'à fournir des services haut de gamme, tels que des applications interactives et une haute disponibilité.

Commençons par décrire l'architecture classique que les hébergeurs basés sur Microsoft utilisaient par le passé : un serveur Web autonome unique avec des services FTP, exécutant IIS avec du contenu hébergé localement sur le serveur. Chaque système autonome a son propre coût : matériel, licences logicielles, réseau, alimentation, espace, entre autres. Certain hébergeurs ont même poussé cette tendance à l'extrême en hébergeant tous les services sur un seul serveur pour un nombre x de clients. Par exemple, ils ont des serveurs avec Microsoft IIS, SQL, des logiciels de serveur de messagerie tiers et du stockage local pour le contenu hébergé.

Ces machines sont faciles à concevoir et rapide à déployer, en particulier si vous vendez des forfaits économiques aux clients qui veulent juste héberger quelques pages et rien de plus complexe.

Au fur et à mesure que ce type de plate-forme s'est développé, de nombreux problèmes ont commencé à apparaître : exigences de sauvegarde et de restauration, consommation d'espace de centre de données coûteux, alimentation par serveur, clients à charge élevée et gestion générale. Aux problèmes de plate-forme se sont ajoutés la demande croissante des consommateurs et les progrès réalisés dans le domaine des nouvelles technologies Web. Des technologies, telles que PHP, Cold Fusion, ASP, JSP et ASP.NET sont apparues, fournissant des plates-formes plus complexes pilotées par le souhait du consommateur de disposer d'une fonctionnalité plus riche et le désir d'obtenir de meilleurs résultats commerciaux. Cela a débouché, à son tour, sur de nouvelles applications nécessitant des stockages de données tels que SQL et autres technologies apparentées. À mesure que de nouvelles applications étaient créées, le potentiel commercial les entourant est devenu plus évident et plus recherché.

Les hébergeurs, en tentant de maximiser les résultats et de simplifier la gestion, ont continué à faire fonctionner tous les services nécessaires pour prendre en charge leurs clients sur un serveur autonome. Cela a créé une charge accrue sur un seul serveur, l'encombrant et réduisant le nombre de sites Web qu'il pouvait servir. La demande des consommateurs a progressé plus rapidement que la technologie matérielle ne pouvait le supporter. Les hébergeurs ont dû évoluer vers l'extérieur, en séparant et isolant les services sur plusieurs serveurs au lieu d'évoluer verticalement avec un matériel plus rapide.

L'industrie de l'hébergement a continué à être saturée d'entreprises concurrentielles en réponse à la demande élevée de services Web tels que les sites Web dynamiques et les paniers du commerce électronique. Ce marché florissant a forcé les hébergeurs à différencier leurs services de ceux des autres en créant des contrats de niveau de service (SLA, Service Level Agreement). Non seulement les hébergeurs doivent fournir des services bon marché, mais ils doivent toujours être disponibles. Cela se justifie par la dépendance accrue des consommateurs et des entreprises envers le Web et leur demande d'applications plus interactives et complexes. La production de services de haute disponibilité se traduit habituellement par un nombre accru de serveurs pour supporter la redondance, ainsi que par de nouvelles exigences en termes de performances, de sécurité et gestion. Comment les hébergeurs peuvent-ils faire évoluer et supporter ces services avec l'architecture matérielle et logicielle donnée ?

Au vu de ces changements industriels, les entreprises de la technologie logicielle à la base de ces services se sont rendu compte que leurs systèmes d'exploitation actuels n'étaient pas capables de répondre aux besoins des hébergeurs. Un niveau élevé de contact d'administrateur système était toujours requis pour que les opérations s'exécutent aussi facilement que possible. Les fournisseurs de services indépendants et les ingénieurs de l'industrie ont pris conscience des lacunes au niveau du logiciel/matériel associé aux services et ont commencé à se concentrer sur le développement de technologies visant à combler ces lacunes tout en en profitant.

C'est à ce stade que les hébergeurs ont commencé à s'intéresser à la construction de plates-formes qui sont plus évolutives et peuvent atteindre une densité par machine plus élevée. Elles doivent également être plus faciles à gérer. La première étape dans la construction de ce type d'architecture consiste à étudier les divers services que l'hébergeur doit supporter et gérer.

Éléments à prendre en compte lors de la planification des architectures haute disponibilité pour l'hébergement de masse

Lorsque l'hébergeur s'arrête et réfléchit aux technologies qu'il peut associer et à la manière de construire une plate-forme pour supporter de nombreux services et sites Web, plusieurs exigences primordiales lui viennent à l'esprit. Ces exigences vont de la densité des utilisateurs ou des applications au type de fonctionnalités et services à supporter et leur impact sur le système sous-jacent (ASP. NET, PHP, SQL entre autres), sans oublier le coût par site ou application hébergé. Lors de la conception d'une plate-forme hébergée, l'objectif principal consiste à optimiser l'évolutivité, la disponibilité, la densité et la parité de prix tout en adhérant à un niveau de sécurité aussi élevé que possible grâce à l'isolement des clients.

Nous classons ces services dans deux grands segments, les principales parties de l'architecture étant : cluster(s) IIS, cluster(s) IIS, services d'infrastructure de support, tels que services Active Directory, System Center Operations Manager, stockage centralisé sur un réseau de stockage ou stockage attaché au réseau, clusters de déchargement SSL, clusters FTP et autres clusters similaires.

La séparation de ces services en plusieurs segments permet à l'hébergeur de faire évoluer l'architecture de plusieurs façons. Un hébergeur peut faire évoluer un cluster SQL différemment d'un cluster Web, ce qui met sur la table un ensemble différent de problèmes liés à l'architecture.

Un autre facteur affectant l'architecture est la prise en charge des exigences héritées, dont le meilleur exemple est donné par les extensions serveur Microsoft Frontpage (FPSE). Elles sont toujours utilisées par des milliers de clients et sont nécessaires si la plate-forme d'hébergement de masse espère les attirer. Ces extensions sont habituellement utilisées par les petits commerçants pour créer des sites simples. Elles sont toujours utilisées par des outils de développement tels que Microsoft Visual Studio et Microsoft Visual Web Developer pour leur fonctionnalité de téléchargement HTTP, malgré les avertissements de Microsoft. Les composants hérités tels que FPSE ne peuvent pas être tout simplement supprimés par les grands hôtes sans perdre une partie de leur clientèle.

Intéressons-nous maintenant à certains de ces clusters à l'intérieur de l'architecture. Le plus important est le cluster Web, suivi par le cluster SQL. Il est important de rappeler que l'un des éléments clés qui distinguent les hébergeurs d'autres entreprises telles que les départements IT internes, est qu'ils tentent de mettre autant de sites ou bases de données sur un cluster que possible. Pour cette raison, certaines solutions d'entreprise ne fonctionnent pas pour eux. De plus, les hébergeurs ne contrôlent pas toujours les types d'applications placés sur un serveur, si bien qu'ils ne peuvent pas définir la capacité de la même façon que les entreprises classiques.

Figure 1. Modèle de distribution de charge d'application

Modèles de distribution de charge

Comme il existe plusieurs parties frontales Web, l'architecte d'hébergement doit tenir compte de nombreuses options pour distribuer la configuration sur tous les serveurs Web. Cette configuration dépend du type de modèle de distribution de charge qui est choisi. Il existe plusieurs modèles de distribution de charge sur plusieurs parties frontales Web. Nous en traiterons deux qui sont courants parmi les scénarios d'hébergement. Il s'agit de la distribution de charge d'application et de la distribution de charge globale.

Distribution de charge d'application

La distribution de charge d'application décrit un modèle dans lequel la charge est distribuée sur plusieurs nœuds de partie frontale Web selon la fonction du serveur. Ce modèle est généralement basé sur des requêtes et s'appuie sur les fonctionnalités de routage de couche d'application que de nombreux équilibreurs de charge de réseau prennent maintenant en charge. Ce modèle permet aux hébergeurs de fractionner la batterie de serveurs Web en fonction des charges de serveur. En étudiant une implémentation classique de ce modèle, vous verrez que des serveurs différents de ceux qui fournissent un contenu dynamique tels que ASP.NET ou PHP sont désignés pour le contenu statique (voir figure 1).

Cette configuration peut être encore plus détaillée en fractionnant les serveurs dynamiques selon leur fonction spécifique. Cela exige la création de batteries secondaires pour chaque type d'application. Tout le trafic ASP.NET est acheminé vers une batterie secondaire ASP.NET et tout le contenu PHP est acheminé vers une autre batterie secondaire. Comme les serveurs de contenu dynamique nécessitent normalement plus de ressources, cette conception permet à l'hébergeur d'utiliser une catégorie différente de matériel pour ces sites que celle requise pour le contenu statique.

La plupart des hébergeurs doivent tenir compte du coût lors de la conception de leur plate-forme ; ainsi, le modèle de distribution de charge d'application peut ne pas toujours être réalisable, simplement parce qu'il augmente le nombre de serveurs nécessaires. La distribution de charge d'application augmente également la complexité de la gestion des serveurs et impose une fiabilité élevée de l'équipement de mise en réseau.

Figure 2. Scénarios de pool d'applications un à un (cliquer sur l'image pour l'agrandir)

Distribution de charge globale

Pour diminuer le plus possible les coûts et également réduire la complexité de la gestion de la plate-forme, un hébergeur peut choisir d'implémenter un modèle de distribution de charge globale. Dans un modèle de distribution de charge globale, tous les serveurs partagent exactement la même configuration. Chaque serveur de la batterie de serveurs Web peut également gérer du contenu statique et dynamique. Sur les systèmes exécutant IIS, la conception de pools d'applications est vitale pour maximiser l'évolutivité dans ce type de modèle.

Évolutivité de Microsoft IIS pour l'hébergement de masse

Dans une entreprise d'hébergement de masse qui se concentre sur la plate-forme Microsoft, il est constamment exigé une densité plus élevée sur chaque serveur de la batterie. Avec une architecture HD complexe, l'hébergeur augmente son modèle de densité ; cependant, des goulots d'étranglement de la performance surviennent toujours, en particulier avec les pools d'applications.

Dans IIS, la conception de pools d'applications est vitale pour atteindre une densité maximale. Ne pas prendre le temps de planifier correctement la conception de pools d'applications peut entraîner des problèmes de performance et de stabilité inattendus. Les pools d'applications concernent véritablement l'isolement et il existe une corrélation directe entre le niveau d'isolement que vous choisissez et le nombre d'applications que vous pouvez placer sur un serveur. En concevant les pools d'applications, vous devez peser votre besoin de sécurité contre la stabilité souhaitée. Les hébergeurs doivent choisir entre deux scénarios de pools d'applications, un scénario un à un ou un scénario de pools d'applications partagés un à plusieurs. Remarquez que sur la figure 2, les scénarios de pools d'applications un à un ont tendance à tendre plus vers l'isolement, que vers l'évolutivité. Le scénario de pools d'applications partagés d'autre part, a tendance à tendre vers des niveaux plus élevés d'évolutivité, plutôt que vers l'isolement Idéalement, l'hébergeur choisit une solution qui lui permet de maximiser l'évolutivité sans sacrifier l'isolement et la sécurité.

Tendances : isolement contre évolutivité

Un scénario d'isolement un à un est défini comme ayant un pool d'applications attribué à une seule application ou dans un scénario d'hébergement Web partagé à un site Web unique. Cela permet à un hébergeur d'atteindre un niveau d'isolement supérieur, parce que chaque site Web ou application s'exécute dans un processus unique et ne partage pas de ressources avec d'autres sur le serveur. C'est une solution optimale pour un hébergeur ou éditeur de logiciels indépendant qui doit garantir à ses clients que les autres clients sur le même serveur n'auront pas accès à leurs données importantes. Cependant, ce scénario est limité dans les scénarios d'hébergement de masse. Bien qu'il apporte un niveau souhaité d'isolement et de sécurité, en raison des exigences de mémoire, il n'arrive pas à fournir aux hébergeurs l'évolutivité qu'ils désirent. À chaque exécution du pool d'applications, celui-ci consomme de la mémoire, et finalement un goulot d'étranglement se crée.

L'introduction d'un code dynamique dans la plate-forme ajoute un tout nouveau niveau de complexité. Par exemple, les applications ASP.NET augmentent la quantité de mémoire nécessaire pour le pool d'applications. Cela devient un problème pour l'hébergeur, parce que le nombre de sites Web dynamiques pouvant fonctionner sur un serveur est ainsi limité. Il commence à comprendre qu'il ne peut faire évoluer que des centaines de sites, et non pas des milliers, ce qui est la norme pour la plupart des améliorations affectant la technologie matérielle. En particulier, l'introduction de l'architecture 64 bits a permis à de nombreux hébergeurs de disposer d'énormes quantités de mémoire sur leurs serveurs. Bien que cela leur permette d'aller au-delà des goulots d'étranglement potentiels, cela pourrait également faire surgir d'autres problèmes.

Scénario de pool d'applications partagé

Un scénario de pool d'applications partagé décrit une situation dans laquelle plus d'une application ou site Web réside dans le même pool d'applications. Il existe deux configurations différentes de pool d'applications partagé. La première est une configuration un à N, où le fournisseur d'hébergement dédie un pool d'applications unique à un nombre prédéfini de sites Web. La seconde est une configuration un à tous, où l'hébergeur place tous les sites Web dans un pool d'applications unique. Un scénario de pool d'applications partagé permet une meilleure évolutivité, parce qu'il n'expose pas le système aux contraintes de mémoire imposées par une conception de pool d'applications un à un.

Certaines personnes craignent que les sites et applications Web d'un pool d'applications partagé puisse potentiellement avoir accès aux données des autres sites et applications du pool. Certaines mesures doivent être prises pour s'assurer que ces applications et sites Web sont sécurisés. Par exemple, chaque site Web doit avoir un utilisateur anonyme unique, et une liste de contrôle d'accès doit être appliquée aux fichiers Web. En outre, les applications ASP.NET doivent être configurées avec une sécurité d'accès au code et définies à un niveau de confiance moyen. Ces types de mesures aideront à garantir que les applications et sites Web sur le serveur sont sécurisés même dans un pool d'applications partagé.

Comme toutes les applications sont exécutées sous le même processus, les pools d'applications partagés ne disposent pas de l'isolement dont de nombreux fournisseurs d'hébergement ont besoin. Cela peut constituer un problème dans les scénarios HD, parce qu'une application à problème affecte tous autres sites et applications Web du même pool. Par exemple, une application peut amener le pool d'applications à recycler ou, pire, s'arrêter complètement. Il est également plus difficile pour les administrateurs système d'identifier un problème lorsqu'un seul pool compte plusieurs sites et applications. Bien qu'il existe des outils permettant aux hébergeurs d'isoler les problèmes au sein d'un pool d'applications, cette tâche est plus facile en utilisant un pool d'applications un à un comme modèle de site Web.

Planification de vos pools d'applications pour une haute disponibilité

Les hébergeurs doivent trouver l'équilibre entre atteindre des niveaux d'isolement élevés et maximiser l'évolutivité. De ce fait, ils sont nombreux à être forcés d'utiliser un hybride des scénarios de pool d'applications susmentionnés. Un scénario type comprend plusieurs pools d'applications, chacun ayant des fins spécifiques. Par exemple, les sites Web qui contiennent uniquement du contenu statique peuvent être tous placés dans un seul pool d'applications partagé. Cela possible parce que le contenu statique n'est pas associé aux problèmes de sécurité et de performances qui affectent le contenu dynamique. Tous les autres pools d'applications sont dédiés aux sites qui contiennent du contenu dynamique. Cela permet à l'hébergeur d'attribuer davantage de ressources à ces sites. Cette configuration est plus courante dans les environnements d'hébergement partagés où une plate-forme unique doit desservir des clients ayant du contenu statique et dynamique.

Réplication de configuration

Une autre exigence fondamentale pour les environnements HD pour l'hébergement de masse HD, consiste à maintenir l'état et la configuration sur toutes les parties frontales Web de la batterie de serveurs. Bien que d'autres configurations doivent exister sur chaque partie frontale, la plus importante est celle du serveur Web. Certains serveurs Web prennent un magasin de configuration centralisé. Lorsque ce n'est pas le cas, une solution logicielle doit être mise œuvre pour répliquer la configuration sur tous les serveurs.

Stockage de contenu

L'un des principes de base d'une plate-forme d'hébergement de masse très évolutive à laquelle les architectes sont confrontés consiste à déterminer l'emplacement du contenu client qui sera hébergé. Dans la plupart des cas, il s'agit d'un contenu qui vit dans SQL ou sur disque. Dans la mesure où la partie frontale de l'architecture est configurée par clusters avec des milliers de sites, il n'est pas facile de localiser le contenu sur les disques embarqués, à connexion directe. Les sections suivantes décrivent les différentes architectures de stockage courantes parmi les entreprises d'hébergement.

Stockage à connexion directe (DAS)

DAS est l'une des méthodes de stockage les plus courantes et classiques utilisées par les entreprises d'hébergement Web. Il s'agit de serveurs Web autonomes dans lesquels le contenu est stocké localement. Le principal avantage étant que si un serveur autonome unique est en panne, la totalité de la base client n'est pas hors ligne. L'un des principaux inconvénients est que les clients peuvent être soumis à n'importe quel type de défaillance matérielle, pas uniquement à une défaillance de sous-système de disque. De plus, ce type de configuration introduit des problèmes tels que les limites de densité, les problèmes de migration et le manque de haute disponibilité pour les sites Web et la distribution de charge.

Stockage à connexion réseau (NAS)

La plupart des hôtes ayant une plate-forme hautement évolutive ont choisi d'utiliser NAS comme stockage à distance centralisé pour tous leurs clients. Dans un environnement Microsoft Windows haute disponibilité, le NAS est accessible via Common Internet File System (CIFS), généralement sur un réseau de stockage dédié. Le contenu Web client est stocké de façon centralisée sur le NAS, le chemin du NAS étant traduit en un chemin logique utilisant le système de fichiers distribués (DFS). L'association de NAS et DFS permet à un hébergeur Windows de propager des clients sur plusieurs sous-systèmes de stockage NAS, en limitant ainsi l'impact d'un problème global sur ces clients.

L'optimisation de CIFS, TCP/IP et NAS joue un rôle important sur l'évolutivité du NAS en fonction du nombre de sites clients simultanés pour lesquels il peut proposer du contenu. Avec une mauvaise optimisation sur le NAS, les hébergeurs peuvent introduire des problèmes susceptibles d'affecter tous les clients. Cependant, les hébergeurs réduisent également ce problème en utilisant plusieurs sous-systèmes NAS pour différents segments de clients et en dédiant des interfaces et réseaux de stockage à ce type de trafic.

De nombreux sous-systèmes NAS ont des fonctionnalités de mise en miroir et d'instantané. Ces technologies sont utilisées par l'hébergeur pour fournir un processus solide en cas de sinistre et de récupération, surtout étant donné que le système de stockage peut contenir le contenu de dizaines de milliers de clients.

C'est un problème avec un pur sous-système de stockage NAS, parce que les technologies telles que SQL ne prennent pas en charge le stockage à distance de leurs bases de données via CIFS, ce qui limite l'hébergeur au niveau des types de services qu'il peut offrir.

Réseau de zone de stockage (SAN)

De nombreux systèmes de stockage d'entreprise sont capables de fonctionner à la fois comme un SAN et un NAS, la principale différence étant la méthode utilisée pour s'y connecter. Dans le cas d'un SAN, les principales méthodes sont Canal fibre (FC) et iSCSI.

Les entreprises d'hébergement sont capables de créer des systèmes SQL et de messagerie évolutifs haute disponibilité, tels que Microsoft Exchange, en s'appuyant sur les fonctionnalités d'un SAN en tant que stockage centralisé pour ces types de clusters. De plus, plus le SAN est avancé, plus l'entreprise d'hébergement a d'options pour exécuter les tâches telles que la gestion d'instantané et de récupération dans SQL ou Exchange.

L'un des principaux obstacles à un système de stockage d'entreprise est le coût supporté par l'hébergeur. Les hébergeurs veillent à s'assurer que le produit qu'ils sont sur le point de déployer aura un retour sur investissement (ROI) assez élevé pour garantir le coût d'un SAN.

Cluster SQL

SQL est un service majeur que de nombreux hébergeurs offrent à une majorité de leurs clients. Cependant, c'est également l'un des principaux domaines que de nombreux hôtes ne mettent pas en œuvre en tant que cluster. Et ceci, pour plusieurs raisons, la principale étant le coût et la concession de licence. Toutefois, les hébergeurs qui utilisent un cluster SQL haute disponibilité doivent concevoir leur architecture de sorte à sélectionner le bon type de méthodologie de mise en clusters, qui prendra en charge de nombreuses bases de données.

Contrairement aux autres entreprises où le cluster SQL consiste en un nombre de bases de données relativement faible, les entreprises d'hébergement déploient des centaines, voire des milliers, de bases de données sur un seul cluster de base de données. Ce cluster doit être résilient tant en termes de performances que de durée de fonctionnement. Comme les entreprises d'hébergement n'ont aucun contrôle sur la façon dont leurs clients écrivent leurs applications, certains problèmes uniques se présentent lors de la conception d'un cluster pour l'hébergement de masse. Dans un environnement d'hébergement, il est attribué à chaque client de 1 à n bases de données. Ces bases de données peuvent être stockées sur un cluster unique ou distribuées sur plusieurs clusters. Le cluster le plus courant créé par un hébergeur pour un hébergement SQL de masse est le cluster SQL actif-passif standard. Cependant, à mesure que les hébergeurs passent à l'hébergement software-as-a-service (SaaS), les exigences affectant le cluster SQL passent de la redondance de nœud à la redondance de données. Cela pose davantage de problèmes, parce que ces mêmes systèmes hébergent toujours de nombreuses bases de données.

Il n'existe pas de vraiment de manière appropriée et rentable de créer une plate-forme de clusters SQL évolutive, de haute disponibilité et dense. Chaque topologie de cluster a ses inconvénients associés au fait que les hébergeurs ne contrôlent pas la conception de l'application du client. Le cluster SQL idéal permettrait aux hôtes de procéder à une distribution de charge ainsi qu'à une mise en miroir de base de données sans devoir traiter les problèmes de collisions de transaction, tout en maintenant un nombre très dense de bases de données sur le ou les clusters.

Conclusion

Les fournisseurs de service doivent continuellement relever de nouveaux défis pour répondre à la demande croissante des clients de nouveaux services offrant plus de valeur aux petites et moyennes entreprises, aux développeurs, aux consommateurs et aux concepteurs. Ils doivent fournir un niveau de service élevé pour conserver la fidélité de leur clientèle et atteindre leurs objectifs commerciaux. Les fournisseurs de services cherchent comment proposer une plate-forme Web miracle capable d'aider à réduire le coût total de propriété (TCO) et de garantir la satisfaction du client de façon efficace.

Lorsque la solution de plate-forme Web comprend une fourniture Web, un stockage de données et un stockage de base de données, un goulot d'étranglement survient inévitablement dans l'un de ces composants. Toute solution n’est aussi forte que son maillon le plus faible. Fondamentalement, chaque composant d'une solution doit évoluer vers l'extérieur et vers le haut avec redondance et rentabilité.

Cet article n'indique pas quelle technologie (Open Source ou Closed Source) pourra combler la lacune ou a déjà pu le faire dans certains secteurs, mais concerne plutôt les problèmes architecturaux sous-jacents qui ne sont pas « primordiaux » lors du développement des technologies. De nos jours, il ne suffit plus de créer la technologie pour l'amour de la technologie en tentant de remplir une niche. Ce n'est que par la stratégie, la planification et le développement de solutions à grande évolutivité que nous pourrons prendre en charge des exigences de grande évolutivité. Le monde grandit, les besoins augmentent et cela n'a de sens que si les infrastructures suivent la même voie.

À propos des auteurs

Shaun Hirschman travaille dans le domaine de l'hébergement depuis plus de huit ans et il est très au courant des défis techniques et commerciaux inhérents au secteur. Avant de rejoindre Microsoft en 2006, Shaun a commencé dans l'industrie de l'hébergement à un poste de support technique avant de devenir administrateur confirmé de systèmes Windows. Il connaît et maîtrise parfaitement les systèmes Microsoft. Il apprécie tout particulièrement de travailler sur les nouvelles versions des logiciels et matériels pour tenter d'apaiser sa soif de connaissances.

Mathew Baldwin travaille dans le domaine des services hébergés depuis 10 ans. Par le passé, il a occupé des postes d'architecte, ingénieur système senior, consultant régulier et consultant pour les plates-formes Microsoft auprès de plusieurs entreprises de services hébergés. Il a joué un rôle important dans la commercialisation de la première plate-forme d'hébergement partagé Windows 2003 à cluster et a travaillé en étroite collaboration avec Microsoft sur plusieurs projets. Il travaille actuellement comme architecte senior pour Affinity Internet.

Tito Leverette travaille dans le domaine de l'hébergement depuis plus de 8 ans. Il a démarré sa carrière chez Interland, Inc. (désormais Web.com). Avant de rejoindre Microsoft, Tito était architecte sur l'équipe de plate-forme Web pour SunTrust, Inc., la neuvième plus grande banque des Etats-Unis. Tito a des années d'expérience dans la conception, la construction et le déploiement d'infrastructures Web destinées aux grandes entreprises, ainsi qu'aux clients d'hébergement. Il est diplômé de l'institut de technologie de Géorgie (Georgia Tech).

Michael Johnson a passé plus de sept ans dans le domaine des fournisseurs de services Web, où il a développé et conçu l'architecture d'applications et de solutions extrêmement évolutives sur les produits Microsoft. Il travaille actuellement comme spécialiste de l'architecture Web pour Microsoft.

Cet article a été publié dans The Architecture Journal, publication papier et en ligne produite par Microsoft. Pour plus d'articles, veuillez consulter le site Web de The Architecture Journal.