Inhalt

Einführung

Hintergrundinformationen

Abkürzungen

Fehlerbehebung bei Komponenten-RMA - Computing-/OSD-Computing-Knoten

Schritt 1: Graceful Shutdown

Identifizieren der im Computing-/OSD-Computing-Knoten gehosteten VMs

Zum Graceful Shutdown für Cluster Manager VM

Für das aktive Herunterfahren des VM Graceful Shutdown-Moduls PD/Load Balancer

Für den Standby-PD/Load Balancer VM Graceful Shutdown

Für PS/QNS VM Graceful Shutdown

Für das reibungslose Herunterfahren des OAM/pcrfclient VM

Für die Arbiter VM

Schritt 2: ESC-Datenbanksicherung.

Schritt 3: Migration von ESC in den Standby-Modus

Schritt 4: Ersetzen Sie die fehlerhafte Komponente aus dem Compute/OSD-Computing-Knoten.

Schritt 5: Stellen Sie die VMs wieder her.

VM-Wiederherstellung vom ESC

Wiederherstellung des ESC VM

Handhabung von ESC-Wiederherstellungsfehlern

Fehlerbehebung Komponenten-RMA - Controller-Knoten

Schritt 1: Controller - Checken

Schritt 2: Verschieben des Controller-Clusters in den Servicemodus

Schritt 3: Ersetzen Sie die fehlerhafte Komponente aus dem Controller-Knoten.

Schritt 4: Schalten Sie den Server ein.

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.

1. 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

2. 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.

1. 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

2. Suchen Sie nach allen Skripts nach der Bereitstellung, die zum Senden der CPS-Orchestrierungs-API verwendet werden.

3. 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

1. 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     |

2. 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

3. Ü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].

4. Überprüfen Sie alle Services in den startenden VMs.

Wiederherstellung des ESC VM

1. Melden Sie sich über die Konsole beim ESC an, und überprüfen Sie den Status.

2. 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

1. Setzen Sie den PC-Cluster auf den Controller, der im Standby-Modus aktualisiert wird..

[heat-admin@pod1-controller-0 ~]$ sudo pcs cluster standby

2. Ü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

3. 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.

1. 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 |

2. 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

3. 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