Turb(l)o(g)

Plus le temps passe et plus j’épuise les sujets à traiter. A l’aide ! HELP ! SOS !! vos idées sont les bienvenues. Bon, j’avoue, je suis aussi tombé dans une série chronophage comportant une centaine de DVD de 2h30 chacun, ça aide pas.

Crédit photo : Will Pate

Je vais reprendre un sujet que j’ai brièvement abordé un peu partout sur ce blog : la redondance, ou l’art de faire que les choses marchent même quand c’est cassé.

Il est important de comprendre qu’on doit l’appréhender de manière globale, un peu comme la sécurité. Avoir deux liens réseaux sur une seule machine n’a aucun intérêt s’ils sont tous deux branchés au même switch. En matière d’internet, on peut vouloir redonder beaucoup de choses, mais l’exemple d’un site web est le plus parlant ou, en tout cas, celui qui rassemble le plus grand nombre de points auxquels il faut faire attention. Nous allons commencer par le bas de la chaîne :

Redonder le réseau

C’est ce qui vient du plus loin, et c’est le plus facile a redonder. Enfin, facile … Si on a les équipements qui vont bien. Le maître mot de la redondance réseau, c’est la multiplicité des fournisseurs.

Une première base de redondance peut être mise en place avec un seul fournisseur. Ca permet de se protéger contre les pannes matérielles puisqu’on se connecte a son fournisseur avec deux connexions distinctes. Il faut bien faire attention à ce que les câbles utilisés empruntent des chemins physiques strictement différents et que les équipements passifs et actifs du fournisseur soient bien distincts. On ne sera par contre pas protégé, dans ce cas, des bourdes humaines qui peuvent, malgré tout l’empilement matériel possible, interrompre simultanément les deux circuits établis.

Pour éviter autant que faire se peut les erreurs humaines du fournisseur, il en faut un second et on saute tout de suite une étape décisive en matière de réseau en passant du coté obscur de la force avec notre ami BGP qui est, à l’heure actuelle, le seul protocole réellement utilisable pour se connecter à plus d’un opérateur à la fois en assurant une redondance à peu près automatique.

Ce n’est pas qu’un saut technologique majeur où il faut investir dans du matériel et acquérir des compétences. Il s’agit aussi d’une implication humaine et administrative dans le bon fonctionnement de l’ensemble du réseau mondial. On ne doit définitivement pas faire un réseau BGP de la même façon qu’on installe un switch avec deux câbles d’arrivée.

Le fait d’obtenir son indépendance technique et administrative vis à vis de ses fournisseurs ne vous assure toutefois pas un fonctionnement continu et dépourvu de coupures. D’une part parce que vous serez probablement vous-même victime d’erreurs humaines en interne, mais aussi sûrement à cause des divers problèmes de congestion ou de blackhole (volontaires ou pas) que BGP peut rencontrer tout en continuant de prétendre que tout va bien.

Redonder l’alimentation électrique

C’est rarement le métier de l’hébergeur ou du fournisseur d’accès. Pour redonder l’électricité, il faut, en premier lieu, deux circuits électriques distincts. Comme notre beau pays n’a qu’un seul réseau électrique, il convient de choisir soigneusement son emplacement géographique pour faire en sorte d’être au plus proche de deux sources d’énergies différentes (deux centrales EDF, en gros).

De la même façon que le réseau, s’il était possible de s’adresser à deux fournisseurs ayant deux réseaux physiques distincts, ce serait mieux, mais ce n’est pas le cas en France. Par contre, contrairement au transit vers Internet, il est facile de créer ou de stocker l’électricité.

Les plus petites structures choisiront sûrement le stockage temporaire d’énergie dans les batteries d’un ou plusieurs onduleurs ou dans des volants d’inertie (en résumé, c’est une grosse roue qui tourne en consommant un peu de courant pour maintenir sa rotation. Lorsque le courant est coupé, l’inertie de la roue fait qu’elle continue à tourner et restitue l’énergie de la même façon qu’une dynamo).

Les plus gros consommateur se tourneront vers les générateurs au gaz ou au fioul. L’ennui de ces appareils, c’est qu’ils sont incapables de démarrer assez rapidement pour prendre en charge l’alimentation des équipements. Il faut donc, en plus, prévoir un stockage temporaire d’énergie (avec les mêmes composantes qu’au paragraphe précédent) qui permettra de continuer à alimenter les équipements le temps que le générateur démarre et fournisse sa pleine puissance.

Ils seront également utiles par la suite, le courant produit par un générateur mécanique ayant une tension fluctuante, les onduleurs permettant de le stabiliser avant de le fournir aux serveurs.

Redonder le matériel

Pendant longtemps, la mode a penché vers la redondance matérielle à toute épreuve. On rencontre à présent souvent des ordinateurs avec des disques dur fonctionnant en RAID, autorisant ainsi la panne d’un ou plusieurs disques sans pour autant perdre les données ou devoir interrompre le fonctionnement de la machine pour réparer.

