Si l’architecture centralisée est pratique dans son utilisation, son principal défaut est quel devient le point de défaillance potentiel de la production. Il est asses facile de mettre en place un système de reprise pour le stockage mais qu’en est il du serveur ?
Pour disposer d’un mécanisme de reprise de base de données, il suffit de mettre en place une copie des données. Cela peut se faire de différents manières :
- interne au produit avec une double écriture ou une synchronisation par le serveur
- externe, par une réplication de la base de données (MSSQL, réplication Sybase).
- éventuellement par copie de fichier, mais dans ce cas on perd les informations entre la reprise et la dernière copie.
Toutes ces solutions utilisent en fait un même principe : une synchronisation des données qui seront accessibles à tout moment.
Pour la partie serveur, la problématique est très différentes car il ne faut justement pas que les deux serveurs soit en ligne en même temps. Mettre en ligne deux serveurs sur un réseau n’est donc pas suffisant car il ne faut absolument pas que ces serveurs traitent les événèments en même temps.
Ces serveurs doivent donc communiquer pour que chacun d’eux connaissent l’état de l’autre. Si un serveur tombe, la communication est coupée et l’autre devrait assurer la reprise.
Mais comment distinguer un probleme logiciel, matériel ou réseau ?
Si le serveur de secours reprend la main alors qu’il ne s’agit que d’un problème réseau, par exemple un simple cable débranché, les deux serveurs traiteront les mêmes données dont la conséquence sera des lancements doubles.
Lorsque ce type de solution est mise en place, le risque de lancement double n’est pas nul et aucun éditeur ne garantit que cela ne peut arriver.
Le problème du lancement double est pourtant à éviter absolument à moins de mettre en place des procédures de retours arrières sur chacun de ses traitements.
Autosys propose une solution basée sur une troisième machine (d’ailleurs justement appelée third machine) qui joue le role d’arbitre en cas de coupure de communication. En effet, si le serveur de secours ne contacte plus le serveur principal, il tente de joindre la troisième machine pour identifier si le problème est un problème réseau. Ce mécanisme évolué ne fait que décaler les problème :
Si le cable réseau de la machine principale est coupée, il est toujours impossible de distinguer les différents problèmes : même problème sur deux sous-réseaux en cs de défaillances du routeur. Ou mettre la troisième machine ? avant ou après le routeur (dans ce cas, la bascule oblige à passer la troisième machine sur l’autres sous-réseau). : si la troisième machine n’est plus accessible, les serveurs s’arretent car le mécanisme n’est plus fiable
Donc, on peut mettre en place le mécanisme de reprise mais sans aucune garantie et avec de sérieux risque de double lancements.
