Sommario

Introduzione

Premesse

Abbreviazioni

Flusso di lavoro di MoP

Prerequisiti

Backup

RMA componente - Nodo di calcolo

Identificazione delle VM ospitate nel nodo di calcolo

1. Chiusura dell'applicazione CPAR

2. Attività snapshot VM

Snapshot VM

Spegnimento regolare

Sostituisci componente difettoso da nodo di calcolo

Ripristino delle VM

Ripristina istanza con snapshot

Crea e assegna indirizzo IP mobile

Abilitazione SSH

Definizione sessione SSH

RMA componente - Nodo di calcolo OSD

Identificazione delle VM ospitate nel nodo di calcolo OSD

1. Chiusura dell'applicazione CPAR

2. Attività snapshot VM

Snapshot VM

Metti CEPH in modalità di manutenzione

Spegnimento regolare

Sostituire il componente difettoso dal nodo di elaborazione OSD

Sposta CEPH fuori dalla modalità di manutenzione

Ripristino delle VM

Ripristina istanza con snapshot

RMA component - Controller Node

Verifica preliminare

Sposta cluster controller in modalità manutenzione

Sostituzione del componente difettoso dal nodo del controller

Accendi server

Introduzione

Questo documento descrive i passaggi necessari per sostituire i componenti guasti menzionati qui in un server UCS (Unified Computing System) in una configurazione Ultra-M.

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

- Modulo di memoria DIMM (Dual In-line Memory Module) sostitutivo

- Errore del controller FlexFlash

- Errore unità a stato solido (SSD)

- Errore del TPM (Trusted Platform Module)

- Errore cache RAID

- Errore del controller RAID/HBA (Hot Bus Adapter)

- Errore riser PCI

- Scheda PCIe Intel X520 10G guasto

- Errore MLOM (Modular LAN-on Motherboard)

- Vassoio ventola RMA

- Errore CPU

Premesse

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

- Calcola

- 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 di MoP

Prerequisiti

Backup

Prima di sostituire un componente difettoso, è 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 è 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. Inoltre, si consiglia di eseguire il backup della configurazione StarOS soprattutto se il nodo di calcolo/OSD da sostituire ospita la macchina virtuale (VM) CF (Control Function).

Nota: Se Server è il nodo Controller, passare alla sezione "", altrimenti passare alla sezione successiva. 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.

RMA componente - Nodo di calcolo

Identificazione delle VM ospitate nel nodo di calcolo

Identificare le VM ospitate nel server.

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

Backup: PROCESSO SNAPSHOT

1. Chiusura dell'applicazione CPAR

Passaggio 1. Aprire un client SSH connesso alla rete di produzione TMO 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 CLI, il comando arserver stop non funziona e viene 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, terminare il processo eseguendo il comando:

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

2. 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, questa schermata viene visualizzata.

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 descritto in questo documento. Per arrestare la VM, passare a Azioni > Arresta istanza come mostrato in questa 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 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 ogni 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)

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

2. Una volta effettuato l'accesso, spostatevi su PROJECT > COMPUTE > INSTANCES (PROGETTO > CALCOLA > ISTANZE) nel menu superiore e cercate le istanze AAA come mostrato in questa immagine.

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

4. Una volta eseguita l'istantanea, passare al menu Immagini e verificare che tutte le operazioni siano completate e che non vengano segnalati problemi, come mostrato in questa 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. Una volta identificata la copia istantanea da scaricare (quella contrassegnata in verde), è possibile scaricarla in formato QCOW2 con il comando glance image-download come illustrato di seguito.

