Sostituzione della scheda madre in un server Ultra-M UCS 240M4 - CPS

Introduzione

In questo documento vengono descritti i passaggi necessari per sostituire una scheda madre difettosa di un server in un'installazione Ultra-M che ospita funzioni di rete virtuale (VNF) di CPS.

Premesse

Ultra-M è una soluzione mobile packet core preconfezionata e convalidata, progettata per semplificare l'installazione delle VNF. OpenStack è Virtualized Infrastructure Manager (VIM) per Ultra-M ed è costituito dai seguenti tipi di nodi:

• Calcola
• Disco Object Storage - Compute (OSD - Compute)
• Controller
• Piattaforma OpenStack - Director (OSPD)

L'architettura di alto livello di Ultra-M e i componenti coinvolti sono illustrati in questa immagine:

Questo documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive i passaggi che devono essere eseguiti a livello OpenStack e StarOS VNF al momento della sostituzione della scheda madre in un server.

Nota: Per definire le procedure descritte in questo documento, viene presa in considerazione la release di Ultra M 5.1.x.

Abbreviazioni

VNF	Funzione di rete virtuale
ESC	Elastic Service Controller
MOP	Metodo
OSD	Dischi Object Storage
HDD	Unità hard disk
SSD	Unità a stato solido
VIM	Virtual Infrastructure Manager
VM	Macchina virtuale
EM	Gestione elementi
UAS	Ultra Automation Services
UUID	Identificatore univoco universale

Flusso di lavoro del piano di mobilità

Sostituzione della scheda madre in Ultra-M Setup

In un'installazione Ultra-M possono verificarsi situazioni in cui è necessaria la sostituzione di una scheda madre nei seguenti tipi di server: Compute, OSD-Compute e Controller.

Nota: I dischi di avvio con l'installazione openstack vengono sostituiti dopo la sostituzione della scheda madre. Non è quindi necessario aggiungere nuovamente il nodo all'overcloud. Una volta che il server è stato acceso dopo l'attività di sostituzione, si sarebbe registrato nuovamente nello stack di overcloud.

Sostituzione della scheda madre nel nodo di calcolo

Prima dell'attività, le VM ospitate nel nodo Calcola vengono spente normalmente. Una volta sostituita la scheda madre, le VM vengono ripristinate.

Identificare le VM ospitate nel nodo di calcolo

Identificare le VM ospitate nel server di elaborazione.

Il server di elaborazione contiene VM CPS o Elastic Services Controller (ESC):

