Stockage multinœud

Cette page décrit le stockage multinœud du système d'appliance Google Distributed Cloud (GDC) air-gapped.

L'appliance GDC isolée par un sas se compose de trois serveurs et de six disques NVMe (Non-Volatile Memory Express) qui y sont rattachés :

  • 2 supports de démarrage NVMe de 1 To
  • 4 NVMe de 3,84 To

Les deux disques NVMe de 1 To de chaque nœud sont dédiés aux charges de travail de démarrage et système, tandis que les quatre autres disques NVMe de 3,84 To sont utilisés pour le stockage fiable des données.

GDC utilise Ceph comme stockage défini par logiciel pour stocker de manière fiable les données système et utilisateur. Le cluster Ceph est déployé au niveau Bare Metal sur les trois serveurs et utilise un total de 12 disques NVMe de 3,84 To (quatre par serveur) attachés à ces serveurs comme stockage sous-jacent.

Chaque serveur contient un moniteur, un gestionnaire, RGW, RBD et quatre OSD.

Composants de stockage Ceph

Moniteur Ceph

Le moniteur Ceph gère les cartes d'état du cluster, y compris la carte du moniteur, la carte du gestionnaire et la carte du démon de stockage d'objets (OSD). Ces cartes représentent un état de cluster critique requis pour que les services Ceph se coordonnent entre eux. Les moniteurs sont également responsables de la gestion de l'authentification entre les services et les clients. Au moins trois moniteurs sont nécessaires pour assurer la redondance et la haute disponibilité.

Gestionnaire Ceph

Le gestionnaire Ceph est chargé de suivre les métriques d'exécution et l'état actuel du cluster Ceph, y compris l'utilisation du stockage, les métriques de performances actuelles et la charge du système. Au moins deux gestionnaires sont généralement requis pour la haute disponibilité. L'environnement GDC exécute autant de gestionnaires Ceph que de moniteurs. Par conséquent, trois gestionnaires Ceph sont déployés dans le cluster.

Démon Ceph OSD (Object Storage Daemon)

Le démon de stockage d'objets (https://docs.ceph.com/en/quincy/glossary/#term-Ceph-OSD) stocke les données et gère leur réplication, leur récupération et leur rééquilibrage. L'OSD fournit des informations de surveillance aux moniteurs et aux gestionnaires Ceph en vérifiant le signal de présence des autres OSD Ceph. Au moins trois OSD Ceph sont normalement requis pour la redondance et la haute disponibilité. L'environnement GDC alloue un OSD par lecteur physique.

Périphériques de blocs Ceph Rados (RBD)

Les périphériques de bloc Ceph sont provisionnés de manière fine et redimensionnables. Elles stockent les données réparties sur plusieurs OSD. Les périphériques de blocs Ceph exploitent les fonctionnalités de base de Ceph, y compris la création d'instantanés, la réplication et la cohérence forte. Dans l'environnement GDC, Ceph RBD n'est pas exposé directement. Toutefois, il est utilisé par le pilote CSI Ceph de stockage par blocs, qui est responsable de la prise en charge du stockage Kubernetes destiné aux utilisateurs (https://kubernetes.io/docs/concepts/storage/).

Ceph RGW

Ceph Rados Gateway est une interface de stockage d'objets qui fournit aux applications une passerelle RESTful vers les clusters de stockage Ceph (https://docs.ceph.com/en/quincy/glossary/#term-Ceph-Object-Storage).

  • Compatible avec S3 : fournit une fonctionnalité de stockage d'objets avec une interface compatible avec un grand sous-ensemble de l'API RESTful Amazon S3.
  • Compatible avec Swift : fournit une fonctionnalité de stockage d'objets avec une interface compatible avec un grand sous-ensemble de l'API OpenStack Swift.

Dans l'environnement GDC, seuls les points de terminaison S3 sont exposés à l'aide du service Kubernetes Service Mesh.

Résilience du stockage GDC

Les composants de stockage d'objets et de blocs Ceph sont configurés pour utiliser un facteur de réplication des données de 3. Au moins deux répliques doivent être disponibles pour continuer à diffuser des entrées/sorties (E/S). Le domaine de défaillance au niveau du nœud est utilisé, ce qui signifie que Ceph tente de répliquer les données trois fois (3x) sur trois serveurs différents.

Voici quelques exemples de gestion des échecs :

  • La défaillance d'un seul nœud n'entraîne pas de perte de données et n'a pas d'incidence sur les opérations de stockage des charges de travail.
  • Deux défaillances de disque sur des nœuds différents n'entraînent pas de perte de données. Toutefois, cela peut avoir un impact sur la disponibilité du stockage pour les charges de travail qui ont deux des trois répliques de données sur ces disques.
  • Plusieurs défaillances de nœuds ou plus de deux défaillances de disques sur différents nœuds peuvent entraîner une perte de données et peuvent avoir un impact sur la disponibilité du stockage pour les charges de travail.

Capacité de stockage GDC

La capacité d'espace disque brut disponible est égale à ce qui suit :

raw_capacity = 3.84TB * 4 (disks_per_node) * 3 (nodes) = 46.08TB

Toutefois, étant donné que les données stockées dans un cluster Ceph sont répliquées trois fois, la capacité de stockage utile disponible pour toutes les charges de travail est la suivante :

available_capacity = raw_capacity / 3 (replicas) = 15.36TB

15,36 To sont partagés entre les charges de travail système et utilisateur pour le stockage par blocs et d'objets.