Article de reference

Cerveau divisé (informatique)

( Learn how and when to remove this message ) Le terme « split-brain » est un terme informatique basé sur une analogie avec le syndrome médical du split-brain . Il indique des i...

(Learn how and when to remove this message)

Le terme « split-brain » est un terme informatique basé sur une analogie avec le syndrome médical du split-brain . Il indique des incohérences de données ou de disponibilité provenant de la maintenance de deux ensembles de données distincts dont la portée se chevauche, soit en raison de serveurs dans une conception de réseau , soit d'une condition de défaillance basée sur des serveurs qui ne communiquent pas et ne synchronisent pas leurs données entre eux. Ce dernier cas est également communément appelé partition de réseau .

Bien que le terme split-brain fasse généralement référence à un état d'erreur, le DNS split-brain (ou DNS split-horizon ) est parfois utilisé pour décrire une situation délibérée dans laquelle les services DNS internes et externes d'un réseau d'entreprise ne communiquent pas, de sorte que des espaces de noms DNS distincts doivent être administrés pour les ordinateurs externes et pour les ordinateurs internes. Cela nécessite une double administration et, s'il y a un chevauchement de domaine dans les noms d'ordinateur, il existe un risque que le même nom de domaine complet (FQDN) apparaisse de manière ambiguë dans les deux espaces de noms faisant référence à des adresses IP d'ordinateur différentes.

Les clusters à haute disponibilité utilisent généralement une connexion réseau privée de type heartbeat qui permet de surveiller l'état et la santé de chaque nœud du cluster. Par exemple, le syndrome du split-brain peut se produire lorsque toutes les liaisons privées tombent en panne simultanément, mais que les nœuds du cluster continuent de fonctionner, chacun pensant être le seul à fonctionner. Les ensembles de données de chaque cluster peuvent alors servir les clients de manière aléatoire par leurs propres mises à jour d'ensemble de données « idiosyncratiques », sans aucune coordination avec les autres ensembles de données. Cela peut entraîner une corruption des données ou d'autres incohérences de données qui peuvent nécessiter l'intervention et le nettoyage de l'opérateur.

Approches pour faire face au split-brain

Davidson et al., après avoir examiné plusieurs approches pour traiter le problème, les classent comme optimistes ou pessimistes.

Les approches optimistes laissent simplement les nœuds partitionnés fonctionner comme d'habitude ; cela offre un niveau de disponibilité plus élevé, au prix d'un sacrifice de l'exactitude. Une fois le problème résolu, une réconciliation automatique ou manuelle peut être nécessaire pour que le cluster soit dans un état cohérent. Une implémentation actuelle de cette approche est Hazelcast , qui effectue une réconciliation automatique de son magasin de clés-valeurs.

Les approches pessimistes sacrifient la disponibilité en échange de la cohérence. Une fois qu'un partitionnement du réseau a été détecté, l'accès aux sous-partitions est limité afin de garantir la cohérence. Une approche typique, telle que décrite par Coulouris et al., consiste à utiliser une approche quorum -consensus. Cela permet à la sous-partition avec la majorité des votes de rester disponible, tandis que les sous-partitions restantes devraient tomber dans un mode de clôture automatique . Une implémentation actuelle de cette approche est celle utilisée par les jeux de réplicas MongoDB . Et une autre implémentation de ce type est la réplication Galera pour MariaDB et MySQL .

Les clusters HA commerciaux modernes à usage général utilisent généralement une combinaison de connexions réseau de pulsation entre les hôtes du cluster et de stockage témoin de quorum . Le défi avec les clusters à deux nœuds est que l'ajout d'un périphérique témoin augmente les coûts et la complexité (même s'il est implémenté dans le cloud), mais sans cela, si la pulsation échoue, les membres du cluster ne peuvent pas déterminer lequel doit être actif. Dans de tels clusters (sans quorum), si un membre échoue, même si les membres attribuent normalement des statuts primaire et secondaire aux hôtes, il existe au moins 50 % de probabilité qu'un cluster HA à 2 nœuds échoue totalement jusqu'à ce qu'une intervention humaine soit fournie, pour éviter que plusieurs membres deviennent actifs indépendamment et soient directement en conflit ou corrompent les données.

Original text
Rate this translation
Your feedback will be used to help improve Google Translate