Ceph

De OpenWikiBSD
Aller à : navigation, rechercher

Vous cherchez un stockage redondant, scalable (parce que échelable ne me plait pas.), d'une capacité colossale, demandant une maintenance réduite,....

Ceph est fait pour vous !


Liens

  • [1] Le guide du spécialiste français de Ceph.

Fonctionnalités

  • répartition (redondance) des données sur plusieurs disques & machines, bref du peer to peer pour vos précieuses données.
  • La perte d'un disque est la norme plutôt que l'exception.

Vocabulaire

  • OSD : Object Storage Device : Un disque dur (ou une partition, mais c'est un mauvais choix en terme de perfs que de mettre plusieurs OSDs par disque)
  • EC : Erasure-coded :
  • Tiering
  • MON
  • n=k+m : nombre de découpages et de redondances. Voir Ceph#erasure-coded
  • pg : placement group  :
  • chunk : morceau,quignon. Les morceaux en lesquels sont découpés les objets.


Limitations

  • Une fois le choix k+m d'un ec-pool fait, il n'est plus modifiable.

A tous ces détails tu prêteras attention

Le réseau

Ceph repose sur le réseau (beaucoup même) pour stocker et échanger ses données. Il FAUT un réseau fiable et rapide et avec un minimum de latence.... Bon, on doit pouvoir éviter l'infiniband 40Gbe, mais en dessous du Gb on ne discute même pas et pour la prod, du 10Gbe (Base T voire SFP+ si possible)

Un Netgear XS708 fournit 8 ports 10Gbe-baseT pour 1000€!

Choix technos

  • Ceph fonctionne sur matériel bas de gamme et le choix judicieux peut être d'utiliser des disques SATA, pas chers, lents mais avec de grosses capacités et de coller devant des caches haute-vitesse pour compenser.

Différents niveaux de cache haute-vitesse

En supposant que vous utilisez des disques SATA 7200 rpm, soit :

  • Bande passante environ 100Mo/s
  • 100 IOPS (entrées sorties par seconde)
  • Cache disque 64 Mo .

64/(100*2) Soit 3 dixièmes de seconde.. On redivise par 2 car le cache est utilisé autant en lecture qu'en écriture..

  • Cache de la carte raid, 1GB.

On redivise par 2 car le cache est utilisé autant en lecture qu'en écriture.. Et ce, bien que sur certains modèles de carte controleur, il soit possible de modifier le ratio read/write d'usage du cache

    • Avec 3 disques, on a 330/2 MB de cache, soit 1,5 secondes de données. Moyen
    • Avec 10 disques, on tombe à 0,5 seconde...

Attention. Si vous utilisez le même contrôleur pour le journal (ou le tiering) et les OSD, alors le cache du contrôleur sera utilisé pour l'ensemble des flux de données, vous allez donc mettre en cache du contrôleur des données que vous voudriez seulement migrer d'un pool OSD à du tiering (ou le journal)... Ca risque d'être au minimum inutile de monter la quantité de cache contrôleur..

Une intéressante discussion sur les choix possibles.

Une config spécifique des cartes Dell PERC H710 et de leur monitoring par smartctl.

Journal

En dehors des dernières versions ( intérêt/fiabilité à valider en prod), l'usage d'un journal est nécessaire à Ceph. Le principe est le suivant pour une écriture:

    • Ecriture sur le journal
    • Acquittement de l'écriture (Ceph considère la donnée comme écrite et passe à la suite)
    • Lecture des données du journal (ou récriture des données précédentes depuis la RAM: A valider)
    • Ecriture des données sur les OSDs;

Bref, la pénalité en écriture est double, vous divisez la bande passante par 2 ! Il est donc d'uage de mettre le journal sur un SSD.

Tiering

Le Tiering consiste à ajouter "devant" un pool standard (OSD+SSD en journal, un seconde pool de SSD qui servent de cache en lecture comme en écriture pour le pool SSD+OSD. Si la lecture tape dans le cache, rien ne sera lu dans le second pool SSD+OSD. L'écriture, quant à elle tape toujours dans ce cache rapide et est récrite ultérieurement dans le pool normal.

Journal vs Tiering

Les stats

Replication

C'est le système de base pour les pools de données.


Choix du nombre de réplicats Attention, répliquer plus c'est écrire moins vite..

erasure-coded

La doc officielle.

Une comparaison quantitative de la réplication et de l'EC.

Un test de l'usage du CPU entre réplication et EC.

ceph osd pool create ecpool 12 12 erasure

Crée un pool erasure-coded avec k=12 et m=12, soit un RAID5 sur 3 hôtes minimum.

  • n=k+m
    • un objet sera découpé en k morceaux

Soit k data chunks

    • m morceaux d'informations redondantes seront ajoutés

soit m coding chunks

    • m est donc le nombre d'OSD qui peuvent être perdus sans pour autant perdre d'information.
  • ruleset-failure-domain=rack/host indique qu'aucune bribe d'information redondante ne doit être stockée sur le même rack/le même hôte.

Donc, avec k=3,m=2, on arrive à :

Pour un objet de 1MB : Il est coupé en m=3 morceaux de données 3,3 MB auxquels on ajoute 2 morceaux d'encodage de 3,3MB. On peut perdre m=2 disques , donc comme du RAID6, mais on utilise n.3,3 = (k+m).3,3=5.3,3 = 18,3 MB seulement.

Défaut

  • k=2,m=1 ce qui donne un miroir (Raid1) mais ne nécessite que 50% d'espace disque supplémentaire et non 100% (cas du miroir)
  • jerasure code : [2]

Hardware

Performances attendues

Plus vous répliquez, moins vous débitez, toutes choses égales par ailleurs !

Bref, le plus souvent ce sont les IOPS qui limiteront, pas la bande passante.

Si ,

  • vous avez un répliquat de 3 (le minimum si vous tenez un peu à vos données)
  • vous avez 3 disques (SATA) par hôte (le minimum)
  • vous avez 3 hôtes (le minimum)

Et malgré le journal et le tiering, vous serez limités au pire, en cas de flux séquentiel à :

100 IOPS * 3 HD * 3 hôtes /3 réplicats = 300 IOPS....

Bref, vous irez plus vite avec un SSD en USB à ce train, là!

Disques , SSD

Tiré du guide de Han :

parted -a

pour aligner les partitions.

SSD

  • Utilisez de l' Intel en SATA/SAS, de l' Intel en PCIe si vous êtes riche , de l' Intel S3500 ou de l' Intel S3700, bref ...de l' Intel !
  • JAMAIS! du Samsung 840/850 Pro ! JAMAIS !. Butinez en ligne les ennuis de ceux qui collent des palanquées de SSD Samsung, espèrent du Go/s et trouvent 50 Mo/s.....

OSD

Vous pouvez mettre du SAS partout, mais votre argent sera bien mieux utilisé en collant des SSD en cache/journal/Tiering devant en hot-pool et des boeufs de SATA pour le cold-pool derrière.

CPU

  • La réplication est BEAUCOUP moins gourmande en CPU que l'EC. (pour 30 OSD en 10Gbe, 12 coeurs à 2GHz suffisent à peine...., voir line précédent)
  • Si ZFS est limité par la RAM, Ceph l'est surtout par le CPU (et le réseau). Les deux l'étant par les disques durs et leurs pauvres 100 à 200 IOPS..

Comment faire pour

Vous avez perdu le SSD Journal

[3]

Virer un OSD du cluster ceph

A la mano :

ceph osd crush remove osd.5
ceph auth del osd.5
ceph osd rm 5
umount /var/lib/ceph/osd/ceph-5

Ou bien sous ProxMox

pveceph destroyosd 5

Détruire la config du cluster Ceph tout en le gardant dans le cluster ProxMoX

Attention, c'est sans retour !

pveceph purge

WARNING ! Vous détruisez le ceph.conf et l'ensemble de la config !!!!

Ce n'est pas du tout indiqué ainsi dans la doc !!

Sur quelle machine est mon OSD ?

  • Pour obtenir l'ensemble des infos (poids relatif, ..), mais l'OSD doit être UP
ceph osd tree
ID WEIGHT  TYPE NAME         UP/DOWN REWEIGHT PRIMARY-AFFINITY 
-1 5.65826 root default                                        
-2 3.17259     host NAME                                        
 3 1.35899         osd.3          up  1.00000          1.00000 


  • Pour trouver l'IP, le nom du serveur où l'OSD a été vu la dernière fois; il peut donc être down.
ceph osd find Numero_OSD
{
   "osd": 3,
   "ip": "IP:PORT_AB",
   "crush_location": {
       "host": "NAME",
       "root": "default"
   }
}
* Pour trouver la partition éventuellement relative à l'OSD, vu la dernière fois; il peut donc être down.
ceph osd dump | grep ^osd.3

osd.3 up   in  weight 1 up_from 304 up_thru 321 down_at 302 last_clean_interval [277,299) IP_SRV:PORT_AB IP_SRV:PORT_AB IP_SRV:PORT_AB IP_SRV:PORT_AB  exists,up d1466996-ddffb-44ddc-9ce7-b685cba39035
ssh NAME 
blkid| grep d1466996-ddffb-44ddc-9ce7-b685cba39035

/dev/sdd1: UUID="1acd1bf5-0555-4f99-8773-053dc6aa7d7b" TYPE="xfs" PARTLABEL="ceph data" PARTUUID="d1466996-ddffb-44ddc-9ce7-b685cba3903"


Où sont mes données ?

  • Quel point de montage
mount |grep ceph
/dev/sdb1 on /var/lib/ceph/osd/ceph-1 type xfs (rw,noatime,attr2,inode64,noquota)
/dev/sdd1 on /var/lib/ceph/osd/ceph-3 type xfs (rw,noatime,attr2,inode64,noquota)
  • OK, lequel des deux contient la dernière carte (CRUSHMAP) ?
ls /var/lib/ceph/osd/ceph-*/current/meta |grep osdmap |grep -v "inc"
osdmap.1__0_666DF966__none
osdmap.2__0_666DF966__none
osdmap.3__0_666DF966__none
osdmap.4__0_666DF966__none
osdmap.5__0_666DF966__none
osdmap.6__0_666DF966__none
osdmap.7__0_666DF966__none
osdmap.8__0_666DF966__none
osdmap.9__0_666DF966__none
osdmap.1__0_666DF966__none
osdmap.2__0_666DF966__none
osdmap.3__0_666DF966__none
osdmap.4__0_666DF966__none
osdmap.5__0_666DF966__none
osdmap.6__0_666DF966__none
osdmap.7__0_666DF966__none
osdmap.8__0_666DF966__none
osdmap.9__0_666DF966__none
  • La dernière version contient le numéro d'incrément le plus élevé. Comme j'ai deux points de montage, je dois la retrouver deux fois : osdmap.9__0_666DF966__none. Trouvons la dernière version :
for MAP in `find  /var/lib/ceph/osd/ -iname osdmap.9__0_666DF966__none` ; do ls -lh $MAP ; done
-rw-r--r-- 1 ceph ceph 1.1K May  7 18:46 /var/lib/ceph/osd/ceph-1/current/meta/osdmap.9__0_666DF966__none
-rw-r--r-- 1 ceph ceph 1.1K Jun 19 21:32 /var/lib/ceph/osd/ceph-3/current/meta/osdmap.9__0_666DF966__none
  • OK, c'est celle de ceph-3 du 19 Juin.
cd /var/lib/ceph/osd/ceph-3/current/meta/
  • Décompilons la crushmap au format binaire
 osdmaptool osdmap.9__0_666DF966__none --export-crush /tmp/crushmap.bin

osdmaptool: osdmap file 'osdmap.9__0_666DF966__none' 
osdmaptool: exported crush map to /tmp/crushmap.bin
  • Rendons la plus intelligible :
crushtool -d /tmp/crushmap.bin -o /tmp/crushmap.txt


Eteindre tout mon cluster sans souci au redémarrage

  • Eteindre le cluster
  • Eteindre toutes les VM, tous les LXC
  • Mettre le cluster en mode de non-exclusion des OSD éteints
 ceph osd set noout
  • Eteindre tous les MON
  • Eteindre tous les OSD
  • Au cas où
ceph -a stop
  • Rallumer le cluster
  • Démarrer les OSD
  • Démarrer les MON
ceph -w 

pour vérifier et agir au besoin.

  • Démarrer LXC et VM
  • Remettre les OSD sous surveillance
ceph osd unset noout
ceph -a start


Une VM a crashé durant une écriture sur son pool

Lorsque vous tentez le pct start du conteneur, ça échoue avec dans les logs :

EXT4-fs (rbd3): required journal recovery suppressed and not mounted read-only

Facile : Testez que les donnés sont présentes (depuis l'hôte )

mount -o ro,noload /dev/rbd3 /mnt/
ls /mnt
umount /mnt

Puis testez le montage en écriture (qui doit planter)

mount -o rw,noload /dev/rbd2 /mnt/

On voit les dégâts :

fsck.ext4 /dev/rbd3 -n

On répare

fsck.ext4 /dev/rbd3

MCO régulière

PGs inconsistent

Source

ceph health detail

HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 7.78 is active+clean+inconsistent, acting [5,1,4]

OK, le pg 7.78 est inconsistent .

ceph pg repair 7.78

Ca marche...parfois !

Scrub errors

Installation

  • Installer une seconde carte réseau pour le réseau de stockage dédié
  • Ajouter la config :
# from /etc/network/interfaces
auto eth2
iface eth2 inet static
  address  10.10.10.XXX
  netmask  255.255.255.0


Sous Ubuntu /Debian

Pour utiliser sous ProxMox  : [4]

Sous ProxMox

Install

Doc

  • A faire sur chaque noeud du cluster Ceph :
apt-get update && apt-get -y dist-upgrade
pveceph install --version luminous


  • A faire sur un unique noeud
 pveceph init --network 10.10.10.0/24

Il pourrait également être judicieux de choisir ce LAN dédié et privé pour la communication du cluster.

  • Sur chacun des 3 noeuds de monitoring (qui peuvent porter des OSD, voire des VM ou des LXC, mais, il faut laisser au MON suffisamment d'IO) :
pveceph createmon

Puis, par l'interface de ProxMox, et dans l'ordre :

  • Vous créez vos OSD (sur des disques vierges, pas sur des partitions..) à raison de 1 OSD par disque et avec journal sur SSD si possible (Max environ 6 OSD par journal)
  • Vous créez votre pool Ceph :
    • Size: Nombre de host
    • Min : Nombre de host minimum pour tenir la réplication
    • Ruleset : 0 si on souhaite accepter la perte d'OSD, 1 pour la perte d'host
    • pg_num : puissance de 2 immédiatement supérieure à 100*OSD/réplicat, soit 256 pour 6 OSD et 3 réplicats
  • Vous créez votre storage (onglet Datacenter) s'appuyant sur le pool ceph, type rbd

Enfin, vous devez permettre l'accès (via clés) des machines aux pools : [5] Sur les moniteurs uniquement !!!

mkdir /etc/pve/priv/ceph
grep "rbd:" /etc/pve/storage.cfg

Vous obtenez le nom des pools,par exemple : rbd: TestPool

 cp /etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/testPool.keyring

Ce qui signifie que vous devez refaire cette opération à chaque création de pool!

Supprimer un pool

Par défaut (et par sécurité), il n'est aps permis de supprimer un pool. Il faut ajouter sur le ceph.conf, dans la partie [mon] sur chacun d'entre eux,

 mon_allow_pool_delete = true

puis un restart du service mon sur chacun.

service ceph-mon@ID restart

Sinon

mon_command failed - pool deletion is disabled; 
you must first set the mon_allow_pool_delete config option to true before you can destroy a pool (500)

Je vous conseille fortement de remettre la ligne à false à l'issue..

Création d'un conteneur LXC avec un backend Ceph de stockage

  1. Créer un pool avec les bonnes caractéristiques :
  • Depuis un membre du cluster :
Ceph/Pools/Create
  • Depuis la racine du cluster, ajoutez un stockage :
Add/RBD/ Choisissez un nom pour la passerelle / Pool précédemmnent créé / Les mons 

N'oubliez pas de cliquer sur Container dans Content et de valider KRBD afin de bénéficier su stockage des LXC

  • Sur les mon, donnez leur les droits
cp /etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/PoolID.keyring


C'est terminé pour le stockage distribué.

Maintenant, sur chaque conteneur auquel vous souhaitez associer une part de cet espace :

  1. Depuis l'onglet du LXC :
Add Mount Point

Tout est self-explicite. Le point de montage sur le FS du conteneur sera créé automatiquement.

Debug

rbd error: rbd: couldn't connect to cluster (500)

Jouez avec les keyrings comme vu au paragraphe précédent.


rados_connect failed - No such file or directory (500)

pveceph configuration not initialized (500)

Simple, vous n'avez pas initialisé le cluster Ceph...Ou bien, vous avez bêtement suivi la doc proxmox qui ne précise pas que pveceph purge vire toute la config du cluster et pas juste le noeud...


Errors while parsing config file

parse_file: cannot open /etc/ceph/ceph.conf: (2) No such file or directory

Le lien vers le fichier réparti (sur /etc/pve) n'est pas fait :

ln -s /etc/pve/priv/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

ou

ln -s /etc/pve/ceph.conf /etc/ceph/ceph.conf

selon

A ne pas faire

A part pveceph purge, je ne vois pas...

Alerte j'ai perdu la conf du cluster

Ne recréez pas une nouvelle instance via pveceph init, sinon vous êtes cuit !

Recréer le ceph.conf

Si vous avez encore les osd fonctionnel, on peut encore s'en sortir...

voila un ceph.conf à coller dans /etc/pve/ceph.conf (il sera donc répliqué)
[global]
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
cluster network = IP_REPL/16
filestore xattr use omap = true
fsid = ID_Cluster
keyring = /etc/pve/priv/$cluster.$name.keyring
osd journal size = 5120
osd pool default min size = 1
public network = IP_PUB/16
[osd]
keyring = /var/lib/ceph/osd/ceph-$id/keyring
[mon.0]

host = jaime mon addr = IP1:6789

[mon.1]

host = daenerys mon addr = IP2:6789

[mon.2]

host = jon mon addr = IP3:6789

le plus important, le fsid, peut être retrouvé via vos osd :

cat /var/lib/ceph/osd/ceph-0/ceph_fsid


Retrouver les clés d'authent de cephx

cp /etc/pve/priv/ceph/MonPool.keyring /etc/pve/priv/ceph.client.admin.keyring
ln -s /etc/pve/priv/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring