Sommario

Introduzione

Premesse

Controllo dello stato

Backup

Identificare le VM ospitate nel nodo di calcolo OSD

Spegnimento regolare

Esegui migrazione ESC in modalità standby

Osd-Compute Node Deletion

Elimina da overcloud

Elimina nodo Osd-Compute dall'elenco dei servizi

Elimina agenti neutroni

Elimina dal database Nova e Ironic

Installare il nuovo nodo di calcolo

Aggiungere il nuovo nodo OSD-Compute a Overcloud

Ripristino delle VM

Aggiunta all'elenco aggregato Nova

Ripristino di VM ESC

Introduzione

In questo documento viene descritto come sostituire un server di elaborazione video difettoso in una configurazione Ultra-M che ospita funzioni di rete virtuale (VNF) di Cisco Policy Suite (CPS).

Premesse

Questo documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive i passaggi richiesti per essere eseguiti a livello di OpenStack e CPS VNF al momento della sostituzione del server di elaborazione OSD.

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

Controllo dello stato

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.

Da OSPD

[root@director ~]$ su - stack

[stack@director ~]$ cd ansible

[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml  -e platform=pcrf

Passaggio 1. Verificare lo stato del sistema da un rapporto di ultrasuoni che viene generato ogni quindici minuti.

[stack@director ~]# cd /var/log/cisco/ultram-health

Controllare il file ultram_health_os.report.

Gli unici servizi da visualizzare come stato XXX sono neutron-sriov-nic-agent.service.

Passaggio 2. Verificare se rabbitmq viene eseguito per tutti i controller, che a loro volta vengono eseguiti da OSPD.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done

Passaggio 3. Verificare che la pietra sia abilitata.

[stack@director ~]# sudo pcs property show stonith-enabled

Verifica dello stato del PCS per tutti i controller

- Tutti i nodi controller sono avviati in haproxy-clone

- Tutti i nodi controller sono master sotto galera

- Tutti i nodi controller sono avviati in Rabbitmq

- 1 nodo controller è Master e 2 slave sotto redis

Da OSPD

[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done

Passaggio 4. Verificare che tutti i servizi openstack siano attivi. Da OSPD eseguire questo comando:

[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

Passaggio 5. Verificare che lo stato del CEPH sia HEALTH_OK per i controller.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done

Passaggio 6. Verificare i log del componente OpenStack. Cercare eventuali errori:

Neutron:

[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log

Cinder:

[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log

Glance:

[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log

Passaggio 7. Da OSPD eseguire queste verifiche per API.

[stack@director ~]$ source

[stack@director ~]$ nova list

[stack@director ~]$ glance image-list

[stack@director ~]$ cinder list

[stack@director ~]$ neutron net-list

Passaggio 8. Verificare lo stato dei servizi.

Every service status should be “up”:

[stack@director ~]$ nova service-list

Every service status should be “ :-)”:

[stack@director ~]$ neutron agent-list

Every service status should be “up”:

[stack@director ~]$ cinder service-list

Backup

In caso di ripristino, Cisco consiglia di eseguire un backup del database OSPD attenendosi alla seguente procedura.

Passaggio 1. Eseguire il dump Mysql.

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

Passaggio 2. Per eseguire il backup delle VM CPS dalla VM di Cluster Manager:

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz

or

[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).tar.gz

Identificare le VM ospitate nel nodo di calcolo OSD

Identificare le VM ospitate nel server di elaborazione:

Passaggio 1. Il server di elaborazione contiene Elastic Services Controller (ESC).

[stack@director ~]$ nova list --field name,host,networks | grep osd-compute-1

| 50fd1094-9c0a-4269-b27b-cab74708e40c | esc | pod1-osd-compute-0.localdomain

| tb1-orch=172.16.180.6; tb1-mgmt=172.16.181.3

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

Nota: Se il nodo di calcolo OSD da sostituire è completamente inattivo e non accessibile, passare alla sezione intitolata "Rimuovi il nodo di calcolo Osd dall'elenco aggregato Nova". In caso contrario, passare alla sezione successiva.

Passaggio 2. Verificare che il CEPH disponga della capacità disponibile per consentire la rimozione di un singolo server OSD.

[root@pod1-osd-compute-0 ~]# 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

Passaggio 3. Verificare che lo stato dell'albero di ceph osd sia attivo sul server di elaborazione osd.

[heat-admin@pod1-osd-compute-0 ~]$ 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 4. I processi CEPH sono attivi sul server di elaborazione a video.

[root@pod1-osd-compute-0 ~]# 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

Passaggio 5. Disabilitare e arrestare ogni istanza di ceph, rimuovere ogni istanza da osd e smontare la directory. Ripetete l'operazione per ogni variante di cefh.

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

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

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

marked out osd.11.

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

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

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

updated

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

removed osd.11

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

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

(o)

Passaggio 6. È possibile utilizzare lo script Clean.sh per eseguire contemporaneamente l'operazione descritta in precedenza.

[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 passa allo stato Degraded ma hd-disk deve ancora essere accessibile.

Spegnimento regolare

Esegui migrazione ESC in modalità standby

Passaggio 1. Accedere alla pagina ESC ospitata nel nodo di calcolo e verificare se si trova nello stato master. In caso affermativo, passare alla modalità di standby.

[admin@esc esc-cli]$ escadm status

0 ESC status=0 ESC Master Healthy

[admin@esc ~]$ sudo service keepalived stop

Stopping keepalived:                                       [  OK  ]

[admin@esc ~]$ escadm status

1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@esc ~]$ 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!

Passaggio 2. Rimuovere il nodo Osd-Compute dall'elenco di aggregazione Nova.

- Elencare gli aggregati nova e identificare l'aggregato che corrisponde al server di elaborazione basato sul VNF ospitato. In genere, il formato è <VNFNAME>-EM-MGMT<X> e <VNFNAME>-CF-MGMT<X>

[stack@director ~]$ nova aggregate-list

+----+------+-------------------+

| Id | Name | Availability Zone |

+----+------+-------------------+

| 3 | esc1 | AZ-esc1 |

| 6 | esc2 | AZ-esc2 |

| 9 | aaa | AZ-aaa |

+----+------+-------------------+

Nel nostro caso, il server di elaborazione osd appartiene a esc1. Quindi, gli aggregati che corrispondono sarebbero esc1

Passaggio 3. Rimuovere il nodo osd-compute dall'aggregazione identificata.

nova aggregate-remove-host

[stack@director ~]$ nova aggregate-remove-host esc1 pod1-osd-compute-0.localdomain

Passaggio 4. Verificare se il nodo osd-compute è stato rimosso dagli aggregati. A questo punto, verificare che l'host non sia elencato negli aggregati.

nova aggregate-show

[stack@director ~]$ nova aggregate-show esc1

[stack@director ~]$

Osd-Compute Node Deletion

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

Elimina da overcloud

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

Passaggio 2. Attendere che l'operazione dello stack OpenStack passi 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 |

+--------------------------------------+------------+-----------------+----------------------+----------------------

Elimina nodo Osd-Compute dall'elenco dei servizi

Eliminare il servizio di elaborazione 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 elaborazione.

[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 nova insieme al 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)

Installare il nuovo nodo di calcolo

Per l'installazione di un nuovo server UCS C240 M4 e le procedure di configurazione iniziali, consultare: Guida all'installazione e all'assistenza del server Cisco UCS C240 M4

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

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

Passaggio 3. Eseguire l'aggiornamento del BIOS se il firmware non è conforme alla versione consigliata utilizzata in precedenza. La procedura per l'aggiornamento del BIOS è illustrata di seguito: Cisco UCS C-Series Rack-Mount Server BIOS Upgrade Guide

Passaggio 4. Verificare lo stato delle unità fisiche. Dev'essere Bene non rappresentato.

Passaggio 5. Creare un'unità virtuale dalle unità fisiche con RAID di livello 1.

Passaggio 6. Passare alla sezione Storage e selezionare Cisco 12G Sas Modular Raid Controller, quindi verificare lo stato e l'integrità del controller RAID come mostrato nell'immagine.

Nota: L'immagine precedente ha solo scopo illustrativo: in CIMC OSD-Compute effettivo vengono visualizzate sette unità fisiche in slot [1,2,3,7,8,9,10] in buono stato non configurato, in quanto da esse non vengono create unità virtuali.

Passaggio 7. Creare un'unità virtuale da un'unità fisica non utilizzata dalle informazioni sul controller, nel controller RAID modulare SAS Cisco 12G.

Passaggio 8. Selezionare il DVD e configurare il set come unità di avvio.

Passaggio 9. Abilitare IPMI over LAN dai servizi di comunicazione nella scheda Amministrazione.

Passaggio 10. Disabilitare Hyper-Threading dalla configurazione avanzata del BIOS sotto il nodo Compute, come mostrato nell'immagine.

Passaggio 11. Analogamente a BOOTOS VD creato con le unità fisiche 1 e 2, creare altre quattro unità virtuali come

JOURNAL - Da numero unità fisica 3

OSD1 - Da unità fisica numero 7

OSD2 - Da numero unità fisica 8

OSD3 - Da numero unità fisica 9

OSD4 - Da unità fisica numero 10

Passaggio 7. Alla fine, le unità fisiche e le unità virtuali devono essere simili.

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 OSD-Compute a Overcloud

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

Passaggio 1. Aggiungere un server di elaborazione con un indice diverso.

Creare un file add_node.json contenente solo i dettagli del nuovo server di elaborazione da aggiungere.  Verificare 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"

}

]

}

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

Passaggio 3. Eseguire l'introspezione del nodo 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       |

Passaggio 4. Aggiungere gli indirizzi IP in custom-templates/layout.yml sotto OsdComputeIPs. In questo caso, sostituendo osd-compute-0, aggiungere l'indirizzo 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

Passaggio 5. 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

Passaggio 6. Attendere che lo stato dello stack di apertura 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 |

+--------------------------------------+------------+-----------------+----------------------+----------------------+

Passaggio 7. Verificare che il nuovo nodo di calcolo dell'osd 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    |

Passaggio 8. Accedere al nuovo server di elaborazione osd e verificare i processi di ceph. Inizialmente, lo stato è 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

Passaggio 9. Tuttavia, 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

Ripristino delle VM

Aggiunta all'elenco aggregato Nova

Aggiungere il nodo osd-compute agli host aggregati e verificare se l'host è stato aggiunto.

nova aggregate-add-host

[stack@director ~]$ nova aggregate-add-host esc1 pod1-osd-compute-3.localdomain

nova aggregate-show

[stack@director ~]$ nova aggregate-show esc1

+----+------+-------------------+----------------------------------------+------------------------------------------+

| Id | Name | Availability Zone | Hosts | Metadata |

+----+------+-------------------+----------------------------------------+------------------------------------------+

| 3 | esc1 | AZ-esc1 | 'pod1-osd-compute-3.localdomain' | 'availability_zone=AZ-esc1', 'esc1=true' |

+----+------+-------------------+----------------------------------------+------------------------------------------+

Ripristino di VM ESC

Passaggio 1. Controllare lo stato della VM ESC dall'elenco delle macchine virtuali ed eliminarla.

stack@director scripts]$ nova list |grep esc

| c566efbf-1274-4588-a2d8-0682e17b0d41 | esc                                                | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |

[stack@director scripts]$ nova delete esc

Request to delete server esc has been accepted.

If can not delete esc then use command: nova force-delete esc

Passaggio 2. In OSPD, passare alla directory ECS-Image e assicurarsi che bootvm.py e qws2 per la versione ESC siano presenti, in caso contrario spostarli in una directory.

[stack@atospd ESC-Image-157]$ ll

total 30720136

-rw-r--r--. 1 root  root       127724 Jan 23 12:51 bootvm-2_3_2_157a.py

-rw-r--r--. 1 root  root           55 Jan 23 13:00 bootvm-2_3_2_157a.py.md5sum

-rw-rw-r--. 1 stack stack 31457280000 Jan 24 11:35 esc-2.3.2.157.qcow2

Passaggio 3. Creare l'immagine.

[stack@director ESC-image-157]$  glance image-create --name ESC-2_3_2_157 --disk-format "qcow2" --container "bare" --file /home/stack/ECS-Image-157/ESC-2_3_2_157.qcow2

Passaggio 4. Verificare che l'immagine ESC esista.

stack@director ~]$ glance image-list

