Beruflich Dokumente
Kultur Dokumente
1. Introduction ............................................................................................................................. 1
2. Utilisations du clustering nentrant pas dans le cadre du sujet de cet expos .............................. 1 2.1. Le clustering, utilis pour le calcul distribu / rparti / parallle ................................................ 1 2.2. Clustering et calcul parallle, Supercalculateurs.......................................................................... 2
3. La dfinition du clustering ou grappe de serveurs ...................................................................... 3 3.1. Dfinition simple : ........................................................................................................................ 3 3.2. Dfinition technique : ................................................................................................................... 3 3.3. Principe de fonctionnement ......................................................................................................... 3 3.4. Les modes de clustering ............................................................................................................... 4
4. Les usages dun cluster ............................................................................................................. 4 4.1. Le load balancing .......................................................................................................................... 5 4.1.1. Dfinition ............................................................................................................................... 5 4.1.2. Boitier et logiciel de load balancing ...................................................................................... 7 4.1.3. Exemple de typologie rseau avec load balancing ................................................................ 8 4.2. La tolrance de panne .................................................................................................................. 9 4.2.1. Dfinition ............................................................................................................................... 9 4.2.2. Principe de fonctionnement dans le cluster ....................................................................... 10 4.3. Exemple concret de rpartition de charge, ncessitant un cluster : Wikipdia. ....................... 10 4.3.1. Prsentation de Wikipdia .................................................................................................. 10 4.3.2. Rpartition de charge et requte utilisateur....................................................................... 11
5. Clustering et logiciels .............................................................................................................. 15 5.1. Les techniques de clustering selon Microsoft ............................................................................ 15 5.1.1. Lquilibrage de la charge rseau (NLB - Network Load Balancing) .................................... 15 5.1.2. Lquilibrage de la charge des composants CLB (Component Load Balancing) .................. 15 5.1.3. Service de cluster................................................................................................................. 15 5.2. Le clustering selon Linux............................................................................................................. 16
7. Enjeux de la haute disponibilit .............................................................................................. 18 7.1. Les Enjeux du clustering ............................................................................................................. 18 7.2. Enjeux de la haute disponibilit ................................................................................................. 19 7.3. Exemples de cas de mise lpreuve ......................................................................................... 20 7.3.1. Exemple 1 : Survivre un incendie grce la rplication de donnes ............................... 20 7.3.2. Exemple 2 : Tolrance de panne : le risque zro nexiste pas............................................. 22 7.3.3. Exemple 3 : Laroport ........................................................................................................ 23
8. Conclusion .............................................................................................................................. 24
1. Introduction
Dans tous les articles rdigs, nous trouvons le terme de clustering et ce dans des sens et contextes diffrents. Bien que le concept ne soit pas li une technologie particulire (ou un constructeur / une marque en particulier), les domaines dutilisation du clustering peuvent tre disparates. Au travers de cet expos, nous tudierons le clustering sous deux problmatiques dans le cadre dune entreprise : La tolrance aux pannes Lquilibrage de la charge rseau Nous explorerons la technique du clustering en passant en revue ses diffrents paramtres avec des exemples concrets. Afin dexpliquer une des utilisations du clustering, nous traiterons dabord - dans un but dclaircissement - les solutions de calcul parallle ou distribus et les superordinateurs qui poursuivent des objectifs diffrents mais font souvent appel au terme de clustering.
Lautre diffrence notable en est lusage. En effet si les calculs parallles ou distribus et les superordinateurs sont destins rpondre des besoins scientifiques ou militaires dans la plupart des cas, les clusters intgrant des solutions de rpartition de charge et de tolrance aux pannes rpondent eux des problmatiques commerciales, sites de-commerce, moteur de recherches et sites forte frquentation.
Les X nuds ont les accs en lecture/criture sur tous les disques partags. Cest un partage matriel. Le Shared Nothing Model
Chaque nud gre ses propres disques et est le seul habilit crire et lire sur les ressources des disques. Chaque nud se voit attribuer ses ressources matrielles propres. Le Mirrored Servers
Un seul nud rpond aux requtes clientes, lautre nud est en attente prt remplacer son homologue en cas de panne. Cest simplement une copie conforme du premier nud, avec rplication en temps rel.
Elles ne peuvent pas soffrir la moindre interruption de service qui serait synonyme de perte nette de transaction/frquentation donc de chiffre daffaires. Limage de marque de lentreprise pourrait aussi en ptir et avoir des consquences en termes de frquentation court et moyen termes. En ce qui concerne les accs dimportante base de donnes nous pourrions prendre les exemples des centres de recherches scientifiques comme le CERN (Organisation Europenne pour la Recherche Nuclaire), la NASA (National Aeronautic and Space Administration), ou bien encore le CNRS (Centre National de la Recherche Scientifique), CIRS (Centre International de Recherche Scientifique) Toutes les organisations commerciales cites ci-dessus ont faire face des requtes Internet trs nombreuses (pic de frquentation, hausse du trafic trs important en peu de temps) du fait des services Web quelles proposent, quant aux centres de recherches leurs bases de donnes importantes composes de donnes sensibles doivent tre tolrantes aux pannes. Ces deux types dorganisation doivent donc mettre en place des techniques de rpartition de charge (Load balancing) et de tolrance de pannes.
Gnralement un rpartiteur matriel agira sur les paquets rseaux agissant sur le routage.
Deux mthodes sont alors possibles : Le routage direct : Le rpartiteur route la mme adresse de service au travers de diffrents serveurs physiques locaux qui doivent tre sur le mme segment de rseau et doivent partager la mme adresse de service. Cette mthode possde lnorme avantage de ne ncessiter aucune modification au niveau IP, faisant en sorte que les serveurs rpondent directement lutilisateur sans passer par le rpartiteur. Cest ce quon appelle le retour direct du serveur (Direct Server Return - DSR). Comme la puissance de traitement requise est minime, cette mthode est couramment utilise sur les serveurs frontaux des sites fort trafic. Dun autre cot, elle requiert de solides comptences du modle TCP/IP pour obtenir une configuration correcte et optimale. La translation dadresse IP (NAT) : Lutilisateur se connecte sur une adresse de destination virtuelle qui est ensuite convertie par le rpartiteur en adresse relle de lun des serveurs. A premire vue, cette mthode semble la plus simple dployer puisquelle ne requiert aucune configuration du serveur. En revanche, elle requiert des rgles de programmation applicative trs strictes. En ce qui concerne les logiciels de rpartition, le plus souvent, ils fonctionnent comme des reverse proxy , prtendant tre le serveur et ayant ensuite pour rle de lui transmettre le trafic. Ceci implique que les serveurs eux-mmes ne puissent tre directement joignables par les utilisateurs, mais galement que certains protocoles ne seront pas grs par le rpartiteur de charge. Ces logiciels ncessitent plus de puissance que les solutions matrielles agissant au niveau du rseau mais comme ils sparent les communications entre les utilisateurs et les serveurs, ils fournissent ainsi un premier niveau de scurit en ne transmettant que ce quils comprennent. Un rpartiteur de charge peut distribuer la charge de multiples faons. Une ide reue trs rpandue est quil enverra la requte au serveur qui rpond le plus rapidement. Cette pratique doit tre vite car si un serveur a de bonnes raisons de rpondre plus rapidement, il risque de dsquilibrer la ferme de serveurs en rcuprant la majorit des requtes. Une autre ide frquemment rencontre consiste envoyer une requte au serveur le moins charg. Bien que cela soit utile dans des environnements qui supposent des sessions de longue dure, ce nest nullement adapt pour des serveurs dont la charge peut varier dun facteur important en quelques secondes. Pour les fermes de serveurs homognes, la mthode cyclique (round robin) est bien souvent la meilleure.
Elle utilise chaque serveur la suite. Si les serveurs sont de capacit ingale, lutilisation dune pondration (weighted round robin) permettra dassigner le trafic aux serveurs en tenant compte de leur capacit relative.
Le principe est simple, intercaler un boitier load balancer (quilibrage de charge) ou un serveur pourvu dun logiciel entre, dune part, les consommateurs, et, dautre part, les ressources du systme. Les redirections vers les ressources les moins occupes ou les plus facilement accessibles seront assures par lquipement (voir schma ci-dessous). Selon nos recherches il existe, malgr leur cot trs lev, des solutions sadressant au middle market (PME-PMI) et bien entendu aux plus grandes structures. Nous trouverons notamment places sur le secteur des PME-PMI des solutions base de boitier Linksys ou Netgear, pour les grandes entreprises F5 (Big-Ip, Viprion), Radware (Fatpipe), Nortel (Alteon) ou Cisco (CSS-Content Services Switches) constituent le haut du pav en termes de solutions de rpartition.
4.1.3. Exemple de typologie rseau avec load balancing Schma exemple darchitecture de load balancing
INTERNET
Symbole Total 1 1 2 1 2 2
Lgende
Equipements Description Connexion Internet Routeur CISCO Pare-feu CISCO redondant Switch CISCO Catalyst Serveur Web Serveur de base de donnes
Ce schma nous prsente un type darchitecture type, il en existe dautres, de plus le nombre de serveurs Web et bases de donnes peut tre multipli, cela dpendra de lquipement charg dquilibrer les charges, du dbit assur par les liaisons filaires, des quipements rseaux et bien entendu de limportance de la structure utilisant cette technique.
On distinguera deux niveaux de tolrance de panne : 1. Le premier niveau, matriel, est celui dont la dfinition est cite : il sagit de garantir le fonctionnement du service au sens matriel du terme ; 2. Le second niveau, plus conceptuel, se base au niveau de larchitecture logique du cluster. La tolrance de panne est le procd selon lequel linformation est toujours accessible mme si une des machines la stockant est dfaillante (ou en maintenance). Cet aspect de la tolrance de panne implique notamment la copie des donnes dun serveur (nud) lautre, donc rplication en temps rel, ainsi que des stratgies de sauvegarde et de restauration (le tout entrant dans le cadre dun plan de continuit dactivit). Ce niveau de tolrance de panne fait partie de la haute disponibilit .
4.2.2. Principe de fonctionnement dans le cluster En ce qui concerne les clusters, la redondance des quipements et leurs remplacements chaud (hot swappable) constituent la principale rponse en cas de panne. Lautre lment cl qui doit se voir attribuer une tolrance aux pannes est lnergie. Des onduleurs sont alors aussi mis en place et redonds galement. Une bonne politique de tolrance de panne doit sappuyer sur les 4 principes fondamentaux suivants : 1. La fiabilit des quipements constituant le systme 2. La disponibilit des matriels 3. Leur maintenabilit 4. La scurit Bien quil existe un certains nombre dorganisations autour de la tolrance de panne nous naborderons ici que les exemples darchitecture en tandem, et la redondance des donnes.
Selon Wikipedia.fr
10
Pour tre rapide daccs et proposer ses contenus, Wikipdia est hberg sur des clusters rpartis en 3 centres : Tampa (~300 serveurs) Amsterdam (~26 serveurs) Soul (~23 serveurs) Quelques statistiques sur Wikipdia2 : 55 serveurs de cache plus 20 en standby ; ~1000 ~2500 requtes http par serveur ; 100 250 Mbits de connexion par serveur ; 14 000 32 000 connexions par serveur. Textes et images : Les textes sont compresss jusqu 100%, chaque article est sauvegard depuis sa cration Les images occupent 1.3 TB rpartis en 4 millions de fichiers Les sauvegardes durent deux semaines
4.3.2. Rpartition de charge et requte utilisateur Lutilisateur final, lorsquil recherche un article, passe implicitement par plusieurs tapes successives : 1. un rpartiteur gographique redirige sa requte sur le nom de domaine correspondant sa langue, par son adresse IP 2. le rpartiteur amne la requte un rpartiteur de charges rgional qui interroge un serveur de cache (Squid) qui divise les requtes en 2 groupes selon le type de contenu (texte ou mdia), via le protocole CARP (Cache Array Routing Protocol). Le systme actuellement utilis fonctionne en 3 couches : des machines munies de caches Squid attendent des demandes de pages, images, etc. des clients (navigateurs Web) ; ils gardent en mmoire les pages les plus rcemment accdes qui n'ont pas t modifies, et les renvoient aux clients qui les demandent, sinon ils passent la requte la couche suivante ; des machines munies de serveurs Apache prparent les pages la demande, en fonction des donnes prsentes dans la base de donnes ;
Selon Wikimdia
11
une base de donnes matre et des bases de donnes esclaves stockent les donnes. Round-robin DNS rpartit la charge sur les Squids.
12
Les serveurs de cache et les bases de donnes disposent aussi de leur propre rpartiteur de charge :
Toute larchitecture logicielle de Wikipdia repose sur du Linux, en particulier Linux Virtual Server.
13
Larchitecture de rplication au niveau de la base de donnes peut tre illustre par le schma suivant :
1. Une application a ralis une criture sur le serveur matre. Celui-ci rpertorie lcriture sur son Binlog , Binary log. 2. le thread dEntre/Sortie du Slave vient collecter le Binlog 3. le thread du Master envoie les donnes du binlog ( binlog dump ) 4. le thread dEntre/Sortie du Slave copie ces donnes sur son propre Binlog local, le Binlog Relay 5. le thread SQL du Slave lit le Binlog Relay et lapplique sur la base de donnes.
14
5. Clustering et logiciels
Selon les logiciels, le clustering est pris en charge diffremment. Nous dtaillerons dans ce paragraphe les deux principaux logiciels qui prennent en chargent le cluster (cration, monitoring, accs aux ressources).
5.1.2. Lquilibrage de la charge des composants CLB (Component Load Balancing) Cette technique permet de distribuer la charge de travail entre plusieurs serveurs excutant la logique mtier dun mme site. Cest un quilibrage dynamique des composants COM+ (8 nuds max).
COM+ : Component Object Model programme permettant de regrouper des services ddis aux applications distribues de Windows. Liens : http://rangiroa.essi.fr/cours/car/07-99-slides-com+.pdf (prsentation trs intressante sur COM+)
5.1.3. Service de cluster Ce type de service assure la haute disponibilit des applications, exemples : les bases de donnes, les services de messageries, de fichiers et dimpression. Lapplication ou les applications en question doivent tre pralablement installe sur plusieurs machines du cluster de sorte quaprs lidentification de lchec un autre serveur prenne le rle principal car la/les application(s) ne peut sexcuter que sur un seul des serveurs la fois. (8 nuds max)
15
16
La haute disponibilit est une notion qui peut sappliquer sur plusieurs domaines : Localement, un serveur, en assurant une tolrance de panne o Redondance des donnes o Technologie RAID o Snapshots
17
Localement un site, en assurant un quilibrage de charge entre plusieurs serveurs et la disponibilit des donnes o Grappe de serveurs en clusters, o Rplication des donnes en temps rel o Systme dquilibrage de charge o Solutions de stockage, distribution de fichiers o Multiplication des cbles de communication (et mise en place de trunk, et/ou STP)
De manire plus loigne un site, en assurant une politique de continuit daccs : o Plan de continuit dactivit o Plan de reprise dactivit o Sauvegardes : centralisation sur un site tiers, externalisation
18
ainsi que leur sauvegarde, ce qui peut impliquer lachat de licences de logiciels et demande des heures de maintenance. De plus, le clustering est gourmand en bande passante, il faut donc investir dans un rseau supportant une charge consquente.
2. le clustering demande des connaissances pousses en informatique : Mettre jour les serveurs dun cluster, configurer de nouveaux serveurs dans la ferme demande, selon les logiciels, une grande quantit de connaissances.
Disponibilit % 90% 95% 98% 99% 99.5% 99.8% 99.9% 99.95% 99.99% 99.999% 99.9999%
Indisponibilit par an 36.5 jours 18.25 jours 7.30 jours 3.65 jours 1.83 jours 17.52 heures 8.76 heures 4.38 heures 52.6 min 5.26 min 31.5 s
Indisponibilit par mois3 72 heures 36 heures 14.4 heures 7.20 heures 3.60 heures 86.23 min 43.2 min 21.56 min 4.32 min 25.9 s 2.59 s
Indisponibilit par semaine 16.8 heures 8.4 heures 3.36 heures 1.68 heures 50.4 min 20.16 min 10.1 min 5.04 min 1.01 min 6.05 s 0.605 s
Il y a donc un seuil de disponibilit, prvu dans le Service Level Agreement (SLA) qui impose un maximum de temps dindisponibilit sur une priode quantifie, en effet, des sites
3
19
comme Ebay ayant de grosses bases de donnes transactionnelles ne peuvent pas se permettre davoir une indisponibilit sous un certain seuil. Lenjeu est dans le cas prsent purement conomique, puisqu indisponibilit rime alors avec perte de chiffre daffaires .
Pour le groupe Despinasse, acteur agroalimentaire spcialis dans la viande, l'informatique se place au cur de la production et de la logistique. Elle lui permet d'une part d'assurer la traabilit de la matire premire, d'autre part un suivi des produits, de la livraison et des cots. Deux usines, l'une situe Saint-tienne, l'autre dans la Drme, tournent 24h/24 et l'informatique doit suivre- en haute disponibilit - pour pouvoir faire partir les camions de livraison l'heure. Les deux usines travaillent le jour, tandis que le chargement des camions a lieu la nuit.
Continuit d'activit lors d'un incendie En octobre 2005, le sige social de l'entreprise, qui se trouve sur l'un des sites de production, a t ravag par un incendie. Durant une quinzaine de jours, le sige social a donc t inaccessible pour les employs. Le temps de nettoyer les dgts provoqus par la fume dans les 1.000 m de bureaux... Pourtant, le groupe n'a jamais cess son activit, grce son architecture informatique et au protocole de continuit d'activit mis en place. Nos deux salles d'informatique ne sont loignes que de quelques kilomtres, et sont relies par une fibre optique propritaire 10 Gbits/s qui assure une rplication instantane des donnes, explique Goran Nedeljkovic, DSI de Despinasse.
Sinistre ou maintenance, un basculement transparent En pratique, cela permet galement de raliser des oprations de maintenance, en basculant l'activit d'une salle sur l'autre. Pour nos utilisateurs, ce basculement est
4
Daprs ZDNet
20
totalement transparent, prcise-t-il. Quant aux 180 magasins du groupe, ils sont connects au site par un VPN (Virtual Private Network), un rseau priv virtuel. Lors de l'incendie, tout le systme informatique a bascul sur les machines de la deuxime salle. Dure de l'opration: cinq minutes. Les utilisateurs, comme lors d'une maintenance, ne se sont aperus de rien. A quelques dtails prs. Le fonctionnement s'est poursuivi en mode dgrad, car les performances taient diminues puisque nous ne disposions plus que d'une seule salle. Mais l'essentiel tait prserv: nous avons pu continuer travailler, produire et vendre dans les 180 points de vente de l'poque, se souvient M. Nedeljkovic.
Un cluster de serveurs Pour la rplication des donnes, le groupe utilise une base de donnes Oracle 9i en version RAC (Real Application Cluster). Cette technologie permet de partager la mme base de donnes sur plusieurs serveurs: les donnes sont rpliques instantanment dans plusieurs salles. Despinasse a choisi de renforcer cette architecture avec un clustering (une grappe) de serveurs Windows et Unix de type HACMP (High availability cluster multiprocessing). Cette architecture a permis le basculement de toutes les applications sans perte de donnes. Un partage de charges a ensuite t appliqu aux serveurs d'applications Windows 2003.
Enfin, le groupe dispose d'une capacit de stockage de 10 disques de 36 Go et de 4 disques de 150 Go, relis un serveur de sauvegarde Veritas sous Windows quip du logiciel Netbackup. Les sauvegardes sont stockes sur bandes DLT (Digital Linear Tape). Deux sauvegardes Oracle sont ralises chaque jour sans arrt de la base. Les autres applications sont sauvegardes une fois par jour 2 heures du matin pour ne pas gner le travail des quipes de nuit, conclut M. Nedeljkovic.
21
7.3.2. Exemple 2 : Tolrance de panne : le risque zro nexiste pas5 Fvrier et Mars 2005, la socit REDBUS INTERHOUSE a subi des coupures gnrales de courant. Bas Courbevoie (92), le Datacenter de Redbus est lhbergeur des hbergeurs. Redbus, par ce biais assure la prestation dhbergement des hbergeurs (par exemple OVH, et quelques grands autres hbergeurs franais) par la location de serveurs dans un Datacenter rput pour sa fiabilit et sa haute technicit. Avec cette panne lectrique, cest entre 30% et 50% des sites franais qui ont t indisponibles pendant plusieurs heures, et ce deux dates distinctes. Plusieurs fois, lalimentation en lectricit a t interrompue : 1er incident lectrique Redbus : o 10h45->12h00: L'alimentation EDF a lch, le groupe de secours n'a pas pris le relais. 2e incident lectrique Redbus : o 14h30->16h30: Lors du branchement des batteries UPS de secours, le groupe lectrogne de secours a tout simplement cess de fonctionner 3e incident lectrique Redbus : o 17h00->18h10: Mme incident, durant la tentative de rebranchement des batteries UPS, le groupe lectrogne de secours a cess de fonctionner
Consquences des incidents : Le btiment fonctionne sur deux gnrateurs (le troisime est cass) Les onduleurs sont vides Le disjoncteur principal (EDF) est cass, rendant la bascule sur le courant EDF impossible Une bascule sur le courant EDF engendrera une nouvelle coupure La situation est extrmement instable
Cet exemple illustre bien que quel que soit le degr de scurit mis en place, quelle que soit la tolrance de panne, le risque zro nexiste pas. Lerreur tait une erreur imputable au matriel, pourtant dans un Datacenter de haute qualit.
22
7.3.3. Exemple 3 : Laroport6 Voici lhistoire dune panne applicative stant transforme en tat de crise globale. Ce fut le cas de l'histoire suivante vcue dans un aroport pourtant quip d'une solution redondante. Cette histoire va nous permettre de dgager les points fondamentaux qui font la qualit d'une solution de haute disponibilit. La crise s'est droule dans un aroport sur l'application de gestion des voyageurs. Cette application affiche les informations sur les panneaux de l'aroport permettant aux voyageurs de retrouver le lieu d'un embarquement ou l'endroit de rcupration des bagages. La base de donnes associe la gestion des voyageurs n'est pas importante en termes de volumtrie (infrieure 500 giga-octets). Cette base est par contre extrmement sensible et doit rsister au pire cas considr dans un aroport : le crash d'un avion sur une salle informatique. La solution de redondance choisie a donc t deux serveurs loigns dans deux salles informatiques distantes, chaque serveur disposant localement de la base de gestion des voyageurs. Un produit de rplication a t choisi pour assurer la redondance de la base entre le serveur principal et le serveur de secours. Pour entretenir la base avec les nouveaux vols d'une semaine, tous les dimanches, une opration de mise jour de la base est ralise avec les vols de la semaine suivante. Un dimanche, alors que l'opration de mise jour des vols a lieu sur le serveur principal, la rplication est malencontreusement arrte sur le serveur de secours. A l'issue de la mise jour, le serveur principal dispose donc des vols pour la semaine suivante, alors que le serveur de secours dispose des vols de la semaine prcdente. Le lundi, le serveur principal alimente correctement les panneaux de l'aroport indiquant aux voyageurs les bons vols et leurs horaires. Pour le service informatique, la gestion de l'aroport fonctionne parfaitement, malgr l'arrt de la rplication sur le serveur de secours qui n'a pas t dtect. En milieu de semaine, une erreur amne le serveur principal rebooter automatiquement. Malheureusement, il reste coinc dans son boot et donc ne redmarre pas l'application de gestion des voyageurs. Les panneaux dans l'aroport deviennent noirs et le service informatique est mis en alerte. Le serveur principal tant coinc dans son boot, la dcision est prise de redmarrer l'application sur le serveur de secours. Le redmarrage sur le serveur de secours est ralis sans difficult et quelques minutes plus tard, tous les panneaux de l'aroport sont de nouveau actifs. Mais ils prsentent aux voyageurs les vols de la semaine prcdente !!
6
23
L'alerte rouge au service informatique se transforme en alerte noire. L'application de gestion des voyageurs est immdiatement arrte sur le serveur de secours et la dcision est prise de rgler le problme de reboot du serveur principal. Pendant cette opration, l'application de gestion de l'aroport est indisponible pour tous les voyageurs. Les administrateurs parviennent au bout de quelques heures rgler le problme du serveur principal et le rebooter. Mais, malheureusement, dans la phase de boot, le produit de rplication sur le serveur principal est lanc automatiquement. Il dtecte que la rplication est dj active sur le serveur de secours et il resynchronise la base locale du serveur principal partir du serveur de secours. Les deux serveurs se retrouvent donc avec la base des vols de la semaine prcdente !!! L'aroport a t perturb une journe entire et seule l'opration spciale du dimanche a permis de resynchroniser correctement le serveur principal. Au bout du compte, l'aroport a abandonn le produit de rplication au profit dune solution de rplication et de haute disponibilit complte.
8. Conclusion
Les notions de rpartition de charge, de tolrance de pannes rapportes aux technologies clusters sinscrivent dans des politiques de haute disponibilit. Nous nous sommes attachs expliquer pourquoi les entreprises fournissant des services Web et les organisations ayant recours dimportantes bases de donnes ont un besoin vital de ce genre doutil. Avec la professionnalisation des applications dployes sur les rseaux et leur criticit, les besoins sont toujours plus accrus. La capacit dune infrastructure de production se voir prive dun ou plusieurs lments la constituant sans souffrir fait aujourdhui la diffrence entre une entreprise comptitive et proactive et les autres. Il faut aussi quelles soient capables aisment de faire face aux demandes croissantes de ressources lies laugmentation soutenue du trafic tout en respectant le principe dextensibilit (scalability). Il est important de rflchir au plus tt, parfois mme ds llaboration dun projet conomique, une politique de haute disponibilit adapte celuici et sa mise en uvre.
24