Sostituzione di OSD-Compute UCS 240M4 - vEPC

Opzioni per il download

PDF (1.4 MB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (1.3 MB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (746.4 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:4 settembre 2018

ID documento:213478

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Sommario

Introduzione

Premesse

Flusso di lavoro del piano di mobilità

Abbreviazioni

Prerequisiti

OSPD di backup

Identificare le VM ospitate nel nodo di calcolo OSD

Spegnimento regolare

Caso 1. Nodo di calcolo OSD che ospita CF/ESC/EM/UAS

Migrazione della scheda CF allo stato di standby

Spegnere CF e VM EM da ESC

Esegui migrazione ESC in modalità standby

Rimozione del nodo di calcolo OSD dall'elenco di aggregazione Nova

Caso 2. OSD-Compute Node Hosts Auto-Deploy/Auto-IT/EM/UAS

Eseguire il backup del CDB della distribuzione automatica

Backup system.cfg da Auto-IT

OSD-Calcola eliminazione nodo

Elimina nodo di calcolo OSD dall'elenco dei servizi

Elimina agenti neutroni

Elimina dal database Nova e Ironic

Elimina da overcloud

Installare il nuovo nodo di calcolo

Aggiungere il nuovo nodo di calcolo OSD all'overcloud

Impostazioni sostituzione post-server

Ripristino delle VM

Caso 1. Hosting di nodi di calcolo OSD CF, ESC, EM e UAS

Aggiunta all'elenco aggregato Nova

Ripristino di VM UAS

Ripristino di VM ESC

Ripristino di VM CF ed EM da ESC

Caso 2. Hosting nodo di calcolo OSD Auto-IT, distribuzione automatica, EM e UAS

Ripristino della VM di installazione automatica

Ripristino della VM Auto-IT

Gestisci errore di ripristino ESC

Aggiornamento configurazione distribuzione automatica

Abilitazione dei syslog

Introduzione

In questo documento vengono descritti i passaggi necessari per sostituire un server di elaborazione con disco di storage a oggetti (OSD) difettoso in una configurazione Ultra-M che ospita funzioni di rete virtuale (VNF) StarOS.

Premesse

Ultra-M è una soluzione di base di pacchetti mobili 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
OSD - Elaborazione
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 di VNF OpenStack e StarOS al momento della sostituzione del server di elaborazione.

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

Flusso di lavoro del piano di mobilità

Abbreviazioni

VNF	Funzione di rete virtuale
CF	Funzione di controllo
SF	Funzione di servizio
ESC	Elastic Service Controller
MOP	Metodo di procedura
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

Prerequisiti

OSPD di backup

Prima di sostituire un nodo OSD-Compute, è importante verificare lo stato corrente dell'ambiente della piattaforma Red Hat OpenStack. Si consiglia di controllare lo stato corrente per evitare complicazioni quando il processo di calcolo sostitutivo è attivo. Questo flusso di sostituzione consente di ottenere il risultato desiderato.

In caso di ripristino, Cisco consiglia di eseguire un backup del database OSPD (DB) attenendosi alla seguente procedura:

[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

Questo processo assicura che un nodo possa essere sostituito senza influire sulla disponibilità di alcuna istanza. Inoltre, si consiglia di eseguire il backup della configurazione StarOS soprattutto se il nodo di calcolo da sostituire ospita la VM CF.

Identificare le VM ospitate nel nodo di calcolo OSD

Identificare le VM ospitate nel server di elaborazione. Esistono due possibilità:

Il server OSD-Compute contiene la combinazione EM/UAS/Auto-Deploy/Auto-IT delle VM:

[stack@director ~]$ nova list --field name,host | grep osd-compute-0
| c6144778-9afd-4946-8453-78c817368f18 | AUTO-DEPLOY-VNF2-uas-0                                   | pod1-osd-compute-0.localdomain |
| 2d051522-bce2-4809-8d63-0c0e17f251dc | AUTO-IT-VNF2-uas-0                                       | pod1-osd-compute-0.localdomain |
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-osd-compute-0.localdomain |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                           | pod1-osd-compute-0.localdomain |

Il server di elaborazione contiene una combinazione CF/ESC/EM/UAS di macchine virtuali:

[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, la seconda colonna è il nome della VM e la terza colonna è il nome host in cui la VM è presente. I parametri di questo output verranno utilizzati nelle sezioni successive.

Verificare che Ceph disponga della capacità disponibile per consentire la rimozione di un singolo server OSD:

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

GLOBAL:

    SIZE       AVAIL      RAW USED     %RAW USED

    13393G     11804G        1589G         11.87

POOLS:

    NAME        ID    USED      %USED     MAX AVAIL     OBJECTS

    rbd         0          0         0         3876G           0

    metrics     1     4157M      0.10         3876G      215385

    images      2     6731M      0.17         3876G         897

    backups     3         0         0         3876G           0

    volumes     4      399G      9.34         3876G      102373

    vms         5      122G      3.06         3876G       31863

Verificare che lo stato della struttura di ceph osd sia attivo sul server OSD-Compute:

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

Sul server OSD-Compute sono attivi i processi di crittografia:

[root@pod1-osd-compute-1 ~]# systemctl list-units *ceph*

UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

ceph-osd@11.service               loaded active running Ceph object storage daemon

ceph-osd@2.service                loaded active running Ceph object storage daemon

ceph-osd@5.service                loaded active running Ceph object storage daemon

ceph-osd@8.service                loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice         loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice          loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                   loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                   loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target               loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                       loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once

Disabilitare e arrestare ogni istanza di Ceph, rimuovere ogni istanza da OSD e smontare la directory. Ripetete l'operazione per ogni istanza di Ceph:

[root@pod1-osd-compute-1 ~]# systemctl disable ceph-osd@11



[root@pod1-osd-compute-1 ~]# systemctl stop ceph-osd@11



[root@pod1-osd-compute-1 ~]# ceph osd out 11

marked out osd.11.



[root@pod1-osd-compute-1 ~]# ceph osd crush remove osd.11

removed item id 11 name 'osd.11' from crush map



[root@pod1-osd-compute-1 ~]# ceph auth del osd.11

updated



[root@pod1-osd-compute-1 ~]# ceph osd rm 11

removed osd.11



[root@pod1-osd-compute-1 ~]# umount /var/lib/ceph.osd/ceph-11



[root@pod1-osd-compute-1 ~]# rm -rf /var/lib/ceph.osd/ceph-11

Per eseguire questa operazione, è possibile utilizzare lo script Clean.sh:

[heat-admin@pod1-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-11 ceph-3 ceph-6 ceph-8

[heat-admin@pod1-osd-compute-0 ~]$ /bin/sh clean.sh



[heat-admin@pod1-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

   i=`echo $c |cut -d'-' -f2`

   sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

   sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

   sleep 2

done

sudo ceph osd tree

Dopo la migrazione o l'eliminazione di tutti i processi OSD, è possibile rimuovere il nodo dall'overcloud.

Nota: quando Ceph viene rimosso, VNF HD RAID entra nello stato Degraded ma HD-disk deve essere ancora accessibile.

Spegnimento regolare

Caso 1. Nodo di calcolo OSD che ospita CF/ESC/EM/UAS

Migrazione della scheda CF allo stato di standby

Accedere alla VNF di StarOS e identificare la scheda corrispondente alla VM CF. Utilizzare l'UUID della VM CF identificata nella sezione Identificare le VM ospitate nel nodo OSD-Compute e individuare la scheda corrispondente all'UUID.

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 2:
  Card Type               : Control Function Virtual Card
  CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]
  CPU Nodes               : 1
  CPU Cores/Threads       : 8
  Memory                  : 16384M (qvpc-di-large)
  UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2
<snip>

Controllare lo stato della scheda:

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Standby        -
 2: CFC      Control Function Virtual Card           Active         No          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
 8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

Se la scheda si trova nello stato attivo, passare allo stato standby:

[local]VNF2# card migrate from 2 to 1

Spegnere CF e VM EM da ESC

Accedere al nodo ESC corrispondente al file VNF e verificare 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>

Arrestare la VM CF e EM uno per uno utilizzando il relativo nome della VM. Nome VM indicato nella sezione Identificare le VM ospitate nel nodo di calcolo OSD.

[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

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>

Esegui migrazione ESC in modalità standby

Accedere alla ESC ospitata 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!

Rimozione del nodo di calcolo OSD dall'elenco di aggregazione Nova

Elencare gli aggregati nova e identificare l'aggregato corrispondente al server di calcolo in base al VNF ospitato. In genere, il formato è <VNFNAME>-EM-MGMT<X> e <VNFNAME>-CF-MGMT<X>:

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

In questo caso, il server OSD-Compute appartiene a VNF2. Pertanto, gli aggregati che corrispondono saranno VNF2-CF-MGMT2 e VNF2-EM-MGMT2.

Rimuovere il nodo OSD-Compute dall'aggregazione identificata:

nova aggregate-remove-host 
       
        
         
       

[stack@director ~]$ nova aggregate-remove-host VNF2-CF-MGMT2 pod1-osd-compute-0.localdomain
[stack@director ~]$ nova aggregate-remove-host VNF2-EM-MGMT2 pod1-osd-compute-0.localdomain
[stack@director ~]$ nova aggregate-remove-host POD1-AUTOIT   pod1-osd-compute-0.localdomain

Verificare se il nodo OSD-Compute è stato rimosso dalle aggregazioni. A questo punto, verificare che l'host non sia elencato tra gli aggregati:

nova aggregate-show 
       
       

[stack@director ~]$ nova aggregate-show VNF2-CF-MGMT2
[stack@director ~]$ nova aggregate-show VNF2-EM-MGMT2
[stack@director ~]$ nova aggregate-show POD1-AUTOIT

Caso 2. OSD-Compute Node Hosts Auto-Deploy/Auto-IT/EM/UAS

Eseguire il backup del CDB della distribuzione automatica

Eseguire il backup periodico dei dati config cdb di distribuzione automatica o dopo ogni attivazione/disattivazione e salvare il file in un server di backup.La distribuzione automatica non è ridondante e se questi dati vengono persi, sarà difficile disattivare la distribuzione.

Accedere alla directory cdb di distribuzione automatica della macchina virtuale e di backup config:

ubuntu@auto-deploy-iso-2007-uas-0:~$sudo -i

root@auto-deploy-iso-2007-uas-0:~#service uas-confd stop

uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd

root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd#tar cvf autodeploy_cdb_backup.tar cdb/

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb


root@auto-deploy-iso-2007-uas-0:~# service uas-confd start

uas-confd start/running, process 13852

Nota: Copiare autodeploy_cdb_backup.tar nel server di backup.

Backup system.cfg da Auto-IT

Eseguire il backup del file system.cfg sul server di backup:

     Auto-it = 10.1.1.2
     Backup server = 10.2.2.2


[stack@director ~]$ ssh ubuntu@10.1.1.2
ubuntu@10.1.1.2's password: 
Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-76-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Wed Jun 13 16:21:34 UTC 2018

  System load:  0.02               Processes:           87
  Usage of /:   15.1% of 78.71GB   Users logged in:     0
  Memory usage: 13%                IP address for eth0: 172.16.182.4
  Swap usage:   0%

  Graph this data and manage this system at:
    https://landscape.canonical.com/

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

  Cisco Ultra Services Platform (USP) 
    Build Date: Wed Feb 14 12:58:22 EST 2018
    Description: UAS build assemble-uas#1891
    sha1: bf02ced


ubuntu@auto-it-vnf-uas-0:~$ scp -r /opt/cisco/usp/uploads/system.cfg root@10.2.2.2:/home/stack
root@10.2.2.2's password: 
system.cfg                                                                                                                                                                                                          100%  565     0.6KB/s   00:00    
ubuntu@auto-it-vnf-uas-0:~$

Nota: le procedure da eseguire per lo spegnimento regolare di EM/UAS su OSD-Compute-0 sono le stesse in entrambi i casi. Per la stessa ragione, fare riferimento alla richiesta Case.1.

OSD-Calcola eliminazione nodo

I passaggi descritti in questa sezione sono comuni indipendentemente dalle VM ospitate nel nodo di calcolo.

Elimina nodo di calcolo OSD dall'elenco dei servizi

Eliminare il servizio di calcolo dall'elenco dei servizi:

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep osd-compute-0
| 404 | nova-compute     | pod1-osd-compute-0.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete 
       
       
[stack@director ~]$ openstack compute service delete 404

Elimina agenti neutroni

Eliminare il vecchio agente neutronico associato e aprire l'agente vswitch per il server di calcolo:

[stack@director ~]$ openstack network agent list | grep osd-compute-0
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete 
       
       

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

Elimina dal database Nova e Ironic

Eliminare un nodo dall'elenco delle novità e dal database ironico e verificarlo:

[stack@director ~]$ source stackrc

[stack@al01-pod1-ospd ~]$ nova list | grep osd-compute-0
| c2cfa4d6-9c88-4ba0-9970-857d1a18d02c | pod1-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.114 |

[stack@al01-pod1-ospd ~]$ nova delete c2cfa4d6-9c88-4ba0-9970-857d1a18d02c

nova show 
       
       
         | grep hypervisor 
       

[stack@director ~]$ nova show pod1-osd-compute-0 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete 
       
       

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a 
[stack@director ~]$ ironic node-list (node delete must not be listed now)

Elimina da overcloud

Creare un file di script denominato delete_node.sh con il contenuto mostrato. Assicurarsi che i modelli indicati siano gli stessi utilizzati nello script deploy.sh utilizzato per la distribuzione dello stack:

 delete_node.sh

 openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

Attendere l'operazione dello stack OpenStack per passare allo stato COMPLETE:

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1 | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------

Installare il nuovo nodo di calcolo

I passaggi per installare un nuovo server UCS C240 M4 e le fasi di configurazione iniziali sono disponibili all'indirizzo:

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

Dopo l'installazione del server, inserire i dischi rigidi nei rispettivi slot come server precedente

Accedere al server utilizzando l'indirizzo IP CIMC

Eseguire l'aggiornamento del BIOS se il firmware non è conforme 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

Verificare lo stato delle unità fisiche. Deve essere Unconimaged Good

Creazione di un'unità virtuale dalle unità fisiche con RAID di livello 1

Storage > Controller RAID modulare SAS Cisco 12G (SLOT-HBA) > Informazioni unità fisica

Nota: Questa immagine è solo a scopo illustrativo: in CIMC OSD-Compute effettivo vengono visualizzate sette unità fisiche in slot (1,2,3,7,8,9,10) in stato Non configurato correttamente poiché da esse non vengono create unità virtuali.

Storage > Controller RAID modulare SAS Cisco 12G (SLOT-HBA) > Informazioni controller > Crea unità virtuale da unità fisiche inutilizzate

Selezionare il DVD e configurare "Set as Boot Drive" (Imposta come unità di avvio)

Abilitare IPMI over LAN: Amministrazione > Servizi di comunicazione > Servizi di comunicazione

Disabilita hyperthreading: Compute > BIOS > Configure BIOS > Advanced > Processor Configuration

Analogamente al VD BOOTOS creato con le unità fisiche 1 e 2, creare altre quattro unità virtuali come

JOURNAL > Dall'unità fisica numero 3

OSD1 > Dall'unità fisica numero 7

OSD2 > Da numero unità fisica 8

OSD3 > Da numero unità fisica 9

OSD4 > Dall'unità fisica numero 10
Alla fine, le unità fisiche e virtuali devono essere simili, come mostrato nell'immagine:

unità virtualiUnità fisiche

Nota: L'immagine qui illustrata e le procedure di configurazione descritte in questa sezione fanno riferimento alla versione del firmware 3.0(3e). Se si utilizzano altre versioni, potrebbero verificarsi lievi variazioni.

Aggiungere il nuovo nodo di calcolo OSD all'overcloud

I passaggi menzionati in questa sezione sono comuni indipendentemente dalla VM ospitata dal nodo di calcolo.

Aggiungere un server di elaborazione con un indice diverso.

Creare un file add_node.json contenente solo i dettagli del nuovo server di calcolo da aggiungere. Accertarsi che il numero di indice per il nuovo server di elaborazione OSD non sia stato utilizzato in precedenza. In genere, incrementa il valore di calcolo successivo più alto.

Esempio: La versione precedente più alta era OSD-Compute-0, quindi è stato creato OSD-Compute-3 in caso di sistema 2-vnf.

Nota: Prestare attenzione al formato json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:osd-compute-3,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

Importare il file json:

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

Eseguire l'introspezione dei nodi utilizzando l'UUID indicato nel passaggio precedente:

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

Aggiungere gli indirizzi IP in custom-templates/layout.yml sotto OsdComputeIPs. In questo caso, quando si sostituisce il comando OSD-Compute-0, l'indirizzo viene aggiunto alla fine dell'elenco per ciascun tipo:

OsdComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take osd-compute-0 .43 and add here

    tenant:

    - 11.117.0.43

    - 11.117.0.44

    - 11.117.0.45

    - 11.117.0.43   << and here

    storage:

    - 11.118.0.43

    - 11.118.0.44

    - 11.118.0.45

    - 11.118.0.43   << and here

    storage_mgmt:

    - 11.119.0.43

    - 11.119.0.44

    - 11.119.0.45

    - 11.119.0.43   << and here

Eseguire lo script deploy.sh precedentemente utilizzato per distribuire lo stack, per aggiungere il nuovo nodo di calcolo allo stack dell'overcloud:

[stack@director ~]$ ./deploy.sh
++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
…
Starting new HTTP connection (1): 192.200.0.1
"POST /v2/action_executions HTTP/1.1" 201 1695
HTTP POST http://192.200.0.1:8989/v2/action_executions 201
Overcloud Endpoint: http://10.1.2.5:5000/v2.0
Overcloud Deployed
clean_up DeployOvercloud: 
END return value: 0

real   38m38.971s
user   0m3.605s
sys    0m0.466s

Attendere che lo stato dello stack OpenStack sia COMPLETE:

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1       | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Verificare che il nuovo nodo OSD-Compute sia nello stato Attivo:

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep osd-compute-3
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep osd-compute-3
| 63 | pod1-osd-compute-3.localdomain    |

Accedere al nuovo server OSD-Compute e verificare i processi di Ceph. Inizialmente, lo stato sarà in HEALTH_WARN al ripristino di Ceph:

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666

     health HEALTH_WARN

            223 pgs backfill_wait

            4 pgs backfilling

            41 pgs degraded

            227 pgs stuck unclean

            41 pgs undersized

            recovery 45229/1300136 objects degraded (3.479%)

            recovery 525016/1300136 objects misplaced (40.382%)

     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 e986: 12 osds: 12 up, 12 in; 225 remapped pgs

            flags sortbitwise,require_jewel_osds

      pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1553 GB used, 11840 GB / 13393 GB avail

            45229/1300136 objects degraded (3.479%)

            525016/1300136 objects misplaced (40.382%)

                 477 active+clean

                 186 active+remapped+wait_backfill

                  37 active+undersized+degraded+remapped+wait_backfill

                   4 active+undersized+degraded+remapped+backfilling

Ma dopo un breve periodo (20 minuti), Ceph torna allo stato HEALTH_OK:

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    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 e1398: 12 osds: 12 up, 12 in

            flags sortbitwise,require_jewel_osds

      pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

            1599 GB used, 11793 GB / 13393 GB avail

                 704 active+clean

  client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr



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

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-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

-5  4.35999     host pod1-osd-compute-3

 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

Impostazioni sostituzione post-server

Dopo aver aggiunto il server all'overcloud, fare riferimento al collegamento seguente per applicare le impostazioni presenti in precedenza nel vecchio server:

Ripristino delle VM

Caso 1. Hosting di nodi di calcolo OSD CF, ESC, EM e UAS

Aggiunta all'elenco aggregato Nova

Aggiungere il nodo OSD-Compute agli host aggregati e verificare se l'host è stato aggiunto. In questo caso, il nodo OSD-Compute deve essere aggiunto sia agli aggregati host CF che EM.

nova aggregate-add-host 
       
        
         
       
[stack@director ~]$ nova aggregate-add-host VNF2-CF-MGMT2 pod1-osd-compute-3.localdomain
[stack@director ~]$ nova aggregate-add-host VNF2-EM-MGMT2 pod1-osd-compute-3.localdomain
[stack@direcotr ~]$ nova aggregate-add-host POD1-AUTOIT   pod1-osd-compute-3.localdomain

nova aggregate-show 
       
       
[stack@director ~]$ nova aggregate-show VNF2-CF-MGMT2
[stack@director ~]$ nova aggregate-show VNF2-EM-MGMT2
[stack@director ~]$ nova aggregate-show POD1-AUTOITT

Ripristino di VM UAS

Verificare lo stato della VM UAS nell'elenco delle macchine virtuali nuove ed eliminarla:

[stack@director ~]$ nova list | grep VNF2-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3
[stack@director ~]$ nova delete VNF2-UAS-uas-0
Request to delete server VNF2-UAS-uas-0 has been accepted.

Per ripristinare la VM autovnf-uas, eseguire lo script uas-check per verificare lo stato. Deve segnalare un ERRORE. Eseguire nuovamente con l'opzione —fix per ricreare la VM UAS mancante:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'

Accedere a autovnf-uas. Attendere alcuni minuti e UAS deve tornare allo stato buono:

VNF2-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP   STATE  ROLE
-----------------------------------
172.17.180.6  alive  CONFD-SLAVE
172.17.180.7  alive  CONFD-MASTER
172.17.180.9  alive  NA

Nota: Se uas-check.py —fix ha esito negativo, potrebbe essere necessario copiare il file ed eseguirlo nuovamente.

[stack@director ~]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
[stack@director ~]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/

Ripristino di VM ESC

Controllare lo stato della VM ESC dall'elenco delle macchine virtuali ed eliminarlo:

stack@director scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete VNF2-ESC-ESC-1
Request to delete server VNF2-ESC-ESC-1 has been accepted.

Da AutoVNF-UAS, trovare la transazione di distribuzione ESC e nel log della transazione trovare la riga di comando boot_vm.py per creare l'istanza ESC:

ubuntu@VNF2-uas-uas-0:~$ sudo -i
root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI    
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show transaction
TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS
-----------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success


VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
  <logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
    <tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
    <log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Salvare la riga boot_vm.py in un file di script della shell (esc.sh) e aggiornare tutte le righe relative al nome utente **** e alla password ***** con le informazioni corrette (in genere core/<PASSWORD>). È necessario rimuovere anche l'opzione -encrypt_key. Per user_pass e user_confd_pass, è necessario utilizzare il formato - nomeutente: password (esempio - admin:<PASSWORD>).

Trovare l'URL per impedire che bootvm.py venga eseguito-config e per ottenere il file bootvm.py nella macchina virtuale autovnf-uas. In questo caso, 10.1.2.3 è l'IP della VM Auto-IT:

root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
  value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!

root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.2.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]

Creare un file /tmp/esc_params.cfg:

root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg

Eseguire lo script della shell per distribuire ESC dal nodo UAS:

root@VNF2-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689
 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url 
http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url 
http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD> 
--esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass 
admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3
172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh 
--file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py 
--file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Accedere al nuovo ESC e verificare lo stato del backup:

ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14
…
   ####################################################################
   #   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

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

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

Ripristino di VM CF ed EM da ESC

Controllare lo stato delle VM CF e EM dall'elenco delle macchine virtuali. Devono essere nello stato ERROR:

[stack@director ~]$ source corerc
[stack@director ~]$ nova list --field name,host,status |grep -i err   
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

Accedere al master ESC, eseguire l'operazione di ripristino-vm per ogni server EM e VM CF interessati. Siate pazienti. ESC pianificherà l'operazione di ripristino e potrebbe non essere possibile attendere alcuni minuti. Monitorare il file yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO 
       
       

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[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>

[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-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]

Accedere a un nuovo EM e verificare che lo stato EM sia attivo:

ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1
admin@scm# show ems
EM            VNFM
ID  SLA  SCM  PROXY
---------------------
2   up   up   up
3   up   up   up

Accedere al VNF di StarOS e verificare che la scheda CF sia in stato di standby.

Caso 2. Hosting nodo di calcolo OSD Auto-IT, distribuzione automatica, EM e UAS

Ripristino della VM di installazione automatica

Da OSPD, se la distribuzione automatica della VM ha subito un impatto ma continua a mostrare ATTIVO/in esecuzione, è necessario prima eliminarla. Se l'installazione automatica non è stata compromessa, passare al ripristino della VM Auto-it:

[stack@director ~]$ nova list |grep auto-deploy

| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.12, 10.1.2.7 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7 --delete

Dopo aver eliminato la distribuzione automatica, crearla nuovamente con lo stesso indirizzo floatingip:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7

2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.2.7' to IP '172.16.181.7'

2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.2.7

Copiare il file Autodeploy.cfg, ISO e il file tar confd_backup dal server di backup per eseguire la distribuzione automatica della macchina virtuale e ripristinare i file confd cdb dal file tar di backup:

ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i

ubuntu@auto-deploy-iso-2007-uas-0:#  service uas-confd stop

uas-confd stop/waiting



root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd



root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb



root@auto-deploy-iso-2007-uas-0~# service uas-confd start

uas-confd start/running, process 2036

Verificare che confd sia stato caricato correttamente controllando le transazioni precedenti. Aggiornare il file autodeploy.cfg con un nuovo nome per il calcolo dell'OSD. Fare riferimento a Sezione - Passo finale: Aggiorna configurazione di distribuzione automatica:

root@auto-deploy-iso-2007-uas-0:~# confd_cli -u admin -C

Welcome to the ConfD CLI

admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0

auto-deploy-iso-2007-uas-0#show transaction

                                   SERVICE                                                              SITE

                                   DEPLOYMENT                                                     SITE  TX    AUTOVNF  VNF  AUTOVNF

TX ID          TX TYPE             ID          DATE AND TIME                  STATUS              ID    ID    ID       ID   TX ID

-------------------------------------------------------------------------------------------------------------------------------------

1512571978613  service-deployment  tb5bxb      2017-12-06T14:52:59.412+00:00  deployment-success



auto-deploy-iso-2007-uas-0# exit

Ripristino della VM Auto-IT

Da OSPD, se la VM auto-it è stata interessata ma viene ancora visualizzata come ATTIVA/in esecuzione, è necessario eliminarla. Se l'auto-it non è stato influenzato, passare alla VM successiva:

[stack@director ~]$ nova list |grep auto-it

| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.3, 10.1.2.8 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.2.8 --delete

Eseguire lo script di gestione temporanea auto-it-vnf e ricreare auto-it:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.2.8

2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.2.8' to IP '172.16.181.9'

2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.2.8

Ricaricare l'immagine ISO. In questo caso, l'indirizzo IP auto-it è 10.1.2.8. Il caricamento richiederà alcuni minuti:

[stack@director ~]$ cd images/5_1_7-2007/isos

[stack@director isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.2.8:5001/isos

{                                                   

  "iso-id": "5.1.7-2007"

}



to check the ISO image:



[stack@director isos]$ curl http://10.1.2.8:5001/isos

{                                       

  "isos": [

    {

      "iso-id": "5.1.7-2007"

    }

  ]

}

Copiare i file system.cfg VNF dalla directory di distribuzione automatica OSPD alla VM di autoit:

[stack@director autodeploy]$ scp system-vnf* ubuntu@10.1.2.8:.

ubuntu@10.1.2.8's password:

system-vnf1.cfg                                                                                               100% 1197     1.2KB/s   00:00

system-vnf2.cfg                                                                                               100% 1197     1.2KB/s   00:00



ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd

/home/ubuntu

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls

system-vnf1.cfg  system-vnf2.cfg

Nota: La procedura di ripristino di EM e UAS VM è la stessa in entrambi i casi. Per la stessa operazione, consultare la sezione Case.1.

Gestisci errore di ripristino ESC

Nei casi in cui ESC non riesca ad avviare la macchina virtuale a causa di uno stato imprevisto, Cisco consiglia di eseguire il switchover di ESC riavviando la macchina virtuale master. Il passaggio all'ESC richiederebbe circa un minuto. Eseguire lo script health.sh sul nuovo master ESC per verificare se lo stato è attivo. Master ESC per avviare la macchina virtuale e correggere lo stato della macchina virtuale. Per completare questa attività di ripristino sono necessari fino a cinque minuti.

È possibile monitorare /var/log/esc/yangesc.log e /var/log/esc/escmanager.log. Se non si rileva che la VM viene ripristinata dopo 5-7 minuti, l'utente dovrà eseguire il ripristino manuale delle VM interessate.

Aggiornamento configurazione distribuzione automatica

Da AutoDeploy VM, modificare il file auto-deploy.cfg e sostituire il vecchio server OSD-Compute con il nuovo. Caricare quindi il comando replace in confd_cli. Questo passaggio è necessario per la corretta disattivazione della distribuzione in un secondo momento.

root@auto-deploy-iso-2007-uas-0:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
auto-deploy-iso-2007-uas-0#config
Entering configuration mode terminal
auto-deploy-iso-2007-uas-0(config)#load replace autodeploy.cfg
Loading.     14.63 KiB parsed in 0.42 sec (34.16 KiB/sec)

auto-deploy-iso-2007-uas-0(config)#commit
Commit complete.
auto-deploy-iso-2007-uas-0(config)#end

Riavviare i servizi uas-config e Auto-Deploy dopo la modifica della configurazione:

root@auto-deploy-iso-2007-uas-0:~# service uas-confd restart
uas-confd stop/waiting
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service uas-confd status
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service autodeploy restart
autodeploy stop/waiting
autodeploy start/running, process 14017
root@auto-deploy-iso-2007-uas-0:~# service autodeploy status
autodeploy start/running, process 14017