DRBD


Qu'est ce que le DRBD?

DRDB se réfère aux blocks des dispositifs conçus en un seul bloc hautement disponible, c'est le cluster HA. Cela est rendu possible grâce au "mirroring" du bloc entier du dispositif via un réseau dédié. Le DRBD peut être considéré comme un réseau en raid-1 Dans l'image ci contre, les deux boites oranges representent les deux serveurs qui forment a cluster HA. Les boites contiennent les éléments habituels d'un kernel Linux: fichier système, cache tampon, gestion des disques, drivers des disques, TCP/IP stack et driver de carte d'interface réseau (NIC). La fleche noire illustre le flow de données entre tous ces éléments La flèche orange montre le flow de données, alors que le DRBD met en miroir les données des services disponibles depuis le noeuf actif du cluster HA vers le noeuf inactif du même cluster HA.

Qu'est-ce-que HA ?

La partie haute de cette image montre un cluster où le noeud gauche est actuellement actif, c'est à dire que l'adresse IP du service du client communique actuellement avec le noeud gauche. Le service, et son adresse IP, peut être migré sur un autre noeud à tout moment, soit en cas de défaillance du noeud actif, soit à la suite d'une demande de l'administrateur.

Qu'est-ce-que DRBD?

"Mirroring" des données importantes

DRDB fonctionne à la base des blocks, c'est à dire sur les partitions du disque dur ou sur le gestionnaire de volumes logiques. Cela permet de créer un miroir de chaque block de données écrit sur le disque, sur le noeud d'échange.

De complétement synchrone

Le "Mirroring" peut être synchrone. Cela signifie que le système de fichiers sur le nœud actif est averti que l'écriture du bloc a été terminée seulement lorsque le block est terminé sur les deux disques du cluster. La mise en mirroir synchrone (également appelé protocol C en DRBD) constitue un bon choix pour les clusters HA où vous ne pouvez pas vous permettre de perdre une seule transaction au cas où un crash surviendrait dans le noeuf actif (primaire, en langage DRBD).

A Asynchrone

L'autre solution est la mise en mirroir asynchrone. Cela veut dire que l'entité qui émet le demande d'écriture est informé de sa réalisation dès que les données sont écrites sur le disque local. La mise en miroir asynchrone est nécessaire afin de construire des miroirs sur de longues distances. En d'autres termes, le temps d'aller-retour du réseau d'interconnexion est supérieure à la latence d'écriture que vous pouvez accepter pour votre application. (Remarque: La quantité de données que le noeud peut échanger est limité par le délai de la bande passante et la mémoire tampon TCP.)

Pack Hébergement SEO