mirroir readonly du Gitit wiki.evolix.org (attention, ne rien commiter/merger sur ce dépôt) https://wiki.evolix.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

877 lines
25 KiB

1 year ago
1 year ago
1 year ago
3 years ago
3 years ago
1 year ago
1 year ago
3 years ago
3 years ago
3 years ago
3 years ago
2 years ago
2 years ago
2 years ago
2 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
3 years ago
2 years ago
1 year ago
  1. ---
  2. categories: cloud storage
  3. title: Howto Ceph
  4. ...
  5. * Documentation : <http://docs.ceph.com>
  6. * Thèse de Sage Weil : <https://ceph.com/wp-content/uploads/2016/08/weil-thesis.pdf>
  7. * Publications sur Ceph : <https://ceph.io/publications/>
  8. * Vidéo "Intro to Ceph" par Sage Weil : <https://youtu.be/PmLPbrf-x9g>
  9. [Ceph](https://ceph.io/) est une plateforme libre de stockage. Historiquement développé par [Sage Weil](https://en.wikipedia.org/wiki/Sage_Weil) à la suite d'une thèse en 2007, Ceph appartient désormais à Red Hat.
  10. Ceph peut également s'apparenter à un « disque distribué auto-réparant » ou encore une sorte de « RAID-NG ». Le principe est de s'appuyer sur des disques répartis au sein de plusieurs ordinateurs reliés en réseau, et d'avoir une tolérance de panne avec réparation rapide et de permettre l'ajout de disques de façon simple.
  11. ## Principes de bases
  12. Ceph permet la répartition d'objets (fichiers, morceaux de fichiers, blocs, etc.) dans un volume (pool) découpé en centaines de morceaux de plusieurs Go (PG). Chaque morceau (PG) est réparti sur 3 disques (OSD) situés dans des ordinateurs distincts.
  13. L'algorithme CRUSH décrit ce découpage et rassemble toutes les informations dans une CRUSH map.
  14. Un cluster Ceph est constitué de démons `osd` pour chaque disque, 3 démons `monitor` et 1 démon `manager`. Si besoin de faire du CephFS il faudra avoir un ou plusieurs démons `mds`, et si besoin d'avoir un accès HTTP REST (compatible Amazon S3) des démons` rgw`.
  15. Pour accéder à un cluster Ceph, un client Ceph peut le faire via RADOS : en mode bloc (RBD), en mode fichers (CephFS) ou en mode HTTP REST compatible Amazon S3 (RGW).
  16. ## Utilisation basique
  17. Voir les infos d'un cluster Ceph :
  18. ~~~
  19. # ceph -w
  20. cluster:
  21. id: c947bfab-ed62-443b-8df2-6e24852a7740
  22. health: HEALTH_OK
  23. services:
  24. mon: 3 daemons, quorum ceph01,ceph02,ceph03
  25. mgr: ceph01(active), standbys: ceph02, ceph03
  26. osd: 12 osds: 12 up, 12 in
  27. data:
  28. pools: 1 pools, 512 pgs
  29. objects: 4.05M objects, 15.3TiB
  30. usage: 30.7TiB used, 34.6TiB / 65.3TiB avail
  31. pgs: 511 active+clean
  32. 1 active+clean+scrubbing+deep
  33. io:
  34. client: 3.33KiB/s wr, 0op/s rd, 0op/s wr
  35. ~~~
  36. ## Installation
  37. On cherche à créer l'architecture suivante où un client interagit avec un cluster Ceph :
  38. ~~~
  39. +-----[ cluster Ceph ]------+
  40. | +-------+ |
  41. | +-> | ceph1 | |
  42. | | +-------+ |
  43. +-------+ | +-------+ | +-------+ |
  44. | cephc | <-> | | cephm | <-+-> | ceph2 | |
  45. +-------+ | +-------+ | +-------+ |
  46. | | +-------+ |
  47. | +-> | ceph3 | |
  48. | +-------+ |
  49. +---------------------------+
  50. cephc : client Ceph
  51. cephm : nœud maitre ou nœud admin
  52. ceph[1-3] : nœud cephs
  53. ~~~
  54. Les données seront stockées sur les nœuds `ceph[123]`. Ces trois machines doivent donc avoir des disques supplémentaires qui seront utilisés par Ceph.
  55. > Le nœud admin peut aussi être comme un nœud à données comme les nœuds `ceph[123]`.
  56. ## Préparation
  57. On suppose ici que :
  58. - chaque machine a été installée sous Debian 9 ;
  59. - `cephm` à un accès SSH à `ceph[123c]`.
  60. Pour la configuration SSH, on aura, pour cephm:
  61. ~~~
  62. $ cat ~/.ssh/config
  63. Hostname ceph1
  64. Host ceph1
  65. User cephuser
  66. Hostname ceph2
  67. Host ceph2
  68. User cephuser
  69. Hostname ceph3
  70. Host ceph3
  71. User cephuser
  72. ~~~
  73. L'utilisateur `cephuser` doit pouvoir exécuter la commande `sudo` sans mot de passe.
  74. > Il est peut-être nécessaire d'ajouter les machines dans le fichier `/etc/hosts` :
  75. >
  76. > ~~~
  77. > X.X.X.X ceph1
  78. > Y.Y.Y.Y ceph2
  79. > Z.Z.Z.Z ceph3
  80. > ~~~
  81. > En réalité seul le nœud maître à besoin de se connecter aux autres nœuds du cluster mais je n'ai pas essayé.
  82. Dans cet exemple, chaque nœud - `ceph1`, `ceph2` et `ceph3` - a un disque supplémentaire à sa disposition. Ce disque contiendra les données à stocker dans le cluster et doit être vide, sans table de partitions et être utilisé comme volume physique :
  83. ~~~
  84. wipefs -a /dev/sdX
  85. pvcreate /dev/sdX
  86. ~~~
  87. > `/dev/sdX` est le volume supplémentaire.
  88. ## Installation
  89. On commence par installer `ceph-deploy`, l'outil qui permet de déployer un cluster Ceph.
  90. ~~~
  91. # apt update && apt install apt-transport-https
  92. # wget https://download.ceph.com/keys/release.asc -O /etc/apt/trusted.gpg.d/ceph.asc
  93. # echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list
  94. # apt update && apt install ceph-deploy
  95. ~~~
  96. > Les commandes précédentes ne sont à exécuter que sur le nœud maître.
  97. Puis, on installe NTP sur l'ensemble des nœuds.
  98. ~~~
  99. # apt install ntp
  100. # timedatectl set-ntp true
  101. ~~~
  102. > Jusqu'à indication du contraire, les commandes qui suivent sont à exécuter sur le nœud maître.
  103. On commence par créer un dossier qui contiendra les fichiers de configuration et les clefs.
  104. ~~~
  105. $ mkdir ceph
  106. $ cd ceph
  107. ~~~
  108. > On peut aussi se placer dans `/etc/ceph`.
  109. On crée le cluster :
  110. ~~~
  111. $ ceph-deploy new ceph1 ceph2 ceph3
  112. ~~~
  113. Ajouter le « public_network » à la configuration de Ceph :
  114. ~~~
  115. $ cat <<eof >>ceph.conf
  116. public_network = X.X.X.0/24
  117. eof
  118. ~~~
  119. Si on souhaite utiliser le cluster pour y installer des VMs, il faut activer le cache RBD :
  120. ~~~
  121. cat <<eof >>ceph.conf
  122. [client]
  123. rbd cache = true
  124. eof
  125. ~~~
  126. On installe les paquets Ceph sur les nœeuds :
  127. ~~~
  128. $ ceph-deploy install --release luminous ceph1 ceph2 ceph3
  129. ~~~
  130. On initialise le moniteur. Cela va créer des fichiers `*.keyring`. On copie ensuite ces fichiers sur tous les nœeuds dans `/etc/ceph` avec la commande `ceph-deploy admin. Un monitor sert à maintenir une carte de l'état du cluster.
  131. ~~~
  132. $ ceph-deploy mon create-initial
  133. $ ceph-deploy admin ceph0 ceph1 ceph2 ceph3
  134. ~~~
  135. On déploie un manager. Celui-ci permet de regrouper l'état du cluster à un seul endroit.
  136. ~~~
  137. $ ceph-deploy mgr create deb1
  138. ~~~
  139. On crée les OSD :
  140. ~~~
  141. $ ceph-deploy osd create --data /dev/sdX deb1
  142. $ ceph-deploy osd create --data /dev/sdX deb2
  143. $ ceph-deploy osd create --data /dev/sdX deb3
  144. ~~~
  145. > On peut lancer la commande suivante pour s'assurer que le cluster fonctionne bien :
  146. >
  147. > ~~~
  148. > $ ssh ceph1 sudo ceph -s | grep HEALTH_OK && echo yes || echo fail
  149. > ~~~
  150. On ajoute des moniteurs afin d'assurer la bonne disponibilité du cluster. Il vaut mieux avoir un nombre impair de moniteurs.
  151. ~~~
  152. $ ceph-deploy mon add deb2
  153. $ ceph-deploy mon add deb3
  154. ~~~
  155. De la même manière, on ajoute des managers. Dans le cas où un manager décide de ne plus fonctionner.
  156. ~~~
  157. $ ceph-deploy mgr create deb2
  158. $ ceph-deploy mgr create deb3
  159. ~~~
  160. Il ne reste qu'à créer un pool et à l'initialiser pour RBD :
  161. ~~~
  162. # ceph osd pool create rbd 128
  163. # ceph osd pool set rbd nodelete true
  164. # ceph osd pool application enable rbd rbd
  165. # rbd pool init rbd
  166. ~~~
  167. > La seconde commande empêche la suppression du pool. Il sera impossible de le supprimer par accident (ou de le supprimer tout court).
  168. Le cluster est prêt. On peut maintenant s'occuper du client.
  169. ## Logs
  170. Tous les logs sont dans `/var/log/ceph`. Chaque service à ses propre log. Par exemple, pour les moniteurs on a `/var/log/ceph/ceph-mon.ceph01.log*`.
  171. ## Client
  172. L'installation du client est analogue à celle des nœuds. On install Ceph sur la machine cliente :
  173. ~~~
  174. # apt install apt-transport-https
  175. # wget https://download.ceph.com/keys/release.asc -O /etc/apt/trusted.gpg.d/ceph.asc
  176. # echo deb https://download.ceph.com/debian-luminous/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list
  177. # apt update && apt install ceph-common
  178. ~~~
  179. Depuis un nœud admin, on copie la configuration du cluster :
  180. ~~~
  181. # ceph-deploy --overwrite-conf config push $MACHINE_CIBLE
  182. # ceph auth export client.libvirt 2> /dev/null | ssh $USER@client 'cat - > ~/ceph.client.libvirt.keyring'
  183. ~~~
  184. De retour sur la machine cliente, on place le fichier de configuration au bon endroit :
  185. ~~~
  186. # cp /home/$USER/ceph.client.libvirt.keyring /etc/ceph
  187. ~~~
  188. Par défault, Ceph passe l'utilisateur ceph.admin. On peut passer en paramètre des commandes rbd et ceph le nom et le fichier qui contient la clef de l'utilisateur. Il est plus simple d'utiliser la variable d'environnement CEPH_ARGS :
  189. ~~~
  190. # CEPH_ARGS='-n client.libvirt -k /etc/ceph/ceph.client.libvirt.keyring'
  191. # export CEPH_ARGS
  192. ~~~
  193. Cet utilisateur n'a que les droits de lecture sur les informations du cluster, comme l'état de santé, et les droit de lecture et d'écriture pour le pool rbd. Il devrait donc être possible de faire :
  194. ~~~
  195. # ceph health
  196. # rbd create $RBD_NAME --size 1G --image-feature layering
  197. # rbd map $RBD_NAME
  198. ~~~
  199. Le block device devrait être disponible dans /dev/rbd/rbd/$RBD_NAME. Happy fdisk!
  200. Si on compte utiliser le block device pour y installer une machine virtuelle, il faut aller à la section [Libvirt](#rbd-et-libvirt). Sinon, il ne reste qu'à le formater puis à le monter :
  201. ~~~
  202. # mkfs.ext4 -m0 /dev/rbd/rbd/foo
  203. # mkdir /mnt/ceph-block-device
  204. # mount /dev/rbd/rbd/foo /mnt/ceph-block-device
  205. # cat <<EOF >>/mnt/ceph-block-device/file
  206. plain text is life
  207. EOF
  208. ~~~
  209. # Gestion des nœuds
  210. ## Redémarrer Ceph
  211. Pour redémarrer tous les services du cluster faire, sur tous les nœuds du cluster :
  212. ~~~
  213. # systemctl stop ceph\*.service ceph\*.target
  214. # systemctl start ceph.target
  215. ~~~
  216. Pour plus de détails : [Operating a Cluster](http://docs.ceph.com/docs/luminous/rados/operations/operating/).
  217. ## Redémarrer un nœud
  218. Si on souhaite redémarrer un des nœuds du cluster, on commence par désactiver le balancing du cluster temporairement. L'objectif est d'empêcher le cluster de répliquer les objects perdus ailleurs. Sur un des nœuds :
  219. ~~~
  220. # ceph osd set noout
  221. # ceph osd set norebalance
  222. ~~~
  223. Sur le nœud à éteindre :
  224. ~~~
  225. # reboot
  226. ~~~
  227. Quand la machine est de nouveau disponible, on vérifie l'état du cluster. Il faut que les pgs soient `active+clean`. Sur un des nœuds :
  228. ~~~
  229. # ceph -s
  230. ~~~
  231. Puis réactiver le balancing du cluster.
  232. ~~~
  233. # ceph osd unset noout
  234. # ceph osd unset norebalance
  235. ~~~
  236. Pour finir, on s'assure que tout va bien :
  237. ~~~
  238. # ceph status
  239. ~~~
  240. # Gestion des comptes utilisateurs
  241. Ceph a un système interne de gestion des utilisateurs. Un utilisateur est représenté par :
  242. - un nom (et un ID) ;
  243. - des permissions ;
  244. - une clef.
  245. Par exemple pour l'utilisateur `client.admin` - l'utilisateur par défaut - l'ID est `admin`, le nom est `client.admin` et la clef et ses permissions sont :
  246. ~~~
  247. $ ceph auth get client.admin
  248. exported keyring for client.admin
  249. [client.admin]
  250. key = ****************************************
  251. caps mds = "allow *"
  252. caps mgr = "allow *"
  253. caps mon = "allow *"
  254. caps osd = "allow *"
  255. ~~~
  256. > On constate naturellement que l'utilisateur `client.admin` a tous les droits sur chacun des éléments du cluster.
  257. Après avoir installé le cluster, `client.admin` est le seul utilisateur et celui par défaut. Si vous vous êtes placé dans `/home/$USER/ceph` pour la mise en place du cluster, les fichiers de configuration et la clef de l'utilisateur `client.admin` s'y trouvent. Cependant, par défaut, les commandes comme `ceph` ou `rbd` cherchent les clefs dans `/etc/ceph`. De ce fait, si on est pas `root` ou que la clef n'est pas dans `/etc/ceph`, Ceph renverra une erreur disant qu'il ne peut pas accéder au cluster. Pour corriger ça, il faut spécifier manuellement l'emplacement de la clef en option :
  258. ~~~
  259. $ ceph -n client.admin -k ~/ceph/ceph.client.admin.keyring health
  260. ~~~
  261. Il est possible de définir des arguments par défaut pour ne pas avoir à tout taper à chaque fois à l'aide de la variable d'environnement `CEPH_ARGS` :
  262. ~~~
  263. $ CEPH_USER_NAME=client.admin
  264. $ export CEPH_ARGS="-n $CEPH_USER_NAME -k $HOME/ceph/ceph.$CEPH_USER_NAME.keyring"
  265. $ ceph health
  266. ~~~
  267. > Depuis peu, il est facultatif de donner l'option `-k` quand l'option `-n` est déjà présente si le fichier de clef de l'utilisateur est présent dans sous cette forme : `/etc/ceph/ceph.$CEPH_USER_NAME.keyring`.
  268. > Il est suffisant de donner la clef avec l'option `-k`, le nom est facultatif.
  269. ## Création
  270. Il y a deux façons de procéder. La première avec `add` et la seconde avec `get-or-create` :
  271. ~~~
  272. $ ceph auth add client.john mon 'allow r'
  273. added key for client.john
  274. $ ceph auth get-or-create client.paul mon 'allow r'
  275. [client.paul]
  276. key = ****************************************
  277. ~~~
  278. La seconde méthode va, en plus de la création de l'utilisateur, afficher sa clef. On peut la récupérer sur la sortie standard ou via l'option `-o` pour l'écrire dans un fichier. De plus, si l'utilisateur existe déjà, c'est la clé déjà existante qui sera imprimée. Si on a utilisé `ceph auth add` pour ajouter l'utilisateur, on pourra récupérer sa clef avec `ceph auth get`.
  279. ## Modification
  280. La commande suivante permet de modifier les droits d'un utilisateur. Cela va *écraser* ses droits actuels.
  281. ~~~
  282. $ ceph auth caps client.john mon 'profile rbd' osd 'profile rbd pool=rbd'
  283. ~~~
  284. ## Suppression
  285. ~~~
  286. $ ceph auth del client.john
  287. ~~~
  288. # Gestion des OSD
  289. ## Remplacement
  290. Identifier la machine sur laquelle se trouve l'OSD :
  291. ~~~
  292. # ceph osd tree
  293. ~~~
  294. Sur la machine NODE, identifier de quel disque physique il s'agit. Avec `lsblk` et `df`. Puis, suivre la procédure :
  295. ~~~
  296. # N=1 # On suppose que l'OSD 1 est down
  297. # ceph osd out osd.$N
  298. # systemctl stop ceph-osd@$N.service
  299. # ceph osd crush remove osd.$N
  300. # ceph auth del osd.$N
  301. # ceph osd rm osd.$N
  302. # mount /var/lib/ceph/osd/ceph-$N
  303. ~~~
  304. On change de disque sur la machine puis :
  305. ~~~
  306. # Y=z
  307. # pvcreate /dev/sd$Y
  308. ~~~
  309. Sur un autre nœud admin :
  310. ~~~
  311. # NODE=servername
  312. # Y=z #
  313. # ceph-deploy osd create --data /dev/sd$Y $NODE
  314. ~~~
  315. ## Suppression
  316. ~~~
  317. OSD=0
  318. ceph osd out $OSD
  319. sudo systemctl stop ceph-osd@$OSD
  320. ceph osd purge $OSD --yes-i-really-mean-it
  321. ~~~
  322. # Gestion des pools
  323. ## Suppression
  324. Par défaut, il est impossible de supprimer un pool. Il y a deux gardes-fous à passer pour permettre la suppression. On s'assure d'abord que le flag « nodelete » est bien à « false » :
  325. ~~~
  326. # ceph osd pool get $POOL_NAME nodelete | grep -q true && ceph osd pool set $POOL_NAME nodelete false
  327. ~~~
  328. Une fois ce flag désactivé, il faut configurer le cluster pour autoriser la suppression d'un pool :
  329. ~~~
  330. # ceph tell mon.* injectargs --mon-allow-pool-delete=true
  331. ~~~
  332. Pour finir, on supprime le pool puis on active à nouveau la sécurité :
  333. ~~~
  334. # ceph osd pool delete $POOL_NAME $POOL_NAME --yes-i-really-really-mean-it
  335. # ceph tell mon.* injectargs --mon-allow-pool-delete=false
  336. ~~~
  337. # RBD
  338. ## Taille
  339. Taille provisionnée :
  340. ~~~
  341. # rbd ls -l
  342. ~~~
  343. Espace alloué *par pool* :
  344. ~~~
  345. ceph df
  346. ~~~
  347. ## RBD et Libvirt
  348. Pour permettre à QEMU/Libvirt de parler à Ceph :
  349. ~~~
  350. # apt install qemu-block-extra
  351. ~~~
  352. Il est possible de faire en sorte que Libvirt parle à Ceph directement. Cela facilite l'allocation de RBD a une machine virtuelle. On peut déjà créer un RBD depuis le client :
  353. ~~~
  354. # qemu-img create -f rbd rbd:rbd/vm0-data 8
  355. ~~~
  356. Une autre forme permet de préciser l'utilisateur que par lequel QEMU doit passer. Il est préférable d'utiliser cette forme :
  357. ~~~
  358. # qemu-img create -f rbd rbd:rbd/kvmdev-test:id=libvirt:conf=/etc/ceph/ceph.conf 8G
  359. ~~~
  360. Cela créer une image vm0-data de 8 Gio dans le pool rbd.
  361. Sur la machine cliente, on ajoute la clef de l'utilisateur libvirt dans un secret :
  362. ~~~
  363. # cat > secret.xml << EOF
  364. <secret ephemeral='no' private='no'>
  365. <usage type='ceph'>
  366. <name>client.libvirt secret</name>
  367. </usage>
  368. </secret>
  369. EOF
  370. # virsh secret-define --file secret.xml # Donne la valeur de UUID
  371. # virsh secret-set-value --secret $UUID --base64 $KEY # KEY est dans le fichier /etc/ceph/ceph.client.libvirt.keyring
  372. ~~~
  373. Il est maintenant possible d'ajouter un RBD à une machine virtuelle. Par exemple pour ajouter le disque vm0-data du pool rbd à la VM vm0 (ne pas oublier de renseigner l'UUID) :
  374. ~~~
  375. # cat << EOF > vm0-data.xml
  376. <disk type='network' device='disk'>
  377. <driver name='qemu'/>
  378. <auth username='libvirt'>
  379. <secret type='ceph' uuid='$UUID'/>
  380. </auth>
  381. <source protocol='rbd' name='rbd/vm0-data'>
  382. <host name='192.168.0.1' port='6789'/>
  383. <host name='192.168.0.2' port='6789'/>
  384. <host name='192.168.0.3' port='6789'/>
  385. </source>
  386. <target dev='vda' bus='virtio'/>
  387. </disk>
  388. EOF
  389. # virsh attach-device vm0 vm0-data.xml --live --config
  390. ~~~
  391. ## VM
  392. On peut utiliser un block device pour y installer une machine virtuelle avec `virt-install`. Le chemin du disque doit mener au block device :
  393. ~~~
  394. # virt-install --connect=qemu:///system \
  395. --name=$VMNAME \
  396. --cpu mode=host-passthrough --vcpus=$VCPU \
  397. --ram=$RAM \
  398. --disk path=/dev/rbd/rbd/foo,bus=virtio,io=threads,cache=none,format=raw \
  399. --network=bridge:br0,model=virtio \
  400. --noautoconsole --graphics vnc,listen=127.0.0.1,keymap=fr \
  401. --rng /dev/random \
  402. --cdrom=/home/images/slackware64-14.2-install-dvd.iso
  403. ~~~
  404. ### migration à chaud
  405. ~~~
  406. virsh migrate --live --unsafe --verbose $vmname qemu+ssh://$IP_DST/system
  407. ~~~
  408. Le cache RBD doit être activé.
  409. ## Redimensionnement
  410. Il est possible d'étendre ou de réduire un block device au sein d'un pool. Si des machines virtuelles ont été installées sur le block device en question, il n'est pas nécessaire de les éteindre. On suppose ici que l'on souhaite étendre le block foo de 8 Gio à 16 Gio. On peut exécuter la commande suivante depuis n’importe quel nœud, y compris depuis un client.
  411. ~~~
  412. # rbd resize foo --size 16G
  413. ~~~
  414. N.B. : Il faut préciser la taille finale du volume et non la quantité que l’on souhaite ajouter.
  415. Depuis un hyperviseur, on pourra utiliser `qemu-img` directement. On peut préciser l’augmentation de la taille au lieu de la taille finale.
  416. ~~~
  417. # export CEPH_ARGS='--id libvirt'
  418. # poolname=name_of_pool
  419. # rbdname=name_of_rbd
  420. # size=N
  421. # qemu-img resize -f rbd "rbd:${poolname}/${rbdname}:id=libvirt" +${size}G
  422. ~~~
  423. Il reste à avertir la machine que le device a changé de taille :
  424. ~~~
  425. # virsh blockresize $domain $dev $newsize
  426. ~~~
  427. > La variable `dev` peut être déterminée avec la commande `virsh domblklist $domain`
  428. > Si on souhaite réduire la taille du block device :
  429. >
  430. > ~~~
  431. > # rbd resize foo --size 8G --allow-shrink
  432. > ~~~
  433. Le reste de la procédure dépend du système de fichier utilisé sur la machine virtuelle.
  434. ## Réplication
  435. Un block device est répliqué fois 2 par défaut. La commande suivante permet de changer cette valeur :
  436. ~~~
  437. # ceph osd pool set rbd size 2
  438. ~~~
  439. Le block device `rbd` sera ainsi répliqué 1 fois. Dans le cluster, on trouvera le block device original plus une réplication, d'où le « 2 ».
  440. Pour accéder au nombre de réplicats :
  441. ~~~
  442. # ceph osd pool get rbd size
  443. ~~~
  444. > **NB** Si on augmente le nombre de réplications, la commande `ceph -s` affichera certainement « HEALTH WARN ». Ce warning est normal et signale qu'une des réplications n'est pas complète. Il s'agit de celle qui vient d'être ajoutée. Le warning disparaitra quand la nouvelle réplication sera complète.
  445. ## Snapshots
  446. Il est possible de créer des snapshots de block device, de les restaurer, les cloner…
  447. Créer une snapshot :
  448. ~~~
  449. $ rbd snap create rbd/foo@foo_$(date +%F)
  450. ~~~
  451. Lister les snapshots :
  452. ~~~
  453. $ rbd snap ls rbd/foo
  454. ~~~
  455. Revenir à une snapshot :
  456. ~~~
  457. $ rbd snap rollback rbd/foo@$SNAPNAME
  458. ~~~
  459. Supprimer une snapshot :
  460. ~~~
  461. $ rbd snap rm rbd/foo@$SNAPNAME
  462. ~~~
  463. **TODO** ajouter la partie protection et clonage des snapshots
  464. # CephFS
  465. ## Mise en place
  466. Il est nécéssaire d'avoir un serveur de méta-données pour utiliser CephFS :
  467. ~~~
  468. $ ceph-deploy mds create $CEPH_NODE
  469. ~~~
  470. On créer le pool de données et de méta-données :
  471. ~~~
  472. $ ceph osd pool create cephfs_data $PG_NUM
  473. $ ceph osd pool create cephfs_metadata $PG_NUM
  474. $ ceph fs new $FS_NAME cephfs_metadata cephfs_data
  475. ~~~
  476. ## Utilisation
  477. Il suffit de monter le CephFS, il sera utilisable :
  478. ~~~
  479. # KEY=$(awk '/key = / { print $NF }' </etc/ceph/ceph.client.admin.keyring)
  480. # CEPH_USER_ID=admin
  481. # mkdir /mnt/mycephfs
  482. # mount.ceph $MON_IP_ADDR:/ /mnt/mycephfs -o "name=$CEPH_USER_ID,secret=$KEY"
  483. # cat <<EOF >/mnt/mycephfs/truth
  484. slackware is the best
  485. e ≃ 2.7181828
  486. EOF
  487. ~~~
  488. > La commande `mount.ceph` est équivalente à `mount -t ceph`.
  489. Il est possible de donner un fichier contenant la clef au lieu donner la clef directement lors du `mount.ceph` :
  490. ~~~
  491. # SECRETFILE=/etc/ceph/admin.secret
  492. # awk '/key = / { print $NF }' </etc/ceph/ceph.client.admin.keyring >$SECRETFILE
  493. # CEPH_USER_ID=admin
  494. # mount.ceph $MON_IP_ADDR:/ /mnt/mycephfs -o "name=$CEPH_USER_ID,secretfile=$SECRETFILE"
  495. ~~~
  496. On peut aussi utiliser FUSE :
  497. ~~~
  498. # ceph-fuse -m $MONITOR_IP_ADDRESS:6789 /mnt/mycephfs
  499. ~~~
  500. Il est également possible de limiter l'utilisation du FS à un répertoire pour un utilisateur Ceph :
  501. ~~~
  502. $ CEPH_USERNAME=client.cephuser
  503. $ ceph fs authorize cephfs $CEPH_USERNAME /dir0 rw /dir1 r
  504. ~~~
  505. Cette commande va créer un utilisateur `client.cephuser`. Il aura accès au répertoire `/dir0` en lecture et en écriture et `/dir1` en lecture seule. On pourra monter le FS de cette manière :
  506. ~~~
  507. $ ceph-fuse -n $CEPH_USERNAME -m $MONITOR_IP_ADDRESS:6789 /mnt/mycephfs -r /dir0
  508. ~~~
  509. > Le mécanisme de restriction d'accès fonctionne aussi bien avec `ceph-fuse` qu'avec `mount.ceph`.
  510. # Troubleshooting
  511. ## Impossible d'ajouter un RBD à une VM
  512. Il est possible que le problème vienne du client. Dans ce cas, l'élément bloquant est certainement apparmor. On suppose ici qu'on souhaite supprimer apparmor.
  513. Alors que apparmor est encore installé et actif, on identifie les processus pris en charge par apparmor :
  514. ~~~
  515. # aa-status
  516. ~~~
  517. Pour ne pas s'embêter, on dit a apparmor d'arrêter de sécuriser tous les processus :
  518. ~~~
  519. # aa-complain /etc/apparmor.d/usr.*
  520. # aa-complain /etc/apparmor.d/local/usr.*
  521. # ls /etc/apparmor.d/libvirt/libvirt-* | grep -v '\.files$' | xargs -n1 aa-complain
  522. ~~~
  523. Normalement, à ce stade tous les processus sont dans la catégorie « complain » et non « enforce ». Puis, on peut supprimer apparmor :
  524. ~~~
  525. # systemctl stop apparmor.service
  526. # apt remove apparmor apparmor-utils
  527. ~~~
  528. Après ça, l'ajout à froid de disque via virsh attach-device fonctionnera :
  529. ~~~
  530. # virsh shutdown $vm
  531. # virsh attach-device $vm $xml --config
  532. # virsh start $vm
  533. ~~~
  534. ## Crash
  535. Si une ou plusieurs machines du cluster s'éteigent brutalement, il suffit de les redémarrer et de s'assurer que le service NTP soit lancé sur la machine :
  536. ~~~
  537. # timedatectl status | grep -q '^NTP synchronized: yes$' || timedatectl set-ntp true
  538. ~~~
  539. Ceph devrait se réparer tout seul. La commande `watch ceph -s` permet de s'en assurer.
  540. ## Installation client impossible
  541. Si l'installation d'un client n'est pas possible à cause d'une erreur de configuration des paquets avec dpkg :
  542. ~~~
  543. # dpkg --configure ceph-common
  544. ~~~
  545. Puis recommencez l'installation depuis le nœud admin.
  546. ## « Reduced data availability »
  547. Après avoir éteint le cluster pendant un week-end, la commande `sudo ceph -s` peut retourner le warning suivant :
  548. ~~~
  549. $ ceph -s
  550. cluster:
  551. id: beaa2317-eecb-4e2b-b5d2-358b072fe05d
  552. health: HEALTH_WARN
  553. Reduced data availability: 154 pgs inactive, 152 pgs peering
  554. Degraded data redundancy: 888/5094 objects degraded (17.432%), 66 pgs degraded
  555. ~~~
  556. Dans la plupart des cas il suffira d'attendre que le cluster se soigne seul. On peut surveiller l'état du cluster avec `watch sudo ceph -s`. En dernier recours, si le cluster est bloqué, la commande suivante *peut* corriger ce warning :
  557. ~~~
  558. $ ceph sync force --yes-i-really-mean-it --i-know-what-i-am-doing
  559. ~~~
  560. ## Manque de placement groups
  561. Si on ajoute un grand nombres d'OSD sur un cluster de petite taille (c.à.d ayant moins de 10 OSD) le rapport de santé de Ceph peut nous avertir d'un manque de placement groups (noté « pgs »). Il suffit d'en ajouter avec la commande suivante :
  562. ~~~
  563. $ ceph osd pool set $POOL_NAME pg_num $PG_NUM
  564. $ ceph osd pool set $POOL_NAME pgp_num $PG_NUM
  565. ~~~
  566. > $PG_NUM devrait être une puissance de 2 pour permettre une répartition des données plus homogène sur le cluster.
  567. ## host down
  568. Le message d'erreur est :
  569. ~~~
  570. cluster:
  571. id: c957bfaa-ec62-443a-8df1-6e21852e7740
  572. health: HEALTH_WARN
  573. 4 osds down
  574. 1 host (4 osds) down
  575. services:
  576. mon: 3 daemons, quorum ceph01,ceph02,ceph03
  577. mgr: ceph01(active), standbys: ceph03, ceph02
  578. osd: 12 osds: 8 up, 12 in
  579. data:
  580. pools: 0 pools, 0 pgs
  581. objects: 0 objects, 0B
  582. usage: 12.8GiB used, 65.3TiB / 65.3TiB avail
  583. pgs:
  584. ~~~
  585. La machine en question est inaccessible.
  586. ## Fichier keyring dans /etc/ceph absents
  587. Si un fichiers *.keyring dans /etc/ceph est absent ou a été supprimé, tout va bien, on peut le générer. Si l’utilisateur est `client.libvirt`, on peut exécuter ces commandes sur un des nœuds du cluster.
  588. ~~~
  589. id=client.libvirt
  590. ceph auth get "$id" | grep -e "$id" -e key > /etc/ceph/ceph."$id".keyring
  591. ~~~
  592. Les infos seront dans `/etc/ceph/ceph.client.libvirt.keyring`.
  593. ## Quel client utilise ce RBD ?
  594. Depuis un nœud de cluster, on peut savoir quel client utilise un RBD avec la commande `rbd status`.
  595. ```
  596. root@ceph-admin-node:~# rbdname=mypool/myrbd
  597. root@ceph-admin-node:~# rbd status vm-root "${rbdname}"
  598. Watchers:
  599. watcher=x.y.z.t:0/2718281828 client.2718281 cookie=271828182845904
  600. ```
  601. L’IP du client est `x.y.z.t`.