La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
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.
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:
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.
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 |
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 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.
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
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.
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 &
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.
Spegni nodo
[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 | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+
I passaggi menzionati in questa sezione sono comuni indipendentemente dalle VM ospitate nel nodo di calcolo.
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
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
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.
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 | +--------------------------------------+------------+-----------------+----------------------+----------------------+
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.
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 |
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.
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.
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.
Aprire una sessione SSH con l'indirizzo IP della macchina virtuale/server corrispondente in cui è installata l'applicazione.
Una volta completata l'attività, sarà possibile ristabilire i servizi CPAR nel Sito che è stato chiuso.
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.