Sommario

Introduzione

Premesse

Abbreviazioni

Flusso di lavoro di MoP

Arresto applicazione CPAR

Attività snapshot VM

Snapshot VM

Ripristino delle VM

Ripristina istanza con snapshot

Crea e assegna indirizzo IP mobile

Abilitazione SSH

Definizione sessione SSH

Avvio istanza CPAR

Controllo dello stato post-attività

Introduzione

In questo documento vengono descritti i passaggi necessari per sostituire un disco di storage degli oggetti (OSD) - server di elaborazione con un'installazione Ultra-M difettosa.

Questa procedura è valida per un ambiente Openstack con la versione NEWTON in cui ESC non gestisce CPAR e CPAR viene installato direttamente sulla macchina virtuale (VM) distribuita su Openstack.

Premesse

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

- Calcola

- OSD - Calcolo

- 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 in dettaglio i passaggi richiesti da eseguire nei sistemi operativi OpenStack e Redhat.

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

Abbreviazioni

MoP

Metodo

OSD

Dischi Object Storage

OSPD

OpenStack Platform Director

HDD

Unità hard disk

SSD

Unità a stato solido

VIM

Virtual Infrastructure Manager

VM

Macchina virtuale

EM

Gestione elementi

UAS

Ultra Automation Services

UUID

Identificatore univoco universale

Flusso di lavoro di MoP

Backup

Prima di sostituire un nodo 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 sostituzione Calcola è attivo. Questo flusso di sostituzione consente di ottenere il risultato desiderato.

In caso di ripristino, Cisco consiglia di eseguire un backup del database OSPD 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.

Nota: Assicurarsi di disporre dello snapshot dell'istanza in modo da poter ripristinare la VM quando necessario. Seguire la procedura per creare un'istantanea della VM.

1. Identificare le VM ospitate nel nodo di calcolo OSD.

2. Identificare le VM ospitate nel server.

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

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

Arresto applicazione CPAR

Passaggio 1. Aprire un client Secure Shell (SSH) connesso alla rete e connettersi all'istanza CPAR.

È importante non arrestare tutte e 4 le istanze AAA all'interno di un sito contemporaneamente, farlo uno alla volta.

Passaggio 2. Per chiudere l'applicazione CPAR, eseguire il comando:

/opt/CSCOar/bin/arserver stop

Viene visualizzato il messaggio "Cisco Prime Access Registrar Server Agent shutdown complete". devono presentarsi.

Nota: Se un utente ha lasciato aperta una sessione di interfaccia della riga di comando (CLI), il comando arserver stop non funzionerà e verrà visualizzato questo messaggio.

ERROR:    You cannot shut down Cisco Prime Access Registrar while the

CLI is being used.   Current list of running

CLI with process id is:

2903 /opt/CSCOar/bin/aregcmd –s

In questo esempio, è necessario terminare il processo evidenziato con ID 2903 prima di poter arrestare CPAR. In questo caso, eseguire il comando per terminare il processo:

kill -9 *process_id*

Ripetere quindi il passaggio 1.

Passaggio 3. Per verificare che l'applicazione CPAR sia stata effettivamente chiusa, eseguire il comando:

/opt/CSCOar/bin/arstatus

Devono essere visualizzati i seguenti messaggi:

Cisco Prime Access Registrar Server Agent not running

Cisco Prime Access Registrar GUI not running

Attività snapshot VM

Passaggio 1. Accedere al sito Web dell'interfaccia utente di Horizon corrispondente al sito (Città) su cui si sta lavorando.

Quando accedete a Horizon, la schermata osservata è quella mostrata in questa immagine.

Passaggio 2. Passare a Progetto > Istanze come mostrato in questa immagine.

Se l'utente utilizzato era CPAR, in questo menu vengono visualizzate solo le 4 istanze AAA.

Passaggio 3. Chiudere una sola istanza alla volta e ripetere l'intero processo in questo documento. Per arrestare la VM, passare a Azioni > Arresta istanza come mostrato nell'immagine e confermare la selezione.

Passaggio 4. Verificare che l'istanza sia stata effettivamente chiusa controllando lo stato = Shutoff e lo stato di alimentazione = Shut Down (Chiuso), come mostrato nell'immagine.

Questo passaggio termina il processo di chiusura CPAR.

Snapshot VM

Una volta che le VM CPAR sono inattive, le istantanee possono essere eseguite in parallelo in quanto appartengono a computer indipendenti.

I quattro file QCOW2 vengono creati in parallelo.

Eseguire un'istantanea di ciascuna istanza AAA. (25 minuti - 1 ora) (25 minuti per le istanze che utilizzano un'immagine qws come origine e 1 ora per le istanze che utilizzano un'immagine raw come origine)

