Hauptplatinenaustausch im Ultra-M UCS 240M4 Server - CPS

Einführung

Dieses Dokument beschreibt die erforderlichen Schritte zum Ersetzen eines fehlerhaften Motherboards eines Servers in einer Ultra-M-Konfiguration, die CPS Virtual Network Functions (VNFs) hostet.

Hintergrundinformationen

Ultra-M ist eine vorkonfigurierte und validierte Kernlösung für virtualisierte mobile Pakete, 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)

Die High-Level-Architektur von Ultra-M und die beteiligten Komponenten sind in diesem Bild dargestellt:

Dieses Dokument richtet sich an Mitarbeiter von Cisco, die mit der Cisco Ultra-M-Plattform vertraut sind. Es enthält eine Beschreibung der Schritte, die beim Austausch des Motherboards in einem Server auf der Ebene von OpenStack und StarOS VNF durchgeführt werden müssen.

Hinweis: Ultra M 5.1.x wird zur Definition der Verfahren in diesem Dokument berücksichtigt.

Abkürzungen

VNF	Virtuelle Netzwerkfunktion
WSA	Elastic Service Controller
MOP	Verfahrensweise
OSD	Objektspeicherdatenträger
HDD	Festplattenlaufwerk
SSD	Solid-State-Laufwerk
VIM	Virtueller Infrastrukturmanager
VM	Virtuelles System
EM	Element Manager
USA	Ultra-Automatisierungsservices
UUID	Universell eindeutige IDentifier

Workflow des MoP

Austausch der Hauptplatine im Ultra-M-Setup

In einer Ultra-M-Konfiguration kann es Szenarien geben, in denen ein Austausch der Hauptplatine für die folgenden Servertypen erforderlich ist: Computing, OSD-Computing und Controller.

Hinweis: Die Boot-Laufwerke mit der OpenStack-Installation werden nach dem Austausch der Hauptplatine ersetzt. Daher ist es nicht erforderlich, den Knoten wieder zur Cloud hinzuzufügen. Sobald der Server nach der Ersetzung eingeschaltet wurde, meldet er sich wieder beim Overcloud-Stack an.

Austausch des Motherboards im Computing-Knoten

Vor der Aktivität werden die im Knoten Compute gehosteten VMs ordnungsgemäß heruntergefahren. Nachdem die Hauptplatine ausgetauscht wurde, werden die VMs wiederhergestellt.

Identifizieren der im Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem Computing-Server gehostet werden.

Der Computing-Server enthält CPS- oder Elastic Services Controller (ESC)-VMs:

[stack@director ~]$ nova list --field name,host | grep compute-8
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem die VM vorhanden ist. Die Parameter aus dieser Ausgabe werden in den nachfolgenden Abschnitten verwendet.

Graceful Power Aus

Computing-Knoten-Hosts CPS/ESC VMs

Schritt 1: Melden Sie sich beim ESC-Knoten an, der der VNF entspricht, und überprüfen Sie den Status der VMs.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_ALIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_ALIVE_STATE</state>
<snip>

Schritt 2: Beenden Sie die CPS VMs einzeln mit dem VM-Namen. (VM-Name siehe Abschnitt Identifizieren der im Compute-Knoten gehosteten VMs).

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

Schritt 3: Nach dem Anhalten müssen die VMs in den SHUTOFF-Status wechseln.

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
                    <vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    <state>VM_ALIVE_STATE</state>
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  <vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>
                  <vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>
                  <vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>
                <state>SERVICE_ACTIVE_STATE</state>
                    <vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    
     
     
       VM_SHUTOFF_STATE 
     
<snip>

Schritt 4: Melden Sie sich beim im Computing-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!

ESC-Sicherung

Schritt 1: ESC bietet eine Redundanz von 1:1 in der UltraM-Lösung. Zwei ESC VMs werden bereitgestellt und unterstützen einen Ausfall in UltraM. d. h. das System wird wiederhergestellt, wenn ein einziger Systemfehler auftritt.

