Aux utilisateurs de Promox.
Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans ? Type de problème: certaines VM semblent avoir des problèmes de ressources CPU comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors qu’elles sont à 30-50% de CPU. La charge globale de l’hôte est autour de 50-60%. Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux limites de l’hôte, mais ce n’est pas le cas. J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème mais son uptime est de 8 mois seulement.
Merci de vos retours.
David Ponzone
Le 17/09/2020 à 20:03, David Ponzone a écrit :
Aux utilisateurs de Promox.
Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans ? Type de problème: certaines VM semblent avoir des problèmes de ressources CPU comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors qu’elles sont à 30-50% de CPU. La charge globale de l’hôte est autour de 50-60%. Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux limites de l’hôte, mais ce n’est pas le cas. J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème mais son uptime est de 8 mois seulement.
Quelle version de Proxmox ?
Il y a quelques années, j'ai eu un problème avec une version de Proxmox qui avaient des compteurs ou id (je ne sais plus) sur 32 bits, ou bout de quelques années d'uptime les commandes de l'hôte vers les invités ne fonctionnaient plus.
4.3.3 donc ça date mais quand ça tourne…
Pas mal de mises à jour à faire pour atteindre la dernière 4.X donc je pense que je vais faire l’impasse, trop risqué. Ca sera plus simple d’ajouter des nouveaux serveurs en 6.2.X et de migrer.
En tentant de virer le swap (parce qu’il est à 100% de 8Go, problème connu, j’avais sapines à 60) avec swapoff: échec, l’opération termine avec un Killed (pas par moi). J’avais pourtant réussi il y a quelques mois mais sur un autre Proxmox. J’ai donc peut-être bien un Proxmox qui va pas ultra-bien.
Le 17 sept. 2020 à 23:46, Frederic MASSOT frederic@juliana-multimedia.com a écrit :
Quelle version de Proxmox ?
Il y a quelques années, j'ai eu un problème avec une version de Proxmox qui avaient des compteurs ou id (je ne sais plus) sur 32 bits, ou bout de quelques années d'uptime les commandes de l'hôte vers les invités ne fonctionnaient plus.
t'as pas une sandbox pour mettre a jour ?
chez nous on upgrade régulièrement, donc pas trop de soucis, mais il fut un temps où on upgradait pas les proxmox. on c'est lancé, on a upgrade de debian7 à 10 (en étapes successives bien sur), et c'est passé comme une lettre à la poste (sauf le cluster, bien sur, mais ça c'est documenté par proxmox).
Seul bémol, on a quelques couple de proxmox qui tournent avec un socle DRBD. comme proxmox a retiré ses packages de ses repository (problème de licence avec linbit...) ben le module drbd kernel de debian8 (fourni par proxmox) a une version supérieure à celui fourni par debian9/10. j'ai du compiler à la mano (c'est pas la panacée...)
Le 18/09/2020 à 02:48, David Ponzone a écrit :
4.3.3 donc ça date mais quand ça tourne…
Pas mal de mises à jour à faire pour atteindre la dernière 4.X donc je pense que je vais faire l’impasse, trop risqué. Ca sera plus simple d’ajouter des nouveaux serveurs en 6.2.X et de migrer.
En tentant de virer le swap (parce qu’il est à 100% de 8Go, problème connu, j’avais sapines à 60) avec swapoff: échec, l’opération termine avec un Killed (pas par moi). J’avais pourtant réussi il y a quelques mois mais sur un autre Proxmox. J’ai donc peut-être bien un Proxmox qui va pas ultra-bien.
Le 17 sept. 2020 à 23:46, Frederic MASSOT frederic@juliana-multimedia.com a écrit : Quelle version de Proxmox ?
Il y a quelques années, j'ai eu un problème avec une version de Proxmox qui avaient des compteurs ou id (je ne sais plus) sur 32 bits, ou bout de quelques années d'uptime les commandes de l'hôte vers les invités ne fonctionnaient plus.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 18/09/2020 à 09:01, Pierre DOLIDON a écrit :
t'as pas une sandbox pour mettre a jour ?
chez nous on upgrade régulièrement, donc pas trop de soucis, mais il fut un temps où on upgradait pas les proxmox. on c'est lancé, on a upgrade de debian7 à 10 (en étapes successives bien sur), et c'est passé comme une lettre à la poste (sauf le cluster, bien sur, mais ça c'est documenté par proxmox).
Idem, mes plus vieilles machines dans mon cluster ont été installées en Proxmox 4. Tout ce petit monde est en 6.2 actuellement.
Seul bémol, on a quelques couple de proxmox qui tournent avec un socle DRBD. comme proxmox a retiré ses packages de ses repository (problème de licence avec linbit...) ben le module drbd kernel de debian8 (fourni par proxmox) a une version supérieure à celui fourni par debian9/10. j'ai du compiler à la mano (c'est pas la panacée...)
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. Ma vie a changée depuis que j'ai fait ça.
Julien
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. Ma vie a changée depuis que j'ai fait ça.
+1. sur ceph depuis 5ans, 0 downtime :)
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Vendredi 18 Septembre 2020 09:35:53 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 18/09/2020 à 09:01, Pierre DOLIDON a écrit :
t'as pas une sandbox pour mettre a jour ?
chez nous on upgrade régulièrement, donc pas trop de soucis, mais il fut un temps où on upgradait pas les proxmox. on c'est lancé, on a upgrade de debian7 à 10 (en étapes successives bien sur), et c'est passé comme une lettre à la poste (sauf le cluster, bien sur, mais ça c'est documenté par proxmox).
Idem, mes plus vieilles machines dans mon cluster ont été installées en Proxmox 4. Tout ce petit monde est en 6.2 actuellement.
Seul bémol, on a quelques couple de proxmox qui tournent avec un socle DRBD. comme proxmox a retiré ses packages de ses repository (problème de licence avec linbit...) ben le module drbd kernel de debian8 (fourni par proxmox) a une version supérieure à celui fourni par debian9/10. j'ai du compiler à la mano (c'est pas la panacée...)
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. Ma vie a changée depuis que j'ai fait ça.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Avec deux nodes?
Linstor a quand même beaucoup progressé, l’intégration est nettement en progrès.
C. Nouvel.
Envoyé de mon iPhone
Le 18 sept. 2020 à 10:05, Alexandre DERUMIER aderumier@odiso.com a écrit :
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. Ma vie a changée depuis que j'ai fait ça.
+1. sur ceph depuis 5ans, 0 downtime :)
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Vendredi 18 Septembre 2020 09:35:53 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 18/09/2020 à 09:01, Pierre DOLIDON a écrit : t'as pas une sandbox pour mettre a jour ?
chez nous on upgrade régulièrement, donc pas trop de soucis, mais il fut un temps où on upgradait pas les proxmox. on c'est lancé, on a upgrade de debian7 à 10 (en étapes successives bien sur), et c'est passé comme une lettre à la poste (sauf le cluster, bien sur, mais ça c'est documenté par proxmox).
Idem, mes plus vieilles machines dans mon cluster ont été installées en Proxmox 4. Tout ce petit monde est en 6.2 actuellement.
Seul bémol, on a quelques couple de proxmox qui tournent avec un socle DRBD. comme proxmox a retiré ses packages de ses repository (problème de licence avec linbit...) ben le module drbd kernel de debian8 (fourni par proxmox) a une version supérieure à celui fourni par debian9/10. j'ai du compiler à la mano (c'est pas la panacée...)
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph. Ma vie a changée depuis que j'ai fait ça.
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Julien,
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph.
On tourne depuis des lustres avec DRBD, ça nous convient. Mais on regarde bien sûr CEPH, alors ton avis m'intéresse :)
Ma vie a changée depuis que j'ai fait ça.
Si tu pouvais m'en dire plus en quelques mots (avec ton contexte).
Ici DRBD est utilisé pour tout, en couple de serveurs, aussi bien en interne qu'en prod (du "ouaib" et du "cloud drive").
Le 18/09/2020 à 10:59, Stéphane Rivière a écrit :
Bonjour Julien,
Mon conseil non-demandé du jour : vire DRBD/Linstor et passe sur Ceph.
On tourne depuis des lustres avec DRBD, ça nous convient. Mais on regarde bien sûr CEPH, alors ton avis m'intéresse :)
+1
Ma vie a changée depuis que j'ai fait ça.
Si tu pouvais m'en dire plus en quelques mots (avec ton contexte).
Ici DRBD est utilisé pour tout, en couple de serveurs, aussi bien en interne qu'en prod (du "ouaib" et du "cloud drive").
+1
de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un cluster... quorum toussa toussa).
Le ven. 18 sept. 2020 à 11:11, Pierre DOLIDON sn4ky@sn4ky.net a écrit :
de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un cluster... quorum toussa toussa).
ll faut 3 noeuds pour les monitors/managers, mais ton 3ème noeud pour les monitors/manager peuvent être sur un autre site, en standalone (un peu comme un arbitre dans un SAN bi-site synchrone). Le cluster d'OSD, si bien configuré peut supporter la perte d'un noeud.
Cyril
Le 18/09/2020 à 11:22, Grosjean Cyril a écrit :
Le ven. 18 sept. 2020 à 11:11, Pierre DOLIDON <sn4ky@sn4ky.net mailto:sn4ky@sn4ky.net> a écrit :
de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un cluster... quorum toussa toussa).ll faut 3 noeuds pour les monitors/managers, mais ton 3ème noeud pour les monitors/manager peuvent être sur un autre site, en standalone (un peu comme un arbitre dans un SAN bi-site synchrone). Le cluster d'OSD, si bien configuré peut supporter la perte d'un noeud.
Trois noeuds mini, tu peux en perdre un ça passe, la resynchro peut être très longue et tueuse de perf pour les disques ou le réseau. Pour le réseau faire un réseau séparé physiquement, Proxmox ne le met pas trop en avant donc par défaut tout le monde le fait passer sur le réseau par défaut, quand ça reconstruit ça va saturer ta capacité en fonction de la vitesse des disques.
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
DRBD c'est bien aussi, c'est surtout très adapté pour 2 noeuds mais malheureusement plus supporté par Proxmox.
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
DRBD c'est bien aussi, c'est surtout très adapté pour 2 noeuds mais malheureusement plus supporté par Proxmox.
Actuellement ici, c'est DRBD, ce dernier étant réseau privé. Les cochons d'un coté, les poules de l'autre, avec chacun sa mangeoire. En cas de resynchro, ça aide 'légèrement'.
Ceph sur trois noeuds dans le moule Proxmox, ça marche quand tout est ok.
Si tu perds un noeuds le quorum en prend un coup comme pour Proxmox mais ça passe.
On a découvert avec douleur qu'un cluster Proxmox trois noeuds qui démarre à froid (coupure courant de nuit dans une entreprise malgré l'onduleur ça n'a pas tenu jusqu'au matin) et qui a un noeud ceph mort (l'équipe sur place faisait une maintenance sur les disques la veille). Ceph refuse de démarrer et donc tu ne peux pas faire repartir. Proxmox dans ce cas on peut toujours dire tel host a un point plus grand pour le quorum et/ou baisser le nombre de voix de chaque membre ça passe. Ceph on a pas trouvé et la seule façon a été de reconfigurer le cluster pour demander une réplication sur 2 noeuds au lieu de 3. Du coup gros travail de Ceph qui a bien saturé ses liens pendant 3 jours mettant des perfs assez faibles pour les vms.
Les réseaux séparés c'est la vie pour tout de toute façon, c'est une best practice dans beaucoup de design d'archi.
Le 18/09/2020 à 13:48, Stéphane Rivière a écrit :
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
DRBD c'est bien aussi, c'est surtout très adapté pour 2 noeuds mais malheureusement plus supporté par Proxmox.
Actuellement ici, c'est DRBD, ce dernier étant réseau privé. Les cochons d'un coté, les poules de l'autre, avec chacun sa mangeoire. En cas de resynchro, ça aide 'légèrement'.
Bonjour,
Le 2020-09-18 13:48, Stéphane Rivière a écrit :
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
CEPH étant (massivement) distribué, il deviens de plus en plus performant avec le volume de disques que tu lui affecte. Selon la documentation, le minimum préconisé est de faire "3 copies", sur "3 machines différentes".
CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de raid sur les disques.
Setup standard CEPH :
+--------------+ +--------------+ +--------------+ | Hôte1 | | Hôte2 | | Hôte3 | | HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 | +--------------+ +--------------+ +--------------+
Ton premier bloc sera sur les disques 1, 3 et 5; Ton second sur les disques 2, 4 et 5; Etc. CEPH s'ammusera à les placer différement à chaque fois.
Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la fragmentation va te faire perdre en performance vis à vis de DRBD. Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu rajoutes de disque, plus ta performance s'améliore :).
Cordialement,
Merci Wallace pour le retex douloureux
Merci Richard, ta réponse générale, qui est limpide !
Dans mon use-case j'en reste donc à DRBD.
Bonjour, Je relance le débat ;-)
Donc, nous tombons d'accord que pour deux nœuds, un cluster CEPH ne fera pas le job.
J'aimerais votre opinion sur une autre possibilité : le RDB mirroring (https://docs.ceph.com/en/latest/rbd/rbd-mirroring/).
Admettons que l'on ai deux nœuds, en particulier si ils sont géographiquement séparés (donc latence, toussa).
Mettons deux disques dans le premier nœud et la crush-map qui va bien pour faire un 'simili' raid1 entre les deux disques avec size=2 (et min_size=1). Le nœud est également MON et MGR.
On a un 'cluster' Ceph autonome, non répliqué. On perd évidemment toute la partie résilience de Ceph, ok.
Maintenant, on créé un second noeud de la même manière et on configure le rdb-mirror pour synchroniser le pool Ceph complet de noeud1 vers noeud2.
C'est du one-way mais rien n'empêche de créer un second pool qui va fasse l'inverse, tant que l'espace disque suite et donc de faire tourner des VMs de chaque côté.
On pourrait même envisager de faire du two-way mirror mais là, ca devient dangereux dans le sens où il faut un mécanisme s'assurant qu'une VM ne tourne pas des deux côtés simultannément sinon c'est la perte de données assurée (et massive). Peut être que le cluster Proxmox peut assurer ce rôle, je ne sais pas.
Je vais probablement me lancer dans un lab sur ce postulat mais avant de perdre du temps sur un détail qui m'échapperait, certains d'entre vous ont-ils un avis ?
Note : ca ferait l'objet d'un magnifique tuto si ça fonctionne.
Merci, Julien
Le 18/09/2020 à 14:00, Richard DEMONGEOT a écrit :
Bonjour,
Le 2020-09-18 13:48, Stéphane Rivière a écrit :
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
CEPH étant (massivement) distribué, il deviens de plus en plus performant avec le volume de disques que tu lui affecte. Selon la documentation, le minimum préconisé est de faire "3 copies", sur "3 machines différentes".
CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de raid sur les disques.
Setup standard CEPH :
+--------------+ +--------------+ +--------------+ | Hôte1 | | Hôte2 | | Hôte3 | | HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 | +--------------+ +--------------+ +--------------+
Ton premier bloc sera sur les disques 1, 3 et 5; Ton second sur les disques 2, 4 et 5; Etc. CEPH s'ammusera à les placer différement à chaque fois.
Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la fragmentation va te faire perdre en performance vis à vis de DRBD. Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu rajoutes de disque, plus ta performance s'améliore :).
Cordialement, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Plus simple dans Proxmox tu fais deux noeuds en zfs local et tu mets des tâches programmées de réplication.
C'est pas temps réel mais c'est pour moi le plus safe quand tu as de la latence entre deux hosts voir pire de la gigue.
Ceph de mes tests n'apprécie pas plus de 5ms de latence il refuse de créer un cluster et s'il a été créé avant, il se met à faire du split brain où chaque noeud estime qu'il est seul.
Notre but était de faire un cluster kube sur plusieurs providers avec un ceph partagé entre eux.
Le 02/10/2020 à 10:11, Julien Escario a écrit :
Bonjour, Je relance le débat ;-)
Donc, nous tombons d'accord que pour deux nœuds, un cluster CEPH ne fera pas le job.
J'aimerais votre opinion sur une autre possibilité : le RDB mirroring (https://docs.ceph.com/en/latest/rbd/rbd-mirroring/).
Admettons que l'on ai deux nœuds, en particulier si ils sont géographiquement séparés (donc latence, toussa).
Mettons deux disques dans le premier nœud et la crush-map qui va bien pour faire un 'simili' raid1 entre les deux disques avec size=2 (et min_size=1). Le nœud est également MON et MGR.
On a un 'cluster' Ceph autonome, non répliqué. On perd évidemment toute la partie résilience de Ceph, ok.
Maintenant, on créé un second noeud de la même manière et on configure le rdb-mirror pour synchroniser le pool Ceph complet de noeud1 vers noeud2.
C'est du one-way mais rien n'empêche de créer un second pool qui va fasse l'inverse, tant que l'espace disque suite et donc de faire tourner des VMs de chaque côté.
On pourrait même envisager de faire du two-way mirror mais là, ca devient dangereux dans le sens où il faut un mécanisme s'assurant qu'une VM ne tourne pas des deux côtés simultannément sinon c'est la perte de données assurée (et massive). Peut être que le cluster Proxmox peut assurer ce rôle, je ne sais pas.
Je vais probablement me lancer dans un lab sur ce postulat mais avant de perdre du temps sur un détail qui m'échapperait, certains d'entre vous ont-ils un avis ?
Note : ca ferait l'objet d'un magnifique tuto si ça fonctionne.
Merci, Julien
Le 18/09/2020 à 14:00, Richard DEMONGEOT a écrit :
Bonjour,
Le 2020-09-18 13:48, Stéphane Rivière a écrit :
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
CEPH étant (massivement) distribué, il deviens de plus en plus performant avec le volume de disques que tu lui affecte. Selon la documentation, le minimum préconisé est de faire "3 copies", sur "3 machines différentes".
CEPH préfère par ailleurs un accès direct au disque, et ne pas avoir de raid sur les disques.
Setup standard CEPH :
+--------------+ +--------------+ +--------------+ | Hôte1 | | Hôte2 | | Hôte3 | | HDD1 HDD2 | | HDD3 HDD4 | | HDD5 HDD6 | +--------------+ +--------------+ +--------------+
Ton premier bloc sera sur les disques 1, 3 et 5; Ton second sur les disques 2, 4 et 5; Etc. CEPH s'ammusera à les placer différement à chaque fois.
Du coup, si tu n'as que 3 disques, les 3 seront "identiques", mais la fragmentation va te faire perdre en performance vis à vis de DRBD. Si tu as 12 disques ou plus, réparti dans plusieurs châssis, tu va pouvoir tirer parti de l'ensemble des axes / ports disques. Et plus tu rajoutes de disque, plus ta performance s'améliore :).
Cordialement, _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le Friday 18 September 2020 13:48:30 Stéphane Rivière a écrit :
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je ne connais pas ceph et pose certainement une question idiote...
Quel serait l'avantage d'avoir a minima 4 nœuds (par rapport à, par exemple, 2 nœuds de prod + un nœud d'arbitrage - ça je comprends l'idée) ?
Question de précision de l'algorithme de répartition des blocs de données (PG en langage ceph). Le manque de précision est du a une optimisation pour trouver plus rapidement le lieu ou est stocké le PG, du coup il y a une variation de quelques pourcents (voir dizaine) entre la quantité de données sur chaque disque. Les paramètres recommandés sont : 3 replicas, 2 nécessaires pour activer les écritures. Si on n'a que 3 noeuds et qu'on en perds un, on n'a pas *exactement* 33% des PG hors ligne, mais un peu plus ou un peu moins, ce qui fait qu'on se retrouve potentiellement avec des écritures bloquées sur une partie du cluster. D'ou le 4 pour avoir une marge de manoeuvre.
Merci à tous pour vos retours, et je suis content que la discussion se soit élargie. Ca me conforte dans mon choix d’avoir arrêter NFS/iSCSI pour le stockage des VM, et de basculer sur du Raidz2 local. C’est moins souple pour migrer une VM, mais je n’ai pas le temps ni les compétences pour gérer du Ceph/DRDB pour le moment.
Le problème de CPU sur mon Proxmox semble avoir presque disparu depuis mon swapoff/swapon. Il reste à 13% pour le moment, on va voir si le swapinness à 10 l’empêcher de monter plus.
Au passage, j’ai découvert un truc important aujourd’hui: ne JAMAIS ajouter de devices à un zPool en utilisant le /dev/sdX. La numérotation peut être modifiée au reboot, et là ZFS s’y perd (j’avais un HD UNAVAIL et l’autre FAULTED, heureusement que je suis en Raidz2….). J’ai pu nettoyer avec un zpool offline, zpool export, puis zpool online. Il utilise maintenant les ID des HD.
Le 18/09/2020 à 20:49, David Ponzone a écrit :
Au passage, j’ai découvert un truc important aujourd’hui: ne JAMAIS ajouter de devices à un zPool en utilisant le /dev/sdX. La numérotation peut être modifiée au reboot, et là ZFS s’y perd (j’avais un HD UNAVAIL et l’autre FAULTED, heureusement que je suis en Raidz2….). J’ai pu nettoyer avec un zpool offline, zpool export, puis zpool online. Il utilise maintenant les ID des HD.
RTFM : c'est dans la doc ça ;-)
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
Julien
Le 20 sept. 2020 à 21:41, Julien Escario julien.escario@altinea.fr a écrit :
Le 18/09/2020 à 20:49, David Ponzone a écrit :
Au passage, j’ai découvert un truc important aujourd’hui: ne JAMAIS ajouter de devices à un zPool en utilisant le /dev/sdX. La numérotation peut être modifiée au reboot, et là ZFS s’y perd (j’avais un HD UNAVAIL et l’autre FAULTED, heureusement que je suis en Raidz2….). J’ai pu nettoyer avec un zpool offline, zpool export, puis zpool online. Il utilise maintenant les ID des HD.
RTFM : c'est dans la doc ça ;-)
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
Alors: 1/ je NRTFM (N = never) :) 2/ maintenant que tu en parles, j’ai fait ce pool là avec Proxmox, dont c’est sa faute à lui
Je vais corriger sur l’autre, mais faut d’abord éteindre toutes les VM, c’est chiant. Mieux vaut maintenant que plus tard ceci dit.
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
tu es certain ?
https://git.proxmox.com/?p=pve-installer.git;a=commit;h=e1b490865f750e08f6c9...
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Dimanche 20 Septembre 2020 21:41:16 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 18/09/2020 à 20:49, David Ponzone a écrit :
Au passage, j’ai découvert un truc important aujourd’hui: ne JAMAIS ajouter de devices à un zPool en utilisant le /dev/sdX. La numérotation peut être modifiée au reboot, et là ZFS s’y perd (j’avais un HD UNAVAIL et l’autre FAULTED, heureusement que je suis en Raidz2….). J’ai pu nettoyer avec un zpool offline, zpool export, puis zpool online. Il utilise maintenant les ID des HD.
RTFM : c'est dans la doc ça ;-)
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/09/2020 à 04:30, Alexandre DERUMIER a écrit :
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
tu es certain ?
https://git.proxmox.com/?p=pve-installer.git;a=commit;h=e1b490865f750e08f6c9...
Très juste, je suis resté sur une idée fausse alors. Vérification faite sur des HV créés cet été, c'est effectivement /dev/disk/by-id/ (et pas /dev/by-id comme indiqué dans le commit).
Julien
T’es en quelle version ? 6.2 Realease ou GIT ?
Parce que moi avec des Promox installés cet été en 6.2.4, c’était /dev/sdX.
Le 21 sept. 2020 à 10:27, Julien Escario julien.escario@altinea.fr a écrit :
Le 21/09/2020 à 04:30, Alexandre DERUMIER a écrit :
D'ailleurs l'installeur de Proxmox est à la ramasse sur cette question : il utilise toujours /dev/sdX au lieu de /dev/disk/by-id/ (ou (by-uuid pour les intrépides).
tu es certain ?
https://git.proxmox.com/?p=pve-installer.git;a=commit;h=e1b490865f750e08f6c9...
Très juste, je suis resté sur une idée fausse alors. Vérification faite sur des HV créés cet été, c'est effectivement /dev/disk/by-id/ (et pas /dev/by-id comme indiqué dans le commit).
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 21/09/2020 à 10:48, David Ponzone a écrit :
T’es en quelle version ? 6.2 Realease ou GIT ?
Parce que moi avec des Promox installés cet été en 6.2.4, c’était /dev/sdX.
# pveversion -v proxmox-ve: 6.2-1 (running kernel: 5.4.41-1-pve)
Donc release, on ne va se lancer dans des trucs exotiques, les releases s'enchaînent déjà bien chez PVE.
# zpool status pool: rpool state: ONLINE scan: scrub repaired 0B in 0 days 00:21:19 with 0 errors on Sun Sep 13 00:45:20 2020 config:
NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNE0N232962-part3 ONLINE 0 0 0 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNE0N232919-part3 ONLINE 0 0 0
Julien
Ah tiens c’est rigolo cette différence. Je viens de vérifier et j’ai bien fait le mien avec le GUI. Par contre, je l’ai fait 2 fois: suite à un problème la première fois, j’avais fait un fdisk sur chaque disque pour les reformater pour pouvoir refaire le pool après un destroy.
Ou alors c’est parce que toi c’est un miroir alors que je suis en RaidZ2.
Le 21 sept. 2020 à 10:59, Julien Escario julien.escario@altinea.fr a écrit :
Donc release, on ne va se lancer dans des trucs exotiques, les releases s'enchaînent déjà bien chez PVE.
# zpool status pool: rpool state: ONLINE scan: scrub repaired 0B in 0 days 00:21:19 with 0 errors on Sun Sep 13 00:45:20 2020 config:
NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNE0N232962-part3 ONLINE 0 0 0 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNE0N232919-part3 ONLINE 0 0 0
Julien
Le ven. 18 sept. 2020 à 13:17, Wallace wallace@morkitu.org a écrit :
Trois noeuds mini, tu peux en perdre un ça passe, la resynchro peut être très longue et tueuse de perf pour les disques ou le réseau.
[...]
Ceph c'est bien à partir de 4 noeuds pour être tranquille.
Je disais pas que c'était recommandé, mais possible (disclaimer : je ne le fais pas tourner dans un modèle 2 noeuds OSDs).
Ceph reste un outil très malléable et peu sensible à la panne, si bien configuré :
Pour un cluster avec 2 OSDs, bien configuré, avec 2 réplicas (au lieu de 3), et une autorisation d'écriture si 2 tiers des monitors voit l'OSD, c'est, je pense, jouable :
- Possible donc d'avoir 2 MON/MGR sur tes noeuds OSD, et un 3ème MON/MGR sur une autre machine, plus petite, pour faire ton quorum - Pas forcément besoin de rebalance si tu as un noeud qui tombe dans cette config, tu reste en dégradé le temps que le noeud revienne. Le rebalance n'arrive qu'au retour du noeud, sur les PG modifiés (ce qui peut être violent si il y a énormément d'écriture, d'où le lien de réplication dédié). - J'ai un cluster, tri-site, replica 3 avec un réplica par site, mais lecture à 1 -> Si je perds un DC (déjà vécu), pas de rebalance entre les 2 autres sites pour corriger (on s'évite une première période merdique), le rebalance est venu après retour du 3ème site. - Tout dépend donc de la crush map et des crushs rules ;)
Donc cela dépend vraiment du risque à la perte de donnée ou au write lock.
Le ven. 18 sept. 2020 à 13:17, Wallace wallace@morkitu.org a écrit :
Pour le réseau faire un réseau séparé physiquement, Proxmox ne le met pas trop en avant donc par défaut tout le monde le fait passer sur le réseau par défaut, quand ça reconstruit ça va saturer ta capacité en fonction de la vitesse des disques.
Lien de réplication inter-noeud OSD indispensable -> Chez nous, on est à 2x10G par noeud OSD.
Pour Ceph, je recommande les docs de Red Hat la dessus, qui sont dispo publiquement et explique bien ce qui est recommandé.
Je ne sais pas ce que propose Proxmox en terme de doc Ceph, je suis en standalone ici.
Cyril
Le 18/09/2020 à 13:15, Wallace a écrit :
DRBD c'est bien aussi, c'est surtout très adapté pour 2 noeuds mais malheureusement plus supporté par Proxmox.
Ici on fait du LVM sur du DRBD. les piles DRBD sont faites à la main (peu d'évolutions, plateformes clientes, 1 VM de prod, 1 VM de test la plupart du temps) Du coup, proxmox n'a pas besoin de savoir qu'il y a un drbd sous la couche LVM.
Le 18/09/2020 à 11:22, Grosjean Cyril a écrit :
Le ven. 18 sept. 2020 à 11:11, Pierre DOLIDON <sn4ky@sn4ky.net mailto:sn4ky@sn4ky.net> a écrit :
de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un cluster... quorum toussa toussa).ll faut 3 noeuds pour les monitors/managers, mais ton 3ème noeud pour les monitors/manager peuvent être sur un autre site, en standalone (un peu comme un arbitre dans un SAN bi-site synchrone). Le cluster d'OSD, si bien configuré peut supporter la perte d'un noeud.
Pas mal de retours intéressants sur cette question de Ceph avec deux noeuds. Je voulais justement faire un lab pour voir ce que ca donne en remplacement d'un cluster DRBD avec deux noeuds.
En 'théorie', avec deux nodes, quatre OSD (deux sur chaque node), deux mon+mgr (un sur chaque node), size = 2, min size = 1.
En gros, un RAID over Ethernet puisque chaque PG sera sur chaque node.
Si on perd TOTALEMENT un node : pas d'impact, et rebalance au redémarrage du node H.S
Si on perd le réseau entre les deux (c'est toujours le scenario stressant) : il se passe quoi exactement ?
En partant du principe que chaque VM a ses propres objects (aka blocks) : je ne vois pas pourquoi il y aurait plus grave comme soucis qu'un resync au moment où le réseau revient ? En quoi le quorum est-il critique dans ce cas ?
Je n'ai pas osé le test encore, je suis peut être complètement à côté de la plaque ...
Merci de vos lumières, Julien
En quoi le quorum est-il critique dans ce cas ?
tu as besoin du quorum pour les moniteurs. (3 moniteurs donc).
size = 2, min size = 1 -> c'est pour les osd uniquement.
en gros, avec 2 monitor, si tu en as un qui est down, tu perd le quorum : le cluster passe en readonly
c'est pour eviter les split-brains.
les clients, ainsi que les osd sont connectés en permanence aux monitors pour voir l'etat du cluster, avoir la map avec les osd down/up, pour injecter tout ca dans l'algo crush pour savoir où lire et ecrire. Imagine le bordel si la moitié des clients/osd voient 1 monitor, et l'autre moitié l'autre monitor.
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Dimanche 20 Septembre 2020 21:49:40 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 18/09/2020 à 11:22, Grosjean Cyril a écrit :
Le ven. 18 sept. 2020 à 11:11, Pierre DOLIDON <sn4ky@sn4ky.net mailto:sn4ky@sn4ky.net> a écrit :
de mémoire, ceph sur 2 noeuds, c'est pas possible ? (puisque c'est un cluster... quorum toussa toussa).
ll faut 3 noeuds pour les monitors/managers, mais ton 3ème noeud pour les monitors/manager peuvent être sur un autre site, en standalone (un peu comme un arbitre dans un SAN bi-site synchrone). Le cluster d'OSD, si bien configuré peut supporter la perte d'un noeud.
Pas mal de retours intéressants sur cette question de Ceph avec deux noeuds. Je voulais justement faire un lab pour voir ce que ca donne en remplacement d'un cluster DRBD avec deux noeuds.
En 'théorie', avec deux nodes, quatre OSD (deux sur chaque node), deux mon+mgr (un sur chaque node), size = 2, min size = 1.
En gros, un RAID over Ethernet puisque chaque PG sera sur chaque node.
Si on perd TOTALEMENT un node : pas d'impact, et rebalance au redémarrage du node H.S
Si on perd le réseau entre les deux (c'est toujours le scenario stressant) : il se passe quoi exactement ?
En partant du principe que chaque VM a ses propres objects (aka blocks) : je ne vois pas pourquoi il y aurait plus grave comme soucis qu'un resync au moment où le réseau revient ? En quoi le quorum est-il critique dans ce cas ?
Je n'ai pas osé le test encore, je suis peut être complètement à côté de la plaque ...
Merci de vos lumières, Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Difficile à dire,
mais au piff, ca pourrait être de la fragmentation mémoire. (ce qui est possible avec un uptime si elevé)
tu as essayé de faire une migration des vms sur un autre noeud, reboot du serveur, et remigration pour comparer ?
----- Mail original ----- De: "David Ponzone" david.ponzone@gmail.com À: "French SysAdmin Group" frsag@frsag.org Envoyé: Jeudi 17 Septembre 2020 20:03:01 Objet: [FRsAG] Proxmox avec gros uptime = problèmes ?
Aux utilisateurs de Promox.
Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans ? Type de problème: certaines VM semblent avoir des problèmes de ressources CPU comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors qu’elles sont à 30-50% de CPU. La charge globale de l’hôte est autour de 50-60%. Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux limites de l’hôte, mais ce n’est pas le cas. J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème mais son uptime est de 8 mois seulement.
Merci de vos retours.
David Ponzone
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
J'ai rarement laissé un hyperviseur allumé autant de temps, je suppose qu'il n'est pas en cluster sinon tu aurais déjà fait le test d'une migration des vms et reboot.
Après ça reste un Linux standard donc sur le host tu dois pouvoir trouver les raisons du ralentissement.
Est-ce que ton swap est bien actif et a une taille pas trop ridicule? C'est quand même l’algorithme de décongestion de la mémoire et même si l'on met une pression sur le swap pour ne pas trop l'utiliser, il est vital d'avoir un swap rapide et en quantité suffisante de l'ordre de 8Go à 16Go pour un hyperviseur.
Le 17/09/2020 à 20:03, David Ponzone a écrit :
Aux utilisateurs de Promox.
Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans ? Type de problème: certaines VM semblent avoir des problèmes de ressources CPU comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors qu’elles sont à 30-50% de CPU. La charge globale de l’hôte est autour de 50-60%. Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux limites de l’hôte, mais ce n’est pas le cas. J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème mais son uptime est de 8 mois seulement.
Merci de vos retours.
David Ponzone
Liste de diffusion du FRsAG http://www.frsag.org/
C’est une hypothèse intéressante car justement, mon swap était full (100% de 8Go, la RAM fait 64Go), j’ai vu ça hier. C’est un problème connu avec la conf par défaut qui a un swapinness à 60. J’ai donc repassé le swapinness à 10 cette nuit, fais un swapoff/swapon qui a terminé ce matin, et là je suis à 12% (ma RAM est pleine à 86/87%, je sais c’est mal de toucher aux limites). Donc on va voir si y a du mieux. Si oui, je vais passer la RAM à 128 ou 256, faut plus s’emmerder avec un truc qui coûte presque rien.
Le 18 sept. 2020 à 10:14, Wallace wallace@morkitu.org a écrit :
J'ai rarement laissé un hyperviseur allumé autant de temps, je suppose qu'il n'est pas en cluster sinon tu aurais déjà fait le test d'une migration des vms et reboot.
Après ça reste un Linux standard donc sur le host tu dois pouvoir trouver les raisons du ralentissement.
Est-ce que ton swap est bien actif et a une taille pas trop ridicule? C'est quand même l’algorithme de décongestion de la mémoire et même si l'on met une pression sur le swap pour ne pas trop l'utiliser, il est vital d'avoir un swap rapide et en quantité suffisante de l'ordre de 8Go à 16Go pour un hyperviseur.
Le 17/09/2020 à 20:03, David Ponzone a écrit :
Aux utilisateurs de Promox.
Avec-vous déjà rencontré des problèmes sur un Proxmox avec un uptime de 3/4 ans ? Type de problème: certaines VM semblent avoir des problèmes de ressources CPU comme si elles n’avaient pas les cycles qu’elles sont censées avoir, alors qu’elles sont à 30-50% de CPU. La charge globale de l’hôte est autour de 50-60%. Si j’avais le problème sur toutes les VM, je pourrais conclure que j’arrive aux limites de l’hôte, mais ce n’est pas le cas. J’ai un autre hôte avec à peu près la même charge et qui n’a pas ce problème mais son uptime est de 8 mois seulement.
Merci de vos retours.
David Ponzone
Liste de diffusion du FRsAG http://www.frsag.org/ http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
je crois me souvenir que depuis les noyaux 3.5, la valeur swapiness ne représente plus un pourcentage. donc si tu veux le maximum en ram, et n'utiliser la swap que si c'est nécessaire, il faut utiliser swapiness = 1
à vérifier
swap, 2020 .. ?
On 9/18/20 10:33 AM, err404@free.fr wrote:
je crois me souvenir que depuis les noyaux 3.5, la valeur swapiness ne représente plus un pourcentage. donc si tu veux le maximum en ram, et n'utiliser la swap que si c'est nécessaire, il faut utiliser swapiness = 1
à vérifier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 18/09/2020 à 10:42, Stéphane Rivière a écrit :
Le 18/09/2020 à 10:37, frsag@jack.fr.eu.org a écrit :
swap, 2020 .. ?
+1000
Ben oui la ram en 2020 c'est encore utilisé, pas pour le dépassement de mémoire car on est tous bien gavé mais c'est utilisé par le kernel pour décongestionner la mémoire, swap c'est un algo pas juste un format de partition. Et si cet algo dans le kernel n'a pas d'espace performant pour travailler ou pas d'espace du tout ça rame même si la mémoire n'est pas totalement utilisée.
Ceux qui ne mettent pas de swap ou qui le mettent tout petit ou pire avec un swapiness à 0 c'est un tueur de performance.
Donc oui pour une petite vm dans un coin ça sert peut être pas à grand chose, pour des hyperviseurs on met 2x128Gb flash en raid 0 que pour le swap et ça permet des gains conséquents.
Après c'est sur que pour de l'hébergement de vm qui font rien ça montrera pas de différence, quand le cluster est chargé ou quand on vise à faire des calculs intensifs alors c'est primordial. La mode des hyperviseurs diskless c'est finit depuis 10 ans quand on veut de la perf.
Ben oui la ram en 2020 c'est encore utilisé, pas pour le dépassement de
.../...> hyperviseurs diskless c'est finit depuis 10 ans quand on veut de la perf.
Manifestement on n'utilise pas la même techno et on n'a pas le même use-case.
Sur un hyperviseur Xen, la mémoire est utilisée pour l'hyperviseur, pas pour les VM. Le seul endroit où la swap est accessible est l'hyperviseur. Les VM n'ont pas, par définition de swap.
La swap est un arrangement qui fut utile et qui est désormais obsolète, tout du moins dans mon use-case. Je dimensionne mes VM en fonction de ce que je fais dessus, additionne la ram et obtient la capa souhaitée du serveur.
Dans ton use-case, il est probable que ta techno permette aux VM de /mutualiser/ de la mémoire surnuméraire de l'hyperviseur (et donc mobiliser la swap), ce que Xen permet mais qui n'est absolument pas (pour Xen tout du moins) une pratique efficiente.
Devoir swapper sur 128 Gb en flash et en raid 0 me semble démontrer que nos use-case sont trop divergents.
Si c'est pas confidentiel, un exemple de use-case et nommer ton hyperviseur me permettrait de comprendre, et donc d'apprendre encore des choses.
De notre coté, nos bécanes roxent et sont stables. On a passé du temps à tout optimiser et valider. Je suis un dinosaure et compte les GB, Mbps, ns et Iops :) Mais ma solution est celle de mon use-case. Elle ne prétend pas à être universelle.
Le ven. 18 sept. 2020 à 13:36, Stéphane Rivière stef@genesix.org a écrit :
La swap est un arrangement qui fut utile et qui est désormais obsolète, tout du moins dans mon use-case.
Ça dépend grandement du use-case effectivement, mais dans la majorité des cas mettre du swap reste utile. Notamment car pas de swap = OOMKill direct si la RAM est saturée. Perso je préfère mettre du swap avec un sonde de monitoring que pas de swap et être réveillé au milieu de la nuit car la moitié des process du serveur ont été tuées. Et l'utilisation du swap peut être optimisée avec vm_swappiness en fonction des workloads.
Un article intéréssant à ce sujet sur le blog de Red Hat : https://www.redhat.com/en/blog/do-we-really-need-swap-modern-systems.
Pour notre part on est sous OpenStack donc KVM. J'ai pratiqué Xen y a 10 ans je valide que Xen n'avait pas la main sur la gestion avancée de la mémoire dans les guests malgré l'agent, je n'ai pas regardé depuis longtemps Xen s'ils ont évolués sur ce point.
VMWare fait aussi cela, on peut dire dans vsphere à ce que les swap des vms soient sur les disques locaux alors que la vm a un seul disque avec le swap dans une partition, je suppose que c'est l'agent vmware qui fait le lien avec l'hyperviseur pour lui dire attention ces écritures sont du swap pour éviter de les mettre sur les datastores.
Dans nos cas d'utilisation, la virtualisation répond aux besoins aussi bien de vms classiques (web, applis métiers, db) qu'aux besoins de calculs en masse où les vms vont connaître une vie assez courte de quelques heures à semaines et seront à 100% cpu tout le long. C'est du bigdata et de l'IA sans besoin de grande vitesse qui tourne dessus. On va déployer des instances gpu pour l'IA plus rapide.
Pour revenir au swap je ne sais pas comment KVM gère cela j'ai pas regardé les sources mais quand tu n'a pas de swap ça marche et ça peut être puissant sur le compute tant qu'on sature pas trop l'IO wait et quand on ajoute les disques swap on a un step de plus avant d'arriver à un décollage de l'iowait et une utilisation du swap qui est assez conséquente.
On a la main système sur 99% des vms de nos clusters, c'est que du Debian avec swapiness entre 1 et 5 en fonction des applications qui tournent, des pressions un peu élevées donc les vms ne swappent que très peu, on garde du swap avec un max à 1/3 de la ram et max 8Go principalement pour éviter l'OOM killer ou lorsque les clients tardent à donner l'accord pour augmenter les ressources.
Et malgré tout cela le swap des hyperviseurs travaillent énormément. Ca se voit beaucoup sur les métrics des IO wait cpu et le temps cpu system qui est très bas.
Le 18/09/2020 à 13:34, Stéphane Rivière a écrit :
Ben oui la ram en 2020 c'est encore utilisé, pas pour le dépassement de
.../...> hyperviseurs diskless c'est finit depuis 10 ans quand on veut de la perf.
Manifestement on n'utilise pas la même techno et on n'a pas le même use-case.
Sur un hyperviseur Xen, la mémoire est utilisée pour l'hyperviseur, pas pour les VM. Le seul endroit où la swap est accessible est l'hyperviseur. Les VM n'ont pas, par définition de swap.
La swap est un arrangement qui fut utile et qui est désormais obsolète, tout du moins dans mon use-case. Je dimensionne mes VM en fonction de ce que je fais dessus, additionne la ram et obtient la capa souhaitée du serveur.
Dans ton use-case, il est probable que ta techno permette aux VM de /mutualiser/ de la mémoire surnuméraire de l'hyperviseur (et donc mobiliser la swap), ce que Xen permet mais qui n'est absolument pas (pour Xen tout du moins) une pratique efficiente.
Devoir swapper sur 128 Gb en flash et en raid 0 me semble démontrer que nos use-case sont trop divergents.
Si c'est pas confidentiel, un exemple de use-case et nommer ton hyperviseur me permettrait de comprendre, et donc d'apprendre encore des choses.
De notre coté, nos bécanes roxent et sont stables. On a passé du temps à tout optimiser et valider. Je suis un dinosaure et compte les GB, Mbps, ns et Iops :) Mais ma solution est celle de mon use-case. Elle ne prétend pas à être universelle.
Je ne peux que seconder cet avis pertinent
Le rationnel derrière est très fort, et s'axe sur plusieurs points.
Tout d'abord, la mémoire volatile s'active à des fréquences beaucoup trop rapide, de nos jours. L'utilisation d'un périphérique de stockage plus lent permet aux CPU de ne pas prendre de décision "dans la hâte", et donc de faire ce qu'il faut. Je note que tu utilises de la flash en raid 0 : il existe des technologies novatrices permettant d'aller encore plus loin : par exemple des disques dur 15k (il existe des modèles 46GB qui sont parfait pour ça).
L'autre point important : toujours faire patienter le client, même lorsque tu sais que tu ne pourra honorer sa requête. Avec un peu de chance, des clients en file d'attente vont "ragequit", ce qui liberera des ressources !
Donc dans le cas de la mémoire, ton applicatif demande 10GB, que tu n'as pas ? Pas de soucis ! Diminue la vitesse d'execution d'un facteur 1000 ! Très vite, l'applicatif n'en aura plus besoin (parce que le client final sera parti ailleurs) ! Et puis au pire, au bout de moultes minutes de souffrance sur l'ensemble de la plateforme, il sera toujours temps de kill -9 l'applicatif en question.
Bref, le swap sur block device, c'est génial. Pourquoi être rapide quand on peut être lent et pourrir le service client ? :)
On 9/18/20 12:42 PM, Wallace wrote:
Le 18/09/2020 à 10:42, Stéphane Rivière a écrit :
Le 18/09/2020 à 10:37, frsag@jack.fr.eu.org a écrit :
swap, 2020 .. ?
+1000
Ben oui la ram en 2020 c'est encore utilisé, pas pour le dépassement de mémoire car on est tous bien gavé mais c'est utilisé par le kernel pour décongestionner la mémoire, swap c'est un algo pas juste un format de partition. Et si cet algo dans le kernel n'a pas d'espace performant pour travailler ou pas d'espace du tout ça rame même si la mémoire n'est pas totalement utilisée.
Ceux qui ne mettent pas de swap ou qui le mettent tout petit ou pire avec un swapiness à 0 c'est un tueur de performance.
Donc oui pour une petite vm dans un coin ça sert peut être pas à grand chose, pour des hyperviseurs on met 2x128Gb flash en raid 0 que pour le swap et ça permet des gains conséquents.
Après c'est sur que pour de l'hébergement de vm qui font rien ça montrera pas de différence, quand le cluster est chargé ou quand on vise à faire des calculs intensifs alors c'est primordial. La mode des hyperviseurs diskless c'est finit depuis 10 ans quand on veut de la perf.
Liste de diffusion du FRsAG http://www.frsag.org/
Le 18/09/2020 à 10:23, David Ponzone a écrit :
C’est une hypothèse intéressante car justement, mon swap était full (100% de 8Go, la RAM fait 64Go), j’ai vu ça hier. C’est un problème connu avec la conf par défaut qui a un swapinness à 60. J’ai donc repassé le swapinness à 10 cette nuit, fais un swapoff/swapon qui a terminé ce matin, et là je suis à 12% (ma RAM est pleine à 86/87%, je sais c’est mal de toucher aux limites). Donc on va voir si y a du mieux. Si oui, je vais passer la RAM à 128 ou 256, faut plus s’emmerder avec un truc qui coûte presque rien.
Encore mieux : mets à jour ton kernel puisque tu vas devoir rebooter pour mettre ta RAM.
De mémoire, j'ai eu aussi ce genre de problèmes et ton message vient de me rappeler sur les nouveaux hôtes, j'ai 'oublié' de changer le swapiness et je n'ai plus de soucis. Si ça se trouve mon sysctl.conf a même été écrasé depuis.
Donc la gestion de la VM (au sens virtual memory) a dû largement évoluer entre un kernel 4.x et 5.x. Le contraire serait étonnant d'ailleurs (merci Captain Obvious).
Julien
La mise à jour kernel ça peut pas faire de mal et même souvent du bien mais dans le cas de proxmox c'est leurs kernel et c'est lié à la version de Proxmox donc ça veut dire maj et à priori ce n'était pas voulu donc warning.
Le 18/09/2020 à 10:41, Julien Escario a écrit :
Encore mieux : mets à jour ton kernel puisque tu vas devoir rebooter pour mettre ta RAM.
De mémoire, j'ai eu aussi ce genre de problèmes et ton message vient de me rappeler sur les nouveaux hôtes, j'ai 'oublié' de changer le swapiness et je n'ai plus de soucis. Si ça se trouve mon sysctl.conf a même été écrasé depuis.
Donc la gestion de la VM (au sens virtual memory) a dû largement évoluer entre un kernel 4.x et 5.x. Le contraire serait étonnant d'ailleurs (merci Captain Obvious).
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 18 sept. 2020 à 10:41, Julien Escario julien.escario@altinea.fr a écrit :
Le 18/09/2020 à 10:23, David Ponzone a écrit :
C’est une hypothèse intéressante car justement, mon swap était full (100% de 8Go, la RAM fait 64Go), j’ai vu ça hier. C’est un problème connu avec la conf par défaut qui a un swapinness à 60. J’ai donc repassé le swapinness à 10 cette nuit, fais un swapoff/swapon qui a terminé ce matin, et là je suis à 12% (ma RAM est pleine à 86/87%, je sais c’est mal de toucher aux limites). Donc on va voir si y a du mieux. Si oui, je vais passer la RAM à 128 ou 256, faut plus s’emmerder avec un truc qui coûte presque rien.
Encore mieux : mets à jour ton kernel puisque tu vas devoir rebooter pour mettre ta RAM.
Après avoir déplacé une VM à problème sur un Proxmox 6.2 presque vide, plus de problème de perf. Donc je pige pas tout, mais la prochaine étape c’est de vider le Proxmox 4 qui va mal pour reboot et upgrade. Parfois, faut pas chercher :)
Merci à tous
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
Le 25/09/2020 à 19:37, David Ponzone a écrit :
Après avoir déplacé une VM à problème sur un Proxmox 6.2 presque vide, plus de problème de perf. Donc je pige pas tout, mais la prochaine étape c’est de vider le Proxmox 4 qui va mal pour reboot et upgrade. Parfois, faut pas chercher :)
Le Friday 25 September 2020 19:53:14 Wallace a écrit :
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
Et si ca rate, formatte ?
Le 25/09/2020 à 19:37, David Ponzone a écrit :
Après avoir déplacé une VM à problème sur un Proxmox 6.2 presque vide, plus de problème de perf. Donc je pige pas tout, mais la prochaine étape c’est de vider le Proxmox 4 qui va mal pour reboot et upgrade. Parfois, faut pas chercher :)
Oui, ça m’emmerde mais bon, 5 ans d’uptime, c’est pas rien. Après ça peut être autre chose: ce Proxmox a du stockage LVM sur iSCSI, pourrait y avoir une merde dans un driver qui provoque des IO-wait anormales même quand la VM est sur le ZFS local. Ca me parait tordu, d’autant plus que le second du cluster a les mêmes volumes LVM/iSCSI et pas du tout les mêmes problèmes. Il a juste un uptime 8 fois plus petit. Ce que je sais par contre, c’est que LVM/iSCSI, c’est un setup à éviter formellement, donc bon…
Ce que je ferai quand j’aurais migré les VM ailleurs (j’en ai pour un moment), c’est remettre une VM qui posait problème dessus, et voir si le problème est toujours là (avec ce coup-ci donc un CPU à 0% et quasi pas d’IO ni local, ni iSCSI). Si oui, c’est bien à priori un problème lié à l’uptime, pas un simple problème de CPU/IO. Ensuite je reboot et si problème disparu, c’est confirmé. Et si je peux pas conclure, tant pis, pas grave :)
Le 25 sept. 2020 à 19:53, Wallace wallace@morkitu.org a écrit :
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
Le 25/09/2020 à 19:37, David Ponzone a écrit :
Après avoir déplacé une VM à problème sur un Proxmox 6.2 presque vide, plus de problème de perf. Donc je pige pas tout, mais la prochaine étape c’est de vider le Proxmox 4 qui va mal pour reboot et upgrade. Parfois, faut pas chercher :)
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour David,
Le ven. 25 sept. 2020 à 20:12, David Ponzone david.ponzone@gmail.com a écrit :
Oui, ça m’emmerde mais bon, 5 ans d’uptime, c’est pas rien. Après ça peut être autre chose: ce Proxmox a du stockage LVM sur iSCSI, pourrait y avoir une merde dans un driver qui provoque des IO-wait anormales même quand la VM est sur le ZFS local. Ca me parait tordu, d’autant plus que le second du cluster a les mêmes volumes LVM/iSCSI et pas du tout les mêmes problèmes. Il a juste un uptime 8 fois plus petit. Ce que je sais par contre, c’est que LVM/iSCSI, c’est un setup à éviter formellement, donc bon…
J'ai peut-être zappé quelque chose mais, pourquoi considères-tu LVM/iSCSI comme à éviter ?
Bon vendredi,
Le 25/09/2020 à 19:53, Wallace a écrit :
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
On est lundi mais je confirme : notamment pour la fameux bug qui empêchait les timestamp des tasks sur X bytes (ce qui arrivait au bout d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne).
La solution, c'était bien DDR (ou patch du bout de code Perl qui gérait ça + restart pvemanager).
Julien
(ce qui arrivait au bout d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne).
497 jours d'uptime, fixé dan la version 3.2 ^_^
https://git.proxmox.com/?p=pve-common.git;a=commit;h=19cec2309dad9487a2fc0a6...
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Lundi 28 Septembre 2020 09:14:48 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 25/09/2020 à 19:53, Wallace a écrit :
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
On est lundi mais je confirme : notamment pour la fameux bug qui empêchait les timestamp des tasks sur X bytes (ce qui arrivait au bout d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne).
La solution, c'était bien DDR (ou patch du bout de code Perl qui gérait ça + restart pvemanager).
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ouah le bug sympa, ça me rappelle les firmwares de disque SSD première gen ...
Le 28/09/2020 à 17:06, Alexandre DERUMIER a écrit :
(ce qui arrivait au bout d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne).
497 jours d'uptime, fixé dan la version 3.2 ^_^
https://git.proxmox.com/?p=pve-common.git;a=commit;h=19cec2309dad9487a2fc0a6...
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Lundi 28 Septembre 2020 09:14:48 Objet: Re: [FRsAG] Proxmox avec gros uptime = problèmes ?
Le 25/09/2020 à 19:53, Wallace a écrit :
On est vendredi je me permet, tu insinues que la méthode DDR (Dans le Doute Reboot) qui colle aux serveurs windows marcherait pour Proxmox? :D
On est lundi mais je confirme : notamment pour la fameux bug qui empêchait les timestamp des tasks sur X bytes (ce qui arrivait au bout d'environ 3 ans d'uptime) en version ... 3 (si ma mémoire est bonne).
La solution, c'était bien DDR (ou patch du bout de code Perl qui gérait ça + restart pvemanager).
Julien _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour Wallace,
Est-ce que ton swap est bien actif et a une taille pas trop ridicule? C'est quand même l’algorithme de décongestion de la mémoire et même si l'on met une pression sur le swap pour ne pas trop l'utiliser, il est vital d'avoir un swap rapide et en quantité suffisante de l'ordre de 8Go à 16Go pour un hyperviseur.
Pourquoi ?
Nos hyperviseurs (Xen) sont sans swap (ou parfois avec 512 Mo suivant la paresse de 'setupeur'), une mémoire allouée (calculée par une formule fournie dans la doc, en fonction du nombre de VM - en général une quinzaine et du système de fichier utilisé, ici ext4/LVM - ce qui donne, avec un peu de mou, autour de 1,5 Go.
Rien ne change avec avec des uptimes déraisonnables (un record involontaire d'environ 1200 jours sur ce type de setup, on ne s'en vante pas).
Ici pour un uptime 118 jours, sur une vieille bécane qui roxe encore son taff avec 13 VM en prod (un SP-64-S OVH)
---------------- total used free shared buffers cached 1467156 1426876 40280 34160 52820 932080 -/+ buffers/cache: 441976 1025180 Swap: 0 0 0 ----------------
Et là dedans t'as la fonction routage/firewalling pour distribuer les IP des VM, ce qui nous évite une VM de routage, augmente les perfs et allège le setup. Juste du Xen, LVM, DRBD. Par contre, que de la CLI mais les besoins d'interface de Proxmox ne doivent pas être importants.
Donc je vois pas pourquoi un setup Proxmox/KVM serait différent... mais je connais pas trop Proxmox. Si tu peux m'expliquer, ça m'intéresse :)
-
Alexandre DERUMIER -
Charles Koprowski -
Christophe Nouvel -
David Ponzone -
err404＠free.fr -
Frederic MASSOT -
frsag＠jack.fr.eu.org -
Grosjean Cyril -
Jonathan Leroy - Inikup -
Julien Escario -
Paul Rolland (ポール・ロラン) -
Pierre DOLIDON -
Richard DEMONGEOT -
Stéphane Rivière -
Vincent Tondellier -
Wallace