1. Accedere alla GUI di Openstack di POD’s Horizon.

2. Una volta eseguito l'accesso, spostarsi nella sezione Progetto > Calcola > Istanze del menu superiore e cercare le istanze AAA come mostrato in questa immagine.

3. Fare clic su Create Snapshot per procedere con la creazione dello snapshot (che deve essere eseguito sull'istanza AAA corrispondente), come mostrato nell'immagine.

4. Una volta eseguita l'istantanea, fare clic su Images (Immagini) e verificare che tutte le operazioni siano terminate e che non vengano segnalati problemi, come mostrato nell'immagine.

5. Il passaggio successivo consiste nel scaricare la copia istantanea in formato QCOW2 e trasferirla in un'entità remota, nel caso in cui l'OSPD venga perso durante questo processo. A tale scopo, identificare la copia istantanea eseguendo il comando glance image-list a livello OSPD.

[root@elospd01 stack]# glance image-list

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

| ID                                   | Name                      |             +--------------------------------------+---------------------------+

| 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary             |             | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017    |

| 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017    |

| e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image                 |

| 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017       |

| 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso   |

| 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 |

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

6. Dopo aver identificato lo snapshot da scaricare (quello contrassegnato in verde), è possibile scaricarlo in formato QCOW2 con il comando glance image-download come illustrato.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

- Il &processo viene inviato in background. Il completamento di questa operazione richiede del tempo. Al termine, l'immagine può trovarsi nella directory /tmp.

- Quando si invia il processo in background, se la connettività viene persa, anche il processo viene interrotto.

- Eseguire il comando diswn -h in modo che, in caso di perdita della connessione SSH, il processo continui a essere in esecuzione e venga completato sull'host OSPD.

7. Al termine del processo di download, è necessario eseguire un processo di compressione poiché lo snapshot potrebbe essere riempito con ZEROES a causa di processi, task e file temporanei gestiti dal sistema operativo. Il comando da utilizzare per la compressione dei file è virtualizzato.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Questo processo può richiedere del tempo (circa 10-15 minuti). Al termine, il file risultante deve essere trasferito a un'entità esterna come specificato nel passo successivo.

Per ottenere questo risultato, è necessario verificare l'integrità del file, eseguire il comando successivo e cercare l'attributo "corrupt" alla fine dell'output.

[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2

image: AAA-CPAR-LGNoct192017_compressed.qcow2

file format: qcow2

virtual size: 150G (161061273600 bytes)

disk size: 18G

cluster_size: 65536

Format specific information:

compat: 1.1

lazy refcounts: false

refcount bits: 16

corrupt: false

- Per evitare un problema di perdita dell'OSPD, è necessario trasferire lo snapshot creato di recente in formato QCOW2 a un'entità esterna. Prima di avviare il trasferimento di file, è necessario verificare se la destinazione dispone di spazio su disco sufficiente, eseguire il comando df -kh per verificare lo spazio di memoria. Si consiglia, ad esempio, di trasferirla temporaneamente nell'OSPD di un altro sito con l'SFTP sftp root@x.x.x.x", dove x.x.x.x è l'IP di un OSPD remoto. Per velocizzare il trasferimento, la destinazione può essere inviata a più OSPD. Allo stesso modo, è possibile eseguire il comando scp *name_of_the_file*.qws2 root@ x.x.x.x:/tmp (dove x.x.x.x è l'indirizzo IP di un OSPD remoto) per trasferire il file a un altro OSPD.

1. Identificare le VM ospitate nel nodo di calcolo OSD.

2. Identificare le VM ospitate nel server.

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |

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

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

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df

GLOBAL:

SIZE       AVAIL      RAW USED     %RAW USED

13393G     11088G        2305G         17.21

POOLS:

NAME        ID     USED      %USED     MAX AVAIL     OBJECTS

rbd         0          0         0         3635G           0

metrics     1      3452M      0.09         3635G      219421

images      2       138G      3.67         3635G       43127

backups     3          0         0         3635G           0

volumes     4       139G      3.70         3635G       36581

vms         5       490G     11.89         3635G      126247

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

[heat-admin@pod2-stack-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 pod2-stack-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 pod2-stack-osd-compute-1

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 pod2-stack-osd-compute-2

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

- I processi CEPH sono attivi sul server di elaborazione a video.

[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph*

UNIT                             LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0

var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3

var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6

var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9

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

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

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

ceph-osd@9.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

LOAD   = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB    = The low-level unit activation state, values depend on unit type.

14 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'.

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

[heat-admin@pod2-stack-osd-compute-0  ~]# systemctl disable ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0

- osd.0 contrassegnato.

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0

- l'id elemento 0 denominato 'osd.0' è stato rimosso dalla mappa di distribuzione

[heat-admin@pod2-stack-osd-compute-0  ~]# ceph auth del osd.0

- aggiornato

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0

- osd.0 rimosso

[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0

[heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0

O,

- È possibile utilizzare lo script Clean.sh per questa attività contemporaneamente.

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

ceph-0  ceph-3  ceph-6  ceph-9

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

[heat-admin@pod2-stack-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 in stato Degraded ma hd-disk deve ancora essere accessibile.

Spegnimento regolare

- Spegni nodo

1. Per spegnere l'istanza: nova stop <NOME_ISTANZA>

2. È possibile visualizzare il nome dell'istanza con lo stato Shutoff.

[stack@director ~]$ nova stop  aaa2-21

Request to stop server aaa2-21 has been accepted.

[stack@director ~]$ nova list

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

| ID                                   | Name                      | Status  | Task State | Power State | Networks                                                                                                   |

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

| 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE  | -          | Running     | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 |

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | SHUTOFF | -          | Shutdown    | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234  |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | ACTIVE  | -          | Running     | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10                 |

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

- Eliminazione nodo

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

Eliminare OSD-Compute Node dall'elenco dei servizi.

- Eliminare il servizio di elaborazione dall'elenco dei servizi:
[stack@director ~]$ openstack compute service list |grep osd-compute

| 135 | nova-compute     | pod2-stack-osd-compute-1.localdomain | AZ-esc2  | enabled | up    | 2018-06-22T11:05:22.000000 |

| 150 | nova-compute     | pod2-stack-osd-compute-2.localdomain | nova     | enabled | up    | 2018-06-22T11:05:17.000000 |

| 153 | nova-compute     | pod2-stack-osd-compute-0.localdomain | AZ-esc1  | enabled | up    | 2018-06-22T11:05:25.000000 |

- openstack calcolare service delete <ID>

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

Elimina agenti neutroni

- Eliminare il vecchio agente neutronico associato e aprire l'agente vswitch per il computer server:
[stack@director ~]$ openstack network agent list | grep osd-compute-0

| eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None              | True  | UP    | neutron-openvswitch-agent |

- openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22

Elimina da database ironico

- Eliminare un nodo dal database ironico e verificarlo:

[root@director ~]#  nova list | grep osd-compute-0

| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.109 |

[root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f

- mostra novità < compute -node> | hypervisor grep

[root@director ~]# source stackrc

[root@director ~]#  nova show pod2-stack-osd-compute-0 | grep hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 05ceb513-e159-417d-a6d6-cbbcc4b167d7

- ironic node-delete <ID>

[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7

[stack@director ~]$ ironic node-list

Il nodo eliminato non deve essere elencato in ironic node-list.

Elimina da overcloud

- Creare un file script denominato delete_node.sh con il contenuto come mostrato. Verificare che i modelli menzionati 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-name> <UUID>

[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 pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444

Deleting the following nodes from stack pod2-stack:

- 7439ea6c-3a88-47c2-9ff5-0a4f24647444

Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s

user   0m0.383s

sys    0m0.086s

- 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 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |

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

Installa 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 Non configurato correttamente:

Selezionare Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Informazioni sull'unità fisica), come mostrato in questa immagine.

- Creare un'unità virtuale dalle unità fisiche con RAID di livello 1:

Passare a Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Informazioni controller > Crea unità virtuale da unità fisiche inutilizzate come mostrato in questa immagine.

- Selezionare il DVD e configurare Set as Boot Drive (Imposta come unità di avvio) come mostrato nell'immagine.

- Abilitare IPMI over LAN:

Passare ad Amministrazione > Servizi di comunicazione > Servizi di comunicazione come mostrato nell'immagine.

- Disabilita hyperthreading:

Passare a Calcola > BIOS > Configura BIOS > Avanzate > Configurazione processore come mostrato nell'immagine.

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

JOURNAL > From physical drive number 3

OSD1 > From physical drive number 7

OSD2 > From physical drive number 8

OSD3 > From physical drive number 9

OSD4 > From physical drive number 10

- Alla fine, le unità fisiche e virtuali devono essere simili a quelle mostrate nelle immagini.

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.

Aggiungi nuovo nodo di calcolo OSD a overcloud

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

- Aggiungere il server di calcolo 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 calcolo non sia stato utilizzato in precedenza. In genere, incrementa il successivo valore di calcolo più alto.

Esempio: La versione precedente più alta era osd-compute-17, quindi è stato creato osd-compute-18 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 del nodo con l'utilizzo dell'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 a custom-templates/layout.yml sotto Osd Compute IPs. In questo caso, sostituendo l'indirizzo osd-compute-0 si aggiunge 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

- Eseguire lo script deploy.sh precedentemente utilizzato per distribuire lo stack, per aggiungere il nuovo nodo di calcolo allo stack del cloud esterno:
[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 il completamento dello stato dello stack aperto:

[stack@director ~]$  openstack stack list

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

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

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

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |

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

- Verificare che il nuovo nodo di calcolo 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 di elaborazione osd e verificare i processi 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

- 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

Ripristino delle VM

Ripristina istanza con snapshot

È possibile ridistribuire l'istanza precedente con l'istantanea eseguita nei passaggi precedenti.

Passaggio 1. (Facoltativo) Se non sono disponibili snapshot della VM precedenti, connettersi al nodo OSPD in cui è stato inviato il backup e riportare il backup al nodo OSPD originale tramite SFTP. Utilizzando sftp root@x.x.x.xwhere x.x.x.x è l'indirizzo IP di un OSPD originale. Salvare il file snapshot nella directory /tmp.

Passaggio 2. Connettersi al nodo OSPD in cui viene ridistribuita l'istanza.

Originare le variabili di ambiente con questo comando:

# source /home/stack/pod1-stackrc-Core-CPAR

Passaggio 3. Per utilizzare l'istantanea come immagine, è necessario caricarla in Horizon come tale. Eseguire il comando successivo.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

Il processo può essere visto in orizzontale come mostrato in questa immagine.

Passaggio 4. In Orizzonte, passare a Progetto > Istanze e fare clic su Avvia istanza, come mostrato nell'immagine.

Passaggio 5. Inserire il nome dell'istanza e scegliere la zona di disponibilità come mostrato in questa immagine.

Passaggio 6. Nella scheda Origine, scegliere l'immagine per creare l'istanza. Nel menu Select Boot Source, selezionare image (Seleziona origine di avvio), viene visualizzato un elenco di immagini, scegliere quella precedentemente caricata facendo clic sul suo segno + e come mostrato in questa immagine.

Passaggio 7. Nella scheda Gusto, scegliere il gusto AAA facendo clic sul segno + come mostrato nell'immagine.

Passaggio 8. Infine, passare alla scheda Rete e scegliere le reti necessarie all'istanza facendo clic sul segno +. In questo caso, selezionare diametralmente-definibile1, radius-routable1 e tb1-mgmt, come mostrato nell'immagine.

Passaggio 9. Infine, fare clic su Avvia istanza per crearla. L'avanzamento può essere monitorato in Orizzonte come mostrato in questa immagine.

Dopo alcuni minuti l'istanza verrà completamente distribuita e pronta per l'utilizzo.

Crea e assegna indirizzo IP mobile

Un indirizzo IP mobile è un indirizzo instradabile, ossia è raggiungibile dall'esterno dell'architettura Ultra M/Openstack e può comunicare con altri nodi dalla rete.

Passaggio 1. Nel menu in alto Orizzonte, selezionare Admin > Floating IPs (Amministratore > IP mobili).

Passaggio 2. Fare clic su Alloca IP al progetto.

Passaggio 3. Nella finestra Alloca IP mobile, selezionare il pool dal quale appartiene il nuovo IP mobile, il progetto al quale verrà assegnato e il nuovo indirizzo IP mobile stesso.

Ad esempio:

Passaggio 4. Fare clic su Alloca IP mobile.

Passaggio 5. Nel menu in alto Orizzonte, passare a Progetto > Istanze.

Passaggio 6. Nella colonna Azione, fare clic sulla freccia rivolta verso il basso nel pulsante Crea snapshot, è necessario visualizzare un menu. Selezionare l'opzione Associa IP mobile.

Passaggio 7. Selezionare l'indirizzo IP mobile corrispondente da utilizzare nel campo IP Address, quindi scegliere l'interfaccia di gestione corrispondente (eth0) dalla nuova istanza a cui verrà assegnato l'indirizzo IP mobile nella porta da associare. Fare riferimento all'immagine seguente come esempio di questa procedura.

Passaggio 8. Infine, fare clic su Associa.

Abilitazione SSH

Passaggio 1. Nel menu in alto Orizzonte, passare a Progetto > Istanze.

Passaggio 2. Fare clic sul nome dell'istanza o della macchina virtuale creata nella sezione Creazione di una nuova istanza.

Passaggio 3. Fare clic su Console. Verrà visualizzata la CLI della VM.

Passaggio 4. Dopo aver visualizzato la CLI, immettere le credenziali di accesso appropriate:

Username: radice

Password: cisco123 come mostrato in questa immagine.

Passaggio 5. Nella CLI, eseguire il comando vi /etc/ssh/sshd_config per modificare la configurazione ssh.

Passaggio 6. Una volta aperto il file di configurazione SSH, premere I per modificare il file. Cercare quindi la sezione visualizzata e modificare la prima riga da PasswordAuthentication no a PasswordAuthentication yes.

Passaggio 7. Premere ESC e immettere :wq! per salvare le modifiche apportate al file sshd_config.

Passaggio 8. Eseguire il comando service sshd restart.

Passaggio 9. Per verificare che le modifiche alla configurazione SSH siano state applicate correttamente, aprire un client SSH e provare a stabilire una connessione remota sicura usando l'IP mobile assegnato all'istanza (ad esempio 10.145.0.249) e la radice dell'utente.

Definizione sessione SSH

Passaggio 1. Aprire una sessione SSH con l'indirizzo IP della macchina virtuale/server corrispondente in cui è installata l'applicazione, come mostrato nell'immagine.

Avvio istanza CPAR

Seguire questi passaggi, una volta che l'attività è stata completata e i servizi CPAR possono essere ristabiliti nel Sito che è stato chiuso.

Passaggio 1. Accedere nuovamente a Orizzonte, selezionare Progetto > Istanza > Avvia istanza.

Passaggio 2. Verificare che lo stato dell'istanza sia Attivo e lo stato di alimentazione sia In esecuzione, come mostrato nell'immagine.

Controllo dello stato post-attività

Passaggio 1. Eseguire il comando /opt/CSCOar/bin/arstatus a livello di sistema operativo:

[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus

Cisco Prime AR RADIUS server running       (pid: 24834)

Cisco Prime AR Server Agent running        (pid: 24821)

Cisco Prime AR MCD lock manager running    (pid: 24824)

Cisco Prime AR MCD server running          (pid: 24833)

Cisco Prime AR GUI running (pid: 24836)

SNMP Master Agent running                (pid: 24835)

[root@wscaaa04 ~]#

Passaggio 2. Eseguire il comando /opt/CSCOar/bin/aregcmd a livello di sistema operativo e immettere le credenziali dell'amministratore. Verificare che CPAr Health sia 10 su 10 e che esista dalla CLI di CPAR.

[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd

Cisco Prime Access Registrar 7.3.0.1 Configuration Utility

Copyright (C) 1995-2017 by Cisco Systems, Inc.  All rights reserved.

Cluster:

User: admin

Passphrase:

Logging in to localhost

[ //localhost ]

LicenseInfo = PAR-NG-TPS 7.2(100TPS:)

PAR-ADD-TPS 7.2(2000TPS:)

PAR-RDDR-TRX 7.2()

PAR-HSS 7.2()

Radius/

Administrators/

Server 'Radius' is Running, its health is 10 out of 10

--> exit

Passaggio 3. Eseguire il comando netstat | diametro grep e verificare che tutte le connessioni DRA siano stabilite.

L'output qui menzionato è relativo a un ambiente in cui sono previsti collegamenti con diametro. Se vengono visualizzati meno collegamenti, si tratta di una disconnessione da DRA che deve essere analizzata.

[root@aa02 logs]# netstat | grep diameter

tcp         0            0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED

tcp         0            0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED

tcp         0            0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED

tcp         0            0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED

tcp         0            0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED

Passaggio 4. Verificare che nel registro TPS siano visualizzate le richieste elaborate da CPAR. I valori evidenziati rappresentano i TPS e quelli a cui è necessario prestare attenzione.

Il valore di TPS non deve superare 1500.

[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv

11-21-2017,23:57:35,263,0

11-21-2017,23:57:50,237,0

11-21-2017,23:58:05,237,0

11-21-2017,23:58:20,257,0

11-21-2017,23:58:35,254,0

11-21-2017,23:58:50,248,0

11-21-2017,23:59:05,272,0

11-21-2017,23:59:20,243,0

11-21-2017,23:59:35,244,0

11-21-2017,23:59:50,233,0

Passaggio 5. Cercare eventuali messaggi "error" o "alarm" in name_radius_1_log.

[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log

Passaggio 6. Per verificare la quantità di memoria utilizzata dal processo CPAR, eseguire il comando:

top | grep radius

[root@sfraaa02 ~]# top | grep radius

27008 root      20   0 20.228g 2.413g  11408 S 128.3  7.7   1165:41 radius

Questo valore evidenziato deve essere inferiore a 7 Gb, ovvero il valore massimo consentito a livello di applicazione.