Présentation d'OpenShift Data Foundation
Virtual Private Cloud Infrastructure classique Satellite
OpenShift Data Foundation est une solution de stockage hautement disponible que vous pouvez utiliser pour gérer le stockage persistant de vos applications conteneurisées.
- Qu'est-ce qu'OpenShift Data Foundation ?
- OpenShift Data Foundation est une solution de stockage hautement disponible qui se compose de plusieurs opérateurs et technologies open source tels que Ceph, NooBaa et Rook. Ces opérateurs vous permettent de mettre à disposition et de gérer le stockage de fichiers, de blocs et d'objets pour vos charges de travail conteneurisées dans des clusters Red Hat® OpenShift® on IBM Cloud®. A la différence d'autres solutions de stockage pour lesquelles vous pouvez avoir besoin de configurer des pilotes et des opérateurs distincts pour chaque type de stockage, ODF est une solution unifiée capable d'adapter ou de mettre à l'échelle vos besoins de stockage. Vous pouvez également déployer ODF sur n'importe quel cluster OCP.
- Comment OpenShift Data Foundation fonctionne-t-il ?
- ODF utilise ces périphériques pour créer une couche de stockage virtualisée, où vos données d'application sont répliquées pour une haute disponibilité. Étant donné que ODF abstrait votre stockage sous-jacent, vous pouvez utiliser ODF pour créer des réclamations de stockage de fichiers, de blocs ou d'objets à partir du même stockage de bloc brut sous-jacent.
- ODF utilise des volumes de stockage en multiples de 3 et réplique vos données d'application dans ces volumes. Les volumes de stockage sous-jacents que vous utilisez pour ODF dépendent de votre type de cluster.
- Pour les clusters VPC qui utilisent des machines virtuelles, les volumes de stockage sont des volumes de stockage Block Storage for VPC.
- Pour les clusters Classic ou VPC qui utilisent des travailleurs bare metal, les volumes de stockage sont des disques locaux sur vos nœuds de travail bare metal.
- Pour les clusters Satellite, les volumes de stockage sont soit des disques locaux sur vos nœuds de travail, soit des disques que vous pouvez approvisionner dynamiquement à l'aide d'un pilote de stockage par blocs compatible.
- Puis-je installer l OpenShift Data Foundation sur des clusters VPC privés uniquement?
- Oui, vous pouvez installer ODF sur des clusters VPC privés uniquement à partir de la version de cluster
4.16.23_1546_openshiftpour les travailleurs d' CoreOS, et4.16.21_1544_openshiftpour les travailleurs de RHEL. - Puis-je installer le module complémentaire OpenShift Data Foundation dans des clusters Satellite ?
- Non. Le module complémentaire de cluster est disponible uniquement pour les clusters Classic et VPC.
- Comment installer OpenShift Data Foundation sur Satellite?
- Vous pouvez installer ODF sur Satellite à l'aide de l'un des modèles de stockage Satellite. Pour plus d'informations, voir la documentation de stockageSatellite.
odf-local: Choisissez ce modèle lorsque vous disposez d'un stockage local disponible pour vos noeuds worker. Si vos volumes de stockage sont visibles lors de l'exécution delsblk, vous pouvez utiliser ces disques lors du déploiement d'ODF s'ils sont bruts et non formatés.odf-remote: choisissez ce modèle si un pilote CSI est installé dans votre cluster. Par exemple, le piloteazuredisk-csi-driver. Vous pouvez utiliser le pilote CSI pour mettre à disposition des volumes de stockage de manière dynamique lors du déploiement d'ODF.
Pour un aperçu complet des caractéristiques et des avantages, voir OpenShift Data Foundation.
Présentation de l'architecture
Examinez le diagramme et le tableau suivants pour en savoir plus sur OpenShift Data Foundation.
![Architecture](images/ODF_components.svg "Architecture ODF* Architecture ODF* " caption-side="bottom"}"){: caption="
| Nombre | Composant ODF | Description |
|---|---|---|
| 1 | Classes de stockage OpenShift Data Foundation | Lorsque vous déployez ODF, l'opérateur ODF crée des classes de stockage de fichiers, de blocs et d'objets dans votre cluster. Référencez ces classes de stockage dans vos réservations de volume persistant (PVC) et pour réclamer du stockage pour vos applications. |
| 2 | Stockage de bloc OSD | Ce type d'unité fournit un espace de stockage des applications dans votre cluster. Chaque unité OSD est une unité de stockage par blocs brut qui peut être un disque local sur votre noeud worker ou mise à disposition de manière dynamique
lorsque vous déployez ODF. Dans les clusters de VPC, vos unités de stockage par blocs OSD sont mises à disposition de manière dynamique à l'aide du pilote Block Storage for VPC. Dans les clusters Satellite, vous pouvez utiliser des volumes
locaux sur vos noeuds worker ou mettre à disposition de manière dynamique des unités de stockage par blocs à l'aide d'un pilote de stockage par blocs qui prend en charge la mise à disposition dynamique. Dans les clusters classiques,
les unités par blocs OSD sont des disques locaux sur vos noeuds worker. Lorsque vous déployez ODF, chaque unité est montée par un pod OSD. Le stockage total disponible pour vos applications est égal à la valeur osdSize multipliée
par numOfOsd. |
| 3 | Pods OSD (Object Storage Daemon) | Les pods OSD gèrent le placement et la réplication des données sur vos unités de stockage. |
| 4 | Pods de surveillance (Mon) | Les pods de surveillance conservent une mappe de votre cluster de stockage OpenShift Data Foundation et surveillent l'état de santé du cluster de stockage. |
| 5 | Unités de stockage par blocs de surveillance | Les unités de stockage par blocs de surveillance sont les unités de stockage sous-jacentes des pods de surveillance. Chaque unité de surveillance est une unité de stockage par blocs brut qui peut être un disque local sur votre noeud worker ou mise à disposition de manière dynamique lorsque vous déployez ODF. Chaque unité fournit un espace de stockage à un pod de surveillance. |
Présentation de la passerelle Multicloud Object Gateway
Le Multicloud Object Gateway est constitué de l'outil open source NooBaa et est un composant de OpenShift Data Foundation. Avec la passerelle Multicloud Object Gateway, vous pouvez gérer des objets et des compartiments entre des fournisseurs de cloud.
| Nombre | Composant de la passerelle Multicloud Object Gateway | Description |
|---|---|---|
| 1 | Magasin de sauvegarde | Les magasins de sauvegarde sont des compartiments de stockage d'objets compatibles s3. Dans la passerelle Multicloud Object Gateway, vos magasins de sauvegarde peuvent se trouver dans n'importe quel environnement de cloud, quel que soit le fournisseur. Vous pouvez connecter plusieurs magasins de sauvegarde à la passerelle Multicloud Object Gateway. Lorsque vous déployez ODF, le magasin de sauvegarde par défaut utilise les unités de stockage par blocs brut que vous spécifiez pour votre cluster de stockage ODF. Cependant, vous pouvez éventuellement configurer IBM Cloud Object Storage comme magasin de sauvegarde par défaut. |
| 2 | Classe de compartiment | Une classe de compartiment est constituée d'un ou plusieurs magasins de sauvegarde (compartiments) et d'une règle de placement. Vous pouvez configurer des magasins de sauvegarde et des règles de placement pour gérer vos objets dans les emplacements et les clouds. |
| 3 | Classe de stockage | Une classe de stockage de la passerelle d'objets Multicloud est similaire à toute autre classe de stockage Kubernetes dans laquelle elle définit les paramètres de ressource de stockage. Cependant, dans la passerelle Multicloud Object Gateway, lorsque vous créez une classe de stockage, vous spécifiez la classe de compartiment que vous voulez utiliser. En créant une classe de stockage à partir de votre classe de compartiment, vous pouvez rendre vos ressources de passerelle Multicloud Object Gateway disponibles dans les espaces de noms. |
| 4 | Réclamation de compartiment d'objets (OBC, Object Bucket Claim) | Une réclamation de compartiment d'objets (OBC) est similaire à une réservation de volume persistant (PVC) Kubernetes en ce sens que les développeurs ou les administrateurs de stockage peuvent créer des OBC pour réclamer des ressources de stockage. Lorsque vous créez une OBC, vous spécifiez la classe de stockage que vous voulez utiliser et fournissez éventuellement un nom pour le compartiment d'objets créé dynamiquement. |
| 5 | Secret | Lorsque vous créez une réservation de compartiment d'objet, un secret Kubernetes est également créé dans votre cluster. |
| 6 | ConfigMap | Lorsque vous créez une réservation de compartiment d'objet, un objet ConfigMap est également créé dans votre cluster. |
| 7 | Compartiment d'objets | Un compartiment d'objets est un élément mis à disposition de manière dynamique lorsque vous créez une réclamation de compartiment d'objets (OBC). Le compartiment d'objets condense un ou plusieurs magasins de sauvegarde en une seule ressource. |
| 8 | Application s3 | Une application qui utilise le stockage d'objets. |
| 9 | Référence de secret | Une référence secrète est une référence à un secret de Kubernetes dans votre cluster. Lorsque vous créez une réclamation de compartiment d'objets, NooBaa crée une mappe de configuration et un secret correspondants. Ensuite, vous pouvez référencer le secret et la mappe de configuration dans vos applications sans avoir à inclure directement les données d'identification dans vos applications. |
| 10 | Référence ConfigMap | Une référence de carte de configuration est une référence à une carte de configuration de Kubernetes dans votre cluster. Lorsque vous créez une réclamation de compartiment d'objets, NooBaa crée dynamiquement une mappe de configuration et un secret correspondants. Vous pouvez référencer le secret et la mappe de configuration dans vos applications sans avoir à inclure ces données d'identification dans vos applications. |
| 11 | Ressource d'espace de noms | Une ressource d'espace de noms est un compartiment compatible s3. Une fois que vous avez ajouté des ressources d'espace de noms (compartiments) à votre passerelle Multicloud Object Gateway, vous pouvez référencer ces compartiments en créant un compartiment d'espace de noms utilisable pour lire et écrire à partir d'une ou plusieurs ressources d'espace de noms. |
| 12 | Compartiment d'espace de noms | Un compartiment d'espace de noms réunit une ou plusieurs ressources d'espace de noms dans l'espace de noms NooBaa. Lorsque vous créez un compartiment d'espace de noms, vous pouvez spécifier des règles de lecture ou d'écriture sur les ressources d'espace de noms que vous avez configurées dans votre passerelle Multicloud Object Gateway. Par exemple, vous pouvez lire à partir de deux compartiments de différents fournisseurs de cloud et écrire dans un troisième compartiment dans un autre environnement de cloud distinct. |
| 13 | Clé d'accès de compartiment d'espaces de noms | La clé d'accès peut être utilisée pour accéder à votre compartiment d'espaces de noms. Les compartiments d'espaces de noms peuvent inclure plusieurs ressources d'espace de noms issues de différents fournisseurs de cloud ou de compartiments sur site. La clé d'accès et la clé secrète du compartiment d'espaces de noms sont utilisées dans vos applications s3 pour configurer l'accès à votre compartiment d'espaces de noms qui définit ensuite les règles de lecture et d'écriture dans les ressources d'espace de noms que vous configurez. |
| 14 | Clé secrète de compartiment d'espaces de noms | La clé secrète est utilisée pour accéder à votre compartiment d'espaces de noms. Les compartiments d'espaces de noms peuvent inclure plusieurs ressources d'espace de noms issues de différents fournisseurs de cloud ou de compartiments sur site. La clé d'accès et la clé secrète du compartiment d'espaces de noms sont utilisées dans vos applications s3 pour configurer l'accès à votre compartiment d'espaces de noms qui définit ensuite les règles de lecture et d'écriture dans les ressources d'espace de noms que vous configurez. |
| 15 | Règle de placement | Lorsque vous créez une classe de compartiment, vous devez spécifier une règle de placement. Les règles de placement définissent comment vos données sont écrites dans vos magasins de sauvegarde. Une règle de placement Mirror met les objets en miroir dans les magasins de sauvegarde de votre classe de compartiment et une règle de placement Spread répartit les objets entre les magasins de sauvegarde de votre classe de compartiment. |
Prise en charge des fonctions par type de facturation
| Prise en charge des fonctions | Essentials | A l'avance |
|---|---|---|
| Stockage par blocs | Oui | Oui |
| Stockage des fichiers | Oui | Oui |
| Object Storage | Oui | Oui |
| Node et résilience du disque | Oui | Oui |
| Automatisation basée sur l'opérateur | Oui | Oui |
| Compression | Oui | Oui |
| Instantanés locaux et clonage | Oui | Oui |
| Chiffrement de base à l'échelle du cluster | Oui | Oui |
| Chiffrement avancé avec KMS | Non | Oui |
| Reprise après incident régionale avec réplication | Non | Oui |
| Clusters étendus-Haute disponibilité Metro et reprise après incident | Non | Oui |
| Multi-cluster-Metro haute disponibilité et reprise après incident | Non | Oui |
Meilleures pratiques
Passez en revue les sections suivantes pour connaître les meilleures pratiques lors de l'installation et de la gestion d'ODF.
Planification
- Planifiez la répartition des nœuds de travail
- Pour garantir la haute disponibilité, répartissez le cluster ODF entre les domaines de défaillance. Cette distribution permet de minimiser l'impact des défaillances de noeud et de maintenir la stabilité globale du cluster.
- Respect des spécifications minimales de noeud worker
- Les noeuds worker qui utilisent ODF doivent disposer de 16 vCPUs et de 64GB de mémoire RAM ou supérieure. Pour les clusters IBM Classic, la version recommandée est
mb4c.32x384.3.8tb.ssdou supérieure. - Conserver un hôte de secours pour la haute disponibilité
- Pour garantir une haute disponibilité et minimiser les temps d'arrêt en cas de défaillance d'un hôte, il est conseillé de toujours conserver un hôte de secours.
- Respecter les recommandations relatives au nombre d'unités de stockage par noeud
- Prévoyez moins de neuf unités de stockage par noeud. Cela permet d'éviter les goulots d'étranglement potentiels et d'améliorer l'efficacité de l'accès et de l'extraction des données.
- Utiliser les tailles et les nombres d'unités de stockage recommandés
- Lors du déploiement du stockage local, utilisez des tailles de disque inférieures ou égales à 4 TiB. Il est important de s'assurer que tous les disques du cluster, sur tous les noeuds de stockage, ont la même taille et le même type pour une utilisation optimale du stockage. Utilisez des OSD d'au moins 512Gi
- Augmentation à l'aide du facteur de réplication par défaut et de la configuration de noeud de stockage
- Dans OpenShift Data Foundation (ODF), le facteur de réplication est défini sur 3 par défaut. Lorsque vous ajoutez de la capacité, prévoyez d'ajouter des noeuds de stockage en multiples de 3.
- Choisissez la configuration adaptée à vos besoins: Stockage à distance et stockage local
- Si vous avez des besoins de stockage plus faibles ou que vous utilisez des instances de serveur virtuel, le stockage à distance peut être une option pratique et rentable. Toutefois, si vous avez des besoins importants en matière de stockage, un cluster bare metal ou un stockage haute performance avec une faible latence du réseau, il serait plus approprié d'utiliser le stockage local.
- Simplifiez votre déploiement en utilisant la fonction de découverte automatique
- Dans les {: tag-classic-inf} [classiques*] ou les environnements avec stockage local, tirez parti de la fonction de découverte automatique pour identifier et configurer automatiquement les disques de stockage disponibles dans votre cluster pour ODF. Cette option élimine la nécessité d'une sélection manuelle des disques. A moins qu'il n'existe des exigences de disque spécifiques pour la mise à disposition d'ODF, l'utilisation de la fonction de reconnaissance automatique rationalise le processus de déploiement et réduit le risque d'erreurs de configuration.
- Utiliser des classes de stockage Metro pour les installations ODF sur le stockage distant
- Lorsque vous effectuez une installation ODF qui utilise un stockage distant, veillez à utiliser une classe de stockage dont le
VolumeBindingModeestWaitForFirstConsumerqui retarde la création du Block Storage jusqu'à ce que le premier pod qui utilise ce stockage soit prêt à être planifié. - Dimensionner votre déploiement
- Pour une analyse détaillée des exigences de stockage, l'outil de dimensionnement vous permet de déterminer la capacité de stockage requise. Vous pouvez également utiliser l'outil de dimensionnement Red Hat officiel
- Configuration de sauvegardes périodiques
- Il est essentiel d'effectuer des sauvegardes périodiques du cluster ODF pour assurer la protection des données et faciliter leur récupération en cas de sinistre. Sans sauvegardes régulières, la récupération de données à partir d'un événement catastrophique devient beaucoup plus difficile et peut entraîner une perte de données permanente.
Déploiement
- Prévoyez d'utiliser des noeuds de stockage dédiés
- Dans les scénarios avec des charges de travail importantes, utilisez des noeuds de stockage dédiés pour ODF. En séparant les opérations des noeuds de stockage, vous pouvez améliorer les performances et l'évolutivité de votre infrastructure de stockage.
- Configuration de la surveillance régulière de la console Red Hat
- La console Red Hat fournit des informations précieuses sur l'état et les performances de votre environnement ODF. Il est recommandé de surveiller régulièrement la console pour être informé de tout problème potentiel. La console déclenche des alertes chaque fois que des problèmes sont détectés avec ODF, ce qui vous permet de prendre des mesures proactives.
- Traiter rapidement les avertissements de capacité
- Lorsque des avertissements de capacité sont émis, il est important de les traiter rapidement. Le fait d'ignorer ou de retarder l'action sur ces avertissements peut entraîner des contraintes de capacité de stockage et des interruptions potentielles de vos charges de travail. Traitez les avertissements de capacité comme une opportunité d'évaluer vos besoins de stockage et de prendre les mesures appropriées pour atténuer les problèmes potentiels.
Extension de capacité
- Comprendre vos options d'extension de capacité
- Deux options sont disponibles pour l'extension de capacité dans ODF. La première option consiste à augmenter la capacité en ajoutant d'autres objets OSD (Object Storage Daemons) sur des noeuds existants au sein du cluster. Cela permet d'utiliser les ressources disponibles pour étendre la capacité de stockage. La deuxième option consiste à étendre la capacité en ajoutant de nouveaux noeuds au cluster. Une fois le nombre d'OSD augmenté, les OSD sont automatiquement mis à disposition sur les noeuds nouvellement ajoutés.
Mettre à jour
- Effectuer des diagnostics d'intégrité en remplaçant les noeuds
- Evitez de remplacer un noeud d'archivage si ODF n'est pas dans un état sain. Avant de procéder au remplacement de noeud, vérifiez toujours l'état de santé d'ODF. Essayez de résoudre les problèmes avant de remplacer le noeud défaillant.
- Gardez votre environnement à jour
- Conservez la version de votre cluster mise à jour vers la version par défaut ou la version la plus récente disponible. Le fait de rester à jour avec la version du cluster vous permet d'optimiser les dernières fonctionnalités et de maintenir la compatibilité avec d'autres composants de votre environnement.
- Effectuer des mises à jour ODF après les mises à niveau de cluster
- Mettez toujours à niveau le maître cluster et le noeud worker en premier, puis procédez à la mise à niveau d'ODF. Une fois la mise à niveau du cluster terminée, il est essentiel de mettre également à jour ODF. Bien qu'ODF prenne en charge à la fois la version de cluster en cours (n) et la version de cluster suivante (n+1), conservez la version ODF identique à la version de cluster. Cet alignement assure une compatibilité optimale.
- Mise à niveau séquentielle des noeuds de stockage
- Lors de la mise à niveau de vos noeuds de stockage, il est recommandé d'effectuer les mises à niveau une par une. Cette approche séquentielle vous permet de vérifier le statut d'ODF après chaque mise à niveau de noeud et de vous assurer que votre infrastructure de stockage reste saine tout au long du processus. En mettant à niveau les noeuds individuellement, vous pouvez surveiller de près l'impact de chaque mise à niveau sur ODF et identifier et résoudre rapidement les problèmes qui peuvent se produire.
Récupération
- Remplacer les hôtes défaillants
- En cas de sinistre local, il est recommandé de remplacer un hôte de cluster malsain par un hôte sain.
- Suivez la documentation pour récupérer les OSD
- Lorsqu'un démon OSD (Object Storage ) tombe en panne dans OpenShift Data Foundation (ODF), il est important de suivre les étapes recommandées pour la reprise. La documentation fournie à partir d' IBM Cloud Platform fournit des instructions détaillées sur la façon de récupérer un OSD dans de telles situations.
Désinstallation et suppression
- Suppression de pods et de volumes persistants
- Lors de la suppression de ressources utilisant des classes de stockage ODF, il est important de suivre la procédure recommandée. Supprimez toujours les pods et les volumes persistants associés créés à l'aide de classes de stockage OF avant de procéder à la suppression d'autres ressources.
- Suivez l'ordre de nettoyage correct
- Lors de la mise hors service ou du retrait d'ODF de votre cluster, veillez à suivre la documentation lors du nettoyage des ressources. Commencez par supprimer la ressource
ocscluster, qui est responsable de la gestion de l'ODF. Une fois la ressourceocsclustersupprimée, supprimez le module complémentaire ODF de la console IBM. Le fait de suivre cette séquence garantit un retrait harmonieux et approprié d'ODF de votre cluster, ce qui permet d'éviter tout problème ou conflit potentiel.
Traitement des incidents
- Passez en revue les alertes et les seuils de capacité
- ODF génère des alertes de capacité lorsque la capacité de stockage du cluster atteint certains seuils. Ces seuils sont fixés à 75% (quasi-pleine) et à 85% (pleine) de la capacité totale. Ces alertes indiquent que la capacité de stockage approche de ses limites et nécessitent une attention particulière.
- Passez en revue les problèmes communs
- Lorsque vous rencontrez des problèmes avec OpenShift Data Foundation (ODF), il est utile de consulter les dossiers d'exploitation disponibles qui fournissent des conseils pour le traitement des incidents courants. Les dossiers d'exploitation contiennent une liste complète des problèmes connus et des solutions correspondantes pour ODF.
Déploiement d'OpenShift Data Foundation
Passez en revue les options de déploiement de votre fournisseur d'infrastructure.
- Clusters de cloud privé virtuel (VPC, Virtual Private Cloud)
- Vous pouvez déployer ODF en utilisant le provisionnement dynamique avec Block Storage for VPC ou en utilisant des disques locaux sur des travailleurs en métal nu. Pour plus d'informations, voir Déploiement d'OpenShift Data Foundation sur des clusters de VPC.
- Clusters Satellite
- Si vous souhaitez déployer ODF sur des clusters Satellite, vous pouvez utiliser le modèle de stockage Satellite. Pour plus d'informations, voir les liens suivants.
- Déploiement du modèle OpenShift Data Foundation pour des disques distants mis à disposition de manière dynamique.
- Déploiement du modèle OpenShift Data Foundation pour des disques locaux.
- Clusters classiques
- Vous pouvez déployer ODF à l'aide de disques locaux sur vos noeuds worker bare metal. Pour plus d'informations, voir Déploiement d'OpenShift Data Foundation sur des clusters classiques.