Hallo zusammen
von Zevenet (letzte verfügbare CE-Version, vollständig auf dem neuesten Stand) auf Relianoid 7.1 mit dem Skript verschoben
alles scheint in Ordnung zu sein, aber der Status der Farmen ist immer „down“, auch wenn alles in Ordnung ist
Gibt es ein Protokoll, in das ich eintauchen kann, um zu verstehen, warum?
TIA
Stefano
Ciao Stefano, welche Art von Farmen nutzt du?
Der Farmstatus wird durch eine PID-Datei gesteuert, die unter dem Pfad /var/run erstellt wird. Sie können die Protokolle in /var/log/syslog auf Fehler überprüfen.
Sie können auch gerne einen Support-Save über System > Support-Save erstellen und ihn über support@relianoid.com
Mit freundlichen Grüßen.
Hallo, danke für deine Antwort
Ich verwende HTTP-Farmen (es ist eine ziemlich einfache Situation), 2 virtuelle IPs, 2 Zertifikate, ungefähr 10 Dienste …
Ich werde die Protokolle überprüfen und berichten
Vielen Dank.
hier bin ich wieder
Ich habe eine neue VM aus Relianoid ce iso erstellt und das Backup wiederhergestellt, das ich auf der Produktionsmaschine erstellt habe
Ich habe das folgende Sabe-Problem:
In der Weboberfläche sehe ich Farmen im Status „Kritisch“, aber es gibt keine Fehler im Syslog und ich sehe, dass alles wie erwartet funktioniert.
Ich habe überall gesucht und es gibt überhaupt keine Fehler, in keiner Protokolldatei auf dem Computer.
Kann jemand einen Hinweis geben, warum?
Und außerdem: Darf ich vorschlagen, es verständlicher zu machen? Ich meine, wenn ich einen kritischen Zustand bei einem Dienst sehe, möchte ich genau wissen, was ich überprüfen muss und/oder warum ich einen solchen Zustand habe.
Vielen Dank.
Hallo Stefano,
Bitte beachten Sie die Dokumentation, in der die Farbcodes für HTTP- und L4-Farmen erläutert werden.
Der Status „kritisch“ bedeutet, dass keine Backends für die Bereitstellung des Datenverkehrs verfügbar sind. Sie können die erweiterten Farm Guardian-Prüfungen vorübergehend deaktivieren, um sicherzustellen, dass die Integritätsskripte den Status der Backends nicht beeinträchtigen.
Hoffe das hilft,
Viele Grüße.
Hallo, der Status, den ich sehe, ist
Schwarz: Zeigt einen KRITISCHEN Schaden an. Die Farm ist aktiv, aber es ist kein Backend verfügbar oder sie befindet sich im Wartungsmodus.
Aber alle Farmen funktionieren wie erwartet, die Backends sind einsatzbereit und sogar Farmguardian sagt mir, dass alles in Ordnung ist
2024-02-27T15:41:26.055263+01:00 svlinproxy farmguardian[243748]: (INFO) Farm Filasolutions8443 – Service pss – timetocheck 15 – portadmin /tmp/Filasolutions8443_proxy.socket – Befehl check_ping -H HOST -w 2,100
2024-02-27T15:41:26.084935+01:00 svlinproxy farmguardian[243757]: (INFO) Farm FilasolutionsSSL – Service-Helpdesk – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – Befehl check_ping -H HOST -w 2,100
2024-02-27T15:41:26.220633+01:00 svlinproxy farmguardian[243756]: (INFO) Farm FilasolutionsSSL – Service Vault – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – Befehl check_ping -H HOST -w 2,100
2024-02-27T15:41:26.243783+01:00 svlinproxy farmguardian[243754]: (INFO) Farm FilasolutionsSSL – Service zucchetti – timetocheck 15 – portadmin /tmp/FilasolutionsSSL_proxy.socket – command check_ping -H HOST -w 2,100
2024-02-27T15:41:27.059237+01:00 svlinproxy farmguardian[243748]: (INFO) Farm Filasolutions8443 – Service pss – Server[0] 192.168.0.63:8443 – Status aktiv – Timeout 0 – Fehlercode 0
2024-02-27T15:41:27.089533+01:00 svlinproxy farmguardian[243757]: (INFO) Farm FilasolutionsSSL – Service Helpdesk – Server[0] 192.168.0.26:443 – Status aktiv – Timeout 0 – Fehlercode 0
2024-02-27T15:41:27.224939+01:00 svlinproxy farmguardian[243756]: (INFO) Farm FilasolutionsSSL – Service Vault – Server[0] 192.168.0.26:443 – Status aktiv – Timeout 0 – Fehlercode 0
2024-02-27T15:41:27.246284+01:00 svlinproxy farmguardian[243754]: (INFO) Farm FilasolutionsSSL – Service zucchetti – server[0] 192.168.0.53:443 – status active – timedout 0 – errorcode 0
habe versucht, Farmguardian für 10 Minuten zu deaktivieren, aber es hat sich nichts geändert
Wenn Farmguardian die Backends nicht erkennt, liegt es wahrscheinlich am Reverse-Proxy. Bitte überprüfen Sie den Status der Backends mit dem folgenden Befehl:
root@noid-ce:~# /usr/local/relianoid/app/pound/sbin/poundctl -c /tmp/ _proxy.socket
Cheers.
schlagen Sie mir vor, diesen Befehl auszuführen?
Ich habe keine _proxy.socket-Datei in /tmp/
drwxr-xr-x 18 root root 4096 27. Feb. 11:32 ..
-rw-r—– 1 Wurzel Wurzel 257 27. Feb. 15:41 cgisess_8acf41d0126e16025b8e9a4e1e7b65ed
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXXB3dCwQ
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXXeCrs2m
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXXiGNzgR
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXXlo8cwj
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXXOhLVuo
drwx—— 2 root root 4096 Feb 13 14:45 cherokee.XXXXYYQraxU
-rw-r–r– 1 root root 0 27. Feb. 15:55 err.log
-rw-r–r– 1 root root 0 Feb 27 15:30 Filasolutions8443.lock
-rw-r–r– 1 root root 0 Feb 13 14:45 Filasolutions.lock
-rw-r–r– 1 root root 0 Feb 27 15:30 FilasolutionsSSL.lock
drwxrwxrwt 2 root root 4096 Feb 13 14:45 .font-unix
drwxrwxrwt 2 root root 4096 Feb 13 14:45 .ICE-unix
drwx—— 3 root root 4096 Feb 13 14:45 systemd-private-1934d9d6cd3240bdb4bb58b5145b9b06-systemd-logind.service-wsM0ZT
drwx—— 3 root root 4096 13. Feb. 14:45 systemd-private-1934d9d6cd3240bdb4bb58b5145b9b06-systemd-timesyncd.service-Iuq6QT
drwxrwxrwt 2 root root 4096 Feb 13 14:45 .X11-unix
drwxrwxrwt 2 root root 4096 13. Februar 14:45 .XIM-unix
Handelt es sich um eine HTTP-Farm, sollte ein „Pound“-Prozess laufen, der einen Control-Socket öffnet, der in der Direktive „Control“ der Farm-Konfigurationsdatei „/usr/local/relianoid/config/FARM-NAME_proxy.cfg“ definiert ist. Anschließend kann der Befehl ctl über den in der Farm-Konfiguration definierten Socket ausgeführt werden.
root@noid-ce:~# /usr/local/relianoid/app/pound/sbin/poundctl -c /tmp/ _proxy.socket
Wenn der Socket definiert ist, aber nicht existiert, könnte dies das Problem sein. Ein Neustart der Farm sollte die Socket-Datei neu generieren.
Cheers.
root@svlinproxy:/usr/local/relianoid/config# ls -la *_proxy.cfg
-rw-r–r– 1 root root 1863 Feb 27 16:26 Filasolutions8443_proxy.cfg
-rw-r–r– 1 root root 1878 Feb 13 14:45 Filasolutions_proxy.cfg
-rw-r–r– 1 root root 2586 Feb 27 15:30 FilasolutionsSSL_proxy.cfg
keine Control-Direktive in meinen _proxy.cfg-Dateien
root@svlinproxy:/usr/local/relianoid/config# grep -i control *_proxy.cfg
root@svlinproxy:/usr/local/relianoid/config#
root@svlinproxy:/usr/local/relianoid/config# ps aux | grep pound
root 901 0.0 0.0 61548 2180 ? Ss Feb13 0:00 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions_proxy.cfg -p /var/run/Filasolutions_proxy.pid
root 902 0.0 0.0 193140 3420 ? Sl Feb13 0:29 /usr/local/relianoid/app/pound/sbin/pound -f /usr/local/relianoid/config/Filasolutions_proxy.cfg -p /var/run/Filasolutions_proxy.pid
root 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
root 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
root 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
root 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
root 246758 0.0 0.0 6332 2132 pts/0 S+ 16:40 0:00 grep pound
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:* LISTEN 243330/Pfund
tcp 0 0 10.10.10.2:8443 0.0.0.0:* LISTEN 246138/Pfund
tcp 0 0 10.10.10.2:80 0.0.0.0:* LISTEN 901/Pfund
Vielen Dank.
Alle Farmen viele, viele Male neu gestartet
ok, vielleicht habe ich das Problem gefunden
Als ich mein Zevenet auf Relinoid aktualisiert habe, wurden die _proxy.cfg-Dateien nicht neu erstellt.
Ich kann die Control-Direktive in meinen Vorlagen sehen
root@svlinproxy:/usr/local/relianoid/share# grep -i control *.cfg
poundtpl.cfg:Steuerung „/tmp/[DESC]_proxy.socket“
proxytpl.cfg:Steuerung „/tmp/[DESC]_proxy.socket“
aber nichts in importierten/wiederhergestellten/migrierten Profilen/Farmen
Wie kann ich meine CFG-Dateien neu generieren, ohne von vorne beginnen zu müssen?
Danke
Die Vorlage für die Proxy-Konfiguration befindet sich unter /usr/local/relianoid/share/poundtpl.cfg und sollte eine solche Anweisung enthalten. Wie hast du solche Farmen erstellt? Hast du ein Backup eingespielt?
Vielen Dank,
Sie können die Farmkonfigurationsdatei jeder Proxyfarm bearbeiten und die Control-Direktive in folgender Form hinzufügen:
Steuerung „/tmp/FARMNAME_proxy.socket“
Direkt vor der ListenHTTP(S)-Direktive. Starten Sie dann die Farmen neu und sie sollten den Steuer-Socket erstellen.
Cheers.
ok, lassen Sie uns die Geschichte rekapitulieren
Ich hatte ein Zevenet 5 CE und habe es mit Ihrem Skript auf Relianoid 7 migriert
alles lief reibungslos, aber der kritische Zustand der Farm
Ich habe dann zu Testzwecken eine neue VM direkt von Relinoid 7 CE iso installiert und ein Backup der Produktionsmaschine wiederhergestellt
bei beiden sehe ich den kritischen Status, auch wenn auf dem Produktionsserver, wie gesagt, alles ok funktioniert (anscheinend)
Wie kann ich meine Konfigurationsdateien neu generieren/minimieren?
Es scheint, dass bei der Migration von Zevenet etwas fehlt.
Vielen Dank.
Haben Sie diese Anleitung befolgt?
Migration von Zevenet CE nach RELIANOID ADC Load Balancer Community Edition
Oder welches Skript hast du verwendet?
Danke.