On en voit moins chez monsieur tout le monde, mais la plus part des serveurs possèdent deux alimentations. Dans l’idéal, elles sont chacune connectées à des lignes de production d’énergie distinctes (voir chapitre ci dessus).

Mais il existe aussi des serveurs qui embarquent des cartes réseaux doublées ou quadruplées, de la mémoire en réserve qui s’active automatiquement si un problème est détecté sur une barrette en fonctionnement et même, parfois, des processeurs redondants.

Ces prouesses techniques coûtent très cher pour un résultat finalement peu convainquant. De nos jours, on préfère redonder la partie logicielle en se reposant sur du matériel peu coûteux et pas fiable du tout mais en plus grand nombre. Vulgairement, au lieu de mettre une machine avec deux alimentations, deux disques durs et deux cartes réseau, on va mettre deux machines avec chacune une alimentation, un disque dur et une carte réseau.

Il est possible, avec ce genre de pratique, si on choisit bien son matériel, d’avoir, pour un coût d’acquisition identique, trois machines au lieu d’une avec, au global, plus de capacité et de puissance.

Autre avantage qui en découle, avec deux (ou plus) serveurs au lieu d’un, vous pouvez les séparer géographiquement (un à Paris et un à Tokyo par exemple) vous permettant, ainsi, de vous prémunir (ou pas) d’un conflit nucléaire local.

Redonder le logiciel

C’est le plus complexe parce qu’il faut généralement que les logiciels soient prévus spécifiquement pour pouvoir être redondants.

Quelques exemples parmi d’autres :

Redonder un serveur web :

Si votre site n’est constitué que de fichiers HTML et d’image, c’est presque facile. Il vous suffit d’avoir deux machines contenant chacune une copie à l’identique du site et de les faire se surveiller mutuellement. Si B détecte que A n’est pas très en forme (ou carrément aux abonnés absents), elle prend l’adresse IP sur lesquels les sites sont pointés et personne (ou presque) n’aura rien vu.

Redonder un serveur de bases de données :

Là, c’est un peu plus compliqué. Si votre site fait appel (par exemple) à une base MySQL, il faudra recommencer l’opération ci dessus mais en configurant les bases de données pour se synchroniser en permanence, généralement selon un mode maître/esclave. L’ennui, c’est que l’esclave ne sait généralement pas se comporter comme un maître tout seul comme un grand. Il ne pourra donc, par exemple, pas accepter les écritures.

Si votre site web ne fait que lire dans la base de données, pas de problème. C’est rarement le cas. Un contournement est possible en faisant en sorte que le serveur esclave soit vu comme un maître par l’autre et inversement. L’ennui de ce principe, c’est que si les deux maîtres enregistrent une écriture dans la base de données au même moment, il y aura collision, chaque ligne dans une base de donnée étant généralement commencée par un identifiant de ligne qui se doit d’être unique.

Là encore, une solution existe. Lorsqu’on a 2 bases de données, les identifiants écrits via le premier serveur doivent systématiquement être pairs, ceux du 2ème serveur seront systématiquement impaires.

On peut aussi faire appel à des solutions propriétaires et/ou commerciales (Oracle, MySQL Cluster, ..) mais c’est un peu moins Do It Yourself, pas vrai ?

Redonder un serveur de mail :

La, c’est carrément le cauchemar. Vous pouvez bien sur prévoir un second serveur disposant d’une configuration strictement identique au premier avec, par exemple, les informations sur vos utilisateurs stockées dans une base de donnée dupliquée en temps réel (voir ci-dessus) et une synchronisation périodique du contenu des boites (une fois par heure, par exemple).

Si votre serveur principal se casse la gueule, le second recevra le flux de nouveaux mails et les mettra en boîte. Avec un peu de malchance, vous aurez perdu au maximum une heure d’emails.

Si la panne était due, par exemple, à une coupure inopportune du réseau, les mails en question sont tout de même stocké sur le serveur principal qui, au bout d’un moment, redevient accessible. C’est bien joli, mais comment allez-vous synchroniser le contenu des deux serveurs puisqu’ils contiennent tous les deux certains emails que l’autre n’a pas en stock ?

Si vous avez de la chance, le logiciel utilisé stocke un seul email par fichier et vous pouvez lancer une synchronisation simple des deux machines. Si vous utilisez POP3 pour relever vos mails vous vous exposez probablement à des doublons, ce qui n’a jamais tué personne. Si vous utilisez IMAP, par contre, vous perdrez probablement les flags d’une partie ou de la totalité de vos mails (ce sont les indicateurs « lu », « répondu », etc.).

Si le logiciel utilisé stocke tous les mails d’une même boîte dans un seul fichier, vous pourrez peut-être créer une moulinette qui va mélanger vos fichiers tout en éliminant les doublons, mais c’est loin d’être propre.

Des solutions propriétaires existent pour palier à ce genre de problèmes, mais on n’aime pas ça, hein, les solutions propriétaires ?

Il manque sans doute quelques points à tout ça. Commentaires bienvenus ! :)