WikiMiNET

La documentation technique et administrative

Outils pour utilisateurs

Outils du site

Piste:
wiki:cluster:ceph:choix

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision 		Révision précédente
wiki:cluster:ceph:choix [2018/06/17 18:14]
varens 		wiki:cluster:ceph:choix [2020/06/27 18:16] (Version actuelle)
Ligne 1: Ligne 1:
 ====== Les choix du stockage ====== ====== Les choix du stockage ======
  
-Le stockage a été refait en 2018 par **Romain Cherré (Prez 2017-2018)** et **Nicolas Bonnet (VP pipo askip 2017-2018)**. Nous avons fait passer ce projet dans le cadre d'un projet Cassiopée.+Le stockage a été refait en 2018 par **Romain Cherré (Prez 2017-2018)** et **Nicolas Bonnet (VP pipo askip 2017-2018)** et debuggé pendant un été entier par (Emmanuel Allaire, Etienne Lamouret, Clément Tarverne et Yohan Pipereau) parce que ça a été lâché à la pisse comme tous les projets cassiopet Minet. Nous avons fait passer ce projet dans le cadre d'un projet Cassiopée.
  
 L'intitulé du projet Cassiopée était plus vague que juste "installer ceph sur les noeuds de prod'", il s'agissait d'abord de faire passer MiNET sur une infrastructure __hautement disponible__. L'intitulé du projet Cassiopée était plus vague que juste "installer ceph sur les noeuds de prod'", il s'agissait d'abord de faire passer MiNET sur une infrastructure __hautement disponible__.
Ligne 23: Ligne 23:
 //Charybde// et //Scylla// étaient aussi placés dans la même salle (la salle serveur), donc si un incendie s'y déclarait on avait beaucoup de chance de perdre les deux en même temps. Il nous fallait donc, en plus de la redondance au niveau des disques, une redondance au niveau des serveurs. //Charybde// et //Scylla// étaient aussi placés dans la même salle (la salle serveur), donc si un incendie s'y déclarait on avait beaucoup de chance de perdre les deux en même temps. Il nous fallait donc, en plus de la redondance au niveau des disques, une redondance au niveau des serveurs.
  
-Charybde et Scylla ont été conçus pour offrir un maximum de performances, tout en gardant une redondance limitée des données (voir article sur le wiki). Nous avons jugé que la disponibilité et la redondance étaient plus important que la performance. Ceph nous offre des compétences suffisantes pour nos VMs tout en répondant à nos besoins.+Charybde et Scylla ont été conçus pour offrir un maximum de performances, tout en gardant une redondance limitée des données (voir article sur le wiki). Nous avons jugé que la disponibilité et la redondance étaient plus important que la performance. Ceph nous offre des performances (voir page benchmark) suffisantes pour nos VMs tout en répondant à nos besoins.
  
 ==== Simplicité d'exploitation ==== ==== Simplicité d'exploitation ====
Ligne 35: Ligne 35:
 ==== Sur nos "vrais" besoins ==== ==== Sur nos "vrais" besoins ====
  
-La conception des NAS ont été les fruits d'un travail admirable par les bureaux précédent. Un de leur objectif a été la performance. En regardant les benchmarks des différents systèmes nous nous sommes interrogés sur nos besoins en performance. Nous avons conclu que nous devions garder suffisamment de performances mais que nous n'avions pas besoin des meilleurs débits et latences pour quelques VMs.+La conception des NAS ont été les fruits d'un travail admirable par les bureaux précédent. Un de leur objectif a été la performance. En regardant les benchmarks des différents systèmes nous nous sommes interrogés sur nos besoins en performance. Nous avons conclu que nous devions garder suffisamment de performances mais que nous n'avions pas besoin des meilleurs débits et latences pour quelques VMs (il s'avère que l'infrastucture CEPh après son déploiement a souffert de lourd problèmes de latences, peut-être que c'était plus important que prévu.).
  
 ==== La multiplicité ==== ==== La multiplicité ====
Ligne 84: Ligne 84:
 Une deuxième solution s'offrait à nous avec Proxmox, un truc qui s'appelle "ZFS+iSCSI". En gros c'est une extension écrite par la communauté qui a été intégré par Proxmox dans leur système qui permet de faire un volume par VM de façon automatisée. Le noeud Proxmox se connecte au serveur de stockage en SSH (en root... pas top pour la sécu) et crée lui même le volume, etc. Une deuxième solution s'offrait à nous avec Proxmox, un truc qui s'appelle "ZFS+iSCSI". En gros c'est une extension écrite par la communauté qui a été intégré par Proxmox dans leur système qui permet de faire un volume par VM de façon automatisée. Le noeud Proxmox se connecte au serveur de stockage en SSH (en root... pas top pour la sécu) et crée lui même le volume, etc.
 Le problème c'est que on ne peut pas utiliser de container avec ce système... Abandon encore. Le problème c'est que on ne peut pas utiliser de container avec ce système... Abandon encore.
 +
 +{{ :wiki:cluster:ceph:stockage_redonde.png?600 |}}
  
  
 On a étudié les différentes autres solution, en gardant à l'esprit qu'on voulait quelque chose de simple, et on a finalement statué sur Ceph. Je vous passe les discussions qu'on a eu sur les autres bricolages qu'on a pensé faire. On a étudié les différentes autres solution, en gardant à l'esprit qu'on voulait quelque chose de simple, et on a finalement statué sur Ceph. Je vous passe les discussions qu'on a eu sur les autres bricolages qu'on a pensé faire.
 +
 +
 +==== Les choix de technos dans ceph ====
 +
 +Ceph propose plusieurs façons de faire du stockage, bon évidemment on utilise RBD pour exporter des block device, ce n'est pas trop exotique. Cependant il y a différentes façons de faire la réplication, et différentes façons d'utiliser RBD.
 +
 +On utilise le nouveau standard de stockage de ceph pour la gestion des OSD qui est [[http://docs.ceph.com/docs/master/rados/configuration/bluestore-config-ref/|bluestore]], en utilisant des partitions sur SSD pour stocker les méta-données de bluestore afin d'améliorer la performance.
 +
 +On avait donc la possibilité d'utiliser une pool en //replicated// ou en //erasure coding//, vu la place qu'on a on a choisi replicated pour ne pas s'embêter, et puis ça évite de descendre trop en performance.
 +
 +On avait également la possibilité d'utiliser du [[http://docs.ceph.com/docs/master/rados/operations/cache-tiering/|cache tiering]] qui est censé améliorer les performances, sauf dans les cas d'utilisation avec RBD. Donc on a laissé tombé pour le cache tiering qui permet de copier les données souvent utilisées dans une autre pool qui est plus performante (se place en priorité sur des SSD par exemple)
 +
 +
 +
wiki/cluster/ceph/choix.1529252092.txt.gz · Dernière modification: 2020/06/27 18:15 (modification externe)

Outils de la page

Sauf mention contraire, le contenu de ce wiki est placé sous les termes de la licence suivante : CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki