Comment déployer Scality RING sur OPCP

Objectif

Scality RING est une plateforme de stockage logicielle qui transforme un ensemble de serveurs en un système unique de stockage objet (S3¹) et/ou fichier (NFS/CIFS), avec une protection des données assurée soit par erasure coding (ARC), soit par réplication (COS), sans nécessiter de contrôleur RAID matériel.

L'On-Prem Cloud Platform (OPCP) d'OVHcloud expose les serveurs physiques de son Bare Metal Pool via OpenStack : Nova confie chaque instance à Ironic, qui démarre en PXE une machine physique entière avec l'image que vous fournissez, plutôt que d'exécuter une machine virtuelle sur un hyperviseur. Il n'y a pas d'accès console et, sur la plateforme de production cible, aucun accès SSH direct aux nœuds avant leur déploiement.

Ce guide détaille le déploiement d'un cluster RING sur du bare metal OPCP, de bout en bout :

1. La préparation des nœuds bare metal (bonding réseau et, éventuellement, RAID logiciel pour le disque OS).
2. Le provisionnement des ports réseau et des instances bare metal avec Terraform.
3. Le lancement automatique de l'installeur RING, piloté par cloud-init, puisque les nœuds ne sont pas joignables en SSH avant leur démarrage.
4. La vérification du déploiement et l'accès à l'interface du superviseur RING.

Prérequis

• Disposer d'un projet OVHcloud OPCP comptant suffisamment de nœuds Bare Metal Pool à l'état Ironic available pour votre topologie cible. Le cluster minimal pris en charge par RING sur cette plateforme est 1 nœud superviseur et 3 nœuds de stockage, les 3 nœuds de stockage devant être soit des modèles du catalogue High Capacity Storage (write cache pas encore disponible), soit des modèles High Performance Storage.

• Disposer d'un identifiant d'application OpenStack (application credential) pour ce projet, utilisable à la fois par la CLI OpenStack et par Terraform. Consultez l'étape Création d'une Application Credential depuis Horizon du guide OVHcloud « Comment utiliser Terraform » pour OPCP.

• Avoir installé les outils suivants sur le poste de travail depuis lequel vous lancez le déploiement :

  • la CLI OpenStack (openstack), pour importer les images (étape 2), configurer le LACP et le RAID (étape 3) et lancer les commandes de vérification (étape 8) ;
  • Terraform (ou OpenTofu) avec le provider terraform-provider-openstack, pour provisionner les ports réseau et les instances bare metal ;
  • jq, pour analyser la sortie JSON de la vérification des groupes de ports (étape 8) ;
  • un client SSH, utile si vous devez accéder directement au superviseur plutôt que par sa seule interface web.

• Disposer d'une image qcow2 superviseur Scality RING et d'une ou plusieurs images qcow2 stockage, basées sur Rocky Linux ou RHEL — les seuls systèmes d'exploitation pris en charge par RING sur OPCP — prêtes à être importées dans Glance. L'image superviseur est censée déjà embarquer le bundle d'installation RING, car le superviseur n'a aucun moyen garanti de le récupérer après son démarrage sur cette plateforme.

  Info

  Vous ne construisez pas ces images vous-même : demandez les images qcow2 superviseur et stockage (ainsi que le bundle d'installation RING, s'il n'est pas déjà intégré à l'image superviseur) à Scality, via votre interlocuteur commercial ou le support Scality. La construction ou la personnalisation des images RING n'est pas couverte par ce guide — consultez le portail de documentation Scality pour cette procédure, ou le guide OVHcloud sur la construction d'une image CentOS Stream personnalisée pour comprendre les exigences sous-jacentes d'Ironic/Nova en matière d'images.

• Posséder une licence Scality RING valide. RING ne s'installe et ne fonctionne sans licence que dans un état d'évaluation limité et borné dans le temps ; demandez une licence auprès du support Scality avant toute mise en production.

• Disposer d'un export de l'outil de dimensionnement RING (un fichier cluster.csv décrivant les rôles de vos nœuds, la disposition des disques et les paramètres de dimensionnement RING), généralement fourni par votre interlocuteur commercial ou le support Scality.

• Disposer du réseau privé backend déjà provisionné par le Bare Metal Pool pour votre projet (utilisé pour le plan interne RING) et, éventuellement, d'un second réseau pour le trafic client S3/NFS, que Terraform peut créer pour vous.

En pratique

1. S'authentifier sur OPCP

Exportez votre identifiant d'application pour que la CLI OpenStack et Terraform puissent l'utiliser :

