Stockage en cluster pour les petits clusters Web basés sur drbd+ocfs2

De quoi nous parlerons :
Comment déployer rapidement un stockage partagé pour deux serveurs basés sur les solutions drbd+ocfs2.

A qui il sera utile :
Le didacticiel sera utile aux administrateurs système et à toute personne choisissant une méthode de mise en œuvre du stockage ou souhaitant essayer la solution.

Quelles décisions avons-nous refusées et pourquoi ?

Nous sommes souvent confrontés à une situation dans laquelle nous devons implémenter un stockage partagé avec de bonnes performances de lecture-écriture sur un petit cluster Web. Nous avons essayé différentes options pour mettre en œuvre un stockage partagé pour nos projets, mais peu ont pu nous satisfaire sur plusieurs indicateurs à la fois. Maintenant, nous allons vous dire pourquoi.

• Glusterfs ne nous satisfaisait pas en termes de performances de lecture et d'écriture, il y avait des problèmes avec la lecture simultanée d'un grand nombre de fichiers et la charge du processeur était élevée. Le problème de lecture des fichiers pourrait être résolu en y accédant directement depuis Brick, mais cela n'est pas toujours applicable et est généralement incorrect.

• Ceph n'a pas aimé la complexité excessive, qui peut être préjudiciable sur des projets comportant 2 à 4 serveurs, surtout si le projet est maintenu par la suite. Encore une fois, il existe de sérieuses limitations de performances qui nous obligent à créer des clusters de stockage séparés, comme avec glusterfs.

• Utiliser un seul serveur NFS pour mettre en œuvre un stockage partagé soulève des questions en termes de tolérance aux pannes.

• s3 est une excellente solution populaire pour un certain nombre de tâches, mais ce n'est pas un système de fichiers, ce qui en restreint la portée.

• lsyncd. Si nous avons déjà commencé à parler de « systèmes sans fichiers », cela vaut la peine d'examiner cette solution populaire. Non seulement il ne convient pas à l'échange bidirectionnel (mais si vous le souhaitez vraiment, vous le pouvez), mais il ne fonctionne pas non plus de manière stable sur un grand nombre de fichiers. Un ajout intéressant à l'ensemble est qu'il est monothread. La raison réside dans l'architecture du programme : il utilise inotify pour surveiller les objets de travail, qu'il attribue au démarrage et lors de la nouvelle analyse. rsync est utilisé comme support de transfert.

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

L'une des solutions les plus pratiques pour nous était le lien ocfs2+drbd. Nous allons maintenant vous expliquer comment déployer rapidement un stockage partagé pour deux serveurs basés sur une base de données de solution. Mais d’abord, un peu sur les composants :

DRBD - un système de stockage de la distribution Linux standard qui permet de répliquer les données entre serveurs par blocs. L'application principale consiste à créer un stockage tolérant aux pannes.

OCFS2 - un système de fichiers qui permet une utilisation partagée du même stockage par plusieurs systèmes. Inclus dans la distribution Linux, il s'agit d'un module de noyau et d'outils d'espace utilisateur pour travailler avec FS. OCFS2 peut être utilisé non seulement sur DRBD, mais également sur iSCSI avec plusieurs connexions. Dans notre exemple, nous utilisons DRBD.

Toutes les actions sont effectuées sur le serveur Ubuntu 18.04 dans une configuration minimale.

Étape 1. Configurez DRBD :

Dans le fichier /etc/drbd.d/drbd0.res nous décrivons notre périphérique 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;
}
}

méta-disque interne - utiliser les mêmes périphériques de bloc pour stocker les métadonnées
périphérique /dev/drbd0 - utilisez /dev/drbd0 comme chemin d'accès au volume drbd.
disque /dev/vdb1 - utilisez /dev/vdb1
synchroniseur { taux 1000M ; } - utiliser la bande passante du canal Gigabit
autoriser deux primaires - une option importante qui permet d'accepter les modifications sur deux serveurs principaux
après-sb-0pri, après-sb-1pri, après-sb-2pri - options responsables des actions du nœud lorsque le splitbrain est détecté. Plus de détails peuvent être trouvés dans la documentation.
devenir-primaire-sur les deux - définit les deux nœuds comme principaux.

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

Dans notre exemple, les noms réseau de deux nœuds de cluster sont drbd1 et drbd2. Pour un fonctionnement correct, vous devez faire correspondre les noms et adresses IP des hôtes dans /etc/hosts.

10.10.10.192 drbd1
10.10.10.193 drbd2

Étape 2. Configurer les nœuds :

Sur les deux serveurs, nous exécutons :

drbdadm create-md drbd0

modprobe drbd
drbdadm up drbd0
cat /proc/drbd

Nous obtenons ce qui suit :

Vous pouvez démarrer la synchronisation. Sur le premier nœud, vous devez exécuter :

drbdadm primary --force drbd0

Regardons le statut :

cat /proc/drbd

Super, la synchronisation a commencé. On attend la fin et on voit la photo :

Étape 3. Démarrez la synchronisation sur le deuxième nœud :

drbdadm primary --force drbd0

Nous obtenons ce qui suit :

Nous pouvons désormais écrire sur drbd à partir de deux serveurs.

Étape 4. Installez et configurez ocfs2.

Nous utiliserons 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'écrire dans /etc/ocfs2/cluster.conf sur les deux nœuds.

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

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

Ici, nous avons créé un système de fichiers avec le label testVol sur drbd0, en utilisant les paramètres par défaut.

Dans /etc/default/o2cb vous devez définir (comme dans notre fichier de configuration)

O2CB_ENABLED=true 
O2CB_BOOTCLUSTER=ocfs2cluster 

et exécutez sur chaque nœud :

o2cb register-cluster ocfs2cluster

Ensuite, nous allumons et ajoutons toutes les unités dont nous avons besoin pour l'exécution automatique :

systemctl enable drbd o2cb ocfs2
systemctl start drbd o2cb ocfs2

Une partie de cela sera déjà exécutée pendant le processus d’installation.

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

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

Annuaire /média/partagé il doit être créé à l'avance.

Ici, nous utilisons les options noauto, ce qui signifie que le fichier ne sera pas monté au démarrage (je préfère monter les fichiers réseau via systemd) et heartbeat=local, ce qui signifie utiliser le service heartbeat sur chaque nœud. Il existe également un rythme cardiaque global, plus adapté aux grands clusters.

Ensuite, vous pouvez monter /média/partagé et vérifiez la synchronisation du contenu.

Fait! En conséquence, nous obtenons un stockage plus ou moins tolérant aux pannes avec une évolutivité et des performances décentes.

Source: habr.com