Guide de survie Rook et Ceph
Le principe de base des conteneurs est qu’ils sont conçus sans états, mais les données doivent tout de même être stockées et être accessibles à certains services. Vous avez donc besoin d’une solution qui préserve les données en cas de redémarrage de conteneurs.
Les demandes de volume persistant (Persistent Volume Claims ou PVC) sont les solutions recommandées pour la gestion d’applications à états dans Kubernetes. Avec une PVC, un pod peut faire une requête et se connecter aux volumes puisque ceux-ci existent indépendamment du cycle de vie du pod enfermant.
Les PVC offrent l’avantage de séparer les Ops du Dev. Les administrateurs infonuagiques peuvent approvisionner les volumes. Les développeurs peuvent faire une requête pour ces volumes sans connaître les fournisseurs à l’arrière-plan.
Voici les composantes d’une PVC.
- Les demandes de volume persistant (Persistent Volume Claims) désignent une requête de stockage faite par un pod. Les PVC sont montées de façon dynamique dans le pod qui fait la requête et seront utilisées en tant que volume.
- Les volumes persistants (Persistent Volumes ou PV) sont les volumes spécifiques approvisionnés manuellement par les administrateurs ou dynamiquement par une classe de stockage. Les PV ne sont pas liés à un pod en particulier et sont gérés par Kubernetes.
- Les classes de stockage permettent l’allocation dynamique de volumes et de PV. Les classes sont définies par les administrateurs.
- Les stockages physiques désignent les volumes comme tels sur lesquels il est possible de connecter et d’être monté.
Les systèmes de stockage distribués sont un moyen efficace de résoudre les ensembles à états hautement disponibles. Ceph est un système de stockage distribué qui, au cours des dernières années, a capté de plus en plus l’attention. Rook est un orchestrateur pour un ensemble divers de solutions de stockage, incluant Ceph. Rook simplifie le déploiement de Ceph dans une grappe Kubernetes.
La liste des entreprises qui utilisent Rook avec Ceph en production est en croissance, spécialement pour les entreprises qui déploient sur place, parmi celles-ci, CENGN, Gini, RPR et plusieurs autres qui en sont à l’étape d’évaluation.
Qu’est-ce que Ceph ?
Ceph est un système de stockage distribué extrêmement évolutif et hautement performant sans aucun point de défaillance. Ceph est un système de logiciel distribué (Software Distributed System ou SDS), ce qui signifie qu’il peut être exploité sur n’importe quel matériel conforme à ses exigences.
Ceph est fait de nombreuses composantes :
- Les moniteurs Ceph (MON) sont responsables de la formation de quorums de grappes. Tous les nœuds de grappes se rapportent aux nœuds moniteurs et partagent l’information à propos de changement dans leur état.
- Les appareils de stockage d’objets Ceph (OSD) sont responsables du stockage d’objets sur des systèmes locaux de fichiers et d’en fournir l’accès sur le réseau. Habituellement, un deamon OSD est lié à un disque physique dans votre grappe. Les clients de Ceph interagissent directement avec les appareils de stockage d’objet.
- Le Gestionnaire Ceph (Ceph Manager ou MGR) offre une surveillance supplémentaire en plus d’interfaces vers une surveillance et des systèmes de gestion externes.
- Le stockage d’objet distribué fiable et autonome (Reliable Autonomic Distributed Object Stores ou RADOS) est au cœur des grappes de stockage Ceph. Cette couche fait en sorte que les données stockées demeurent toujours constantes et qu’elles effectuent, entre autres, des répliques, des détections de failles et des reprises après celles-ci.
Pour lire ou écrire des données, vers une grappe ou d’une grappe Ceph, un client doit d’abord contacter les Ceph Mon afin d’obtenir la copie la plus récente de sa carte de grappes (cluster map). Celle-ci contient la topologie des grappes ainsi que les lieux de stockage des données. Les clients de Ceph utilisent la carte pour trouver les appareils (OSD) avec lesquels interagir et initier une connexion avec l’appareil (OSD) associé.
Qu’est-ce que Rook ?
Rook est un opérateur qui gère pour vous vos grappes Ceph. Rook utilise des définitions de ressources sur mesure (Custom Resource Definitions ou CRD) et des contrôleurs sur mesure pour déployer et gérer des ressources sur mesure, comme des grappes Ceph.
Rook est fait de nombreuses composantes :
- L’opérateur Rook se trouve au cœur de Rook.L’opérateur Rook est un simple conteneur qui initialise automatiquement la grappe de stockage et surveille les deamons de stockage afin d’assurer que les grappes de stockage restent saines.
- Les agents Rook fonctionnent sur chaque nœud de stockage et configurent un module d’extension FlexVolume qui s’intègre à la structure de contrôleur de volume de Kubernetes. Les agents s’occupent de toutes les opérations de stockage comme d’attacher les appareils de stockage de réseau, de monter les volumes sur les hôtes et de formater le système de fichier.
- Rook Discovers détecte les appareils de stockage attachés au nœud de stockage.
Rook déploie aussi des deamons MON, OSD et MGR pour les grappes Ceph comme pods Kubernetes.
L’opérateur Rook vous permet de créer et de gérer vos grappes de stockage avec des CRD. Chaque type de ressource à son propre CRD défini.
- Une grappe Rook fournit les paramètres de la grappe de stockage afin de servir les systèmes de blocs, de stockage d’objets et de fichiers partagés. Chaque grappe contient de nombreux bassins.
- Un bassin gère le stockage de sauvegarde pour un stock en mode bloc.. Les bassins sont aussi utilisés à l’interne par le stockage d’objets et de fichiers.
- Un système de fichier offre le stockage partagé pour de nombreux pods Kubernetes.
A File System provides shared storage for multiple Kubernetes pods.
Comment déployer Rook dans Kubernetes ?
Dans ce guide, nous allons présenter les étapes à suivre pour déployer Rook dans la même grappe Kubernetes qu’un client consommateur de stockage. Comme Ceph exige de l’espace supplémentaire pour stocker les données, il est recommandé d’avoir un ensemble réservé de nœuds de stockage.
Prérequis
- Helm
- Grappe Kubernetes avec contrôle d’accès basé sur les rôles (CABR).
Configuration de disque
Ce guide assume les disques non formatés sur les nœuds de stockage. Afin de maximiser leur performance, vous devez localiser le Write Ahead Log (WAL) sur un appareil différent (non couvert dans cet article).
Configurer FlexVolume (si nécessaire)
Les agents Rook utilisent FlexVolume afin de s’intégrer à Kubernetes pour les opérations de stockage performantes. Pour ce faire, les agents Rook déploient le pilote FlexVolume de Rook dans un répertoire sur chaque nœud.
Le répertoire FlexVolume par défaut est, dans certains cas, à lecture seule, comme Rancher et CoreOS. Dans ce cas-ci, le Kubelet doit être configuré pour utiliser un différent répertoire sur lequel on peut écrire.
Si vous utilisez Rancher Kubernetes Engine (RKE), configurez le kubelet comme suit et exécutez `rke up` pour l’appliquer.
kubelet:
image: ""
extra_args:
volume-plugin-dir: /usr/libexec/kubernetes/kubelet-plugins/volume/exec
extra_binds:
- /usr/libexec/kubernetes/kubelet-plugins/volume/exec:/usr/libexec/kubernetes/kubelet-plugins/volume/exec
Installer l’opérateur Rook
Ajoutez le dépôt « Rook Charts » à Helm
helm repo add rook-stable https://charts.rook.io/stable
Installer l’opérateur Rook (v 0.9.3 au moment d’écrire ceci)
helm install --name rook --namespace rook-ceph-system rook-stable/rook-ceph
$ kubectl get po -n rook-ceph-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
rook-ceph-agent-gwl8s 1/1 Running 0 35d 10.212.144.51 coo-r1-k8s-worker-st-01
rook-ceph-agent-lqkjl 1/1 Running 0 35d 10.212.144.52 coo-r1-k8s-worker-st-02
rook-ceph-agent-x66sw 1/1 Running 0 35d 10.212.144.53 coo-r1-k8s-worker-st-03
rook-ceph-operator-7d44ddfdcb-q5chh 1/1 Running 0 35d 10.244.8.3 coo-r1-k8s-worker-st-03
rook-discover-fmqrd 1/1 Running 0 35d 10.244.7.5 coo-r1-k8s-worker-st-01
rook-discover-jlsv9 1/1 Running 0 35d 10.244.6.3 coo-r1-k8s-worker-st-02
rook-discover-vt7mk 1/1 Running 0 35d 10.244.8.4 coo-r1-k8s-worker-st-03
Le tableau helm (Helm Chart) déploie, entre autres, les pods reliés à Rook (rook-operator, rook-discover and rook-agent) ainsi qu’une CustomResourceDefinition pour une grappe Ceph. Le pod de découverte exécute un script découverte pour localiser les appareils de stockage attachés aux nœuds de stockage Kubernetes.
Veuillez noter que tous les pods dans le système rook-ceph doivent être exécutés ou complétés sans redémarrage ou erreurs avant de procéder à l’étape suivante.
Créer une grappe Ceph gérée par Rook
L’étape suivante est de créer une grappe Ceph de l’arborescence des sources « Rook ». Cliquez ici pour voir le clone git. Au niveau cluster/exemples/kubernetes/ceph, inspectez et modifiez
cluster.yaml
selon vos préférences. La grappe CRD définit les paramètres désirés pour une grappe de stockage. Exécutez simplement la commande suivante pour initialiser une grappe rook :
kubectl create -f cluster.yaml
Afin de confirmer que notre grappe Rook fonctionne, vérifions les nœuds exécutés sous le namespace rook-ceph :
$ kubectl get po -n rook-ceph -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE rook-ceph-mgr-a-bf78cdcb8-q4gpz 1/1 Running 0 35d 10.244.7.7 coo-r1-k8s-worker-st-01rook-ceph-mon-a-755d985488-72kzh 1/1 Running 0 35d 10.244.7.6 coo-r1-k8s-worker-st-01 rook-ceph-mon-b-845c97f94b-h5jlp 1/1 Running 0 35d 10.244.6.4 coo-r1-k8s-worker-st-02 rook-ceph-mon-c-68b495d97d-m524q 1/1 Running 0 35d 10.244.8.7 coo-r1-k8s-worker-st-03 rook-ceph-osd-0-56b7b86b5b-kz882 1/1 Running 0 35d 10.244.7.9 coo-r1-k8s-worker-st-01 rook-ceph-osd-1-6d9558b6bd-xlkzf 1/1 Running 0 35d 10.244.6.6 coo-r1-k8s-worker-st-02 rook-ceph-osd-2-56bf4b6c64-2p9rp 1/1 Running 0 35d 10.244.8.9 coo-r1-k8s-worker-st-03 rook-ceph-osd-3-86ccf5d69f-xzjmz 1/1 Running 0 35d 10.244.7.10 coo-r1-k8s-worker-st-01 rook-ceph-osd-4-6f469fc877-bt799 1/1 Running 0 35d 10.244.6.7 coo-r1-k8s-worker-st-02 rook-ceph-osd-5-6549cdf949-qbvnh 1/1 Running 0 35d 10.244.7.11 coo-r1-k8s-worker-st-01 rook-ceph-osd-6-7f56d8cf95-qgd8p 1/1 Running 0 35d 10.244.6.8 coo-r1-k8s-worker-st-02 rook-ceph-osd-7-55b6c5c8df-dnp4p 1/1 Running 0 35d 10.244.8.11 coo-r1-k8s-worker-st-03 rook-ceph-osd-8-d6df7694-w2psw 1/1 Running 0 35d 10.244.8.10 coo-r1-k8s-worker-st-03 rook-ceph-osd-prepare-coo-r1-k8s-worker-st-01-zbs6m 0/2 Completed 0 35d 10.244.7.8 coo-r1-k8s-worker-st-01 rook-ceph-osd-prepare-coo-r1-k8s-worker-st-02-sr2dm 0/2 Completed 0 35d 10.244.6.5 coo-r1-k8s-worker-st-02 rook-ceph-osd-prepare-coo-r1-k8s-worker-st-03-zzqmq 0/2 Completed 0 35d 10.244.8.8 coo-r1-k8s-worker-st-03 rook-ceph-tools-cb5655595-vq4vj 1/1 Running 0 35d 10.212.144.53 coo-r1-k8s-worker-st-03
Vous verrez que Rook commencera à déployer quelques
mon
ainsi que des pods
osd-prepare
. Les pods
rook-ceph-osd-prepare
préparent le
osd
en formatant le disque et en ajoutant les pods osd dans la grappe.
Rook vient aussi avec un conteneur
toolkit
qui a toute la suite de clients de Ceph pour le débogage et les tests rook. Après avoir exécuté
kubectl create -f toolkit.yaml
dans la grappe, utilisez la commande suivante pour entrer dans le pod :
kubectl -n rook-ceph exec -it $(kubectl -n rook-ceph get pod -l "app=rook-ceph-tools" -o jsonpath='{.items[0].metadata.name}') bashAstuces pour la configuration de grappes :
Définir
mon.count
avec un nombre impair plus grand que 3.
Définir les limites de ressources pour les composantes Ceph :
mgr: limits: cpu: "500m" memory: "1024Mi" requests: cpu: "500m" memory: "1024Mi" mon: limits: cpu: "1" memory: "1024Mi" requests: cpu: "500m" memory: "1024Mi" osd: limits: cpu: "1" memory: "2048Mi" requests: cpu: "500m" memory: "1024Mi"
Je recommande de rendre tous les nœuds de stockage aussi homogènes que possible, pour qu’ils aient tous la même UCT, la même mémoire vive et le même disque. Cela permet d’utiliser la fonctionnalité deviceFilter :
storage: useAllNodes: true useAllDevices: false deviceFilter: sd[a-z]
Qui effectue la recherche de tous les appareils possédant le regex
/dev/sd[a-z]
.
Création d’un bassin de répliques Ceph et d’une classe de stockage Kubernetes
Le bassin CRD défini les paramètres désirés pour un bassin. Rook offre deux mécanismes pour assumer les pertes d’OSD : la réplication et le code d’effacement. La réplication est le choix par défaut, cela signifie que chaque objet est répliqué sur de nombreux disques, selon la taille spec.replicated.size. Veuillez noter qu’il faut préciser une taille de réplication qui convient à votre cas d’utilisation. Je recommande au moins 2 pour la non-production et 3 pour la production, mais cela dépend évidemment de la taille de votre grappe.
Le code d’effacement (erasure coding ou EC) est une alternative qui fait épargner de l’espace. Le code d’effacement brise les données en fragments n (spec.erasureCoded.dataChunks), ajoute des fragments de code k (spec.erasureCoded.codingChunks) et stocke des fragments n+k d’une manière distribuée sur les disques. Dans ce cas-ci, Ceph peut tolérer la perte d’OSD k.
# pool with replication enabled
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
name: replicated-metadata-pool
namespace: rook-ceph
spec:
replicated:
size: 2
---
# pool with EC enabled
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
name: ec-data-pool
namespace: rook-ceph
spec:
erasureCoded:
dataChunks: 2
codingChunks: 1
Dans ce guide, nous allons nous fier à la réplication pour maintenir les données redondantes.
Les classes de stockage sont au cœur de l’approvisionnement dynamique des volumes persistant dans Kubernetes. Voici un exemple d’une classe de stockage pour le stockage en bloc de Ceph.
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: rook-ceph-block provisioner: ceph.rook.io/block parameters: # The replicated pool as the `blockPool` parameter blockPool: replicated-metadata-pool # The erasure coded pool must be set as the `dataBlockPool` parameter below. dataBlockPool: ec-data-pool clusterNamespace: rook-ceph
Pour créer un bassin de réplique Ceph et une classe de stockage, il faut simplement appliquer le manifeste
storageclass.yaml
qui se trouve au même endroit que
cluster.yaml
.
kubectl create -f storageclass.yaml
Tester le stockage
Pour tester votre configuration, créez une PVC en utilisant le nom de la classe de stockage que vous avez créée à l’étape précédente.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
storageClassName: rook-ceph-block
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Vérifiez l’état du PVC pour s’assurer qu’il est dans un état ‘Bounded’.
$ kubectl get pvc NAMESPACE NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE default mysql-pv-claim Bound pvc-f1af6df6-474a-11e9-8360-02006e76001e 8Gi RWO rook-ceph-block 1m
Commandes Ceph courantes
Une fois dans le pod ‘toolbox’, vous pouvez interagir avec les grappes Ceph et exécutez les commandes. Voici une liste de commandes utiles afin de vérifier l’état de votre grappe.
État général de la grappe
$ ceph status
cluster:
id: 62e69dc1-efb5-42d9-a7bc-1ea6cfbd467f
health: HEALTH_OK
services:
mon: 3 daemons, quorum c,a,b
mgr: a(active)
osd: 9 osds: 9 up, 9 in
data:
pools: 1 pools, 100 pgs
objects: 236 objects, 406 MiB
usage: 10 GiB used, 1.7 TiB / 1.8 TiB avail
pgs: 100 active+clean
io:
client: 38 KiB/s wr, 0 op/s rd, 3 op/s wr
État de santé détaillé
Utile pour identifier les groupes en mauvais états qui ont besoin d’être réparés.
$ ceph health detail HEALTH_OK
État de tous les OSD
$ ceph osd status +—-+————————-+——-+——-+——–+———+——–+———+———–+ | id | host | used | avail | wr ops | wr data | rd ops | rd data | state | +—-+————————-+——-+——-+——–+———+——–+———+———–+ | 0 | coo-r1-k8s-worker-st-01 | 1149M | 198G | 0 | 13.6k | 0 | 0 | exists,up | | 1 | coo-r1-k8s-worker-st-02 | 1157M | 198G | 0 | 0 | 0 | 0 | exists,up | | 2 | coo-r1-k8s-worker-st-03 | 1143M | 198G | 0 | 0 | 0 | 0 | exists,up | | 3 | coo-r1-k8s-worker-st-01 | 1128M | 198G | 0 | 0 | 0 | 0 | exists,up | | 4 | coo-r1-k8s-worker-st-02 | 1180M | 198G | 4 | 37.6k | 0 | 0 | exists,up | | 5 | coo-r1-k8s-worker-st-01 | 1169M | 198G | 1 | 12.0k | 0 | 0 | exists,up | | 6 | coo-r1-k8s-worker-st-02 | 1109M | 198G | 0 | 0 | 0 | 0 | exists,up | | 7 | coo-r1-k8s-worker-st-03 | 1160M | 198G | 0 | 1638 | 0 | 0 | exists,up | | 8 | coo-r1-k8s-worker-st-03 | 1143M | 198G | 0 | 3276 | 0 | 0 | exists,up | +—-+————————-+——-+——-+——–+———+——–+———+———–+
Détails du bassin Ceph
$ ceph osd pool ls detail pool 1 ‘replicapool’ replicated size 3 min_size 1 crush_rule 1 object_hash rjenkins pg_num 100 pgp_num 100 last_change 37 flags hashpspool,selfmanaged_snaps stripe_width 0 application rbd removed_snaps [1~3]
Indiquer l’utilisation du bassin et l’utilisation totale
$ rados df POOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR
replicapool 1.4 GiB 575 0 1150 0 0 0 1224 2.4 MiB 1698291 84 GiBtotal_objects 575 total_used 5.6 GiB total_avail 294 GiB total_space 300 GiB
Utiliser la classe de stockage avec les applications ou les Helm charts de Kubernetes.
La plupart, sinon tous les Helm charts ont des options de configuration qui permettent d’outrepasser la classe de stockage. Par exemple :
helm install –name=redis stable/redis
–set master.persistence.storageClass=rook-ceph-block
–set slave.persistence.storageClass=rook-ceph-block
Réinstallation
Réinstallation complète incluant RKE
Clause de non-responsabilité : Les instructions suivantes servent à effacer les données ; il n’est pas recommandé de les exécuter sur la grappe Production.
Rook peut être difficile à réinstaller, car un grand nombre de données sont stockées sur les nœuds de stockage locaux. Si vous utilisez RKE, effacez les données sur les nœuds ouvriers et les nœuds maîtres, puis réinstaller RKE en entier. Pour nettoyer :
# remove rke docker and everything sudo apt -y purge docker-ce
&& sudo apt -y autoremove
&& sudo rm -rf /var/lib/docker
&& sudo rm -rf /opt/*
&& sudo rm -rf /var/lib/rook
&& sudo rm -rf /var/lib/etcd
&& sudo rm -rf /var/lib/cni
&& sudo rm -rf /var/lib/containerd
&& sudo rm -rf /var/lib/calico
&& sudo rm -rf /var/lib/kubelet
&& sudo rm -rf /var/lib/rancher
Ceci supprime toute trace de Docker, Rook, RKE et de leurs composantes.
Si cela fonctionne sur un nœud ouvrier/maître en marche, vous devriez redémarrer après avoir exécuté cette commande, et puis exécuter la commande à nouveau (certains fichiers sont verrouillés lors de processus en exécution), puis procédez à une réinstallation complète, Docker y compris !
Vous allez aussi devoir formater les disques utilisés par Rook/Ceph.
$ sudo fdisk /dev/sdb Welcome to fdisk (util-linux 2.29.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command.Device /dev/sdb already contains a LVM2_member signature. The signature will be removed by a write command.
Device does not contain a recognized partition table. Created a new DOS disklabel with disk identifier 0xa24124a7.
Command (m for help):
Tapez simplement ‘w’ et ‘enter’ ; cela aura pour effet d’écraser la table de partition et de rendre les disques à nouveau prêts à être utilisé par Rook/Ceph. Je recommande de réinitialiser après avoir effacé le disque, afin d’assurer que rien n’est lié ni ne possède d’indicateur fichier ouvert.
Rook seulement
Le fait de supprimer les namespaces rook-ceph et rook-ceph-system peut vous créer des problèmes. Pour démanteler la grappe Ceph :
Supprimez les ressources créées par-dessus la grappe rook (bassin, classe de stockage, PVC, etc.).
kubectl delete -n rook-ceph cephblockpool replicapool kubectl delete storageclass rook-ceph-block
Supprimez la grappe CRD et l’opérateur helm chart.
kubectl -n rook-ceph patch clusters.ceph.rook.io rook-ceph -p ‘{« metadata »:{« finalizers »: []}}’ –type=merge
kubectl -n rook-ceph delete cephcluster rook-ceph
helm delete –purge rook
kubectl delete namespace rook-ceph
Connectez-vous à chaque machine et supprimez
/var/lib/rook
, ou le chemin précisé par le
dataDirHostPath
.
Si vous rencontrez des problèmes, consultez cette page.
Diagnostiques
Réparation de groupe physique
Occasionnellement, l’état de Ceph peut indiquer que les groupes physiques nécessitent des réparations. Pour exécuter cela, connectez-vous dans le pod ‘toolbox’ :
$ ceph health detail HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
Cela indique que le groupe physique 0.6 a besoin de réparation. Pour le réparer :
ceph pg repair 0.6
Cela lancera la réparation qui peut prendre une minute à se compléter. À la suite de cela, l’état ‘health’ devrait être :
HEALTH_OK
Changement de la taille de réplication
Si la taille de réplication n’est pas bien définie, vous pouvez la définir sur un bassin de réplication ; appelé replicapool dans cet exemple. Une fois dans le pod ‘toolbox’ :
ceph osd pool set replicapool size 3 ceph osd pool set replicapool min_size 3
Changements de nombre de groupes physiques
Pour changer la taille du groupe physique pour un bassin de répliques, une fois à l’intérieur du pod ‘toolbox’ :
ceph osd pool set replicapool pg_num 256 ceph osd pool set replicapool pgp_num 256
Rook et Ceph peuvent aider les équipes à trouver des solutions infonuagiques pour le stockage. Pour en apprendre plus sur les outils du DevOps, inscrivez-vous à l’un de nos ateliers pratiques sur le DevOps. Nous offrons des formations publiques, dans une variété de villes, sur Docker, Kubernetes, et sur la surveillance DevOps, puis des formations privées sur un plus grand éventail de sujets dans n’importe quelle ville. Contactez-nous pour savoir comment CloudOps peut aider votre organisation à trouver des solutions DevOps.
Références :
- https://github.com/rook/rook/blob/master/Documentation/ceph-toolbox.md
- http://docs.ceph.com/docs/mimic/rados/troubleshooting/troubleshooting-pg/
- http://docs.ceph.com/docs/jewel/rados/operations/placement-groups/#set-the-number-of-placement-groups
- http://accelazh.github.io/ceph/Ceph-Performance-Tuning-Checklist
- https://github.com/rook/rook/blob/master/Documentation/advanced-configuration.md
- https://github.com/rook/rook/blob/master/Documentation/common-issues.md
- http://docs.ceph.com/docs/giant/rados/troubleshooting/troubleshooting-osd/