export OS_AUTH_TYPE=v3applicationcredential
export OS_AUTH_URL=<opcp-keystone-endpoint>
export OS_IDENTITY_API_VERSION=3
export OS_REGION_NAME=<opcp-region>
export OS_INTERFACE=public
export OS_APPLICATION_CREDENTIAL_ID="<application-credential-id>"
export OS_APPLICATION_CREDENTIAL_SECRET="<application-credential-secret>"

Vérifiez que cela fonctionne :

openstack token issue -f value -c id

2. Importer les images RING dans Glance

Importez les images superviseur et stockage fournies par Scality, en donnant à chacune un nom distinct :

openstack image create --disk-format qcow2 --container-format bare \
  --file <chemin-vers-image-superviseur>.qcow2 "<nom-image-superviseur>"

openstack image create --disk-format qcow2 --container-format bare \
  --file <chemin-vers-image-stockage>.qcow2 "<nom-image-stockage>"

La construction ou la personnalisation de ces images sort du périmètre de ce guide — consultez la note de la section « Prérequis » pour savoir comment les obtenir.

3. Préparer les nœuds bare metal

Deux réglages au niveau des nœuds se situent en dehors de Terraform, car le driver OpenStack Ironic standard ne dispose d'aucune ressource Terraform pour eux. Configurez ces réglages avant le déploiement des nœuds — ils ne peuvent être modifiés que sur des nœuds sans instance, et les refaire plus tard nécessite d'abord de détruire l'instance.

Bonding réseau (LACP). RING attend que chaque nœud présente son ou ses réseaux sous forme d'interface agrégée (bond0 pour le plan backend et, si vous utilisez un réseau frontend, bond1), afin que la perte d'une seule carte réseau ou d'un switch top-of-rack ne mette pas le nœud hors service. Configurez un groupe de ports 802.3ad (LACP) par plan directement dans OpenStack Ironic, en suivant le guide OVHcloud « Comment configurer LACP sur un nœud ». Utilisez la politique de hachage layer3+4 pour que le trafic se répartisse sur les 2 membres du bond (la valeur par défaut du noyau, layer2, attache chaque flux à un seul lien).

RAID logiciel pour le disque OS (facultatif). Si vous souhaitez que le disque OS soit en miroir plutôt que de dépendre d'un contrôleur RAID matériel, configurez un target_raid_config RAID-1 sur chaque nœud en suivant le guide OVHcloud « Comment configurer un RAID logiciel sur un nœud », avant le prochain déploiement du nœud.

4. Définir votre configuration Terraform

RING ne fournit pas de module Terraform public pour OPCP ; cette configuration est donc construite directement à partir des providers OpenStack, tls et random. Elle nécessite, dans l'ordre : une IP backend fixe par nœud, votre CSV de dimensionnement complété avec ces adresses, une paire de clés SSH de déploiement dédiée, les instances bare metal elles-mêmes, et une configuration cloud-init suffisante pour que le superviseur pilote l'installation une fois tous les nœuds démarrés.

Providers et adresses des nœuds

terraform {
  required_providers {
    openstack = {
      source  = "terraform-provider-openstack/openstack"
      version = "~> 3.0"
    }
    tls    = { source = "hashicorp/tls", version = "~> 4.0" }
    random = { source = "hashicorp/random", version = "~> 3.0" }
  }
}

provider "openstack" {
  # Lit OS_AUTH_URL, OS_APPLICATION_CREDENTIAL_ID, etc. depuis l'environnement de l'étape 1.
}

variable "backend_network_name" { type = string }
variable "backend_subnet_name"  { type = string }
variable "store_image_name"      { type = string }
variable "supervisor_image_name" { type = string }

variable "lacp_enabled" {
  type    = bool
  default = true
}

# L'IP backend privée du superviseur (voir étape 9).
variable "supervisor_published_address" { type = string }

# Une IP backend fixe par nœud, indexée par minion_id — doit correspondre exactement à
# cluster.csv. La topologie minimale de RING sur OPCP est un superviseur et trois nœuds de
# stockage.
variable "node_ips" {
  type = map(string)
  default = {
    "<minion-id-superviseur>" = "<ip-backend-superviseur>"
    "<minion-id-stockage-1>"  = "<ip-backend-stockage-1>"
    "<minion-id-stockage-2>"  = "<ip-backend-stockage-2>"
    "<minion-id-stockage-3>"  = "<ip-backend-stockage-3>"
  }
}

Compléter le CSV de l'outil de dimensionnement

Votre export de l'outil de dimensionnement peut regrouper plusieurs sections (par exemple, des paramètres au niveau du ring suivis d'un tableau de serveurs). Extrayez uniquement le tableau des serveurs — une ligne par nœud, avec son en-tête — dans son propre fichier (par exemple servers.csv), en conservant minion_id, role et enclosure tels que fournis, et en laissant vides les colonnes d'adresse (data_ip, data_iface, s3_ip, s3_iface). Terraform remplit alors exactement ces 4 colonnes :

