Sommario

Introduzione

Premesse

Abbreviazioni

Flusso di lavoro MoP

Errore di un singolo disco rigido

Errore di un singolo disco rigido sul server di elaborazione

Identificazione delle VM ospitate nel nodo di calcolo

Controlli integrità

Errore di un singolo disco rigido sul server controller

Errore di un singolo disco rigido su un server di elaborazione OSD

Errore di un singolo disco rigido sul server OSPD

Introduzione

Questo documento descrive i passaggi necessari per sostituire il disco rigido (HDD) difettoso in un server 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 macchina virtuale (VM) distribuita su Openstack.

Premesse

Ultra-M è una soluzione mobile packet core preconfezionata e convalidata, progettata per semplificare l'installazione delle funzioni di rete virtuale (VNF). OpenStack è Virtual 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 a livello OpenStack al momento della sostituzione del server OSPD.

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

Abbreviazioni

VNF

Funzione di rete virtuale

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 MoP

Errore di un singolo disco rigido

1. Ogni server Baremetal è dotato di due unità HDD che fungono da DISCO DI AVVIO nella configurazione Raid 1. In caso di guasto di un singolo disco rigido, poiché è presente la ridondanza di livello RAID 1, l'unità disco rigido guasta può essere sostituita a caldo.

2. La procedura per la sostituzione di un componente guasto su un server UCS C240 M4 può essere utilizzata da: Sostituzione dei componenti server.

3. In caso di guasto di un singolo disco rigido, solo il disco rigido difettoso viene sostituito a caldo, pertanto non è necessaria alcuna procedura di aggiornamento del BIOS dopo la sostituzione dei nuovi dischi.

4. Dopo la sostituzione dei dischi, è necessario attendere la sincronizzazione dei dati tra i dischi. Il completamento potrebbe richiedere ore.

5. Nella soluzione basata su Openstack (Ultra-M), il server baremetal UCS 240M4 può assumere uno dei seguenti ruoli: Compute, OSD-Compute, Controller e OSPD. Le procedure richieste per la gestione di un singolo errore del disco rigido in ciascuno di questi ruoli server sono le stesse e la sezione seguente descrive i controlli di stato da eseguire prima dell'hot swap del disco.

Errore di un singolo disco rigido sul server di elaborazione

1. Se il guasto delle unità disco rigido viene rilevato in UCS 240M4 che funge da nodo di calcolo, eseguire questi controlli di integrità prima di eseguire la sostituzione a caldo del disco guasto.

2. Identificare le VM in esecuzione su questo server e verificare che lo stato delle funzioni sia buono.

Identificazione delle VM ospitate nel nodo di calcolo

Identificare le VM ospitate nel server di elaborazione e verificare che siano attive e in esecuzione.

[stack@director ~]$ nova list

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

Controlli integrità

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

[root@aaa04 ~]# /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 | grep diametro e verificare che tutte le connessioni Diameter Routing Agent (DRA) siano state stabilite.

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

[root@aa02 logs]# netstat | grep diameter

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

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

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

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

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

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

Il valore di TPS non deve superare 1500.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

top | grep radius

[root@sfraaa02 ~]# top | grep radius

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

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

Passaggio 7. Per verificare l'utilizzo del disco, eseguire il comando df -h.

[root@aaa02 ~]# df -h

Filesystem                       Size  Used Avail Use% Mounted on

/dev/mapper/vg_arucsvm51-lv_root 26G   21G  4.1G  84% /

tmpfs                            1.9G  268K  1.9G   1% /dev/shm

/dev/sda1                        485M   37M  424M   8% /boot

/dev/mapper/vg_arucsvm51-lv_home 23G  4.3G   17G  21% /home

Questo valore complessivo deve essere inferiore all'80%. Se è superiore all'80%, identificare i file non necessari e pulirli.

Passaggio 8. Verificare che non vi siano file "core" generati.

- Il file di base viene generato in caso di arresto anomalo dell'applicazione quando CPAR non è in grado di gestire un'eccezione e viene generato nelle due posizioni seguenti:

[root@aaa02 ~]# cd /cisco-ar/

[root@aaa02 ~]# cd /cisco-ar/bin

In questi due percorsi non devono essere presenti file di base. Se individuato, sollevare una richiesta TAC da Cisco per identificare la causa principale di tale eccezione e allegare i file di base per il debug.

- Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati perché sono necessarie ore per completare.

Sostituzione dei componenti server

- Ripetere le procedure di controllo dello stato per verificare che lo stato delle VM ospitate nel nodo di calcolo sia ripristinato.

Errore di un singolo disco rigido sul server controller

- Se il guasto delle unità disco rigido viene rilevato in UCS 240M4 che funge da nodo di controllo, eseguire questi controlli di integrità prima di eseguire la sostituzione a caldo del disco difettoso.

