salut
déplacé de zevenet (dernière version disponible de ce, entièrement à jour) vers relianoid 7.1 en utilisant le script
tout semble ok mais le statut des fermes, qui est toujours « down » même si tout va bien
existe-t-il un journal dans lequel je peux plonger pour comprendre pourquoi ?
NOTRE
Stefano
Ciao Stefano, quel type de ferme utilisez-vous ?
L'état de la batterie est contrôlé par un fichier PID créé sous le chemin /var/run. Vous pouvez consulter les journaux dans /var/log/syslog à la recherche de certaines erreurs.
N'hésitez pas non plus à générer une sauvegarde de support via Système > Sauvegarde de support et à l'envoyer via support@relianoid.com
Kind Regards.
Salut, merci pour votre réponse
J'utilise des fermes http (c'est une situation assez simple), 2 ips virtuelles, 2 certificats, environ 10 services.
Va vérifier les journaux et faire un rapport
Merci beaucoup
me voici, encore une fois
J'ai créé une nouvelle VM à partir de Relianoid ce iso et restauré la sauvegarde que j'ai prise sur la machine de production
Je rencontre le problème sabe :
dans l'interface Web, je vois des fermes en état Critique, mais il n'y a aucune erreur dans syslog et je vois que tout fonctionne comme prévu.
J'ai fouillé partout et il n'y a aucune erreur, dans aucun fichier journal sur la machine.
Quelqu'un peut-il donner un indice pour comprendre pourquoi ?
Et plus encore, puis-je suggérer de le rendre plus facile à comprendre ? Je veux dire, si je vois un état critique sur un service, j'aimerais savoir exactement quoi vérifier et/ou pourquoi j'ai un tel état.
Merci beaucoup
Bonjour Stéfano,
Veuillez vous référer à la documentation expliquant les codes couleur pour les batteries HTTP et L4.
Le statut « critique » signifierait qu’aucun backend n’est disponible pour acheminer le trafic. Vous pouvez désactiver temporairement les vérifications avancées de Farm Guardian simplement pour confirmer que les scripts de santé n'affectent pas l'état des backends.
Hope that helps,
Cordialement.
Salut, le statut que je vois est
Noir : Indique un dommage CRITIQUE. La ferme est UP mais aucun backend n'est disponible ou ils sont en mode maintenance.
Mais toutes les fermes fonctionnent comme prévu, les backends sont opérationnels et même farmguardian me dit que tout va bien.
2024-02-27T15:41:26.055263+01:00 svlinproxy farmguardian[243748] : (INFO) Ferme Filasolutions8443 – Service pss – timetocheck 15 – portadmin /tmp/Filasolutions8443_proxy.socket – commande check_ping -H HOST -w 2,100 XNUMX
2024-02-27T15:41:26.084935+01:00 svlinproxy farmguardian[243757] : (INFO) Farm FilasolutionsSSL – Service d'assistance – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – commande check_ping -H HOST -w 2,100 XNUMX
2024-02-27T15:41:26.220633+01:00 svlinproxy farmguardian[243756] : (INFO) Ferme FilasolutionsSSL – Service vault – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – commande check_ping -H HOST -w 2,100 XNUMX
2024-02-27T15:41:26.243783+01:00 svlinproxy farmguardian[243754] : (INFO) Ferme FilasolutionsSSL – Service zucchetti – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – commande check_ping -H HOST -w 2,100 XNUMX
2024-02-27T15:41:27.059237+01:00 svlinproxy farmguardian[243748] : (INFO) Ferme Filasolutions8443 – Service pss – serveur[0] 192.168.0.63:8443 – statut actif – délai d'attente 0 – code d'erreur 0
2024-02-27T15:41:27.089533+01:00 svlinproxy farmguardian[243757] : (INFO) Farm FilasolutionsSSL – Service d'assistance – serveur[0] 192.168.0.26:443 – statut actif – délai d'attente 0 – code d'erreur 0
2024-02-27T15: 41: 27.224939 + 01: 00 svlinproxy farmguardian [243756]: (INFO) Farm FilasolutionsSSL – Coffre de service – serveur [0] 192.168.0.26:443 – statut actif – délai d'attente 0 – code d'erreur 0
2024-02-27T15:41:27.246284+01:00 svlinproxy farmguardian[243754] : (INFO) Farm FilasolutionsSSL – Service zucchetti – serveur[0] 192.168.0.53:443 – statut actif – délai d'attente 0 – code d'erreur 0
j'ai essayé de désactiver farmguardian pendant 10 minutes et rien n'a changé
Si farmguardian ne détecte pas les backends, il s'agit probablement du proxy inverse. Veuillez vérifier l'état des backends avec la commande :
root@noid-ce:~# /usr/local/relianoid/app/pound/sbin/poundctl -c /tmp/ _proxy.socket
Cheers.
me suggérez-vous d'exécuter cette commande ?
Je n'ai pas de fichier _proxy.socket dans /tmp/
drwxr-xr-x 18 racine racine 4096 27 février 11:32 ..
-rw-r—– 1 racine racine 257 27 février 15:41 cgisess_8acf41d0126e16025b8e9a4e1e7b65ed
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXB3dCwQ
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXeCrs2m
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXiGNzgR
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXlo8cwj
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXOhLVuo
drwx—— 2 racine racine 4096 13 février 14:45 cherokee.XXXXXYQraxU
-rw-r–r– 1 racine racine 0 27 février 15h55 err.log
-rw-r–r– 1 racine racine 0 27 février 15:30 Filasolutions8443.lock
-rw-r–r– 1 racine racine 0 13 février 14:45 Filasolutions.lock
-rw-r–r– 1 racine racine 0 27 février 15:30 FilasolutionsSSL.lock
drwxrwxrwt 2 racine racine 4096 13 février 14:45 .font-unix
drwxrwxrwt 2 racine racine 4096 13 février 14:45 .ICE-unix
drwx—— 3 racine racine 4096 13 février 14:45 systemd-private-1934d9d6cd3240bdb4bb58b5145b9b06-systemd-logind.service-wsM0ZT
drwx—— 3 racine racine 4096 13 février 14:45 systemd-private-1934d9d6cd3240bdb4bb58b5145b9b06-systemd-timesyncd.service-Iuq6QT
drwxrwxrwt 2 racine racine 4096 13 février 14:45 .X11-unix
drwxrwxrwt 2 racine racine 4096 13 février 14:45 .XIM-unix
Dans le cas d'une ferme HTTP, vous devez avoir un processus « pound » en cours d'exécution qui doit ouvrir un socket de contrôle défini dans la directive « Control » du fichier de configuration de la ferme « /usr/local/relianoid/config/FARM-NAME_proxy.cfg ». Vous pouvez ensuite exécuter la commande ctl sur ce socket défini dans la configuration de la ferme.
root@noid-ce:~# /usr/local/relianoid/app/pound/sbin/poundctl -c /tmp/ _proxy.socket
Si le socket est défini mais n'existe pas, cela pourrait être le problème de statut rencontré. Le redémarrage de la batterie devrait régénérer le fichier socket.
Cheers.
root@svlinproxy:/usr/local/relianoid/config# ls -la *_proxy.cfg
-rw-r–r– 1 racine racine 1863 27 février 16:26 Filasolutions8443_proxy.cfg
-rw-r–r– 1 racine racine 1878 13 février 14:45 Filasolutions_proxy.cfg
-rw-r–r– 1 racine racine 2586 27 février 15:30 FilasolutionsSSL_proxy.cfg
pas de directive Control dans mes fichiers _proxy.cfg
root@svlinproxy:/usr/local/relianoid/config# grep -i contrôle *_proxy.cfg
root@svlinproxy:/usr/local/relianoid/config#
root@svlinproxy:/usr/local/relianoid/config# ps aux | grep pound
racine 901 0.0 0.0 61548 2180 ? Ss 13 févr. 0:00 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions_proxy.cfg -p /var/run/Filasolutions_proxy.pid
racine 902 0.0 0.0 193140 3420 13 0 ? Sl 29 févr. XNUMX:XNUMX /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions_proxy.cfg -p /var/run/Filasolutions_proxy.pid
racine 243330 0.0 0.0 61672 2380 ? Ss 15:30 0:00 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/FilasolutionsSSL_proxy.cfg -p /var/run/FilasolutionsSSL_proxy.pid
racine 243331 0.0 0.2 1049524 9632 ? Sl 15:30 0:01 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/FilasolutionsSSL_proxy.cfg -p /var/run/FilasolutionsSSL_proxy.pid
racine 246138 0.0 0.0 61672 2364 ? Ss 16:26 0:00 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions8443_proxy.cfg -p /var/run/Filasolutions8443_proxy.pid
racine 246139 0.0 0.1 127728 6480 ? Sl 16:26 0:00 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions8443_proxy.cfg -p /var/run/Filasolutions8443_proxy.pid
racine 246758 0.0 0.0 6332 2132 pts/0 S+ 16:40 0:00 grep livre
root@svlinproxy:/usr/local/relianoid/config#
root@svlinproxy:/usr/local/relianoid/config# netstat -napt | grep pound
tcp 0 0 10.10.10.2:443 0.0.0.0:* ECOUTER 243330/livre
tcp 0 0 10.10.10.2:8443 0.0.0.0:* ECOUTER 246138/livre
tcp 0 0 10.10.10.2:80 0.0.0.0:* ECOUTER 901/livre
Merci beaucoup
Redémarré toutes les fermes à plusieurs reprises
ok, j'ai peut-être trouvé le problème
Lorsque j'ai mis à niveau mon zevenet vers Relinoid, les fichiers _proxy.cfg n'ont pas été recréés.
Je peux voir la directive Control dans mes modèles
root@svlinproxy:/usr/local/relianoid/share# grep -i control *.cfg
poundtpl.cfg : Contrôle « /tmp/[DESC]_proxy.socket »
proxytpl.cfg : Contrôle « /tmp/[DESC]_proxy.socket »
mais rien dans les profils/fermes importés/restaurés/migrés
Comment puis-je régénérer mes fichiers cfg sans recommencer à zéro ?
Merci
Le modèle de configuration du proxy se trouve sous /usr/local/relianoid/share/poundtpl.cfg et doit inclure cette directive. Comment avez-vous créé de telles fermes ? Avez-vous importé une sauvegarde ?
Merci,
Vous pouvez modifier le fichier de configuration de chaque batterie proxy et ajouter la directive Control sous la forme :
Contrôlez «/tmp/FARMNAME_proxy.socket»
Juste avant la directive ListenHTTP(S). Redémarrez ensuite les fermes et elles devraient créer le socket de contrôle.
Cheers.
ok, récapitulons l'histoire
J'avais un zevenet 5 CE et je l'ai migré vers Relianoid 7 avec votre script
tout s'est bien passé, mais le statut critique de la ferme
J'ai ensuite installé, à des fins de tests, une nouvelle VM directement depuis l'iso de Relinoid 7 CE et restauré une sauvegarde issue de la machine de production.
dans les deux cas, je vois l'état critique, même si sur celui de production, tout fonctionne, comme dit, correctement (apparemment)
Comment puis-je régénérer/mitrer mes fichiers de configuration ?
Il semble que quelque chose manque dans la migration depuis Zevenet
Merci beaucoup
Avez-vous suivi ce guide ?
Migration de Zevenet CE vers RELIANOID Édition communautaire de l'équilibreur de charge ADC
Ou quel script as-tu utilisé ?
Merci.