locals {
  csv_rows = csvdecode(file("${path.module}/servers.csv"))
  iface    = var.lacp_enabled ? "bond0" : "eth0"

  completed_rows = [
    for row in local.csv_rows : merge(row, {
      data_ip    = var.node_ips[row.minion_id]
      data_iface = local.iface
      s3_ip      = row.role == "supervisor" ? "" : var.node_ips[row.minion_id]
      s3_iface   = local.iface
    })
  ]

  completed_csv = csvencode(local.completed_rows)
  store_ips     = [for r in local.completed_rows : r.data_ip if r.role != "supervisor"]
  nodes         = { for r in local.completed_rows : r.minion_id => r }
}

Ports réseau

data "openstack_networking_network_v2" "backend" {
  name = var.backend_network_name
}

data "openstack_networking_subnet_v2" "backend" {
  name = var.backend_subnet_name
}

resource "openstack_networking_port_v2" "backend" {
  for_each   = var.node_ips
  name       = "${each.key}-backend"
  network_id = data.openstack_networking_network_v2.backend.id

  fixed_ip {
    subnet_id  = data.openstack_networking_subnet_v2.backend.id
    ip_address = each.value
  }
}

Paire de clés de déploiement et mot de passe GUI

resource "tls_private_key" "deploy" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

resource "random_password" "gui" {
  length  = 20
  special = false
}

Instances bare metal et cloud-init

resource "openstack_compute_instance_v2" "node" {
  for_each = local.nodes

  name         = each.key
  image_name   = each.value.role == "supervisor" ? var.supervisor_image_name : var.store_image_name
  flavor_name  = each.value.enclosure
  config_drive = true

  network {
    port = openstack_networking_port_v2.backend[each.key].id
  }

  user_data = each.value.role == "supervisor" ? templatefile("${path.module}/cloudinit-supervisor.yaml.tftpl", {
    deploy_private_key = tls_private_key.deploy.private_key_openssh
    deploy_public_key  = tls_private_key.deploy.public_key_openssh
    store_ips          = local.store_ips
    cluster_csv        = local.completed_csv
    gui_password       = random_password.gui.result
    published_address  = var.supervisor_published_address
  }) : templatefile("${path.module}/cloudinit-store.yaml.tftpl", {
    deploy_public_key = tls_private_key.deploy.public_key_openssh
  })
}

output "port_ids" {
  value = { for k, p in openstack_networking_port_v2.backend : k => p.id }
}

output "gui_password" {
  value     = random_password.gui.result
  sensitive = true
}

cloudinit-store.yaml.tftpl a uniquement besoin d'autoriser la clé de déploiement en tant que root, pour que le superviseur puisse accéder au nœud :

#cloud-config
users:
  - name: root
    ssh_authorized_keys:
      - ${deploy_public_key}

cloudinit-supervisor.yaml.tftpl autorise la même clé, dépose le CSV complété et la partie privée de la clé de déploiement, puis attend que chaque nœud de stockage réponde en SSH avant de lancer l'installeur RING de façon non interactive et détachée (pour qu'il survive à la fin de cloud-init) :

#cloud-config
users:
  - name: root
    ssh_authorized_keys:
      - ${deploy_public_key}

write_files:
  - path: /root/.ssh/id_rsa
    permissions: '0600'
    content: |
      ${indent(6, deploy_private_key)}
  - path: /var/tmp/scality/cluster.csv
    content: |
      ${indent(6, cluster_csv)}

runcmd:
  - |
    for ip in ${join(" ", store_ips)}; do
      timeout 3600 bash -c "until ssh -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa root@$ip true; do sleep 10; done"
    done
    RING_GUI_PASSWORD=${gui_password} RING_SUPERVISOR_FQDN=${published_address} \
      setsid /root/<bundle-installeur-ring>.run --yes --conf /var/tmp/scality/conf \
      > /var/tmp/scality/install.log 2>&1 &

5. Effectuer une vérification préalable

Avant de lancer terraform plan, vérifiez en lecture seule les conditions préalables au déploiement :

• L'identifiant d'application et le provider Terraform peuvent tous deux joindre le projet.
• Les images superviseur et stockage existent dans Glance sous les noms référencés par votre configuration.
• Le nombre de nœuds à l'état Ironic available est au moins égal à celui qu'exige votre cluster.csv.
• Si lacp_enabled est activé, chaque nœud susceptible d'être sélectionné par Terraform porte déjà ses groupes de ports LACP (étape 3). Nova peut choisir n'importe quel nœud available et le CSV de l'installeur fige les noms de bond au moment du plan : un nœud sans bonding démarre avec une configuration réseau incohérente.
• Si vous avez configuré le RAID logiciel, son état correspond à ce que vous souhaitez pour ce déploiement.