+--------------------------------------+--------------------------------------+

| ID                                   | Name                                 |

+--------------------------------------+--------------------------------------+

| 8f50acbe-b391-4433-aa21-98ac36011533 | ESC-2_3_2_157|

| 2f67f8e0-5473-467c-832b-e07760e8d1fa | tmobile-pcrf-13.1.1.iso              |

| c5485c30-45db-43df-831d-61046c5cfd01 | tmobile-pcrf-13.1.1.qcow2            |

| 2f84b9ec-61fa-46a3-a4e6-45f14c93d9a9 | tmobile-pcrf-13.1.1_cco_20170825.iso |

| 25113ecf-8e63-4b81-a73f-63606781ef94 | wscaaa01-sept072017                  |

| 595673e8-c99c-40c2-82b1-7338325024a9 | wscaaa02-sept072017                  |

| 8bce3a60-b3b0-4386-9e9d-d99590dc9033 | wscaaa03-sept072017                  |

| e5c835ad-654b-45b0-8d36-557e6c5fd6e9 | wscaaa04-sept072017                  |

| 879dfcde-d25c-4314-8da0-32e4e73ffc9f | WSP1_cluman_12_07_2017               |

| 7747dd59-c479-4c8a-9136-c90ec894569a | WSP2_cluman_12_07_2017               |

