Modulare Komponenten RMA-PCRF
Download-Optionen
-
ePub (88.4 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Inklusive Sprache
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.
Informationen zu dieser Übersetzung
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.
Inhalt
Einführung
Dieses Dokument beschreibt die erforderlichen Schritte zum Ersetzen fehlerhafter Komponenten, die hier in einem Cisco Unified Computing System (UCS)-Server in einer Ultra-M-Konfiguration erwähnt werden, in der Cisco Policy Suite (CPS) Virtual Network Functions (VNFs) gehostet wird.
- DIMM-Austauschmodul (Dual In-Line Memory Module)
- FlexFlash-Controller-Fehler
- SSD-Fehler (Solid State Drive)
- Trusted Platform Module (TPM) Failure
- RAID-Cache-Fehler
- RAID-Controller/Hot-Bus-Adapter (HBA)-Fehler
- Fehler der PCI-Riserkarte
- PCIe-Adapter Intel X520 10G-Fehler
- Modularer LAN-on-Motherboard (MLOM)-Fehler
- RMA für Lüftereinschübe
- CPU-Ausfall
Verfasst von Nitesh Bansal, Cisco Advance Services.
Hintergrundinformationen
Ultra-M ist eine vorkonfigurierte und validierte virtualisierte Lösung, die die Bereitstellung von VNFs vereinfacht. OpenStack ist der Virtualized Infrastructure Manager (VIM) für Ultra-M und besteht aus den folgenden Knotentypen:
- Computing
- Object Storage Disk - Computing (OSD - Computing)
- Controller
- OpenStack-Plattform - Director (OSPD)
- Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument in Betracht gezogen.
- Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es beschreibt die Schritte, die auf der Ebene von OpenStack und CPS VNF zum Zeitpunkt des Austauschs von Komponenten im Server erforderlich sind.
Bevor Sie eine fehlerhafte Komponente austauschen, ist es wichtig, den aktuellen Status der Red Hat Open Stack Plattform-Umgebung zu überprüfen. Es wird empfohlen, den aktuellen Zustand zu überprüfen, um Komplikationen zu vermeiden, wenn der Austauschprozess eingeschaltet ist.
Im Falle einer Wiederherstellung empfiehlt Cisco die Sicherung der OSPD-Datenbank mithilfe der folgenden Schritte:
[root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql [root@director ~]# tar --xattrs -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql /etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack tar: Removing leading `/' from member names
Dieser Prozess stellt sicher, dass ein Knoten ausgetauscht werden kann, ohne dass die Verfügbarkeit der Instanzen beeinträchtigt wird.
Hinweis: Wenn es sich bei einem Server um einen Controller-Knoten handelt, fahren Sie mit dem Abschnitt fort. Andernfalls fahren Sie mit dem nächsten Abschnitt fort.
Abkürzungen
| VNF |
Virtuelle Netzwerkfunktion |
| PD |
Policy Director (Load Balancer) |
| PS |
Richtlinienserver (pcrfclient) |
| WSA |
Elastic Service Controller |
| MOP |
Verfahrensweise |
| OSD |
Objektspeicherdatenträger |
| HDD |
Festplattenlaufwerk |
| SSD |
Solid-State-Laufwerk |
| VIM |
Virtueller Infrastrukturmanager |
| VM |
Virtuelles System |
| SM |
Sitzungsmanager |
| QNS |
Quantum Name-Server |
| UUID |
Universell eindeutige IDentifier |
Fehlerbehebung bei Komponenten-RMA - Computing-/OSD-Computing-Knoten
Schritt 1: Graceful Shutdown
Identifizieren der im Computing-/OSD-Computing-Knoten gehosteten VMs
Der Compute/OSD-Compute kann mehrere Arten von VM hosten. Identifizieren Sie alle, und fahren Sie mit den einzelnen Schritten zusammen mit dem jeweiligen Bare-Metal-Knoten und den auf diesem Computer gehosteten VM-Namen fort:
[stack@director ~]$ nova list --field name,host | grep compute-10 | 49ac5f22-469e-4b84-badc-031083db0533 | SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 | pod1-compute-10.localdomain | | 49ac5f22-469e-4b84-badc-031083db0533 | SVS1-tmo_sm-s3_0_05966301-bd95-4071-817a-0af43757fc88 | pod1-compute-10.localdomain |
Zum Graceful Shutdown für Cluster Manager VM
Schritt 1: Erstellen Sie einen Snapshot, und FTP der Datei an einen anderen Speicherort außerhalb des Servers oder, wenn möglich, außerhalb des Racks selbst.
openstack image create --poll
Schritt 2: Beenden Sie die VM von ESC.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < CM vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli [admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>" <snip> <state>SERVICE_ACTIVE_STATE</state> SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für das aktive Herunterfahren des VM Graceful Shutdown-Moduls PD/Load Balancer
Schritt 1: Melden Sie sich bei Active Lb an, und beenden Sie die Dienste wie unten beschrieben.
- Umschalten von Aktiv auf Standby
service corosync restart
- Stoppservices im Standby-Modus
service monit stop service qns stop
Schritt 2. Vom ESC Master.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für den Standby-PD/Load Balancer VM Graceful Shutdown
Schritt 1: Melden Sie sich beim Standby-LB an, und beenden Sie die Dienste.
service monit stop service qns stop
Schritt 2: Vom ESC Master.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < Standby PD vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für PS/QNS VM Graceful Shutdown
Schritt 1: Dienst beenden:
service monit stop service qns stop
Schritt 2: Vom ESC Master.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
[dmin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[dmin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für SM VM Graceful Shutdown
Schritt 1: Stoppen Sie alle Mongo-Dienste, die in der Sitzung vorhanden sind.
[root@sessionmg01 ~]# cd /etc/init.d [root@sessionmg01 init.d]# ls -l sessionmgr* [root@sessionmg01 ~]# /etc/init.d/sessionmgr-27717 stop Stopping mongod: [ OK ] [root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27718 stop Stopping mongod: [ OK ] [root@ sessionmg01 ~]# /etc/init.d/sessionmgr-27719 stop Stopping mongod: [ OK ]
Schritt 2: Vom ESC Master.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < PS vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für das reibungslose Herunterfahren des OAM/pcrfclient VM
Schritt 1: Überprüfen Sie, ob die SVN-Richtlinie über diese Befehle synchronisiert ist. Wenn ein Wert zurückgegeben wird, ist SVN bereits synchronisiert und Sie müssen sie nicht über PCRFCLIENT02 synchronisieren. Sie sollten die Datenwiederherstellung von der letzten Datensicherung überspringen können noch verwendet werden, wenn erforderlich.
/usr/bin/svn propget svn:sync-from-url --revprop -r0 http://pcrfclient01/repos
Schritt 2: Stellen Sie die SVN-Master-/Slave-Synchronisierung zwischen dem pcrfclient01 und dem pcrfclient02 mithilfe von pcrfclient01 als Master wieder her, indem Sie die Befehlsfolge auf PCRFCLIENT01 ausführen.
/bin/rm -fr /var/www/svn/repos /usr/bin/svnadmin create /var/www/svn/repos /usr/bin/svn propset --revprop -r0 svn:sync-last-merged-rev 0 http://pcrfclient02/repos-proxy-sync /usr/bin/svnadmin setuuid /var/www/svn/repos/ "Enter the UUID captured in step 2" /etc/init.d/vm-init-client /var/qps/bin/support/recover_svn_sync.sh
Schritt 3: Sichern Sie den SVN im Cluster-Manager.
config_br.py -a export --svn /mnt/backup/svn_backup_pcrfclient.tgz
Schritt 4: Fahren Sie die Dienste in pcrfclient herunter.
service monit stop service qns stop
Schritt 5: Vom ESC Master:
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>
Schritt 6: Überprüfen Sie, ob die VM gestoppt wird.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für die Arbiter VM
Schritt 1: Melden Sie sich beim Schiedsrichter an, und schließen Sie die Services ab.
[root@SVS1OAM02 init.d]# ls -lrt sessionmgr* -rwxr-xr-x 1 root root 4382 Jun 21 07:34 sessionmgr-27721 -rwxr-xr-x 1 root root 4406 Jun 21 07:34 sessionmgr-27718 -rwxr-xr-x 1 root root 4407 Jun 21 07:34 sessionmgr-27719 -rwxr-xr-x 1 root root 4429 Jun 21 07:34 sessionmgr-27717 -rwxr-xr-x 1 root root 4248 Jun 21 07:34 sessionmgr-27720
service monit stop service qns stop
/etc/init.d/sessionmgr-[portno.] stop , where port no is the db port in the arbiter.
Schritt 2.Vom ESC Master.
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli vm-action STOP < pcrfclient vm-name>
Schritt 3: Überprüfen Sie, ob die VM gestoppt wird.
[admin@esc ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@esc ~]$ ./esc_nc_cli get esc_datamodel | egrep --color "
|
|
|
"
SERVICE_ACTIVE_STATE
SVS1-tmo_cm_0_e3ac7841-7f21-45c8-9f86-3524541d6634 VM_SHUTOFF_STATE
Für den Elastic Services Controller (ESC)
Schritt 1: Die Konfigurationen in ESC-HA müssen monatlich gesichert werden, vor/nach einem Scale-Up- oder Scale-Down-Vorgang mit dem VNF und vor/nach Konfigurationsänderungen beim ESC. Dies muss gesichert werden, um eine effektive Notfallwiederherstellung des ESC zu erreichen.
- Melden Sie sich mithilfe der Administratoranmeldeinformationen beim ESC an, und exportieren Sie Opdata in XML.
/opt/cisco/esc/confd/bin/netconf-console --host 127.0.0.1 --port 830 -u-p --get-config > /home/admin/ESC_config.xml - Laden Sie diese Datei auf Ihren lokalen Computer von ftp/sftp auf einen Server außerhalb der Cloud herunter.
Schritt 2: Sichern der PCRF-Cloud-Konfiguration Alle Skripts und Benutzerdatendateien, auf die in Bereitstellungs-XMLs verwiesen wird.
- Suchen aller Benutzerdatendateien, auf die in Bereitstellungs-XMLs aller VNFs verwiesen wird, aus den im vorherigen Schritt exportierten Opdata.Beispielausgabe.
file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-cm_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-oam_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-pd_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-qns_cloud.cfg file://opt/cisco/esc/cisco-cps/config/gr/cfg/std/pcrf-sm_cloud.cfg - Suchen Sie nach allen Skripts nach der Bereitstellung, die zum Senden der CPS-Orchestrierungs-API verwendet werden.
- Beispielausschnitte von Skripts nach der Bereitstellung in esc opdata.
Beispiel 1:
PCRF_POST_DEPLOYMENT
LCS::POST_DEPLOY_ALIVE
FINISH_PCRF_INSTALLATION
SCRIPT
----------
script_filename
/opt/cisco/esc/cisco-cps/config/gr/tmo/cfg/../cps_init.py
script_timeout
3600
Beispiel 2:
PCRF_POST_DEPLOYMENT
LCS::POST_DEPLOY_ALIVE
FINISH_PCRF_INSTALLATION
SCRIPT
CLUMAN_MGMT_ADDRESS
10.174.132.46
CLUMAN_YAML_FILE
/opt/cisco/esc/cisco-cps/config/vpcrf01/ cluman_orch_config.yaml
script_filename
/opt/cisco/esc/cisco-cps/config/vpcrf01/vpcrf_cluman_post_deployment.py
wait_max_timeout
3600
Wenn die Bereitstellung ESC opdata (extrahiert im vorherigen Schritt) eine der markierten Dateien enthält, führen Sie die Sicherung durch.
BeispielbackupBefehl:
tar –zcf esc_files_backup.tgz /opt/cisco/esc/cisco-cps/config/
Laden Sie diese Datei auf Ihren lokalen Computer von ftp/sftp auf einen Server außerhalb der Cloud herunter.
Note:- Although opdata is synced between ESC master and slave, directories containing user-data, xml and post deploy scripts are not synced across both instances. It is suggested that customers can push the contents of directory containing these files using scp or sftp, these files should be constant across ESC-Master and ESC-Standby in order to recover a deployment when ESC VM which was master during deployment is not available do to any unforeseen circumstances.
Schritt 2: ESC-Datenbanksicherung.
Schritt 1: Sammeln Sie die Protokolle von den beiden ESC VMs, und sichern Sie sie.
$ collect_esc_log.sh
$ scp /tmp/
@
:
Schritt 2: Sichern Sie die Datenbank vom Master-ECS-Knoten.
Schritt 3: Wechseln Sie zum Stammbenutzer, und überprüfen Sie den Status des primären ESC, und überprüfen Sie, ob der Ausgabewert Master ist.
$ sudo bash $ escadm status Set ESC to maintenance mode & verify $ sudo escadm op_mode set --mode=maintenance $ escadm op_mode show
Schritt 4: Verwenden Sie eine Variable, um den Dateinamen festzulegen und Datumsangaben einzuschließen. Rufen Sie das Sicherungstool auf, und stellen Sie die Dateinamenvariable aus dem vorherigen Schritt bereit.
fname=esc_db_backup_$(date -u +"%y-%m-%d-%H-%M-%S") $ sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup -- file /tmp/atlpod-esc-master-$fname.tar
Schritt 5: Überprüfen Sie die Sicherungsdatei in Ihrem Sicherungsspeicher, und stellen Sie sicher, dass die Datei vorhanden ist.
Schritt 6: Setzen Sie Master ESC wieder in den normalen Betriebsmodus zurück.
$ sudo escadm op_mode set --mode=operation
Wenn das Dienstprogramm "dbtool backup" fehlschlägt, wenden Sie die folgende Problemumgehung einmal im ESC-Knoten an. Wiederholen Sie anschließend Schritt 6.
$ sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py
Schritt 3: Migration von ESC in den Standby-Modus
Schritt 1: Melden Sie sich beim im Knoten gehosteten ESC an, und prüfen Sie, ob er sich im Master-Status befindet. Wenn ja, schalten Sie den ESC in den Standby-Modus um.
[admin@VNF2-esc-esc-0 esc-cli]$ escadm status 0 ESC status=0 ESC Master Healthy [admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop Stopping keepalived: [ OK ] [admin@VNF2-esc-esc-0 ~]$ escadm status 1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while. [admin@VNF2-esc-esc-0 ~]$ sudo reboot Broadcast message from admin@vnf1-esc-esc-0.novalocal (/dev/pts/0) at 13:32 ... The system is going down for reboot NOW!
Schritt 2: Sobald die VM ESC Standby ist, fahren Sie die VM mit dem Befehl shutdown -r jetzt herunter
Hinweis: Wenn die fehlerhafte Komponente auf dem OSD-Compute-Knoten ausgetauscht werden soll, legen Sie die CEPH in Maintenance auf dem Server ein, bevor Sie mit dem Austausch der Komponente fortfahren.
[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance
set norebalance
[admin@osd-compute-0 ~]$ sudo ceph osd set noout
set noout
[admin@osd-compute-0 ~]$ sudo ceph status
cluster eb2bb192-b1c9-11e6-9205-525400330666
health HEALTH_WARN
noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
monmap e1: 3 mons at {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}
election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2
osdmap e194: 12 osds: 12 up, 12 in
flags noout,norebalance,sortbitwise,require_jewel_osds
pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
1585 GB used, 11808 GB / 13393 GB avail
704 active+clean
client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr
Schritt 4: Ersetzen Sie die fehlerhafte Komponente aus dem Compute/OSD-Computing-Knoten.
Schalten Sie den angegebenen Server aus. Die Schritte zum Ersetzen einer fehlerhaften Komponente auf dem UCS C240 M4 Server können wie folgt beschrieben werden:
Ersetzen der Serverkomponenten
Weitere Informationen finden Sie unter "Persistent Logging" (Dauerhafte Protokollierung) im folgenden Verfahren und führen Sie das Programm bei Bedarf aus.
Schritt 5: Stellen Sie die VMs wieder her.
VM-Wiederherstellung vom ESC
- Die VM befindet sich in der Nova-Liste im Fehlerstatus.
[stack@director ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d | ERROR | - | NOSTATE |
- Stellen Sie die VMs vom ESC wieder her.
[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d [sudo] password for admin: Recovery VM Action /opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW - Überwachen Sie die yangesc.log
admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log … 14:59:50,112 07-Nov-2017 WARN Type: VM_RECOVERY_COMPLETE 14:59:50,112 07-Nov-2017 WARN Status: SUCCESS 14:59:50,112 07-Nov-2017 WARN Status Code: 200 14:59:50,112 07-Nov-2017 WARN Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].
- Überprüfen Sie alle Services in den startenden VMs.
Wiederherstellung des ESC VM
- Melden Sie sich über die Konsole beim ESC an, und überprüfen Sie den Status.
- Starten Sie die Prozesse, falls diese noch nicht gestartet wurden.
[admin@esc ~]$ sudo service keepalived start
[admin@esc ~]$ escadm status 0 ESC status=0 ESC Slave Healthy
Handhabung von ESC-Wiederherstellungsfehlern
Falls ESC aufgrund eines unerwarteten Zustands nicht starten kann, empfiehlt Cisco die Durchführung eines ESC-Switchover durch einen Neustart des Master-ESC. Der ESC-Switchover würde etwa eine Minute dauern. Führen Sie das Skript "health.sh" auf dem neuen Master-ESC aus, um zu überprüfen, ob der Status aktiv ist. Master-ESC zum Starten der VM und zum Beheben des VM-Status. Diese Wiederherstellungsaufgabe würde bis zu 5 Minuten in Anspruch nehmen.
Sie können /var/log/esc/yangesc.log und /var/log/esc/escmanager.log überwachen. Wenn Sie NICHT sehen, dass VM nach 5-7 Minuten wiederhergestellt wird, muss der Benutzer die manuelle Wiederherstellung der betroffenen VM(s) durchführen.
Falls die ESC VM nicht wiederhergestellt wird, folgen Sie dem Verfahren, um eine neue ESC VM bereitzustellen. Wenden Sie sich für das Verfahren an den Cisco Support.
Fehlerbehebung Komponenten-RMA - Controller-Knoten
Schritt 1: Controller - Checken
Vom OSPD, melden Sie sich an den Controller und überprüfen Sie, ob die PCs in einem guten Zustand sind - alle drei Controller Online und galera zeigen alle drei Controller als Master.
Hinweis: Ein gesunder Cluster benötigt zwei aktive Controller, also überprüfen Sie, ob die beiden verbleibenden Controller online und aktiv sind.
heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:46:10 2017 Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0 3 nodes and 22 resources configured Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-0 pod1-controller-1 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
Schritt 2: Verschieben des Controller-Clusters in den Servicemodus
- Setzen Sie den PC-Cluster auf den Controller, der im Standby-Modus aktualisiert wird..
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby
- Überprüfen Sie den PC-Status erneut, und stellen Sie sicher, dass der PC-Cluster an diesem Knoten gestoppt wird..
[heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 00:48:24 2017 Last change: Mon Dec 4 00:48:18 2017 by root via crm_attribute on pod1-controller-0 3 nodes and 22 resources configured Node pod1-controller-0: standby Online: [ pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-1 pod1-controller-2 ] Stopped: [ pod1-controller-0 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-1 pod1-controller-2 ] Slaves: [ pod1-controller-0 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-1 ] Stopped: [ pod1-controller-0 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
- Außerdem sollte der Knoten auf den beiden anderen Controllern als Standby-Knoten angezeigt werden.
Schritt 3: Ersetzen Sie die fehlerhafte Komponente aus dem Controller-Knoten.
Schalten Sie den angegebenen Server aus. Die Schritte zum Ersetzen einer fehlerhaften Komponente auf dem UCS C240 M4 Server können wie folgt beschrieben werden:
Ersetzen der Serverkomponenten
Schritt 4: Schalten Sie den Server ein.
- Schalten Sie den Server ein, und überprüfen Sie, ob der Server hochgefahren ist.
[stack@tb5-ospd ~]$ source stackrc [stack@tb5-ospd ~]$ nova list |grep pod1-controller-0 | 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.112 |
- Melden Sie sich beim betroffenen Controller an, und entfernen Sie den Standby-Modus, indem Sie den Standby-Modus festlegen. Überprüfen Sie, ob der Controller online mit Cluster geliefert wird, und galera zeigt alle drei Controller als Master an. Dies kann einige Minuten dauern..
[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster unstandby [heat-admin@pod1-controller-0 ~]$ sudo pcs status Cluster name: tripleo_cluster Stack: corosync Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum Last updated: Mon Dec 4 01:08:10 2017 Last change: Mon Dec 4 01:04:21 2017 by root via crm_attribute on pod1-controller-0 3 nodes and 22 resources configured Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Full list of resources: ip-11.118.0.42 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-11.119.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 ip-11.120.0.49 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 ip-192.200.0.102 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: haproxy-clone [haproxy] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: galera-master [galera] Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] ip-11.120.0.47 (ocf::heartbeat:IPaddr2): Started pod1-controller-2 Clone Set: rabbitmq-clone [rabbitmq] Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ] Master/Slave Set: redis-master [redis] Masters: [ pod1-controller-2 ] Slaves: [ pod1-controller-0 pod1-controller-1 ] ip-10.84.123.35 (ocf::heartbeat:IPaddr2): Started pod1-controller-1 openstack-cinder-volume (systemd:openstack-cinder-volume): Started pod1-controller-2 my-ipmilan-for-pod1-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1 my-ipmilan-for-pod1-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled
- Sie können einige Überwachungsdienste überprüfen, z. B. ob sie sich in einem gesunden Zustand befinden.
[heat-admin@pod1-controller-0 ~]$ sudo ceph -s cluster eb2bb192-b1c9-11e6-9205-525400330666 health HEALTH_OK monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0} election epoch 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2 osdmap e218: 12 osds: 12 up, 12 in flags sortbitwise,require_jewel_osds pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects 2142 GB used, 11251 GB / 13393 GB avail 704 active+clean client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr
Beiträge von Cisco Ingenieuren
- Nitesh BansalCisco Advanced Services
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)