Julie est réveillée à 4 h 30 par son téléphone portable. Elle reçoit texto sur texto au rythme d’un par minute. Finalement, Éric appelle. Il est furieux et Julie a du mal à comprendre ce qu’il dit. En fait, Julie a du mal à comprendre pourquoi Éric voudrait l’appeler en pleine nuit. Puis elle se souvient. Éric est le propriétaire d’un site de commerce en ligne. Il vend des vêtements de sport et est hébergé sur un de ses serveurs. Il est furieux, car le serveur s’est arrêté et ses clients néo-zélandais sont en colère, car ils ne peuvent pas accéder au site web.
Voilà un scénario typique, et vous en avez sans doute déjà rencontré des variations, en étant soit dans le rôle de Julie soit dans celui d’Éric, ou les deux. Dans le premier cas, vous voulez passer des nuits tranquilles ; dans le second, vous voulez permettre à vos clients de passer commande quand ils le désirent.
Les problèmes persistent : les ordinateurs faillissent, et ce d’innombrables façons. Il y a les problèmes matériels, les pertes de courant, les bogues dans les systèmes d’exploitation ou dans les applications, etc. Seul CouchDB n’a pas de bogues. (Oui, enfin, bien sûr, c’est faux : tous les logiciels ont des bogues, sauf peut-être les choses écrites par Daniel J. Bernstein et Donald Knuth.)
Quelle qu’en soit la cause, vous voulez vous assurer que le service que vous fournissez (dans le cas de Julie et Éric, c’est la base de données d’un site de commerce en ligne) résiste aux pannes. Le chemin vers la résistance aux pannes est un chemin qui consiste à localiser les points uniques de défaillance et les ôter. L’alimentation d’un serveur peut défaillir. Pour éviter que la machine s’éteigne, la plupart sont livrés avec deux alimentations. En poussant ce raisonnement, vous pourriez avoir un serveur où tout est doublé (voire triplé, ou plus encore), mais ce serait là une pièce très spécialisée et par conséquent cher. Il est beaucoup plus économique de posséder deux serveurs similaires dans une configuration où l’un peut prendre le relais de l’autre. Toutefois, cela exige qu’ils détiennent les mêmes données pour pouvoir basculer de l’un à l’autre sans que l’utilisateur s’en rende compte.
S’affranchir de tous les points individuels de défaillance vous permettra d’obtenir un système à haute disponibilité ou résistant aux défaillances. Le niveau de résistance n’est restreint que par votre budget. Si vous ne pouvez pas vous permettre de perde le panier d’un client, quelle que soit la circonstance, vous devez au minimum disposer de deux serveurs hébergés dans des endroits différents, si possible loin l’un de l’autre.
C’est ce que fait Amazon pour le site web Amazon.com. Si un centre de données est touché par un tremblement de terre, l’utilisateur sera toujours capable de passer commande.
Il est toutefois raisonnable de penser que les problèmes d’Amazon ne sont pas les vôtres et que vous aurez bien des problèmes quand votre centre de données s’effondrera. Mais vous désirez quand même survivre à la perte d’un serveur.
Avant de rentrer dans les détails quant à la mise en place d’un système CouchDB à haute disponibilité, examinons une autre situation. Éric appelle Julie durant les heures d’ouverture et lui fait part de la colère de ses clients, car ceux-ci trouvent que le site web est trop lent à s’afficher. Julie jette un œil aux serveurs et constate que c’est un heureux problème. Éric en reste coi, et Julie lui explique que son commerce attire soudainement un grand nombre de clients désireux d’acheter ses produits. Éric y ajoute son grain de sel : « j’ai eu une excellente note sur ce blogue et ils doivent venir de là. » Une vérification rapide des référents indique en effet que la majorité des clients proviennent d’un seul site. Les commentaires de l’article du blogue contiennent déjà des avis négatifs de clients trouvant le site trop lent. Éric veut contenter ses clients et demande conseil à Julie qui l’invite à installer un autre serveur. Celui-ci pourrait absorber la moitié de la charge et résorber le problème de lenteur. Éric donne son accord et Julie installe la nouvelle machine.
La solution à ce problème ressemble beaucoup au précédent visant à obtenir un système résistant aux pannes : il faut installer un second serveur et synchroniser les données. La différence tient au fait que, dans le cadre de la résistance aux pannes, le deuxième serveur attend que le premier s’effondre, tandis que dans le deuxième cas, le serveur absorbe la moitié de la charge. Ce dernier cas n’est pas résistant aux pannes : si un serveur s’arrête, l’autre subira toute la charge et il est probable qu’il s’effondre à son tour, ou du moins qu’il réponde lentement aux requêtes. Ces deux éventualités sont inacceptables.
Gardez à l’esprit que si les deux solutions se ressemblent, il ne faut pas confondre haute disponibilité et résistance aux pannes. Nous reviendrons plus tard sur le deuxième scénario. Pour l’instant, penchons-nous sur la mise en œuvre d’un système CouchDB résistant aux pannes.
Nous avons déjà apporté la réponse dans les chapitres précédents : la solution pour synchroniser les serveurs est de les répliquer.