In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie Sie Statusprobleme mit der Cisco Policy Suite (CPS)-Diameter Routing Agent (DRA) Virtual Machine (VM) behebenJOINING.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Linux
- CPS
Hinweis: Cisco empfiehlt, dass Sie über Berechtigungen für den Root-Zugriff auf die CPS DRA-CLI verfügen müssen.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- CPS-DRA 22,2
- Unified Computing System (UCS)-B
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Der CPS Virtual Diameter Routing Agent (vDRA) dient als Betriebskomponente innerhalb eines Netzwerks und leitet Nachrichten mithilfe von Routing-Algorithmen zu den gewünschten Zielknoten.
Die zentrale Rolle von CPS vDRA umfasst das Routing von Nachrichten und die anschließende Übertragung von Antworten an die ursprünglichen Ursprungspunkte.
CPS vDRA umfasst eine Reihe virtueller Systeme (VMs), die mithilfe von Docker-Engines als Cluster orchestriert sind, und besteht aus unterschiedlichen Einheiten, nämlich Master-, Steuerungs-, Director-, Distributor- und Worker-VMs.
admin@orchestrator[master-1]# show docker engine
Fri Jul 14 09:36:18.635 UTC+00:00
MISSED
ID STATUS PINGS
----------------------------------
control-1 CONNECTED 0
control-2 CONNECTED 0
director-1 CONNECTED 0
director-2 CONNECTED 0
director-3 CONNECTED 0
director-4 CONNECTED 0
director-5 CONNECTED 0
director-6 CONNECTED 0
director-7 CONNECTED 0
director-8 CONNECTED 0
distributor-1 CONNECTED 0
distributor-2 CONNECTED 0
distributor-3 CONNECTED 0
distributor-4 CONNECTED 0
master-1 CONNECTED 0
worker-1 CONNECTED 0
worker-2 CONNECTED 0
worker-3 CONNECTED 0
admin@orchestrator[master-1]#
Status - Zeigt an, ob die Planungsanwendung mit der Docker-Engine verbunden ist und auf einem Host ausgeführt wird.
Verpasste Pings - Die Anzahl aufeinander folgender verpasster Pings für einen Host.
Problem
Manchmal wird CPS vDRA VM aus verschiedenen Gründen im JOINING-Status festgehalten.
admin@orchestrator[master-1]# show docker engine
Fri Jul 14 09:36:18.635 UTC+00:00
MISSED
ID STATUS PINGS
----------------------------------
control-1 CONNECTED 0
control-2 CONNECTED 0
director-1 JOINING 57
director-2 JOINING 130
director-3 JOINING 131
director-4 JOINING 130
director-5 JOINING 30
director-6 JOINING 129
distributor-1 CONNECTED 0
distributor-2 CONNECTED 0
distributor-3 CONNECTED 0
distributor-4 CONNECTED 0
master-1 CONNECTED 0
worker-1 CONNECTED 0
worker-2 CONNECTED 0
worker-3 CONNECTED 0
admin@orchestrator[master-1]#
Die möglichen Gründe für VM, im
JOINING Status festzuhalten.
1. Die VM ist von der Master-VM nicht erreichbar.
1.1. Überprüfen Sie, ob sich die Webverbindungen des betroffenen virtuellen Systems im Hülsenmodus befinden.
Hinweis: WebNet erstellt ein virtuelles Netzwerk, das Docker-Container verbindet, die über mehrere Hosts verteilt sind, und deren automatische Erkennung ermöglicht. Mit WebNet können portable, aus mehreren Containern bestehende Mikroservice-Anwendungen überall ausgeführt werden: auf einem Host, auf mehreren Hosts oder sogar zwischen Cloud-Anbietern und Rechenzentren. Anwendungen verwenden das Netzwerk so, als wären alle Container an denselben Netzwerk-Switch angeschlossen, ohne Port-Zuordnungen, Botschafter oder Links zu konfigurieren.
CPS-DRA verfügt über zwei primäre Bindungszustände: Fastdp und Manschette. Die Präferenz innerhalb des CPS-DRA-Clusters ist konsequent auf Webverbindungen im
fastdp Zustand ausgerichtet.
cps@director-1:~$ weave status connections
-> xx.xx.xx.xx:6783 established sleeve 4e:5f:58:99:d5:65(worker-1) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve 76:33:17:3a:c7:ec(worker-2) mtu=1438
<- xx.xx.xx.xx:54751 established sleeve 76:3a:e9:9b:24:84(director-1) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve 6e:62:58:a3:7a:a0(director-2) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve de:89:d0:7d:b2:4e(director-3) mtu=1438
1.2. Überprüfen Sie, ob diese Protokollmeldungen im
journalctl Protokoll des betroffenen virtuellen Systems vorhanden sind.
2023-08-01T10:20:25.896+00:00 docker-engine Docker engine control-1 is unreachable
2023-08-01T10:20:25.897+00:00 docker-engine Docker engine control-2 is unreachable
2023-08-01T10:20:25.935+00:00 docker-engine Docker engine distributor-1 is unreachable
2023-08-01T10:20:25.969+00:00 docker-engine Docker engine worker-1 is unreachable
INFO: 2023/08/02 20:46:26.297275 overlay_switch ->[ee:87:68:44:fc:6a(worker-3)] fastdp timed out waiting for vxlan heartbeat
INFO: 2023/08/02 20:46:26.297307 overlay_switch ->[ee:87:68:44:fc:6a(worker-3)] using sleeve
2. VM-Festplattenspeicher wird aufgebraucht.
2.1. Überprüfen Sie die Festplattenspeichernutzung auf dem betroffenen virtuellen System und identifizieren Sie die Partition mit hoher Festplattenspeichernutzung.
cps@control-2:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 32G 0 32G 0% /dev
tmpfs 6.3G 660M 5.7G 11% /run
/dev/sda3 97G 97G 0 100% /
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 32G 0 32G 0% /sys/fs/cgroup
/dev/sdb1 69G 4.7G 61G 8% /data
/dev/sda1 180M 65M 103M 39% /boot
/dev/sdb2 128G 97G 25G 80% /stats
overlay 97G 97G 0 100% /var/lib/docker/overlay2/63854e8173b46727e11de3751c450037b5f5565592b83112a3863febf3940792/merged
overlay 97G 97G 0 100% /var/lib/docker/overlay2/a86da2c7a289dc2b71359654c5160a9a8ae334960e78def78e6eecea95855853/merged
overlay 97G 97G 0 100% /var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged
overlay 97G 97G 0 100% /var/lib/docker/overlay2/49ee42311e82974707a6041d82e6c550004d1ce25349478bb974cc017a84aff5/merged
cps@control-2:~$
Verfahren zur Wiederherstellung von CPS-DRA VMs aus dem ZUSTAND JOINING
Ansatz 1.
Wenn die VM von der Master-VM aus nicht erreichbar ist, gehen Sie folgendermaßen vor.
1. Überprüfen Sie den Webverbindungsstatus auf den betroffenen VM/s, wenn es sich um einen Hülsenmodus handelt.
#weave connection status
Sample output:
cps@director-1:~$ weave status connections
-> xx.xx.xx.xx:6783 established sleeve 4e:5f:58:99:d5:65(worker-1) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve 76:33:17:3a:c7:ec(worker-2) mtu=1438
<- xx.xx.xx.xx:54751 established sleeve 76:3a:e9:9b:24:84(director-1) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve 6e:62:58:a3:7a:a0(director-2) mtu=1438
-> xx.xx.xx.xx:6783 established sleeve de:89:d0:7d:b2:4e(director-3) mtu=1438
2. Starten Sie die Webung auf den entsprechenden virtuellen Rechnern neu.
#docker restart weave
3. Überprüfen Sie, ob der Webverbindungsstatus in den fastdp Status verschoben und die betroffene VM in den
CONNECTED Status verschoben wurde.
4. Wenn VMs noch im JOINING Status feststecken, starten Sie diese betroffenen VMs neu.
#sudo reboot now or #init 6
5. Überprüfen Sie nun, ob die betroffene VM in den
CONNECTED Status verschoben wurde.
admin@orchestrator[master-1]# show docker engine
Fri Jul 14 09:36:18.635 UTC+00:00
MISSED
ID STATUS PINGS
----------------------------------
control-1 CONNECTED 0
control-2 CONNECTED 0
director-1 CONNECTED 0
director-2 CONNECTED 0
director-3 CONNECTED 0
director-4 CONNECTED 0
distributor-1 CONNECTED 0
distributor-2 CONNECTED 0
distributor-3 CONNECTED 0
distributor-4 CONNECTED 0
master-1 CONNECTED 0
worker-1 CONNECTED 0
worker-2 CONNECTED 0
worker-3 CONNECTED 0
admin@orchestrator[master-1]#
6. Überprüfen Sie, ob vPAS mit dem Catering des Datenverkehrs beginnt und alle Container aktiv sind (insbesondere der Durchmesser des Endpunkts), oder starten Sie den Container im virtuellen System drc01 neu
orchestrator-backup-a.
#docker restart orchestrator-backup-a
7. Überprüfen Sie nun, ob vPAS mit der Verarbeitung des Datenverkehrs begonnen hat.
Ansatz 2.
Wenn der Festplattenspeicher des virtuellen Systems erschöpft ist.
1. Identifizieren Sie das Verzeichnis, das viel Speicherplatz belegt.
root@control-2:/var/lib/docker/overlay2#du -ah / --exclude=/proc | sort -r -h | head -n 10
176G 9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7
2. Überprüfen Sie die Dateien/Protokolle/Dumps, die großen Speicherplatz belegen.
root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/diff# ls -lrtha | grep G
total 88G
-rw------- 1 root root 1.1G Jul 12 18:10 core.22781
-rw------- 1 root root 1.2G Jul 12 18:12 core.24213
-rw------- 1 root root 1.2G Jul 12 18:12 core.24606
-rw------- 1 root root 1.1G Jul 12 18:12 core.24746
-rw------- 1 root root 1.1G Jul 12 18:13 core.25398
3. Identifizieren Sie die Container, die auf den betroffenen virtuellen Systemen ausgeführt werden (insbesondere Container mit fehlerhaften Systemen).
admin@orchestrator[master-1]# show docker service | exclude HEALTHY
Fri Jul 14 09:37:20.325 UTC+00:00
PENALTY
MODULE INSTANCE NAME VERSION ENGINE CONTAINER ID STATE BOX MESSAGE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
cc-monitor 103 cc-monitor 22.1.1-release control-2 cc-monitor-s103 STARTED true Pending health check
mongo-node 103 mongo-monitor 22.1.1-release control-2 mongo-monitor-s103 STARTED true Pending health check
mongo-status 103 mongo-status 22.1.1-release control-2 mongo-status-s103 STARTED false -
policy-builder 103 policy-builder 22.1.1-release control-2 policy-builder-s103 STARTED true Pending health check
prometheus 103 prometheus-hi-res 22.1.1-release control-2 prometheus-hi-res-s103 STARTED true Pending health check
prometheus 103 prometheus-planning 22.1.1-release control-2 prometheus-planning-s103 STARTED false -
admin@orchestrator[master-1]#
4. Identifizieren Sie den Container, der sperrige Core-Dateien auslöst, um dies zu tun inspizieren Sie jeden Container auf dem betroffenen VM gehostet, eine nach der anderen.
Sample output for container "cc-monitor-s103":
root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged# docker inspect cc-monitor-s103| grep /var/lib/docker/overlay2/| grep merged
"MergedDir": "/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged",
root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/merged#
5. Überprüfen Sie, ob Sie Zugriff auf diesen bestimmten Container haben oder nicht.
#admin@orchestrator[master-0]# docker connect cc-monitor-s103
6. Wenn Sie nicht auf diesen Container zugreifen können, entfernen Sie sperrige Core-Dateien, um Speicherplatz freizugeben.
root@control-2:/var/lib/docker/overlay2/9dfd1bf36282c4e707a3858beba91bfaa383c78b5b9eb3acf0e58f335126d9b7/diff# rm -rf core*
7. Melden Sie sich vom betroffenen virtuellen System aus am betroffenen Container an.
#docker exec -it cc-monitor-s103 bash
8. Starten Sie den
app Prozess im Container neu, um die Generierung sperriger Core-Dateien zu stoppen.
root@cc-monitor-s103:/# supervisorctl status
app STARTING
app-logging-status RUNNING pid 30, uptime 21 days, 23:02:17
consul RUNNING pid 26, uptime 21 days, 23:02:17
consul-template RUNNING pid 27, uptime 21 days, 23:02:17
haproxy RUNNING pid 25, uptime 21 days, 23:02:17
root@cc-monitor-s103:/#
root@cc-monitor-s103:/# date; supervisorctl restart app
Fri Jul 14 09:08:38 UTC 2023
app: stopped
app: started
root@cc-monitor-s103:/#
root@cc-monitor-s103:/# supervisorctl status
app RUNNING pid 26569, uptime 0:00:01
app-logging-status RUNNING pid 30, uptime 21 days, 23:02:44
consul RUNNING pid 26, uptime 21 days, 23:02:44
consul-template RUNNING pid 27, uptime 21 days, 23:02:44
haproxy RUNNING pid 25, uptime 21 days, 23:02:44
root@cc-monitor-s103:/#
9. Wenn Schritt 8. nicht hilft, die Generierung von Bulk-Core-Dateien zu stoppen, starten Sie den betroffenen Container neu.
#docker restart cc-monitor-s103
10. Überprüfen Sie, ob die Generierung der Bulk-Core-Datei beendet wurde.
11. Um die betroffene VM wieder in den Status VERBUNDEN zu versetzen, melden Sie sich beim
orchestrator Container an, und führen Sie einen
orchestration-engine Neustart durch.
cps@master-1:~$ date; docker exec -it orchestrator bash
Fri Jul 14 09:26:12 UTC 2023
root@orchestrator:/#
root@orchestrator:/# supervisorctl status
confd RUNNING pid 20, uptime 153 days, 23:33:33
consul RUNNING pid 19, uptime 153 days, 23:33:33
consul-template RUNNING pid 26, uptime 153 days, 23:33:33
haproxy RUNNING pid 17, uptime 153 days, 23:33:33
mongo RUNNING pid 22, uptime 153 days, 23:33:33
monitor-elastic-server RUNNING pid 55, uptime 153 days, 23:33:33
monitor-log-forward RUNNING pid 48, uptime 153 days, 23:33:33
orchestration-engine RUNNING pid 34, uptime 153 days, 23:33:33
orchestrator_back_up RUNNING pid 60, uptime 153 days, 23:33:33
remove-duplicate-containers RUNNING pid 21, uptime 153 days, 23:33:33
rolling-restart-mongo RUNNING pid 18, uptime 153 days, 23:33:33
simplehttp RUNNING pid 31, uptime 153 days, 23:33:33
root@orchestrator:/#
root@orchestrator:/# date; supervisorctl restart orchestration-engine
Fri Jul 14 09:26:39 UTC 2023
orchestration-engine: stopped
orchestration-engine: started
root@orchestrator:/#
12. Wenn Schritt 11. nicht zur Wiederherstellung des virtuellen Systems beiträgt, fahren Sie mit dem Neustart des Engine-Proxys im betroffenen virtuellen System fort.
cps@control-2:~$ docker ps | grep engine
0b778fae2616 engine-proxy:latest "/w/w /usr/local/bin…" 5 months ago Up 3 weeks engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
cps@control-2:~$ docker restart engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
cps@control-2:~$
cps@control-2:~$ docker ps | grep engine
0b778fae2616 engine-proxy:latest "/w/w /usr/local/bin…" 5 months ago Up 6 seconds engine-proxy-ddd7e7ec4a70859b53b24f3926ce6f01
cps@control-2:~$
13. Überprüfen Sie nun, ob die betroffene VM in den
CONNECTED Status verschoben wurde.
admin@orchestrator[master-1]# show docker engine
Fri Jul 14 09:36:18.635 UTC+00:00
ID STATUS MISSED PINGS
----------------------------------
control-1 CONNECTED 0
control-2 CONNECTED 0
director-1 CONNECTED 0
director-2 CONNECTED 0
director-3 CONNECTED 0
director-4 CONNECTED 0
distributor-1 CONNECTED 0
distributor-2 CONNECTED 0
distributor-3 CONNECTED 0
distributor-4 CONNECTED 0
master-1 CONNECTED 0
worker-1 CONNECTED 0
worker-2 CONNECTED 0
worker-3 CONNECTED 0
admin@orchestrator[master-1]#
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
25-Jun-2024 |
Erstveröffentlichung |