[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 può richiedere 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 può 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. A tale scopo, utilizzare il comando df -kh. Si consiglia, ad esempio, di trasferirla temporaneamente nell'OSPD di un altro sito utilizzando SFTP sftproot@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 in un altro OSPD.

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                 |

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

Sostituisci componente difettoso da nodo di calcolo

Spegnere il server specificato. Per sostituire un componente guasto su un server UCS C240 M4, è possibile seguire la procedura descritta di seguito:

Sostituzione dei componenti server

Ripristino delle VM

Ripristina istanza con snapshot

Processo di ripristino

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

Passaggio 1. [facoltativo] Se non è disponibile alcuna istantanea VM precedente, connettersi al nodo OSPD in cui è stato inviato il backup e riportare il backup al nodo OSPD originale tramite SFTP. Con sftproot@x.x.x.x dove x.x.x.x è l'IP di un OSPD originale. Salvare il file snapshot nella directory /tmp.

Passaggio 2. Connettersi al nodo OSPD in cui è possibile ridistribuire l'istanza, come mostrato nell'immagine.

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 sull'orizzonte 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 e come mostrato in questa immagine.

Passaggio 4. In 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 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 sapore 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.

Infine, fare clic su Avvia istanza per crearla. I progressi possono essere monitorati in Orizzonte:

Dopo alcuni minuti, l'istanza è completamente distribuita e pronta per l'uso, come mostrato in questa immagine.

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 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, viene visualizzato 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 successiva 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 Avviare una nuova istanza.

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

Passaggio 4. Una volta visualizzata la CLI, immettere le credenziali di accesso appropriate, come mostrato nell'immagine:

Nome utente:root

Password:cisco123

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

Passaggio 6. Dopo aver aperto il file di configurazione SSH, premere I per modificare il file. Cercare quindi la sezione e modificare la prima riga da PasswordAuthentication no a PasswordAuthentication yes, come mostrato nell'immagine.

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

Passaggio 8. Eseguire il comando service sshd restart come mostrato nell'immagine.

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, come mostrato nell'immagine.

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 che lo stato di alimentazione sia In esecuzione come illustrato in questa immagine.

9. 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 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. Verificare la quantità di memoria utilizzata dal processo CPAR eseguendo 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.

RMA componente - Nodo di calcolo OSD

Identificazione delle VM ospitate nel nodo di calcolo OSD

Identificare le VM ospitate nel server OSD-Compute.

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

Backup: PROCESSO SNAPSHOT

1. Chiusura dell'applicazione CPAR

Passaggio 1. Aprire un client SSH connesso alla rete di produzione TMO 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 CLI, il comando arserver stop non funziona e viene 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, terminare il processo eseguendo il comando:

kill -9 *process_id*

Ripetere quindi il punto 1.

Passaggio 3. Verificare che l'applicazione CPAR sia stata effettivamente chiusa eseguendo 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

2. 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, è possibile osservare questa schermata.

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

Se l'utente utilizzato era CPAR, in questo menu possono essere 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 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 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 utilizzano un'immagine qws come origine e 1 ora per le istanze che utilizzano un'immagine raw come origine)

1. Accesso alla GUI Openstack del POD

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 (Crea snapshot) per procedere con la creazione dello snapshot (che deve essere eseguita sull'istanza AAA corrispondente), come mostrato nell'immagine.

4. Una volta eseguita l'istantanea, passare al menu Immagini e verificare che tutti finiscano e segnalino i problemi come mostrato in questa 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 di seguito.

[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 può richiedere 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 può 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 -khin per verificare lo spazio di memoria. Si consiglia, ad esempio, di trasferirla temporaneamente nell'OSPD di un altro sito utilizzando SFTP sftproot@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.

Metti CEPH in modalità di manutenzione

Nota: Se il componente difettoso deve essere sostituito su un nodo OSD-Compute, attivare la manutenzione sul server prima di procedere con la sostituzione del componente.

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

[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

- Accedere al nodo di calcolo OSD e impostare CEPH in modalità di manutenzione.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set norebalance

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd set noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

noout,norebalance,sortbitwise,require_jewel_osds flag(s) set

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e79: 12 osds: 12 up, 12 in

flags noout,norebalance,sortbitwise,require_jewel_osds

pgmap v22844323: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3858 kB/s wr, 0 op/s rd, 546 op/s wr

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                 |

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

Sostituire il componente difettoso dal nodo di elaborazione OSD

Spegnere il server specificato. Per sostituire un componente guasto su un server UCS C240 M4, è possibile seguire la procedura descritta di seguito:

Sostituzione dei componenti server

Sposta CEPH fuori dalla modalità di manutenzione

- Accedere al nodo di calcolo OSD e spostare CEPH fuori dalla modalità di manutenzione.

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset norebalance

[root@pod2-stack-osd-compute-0 ~]# sudo ceph osd unset noout

[root@pod2-stack-osd-compute-0 ~]# sudo ceph status

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e81: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr

Ripristino delle VM

Ripristina istanza con snapshot

Processo di ripristino

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

Passaggio 1. [FACOLTATIVO] Se non è disponibile alcuna copia istantanea VM precedente, connettersi al nodo OSPD in cui è stato inviato il backup e reinserire il backup nel nodo OSPD originale. Utilizzando sftproot@x.x.x.x dove x.x.x.x è l'IP di un OSPD originale. Salvare il file snapshot nella directory /tmp.

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

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 all'orizzonte.

Passaggio 4. In 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 (Seleziona origine di avvio) selezionare Image (Immagine), 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 +.

Passaggio 8. Infine, 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.

Infine, 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.

Creare e assegnare 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, 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 Avviare una nuova istanza.

Passaggio 3. Fare clic sulla scheda Console. Verrà visualizzata l'interfaccia della riga di comando della macchina virtuale.

Passaggio 4. Una volta visualizzata la CLI, immettere le credenziali di accesso appropriate, come mostrato nell'immagine:

Nome utente:root

Password:cisco123

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 questa sezione e modificare la prima riga da PasswordAuthentication no a PasswordAuthentication yes.

Passaggio 7. Premere ESC e immettere :wq!per salvare le modifiche 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 utilizzando l'indirizzo IP della macchina virtuale o del server corrispondente in cui è installata l'applicazione.

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.

9. 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. Verificare la quantità di memoria utilizzata dal processo CPAR eseguendo 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.

RMA component - Controller Node

Verifica preliminare

- Da OSPD, effettuare il login al controller e verificare che lo stato dei pc sia buono. Tutti e tre i controller Online e Galera presentano tutti e tre i controller come Master.

Nota: Un cluster integro richiede 2 controller attivi, quindi verificare che i due controller rimanenti siano online e attivi.

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:37 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Sposta cluster controller in modalità manutenzione

- Eseguire il cluster pcs sul controller aggiornato in standby:

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster standby

- Controllare di nuovo lo stato del pcs e verificare che il cluster del pcs sia stato arrestato in questo nodo:

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:10 2018Last change: Fri Jul 6 09:03:06 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Node pod2-stack-controller-0: standby

Online: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-1 ]

Stopped: [ pod2-stack-controller-0 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Inoltre, lo stato del pcs sugli altri 2 controller deve indicare il nodo come standby.

Sostituzione del componente difettoso dal nodo del controller

Spegnere il server specificato. Per sostituire un componente guasto su un server UCS C240 M4, è possibile seguire la procedura descritta di seguito:

Sostituzione dei componenti server

Accendi server

- Accendere il server e verificarne l'accensione:

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list

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

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

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

| 03f15071-21aa-4bcf-8fdd-acdbde305168 | pod2-stack-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.106 |

| 1f725ce3-948d-49e9-aed9-b99e73d82644 | pod2-stack-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.107 |

| fbc13c78-dc06-4ac9-a3c5-595ccc147adc | pod2-stack-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.119 |

| 3b94e0b1-47dc-4960-b3eb-d02ffe9ae693 | pod2-stack-compute-3 | ACTIVE | - | Running | ctlplane=192.200.0.112 |

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

| b896c73f-d2c8-439c-bc02-7b0a2526dd70 | pod2-stack-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.113 |

| 2519ce67-d836-4e5f-a672-1a915df75c7c | pod2-stack-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.105 |

| e19b9625-5635-4a52-a369-44310f3e6a21 | pod2-stack-controller-2 | ACTIVE | - | Running | ctlplane=192.200.0.120 |

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

| 26d3f7b1-ba97-431f-aa6e-ba91661db45d | pod2-stack-osd-compute-1 | ACTIVE | - | Running | ctlplane=192.200.0.117 |

| 6e4a8aa9-4870-465a-a7e2-0932ff55e34b | pod2-stack-osd-compute-2 | ACTIVE | - | Running | ctlplane=192.200.0.103 |

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

- Accedere al controller interessato e rimuovere la modalità standby utilizzando unstandby. Verificare che il controller sia in linea con il cluster e che in Galera tutti e tre i controller siano visualizzati come Master. L'operazione potrebbe richiedere alcuni minuti:

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs cluster unstandby

[heat-admin@pod2-stack-controller-0 ~]$ sudo pcs status

Cluster name: tripleo_cluster

Stack: corosync

Current DC: pod2-stack-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum

Last updated: Fri Jul 6 09:03:37 2018Last change: Fri Jul 6 09:03:35 2018 by root via crm_attribute on pod2-stack-controller-0

3 nodes and 19 resources configured

Online: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Full list of resources:

ip-11.120.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Clone Set: haproxy-clone [haproxy]

Started: [ pod2-stack-controller-0 pod2-stack-controller-1 pod2-stack-controller-2 ]

Master/Slave Set: galera-master [galera]

Masters: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 ]

ip-192.200.0.110(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

ip-11.120.0.44(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

ip-11.118.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

Clone Set: rabbitmq-clone [rabbitmq]

Started: [ pod2-stack-controller-1 pod2-stack-controller-2 ]

Stopped: [ pod2-stack-controller-0 ]

ip-10.225.247.214(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-1

Master/Slave Set: redis-master [redis]

Masters: [ pod2-stack-controller-2 ]

Slaves: [ pod2-stack-controller-0 pod2-stack-controller-1 ]

ip-11.119.0.49(ocf::heartbeat:IPaddr2):Started pod2-stack-controller-2

openstack-cinder-volume(systemd:openstack-cinder-volume):Started pod2-stack-controller-1

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

- È possibile verificare che alcuni servizi di monitoraggio, ad esempio ceph, siano in buono stato:

[heat-admin@pod2-stack-controller-0 ~]$ sudo ceph -s

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {pod2-stack-controller-0=11.118.0.10:6789/0,pod2-stack-controller-1=11.118.0.11:6789/0,pod2-stack-controller-2=11.118.0.12:6789/0}

election epoch 10, quorum 0,1,2 pod2-stack-controller-0,pod2-stack-controller-1,pod2-stack-controller-2

osdmap e81: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v22844355: 704 pgs, 6 pools, 804 GB data, 423 kobjects

2404 GB used, 10989 GB / 13393 GB avail

704 active+clean

client io 3658 kB/s wr, 0 op/s rd, 502 op/s wr