Pools répliqués (par défaut)

La configuration ODF par défaut utilise la réplication à trois voies. Chaque donnée est stockée en trois exemplaires répartis sur différents nœuds, ce qui permet de se prémunir contre jusqu'à deux pannes simultanées de disque ou de nœud.

• Avantages : architecture simple, lectures rapides, récupération rapide et latence prévisible.
• Augmentation de l'utilisation : 3x de stockage brut pour chaque octet de données utilisables.

Que se passe-t-il en cas de perte de copies ( rep3 ):

Le paramètre min_size contrôle le nombre minimum de copies qui doivent être disponibles avant que Ceph n'autorise les entrées/sorties. ODF définit par défaut des ensembles de min_size=2 pools rep3 s et cette configuration est appliquée via requireSafeReplicaSize: true, ce qui signifie que lorsque 2 ou 3 copies sont disponibles, les opérations de lecture et d'écriture se déroulent normalement. Lorsqu'une seule copie est disponible, Ceph bloque les opérations d'E/S afin d'éviter toute nouvelle incohérence des données.

Ce comportement est un mécanisme de sécurité délibéré qui privilégie l'intégrité des données au détriment de la disponibilité.

Le délai entre la perte de la deuxième copie et la fin de la réplication est le plus dangereux. Pendant ce temps, une troisième défaillance entraîne une perte de données permanente. C'est la raison pour laquelle la planification des capacités est importante, car la vitesse de réplication de Ceph dépend de la bande passante disponible du cluster et de l'espace libre. Un cluster surchargé ou presque plein met plus de temps à se répliquer, ce qui prolonge la durée d'exposition à la vulnérabilité.

Pour les pools d' rep2, la progression est plus rapide. Si une copie est perdue, il n'en reste plus qu'une. Avec ( min_size=2 par défaut), les E/S sont immédiatement bloquées sur les PG concernées jusqu'à ce que l'OSD manquant revienne ou qu'une nouvelle copie soit répliquée. Dans ce cas min_size=1, les opérations d’E/S se poursuivent sur la seule copie restante, mais une deuxième défaillance entraîne une perte définitive des données.

Le module complémentaire ODF d' Red Hat OpenShift Kubernetes Service crée automatiquement uniquement des pools rep3 avec ocs-storagecluster-cephblockpool. Rep2 Les pools ne sont pas créés par le module complémentaire. Vous devez créer manuellement une instance personnalisée de CephBlockPool avec replicated.size: 2 et une StorageClass correspondante. Pour plus d’informations, consultez la section Création d’une configuration personnalisée d’ StorageClass s pour la virtualisation.

rep2 offrant une tolérance aux pannes inférieure à celle d' rep3, évaluez si les économies réalisées en matière de stockage justifient le risque accru pour votre charge de travail.

IBM Il est recommandé d’utiliser la réplication à trois voies pour toutes les charges de travail de virtualisation en production afin de garantir la disponibilité et la pérennité des données.

Pools codés par effacement

Pour les environnements où l'efficacité de la capacité de stockage est une priorité, ODF prend également en charge les pools à codage par effacement (EC). L'EC divise les données en blocs de données k et en blocs de parité m, ce qui réduit l'espace de stockage brut par rapport à la réplication tout en garantissant une tolérance aux pannes.