Corriger un écart à ce stade est bien moins coûteux qu'après le provisionnement d'une instance bare metal.

6. Vérifier et appliquer le plan Terraform

terraform init
terraform plan -out=tfplan
terraform show tfplan > tfplan.txt

Lisez attentivement tfplan.txt avant d'appliquer le plan :

terraform apply tfplan

7. Laisser l'installation automatisée se dérouler

Puisque les nœuds ne sont pas joignables en SSH avant leur démarrage, l'installeur RING est lancé par cloud-init lui-même plutôt que par un opérateur exécutant un script :

• Terraform génère une paire de clés de déploiement dédiée. La partie publique est ajoutée au fichier authorized_keys de root sur chaque nœud ; la partie privée n'est présente que dans le cloud-init du superviseur, pour que seul le superviseur puisse accéder en root à chaque nœud de stockage.
• Au premier démarrage, le superviseur écrit sur le disque local le CSV d'installation complété et la configuration de l'installeur, puis attend que chaque nœud de stockage réponde en SSH root (l'ordre de démarrage des nœuds bare metal n'étant pas garanti, cette attente est généralement assortie d'un délai généreux, de l'ordre d'une heure).
• Une fois que tous les nœuds répondent, le superviseur lance l'installeur RING de façon non interactive et détachée, pour qu'il survive à la fin de cloud-init et ne soit pas affecté par une coupure de connexion vers le superviseur.

Aucune action de l'opérateur n'est requise à cette étape — c'est tout l'intérêt de la conception pilotée par cloud-init.

8. Vérifier le déploiement

Avant de considérer que l'installation progresse normalement, vérifiez que la couche réseau correspond à ce que le CSV supposait au moment du plan :

openstack baremetal port group list --node <node> --long -f json | jq '.[] | {name, internal_info}'

Chaque groupe de ports backend doit porter l'ID de port du nœud issu de votre sortie Terraform port_ids dans internal_info.tenant_vif_port_id (et, si vous avez configuré un réseau frontend, chaque groupe de ports frontend doit porter l'entrée frontend_port_ids correspondante). Cette correspondance n'est pas garantie contractuellement par Ironic, mieux vaut donc la vérifier après chaque déploiement, et pas uniquement après le premier.

Depuis le superviseur, vérifiez dans l'OS invité que chaque bond est monté avec l'adresse attendue et que la route par défaut pointe vers la passerelle backend, puis suivez le journal d'installation :

tail -f /var/tmp/scality/install.log

9. Accéder à l'interface du superviseur RING

Récupérez le mot de passe GUI/admin généré par Terraform :

terraform output -raw gui_password

Depuis un hôte ayant accès au réseau backend, ouvrez ensuite https://<supervisor_published_address>/gui/ dans un navigateur, où <supervisor_published_address> est l'IP backend privée du superviseur. Acceptez le certificat auto-signé lors du premier accès et connectez-vous en tant qu'administrateur.

Conclusion

À ce stade, Terraform gère les ports réseau, les instances bare metal et les identifiants générés, et cloud-init a piloté une installation RING sans intervention sur l'ensemble des nœuds. Vous disposez d'un cluster Scality RING fonctionnel sur OPCP, prêt pour l'activation de la licence (si ce n'est pas déjà fait) et pour la configuration de S3/IAM et, le cas échéant, des connecteurs fichiers. Pour tout ce qui va au-delà — dimensionnement, modifications de la topologie du ring, configuration des connecteurs, mises à jour — consultez le portail de documentation Scality, et contactez le support Scality pour toute question de licence ou d'incident.

Aller plus loin

• Portail de documentation Scality — concepts RING, configuration et exploitation au-delà du déploiement initial
• Support Scality — licences et assistance technique
• Présentation d'OPCP
• Comment utiliser Terraform
• Comment configurer LACP sur un nœud
• Comment configurer un RAID logiciel sur un nœud
• Cycle de vie d'un nœud OPCP
• Matrice de compatibilité OPCP Core
• Contexte sur les exigences d'image Ironic/Nova : image CentOS Stream personnalisée

Pour une formation ou une assistance technique sur la mise en œuvre de nos solutions, contactez votre commercial ou consultez la page Professional Services pour obtenir un devis et faire analyser votre projet par nos experts.

Échangez avec notre communauté d'utilisateurs.

¹ : S3 est une marque déposée appartenant à Amazon Technologies, Inc. Les services d'OVHcloud ne sont pas sponsorisés, approuvés, ou affiliés de quelque manière que ce soit.