Hinweis: Wenn mehr als ein Fehler vorliegt, wird er nicht unterstützt und erfordert möglicherweise eine Neubereitstellung des Systems.

ESC-Sicherungsdetails:

• Konfiguration wird ausgeführt
• ConfD CDB DB
• ESC-Protokolle
• Syslog-Konfiguration

Schritt 2: Die Häufigkeit der ESC DB-Backups ist schwierig und muss sorgfältig behandelt werden, da der ESC die verschiedenen Statuscomputer für verschiedene bereitgestellte VNF VMs überwacht und verwaltet. Es wird empfohlen, dass diese Sicherungen nach den folgenden Aktivitäten in der gegebenen VNF/POD/Site durchgeführt werden.

Schritt 3: Überprüfen Sie, ob der Zustand von ESC für die Verwendung des health.sh-Skripts geeignet ist.

[root@auto-test-vnfm1-esc-0 admin]# escadm status
0 ESC status=0 ESC Master Healthy

[root@auto-test-vnfm1-esc-0 admin]# health.sh
esc ui is disabled -- skipping status check
esc_monitor start/running, process 836
esc_mona is up and running ...
vimmanager start/running, process 2741
vimmanager start/running, process 2741
esc_confd is started
tomcat6 (pid 2907) is running...                           [  OK  ]
postgresql-9.4 (pid  2660) is running...
ESC service is running...
Active VIM = OPENSTACK
ESC Operation Mode=OPERATION

/opt/cisco/esc/esc_database is a mountpoint

============== ESC HA (MASTER) with DRBD =================

DRBD_ROLE_CHECK=0
MNT_ESC_DATABSE_CHECK=0
VIMMANAGER_RET=0
ESC_CHECK=0
STORAGE_CHECK=0
ESC_SERVICE_RET=0
MONA_RET=0
ESC_MONITOR_RET=0

=======================================

ESC HEALTH PASSED

Schritt 4: Sichern Sie die Running-Konfiguration, und übertragen Sie die Datei auf den Backup-Server.

[root@auto-test-vnfm1-esc-0 admin]# /opt/cisco/esc/confd/bin/confd_cli -u admin -C

admin connected from 127.0.0.1 using console on auto-test-vnfm1-esc-0.novalocal
auto-test-vnfm1-esc-0# show running-config | save /tmp/running-esc-12202017.cfg
auto-test-vnfm1-esc-0#exit

[root@auto-test-vnfm1-esc-0 admin]# ll /tmp/running-esc-12202017.cfg
-rw-------. 1 tomcat tomcat 25569 Dec 20 21:37 /tmp/running-esc-12202017.cfg

Backup ESC-Datenbank

Schritt 1: Melden Sie sich bei ESC VM an, und führen Sie diesen Befehl aus, bevor Sie die Sicherung durchführen.

[admin@esc ~]# sudo bash
[root@esc ~]# cp /opt/cisco/esc/esc-scripts/esc_dbtool.py /opt/cisco/esc/esc-scripts/esc_dbtool.py.bkup
[root@esc esc-scripts]# sudo sed -i "s,'pg_dump,'/usr/pgsql-9.4/bin/pg_dump," /opt/cisco/esc/esc-scripts/esc_dbtool.py

#Set ESC to mainenance mode
[root@esc esc-scripts]# escadm op_mode set --mode=maintenance

Schritt 2: Prüfen Sie den ESC-Modus, und vergewissern Sie sich, dass er sich im Wartungsmodus befindet.

[root@esc esc-scripts]# escadm op_mode show

Schritt 3: Backup-Datenbank mithilfe des in ESC verfügbaren Tools zur Wiederherstellung der Datenbanksicherung.

[root@esc scripts]# sudo /opt/cisco/esc/esc-scripts/esc_dbtool.py backup --file  scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

