Sommario

Introduzione

Premesse

Abbreviazioni

Flusso di lavoro del piano di mobilità

Prerequisiti

Backup

Identificare le VM ospitate nel nodo di calcolo

Processo snapshot

Arresto applicazione CPAR

Attività snapshot VM

Snapshot VM

Spegnimento regolare

Calcola eliminazione nodo

Elimina nodo di calcolo dall'elenco dei servizi

Elimina agenti neutroni

Elimina dal database Ironic

Elimina da overcloud

Installare il nuovo nodo di calcolo

Aggiungi nuovo nodo di calcolo all'overcloud

Ripristino delle VM

Ripristino di un'istanza tramite snapshot

Creazione e assegnazione di un indirizzo IP mobile

Abilitazione SSH

Definizione di una sessione SSH

Avvio istanza CPAR

Controllo dello stato post-attività

Introduzione

Questo documento descrive i passaggi necessari per sostituire un server di elaborazione difettoso in una configurazione Ultra-M.

Questa procedura è valida per un ambiente Openstack che utilizza la versione NEWTON in cui Elastic Serives Controller (ESC) non gestisce Cisco Prime Access Registrar (CPAR) e CPAR viene installato direttamente sulla VM distribuita in Openstack.

Premesse

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

- Calcola

- Disco Object Storage - Compute (OSD - Compute)

- Controller

- Piattaforma OpenStack - Director (OSPD)

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

Questo documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive in dettaglio i passaggi richiesti da eseguire in OpenStack e Redhat OS.

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 del piano di mobilità

Prerequisiti

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@ al03-pod2-ospd ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

[root@ al03-pod2-ospd ~]# 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. Attenersi alla procedura seguente per creare un'istantanea della VM.

Identificare le VM ospitate nel nodo di calcolo

Identificare le VM ospitate nel server di elaborazione.

[stack@al03-pod2-ospd ~]$ nova list --field name,host

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

| ID                                   | Name                      | Host                             |

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

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

| 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21                   | pod2-stack-compute-3.localdomain |

| f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june                 | pod2-stack-compute-3.localdomain |

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

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

Processo snapshot

Arresto applicazione CPAR

Passaggio 1. Aprire un client 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. Chiudere l'applicazione CPAR con questo comando:

/opt/CSCOar/bin/arserver stop

In un messaggio viene visualizzato il messaggio "Cisco Prime Access Registrar Server Agent shutdown complete" (Arresto agente server Cisco Prime Access Registrar completato). dovrebbe presentarsi.

Nota: Se un utente ha lasciato aperta una sessione CLI, il comando arserver stop non funziona e viene visualizzato il seguente messaggio:

ERROR:    You can not 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, terminare il processo con questo comando:

kill -9 *process_id*

Ripetere quindi il punto 1.

Passaggio 3. Verificare che l'applicazione CPAR sia stata effettivamente chiusa con questo comando:

/opt/CSCOar/bin/arstatus

Verranno visualizzati i messaggi seguenti:

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 si accede a Horizon, viene osservata la schermata mostrata nell'immagine:

Passaggio 2. Come mostrato nell'immagine, selezionare Progetto > Istanze.

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

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

4. Verificare che l'istanza sia stata effettivamente chiusa tramite Status = Shutoff e Power State = Shut Down.

Questo passaggio termina il processo di chiusura CPAR.

Snapshot VM

Una volta disattivate le VM CPAR, 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 hanno utilizzato un'immagine qws come origine e 1 ora per le istanze che utilizzano un'immagine raw come origine).

Passaggio 1. Accesso alla GUI Horizon del POD Openstack.

Passaggio 2. Una volta eseguito l'accesso, passare alla sezione Progetto > Calcola > Istanze del menu superiore e cercare le istanze AAA.

