76 lines
3.2 KiB
Markdown
76 lines
3.2 KiB
Markdown
# Ceph
|
||
Pour stocker les données des utilisateur⋅ices, d'administration et les disques
|
||
des machines virtuelles, on utilise ceph. C'est un système de stockage distribué
|
||
sur le réseau qui permet de conserver l'accessibilité des données même en cas de
|
||
panne ou de maintenance d'une partie des nœuds du réseaux. Pour donner une idée
|
||
en quelques mots, c'est un RAID mais sur le réseau.
|
||
|
||
## Daemons
|
||
Ceph fonctionne grâce à une collection de daemons qui s'occupent chacun de tâches
|
||
bien spécifiques.
|
||
|
||
### Moniteurs
|
||
Les moniteurs sont chargés de maintenir la cartographie du réseau. C'est eux qui
|
||
répartissent les données entre les différents nœuds et qui servent de frontend
|
||
pour beaucoup d'opérations utilisateur⋅ices. Tout ce qui est de la création de
|
||
pool ou de système de fichiers passent par eux.
|
||
|
||
### OSDs
|
||
Les OSDs sont les daemons qui gèrent directement les données. Pour chacun des
|
||
disques qu'on rend disponible sur le réseau, on lance un osd correspondant qui
|
||
est son intermediaire avec le reste du réseau.
|
||
|
||
### Manageurs
|
||
Ils permettent de suivre l'état du réseaux. Il est reccomandé de lancer au moins
|
||
un manager par nœud sur le réseaux.
|
||
|
||
### MDSs
|
||
Wallah aucune idée je crois qu'ils servent à des trucs avec cephfs mais j'irais
|
||
fouiller la doc plus tard :p
|
||
|
||
|
||
## Infrastructure (proposition de shirenn)
|
||
La plupart des OSDs sont concentrées sur trois nœuds de stockage : tealc,
|
||
cameron et un troisième (sur l'infrastructure de test il s'agit de tealch,
|
||
kameron et otter (other <-> otter, tu as compris x)). Le lien public du réseau
|
||
est située sur san (vlan 4) et le lien privé du cluster sur zef (vlan 5). Les
|
||
autres nœuds sur le réseau sont les serveurs des deux clusters proxmox. Chacun
|
||
d'entre eux dispose d'un moniteur pour permettre l'intégration proxmox de ceph.
|
||
|
||
Il peut être pertinent d'avoir quelques osds sur les serveurs directement
|
||
pour que certaines données puissent être partiellement stockée en local pour
|
||
réduire les temps de transit. En particulier,
|
||
1. les homes
|
||
2. les disques des machines virtuelles hébergées sur le nœud
|
||
Cela demande de créer une crush map pertinente et d'éviter de migrer des vms
|
||
trop souvent.
|
||
|
||
|
||
## Infrastructure (proposition de esum)
|
||
Les MONs, MGRs, OSDs et MDSs sont déployés sur les trois nœuds de stockage :
|
||
tealc, cameron et un troisième serveur via l'intégration ceph de proxmox qui
|
||
permet d'avoir une interface d'administration jolie et accessible et une
|
||
configuration répliquée automatiquement avec corosync. À mon avis ça rend
|
||
l'infrastructure fool-proof et future-proof.
|
||
|
||
Pour celà on créé un cluster proxmox dédié sur le vlan ceph (vlan id 5) et on
|
||
créé un cluster ceph avec comme subnet public un réseau sur le vlan san (vlan id
|
||
4) et comme subnet de cluster un réseau sur le vlan ceph.
|
||
|
||
Sur les deux clusters de virtualisation on ajoute un stockage RBD sur la bonne
|
||
pool (vm pour les VMs Crans et vm-adh pour les VMs adhérents).
|
||
|
||
Enfin on créé un cephfs nommé crans avec trois dossiers :
|
||
* `/home` pour les homes des adhérents
|
||
* `/mail` pour les mails des adhérents
|
||
* `/nounou` pour les homes des nounous
|
||
|
||
|
||
## Infrastructure (proposition de «quelqu'un d'autre»)
|
||
|
||
## Déploiement
|
||
Soon<sup>TM</sup>
|
||
|
||
### Création de clients
|
||
Soon<sup>TM</sup>
|