Garage

Garage est une solution de stockage d'objets distribuée compatible avec l'API S3 (Amazon Simple Storage Service). Conçu pour être léger, résilient et facilement déployable, Garage permet de stocker de grandes quantités de données de manière répartie sur plusieurs zones, tout en assurant la redondance, la haute disponibilité et la tolérance aux pannes.

Installation

Les machines garage font partie des machines virtuelles créés avec Terraform. On en aura une dans chaque serveur (Titanium, Plutonium et Uranium). Une fois la création faite avec Terraform, nous allons mettre en place Garage avec une configuration Nix.

Nix

Configuration

Nous devons ajouter un nouveau dossier "Garage" dans la configuration Nix des serveurs. Dans ce dossier, on va créer un fichier garage.nix pour y mettre la configuration de Garage commune aux 3 machines :

NB : Pour l'instant, nous n'avons pas à notre disposition les node_id n'ayant pas encore les différents Garage d'installé

{
  config,
  pkgs,
  ...
}: {
  services.garage = {
    package = pkgs.garage_1_1_0;
    enable = true;
    settings = {
      metadata_dir = "/var/lib/garage/meta";
      data_dir = "/var/lib/garage/data";
      db_engine = "lmdb";
      metadata_auto_snapshot_interval = "6h";
      replication_factor = 3;
      compression_level = 2;

      s3_api = {
        s3_region = "garage";
        api_bind_addr = "0.0.0.0:3900";
        root_domain = ".s3.garage";
      };

      s3_web = {
        bind_addr = "0.0.0.0:3902";
        root_domain = ".web.garage";
        index = "index.html";
      };

      rpc_bind_addr = "0.0.0.0:3901";
      # commande pour générer le rpc_secret -> openssl rand -hex 32
      rpc_secret = "SECRET";

      bootstrap_peers = [
        "NODE_ID@10.125.0.2:3901"
        "NODE_ID@10.1.1.3:3901"
        "NODE_ID@10.50.75.2:3901"
      ];
    };
  };

  networking.firewall.allowedTCPPorts = [3901 3900 3902];
}

Pour chaque machine, on crée un dossier avec un fichier default.nix permettant de récupérer les différents fichiers dont il aura besoin. On ajoute ensuite dans chaque dossier un fichier networking.nix pour la partie réseau et adresse IP de la machine et un fichier garage.nix avec la configuration unique de chaque machine :

{config, ...}: {
  services.garage.settings = {
    rpc_public_addr = "IP_DE_LA_MACHINE:3901";
  };
}

Application de la configuration

Pour appliquer la configuration à nos machines, nous ajoutons dans Colmena nos configurations :

colmena = {
      ## Garage

      garage-titanium-01 = {
        name,
        nodes,
        pkgs,
        ...
      }: {
        deployment = {
          targetHost = "10.125.0.2";
          targetUser = "nixos";
          tags = ["garage" "titanium"];
        };
        imports = import ./hosts/garage/garage-titanium-01;
        networking.hostName = name;
      };

      garage-plutonium-01 = {
        name,
        nodes,
        pkgs,
        ...
      }: {
        deployment = {
          targetHost = "10.1.1.3";
          targetUser = "nixos";
          tags = ["garage" "plutonium"];
        };
        imports = import ./hosts/garage/garage-plutonium-01;
        networking.hostName = name;
      };

      garage-uranium-01 = {
        name,
        nodes,
        pkgs,
        ...
      }: {
        deployment = {
          targetHost = "10.50.75.2";
          targetUser = "nixos";
          tags = ["garage" "uranium"];
        };
        imports = import ./hosts/garage/garage-uranium-01;
        networking.hostName = name;
      };
}

Pour appliquer la configuration, on effectue cette commande :

colmena apply --impure --on @garage

Configuration de Garage

Node id

Maintenant que garage est installé sur les machines, nous pouvons récupérer les nodes id de chaque machine :

sudo garage node id

Une fois tous les nodes id récupérés, on modifie de nouveau notre configuration Nix que nous allons réappliquer.

Pour vérifier que les différentes machines se reconnaissent entre elles, nous utilisons cette commande :

sudo garage status

Zones

Dans Garage S3, une zone représente un groupe logique de serveurs, souvent basé sur un critère géographique ou physique (comme un datacenter ou un bâtiment). Bien que le concept soit libre et personnalisable, il est principalement utilisé pour renforcer la résilience et la haute disponibilité du stockage. Dans notre projet, nous allons configurer des zones afin de :

Répartir les données sur plusieurs emplacements logiques, ce qui réduit le risque de perte en cas de panne locale (ex. : coupure réseau ou crash d’un nœud).
Simuler un environnement multi-sites, comme cela se fait dans une infrastructure cloud professionnelle.
Améliorer la tolérance aux pannes : Garage essaiera automatiquement de répliquer les objets stockés dans des zones différentes, garantissant ainsi que les données restent accessibles même si une zone devient indisponible.
Tester des scénarios de basculement (failover) et de redondance dans un contexte distribué.

En résumé, l'utilisation des zones nous permet d’assurer que nos données sont à la fois redondées et réparties, une exigence essentielle pour tout système de stockage fiable et robuste.

Voici les zones créées :

sudo garage layout assign -z titanium -c 480G 3ac089f290dc53ab
sudo garage layout assign -z uranium -c 480G b36f0a8541f3425b
sudo garage layout assign -z plutonium -c 480G 5eea01bb3eca428e

sudo garage layout show

sudo garage layout apply --version 1

Bucket

Un bucket dans Garage (comme dans AWS S3) représente une unité logique de stockage. C’est dans ces buckets que seront stockés les fichiers et objets utilisés par les services de notre infrastructure.

Dans notre projet, nous devons créer deux buckets :

longhorn: utilisé pour le stockage persistant dans notre cluster Kubernetes (via Longhorn).
xcp-ng: utilisé pour les sauvegardes de machines virtuelles gérées avec Xen Orchestra.

Chaque bucket est distribué sur l’ensemble des zones définies.

sudo garage bucket create longhorn
sudo garage bucket create xcp-ng
sudo garage bucket list

API Key

Pour interagir avec les buckets, Garage utilise un système de clés API. Chaque clé correspond à une identité autorisée à lire ou écrire sur un ou plusieurs buckets.

Nous devons générer :

une clé longhorn-key pour permettre à Longhorn de lire et écrire dans son bucket dédié.
une clé xcp-ng-key pour autoriser Xen Orchestra à sauvegarder et restaurer des machines virtuelles dans son propre espace.

sudo garage key create longhorn-key
sudo garage key create xcp-ng-key
sudo garage key list

ACL

Une fois les clés créées, nous devons explicitement définir les droits d’accès à chaque bucket :

--read: autorise la lecture des données du bucket.
--write: autorise l’écriture (upload, modification, suppression) dans le bucket.

Cela permet de garantir un contrôle fin des accès, évitant qu’un service ait plus de permissions que nécessaire (principe du moindre privilège). Cette configuration est également essentielle pour la sécurité et la traçabilité des opérations sur les données.

 sudo garage bucket allow   --read   --write   longhorn   --key longhorn-key
sudo garage bucket allow   --read   --write   xcp-ng   --key xcp-ng-key

Sur chaque Bucket, nous pouvons vérifier que notre configuration s'est bien répliqué en effectuant cette commande :

sudo garage bucket info longhorn

Last modified: 30 April 2025