Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
De mémoire, la partie Ceph n'était pas bien intégrée dan le GUI de Proxmox. C'est mieux maintenant ou ça reste du CLI pour la partie Ceph ?
Merci de ton retour!
Le 15 déc. 2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
Il y a toujours une toute petite partie de CLI pour mettre en place le cluster, mais ensuite ça passe plus ou moins.
La CLI de Proxmox concernant CEPH n'est pas super difficile non plus en même temps…
Le 15/12/2017 à 12:41, David Ponzone a écrit :
De mémoire, la partie Ceph n'était pas bien intégrée dan le GUI de Proxmox. C'est mieux maintenant ou ça reste du CLI pour la partie Ceph ?
Merci de ton retour!
Le 15 déc. 2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
Ca y est, j'ai envie de monter une plate-forme de test :) Tu utilises des clusters de 3 ou 5 noeuds ou plus ? Ca a un impact sur le temps de calcul en cas de perte d'un noeud ?
Le 15 déc. 2017 à 12:42, GAoL garfieldairlines on lists a écrit :
Il y a toujours une toute petite partie de CLI pour mettre en place le cluster, mais ensuite ça passe plus ou moins.
La CLI de Proxmox concernant CEPH n'est pas super difficile non plus en même temps…
Le 15/12/2017 à 12:41, David Ponzone a écrit :
De mémoire, la partie Ceph n'était pas bien intégrée dan le GUI de Proxmox. C'est mieux maintenant ou ça reste du CLI pour la partie Ceph ?
Merci de ton retour!
Le 15 déc. 2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit :
Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous,
de notre côté, nous avons fini par splitter ceph du reste de la plate-forme de virtu :
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).
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.
++ Raph
Le 2017-12-15 14:00, David Ponzone a écrit :
Ca y est, j'ai envie de monter une plate-forme de test :) Tu utilises des clusters de 3 ou 5 noeuds ou plus ? Ca a un impact sur le temps de calcul en cas de perte d'un noeud ?
Le 15 déc. 2017 à 12:42, GAoL garfieldairlines on lists a écrit :
Il y a toujours une toute petite partie de CLI pour mettre en place le cluster, mais ensuite ça passe plus ou moins.
La CLI de Proxmox concernant CEPH n'est pas super difficile non plus en même temps…
Le 15/12/2017 à 12:41, David Ponzone a écrit : De mémoire, la partie Ceph n'était pas bien intégrée dan le GUI de Proxmox. C'est mieux maintenant ou ça reste du CLI pour la partie Ceph ?
Merci de ton retour!
Le 15 déc. 2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit : Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit : Bonjour à tous,
Je serais intéressé par des retours d'expériences sur Proxmox en cluster _avec_ Ceph pour le stockage des VMs. Je serais intéressé notamment par la robustesse de la solution, typiquement dans le cas d'une coupure électrique brutale. Avez-vous déjà eu ce genre d'incident sur un tel cluster, est-ce que ça a redémarré sans problème etc. ?
Merci d'avance pour vos retours.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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 :
1. ceph osd set noout 2. stops successifs des daemons ceph-osd de l'hôte 3. reboot 4. 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.
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/
samedi 16 décembre 2017, 14:08:53 CET Eric Joseph-Alexandre wrote:
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.
Je veux bien que tu expliques 2/3 trucs là. Ça, c'est la recette pour faire tomber un cluster Ceph ?
Donc pour avoir un cluster Ceph, il faudrait : - changer la conf par défaut pour prioriser les I/O clients - ne pas remplir les OSDs au-delà de 2/3 de leur capacité - utiliser les bons outils pour monitorer le cluster. C'est à dire ? J'utilise des sondes nagios, dont une qui checke le ceph health, une pour le taux de remplissage des OSDs et une pour surveiller les monitors. Est-ce suffisant ?
C'est bien ce que tu voulais dire ?
Bonsoir,
----- Le 16 Déc 17, à 19:49, Luc Didry luc@didry.org a écrit :
D'ailleurs je serai curieux d'avoir un retour d'expérience de quelques uns sur les sauvegades.
Je veux bien que tu expliques 2/3 trucs là. Ça, c'est la recette pour faire tomber un cluster Ceph ?
Oui. C'était de l'autodérision. La règle des 2/3 c'est pour reprendre ce qui a été ecrit dans cette discussion. Mais je pense que cette règle s'applique plutôt au stockage global. Un peu comme avec ZFS ou il ne faut pas dépasser 80% de l'espace utilisable.
Donc pour avoir un cluster Ceph, il faudrait :
- changer la conf par défaut pour prioriser les I/O clients
Oui. Je l'ai appris ici après coup (slide 15) : https://redhatstorage.redhat.com/2015/10/06/ceph-deployment-at-target-best-p... Il y a ça aussi: https://forum.proxmox.com/threads/ceph-high-i-o-wait-on-osd-add-remove.20271...
- ne pas remplir les OSDs au-delà de 2/3 de leur capacité
A vérifier. Mais une chose est certaine c'est que j'avais beaucoup de warnings à ce sujet.
- utiliser les bons outils pour monitorer le cluster. C'est à dire ? J'utilise
des sondes nagios, dont un
e qui checke le ceph health, une pour le taux de
remplissage des OSDs et une pour surveiller les monitors. Est-ce suffisant ?
Avec le recul ça me semble être un minimum. En tous les cas c'est ce que je ferai la prochaine fois. Surveiller le taux de remplissage des OSDs et leur états (up/down)
C'est bien ce que tu voulais dire ?
Oui.
-- Luc https://fiat-tux.fr/ https://luc.frama.io/ Internet n'est pas compliqué, Internet est ce que vous en faites.
C'est avec 5 nœuds de test. En cas de perte d'un nœud, vu qu'il fallait recalculer pour CEPH, il y avait évidemment un impact (rajoute le fait que les serveurs étaient vieux et les disques anciens).
Le 15/12/2017 à 14:00, David Ponzone a écrit :
Ca y est, j'ai envie de monter une plate-forme de test :) Tu utilises des clusters de 3 ou 5 noeuds ou plus ? Ca a un impact sur le temps de calcul en cas de perte d'un noeud ?
Le 15 déc. 2017 à 12:42, GAoL garfieldairlines on lists a écrit :
Il y a toujours une toute petite partie de CLI pour mettre en place le cluster, mais ensuite ça passe plus ou moins.
La CLI de Proxmox concernant CEPH n'est pas super difficile non plus en même temps…
Le 15/12/2017 à 12:41, David Ponzone a écrit :
De mémoire, la partie Ceph n'était pas bien intégrée dan le GUI de Proxmox. C'est mieux maintenant ou ça reste du CLI pour la partie Ceph ?
Merci de ton retour!
Le 15 déc. 2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15 déc. 2017 à 11:24, GAoL garfieldairlines on lists a écrit :
O hai !
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu. Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour. Je te suggère fortement un RAID1 pour l'OS pour éviter ce qui arrive dans le paragraphe d'au-dessus (ce qui prend beaucoup de ressources et d'écriture disque).
Le 15/12/2017 à 11:02, Francois Lafont a écrit : > Bonjour à tous, > > Je serais intéressé par des retours d'expériences sur Proxmox > en cluster _avec_ Ceph pour le stockage des VMs. Je serais > intéressé notamment par la robustesse de la solution, typiquement > dans le cas d'une coupure électrique brutale. Avez-vous déjà eu > ce genre d'incident sur un tel cluster, est-ce que ça a redémarré > sans problème etc. ? > > Merci d'avance pour vos retours. > _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Le 15/12/2017 à 15:18, Wallace a écrit :
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Je valide pour DRBD sur un contexte petit cluster de 3 serveurs :)
@+ Gilou
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Liste de diffusion du FRsAG http://www.frsag.org/
M'enfin Pour avoir utilisé drbd pendant des années (le 8, pas le neuf, je n'utilise pas des soft en béta pour stocker mes données), ça reste une solution bien contraignante, en particulier au vu de la flexibilité apportée par Ceph
drbd reste du raid, donc de la réplication en mode block pair à pair, là où Ceph s’abstient de répliquer (dans le sens où les données sont utilisables par l'ensemble des nodes à chaque instant) et a un fonctionnement centré sur les données utiles : un volume rbd nouvellement crée ne pèse rien, est vide et est "sécurisé" instantanément, contrairement à un "volume" drbd
On 12/15/2017 04:47 PM, Gilou wrote:
Le 15/12/2017 à 15:18, Wallace a écrit :
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Je valide pour DRBD sur un contexte petit cluster de 3 serveurs :)
@+ Gilou
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
D'ailleurs, à ce sujet, Proxmox5, ça mérite la prise de tête/sueurs froides pour upgrader ?
Le 15 déc. 2017 à 15:18, Wallace a écrit :
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Liste de diffusion du FRsAG http://www.frsag.org/
Avec le changement important qu'apporte DRBD 8 à 9 j'ai opté pour une clean install. Agrémenté du fait que la doc est pas super au point encore car elle a été déléguée à l'éditeur de DRBD, Proxmox ne maintient plus cette partie.
Le 15/12/2017 à 16:49, David Ponzone a écrit :
D'ailleurs, à ce sujet, Proxmox5, ça mérite la prise de tête/sueurs froides pour upgrader ? / /
Le 15 déc. 2017 à 15:18, Wallace a écrit :
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Liste de diffusion du FRsAG http://www.frsag.org/
Le 15/12/2017 à 16:49, David Ponzone a écrit :
D'ailleurs, à ce sujet, Proxmox5, ça mérite la prise de tête/sueurs froides pour upgrader ?
A priori, il faut faire bien gaffe à la version des modules et softs de mgmt DRBD9. Encore une fois, c'est pas 'théoriquement' production-ready donc ils ont introduit des modifs incompatibles dans certaines version.
En revanche, une fois que tu as rajouté ton noeud DRBd, la partie Proxmox, c'est tout droit : un promox 4 peut être intégré dans un cluster v4 sans soucis (contrairement au passage 3 -> 4).
Pis après, 'as usual' : vidange d'un hyperviseur, montée de version, vidange d'un second noeud, montée de version, etc ...
Je plussoie pour DRBD9. Attention : drbdmanage va disparaître dans quelques mois et va être remplacé par linstor en mode client/serveur pour se débarrasser de dbus. Il est probable que le support Proxmox va prendre du plomb dans l'aile d'autant plus que ce n'est pas l'amour fou entre linbit et proxmox.
Julien
Le 15 déc. 2017 à 15:18, Wallace a écrit :
Si le stockage est pas différencié des hosts sur lesquels il tourne alors pourquoi ne pas utiliser drbd9.
J'adore Ceph mais clairement pour 2/3/5 serveurs clairement DRBD est plus facile à maintenir dans le tmeps et en version 9 super bien intégré à Proxmox 5 c'est le bonheur.
Le 15/12/2017 à 12:30, GAoL garfieldairlines on lists a écrit :
Le cluster CEPH est intégré (et géré !) avec/par Proxmox. Il n'y a pas de serveur séparé juste pour garder les clusters, mais c'est de mémoire aussi une possibilité.
Le 15/12/2017 à 12:08, David Ponzone a écrit :
Question idiote peut-être: tu as fait un custer Ceph indépendant, ou ton Ceph tourne sur les serveurs Proxmox ? Si cluster indépendant, même type de serveur que pour Proxmox ?
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir,
On 12/15/2017 11:24 AM, GAoL garfieldairlines on lists wrote:
On s'est posé exactement la même question ici, et on a donc décidé d'installer un cluster de test avec des machines disons… plutôt âgées.
Tout y est passé et on a même pas fait exprès : les disques qui ont lâchés, le switch pourri bas de gamme, la panne hardware sur un des quatre serveurs etc… et c'est plutôt solide.
Ok, cool. Et vous avez testé l'extinction brutale de _tous_ les nœuds du cluster... type coupure électrique de la salle serveurs ?
Il faut juste faire très attention : quand une machine tombe, toutes les autres seront pendant un certain temps plus actives histoire de recalculer et de ré-allouer les blocs CEPH qui ont disparu.
Oui. Alors je ne sais pas si le management de Ceph via Proxmox le permet, mais avec un Ceph « externe/classique », on peut mettre des priorités et faire en sorte que les I/O « clients » passent avant les I/O dues au load balancing des data. On peut aussi indiquer à Ceph de ne pas faire de load balancing du tout dans le cas où ce sont tous les OSDs d'un même host qui sont tombés (personnellement c'est un choix que je ferai si c'est possible avec un Ceph « proxmox-managed » of course). Ce sont juste des paramètres à définir dans le ceph.conf mais peut-être qu'avec un Ceph « Promox-managed » on ne peut pas toucher à ce fichier ? On peut ou c'est interdit ?
Donc bien faire attention à garder un peu d'espace disque libre, au cas où (je suggère de remplir au maximum 2/3).
Oui oui, tout à fait. Ce sont les préconisations de Ceph, ne jamais trop remplir les OSDs afin de permettre le load balancing des data à chaque instant.
Au fait, évite d'installer Proxmox sur des clés USB, ce n'est clairement pas fait pour
En effet, j'ai déjà eu des merdes avec les clés USB. Depuis, je ne tente plus le diable et j'utilise toujours un CD pour éviter les problèmes.
Je te suggère fortement un RAID1 pour l'OS
Oui, c'est ce qu'on projettait de faire (RAID1 Soft sur l'OS).
Merci pour ce retour plutôt encourageant. :)
Je répond sur la liste à ce message qui m'a été fait en privé (par mégardes j'imagine).
On 12/15/2017 11:14 AM, Vincent Hautot wrote:
Bonjour François,
Nous avons un cluster avec CEPH avec 8 serveurs promox. Nous avons déjà eu plusieurs coupures de courant sans problème jusqu'à aujourd'hui.
Ok, tous les nœuds se sont éteints brutalement et tout est reparti au reboot les doigts dans le pif ? Si c'est ça, c'est une très bonne nouvelle. :)
Par contre, pensez bien a isoler le trafic de ceph sur une switch dédié pour des questions de perf et de sécurité.
Oui, on aura un switch 10G (enfin 2 switchs redondés) pour le réseau interne au cluster Ceph.
Merci de ton retour Vincent.
-
David Ponzone -
Eric Joseph-Alexandre -
Francois Lafont -
frsag＠jack.fr.eu.org -
GAoL garfieldairlines on lists -
Gilou -
Julien Escario -
Luc Didry -
Raphaël Enrici -
Wallace