Longhorn : Une solution de stockage viable en production ?

Publié le

Longhorn est un projet initialiement développé par Rancher et fait partie des "Sandbox projects" de la Cloud Native Computing Foundation (CNCF).

Longhorn se présente sous la forme d'un plugin CSI (Container Storage Interface). Il est capable de gérer des volumes de données dans Kubernetes grâce aux objets de type PersistentVolume et PersistentVolumeClaim, et il supporte les mécanismes de snapshots avec les objets de type SnapshotVolume.

Longhorn est une solution de stockage de données hautement disponible, qui en plus de son intégration avec Kubernete, propose des solutions de sauvegarde très utiles.

Un dashboard intégré est disponible pour faciliter l'administration de Longhorn.

Infrastructure cible

Longhorn s'installe dans un cluster Kubernetes comportant au moins 3 nœuds. Pour avoir des performances optimales, les développeurs préconisent d'avoir au moins 4 CPU, 4Go de ram et du stockage SSD ou NVMe sur chacun de ces nœuds. Ils déconseillent l'utilisation de disques mécaniques. L'idéal est d'avoir un disque dédié aux stockages des données par Longhorn.

Observabilité

Pour ce qui est de l'observabilité, Longhorn s'intègre très bien avec Prometheus. De ce fait, il est possible de surveiller efficacement son fonctionnement, et de mettre en place des alertes automatiques en cas de problème.

Une liste des métriques exportées est visible dans la documentation officielle.

Accès aux volumes en mode "ReadWriteMany"

Dans le cas où l'on souhaite déployer plusieurs replicas d'un Pod, qui utiliseraient un même volume, il est nécessaire de le monter en mode "ReadWriteMany". Dans le cas contraire, avec le mode "ReadWriteOnce", un seul replica accèdera au volume, les autres Pods ne pourront pas être déployés : ils restent dans le statut "Pending".

Malheureusement, la plupart des solutions de stockages pour Kubernetes ne permettent pas le mode "ReadWriteMany", car ce sont des volumes de type "block device" : ils se comportent comme un disque à part entière, chacun avec son propre système de fichier.

2021-03-17-ReadWriteOnce.svg
Mode ReadWriteOnce : un seul Pod peut accèder au volume

Longhorn implémente également son stockage sous la forme d'un "block device", mais supporte quand même le mode ReadWriteMany. Quand ce mode d'accès est demandé, Longhorn met en place automatiquement un serveur NFS, qui accède directement au volume de type "block device". Les Pods, eux, accèdent aux partages NFS.

2021-03-17-ReadWriteMany.svg
Mode ReadWriteMany : plusieurs Pods peuvent accèder au volume, au travers d'un serveur NFS

Mécanismes des sauvegardes

Quand on désire mettre en place une solution de stockage de données, dès le début de la mise en place de l'infrastructure, on doit mettre en place des sauvegardes.

Longhorn implémente plusieurs mécanismes facilitant celles-ci.

Les snapshots

Les snapshots permettent de stocker et éventuellement de restaurer l'état exact dans lequel était un volume de données à un instant T. Longhorn permet aussi de planifier la création automatique de snapshots de façon récurrente.

Les sauvegardes primaires et secondaires

Quand un volume est créé avec Longhorn, celui-ci est réservé sur l'espace disque des nœuds du cluster, puis il est mis à disposition via le protocole iSCSI. Plusieurs copies (ou replicas) de ce volume sont faites sur d'autres nœuds du cluster : avec le déploiement par défaut, 3 copies sont faites pour chaque volume. Les replicas sont une garantie de haute disponibilité, et constituent à eux seuls un premier mécanisme de sauvegarde : ce sont les backups primaires.

Un autre mécanisme de sauvegarde est implémenté par les backups secondaires : les sauvegardes sont exportées vers un serveur NFS ou un stockage objet compatible avec Amazon S3 (Digital Ocean Spaces, Scaleway Object Storage, Exoscale SKS, Minio, etc). L'idéal est bien sûr de stocker ces sauvegardes sur un site géographiquement différent de celui qui héberge votre cluster, voire même d'utiliser un autre fournisseur de Cloud pour héberger celles-ci. Ces sauvegardes peuvent être manipulées grâce aux objets de type VolumeSnapshot du standard CSI. Il ne faut pas les confondre avec le mécanisme de snapshot propre à Longhorn.

Les "Disaster Recovery Volumes"

Les Disaster Recovery Volumes sont une spécificité de Longhorn et ne font pas partie du standard CSI. Comme leur nom le sous-entend, ils permettent de faciliter l'implémentation d'un Disaster Recovery Plan efficace. Ce sont des volumes stockés dans un autre cluster. Ils sont une copie des volumes gérés par Longhorn, et permettent une restauration rapide des données en cas d'incident majeur.

Élaboration d'un plan de sauvegarde efficace

En production, suivant l'importance des services hébergés, l'idéal est de multiplier les mécanismes de sauvegarde. Pour des tâches critiques, il est judicieux de mettre en place tous les mécanismes de sauvegarde de Longhorn.

Un plan de sauvegarde possible est celui-ci :

  • snapshot des volumes (tous les jours, conservation sur les 7 derniers jours)
  • sauvegarde secondaire vers un serveur NFS dans un autre Datacenter, et si possible chez un autre fournisseur Cloud (tous les jours, conservation sur les 30 derniers jours)
  • sauvegarde du serveur NFS avec un outil comme restic, qui déduplique et chiffre les données vers un stockage objet (tous les jours, conservation sur les 90 derniers jours)

Conclusion

Longhorn implémente une solution de stockage très complète pour Kubernetes : nous avons de la haute disponibilité, de l'observabilité, et des solutions de sauvegarde intégrées. Tous les ingrédients sont là pour déployer cette solution en production.

Le support du mode ReadWriteMany est aussi un atout important quand on doit déployer des charges de travail hautement disponibles.

Autres références

PHILIPPE CHEPY

Administrateur Système et Développeur