Sinon je teste pas non plus mes sauvegardes, je vous rassure :)
Je suis rassuré :)
Plus sérieusement, la redondance est effectivement capable de faire pire que mieux (si j'ose dire). Un exemple que j'ai vu récemment : du Proxmox en haute disponibilité. Soit trois serveurs physiques qui contiennent (mettons) 30 machines virtuelles équivalentes, réparties à parts égales (10 par serveur, pour ceux qui ont fait des maths au lycée). Tous ont la haute dispo activée, c'est à dire que si n'importe lequel des trois serveurs se vautre, les 30 machines continueront à tourner sur les deux restants. Et ça, c'est chouette.
Là où c'est moins chouette, c'est quand tu n'as pas pensé (ou oublié, ou que ça n'a pas marché, ou que ça a arrêté de marcher sans prévenir) à monitorer l'état de ton cluster. Quand une VM tombe, tu le sais (les utilisateurs étant le meilleur système de monitoring jamais inventé), mais quand un nœud tombe pas forcément, du coup.
Et là, donc (suspense!) un nœud tombe. La HA prend le relais, et on se retrouve avec deux nœuds de 15 machines (sans calculatrice, promis) qui ne sont plus en haute dispo. Le cluster est dégradé. Et si on reperd un nœud, ce ne sont pas 10 VMs qu'on perd, mais 15.
Moralité n°1, ne pas faire d'alerting, c'est mal.
Moralité n°2, sauf à vraiment avoir besoin que les services ne coupent pas (du tout), on est souvent mieux à s'éviter la HA : c'est plus simple à gérer, la récupération est certes manuelle mais dès l'apparition du problème, et on réduit d'autant la taille de l'impact.
[^] # Re: Illustration
Posté par Larry Cow . En réponse au journal De l'importance (des tests réguliers) des sauvegardes. Évalué à 10.
Je suis rassuré :)
Plus sérieusement, la redondance est effectivement capable de faire pire que mieux (si j'ose dire). Un exemple que j'ai vu récemment : du Proxmox en haute disponibilité. Soit trois serveurs physiques qui contiennent (mettons) 30 machines virtuelles équivalentes, réparties à parts égales (10 par serveur, pour ceux qui ont fait des maths au lycée). Tous ont la haute dispo activée, c'est à dire que si n'importe lequel des trois serveurs se vautre, les 30 machines continueront à tourner sur les deux restants. Et ça, c'est chouette.
Là où c'est moins chouette, c'est quand tu n'as pas pensé (ou oublié, ou que ça n'a pas marché, ou que ça a arrêté de marcher sans prévenir) à monitorer l'état de ton cluster. Quand une VM tombe, tu le sais (les utilisateurs étant le meilleur système de monitoring jamais inventé), mais quand un nœud tombe pas forcément, du coup.
Et là, donc (suspense!) un nœud tombe. La HA prend le relais, et on se retrouve avec deux nœuds de 15 machines (sans calculatrice, promis) qui ne sont plus en haute dispo. Le cluster est dégradé. Et si on reperd un nœud, ce ne sont pas 10 VMs qu'on perd, mais 15.
Moralité n°1, ne pas faire d'alerting, c'est mal.
Moralité n°2, sauf à vraiment avoir besoin que les services ne coupent pas (du tout), on est souvent mieux à s'éviter la HA : c'est plus simple à gérer, la récupération est certes manuelle mais dès l'apparition du problème, et on réduit d'autant la taille de l'impact.