Statut de prise en charge : le codage d'effacement pour les RBD et les CephFS dans ODF est une fonctionnalité en préversion pour les développeurs, introduite pour la première fois dans la version ODF 4.20. Les fonctionnalités en avant-première pour les développeurs ne sont pas prises en charge en environnement de production. Ils ne sont pas non plus pris en charge par le système de gestion des dossiers du portail client d' Red Hat. Avant l' 4.20 d'ODF, seule la version EC de RGW (stockage d'objets) était disponible en avant-première pour les développeurs (à partir de l' 4.16 d'ODF). Bien que le moteur de stockage Ceph sous-jacent prenne en charge les écrasements EC pour RBD depuis la version Luminous (2017), l'opérateur ODF et son modèle de déploiement géré ne certifient pas encore les pools EC pour les charges de travail de stockage de blocs de production. Prévoyez d'utiliser des pools répliqués ( rep2 ou rep3 ) pour tous les environnements de production VM, et n'envisagez les pools EC que pour les environnements hors production où les limitations de la préversion pour développeurs sont acceptables.

Le tableau suivant compare tous les types de pools disponibles à titre de référence.

Les listes suivantes présentent les principaux éléments à prendre en compte concernant le codage d'effacement.

• Les pools EC présentent une latence d'écriture plus élevée que les pools répliqués en raison du calcul de parité et de la nécessité d'écrire davantage de blocs par opération.
• Les pools EC offrent un débit de lecture séquentielle compétitif, mais peuvent présenter des IOPS d'écriture aléatoire réduits.
• Le nombre de domaines de défaillance doit être au moins égal à k+m. Sur un cluster à 3 nœuds, seules les configurations suivantes sont possibles : rep2, rep3 et ec-2-1.
• Pour un cluster à 6 nœuds, tous les types de pools mentionnés précédemment sont disponibles.

Pool à réplique unique (non résilient, réservé au développement et aux tests)

À partir de la version du module complémentaire ODF 4.14, Red Hat OpenShift Kubernetes Service prend en charge un pool de répliques unique ( rep1 ) par l'intermédiaire du paramètre addSingleReplicaPool. Ce paramètre crée un pool de blocs Ceph non résilient, sans réplication des données, dans lequel chaque bloc de données est stocké une seule fois.

Pour activer le pool à réplique unique lors du déploiement d’ODF, utilisez la commande suivante

ibmcloud oc cluster addon enable openshift-data-foundation -c <cluster_name> \
  --version <version> \
  --param "addSingleReplicaPool=true"

Cette commande crée une extra- StorageClass:

• ocs-storagecluster-ceph-non-resilient-rbd: Stockage de blocs à réplique unique avec WaitForFirstConsumer volume binding.

Le pool d' replica-3 s standard (ocs-storagecluster-cephblockpool) est toujours créé avec cette commande. La réserve non résiliente est une option distincte et facultative.

Un pool de répliques unique présente les cas d'utilisation suivants.

• Environnements de développement et de test : lorsque la pérennité des données n'est pas essentielle et que la priorité est donnée à la réduction des coûts de stockage.
• Applications avec réplication intégrée : ces applications gèrent elles-mêmes la redondance de leurs données au niveau de la couche applicative. Ces applications conservent plusieurs copies sur différents nœuds, ce qui signifie que la réplication au niveau du stockage est redondante.

Le pool de répliques unique offre une tolérance de panne nulle. La défaillance d'un seul OSD ou d'un seul nœud entraîne une perte de données permanente et irrécupérable pour toutes les données de cet OSD. Aucune deuxième copie n'est disponible pour la récupération. La documentation de IBM Cloud avertit explicitement que cette option augmente le risque de perte et de corruption des données, ainsi que l'instabilité potentielle du système. Pour plus d'informations, voir la documentation Ceph.

Limites :

• Stockage en blocs uniquement : le stockage de fichiers n'est pas pris en charge avec une seule réplique.
• Disques supplémentaires requis : au moins un disque NVMe utilisable supplémentaire par nœud, en plus de ceux utilisés par le pool replica-3. Sans ce disque supplémentaire, les OSD replica-1 ne démarrent pas et la grappe de stockage reste dans un état de progression.
• Un pool par domaine de défaillance : ODF crée un site CephBlockPool non résilient par domaine de défaillance, avec des volumes liés en utilisant WaitForFirstConsumer pour valider la localité des données.
• Non recommandé pour les disques racine de la charge de travail des machines virtuelles : Si l'OSD qui héberge un disque racine tombe en panne, la charge de travail de la machine virtuelle est définitivement perdue. Utilisez le pool non résilient uniquement pour les disques de données jetables dans les charges de travail des machines virtuelles de développement ou de test.

Pour les charges de travail de virtualisation en production, utilisez toujours des pools replica-3 (ou au minimum replica-2 ).

VMware vSAN Comparaison des options de migration

Pour les équipes qui migrent depuis VMware vSAN™, ces types de pools Ceph correspondent aux politiques de stockage habituelles d’ vSAN:

Principales différences par rapport à vSAN:

• Des minimums d'hôtes plus petits : Ceph sépare le quorum du cluster du placement des données. Un pool rep3 ne nécessite que 3 hôtes, car chaque hôte stocke une copie complète. vSAN RAID-1 FTT=2 nécessite 5 hôtes.
• rep2 Conforme à la norme vSAN RAID-1: La plupart des déploiements d' vSAN utilisent FTT=1, qui stocke 2 copies. L' rep2 de Ceph en est l'équivalent direct.
• ec-3-1 correspond à vSAN RAID-5: Les deux utilisent une configuration 3+1 et permettent une utilisation de type 1.33x, l’option la plus économe en espace pour une tolérance à une seule défaillance.
• ec-4-2 correspond à vSAN RAID-6: Les deux utilisent une configuration 4+2 et permettent une utilisation de type 1.5x avec une tolérance à deux pannes.
• ec-2-1 et ec-2-2 n'ont pas d'équivalent direct dans l' vSAN: des configurations Ceph EC plus petites avec moins de blocs de données, ce qui se traduit par une utilisation plus importante par octet mais nécessite moins d'hôtes. Ils privilégient l'efficacité du stockage au détriment d'un nombre réduit d'hôtes requis.

Capacité de planification

Lorsque vous planifiez votre cluster ODF, tenez compte de l'utilisation brute du stockage liée à la politique de protection des données que vous avez choisie. La capacité utilisable est inférieure à la capacité NVMe brute totale.

La formule de la capacité utilisable est la suivante : Usable capacity = Total raw NVMe capacity / Replication or EC overhead factor.

Voir l'exemple suivant de calculs pour un cluster à 3 nœuds avec 8 disques NVMe de 3.2 To par nœud ( 76.8 To de données brutes au total):

Estimation de la capacité de la charge de travail de la machine virtuelle : Une machine virtuelle typique avec un disque racine de 30 Go et un disque de données de 100 Go utilise 130 Go de stockage utilisable. Avec l' rep3, cette charge de travail de machine virtuelle nécessite 390 Go de stockage brut. Sur le cluster à 3 nœuds précédent, vous pourriez provisionner environ 196 charges de travail de machines virtuelles de cette taille. En pratique, l'utilisation de Ceph doit être inférieure à 75 % pour maintenir les performances et soutenir les opérations de récupération.

Les performances de Ceph se dégradent au fur et à mesure que l'utilisation du cluster augmente. ODF déclenche l'alerte PrometheusCephOSDNearFull (Utilisation de l'OSD en baisse) dès qu'un OSD dépasse 75 % de son utilisation. À 85 %, Ceph active l'indicateur OSD nearfull natif (mon_osd_nearfull_ratio) et ODF déclenche l'alerte CephOSDCriticallyFull. À 90 %, Ceph interrompt les opérations de remplissage et de récupération sur l’OSD concerné (mon_osd_backfillfull_ratio). À 95 %, Ceph marque l’OSD full (mon_osd_full_ratio), bloque toutes les écritures et émet HEALTH_ERR. Planifiez votre capacité de manière à ce que l'utilisation reste inférieure à 70 % en conditions normales d'exploitation, afin de disposer d'une marge suffisante pour la récupération des données et le rééquilibrage en cas de maintenance ou de défaillance des nœuds.

Pour vérifier l'utilisation actuelle du cluster, exécutez la commande suivante :

oc exec -n openshift-storage $(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name) -- ceph df

Nombre de nœuds de travail et topologie

La topologie du domaine de défaillance utilisée par le module complémentaire ODF d' IBM Cloud dépend de la configuration de votre cluster :

• Clusters multizones (3 zones de disponibilité): le domaine de défaillance est défini sur zone. Les nœuds de travail sont répartis entre les zones, et l'ODF doit évoluer par multiples de 3 pour maintenir l'équilibre entre les zones. Pour une disponibilité, des performances et une sécurité des données optimales, utilisez 3, 6 ou 9 nœuds dans le cluster de stockage ODF — chaque zone reçoit le même nombre de nœuds.
• Clusters à zone unique ou clusters comportant moins de 3 zones de disponibilité : la mise à l'échelle flexible est automatiquement activée et le domaine de défaillance est défini sur host. Vous pouvez commencer avec 3 nœuds et en ajouter un par un.

Tous les nœuds qui participent au cluster de stockage ODF doivent être en métal nu. Il n'est pas possible de mélanger des nœuds virtualisés et des nœuds bare-metal au sein d'un même cluster ODF.

Pour les clusters multi-zones : l'ajout de nœuds dont le nombre n'est pas un multiple de 3 entraîne un déséquilibre entre les zones. Avec 4 nœuds, une zone en reçoit 2 tandis que les autres en reçoivent 1 chacune, ce qui entraîne une répartition inégale de la charge sur les OSD, un placement des données sous-optimal, une utilisation inégale et des OSD partiellement inactifs.

Pour les clusters multi-zones, effectuez toujours la mise à l'échelle par multiples de 3 afin de maintenir une topologie de zones équilibrée.

oc get nodes -l node-role.kubernetes.io/worker= \
  -o custom-columns='NAME:.metadata.name,RACK:.metadata.labels.topology\.kubernetes\.io/rack'

Plans d'abonnement ODF

Choisissez la formule qui correspond le mieux à vos besoins :

• Essentials

  • Coût réduit
  • Déploiement en mode interne uniquement
  • Ne prend pas en charge la reprise après sinistre, les clusters étendus ni les déploiements en mode externe
  • Convient particulièrement aux environnements de test et de développement, aux démonstrations de faisabilité ou aux déploiements à petite échelle

• A l'avance

  • Ensemble complet de fonctionnalités comprenant la reprise après sinistre, les clusters étendus, le déploiement en mode externe, le chiffrement granulaire avancé et la prise en charge multi-clusters
  • Recommandé pour les charges de travail de virtualisation en production avec des machines virtuelles

Les deux formules incluent la compression BlueStore sur les pools de blocs, l'allocation dynamique, les instantanés et le clonage. Les différences entre les formules concernent la reprise après sinistre, la granularité du chiffrement et la flexibilité de déploiement, plutôt que les fonctionnalités liées à l'efficacité du stockage.

ODF prend en charge la déduplication uniquement pour le stockage d'objets via la passerelle Multicloud Object Gateway (MCG). Le stockage en bloc ne prend pas en charge la déduplication. Cette assistance s'applique aussi bien aux formules Essentials qu'aux formules Advanced. La déduplication Ceph en amont pour RBD reste expérimentale et n'est pas certifiée pour une utilisation dans ODF.

Pour plus d'informations, consultez la rubrique ODF : notions de base et avancées.

Type de stockage

• Sélectionnez Stockage local.
• Le stockage local utilise le stockage d'instance NVMe local disponible sur les nœuds de travail bare metal.
• Les disques NVMe offrent une latence réduite et des performances IOPS élevées, indispensables pour les disques destinés aux charges de travail des machines virtuelles.

Profil de ressources ODF

ODF fournit trois profils d'allocation de ressources qui contrôlent l'unité centrale et la mémoire réservées aux démons Ceph.

• Lean : allocation minimale des ressources. Le profil Lean est adapté aux environnements à ressources limitées, aux tests, au développement et aux preuves de concept. L'approche Lean n'est pas recommandée pour les charges de travail de virtualisation en production.
• Équilibré : Le profil par défaut sur Red Hat OpenShift Kubernetes Service. Le profil équilibré offre un équilibre entre la consommation de ressources et les performances pour les charges de travail générales.
• Performances : alloue davantage de ressources CPU et de mémoire aux démons Ceph, ce qui réduit le risque de goulots d'étranglement au niveau des démons. Idéal pour les charges de travail à haut débit IOPS, les déploiements comportant un grand nombre de serveurs virtuels et les applications exigeantes.

Pour les déploiements bare metal avec des disques NVMe locaux, utilisez le profil de ressources Performance. Les nœuds bare-metal comportant au moins 8 disques NVMe par nœud génèrent un nombre élevé d’OSD par hôte. Avec le profil Balanced, les limites de CPU et de mémoire du démon Ceph sont souvent atteintes avant que le matériel NVMe sous-jacent ne soit saturé, ce qui limite les IOPS et augmente la latence. Le profil Performance est le profil minimum recommandé pour les charges de travail de virtualisation d’ Red Hat OpenShift s de production sur serveurs physiques.

Les besoins en ressources affichés dans la console web Red Hat OpenShift lors de l'installation d'ODF sont calculés dynamiquement en fonction du nombre d'OSD du cluster. Par conséquent, les clusters comportant davantage de disques NVMe nécessitent proportionnellement plus de ressources. Ces valeurs ne sont pas fixes. Vérifiez toujours les exigences affichées dans la console pour votre configuration de cluster spécifique.

Le profil est sélectionné lors de la création de StorageSystem via l'écran Configure Performance de la console web Red Hat OpenShift. Des démons Ceph sous-dimensionnés peuvent devenir un goulot d'étranglement caché, entraînant une baisse des IOPS ou une latence plus élevée que ce que le matériel de stockage sous-jacent est capable de fournir.

Faites correspondre vos profils de serveurs métalliques nus aux besoins en ressources indiqués pour le profil choisi : IBM Cloud Profils de serveurs métalliques nus VPC.

Une légère sursouscription des ressources est souvent acceptable sur un serveur bare metal. Cependant, ne prévoyez jamais des ressources nettement inférieures aux exigences minimales affichées, car cela nuit aux performances et à la stabilité d’ODF.

Nombre de disques OSD par nœud

• Déterminez le nombre de disques NVMe locaux disponibles sur chaque serveur bare metal.
• Veillez à ce que le nombre d'OSD configurés par nœud ne dépasse pas le nombre de disques NVMe utilisables.
• La configuration recommandée est d'un OSD par disque NVMe pour des performances optimales et une isolation des pannes.
• Veillez à ce que le nombre de disques OSD corresponde généralement au nombre de disques NVMe par nœud bare metal. Le calcul de la capacité de stockage affiché dans l’interface utilisateur ne reflète pas la capacité utilisable réelle pour les configurations de stockage local et peut être ignoré.

Lorsque vous sélectionnez des nœuds lors de la création d' StorageSystem, évitez de sélectionner tous les nœuds du cluster. La sélection de tous les nœuds crée un système de répartition de charge ( LocalVolumeSet, LVS) sans nodeSelector. Tout nœud de travail ajouté ultérieurement au cluster sera automatiquement détecté par ODF, même s’il n’est pas destiné au stockage. Les nœuds détectés de manière inattendue doivent être supprimés manuellement du LVS. Pour éviter cela, sélectionnez uniquement les nœuds de votre pool de travailleurs de stockage dédié, ou assurez-vous que ces nœuds portent le label cluster.ocs.openshift.io/openshift-storage avant la création de l' StorageSystem.

StorageClass par défaut pour le cluster

Une fois l’ODF déployé, les fichiers followingStorageClasses sont généralement créés :

• ocs-storagecluster-ceph-rbd: Stockage en bloc
• ocs-storagecluster-cephfs: Stockage de fichiers
• ocs-storagecluster-ceph-rgw: Stockage d'objets

Pour permettre aux charges de travail d'utiliser automatiquement un stockage en blocs persistant haute performance basé sur ODF sans configuration supplémentaire, sélectionnez Utiliser le périphérique de blocs Ceph RADOS (RBD) comme classe de stockage par défaut ou définissez manuellement RBD (ocs-storagecluster-ceph-rbd) comme StorageClass par défaut pour le cluster une fois le module complémentaire ODF installé.

1. Marquer RBD comme valeur par défaut :

   oc patch storageclass ocs-storagecluster-ceph-rbd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
   

2. Si nécessaire, supprimez la valeur par défaut de la configuration par défaut précédemment définie :

   oc patch storageclass <previous-default-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
   

Liste de contrôle pour la configuration d'ODF

• Le cluster contient au moins un pool de serveurs bare metal
• Red Hat OpenShift version 4.17 ou supérieure
• Le module complémentaire ODF et l'opérateur sont installés et fonctionnent
• Les serveurs bare metal disposent de suffisamment de disques NVMe locaux utilisables
• Le profil de ressources sélectionné correspond à la capacité du nœud
• Un cluster de stockage ODF utilise au moins 3 nœuds; les clusters multizones doivent utiliser des multiples de 3 (3, 6, 9, …) pour maintenir l'équilibre entre les zones
• Tous les nœuds participant à ODF sont en métal nu
• Le RBD StorageClass est créé et, de préférence, défini comme valeur par défaut
• L'état du cluster ODF est Prêt (oc get storagecluster -n openshift-storage)
• L'état de Ceph est HEALTH_OK (oc -n openshift-storage rsh $(oc get pod -l app=rook-ceph-tools -o name) ceph status)

Prérequis : installer l'opérateur de virtualisation Red Hat OpenShift

Avant d'utiliser la virtualisation d' Red Hat OpenShift sur IBM Cloud, vérifiez que l'opérateur de virtualisation Red Hat OpenShift est installé dans votre cluster Red Hat OpenShift Kubernetes Service.

L'opérateur de virtualisation Red Hat OpenShift permet la gestion des charges de travail des machines virtuelles natives d' Kubernetes. Il fournit également les contrôleurs nécessaires, les CRD et les intégrations avec les composants de stockage et de réseau.

Pour plus d'informations, voir Red Hat OpenShift Virtualization sur IBM Cloud.

Utilisation du stockage ODF pour les charges de travail des machines virtuelles

Red Hat OpenShift Data Foundation (ODF) fournit un stockage permanent défini par logiciel pour les charges de travail de virtualisation qui s'exécutent sur Red Hat OpenShift. Lorsque vous utilisez ODF comme backend de stockage pour les machines virtuelles, il est essentiel de choisir la bonne configuration StorageClass afin de garantir les performances, la stabilité et la compatibilité totale des fonctionnalités.

Vous devez indiquer l’ StorageClass appropriée dans les situations suivantes :

• Les serveurs virtuels sont créés
• Les serveurs virtuels sont importés ou clonés
• Les serveurs virtuels sont migrés vers un cluster Red Hat OpenShift Kubernetes Service

Virtualisation par défaut StorageClass

Une fois l’ Red Hat OpenShift Virtualization Operator installé et un cluster ODF disponible, une instance StorageClass optimisée pour les charges de travail de virtualisation est automatiquement créée :

• ocs-storagecluster-ceph-rbd-virtualization

Ce site StorageClass est :

• Adapté aux schémas d'E/S sur disque tels que les lectures aléatoires, les écritures et les débits soutenus
• Validé pour les opérations du cycle de vie de la virtualisation telles que le démarrage, l'arrêt, la migration en direct et les instantanés
• Entièrement pris en charge et recommandé pour les environnements de virtualisation Red Hat OpenShift

Dans la plupart des cas, utilisez cette page StorageClass sans la modifier.

Exigences en matière de stockage pour la migration en direct

La migration en direct permet de déplacer une charge de travail de machine virtuelle en cours d'exécution d'un nœud de travail à un autre sans interruption de service. Pour une migration en direct réussie, le stockage doit être accessible simultanément depuis les nœuds d'origine et de destination. La migration à chaud nécessite les configurations suivantes.

• ReadWriteMany mode d'accès sur les PVC de charge de travail des machines virtuelles. Ceph RBD prend en charge RWX en mode bloc, qui est la configuration par défaut de la virtualisation ODF StorageClass.
• Le service StorageClassocs-storagecluster-ceph-rbd-virtualization est préconfiguré avec une prise ReadWriteMany en charge via le mode bloc RBD. Les serveurs virtuels qui utilisent ce site StorageClass peuvent migrer en direct sans configuration supplémentaire.
• Le site générique ocs-storagecluster-ceph-rbd StorageClass utilise par défaut le mode d'accès ReadWriteOnce. Les serveurs virtuels qui utilisent des PVC RWO ne peuvent pas effectuer de migration en direct. La migration échoue car le PVC ne peut pas être monté sur le nœud de destination alors qu'il est attaché à la source.

Si vous créez des customStorageClasses (PVC) pour des serveurs virtuels nécessitant une migration à chaud, vérifiez que les PVC sont créés avec accessModes: [ReadWriteMany] et volumeMode: Block.

La migration en direct est également nécessaire :

• Configurer l'opérateur de virtualisation Red Hat OpenShift avec une politique de migration appropriée
• Vérification de la disponibilité de l'unité centrale et de la mémoire sur le nœud de destination

RBD spécifique à la virtualisation par rapport au RBD générique StorageClass

Bien que les machines virtuelles puissent utiliser une configuration Ceph RBD générique ( StorageClass, ), la configuration spécifique à la virtualisation ( StorageClass ) est optimisée pour les caractéristiques propres aux disques de charge de travail des machines virtuelles en termes d’E/S et de cycle de vie.

Les StorageClasses s RBD génériques restent adaptées aux charges de travail en conteneurs, mais il est recommandé de se reporter aux StorageClass s spécifiques à la virtualisation pour les environnements de virtualisation en production.

Création d'un site personnalisé StorageClass pour la virtualisation

Dans certains cas, vous pouvez avoir besoin d'un site StorageClass personnalisé pour répondre à des exigences spécifiques en matière de performances, de résilience ou de capacité.

Pour créer une configuration personnalisée d' StorageClass, vous devez d'abord créer une configuration personnalisée d' CephBlockPool. Lorsque vous créez un pool personnalisé, vous devez définir targetSizeRatio sur le pool. Sans ce paramètre, l'autoscaler des groupes de placement Ceph n'attribue qu'un seul groupe de placement au pool. Cette configuration provoque un goulot d'étranglement au niveau d'un seul OSD pour toutes les opérations d'E/S, ce qui se traduit par des performances inférieures à celles du pool par défaut.

Lorsque vous créez un site StorageClass personnalisé pour les charges de travail de virtualisation, vérifiez que les paramètres suivants sont correctement configurés.

• Fournisseur

  L' StorageClass e doit utiliser le provisionneur Ceph RBD CSI fourni par ODF :

  openshift-storage.rbd.csi.ceph.com
  

  Ce provisionneur permet le provisionnement dynamique des volumes Ceph RBD qui sont sauvegardés par le cluster ODF.

• Pool de stockage

  Indiquez le site CephBlockPool qui sauvegarde les disques de charge de travail de la machine virtuelle. Vous pouvez choisir l'une des options suivantes :

  • Bloc par défaut. Le pool de blocs Ceph répliqué à trois voies par défaut créé par ODF :

      ocs-storagecluster-cephblockpool
      ```
  
  - Piscine en blocs sur mesure. Une adresse définie par l'utilisateur CephBlockPool. Le pool doit comprendre les paramètres suivants pour éviter les problèmes de performance :
  
  ```yaml
        apiVersion: ceph.rook.io/v1
        kind: CephBlockPool
        metadata:
        name: my-custom-pool
        namespace: openshift-storage
       spec:
         failureDomain: zone          # Default for multi-zone clusters — data copies spread across zones; use host for single-zone flexible-scaling clusters
         deviceClass: ssd             # Match OSD device class
         enableCrushUpdates: true     # Keep CRUSH rules current on topology changes
         enableRBDStats: true         # Enable per-volume I/O monitoring
         replicated:
          size: 3
          requireSafeReplicaSize: true
              targetSizeRatio: 0.1       # CRITICAL — prevents 1-PG bottleneck
          ```
      The `targetSizeRatio` instructs the placement group autoscaler to proportionally preallocate placement groups based on the expected capacity share. Without it, the pool receives 1 PG and all I/O is funneled through a single OSD.
      
  

• Caractéristiques de l'image

  Le site StorageClass doit inclure les caractéristiques de l'image RBD qui sont essentielles pour la performance de la charge de travail :

  imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
  

  Caractéristiques de l'image RBD et leur utilité

  Fonction	Objectif
  exclusive-lock	Active la mise en cache de l'écriture et l'optimisation de l'écriture unique. Sans cette fonction, les IOPS d'écriture peuvent être jusqu'à 7x inférieurs.
  object-map	Permet le suivi bitmap des objets alloués pour les images peu denses.
  fast-diff	Accélère les opérations de diff de snapshot et de clonage DataVolume pour un démarrage plus rapide.
  deep-flatten	Rend les clones totalement indépendants après leur aplatissement.
  layering	Active le clonage par copie sur écriture qui est nécessaire pour le clonage DataVolume.

• Options de carte

  mapOptions: krbd:rxbounce
  

  Cette option corrige les problèmes de corruption des données lorsque vous utilisez le pilote RBD du noyau avec des serveurs virtuels Windows. Cela oblige le noyau à utiliser un tampon de rebond pour les données reçues afin d'assurer la compatibilité. Cette option doit être définie sur toutes les instances d' StorageClasses de charge de travail.

• Exemple complet et personnalisé de StorageClass

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: my-custom-virt-sc
  provisioner: openshift-storage.rbd.csi.ceph.com
  parameters:
    clusterID: <your-cluster-id>
    pool: my-custom-pool
    imageFormat: "2"
    imageFeatures: layering,deep-flatten,exclusive-lock,object-map,fast-diff
    mapOptions: krbd:rxbounce
    csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
    csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
    csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
    csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
    csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
    csi.storage.k8s.io/fstype: ext4
  reclaimPolicy: Delete
  allowVolumeExpansion: true
  volumeBindingMode: Immediate
  

  Pour trouver le site clusterID de votre cluster, exécutez la commande suivante :

  oc get sc ocs-storagecluster-ceph-rbd -o jsonpath='{.parameters.clusterID}'
  

  Pour les pools avec codage d’effacement (aperçu développeur uniquement), consultez la section Comprendre la protection des données, ajoutez dataPool qui pointe vers le pool EC, et conservez pointant pool vers le pool répliqué par défaut :

  parameters:
    pool: ocs-storagecluster-cephblockpool   # Replicated pool for metadata
    dataPool: my-ec-pool                      # EC pool for data blocks
  

Compression

ODF prend en charge la compression en ligne BlueStore sur les pools de blocs Ceph, ce qui permet de réduire le stockage brut utilisé par les disques. La compression est appliquée de manière transparente au niveau de la couche OSD; ainsi, la charge de travail de la machine virtuelle et son système d'exploitation invité ne se rendent pas compte que les données sont compressées.

apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: compressed-block-pool
  namespace: openshift-storage
spec:
  failureDomain: zone          # Default for multi-zone clusters; use host for single-zone flexible-scaling clusters
  deviceClass: ssd
  enableCrushUpdates: true
  enableRBDStats: true
  replicated:
    size: 3
    requireSafeReplicaSize: true
    targetSizeRatio: 0.1
  parameters:
    compression_mode: "aggressive"

Chiffrement

ODF prend en charge le cryptage des données au repos à plusieurs niveaux que vous pouvez activer indépendamment.

• IBM Cloud Chiffrement de l'infrastructure : chiffrement complet du disque sur des disques physiques NVMe - géré par IBM Cloud.
• Chiffrement ODF à l'échelle du cluster : tous les disques OSD Ceph sont chiffrés avec dm-crypt au niveau du périphérique. Activé via encryption.clusterWide: true sur le CR du cluster de stockage. Protège contre le vol physique de disques.
• Chiffrement ODF par volume : les volumes RBD individuels sont chiffrés à l'aide de la technologie LUKS2, chacun disposant de sa propre clé de chiffrement des données. Assure l'isolation des locataires et une gestion granulaire des clés.

Sur Red Hat OpenShift Kubernetes Service, ODF s'intègre à IBM Key Protect en tant que service de gestion des clés externes pour le chiffrement à l'échelle du cluster et par volume. Lorsque le cryptage par volume est activé, ODF crée automatiquement des variantes de -encrypted StorageClass (par exemple, ocs-storagecluster-ceph-rbd-encrypted).

Optimisation des performances de Ceph pour les serveurs bare metal NVMe

La configuration par défaut de Ceph est optimisée pour les charges de travail générales. Les valeurs de paramètres suivantes sont validées sur le profil bare-metal mx2d.metal.96x768 et augmentent considérablement les IOPS tout en réduisant la latence pour les charges de travail sur disque VM sur ce profil. Si vous utilisez un profil bare-metal différent, considérez ces informations comme une référence de départ et adaptez les valeurs en fonction du nombre de disques NVMe et de la capacité CPU disponibles pour votre profil spécifique.

Appliquez chaque paramètre à l'aide de la commande ceph config set du pod Ceph toolbox :

TOOLS_POD=$(oc get pod -n openshift-storage -l app=rook-ceph-tools -o name)
# OSD memory and shard tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_memory_target 8589934592
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_shards_ssd 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd osd_op_num_threads_per_shard_ssd 2
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd bluestore_prefer_deferred_size_ssd 0
# RocksDB tuning
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_write_buffer_size 268435456
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_write_buffer_number 16
oc exec -n openshift-storage ${TOOLS_POD} -- ceph config set osd rocksdb_max_background_jobs 12

Une fois la configuration appliquée, vérifiez qu'elle a bien été acceptée :

oc exec -n openshift-storage ${TOOLS_POD} -- ceph config dump | grep -E "osd_memory_target|osd_op_num_shards|bluestore_prefer_deferred|rocksdb"

Il n'est pas nécessaire de redémarrer les pods OSD pour appliquer les modifications ceph config set. Ceph applique la configuration de manière dynamique. Cependant, les modifications apportées au cache d' BlueStore (osd_memory_target) ne prennent pleinement effet qu'après le recyclage de chaque pod OSD. Vous pouvez recycler les pods OSD un par un pendant une fenêtre de maintenance sans interrompre les opérations d'E/S.

Référence de benchmark : des tests internes réalisés sur un cluster mx2d.metal.96x768 à 3 nœuds comprenant 200 machines virtuelles et un nombre illimité d’IOPS ont montré que la combinaison de 16 shards, de 8 Go de mémoire OSD et d’un tampon d’écriture RocksDB de 256 Mo permettait d’atteindre environ 194 000 IOPS et un débit de 758 Mo/s. L'augmentation du nombre de shards de 8 à 16 a systématiquement généré la plus forte amélioration en termes d'IOPS parmi toutes les configurations testées.

Sauvegarde basée sur des instantanés

ODF prend en charge Kubernetes VolumeSnapshots pour les volumes Ceph RBD. Pour prendre un instantané d'un disque, utilisez la commande suivante :

oc apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-vm-snapshot
spec:
  volumeSnapshotClassName: ocs-storagecluster-rbdplugin-snapclass
  source:
    persistentVolumeClaimName: my-vm-data-disk
EOF

VolumeSnapshots sont copiés à l'écriture et leur création est quasi instantanée. Vous pouvez les utiliser pour restaurer une charge de travail de machine virtuelle à un état antérieur ou pour cloner un disque. La virtualisation Red Hat OpenShift fournit également une API intégrée d'instantanés et de restaurations VM qui permet de capturer l'état complet de la charge de travail de la machine virtuelle, y compris la configuration et tous les disques, en une seule opération.

Réduction de la charge de travail des machines virtuelles pour des instantanés cohérents avec l'application

Lorsque vous effectuez un instantané d'une charge de travail sur une machine virtuelle en cours d'exécution, les données présentes sur le disque doivent être cohérentes. En l'absence de quiescing, l'instantané capture tout ce qui se trouve sur le disque à ce moment-là, y compris les transactions partiellement écrites, les tampons sales et les E/S en vol. Ce processus génère un instantané cohérent en cas de panne, ce qui peut nécessiter une restauration au niveau de l'application lors de la remise en service.

Pour obtenir des instantanés cohérents avec l’application, gelez le système de fichiers invité avant la création de l’instantané, puis dégelez-le après. Red Hat OpenShift Virtualization automatise ce processus à l’aide de l’agent invité QEMU.

Le contrôleur d'instantanés détecte l'agent invité QEMU. Avant de réaliser l' VolumeSnapshot, il exécute une commande guest-fsfreeze-freeze qui interrompt toutes les opérations d'E/S des systèmes de fichiers. L' est réalisée pendant que le système de fichiers est gelé. Une fois l'instantané terminé, une commande guest-fsfreeze-thaw reprend les entrées/sorties. Le statut de l'instantané indique le niveau de cohérence atteint. Reportez-vous au tableau ci-dessous pour connaître la signification de chaque statut.

Il est recommandé d'installer l'agent invité QEMU sur toutes les machines virtuelles de production. Sur les machines Linux, utilisez la commande suivante.

# RHEL / CentOS / Fedora
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# Ubuntu / Debian
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Pour les invités Windows, installez le paquet de pilotes VirtIO, qui comprend le service d'agent invité QEMU.

Hooks personnalisés de gel/dégel pour les applications : pour les bases de données et autres applications avec état qui nécessitent une mise en veille supplémentaire au-delà du gel du système de fichiers, placez des scripts de hook personnalisés au sein de la charge de travail de la machine virtuelle invitée à l'emplacement /etc/qemu-ga/fsfreeze-hook.d/. Ces scripts sont exécutés automatiquement par l’agent invité avec un argument freeze avant le gel du système de fichiers et un thaw argument après le dégel du système de fichiers. Les journaux d'exécution des crochets sont écrits sur /var/log/qga-fsfreeze-hook.log.

Par exemple, le crochet de gel PostgreSQL suivant peut être placé à l'adresse /etc/qemu-ga/fsfreeze-hook.d/postgresql.sh:

#!/bin/bash
case "$1" in
  freeze)
    sudo -u postgres psql -c "SELECT pg_backup_start('snapshot');" 2>/dev/null || true
    ;;
  thaw)
    sudo -u postgres psql -c "SELECT pg_backup_stop();" 2>/dev/null || true
    ;;
esac

VMware Comparaison : cet exemple est analogue au script de pré-gel et de post-dégel de l' VMware, utilisé avec les outils d' VMware pour créer des instantanés cohérents avec les applications. L'agent invité QEMU remplit le même rôle que les outils d' VMware s pour la mise en veille des instantanés.

Modification des limitations du suivi des blocs

La fonctionnalité Changed Block Tracking permet d'effectuer des sauvegardes incrémentielles en identifiant uniquement les blocs qui ont été modifiés depuis la dernière sauvegarde. Le VADP (API vStorage s pour la protection des données) de VMware utilise ce mécanisme pour fournir des sauvegardes incrémentielles efficaces.

CBT n'est pas disponible pour ODF et Ceph RBD sur Red Hat OpenShift Virtualization. Les sauvegardes s'appuient actuellement sur des instantanés complets, ce qui peut entraîner des fenêtres de sauvegarde plus longues et une utilisation plus importante de l'espace de stockage.

Le développement des TCC est en cours à plusieurs niveaux :

Bien que Ceph RBD prenne en charge la fonctionnalité rbd diff sous-jacente permettant d'identifier les blocs modifiés entre deux instantanés, cette fonctionnalité n'est pas encore accessible via l'API CSI Changed Block Tracking d' Kubernetes. Tant que la pile complète n'est pas en place (CSI CBT API + Ceph CSI driver support + KubeVirt integration), les sauvegardes incrémentales au niveau des blocs ne sont pas disponibles.

Solutions de sauvegarde

Plusieurs fournisseurs de solutions de sauvegarde proposent des solutions pour la virtualisation d' Red Hat OpenShift, qui s'inscrivent dans le modèle actuel basé sur les instantanés :

• Veeam® Kasten : Kubernetes-protection native des données avec prise en charge de la virtualisation Red Hat OpenShift et capacités d'instantanés incrémentiels pour ODF. Pour plus d'informations, voir l'architecture de référence de Veeam Kasten.
• Trilio pour Kubernetes: Sauvegarde et récupération pour les charges de travail de virtualisation Red Hat OpenShift avec intégration ODF. Pour plus d'informations, voir la prise en charge de la virtualisation de Trilio Red Hat OpenShift.
• Veritas NetBackup: Enterprise backup avec Red Hat OpenShift Virtualization support. Pour plus d’informations, consultez NetBackup- Protection complète des données d’entreprise.

Recommandations pour VMware migrations

Si votre environnement VMware actuel repose sur des sauvegardes incrémentielles basées sur CBT, tenez compte des recommandations suivantes :

• Prévoyez des sauvegardes complètes. Évaluez vos fenêtres de sauvegarde et vos besoins en stockage en vous basant sur des sauvegardes complètes VolumeSnapshots plutôt que sur des sauvegardes incrémentielles.
• Évaluer les outils de sauvegarde natifs sur Kubernetes. Veeam Kasten et Trilio sont conçus pour la virtualisation Kubernetes et Red Hat OpenShift, et fonctionnent dans le cadre du modèle de snapshot actuel.
• Utiliser l'efficacité des instantanés Ceph. Les instantanés Ceph RBD fonctionnent selon le principe copy-on-write et n'utilisent de l'espace de stockage que pour les blocs modifiés après la création de l'instantané, ce qui rend le stockage continu des instantanés plus efficace que celui de copies complètes.

Contrôler l'état de santé d'ODF et de Ceph

Une surveillance régulière du cluster de stockage ODF est essentielle pour maintenir la disponibilité et les performances. La section suivante décrit les commandes principales et leurs résultats.

TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
oc exec -n openshift-storage ${TOOLS_POD} -- ceph status

  cluster:
    id:     a1b2c3d4-...
    health: HEALTH_OK          ← What you want to see
  services:
    mon: 3 daemons             ← Should be 3 (quorum)
    mgr: 1 active              ← Manager daemon running
    osd: 24 osds: 24 up, 24 in ← All OSDs healthy (should match your NVMe count)
  data:
    pools:   4 pools, 353 pgs
    objects: 12.5k objects, 48 GiB
    usage:   152 GiB used, 69 TiB / 70 TiB avail   ← Cluster usage

oc exec -n openshift-storage ${TOOLS_POD} -- ceph health detail

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree

oc exec -n openshift-storage ${TOOLS_POD} -- ceph df

oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd pool stats

Mise à jour d'ODF sur Red Hat OpenShift Kubernetes Service

Le module complémentaire ODF ( IBM CloudRed Hat OpenShift Data Foundation) applique automatiquement les mises à jour z-stream au sein d'une même version mineure. Ces mises à jour sont gérées par IBM Cloud.

Toutefois, les mises à jour de version majeures et mineures (par exemple, 4.18 → 4.19 ) ne sont pas automatiques. Suivez la procédure de mise à niveau manuelle pour garantir la sécurité des données et la stabilité du cluster.

La mise à jour d'ODF sur un cluster Red Hat OpenShift Kubernetes Service se compose de deux phases principales, toutes deux nécessaires à la réussite de la mise à jour.

1. Mettre à jour ou remplacer les nœuds de travail ODF.

   • ODF s'appuie sur des nœuds de travail dédiés ou étiquetés pour héberger les composants de stockage.
   • Lors d'une mise à niveau majeure ou mineure, ces nœuds de travail doivent être mis à niveau ou remplacés pour s'aligner sur les versions cibles de Red Hat OpenShift et d'ODF.
   • Ce processus permet de s'assurer que les pods ODF (tels que les OSD Ceph, les MON et les managers) sont reprogrammés correctement et continuent de fonctionner sans perte de données.
   • Assurez-vous que la capacité est suffisante et que les nœuds sont en bon état de fonctionnement avant de commencer cette étape afin de garantir la disponibilité du stockage.

2. Mettre à jour le module complémentaire ODF.

   • Après la mise à niveau ou le remplacement des nœuds de travail, mettez à jour le module complémentaire ODF.
   • Cette étape met à niveau les opérateurs ODF, les pilotes CSI et les composants connexes vers la version cible.
   • Une fois la mise à jour du module complémentaire terminée, le cluster réconcilie automatiquement les ressources ODF et applique les modifications requises.

   Effectuez une validation après la mise à niveau pour vérifier :

   • Santé des clusters ODF et Ceph
   • StorageClasses disponibilité
   • Succès des opérations de lecture et d'écriture du PVC par les applications

Pour plus d'informations, voir Mise à jour d'ODF sur les clusters VPC.

Extension de l'espace de stockage ODF sur l' Red Hat OpenShift Kubernetes Service

Par conséquent, à mesure que vos charges de travail s'accroissent et que vos besoins en stockage augmentent, il devient essentiel de faire évoluer votre infrastructure de stockage. L'extension d'ODF est une opération clé du deuxième jour qui vous permet d'augmenter la capacité de stockage, d'améliorer les performances et de maintenir la résilience sans perturber les applications en cours d'exécution.

Dans les environnements IBM Cloud Red Hat OpenShift Kubernetes Service, l'expansion implique généralement l'extension du pool de travailleurs du stockage. Cette opération s'effectue avec un minimum de temps d'arrêt, ce qui permet une croissance transparente de votre cluster de stockage.

1. Ajoutez des nœuds de travail à votre cluster VPC. Pour les clusters multi-zones dont le cluster de stockage s'étend sur 3 zones de disponibilité, ajoutez des nœuds de travail par multiples de 3 afin de maintenir l'équilibre entre les zones (par exemple, 3, 6 ou 9). Pour les clusters à zone unique sur lesquels la mise à l'échelle flexible est activée, vous pouvez ajouter des nœuds un par un.

2. Une fois les nœuds ajoutés, enregistrez-les auprès d'ODF. Si ODF s'exécute sur tous les nœuds de travail de votre cluster, les nouveaux nœuds sont automatiquement ajoutés à la topologie de stockage. Si ODF ne fonctionne que sur un sous-ensemble de nœuds de travail, passez à l'étape suivante.

3. Si ODF fonctionne sur tous les nœuds de travail de votre cluster, les nouveaux nœuds de travail sont ajoutés automatiquement à la topologie du cluster de stockage ODF. Si ODF ne s'exécute que sur un sous-ensemble de nœuds de travail, spécifiez les paramètres <workerNodes> privés dans votre ressource personnalisée OcsCluster. Ajoutez les noms des nouveaux nœuds de travail à votre déploiement ODF en modifiant la définition des ressources personnalisées. Modifiez la ressource personnalisée OcsCluster comme suit :

   • Rechercher ocscluster

     oc get ocscluster
     

   • Modifier le fichier de ressources personnalisées ocscluster et ajouter de nouveaux nœuds de travail

     oc edit ocscluster <ocs cluster name> -o yaml
     

   • Enregistrez le fichier de ressource personnalisée OcsCluster pour le réappliquer à votre cluster.

4. Augmentez la valeur de l' 'numOfOsd' e dans votre ressource personnalisée OcsCluster afin de permettre à OCS de déployer des composants ODF sur les nœuds de travail nouvellement ajoutés et de provisionner des OSD supplémentaires dans le cluster de stockage.

   L'ajustement de la valeur 'numOfOsd' dépend à la fois du nombre de disques OSD par nœud et du nombre de nœuds ajoutés. Par exemple, si chaque nœud dispose de 8 disques NVMe dédiés aux OSD, l'ajout de 3 nœuds augmente l' 'numOfOsd' e de 8, tandis que l'ajout de 6 nœuds l'augmente de 16.

5. Vérifiez le résultat en exécutant la commande suivante :

   oc exec -n openshift-storage ${TOOLS_POD} -- ceph osd tree
   

6. Vérifiez que les nouveaux nœuds de travail ont bien été ajoutés et qu’ils sont répartis de manière homogène dans chaque zone (pour les clusters multizones) ou qu’ils apparaissent sous forme de buckets d’hôtes individuels (pour les clusters à mise à l’échelle flexible à zone unique), ainsi que le nombre correspondant d’OSD attribués à chaque nœud.

Pour plus d'informations, consultez la section « Étendre ODF en ajoutant des nœuds de travail à votre cluster VPC ».

Mise à l'échelle flexible

Le module complémentaire ODF d' IBM Cloud utilise différentes topologies de domaines de défaillance en fonction de la configuration de votre cluster :

• Clusters multizones (3 zones de disponibilité): le domaine de défaillance est défini sur zone. Les OSD sont provisionnés par multiples de 3, à raison d'un ensemble par zone, afin d'assurer la réplication des données et la haute disponibilité entre les zones. Le cluster de stockage doit s'étendre par multiples de 3 afin de maintenir l'équilibre entre les zones.
• Clusters à zone unique ou clusters comportant moins de 3 zones de disponibilité : la mise à l'échelle flexible est automatiquement activée. Le domaine de défaillance est défini sur host, ce qui signifie que chaque nœud individuel constitue un domaine de défaillance distinct. Vous pouvez ajouter un nœud à la fois et faire évoluer le stockage de manière granulaire.

À partir de la version ODF 4.21, le comportement de mise à l’échelle flexible est déterminé automatiquement lors du déploiement initial en fonction de la topologie du cluster et ne peut plus être modifié par la suite.

Dans un déploiement à zone unique ou à évolutivité flexible, un pool de services replica-3 résiste à la perte d'un hôte quelconque. Dans un déploiement multi-zones, un pool de replica-3 s résiste à la perte d'une zone entière. Vérifiez que la topologie de votre cluster et la tolérance aux pannes associée répondent à vos exigences en matière de résilience avant de déployer ODF en production.

Pour connaître l’ensemble des paramètres des modules complémentaires et les étapes d’installation via la console, consultez la section Déploiement d’ OpenShift Data Foundation sur des clusters VPC.

Performances lors de l'extension d'un nœud : l'ajout d'un nœud à un cluster ODF à évolutivité flexible déclenche un rééquilibrage des données Ceph. Lors du test interne décrit ci-dessous, les IOPS et le débit sont restés stables tandis que la latence en écriture a temporairement augmenté. Lors de tests internes réalisés sur un cluster à 3 nœuds comprenant 100 machines virtuelles à 50 000 IOPS, les résultats suivants ont été observés :

La latence d'écriture revient à son niveau de référence une fois le rééquilibrage terminé. Prévoyez l'ajout de nœuds pendant les périodes de faible activité d' VM, si vos charges de travail sont sensibles aux pics de latence en écriture.