[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     |

Nota:nell'output mostrato di seguito, la prima colonna corrisponde all'UUID (Universally Unique IDentifier), la seconda colonna è il nome della macchina virtuale e la terza colonna è il nome host in cui è presente la macchina virtuale. I parametri di questo output verranno utilizzati nelle sezioni successive.

Spegnimento regolare

Nodo di calcolo che ospita VM CPS/ESC

Passaggio 1. Accedere al nodo ESC corrispondente al file VNF e controllare lo stato delle macchine virtuali.

[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>

Passaggio 2. Arrestare le VM CPS uno per uno utilizzando il relativo nome di VM. (Nome VM indicato nella sezione Identificare le VM ospitate nel nodo di calcolo).

[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

Passaggio 3. Dopo l'arresto, le VM devono entrare nello stato SHUTOFF.

[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>

Passaggio 4. Accedere all'ESC ospitato nel nodo di calcolo e verificare se si trova nello stato master. In caso affermativo, passare all'ESC in modalità standby:

[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!

Backup ESC

Passaggio 1. La soluzione UltraM offre ridondanza 1:1. 2 Le VM ESC vengono implementate e supportano un singolo errore in UltraM. ovvero il sistema viene ripristinato in caso di errore singolo.

Nota: Se si verifica più di un errore, non è supportato e potrebbe essere necessario ridistribuire il sistema.

Dettagli backup ESC:

• Configurazione in esecuzione
• DB CDB ConfD
• Registri ESC
• Configurazione Syslog

Passaggio 2. La frequenza del backup del database ESC è complessa e deve essere gestita con attenzione durante il monitoraggio e la manutenzione da parte di ESC dei vari computer di stato per le diverse VM VNF installate. Si consiglia di eseguire questi backup dopo le seguenti attività in un determinato VNF/POD/sito.

Passaggio 3. Verificare che lo stato di ESC sia corretto per l'utilizzo dello script health.sh.

[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

Passaggio 4. Eseguire un backup della configurazione corrente e trasferire il file nel server di backup.

[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 database ESC

Passaggio 1. Accedere alla VM ESC ed eseguire questo comando prima di eseguire il backup.

[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

Passaggio 2. Controllare la modalità ESC e verificare che sia in modalità manutenzione.

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

Passaggio 3. Eseguire il backup del database utilizzando lo strumento di ripristino del backup del database disponibile in ESC.

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

Passaggio 4. Ripristinare la modalità operativa e confermare la modalità.

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

[root@esc scripts]# escadm op_mode show 

Passaggio 5. Passare alla directory scripts e raccogliere i log.

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

sudo ./collect_esc_log.sh

Passaggio 6. Per creare un'istantanea dell'ESC, chiudere prima l'ESC.

shutdown -r now

Passaggio 7. Da OSPD creare uno snapshot dell'immagine.

•  nova image-create --poll esc1 esc_snapshot_27aug2018 

Passaggio 8. Verificare che lo snapshot sia stato creato 

openstack image list | grep esc_snapshot_27aug2018

Passaggio 9. Avviare ESC da OSPD 

nova start esc1 

Passaggio 10. Ripetere la stessa procedura sulla VM ESC in standby e trasferire i registri sul server di backup.

Passaggio 11. Raccogliere il backup della configurazione syslog su entrambe le VM ESC e trasferirle sul server di backup.

[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

Sostituisci scheda madre

Passaggio 1. Per sostituire la scheda madre in un server UCS C240 M4, è possibile fare riferimento ai passaggi seguenti:

Guida all'installazione e all'assistenza del server Cisco UCS C240 M4

Passaggio 2. Accedere al server utilizzando l'indirizzo IP CIMC.

Passaggio 3. Eseguire l'aggiornamento del BIOS se il firmware non corrisponde alla versione consigliata utilizzata in precedenza. Le fasi per l'aggiornamento del BIOS sono riportate di seguito:

Guida all'aggiornamento del BIOS dei server con montaggio in rack Cisco UCS serie C

Ripristino delle VM

Nodo di calcolo che ospita CPS, ESC

Ripristino di VM ESC

Passaggio 1. La VM ESC è recuperabile se la VM è in stato di errore o di arresto eseguire un riavvio rapido per attivare la VM interessata. Eseguire i seguenti passaggi per ripristinare ESC.

Passaggio 2. Identificare la VM in stato ERRORE o Arresto, una volta identificato il riavvio a freddo della VM ESC. Nell'esempio, riavviare auto-test-vnfm1-ESC-0.

[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]#

Passaggio 3. Se la VM ESC viene eliminata e deve essere visualizzata di nuovo. 

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

Passaggio 4. Da OSPD, verificare che la nuova VM ESC sia ATTIVA/in esecuzione:

[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

Passaggio 5. Se la VM ESC non è recuperabile e richiede il ripristino del database, ripristinare il database dal backup eseguito in precedenza.

Passaggio 6. Per il ripristino del database ESC, è necessario assicurarsi che il servizio esc sia interrotto prima di ripristinare il database. Per ESC HA, eseguire prima nella VM secondaria e quindi nella VM principale.

# service keepalived stop

Passaggio 7. Controllare lo stato del servizio ESC e verificare che tutti gli elementi siano arrestati nelle VM principali e secondarie per HA

# escadm status

Passaggio 8. Eseguire lo script per ripristinare il database. Come parte del ripristino del database nella nuova istanza ESC creata, lo strumento promuoverà anche una delle istanze come ESC primario, montare la sua cartella DB sul dispositivo drbd e avviare il database PostgreSQL.

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

Passaggio 9. Riavviare il servizio ESC per completare il ripristino del database.

Per eseguire HA in entrambe le VM, riavviare il servizio keepalive

# service keepalived start

Passaggio 10. Una volta che la VM è stata ripristinata ed eseguita correttamente; accertarsi che tutta la configurazione specifica del syslog sia ripristinata dal precedente backup noto riuscito. Garantire il ripristino in tutte le VM ESC

[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

Passaggio 11. Se è necessario ricreare la sicurezza avanzata dallo snapshot OSPD, utilizzare il comando seguente utilizzando lo snapshot creato durante il backup.

nova rebuild --poll --name esc_snapshot_27aug2018 esc1

Passaggio 12. Verificare lo stato della ESC al termine della ricostruzione.

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

Passaggio 13. Controllare lo stato di integrità ESC con il comando seguente.

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

Ripristino delle VM CPS

La VM CPS sarebbe in stato di errore nell'elenco nova:

[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     | 

Ripristinare la VM CPS dalla ESC:

[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>

Monitorare il file 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].

Quando ESC non riesce ad avviare la VM

Passaggio 1. In alcuni casi, ESC non riesce ad avviare la macchina virtuale a causa di uno stato imprevisto. Per risolvere il problema, è possibile eseguire il passaggio a un ESC riavviando il Master ESC. Il passaggio al CES richiede circa un minuto.  Eseguire health.sh sul nuovo master ESC per verificare che sia attivo. Quando la funzione ESC diventa Master, la funzione ESC può correggere lo stato della macchina virtuale e avviarla. Poiché l'operazione è pianificata, è necessario attendere 5-7 minuti per il completamento.

Passaggio 2. È possibile monitorare /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se NON si vede che la VM viene ripristinata dopo 5-7 minuti, l'utente deve procedere al ripristino manuale delle VM interessate.

Passaggio 3. Una volta che la VM è stata ripristinata ed eseguita correttamente; accertarsi che tutta la configurazione specifica del syslog sia ripristinata dal precedente backup noto riuscito. Assicurarsi che venga ripristinato in tutte le VM ESC.

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

Sostituzione della scheda madre in OSD Compute Node

Prima dell'attività, le VM ospitate nel nodo Calcola vengono spente e il CEPH viene messo in modalità manutenzione. Una volta sostituita la scheda madre, le VM vengono ripristinate e CEPH viene disattivato dalla modalità di manutenzione.

Metti CEPH in modalità di manutenzione

Passaggio 1. Verificare che lo stato dell'albero di ceph osd sia attivo nel server

[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 

Passaggio 2. Accedere al nodo di calcolo dell'OSD e impostare CEPH in modalità di manutenzione.

[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

Nota: Quando il CEPH viene rimosso, VNF HD RAID entra nello stato Degraded ma hd-disk deve ancora essere accessibile

Identificare le VM ospitate nel nodo di calcolo Osd

Identificare le VM ospitate nel server di elaborazione OSD.

Il server di elaborazione contiene Elastic Services Controller (ESC) o VM CPS

[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     |

Nota: Nell'output mostrato di seguito, la prima colonna corrisponde all'UUID (Universally Unique IDentifier), la seconda colonna è il nome della macchina virtuale e la terza colonna è il nome host in cui la macchina virtuale è presente. I parametri di questo output verranno utilizzati nelle sezioni successive.

Spegnimento regolare

Caso 1. Nodo OSD-Compute che ospita ESC

La procedura per l'alimentazione regolare delle VM ESC o CPS è la stessa indipendentemente dal fatto che le VM siano ospitate nel nodo Compute o OSD-Compute.

Seguire i passaggi da "Sostituzione della scheda madre nel nodo di elaborazione" per spegnere le VM in modo corretto.

Sostituisci scheda madre

Passaggio 1. Per sostituire la scheda madre in un server UCS C240 M4, è possibile seguire i passaggi seguenti:

Guida all'installazione e all'assistenza del server Cisco UCS C240 M4

Passaggio 2. Accedere al server utilizzando l'indirizzo IP CIMC

3. Eseguire l'aggiornamento del BIOS se il firmware non corrisponde alla versione consigliata utilizzata in precedenza. Le fasi per l'aggiornamento del BIOS sono riportate di seguito:

Guida all'aggiornamento del BIOS dei server con montaggio in rack Cisco UCS serie C

Sposta CEPH fuori dalla modalità di manutenzione

Accedere al nodo di calcolo OSD e spostare CEPH fuori dalla modalità di manutenzione.

[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

Ripristino delle VM

Caso 1. Nodo OSD-Compute che ospita VM ESC o CPS

La procedura per il ripristino delle VM CF/ESC/EM/UAS è la stessa indipendentemente dal fatto che le VM siano ospitate nel nodo Compute o OSD-Compute.

Seguire i passaggi da "Caso 2. Nodo di calcolo host CF/ESC/EM/UAS" per ripristinare le VM.

Sostituzione della scheda madre nel nodo del controller

Verificare lo stato del controller e attivare la modalità di manutenzione per il cluster

Da OSPD, effettuare il login al controller e verificare che il pc sia in buono stato - tutti e tre i controller Online e Galera mostrano tutti e tre i controller come 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

Attivare la modalità manutenzione per il cluster.

[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

Sostituisci scheda madre

Passaggio 1. Per sostituire la scheda madre in un server UCS C240 M4, è possibile fare riferimento ai passaggi seguenti:

Guida all'installazione e all'assistenza del server Cisco UCS C240 M4

Passaggio 2. Accedere al server utilizzando l'indirizzo IP CIMC.

Passaggio 3. Eseguire l'aggiornamento del BIOS se il firmware non corrisponde alla versione consigliata utilizzata in precedenza. Le fasi per l'aggiornamento del BIOS sono riportate di seguito:

Guida all'aggiornamento del BIOS dei server con montaggio in rack Cisco UCS serie C

Ripristina stato cluster

Accedere al controller interessato, rimuovere la modalità standby impostando unstandby. Verificare che il controller sia online con il cluster e che galera mostri tutti e tre i controller come Master. L'operazione potrebbe richiedere alcuni minuti.

[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