Passaggio 3. Fare clic su Crea snapshot per procedere con la creazione dello snapshot (questa operazione deve essere eseguita sull'istanza AAA corrispondente).

Passaggio 4. Una volta eseguita l'istantanea, passare al menu Immagini e verificare che sia completa e che non presenti alcun problema.

Passaggio 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 con questo 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 |

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

Passaggio 6. Una volta identificata la copia istantanea da scaricare (in questo caso sarà quella contrassegnata in verde sopra), viene scaricata in formato QCOW2 tramite questo comando glance image-download come mostrato di seguito.

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

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

- Quando il processo viene inviato in background, se la connettività viene interrotta, anche il processo viene interrotto.

- Eseguire il comando diswn -h in modo che, in caso di perdita della connessione Secure Shell (SSH), il processo continui a essere eseguito e venga completato sull'host.

Passaggio 7. Al termine del processo di download, è necessario eseguire un processo di compressione in quanto 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 richiede un certo 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. Per verificare lo spazio di memoria, utilizzare il comando df -kh. Si consiglia di trasferirlo temporaneamente nell'OSPD di un altro sito tramite 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, questo comando può essere utilizzato 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 in un altro OSPD.

Spegnimento regolare

Spegni nodo

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

2. A questo punto viene visualizzato 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                 |

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

Calcola eliminazione nodo

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

Elimina nodo di calcolo dall'elenco dei servizi

Eliminare il servizio di elaborazione dall'elenco dei servizi:

[stack@director ~]$ openstack compute service list |grep compute-3

| 138 | nova-compute     | pod2-stack-compute-3.localdomain     | AZ-aaa   | enabled | up    | 2018-06-21T15:05:37.000000 |

openstack calcolare service delete <ID>

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

Elimina agenti neutroni

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

[stack@director ~]$ openstack network agent list | grep compute-3

| 3b37fa1d-01d4-404a-886f-ff68cec1ccb9 | Open vSwitch agent | pod2-stack-compute-3.localdomain     | None              | True  | UP    | neutron-openvswitch-agent |

openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete 3b37fa1d-01d4-404a-886f-ff68cec1ccb9

Elimina dal database Ironic

Eliminare un nodo dal database ironico e verificarlo:

mostra novità <calcolare-node> | hypervisor grep

[root@director ~]# source stackrc

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

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 7439ea6c-3a88-47c2-9ff5-0a4f24647444

ironic node-delete <ID>

[stack@director ~]$ ironic node-delete 7439ea6c-3a88-47c2-9ff5-0a4f24647444

[stack@director ~]$ ironic node-list

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

Elimina da overcloud

Passaggio 1. Creare un file di script denominato delete_node.sh con il contenuto come 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-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

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

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

Installare il nuovo nodo di calcolo

Per informazioni sulle procedure di installazione di un nuovo server UCS C240 M4 e sulle procedure di configurazione iniziali, consultare la 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 corrisponde alla versione consigliata utilizzata in precedenza. Le fasi per l'aggiornamento del BIOS sono riportate di seguito: Guida all'aggiornamento del BIOS dei server con montaggio in rack Cisco UCS serie C

Passaggio 4. Per verificare lo stato delle unità fisiche, che non è configurato correttamente, selezionare Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info.

Passaggio 5. Per creare un'unità virtuale dalle unità fisiche con RAID di livello 1, selezionare Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Informazioni controller > Crea unità virtuale da unità fisiche inutilizzate.

Passaggio 6. Selezionare il DVD e configurare Set as Boot Drive, come mostrato nell'immagine.

Passaggio 7. Per abilitare IPMI su LAN, selezionare Admin > Communication Services > Communication Services, come mostrato nell'immagine.

Passaggio 8. Per disabilitare l'HyperThreading, selezionare Compute > BIOS > Configure BIOS > Advanced > Processor Configuration.

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 all'overcloud

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

Passaggio 1. Aggiungere un 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 è compute-17, quindi è stata creata compute-18 nel caso del sistema 2-vnf.

Nota: Prestare attenzione al formato json.

[stack@director ~]$ cat add_node.json

{

"nodes":[

{

"mac":[

"<MAC_ADDRESS>"

],

"capabilities": "node:compute-18,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. Eseguire lo script deploy.sh precedentemente utilizzato per distribuire lo stack, per aggiungere il nuovo nodo del computer 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 5. Attendere che lo stato dello stack di apertura sia Completo.

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

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

Passaggio 6. Verificare che il nuovo nodo di calcolo sia nello stato Attivo.

[root@director ~]# nova list | grep pod2-stack-compute-4

| 5dbac94d-19b9-493e-a366-1e2e2e5e34c5 | pod2-stack-compute-4     | ACTIVE | -          | Running     | ctlplane=192.200.0.116 |

Ripristino delle VM

Ripristino di un'istanza tramite snapshot

Processo di ripristino:

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

Passaggio 1 [FACOLTATIVO]. Se non sono disponibili snapshot della macchina virtuale precedenti, connettersi al nodo OSPD in cui è stato inviato il backup e reindirizzare il backup al nodo OSPD originale. Tramite sftp root@x.x.x.x dove x.x.x.x è l'indirizzo IP dell'OSPD originale. Salvare il file snapshot nella directory /tmp.

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

Originare le variabili di ambiente con il comando seguente:

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

Passaggio 3. Per utilizzare l'istantanea come immagine è necessario caricarla in Horizon come tale. A tale scopo, utilizzare 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 all'orizzonte.

Passaggio 4. Nell'orizzonte, selezionare 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 nell'immagine.

Passaggio 6. Nella scheda Origine, scegliere l'immagine per creare l'istanza. Nel menu Select Boot Source select image (Seleziona origine di avvio), viene visualizzato un elenco di immagini; selezionare quella che era stata caricata in precedenza facendo clic sul segno +.

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

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

Passaggio 9. Fare clic su Avvia istanza per crearla. I progressi possono essere monitorati in Orizzonte:

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

Creazione e assegnazione di un 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, passare ad Amministrazione > IP mobili.

Passaggio 2. Fare clic sul pulsante Allocate IP to Project (Assegna 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 lo stesso indirizzo IP mobile.

Ad esempio:

Passaggio 4. Fare clic sul pulsante 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 per visualizzare un menu. Selezionare l'opzione Associa IP mobile.

Passaggio 7. Selezionare l'indirizzo IP mobile corrispondente da utilizzare nel campo IP Address (Indirizzo IP), 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. 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/macchina virtuale creata nella sezione Avviare una nuova istanza.

Passaggio 3. Fare clic sulla scheda Console. Viene visualizzata la CLI della VM.

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

Username: radice

Password: cisco 123

Passaggio 5. Nella CLI, immettere 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 riportata di seguito 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 di una sessione SSH

Aprire una sessione SSH con l'indirizzo IP della macchina virtuale/server corrispondente in cui è installata l'applicazione.

Avvio istanza CPAR

Una volta completata l'attività, sarà possibile ristabilire i servizi CPAR nel Sito che è stato chiuso.

1. Per accedere nuovamente a Orizzonte, selezionare Progetto > Istanza > Avvia istanza.

2. Verificare che lo stato dell'istanza sia attivo e che lo stato di alimentazione sia in esecuzione:

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 l'uscita da CPAR CLI sia corretta.

[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 riportato di seguito è 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 dobbiamo 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. Verificare la quantità di memoria del processo CPAR con questo comando:

inizio | raggio grep

[root@sfraaa02 ~]# top | grep radius

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

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