Stockage en cluster pour de petits web-clusters basé sur drbd+ocfs2

De quoi nous allons parler :
Comment déployer rapidement un stockage partagé pour deux serveurs basé sur des solutions drbd+ocfs2.

Pour qui cela sera utile :
Ce tutoriel sera utile aux administrateurs système et à tous ceux qui choisissent un moyen de réaliser un stockage ou souhaitent essayer une solution.

Des solutions dont nous nous sommes éloignés et pourquoi

Nous faisons souvent face à la situation où nous devons mettre en œuvre un stockage partagé sur un petit cluster web avec de bonnes performances en lecture et en écriture. Nous avons essayé différentes options de mise en œuvre du stockage partagé pour nos projets, mais peu d'entre elles ont pu nous satisfaire sur plusieurs critères. Nous allons maintenant vous expliquer pourquoi.

• Glusterfs ne nous a pas convaincus par ses performances en lecture et en écriture, des problèmes se posaient lors de la lecture simultanée d'un grand nombre de fichiers, avec une forte charge sur le CPU. Le problème de lecture des fichiers pouvait être résolu en les récupérant directement dans les bricks, mais ce n'est pas toujours applicable et généralement incorrect.

• Ceph ne nous a pas plu en raison de sa complexité excessive, qui peut être nuisible sur des projets de 2 à 4 serveurs serveurs très chargés, en particulier si le projet est ensuite maintenu. De plus, il existe des limitations sérieuses en matière de performances, obligeant à construire des clusters de stockage séparés, tout comme avec glusterfs.

• L'utilisation d'un serveur NFS pour réaliser un stockage partagé suscite des questions en termes de tolérance aux pannes.

• s3 — une excellente solution populaire pour certaines tâches, mais ce n'est pas un système de fichiers, ce qui limite son domaine d'application.

• lsyncd. Si nous avons déjà commencé à parler de « systèmes non-fichiers », il convient également de passer en revue cette solution populaire. Non seulement elle n'est pas adaptée à l'échange bidirectionnel (mais si vous tenez vraiment, c'est possible), mais en plus, elle ne fonctionne pas de manière stable avec un grand nombre de fichiers. Un complément agréable est qu'elle est monothread. La raison en est l'architecture du programme : elle utilise inotify pour surveiller les objets de travail, qu'elle accole lors du démarrage et lors du rescannage. Pour le transfert, rsync est utilisé.

Tutoriel : Comment déployer un stockage partagé basé sur drbd+ocfs2

L'une des solutions les plus adaptées pour nous a été la combinaison ocfs2+drbd. Nous allons maintenant vous expliquer comment mettre en place rapidement un stockage partagé pour deux. serveurs sur des solutions de base de données. Mais d'abord, un peu sur les composants :

DRBD — un système de stockage fourni par défaut avec Linux, qui permet de répliquer des données entre des serveurs par blocs. Son utilisation principale consiste à construire des systèmes de stockage tolérants aux pannes.

OCFS2 — un système de fichiers qui permet l'accès partagé au même stockage par plusieurs systèmes. Il fait partie de la distribution Linux et se compose d'un module de noyau et d'outils en espace utilisateur pour travailler avec le système de fichiers. OCFS2 peut être utilisé non seulement au-dessus de DRBD, mais aussi au-dessus d'iSCSI avec plusieurs connexions. Dans notre exemple, nous utilisons DRBD.

Toutes les actions sont réalisées sur un serveur Ubuntu 18.04 avec une configuration minimale.

Étape 1. Configuration de DRBD :

Dans le fichier /etc/drbd.d/drbd0.res, nous décrivons notre dispositif de bloc virtuel /dev/drbd0 :

resource drbd0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }
    on drbd1 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.192:7789;
}
    on drbd2 {
        meta-disk internal;
        device /dev/drbd0;
        disk /dev/vdb1;
        address 10.10.10.193:7789;
}
}

meta-disk internal — utiliser les mêmes dispositifs de bloc pour stocker les métadonnées
device /dev/drbd0 — utiliser /dev/drbd0 comme chemin vers drbd.
disk /dev/vdb1 — utiliser /dev/vdb1
syncer { rate 1000M; } — utiliser la bande passante gigabit de la liaison
allow-two-primaries — une option importante, permettant d'accepter les modifications sur deux serveurs principaux
after-sb-0pri, after-sb-1pri, after-sb-2pri — des options qui déterminent les actions du nœud lors de la détection d'un split-brain. Vous pouvez en savoir plus dans la documentation.
become-primary-on both — définit les deux nœuds comme principaux.

Dans notre cas, nous avons deux machines virtuelles absolument identiques, avec un réseau virtuel dédié ayant une bande passante de 10 gigabits.

Dans notre exemple, les noms des deux nœuds du cluster sont drbd1 et drbd2. Pour un fonctionnement correct, il est nécessaire de faire correspondre les noms et les adresses IP des nœuds dans /etc/hosts.

10.10.10.192 drbd1
10.10.10.193 drbd2

Étape 2. Configuration des nœuds :

Sur les deux serveurs, exécutez :

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Nous obtenons ce qui suit :

Nous pouvons lancer la synchronisation. Sur le premier nœud, vous devez exécuter :

drbdadm primary --force drbd0

Vérifions le statut :

cat /proc/drbd

Parfait, la synchronisation a commencé. Nous attendons son achèvement et constatons ce résultat :

Étape 3. Lancement de la synchronisation sur le deuxième nœud :

drbdadm primary --force drbd0

Nous obtenons ce qui suit :

Nous pouvons désormais écrire dans drbd depuis les deux serveurs.

Étape 4. Installation et configuration d'ocfs2.

Nous allons utiliser une configuration assez triviale :

cluster:
     node_count = 2
     name = ocfs2cluster

node:
     number = 1
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.192
     name = drbd1

node:
     number = 2
     cluster = ocfs2cluster
     ip_port = 7777
     ip_address = 10.10.10.193
     name = drbd2

Il faut l'enregistrer dans /etc/ocfs2/cluster.conf les deux nœuds.

Créons un FS sur drbd0 sur n'importe quel nœud :

mkfs.ocfs2 -L "testVol" /dev/drbd0

Ici, nous avons créé un FS avec l'étiquette testVol sur drbd0 en utilisant les paramètres par défaut.

Dans /etc/default/o2cb, il est nécessaire de définir (comme dans notre fichier de configuration)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

et d'exécuter sur chaque nœud :

o2cb register-cluster ocfs2cluster

Ensuite, nous activons et ajoutons au démarrage automatique tous les unités nécessaires :

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Une partie de cela sera déjà lancée lors du processus de configuration.

Étape 5. Ajout des points de montage dans fstab sur les deux nœuds :

/dev/drbd0 /media/shared ocfs2 defaults,noauto,heartbeat=local 0 0

Répertoire /media/shared celui-ci doit être créé à l'avance.

Ici, nous utilisons l'option noauto, ce qui signifie que le FS ne sera pas monté au démarrage (je préfère monter les FS réseaux via systemd) et heartbeat=local, ce qui signifie l'utilisation du service heartbeat sur chaque nœud. Il existe également un heartbeat global, plus adapté aux grands clusters.

Ensuite, nous pouvons monter /media/shared et vérifier la synchronisation du contenu.

C'est fait ! En conséquence, nous obtenons un stockage plus ou moins tolérant aux pannes avec la possibilité de mise à l'échelle et des performances décentes.

Source : habr.com