Bonjour,
Je trouve que Ceph est un bon produit. Nous avions nous aussi un cluster pour les VMs (5 noeuds) pour et un pour le Ceph (3 noeuds).
Je n'ai pas de conseils à donner car je ne maitrise pas Ceph. Par contre je peux expliquer comment planter une infra Ceph puisque je l'ai fait. Cela va juste confirmer ce qui a déjà été écrit par d'autre.
Le premier truc à faire: garder la configuration par défaut. Comme ça il n'y a pas de priorisation entre les I/O client et les tâches de maintenance. Et le jour où tu change un OSD de 3To tu attends une demi-journée avant que ton un cluster Ceph retrouve un fonctionnement normal.
Deuxième truc: ne pas respecter la règle de 2/3 et laisser une bonne partie des OSDs se remplir à plus de 90%. Du coup au moindre problème il n'y a plus rien qui fonctionne, les VMs sont deviennent inexploitables.
Troisième truc: utiliser les mauvais outils pour monitorer le cluster et sous estimer les messages d'alertes et ne pas résoudre les problèmes de pg dégradés.
En dehors de ça le Cluster fonctionnait parfaitement bien et encaissait toutes sortes de manipulations sans impactes les performances des VM. Mon seul gros problèmes était sur les temps de sauvegardes (vzdump) qui étaient franchement calamiteux. Du coup je faisais des snapshot avec rbd que j'exportais, mais je n'étais pas satisfait de la solution.
D'ailleurs je serai curieux d'avoir un retour d'expérience de quelques uns sur les sauvegades.
-- Eric.
----- Le 15 Déc 17, à 18:35, Francois Lafont francois.lafont.1978@gmail.com a écrit :
On 12/15/2017 02:42 PM, Raphaël Enrici wrote:
de notre côté, nous avons fini par splitter ceph du reste de la plate-forme de virtu :
Ah ok, c'est donc possible. C'est une info pour moi. ;)
Les MAJ noyau sont régulières chez proxmox et necessitent donc un redémarrage régulier des noeuds, certes en rolling upgrade mais du coup en fragilisant momentanément la partie ceph en la privant d'un noeud puis d'un autre puis d'un autre, ce qui devient lourd à gérer (sans parler de la goutte de sueur qui perle sur le front).
Quoi ? Un reboot d'un serveur avec des gouttes de sueur qui perlent ? Ça existe ça ? :)
Au final, nous avons 2 clusters proxmox : un pour la virtu quasi toujours up to date et un pour la gestion de ceph que nous faisons donc évoluer moins régulièrement. Cela a rendu service par moment, migration temporaire des VMs d'un cluster à l'autre pour grosse upgrade majeur ou ce genre de choses. Bref, c'est moins dans le registre hyper-convergence mais nous vivons mieux depuis ce split avec toujours en arrière plan le projet de faire vivre ceph hors proxmox en partant d'upstream.
Ok, merci pour ce point de vue intéressant. J'avoue que j'aurais plutôt tendance à partir du Ceph via Proxmox mais je comprends le souci pour les màj+reboot. Perso, pour un Proxmox qui ne contient que des OSDs et pas de monitors, j'aurais plutôt tendance à être confiant en la procédure :
- ceph osd set noout
- stops successifs des daemons ceph-osd de l'hôte
- reboot
- ceph osd unset noout
Après, de ce que j'ai constaté, lorsqu'il y a un restart un monitor, il y a un nouveau quorum et une réélection ce qui provoque une petite pause (vraiment très brèves) des I/O au niveau du cluster.
-- François Lafont _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/