Schritt 4: Setzen Sie ESC zurück in den Betriebsmodus, und bestätigen Sie den Modus.

[root@esc scripts]# escadm op_mode set --mode=operation

[root@esc scripts]# escadm op_mode show 

Schritt 5: Navigieren Sie zum Skriptverzeichnis, und sammeln Sie die Protokolle.

[root@esc scripts]# /opt/cisco/esc/esc-scripts

sudo ./collect_esc_log.sh

Schritt 6: So erstellen Sie einen Snapshot des ESC, um den ESC zuerst herunterzufahren.

shutdown -r now

Schritt 7: Erstellen Sie aus dem OSPD einen Image-Snapshot.

•  nova image-create --poll esc1 esc_snapshot_27aug2018 

Schritt 8: Überprüfen, ob der Snapshot erstellt wird 

openstack image list | grep esc_snapshot_27aug2018

Schritt 9: ESC vom OSPD starten 

nova start esc1 

Schritt 10: Wiederholen Sie das gleiche Verfahren für das Standby-ESC-VM, und übertragen Sie die Protokolle auf den Backup-Server.

Schritt 11: Sichern der Syslog-Konfiguration auf dem ESC VMS und Übertragen dieser Daten auf den Backup-Server.

[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

Hauptplatine ersetzen

Schritt 1: Die Schritte zum Ersetzen des Motherboards in einem UCS C240 M4 Server können wie folgt beschrieben werden:

Cisco UCS C240 M4 Serverinstallations- und Serviceleitfaden

Schritt 2: Melden Sie sich mit der CIMC IP-Adresse beim Server an.

Schritt 3: Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Schritte für ein BIOS-Upgrade finden Sie hier:

BIOS-Upgrade-Leitfaden für Rackmount-Server der Cisco UCS C-Serie

Stellen Sie die VMs wieder her

Computing-Knoten-Hosts CPS, ESC

Wiederherstellung des ESC VM

Schritt 1: Wenn sich das virtuelle System im Fehler- oder Herunterladezustand befindet, kann das virtuelle System wiederhergestellt werden, indem ein harter Neustart durchgeführt wird, um das betroffene virtuelle System aufzurufen. Führen Sie diese Schritte aus, um ESC wiederherzustellen.

Schritt 2: Identifizieren Sie die VM, die sich im FEHLER- oder Herunterfahren-Zustand befindet, nachdem Sie einen harten Neustart der ESC VM identifiziert haben. In diesem Beispiel starten Sie auto-test-vnfm1-ESC-0 neu.

[root@tb1-baremetal scripts]# nova list | grep auto-test-vnfm1-ESC-

| f03e3cac-a78a-439f-952b-045aea5b0d2c | auto-test-vnfm1-ESC-0                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.11; auto-testautovnf1-uas-management=172.57.11.3                                                                                      |
| 79498e0d-0569-4854-a902-012276740bce | auto-test-vnfm1-ESC-1                                       | ACTIVE | -          | running     | auto-testautovnf1-uas-orchestration=172.57.12.15; auto-testautovnf1-uas-management=172.57.11.5                                                                                      |

[root@tb1-baremetal scripts]# [root@tb1-baremetal scripts]# nova reboot --hard f03e3cac-a78a-439f-952b-045aea5b0d2c\
Request to reboot server <Server: auto-test-vnfm1-ESC-0> has been accepted.

[root@tb1-baremetal scripts]#

Schritt 3: Wenn ESC VM gelöscht wird und wieder aktiviert werden muss. 

[stack@pod1-ospd scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@pod1-ospd scripts]$ nova delete vnf1-ESC-ESC-1
Request to delete server vnf1-ESC-ESC-1 has been accepted.

Schritt 4: Über OSPD prüfen Sie, ob die neue ESC VM aktiv/aktiv ist:

[stack@pod1-ospd ~]$ nova list|grep -i esc
| 934519a4-d634-40c0-a51e-fc8d55ec7144 | vnf1-ESC-ESC-0                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.13; vnf1-UAS-uas-management=172.168.10.3                                                                                                 |
| 2601b8ec-8ff8-4285-810a-e859f6642ab6 | vnf1-ESC-ESC-1                                                 | ACTIVE | -          | running     | vnf1-UAS-uas-orchestration=172.168.11.14; vnf1-UAS-uas-management=172.168.10.6                                                                                                 |

#Log in to new ESC and verify Backup state.  You may execute health.sh on ESC Master too.

…
   ####################################################################
   #   ESC on vnf1-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@esc-1 ~]$ health.sh
============== ESC HA (BACKUP) =================
=======================================

ESC HEALTH PASSED
[admin@esc-1 ~]$ cat /proc/drbd
version: 8.4.7-1 (api:1/proto:86-101)
GIT-hash: 3a6a769340ef93b1ba2792c6461250790795db49 build by mockbuild@Build64R6, 2016-01-12 13:27:11
 1: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:0 nr:504720 dw:3650316 dr:0 al:8 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Schritt 5: Wenn ESC VM nicht wiederherstellbar ist und die Wiederherstellung der Datenbank erfordert, stellen Sie die Datenbank aus der zuvor durchgeführten Sicherung wieder her.

Schritt 6: Für die Wiederherstellung der ESC-Datenbank muss vor der Wiederherstellung der Datenbank sichergestellt werden, dass der Dienst esc beendet wird. Führen Sie für ESC HA zunächst eine sekundäre VM und dann die primäre VM aus.

# service keepalived stop

Schritt 7: Überprüfen Sie den ESC-Dienststatus, und stellen Sie sicher, dass in primären und sekundären VMs alles für HA gestoppt wird.

# escadm status

Schritt 8: Führen Sie das Skript aus, um die Datenbank wiederherzustellen. Im Rahmen der Wiederherstellung der DB zur neu erstellten ESC-Instanz fördert das Tool auch eine der Instanzen als primären ESC, mountet ihren DB-Ordner auf dem laufenden Gerät und startet die PostgreSQL-Datenbank.

# /opt/cisco/esc/esc-scripts/esc_dbtool.py restore --file scp://
     
     
       : 
      
        @ 
       
         : 
         
        
       
     

Schritt 9: Starten Sie den ESC-Dienst neu, um die Datenbankwiederherstellung abzuschließen.

Für HA-Ausführung in beiden VMs starten Sie den Keepalived Service neu

# service keepalived start

Schritt 10: Sobald die VM erfolgreich wiederhergestellt und ausgeführt wurde, Stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt werden. Stellen Sie sicher, dass sie in allen ESC VMs wiederhergestellt wird.

[admin@auto-test-vnfm2-esc-1 ~]$
[admin@auto-test-vnfm2-esc-1 ~]$ cd /etc/rsyslog.d
[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/00-escmanager.conf
00-escmanager.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/01-messages.conf
01-messages.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.d/02-mona.conf
02-mona.conf

[admin@auto-test-vnfm2-esc-1 rsyslog.d]$ls /etc/rsyslog.conf
rsyslog.conf

Schritt 11: Wenn der ESC aus dem OSPD-Snapshot neu erstellt werden muss, verwenden Sie den folgenden Befehl mithilfe des Snapshots, der während des Backups erstellt wurde.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

Schritt 12: Überprüfen Sie den Status des ESC, nachdem die Wiederherstellung abgeschlossen ist.

nova list --fileds name,host,status,networks | grep esc

Schritt 13: Überprüfen Sie den ESC-Status mit dem folgenden Befehl.

health.sh

Copy Datamodel to a backup file
/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli get esc_datamodel/opdata > /tmp/esc_opdata_`date +%Y%m%d%H%M%S`.txt

Stellen Sie die CPS VMs wieder her

Die CPS VM befindet sich in der nova-Liste im Fehlerzustand:

[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 CPS VM 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
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

Überwachen Sie 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].

Wenn ESC zum Starten von VM fehlschlägt

Schritt 1: In einigen Fällen kann ESC aufgrund eines unerwarteten Zustands nicht die VM starten. Eine Problemumgehung besteht darin, einen ESC-Switchover durchzuführen, indem der Master-ESC neu gestartet wird. Der ESC-Switchover dauert etwa eine Minute.  Führen Sie health.sh auf dem neuen Master-ESC aus, um zu überprüfen, ob er aktiviert ist. Wenn der ESC Master wird, kann ESC den VM-Status reparieren und das virtuelle System starten. Da dieser Vorgang geplant ist, müssen Sie 5-7 Minuten warten, bis er abgeschlossen ist.

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

Schritt 3: Sobald die VM erfolgreich wiederhergestellt und ausgeführt wurde, Stellen Sie sicher, dass alle Syslog-spezifischen Konfigurationen aus der vorherigen erfolgreichen, bekannten Sicherung wiederhergestellt werden. Stellen Sie sicher, dass es in allen ESC VMs wiederhergestellt ist.

root@autotestvnfm1esc2:/etc/rsyslog.d# pwd
/etc/rsyslog.d

root@autotestvnfm1esc2:/etc/rsyslog.d# ll

total 28
drwxr-xr-x  2 root root 4096 Jun  7 18:38 ./
drwxr-xr-x 86 root root 4096 Jun  6 20:33 ../]
-rw-r--r--  1 root root  319 Jun  7 18:36 00-vnmf-proxy.conf
-rw-r--r--  1 root root  317 Jun  7 18:38 01-ncs-java.conf
-rw-r--r--  1 root root  311 Mar 17  2012 20-ufw.conf
-rw-r--r--  1 root root  252 Nov 23  2015 21-cloudinit.conf
-rw-r--r--  1 root root 1655 Apr 18  2013 50-default.conf

root@abautotestvnfm1em-0:/etc/rsyslog.d# ls /etc/rsyslog.conf
rsyslog.conf

Hauptplatinenaustausch im OSD-Computing-Knoten

Vor der Aktivität werden die im Knoten Compute gehosteten VMs ordnungsgemäß heruntergefahren und in den Wartungsmodus versetzt. Nachdem die Hauptplatine ausgetauscht wurde, werden die VMs wiederhergestellt und CEPH aus dem Wartungsmodus entfernt.

CEPH im Servicemodus aktivieren

Schritt 1: Stellen Sie sicher, dass der Status "sceph osd tree" auf dem Server aktiv ist.

[heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default
-2  4.35999     host pod1-osd-compute-0
 0  1.09000         osd.0                          up  1.00000          1.00000
 3  1.09000         osd.3                          up 1.00000          1.00000
 6  1.09000         osd.6                          up  1.00000          1.00000
 9  1.09000         osd.9                          up  1.00000          1.00000

-3  4.35999     host pod1-osd-compute-2
 1  1.09000        osd.1                          up  1.00000          1.00000
 4  1.09000         osd.4                          up  1.00000          1.00000
 7  1.09000         osd.7                          up  1.00000          1.00000
10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1
 2  1.09000         osd.2                          up  1.00000          1.00000
 5  1.09000         osd.5                          up  1.00000          1.00000
 8  1.09000         osd.8                          up  1.00000          1.00000
11  1.09000         osd.11                         up  1.00000          1.00000 

Schritt 2: Melden Sie sich beim OSD Compute-Knoten an, und setzen Sie CEPH in den Wartungsmodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# 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 {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,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

Hinweis: Wenn CEPH entfernt wird, wechselt VNF HD RAID in den Status "Degraded" (Heruntergestuft), aber der Zugriff auf die Festplatte muss noch möglich sein.

Identifizieren der im Osd-Compute-Knoten gehosteten VMs

Identifizieren Sie die VMs, die auf dem OSD-Computing-Server gehostet werden.

Der Computing-Server enthält Elastic Services Controller (ESC) oder CPS VMs.

[stack@director ~]$ nova list --field name,host | grep osd-compute-1
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Hinweis: In der hier gezeigten Ausgabe entspricht die erste Spalte dem Universally Unique IDentifier (UUID), die zweite Spalte dem VM-Namen und die dritte Spalte dem Hostnamen, in dem das virtuelle System vorhanden ist. Die Parameter aus dieser Ausgabe werden in den nachfolgenden Abschnitten verwendet.

Graceful Power Aus

Fall 1. OSD-Compute-Knoten-Hosts ESC

Das Verfahren zur sanften Stromversorgung von ESC- oder CPS-VMs ist gleich, unabhängig davon, ob die VMs im Knoten "Compute" oder "OSD-Compute" gehostet werden.

Führen Sie die Schritte aus "Hauptplatinenaustausch im Compute-Knoten" aus, um die virtuellen Systeme ordnungsgemäß abzuschalten.

Hauptplatine ersetzen

Schritt 1: Die Schritte zum Ersetzen der Hauptplatine in einem UCS C240 M4 Server können wie folgt beschrieben werden:

Cisco UCS C240 M4 Serverinstallations- und Serviceleitfaden

Schritt 2: Melden Sie sich mit der CIMC IP-Adresse beim Server an.

3. Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Schritte für ein BIOS-Upgrade finden Sie hier:

BIOS-Upgrade-Leitfaden für Rackmount-Server der Cisco UCS C-Serie

CEPH aus dem Servicemodus verschieben

Melden Sie sich beim Knoten OSD Compute an, und verschieben Sie CEPH aus dem Wartungsmodus.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance
[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

 cluster eb2bb192-b1c9-11e6-9205-525400330666
 health HEALTH_OK
 monmap e1: 3 mons at {pod1-controller-0=11.118.0.40:6789/0,pod1-controller-1=11.118.0.41:6789/0,pod1-controller-2=11.118.0.42:6789/0}
 election epoch 58, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
 osdmap e196: 12 osds: 12 up, 12 in
 flags sortbitwise,require_jewel_osds
 pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects
 1585 GB used, 11808 GB / 13393 GB avail
 704 active+clean
 client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

Stellen Sie die VMs wieder her

Fall 1. OSD-Compute-Knoten hostet ESC- oder CPS-VMs

Das Verfahren zur Wiederherstellung von CF/ESC/EM/UAS VMs ist unabhängig davon, ob die VMs im Knoten Compute oder OSD-Compute gehostet werden, identisch.

Folgen Sie den Schritten aus "Fall 2. Compute Node Hosts CF/ESC/EM/UAS" zur Wiederherstellung der VMs.

Austausch der Hauptplatine im Controller-Knoten

Controller-Status überprüfen und Cluster in Wartungsmodus schalten

Vom OSPD, Login zum Controller und prüfen, ob die PCs in gutem Zustand sind - alle drei Controller Online und galera zeigen alle drei Controller als Master.

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enabled

Setzen Sie den Cluster in den Wartungsmodus.

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Hauptplatine ersetzen

Schritt 1: Die Schritte zum Ersetzen des Motherboards in einem UCS C240 M4 Server können wie folgt beschrieben werden:

Cisco UCS C240 M4 Serverinstallations- und Serviceleitfaden

Schritt 2: Melden Sie sich mit der CIMC IP-Adresse beim Server an.

Schritt 3: Führen Sie ein BIOS-Upgrade durch, wenn die Firmware nicht der zuvor verwendeten empfohlenen Version entspricht. Schritte für ein BIOS-Upgrade finden Sie hier:

BIOS-Upgrade-Leitfaden für Rackmount-Server der Cisco UCS C-Serie

Cluster-Status wiederherstellen

Melden Sie sich beim betroffenen Controller an, 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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1
 my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:
 corosync: active/enabled
 pacemaker: active/enabled
 pcsd: active/enable