+--------------------------------------+--------------------------------------+

[stack@ ~]$ openstack flavor list

+--------------------------------------+------------+--------+------+-----------+-------+-----------+

| ID                                   | Name       |    RAM | Disk | Ephemeral | VCPUs | Is Public |

+--------------------------------------+------------+--------+------+-----------+-------+-----------+

| 1e4596d5-46f0-46ba-9534-cfdea788f734 | pcrf-smb   | 100352 |  100 |         0 |     8 | True      |

| 251225f3-64c9-4b19-a2fc-032a72bfe969 | pcrf-oam   |  65536 |  100 |         0 |    10 | True      |

| 4215d4c3-5b2a-419e-b69e-7941e2abe3bc | pcrf-pd    |  16384 |  100 |         0 |    12 | True      |

| 4c64a80a-4d19-4d52-b818-e904a13156ca | pcrf-qns   |  14336 |  100 |         0 |    10 | True      |

| 8b4cbba7-40fd-49b9-ab21-93818c80a2e6 | esc-flavor |   4096 |    0 |         0 |     4 | True      |

| 9c290b80-f80a-4850-b72f-d2d70d3d38ea | pcrf-sm    | 100352 |  100 |         0 |    10 | True      |

| e993fc2c-f3b2-4f4f-9cd9-3afc058b7ed1 | pcrf-arb   |  16384 |  100 |         0 |     4 | True      |