- Controllare lo stato di Pacemaker sui controller.

- Accedere a uno dei controller attivi e verificare lo stato di pacemaker. Tutti i servizi devono essere in esecuzione sui controller disponibili e arrestati sul controller guasto.

[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: Tue Jul 10 10:04:15 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-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-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

- Controllare lo stato di MariaDB nei controller attivi.

[stack@director ~]$ nova list | grep control

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

[stack@director ~]$ for i in 192.200.0.102 192.200.0.110 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_ state_comment'\" ; sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_cluster_size'\""; done 192.200.0.110 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_st5 192.200.0.110 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_st ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_st3 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_st ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_s1 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local_9 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_local2 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_loca. ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_loc2 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_lo0 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_l0 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep_. ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsrep0 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsre. ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'wsr1 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'ws2 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE 'w0 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql --exec=\"SHOW STATUS LIKE '

*** 192.200.0.102 ***

Variable_nameValue

wsrep_local_state_commentSynced

Variable_nameValue

wsrep_cluster_size2

*** 192.200.0.110 ***

Variable_nameValue

wsrep_local_state_commentSynced

Variable_nameValue

wsrep_cluster_size2

- Verificare che le righe seguenti siano presenti per ogni controller attivo:

wsrep_local_state_comment: Synced

wsrep_cluster_size: 2

- Controllare lo stato di Rabbitmq nei controller attivi.

[heat-admin@pod2-stack-controller-0 ~]$ sudo rabbitmqctl cluster_status

Cluster status of node 'rabbit@pod2-stack-controller-0' ...

[{nodes,[{disc,['rabbit@pod2-stack-controller-0',

'rabbit@pod2-stack-controller-1',

'rabbit@pod2-stack-controller-2']}]},

{running_nodes,['rabbit@pod2-stack-controller-1',

'rabbit@pod2-stack-controller-2',

'rabbit@pod2-stack-controller-0']},

{cluster_name,<<"rabbit@pod2-stack-controller-1.localdomain">>},

{partitions,[]},

{alarms,[{'rabbit@pod2-stack-controller-1',[]},

{'rabbit@pod2-stack-controller-2',[]},

{'rabbit@pod2-stack-controller-0',[]}]}]

- Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati perché sono necessarie ore per completare.

Sostituzione dei componenti server

- Ripetere le procedure di controllo per verificare che lo stato di integrità sul controller sia stato ripristinato.

Errore di un singolo disco rigido su un server di elaborazione OSD

- Se il guasto delle unità disco rigido viene rilevato in UCS 240M4 che funge da nodo di calcolo OSD, eseguire i controlli di integrità prima di eseguire la sostituzione a caldo del disco guasto.

1. Identificazione delle VM ospitate nel nodo di calcolo OSD

2. Identificare le VM ospitate nel server di elaborazione

[stack@director ~]$ nova list

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

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

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

UNIT LOAD ACTIVE SUB DESCRIPTION

var-lib-ceph-osd-ceph\x2d1.mount loaded active mounted /var/lib/ceph/osd/ceph-1

var-lib-ceph-osd-ceph\x2d10.mount loaded active mounted /var/lib/ceph/osd/ceph-10

var-lib-ceph-osd-ceph\x2d4.mount loaded active mounted /var/lib/ceph/osd/ceph-4

var-lib-ceph-osd-ceph\x2d7.mount loaded active mounted /var/lib/ceph/osd/ceph-7

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

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

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

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

system-ceph\x2ddisk.slice loaded active active system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice loaded active active system-ceph\x2dosd.slice

ceph-mon.target loaded active active ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target loaded active active ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target loaded active active ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target loaded active active ceph target allowing to start/stop all ceph*@.service instances at once

LOAD = Reflects whether the unit definition was properly loaded.

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

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

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

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

- Verificare che la mappatura dell'OSD (disco rigido) al Journal (SSD) sia corretta.

[heat-admin@pod2-stack-osd-compute-1 ~]$ sudo ceph-disk list

/dev/sda :

/dev/sda1 other, iso9660

/dev/sda2 other, xfs, mounted on /

/dev/sdb :

/dev/sdb1 ceph journal, for /dev/sdc1

/dev/sdb3 ceph journal, for /dev/sdd1

/dev/sdb2 ceph journal, for /dev/sde1

/dev/sdb4 ceph journal, for /dev/sdf1

/dev/sdc :

/dev/sdc1 ceph data, active, cluster ceph, osd.1, journal /dev/sdb1

/dev/sdd :

/dev/sdd1 ceph data, active, cluster ceph, osd.7, journal /dev/sdb3

/dev/sde :

/dev/sde1 ceph data, active, cluster ceph, osd.4, journal /dev/sdb2

/dev/sdf :

/dev/sdf1 ceph data, active, cluster ceph, osd.10, journal /dev/sdb4

- Verificare che la mappatura dello stato di salute del ceph e della struttura osd sia corretta.

[heat-admin@pod2-stack-osd-compute-1 ~]$ 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 v23095222: 704 pgs, 6 pools, 809 GB data, 424 kobjects

2418 GB used, 10974 GB / 13393 GB avail

704 active+clean

client io 1329 kB/s wr, 0 op/s rd, 122 op/s wr

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

- Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati poiché sono necessarie ore per completare la procedura.

Sostituzione dei componenti server

- Ripetere le procedure di controllo per verificare che lo stato delle VM ospitate nel nodo OSD-Compute sia ripristinato.

Errore di un singolo disco rigido sul server OSPD

- Se il guasto delle unità disco rigido viene rilevato in UCS 240M4 che funge da nodo OSPD, eseguire i controlli di integrità prima di eseguire la sostituzione a caldo del disco guasto.

- Controllare lo stato di openstack e l'elenco dei nodi.

[stack@director ~]$ source stackrc

[stack@director ~]$ openstack stack list --nested

[stack@director ~]$ ironic node-list

[stack@director ~]$ nova list

- Verificare che tutti i servizi undercloud siano in stato caricato, attivo e in esecuzione dal nodo OSP-D.

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

UNIT LOAD ACTIVE SUB DESCRIPTION

neutron-dhcp-agent.service loaded active running OpenStack Neutron DHCP Agent

neutron-metadata-agent.service loaded active running OpenStack Neutron Metadata Agent

neutron-openvswitch-agent.service loaded active running OpenStack Neutron Open vSwitch Agent

neutron-server.service loaded active running OpenStack Neutron Server

openstack-aodh-evaluator.service loaded active running OpenStack Alarm evaluator service

openstack-aodh-listener.service loaded active running OpenStack Alarm listener service

openstack-aodh-notifier.service loaded active running OpenStack Alarm notifier service

openstack-ceilometer-central.service loaded active running OpenStack ceilometer central agent

openstack-ceilometer-collector.service loaded active running OpenStack ceilometer collection service

openstack-ceilometer-notification.service loaded active running OpenStack ceilometer notification agent

openstack-glance-api.service loaded active running OpenStack Image Service (code-named Glance) API server

openstack-glance-registry.service loaded active running OpenStack Image Service (code-named Glance) Registry server

openstack-heat-api-cfn.service loaded active running Openstack Heat CFN-compatible API Service

openstack-heat-api.service loaded active running OpenStack Heat API Service

openstack-heat-engine.service loaded active running Openstack Heat Engine Service

openstack-ironic-api.service loaded active running OpenStack Ironic API service

openstack-ironic-conductor.service loaded active running OpenStack Ironic Conductor service

openstack-ironic-inspector-dnsmasq.service loaded active running PXE boot dnsmasq service for Ironic Inspector

openstack-ironic-inspector.service loaded active running Hardware introspection service for OpenStack Ironic

openstack-mistral-api.service loaded active running Mistral API Server

openstack-mistral-engine.service loaded active running Mistral Engine Server

openstack-mistral-executor.service loaded active running Mistral Executor Server

openstack-nova-api.service loaded active running OpenStack Nova API Server

openstack-nova-cert.service loaded active running OpenStack Nova Cert Server

openstack-nova-compute.service loaded active running OpenStack Nova Compute Server

openstack-nova-conductor.service loaded active running OpenStack Nova Conductor Server

openstack-nova-scheduler.service loaded active running OpenStack Nova Scheduler Server

openstack-swift-account-reaper.service loaded active running OpenStack Object Storage (swift) - Account Reaper

openstack-swift-account.service loaded active running OpenStack Object Storage (swift) - Account Server

openstack-swift-container-updater.service loaded active running OpenStack Object Storage (swift) - Container Updater

openstack-swift-container.service loaded active running OpenStack Object Storage (swift) - Container Server

openstack-swift-object-updater.service loaded active running OpenStack Object Storage (swift) - Object Updater

openstack-swift-object.service loaded active running OpenStack Object Storage (swift) - Object Server

openstack-swift-proxy.service loaded active running OpenStack Object Storage (swift) - Proxy Server

openstack-zaqar.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server

openstack-zaqar@1.service loaded active running OpenStack Message Queuing Service (code-named Zaqar) Server Instance 1

openvswitch.service loaded active exited Open vSwitch

LOAD = Reflects whether the unit definition was properly loaded.

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

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

lines 1-43

lines 2-44 37 loaded units listed. Pass --all to see loaded but inactive units, too.

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

lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END) lines 4-46/46 (END)

- Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati poiché sono necessarie ore per completare la procedura.

Sostituzione dei componenti server

- Ripetere le procedure di controllo dello stato per verificare che lo stato di integrità del nodo OSPD sia ripristinato.