| f2b3b925-1bf8-4022-9f17-433d6d2c47b5 | pcrf-cm    |  14336 |  100 |         0 |     6 | True      |

+--------------------------------------+------------+--------+------+-----------+-------+-----------+

Passaggio 5. Creare il file nella directory delle immagini e avviare l'istanza ESC.

[root@director ESC-IMAGE]# cat esc_params.conf

openstack.endpoint = publicURL

[root@director ESC-IMAGE]./bootvm-2_3_2_157a.py esc --flavor esc-flavor --image ESC-2_3_2_157 --net tb1-mgmt --gateway_ip 172.16.181.1 --net tb1-orch --enable-http-rest --avail_zone AZ-esc1 --user_pass "admin:Cisco123" --user_confd_pass "admin:Cisco123" --bs_os_auth_url http://10.250.246.137:5000/v2.0 --kad_vif eth0 --kad_vip 172.16.181.5 --ipaddr 172.16.181.4 dhcp --ha_node_list 172.16.181.3 172.16.181.4 --esc_params_file esc_params.conf

Nota: Dopo che la VM ESC con problemi è stata ridistribuita con lo stesso identico comando bootvm.py dell'installazione iniziale, la sincronizzazione viene eseguita automaticamente senza alcuna procedura manuale. Assicurarsi che il master ESC sia attivo e in esecuzione.

Passaggio 6. Accedere al nuovo ESC e verificare lo stato del backup.

[admin@esc ~]$ escadm status

0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh

============== ESC HA (BACKUP) ===================================================

ESC HEALTH PASSED