Guasto di un singolo disco rigido Ultra-M UCS 240M4 - Procedura di sostituzione a caldo - CPS

Opzioni per il download

  • PDF     (350.6 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (265.4 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (237.1 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:21 settembre 2018
ID documento:213713

Linguaggio senza pregiudizi

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.

Informazioni su questa traduzione

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

    Introduzione

    In questo documento viene descritto come sostituire l'unità HDD difettosa di un server in una configurazione Ultra-M che ospita VNF (Virtual Network Function) di Cisco Policy Suite (CPS).

    Premesse

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

    • Calcola
    • Disco Object Storage - Compute (OSD - Compute)
    • Controller
    • Piattaforma OpenStack - Director (OSPD)

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

    Architettura UltraM

    Nota: Per definire le procedure descritte in questo documento, viene presa in considerazione la versione Ultra M 5.1.x. Il presente documento è destinato al personale Cisco che ha familiarità con la piattaforma Cisco Ultra-M e descrive in dettaglio i passaggi da eseguire a livello di OpenStack al momento della sostituzione del server OSPD.

    Abbreviazioni

    VNF   Funzione di rete virtuale
    ESC   Elastic Service Controller
    MOP   Metodo
    OSD   Dischi Object Storage
    HDD   Unità hard disk
    SSD   Unità a stato solido
    VIM   Virtual Infrastructure Manager
    VM    Macchina virtuale
    EM    Gestione elementi
    UAS   Ultra Automation Services
    UUID   Identificatore univoco universale

    Flusso di lavoro del piano di mobilità

    Errore di un singolo disco rigido

    1. A ciascun server Baremetal verranno forniti due dischi rigidi che fungeranno da disco di avvio nella configurazione Raid 1. In caso di guasto di un singolo disco rigido, poiché è presente una ridondanza di livello Raid 1, l'unità disco rigido guasta può essere sostituita a caldo.

    2. Fare riferimento alla procedura per sostituire un componente guasto sul server UCS C240 M4 qui: Sostituzione dei componenti del server

    3. In caso di guasto di un singolo disco rigido, solo il disco rigido difettoso verrà sostituito a caldo e quindi non sarà necessaria alcuna procedura di aggiornamento del BIOS dopo la sostituzione dei nuovi dischi.

    4. Dopo aver sostituito i dischi, attendere la sincronizzazione dei dati tra i dischi. Il completamento potrebbe richiedere un paio d'ore.

    5. In una soluzione basata su OpenStack (Ultra-M), il server baremetal UCS 240M4 può assumere uno dei seguenti ruoli: Compute, OSD-Compute, Controller e OSPD.

    6. Le fasi richieste per gestire il guasto di un singolo disco rigido in ciascuno di questi ruoli server sono le stesse e in questa sezione vengono descritti i controlli di stato da eseguire prima dell'hot swap del disco.

    Errore di un singolo disco rigido su un 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 avviare la procedura di sostituzione a caldo del disco guasto.

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

    Identificare le VM ospitate nel nodo di calcolo

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

    Il server di elaborazione contiene una combinazione di VM CPS/Elastic Services Controller (ESC):

    [stack@director ~]$ nova list --field name,host | grep compute-8
    | 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     | ACTIVE |
    | f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c2_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     | ACTIVE | 
    | 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     | ACTIVE |

    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.

    Controlli integrità

    1. Accedere all'ESC ospitato nel nodo di calcolo e controllare lo stato.

    [admin@VNF2-esc-esc-0 esc-cli]$ escadm status
    0 ESC status=0 ESC Master Healthy

      

    2. Accedere all'UAS ospitato nel nodo di calcolo e controllare lo stato.

    ubuntu@autovnf2-uas-1:~$ sudo su
    root@autovnf2-uas-1:/home/ubuntu# confd_cli -u admin -C
    Welcome to the ConfD CLI
    admin connected from 127.0.0.1 using console on autovnf2-uas-1
    autovnf2-uas-1#show uas ha
    uas ha-vip 172.18.181.101
    autovnf2-uas-1#
    autovnf2-uas-1#
    autovnf2-uas-1#show uas
    uas version 1.0.1-1
    uas state ha-active
    uas ha-vip 172.18.181.101
    INSTANCE IP   STATE  ROLE          
    -----------------------------------
    172.18.180.4  alive  CONFD-SLAVE            
    172.18.180.5  alive  CONFD-MASTER  
    172.18.180.8  alive  NA            

    autovnf2-uas-1#show errors 
    % No entries found.

    3. Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati, in quanto potrebbe richiedere un paio d'ore per completare. Vedere: Sostituzione dei componenti server

    4. Ripetere queste procedure di controllo dello stato per confermare che lo stato di integrità delle VM ospitate nel nodo di calcolo sia ripristinato.

    Errore di un singolo disco rigido su un server controller

    1. Se il guasto delle unità HDD viene osservato in UCS 240M4 che funge da nodo del controller, eseguire questi controlli di integrità prima di avviare la procedura di sostituzione a caldo del disco guasto.

    2. Controllare lo stato di Pacemaker sui controller.

    3. Accedere a uno dei controller attivi e controllare lo stato di Pacemaker. Tutti i servizi devono essere in esecuzione sui controller disponibili e arrestati sul controller guasto.

    [heat-admin@pod1-controller-0 ~]$ sudo pcs status
    Cluster name: tripleo_cluster
    Stack: corosync
    Current DC: pod1-controller-0 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
    Last updated: Thu Jun 28 07:53:06 2018          Last change: Wed Jan 17 11:38:00 2018 by root via cibadmin on pod1-controller-0

    3 nodes and 22 resources conimaged

    Online: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]

    Full list of resources:

     ip-10.2.2.2      (ocf::heartbeat:IPaddr2):       Started pod1-controller-0
     ip-11.120.0.42 (ocf::heartbeat:IPaddr2):       Started pod1-controller-1
     ip-11.119.0.42 (ocf::heartbeat:IPaddr2):       Started pod1-controller-2
     ip-11.120.0.50 (ocf::heartbeat:IPaddr2):       Started pod1-controller-0
     ip-11.118.0.48 (ocf::heartbeat:IPaddr2):       Started pod1-controller-1
     ip-192.200.0.102       (ocf::heartbeat:IPaddr2):       Started pod1-controller-2
     Clone Set: haproxy-clone [haproxy]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: galera-master [galera]
         Masters: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Clone Set: rabbitmq-clone [rabbitmq]
         Started: [ pod1-controller-0 pod1-controller-1 pod1-controller-2 ]
     Master/Slave Set: redis-master [redis]
         Masters: [ pod1-controller-0 ]
         Slaves: [ pod1-controller-1 pod1-controller-2 ]
     openstack-cinder-volume        (systemd:openstack-cinder-volume):      Started pod1-controller-0
     my-ipmilan-for-controller-0    (stonith:fence_ipmilan):        Started pod1-controller-1
     my-ipmilan-for-controller-1    (stonith:fence_ipmilan):        Started pod1-controller-2
     my-ipmilan-for-controller-2    (stonith:fence_ipmilan):        Started pod1-controller-0

    Daemon Status:
      corosync: active/enabled
      pacemaker: active/enabled
      pcsd: active/enabled

    4. Controllare lo stato di MariaDB nei controller attivi.

    [stack@director] nova list | grep control
    | 4361358a-922f-49b5-89d4-247a50722f6d | pod1-controller-0 | ACTIVE | - | Running | ctlplane=192.200.0.102 |
    | d0f57f27-93a8-414f-b4d8-957de0d785fc | pod1-controller-1 | ACTIVE | - | Running | ctlplane=192.200.0.110 |

    [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.152 ***
    Variable_name     Value
    wsrep_local_state_comment  Synced
    Variable_name     Value
    wsrep_cluster_size         2
    *** 192.200.0.154 ***
    Variable_name     Value
    wsrep_local_state_comment  Synced
    Variable_name     Value
    wsrep_cluster_size         2

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

    wsrep_local_state_comment: Synced

    wsrep_cluster_size: 2

     5. Controllare lo stato di Rabbitmq nei controllori attivi.

    [heat-admin@pod1-controller-0 ~]$ sudo rabbitmqctl cluster_status
    Cluster status of node 'rabbit@pod1-controller-0' ...
    [{nodes,[{disc,['rabbit@pod1-controller-0','rabbit@pod1-controller-1',
                    'rabbit@pod1-controller-2']}]},
     {running_nodes,['rabbit@pod1-controller-2',
                     'rabbit@pod1-controller-1',
                     'rabbit@pod1-controller-0']},
     {cluster_name,<<"rabbit@pod1-controller-0.localdomain">>},
     {partitions,[]},
     {alarms,[{'rabbit@pod1-controller-2',[]},
              {'rabbit@pod1-controller-1',[]},
              {'rabbit@pod1-controller-0',[]}]}]

    6. Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettoso e attendere la sincronizzazione dei dati, in quanto potrebbe richiedere un paio d'ore per completare. Vedere: Sostituzione dei componenti server

    7. Ripetere queste procedure di controllo dello stato per confermare che lo stato di salute sul controller è 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 questi controlli di integrità prima di avviare la procedura di sostituzione a caldo del disco guasto.

    Identificare le VM ospitate nel nodo di calcolo OSD

      

    1. Il server di elaborazione contiene VM ESC.

    [stack@director ~]$ nova list --field name,host | grep osd-compute-1
    | 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea   | pod1-compute-8.localdomain     | ACTIVE |
    | f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     | ACTIVE |
    | 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     | ACTIVE |
    | f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     | ACTIVE |

    Nota: Nell'output mostrato di seguito, la prima colonna corrisponde a (UUID), la seconda colonna è il nome della VM e la terza colonna è il nome host in cui la VM è presente.

    2. Sul server OSD-Compute sono attivi i processi Ceph.

    [root@pod1-osd-compute-1 ~]# systemctl list-units *ceph*

    UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

    var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

    var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

    var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

    var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

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

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

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

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

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

    [heat-admin@pod1-osd-compute-3 ~]$ 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

    4. Verificare che lo stato di salute di Ceph e la mappatura dell'albero OSD siano corretti.

    [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s
        cluster eb2bb192-b1c9-11e6-9205-525400330666
         health HEALTH_OK
                1 mons down, quorum 0,1 pod1-controller-0,pod1-controller-1
         monmap e1: 3 mons at {pod1-controller-0=11.118.0.10:6789/0,pod1-controller-1=11.118.0.11:6789/0,pod1-controller-2=11.118.0.12:6789/0}
                election epoch 28, quorum 0,1 pod1-controller-0,pod1-controller-1
         osdmap e709: 12 osds: 12 up, 12 in
                flags sortbitwise,require_jewel_osds
          pgmap v941813: 704 pgs, 6 pools, 490 GB data, 163 kobjects
                1470 GB used, 11922 GB / 13393 GB avail
                     704 active+clean
      client io 58580 B/s wr, 0 op/s rd, 7 op/s wr
    [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph osd tree
    ID WEIGHT   TYPE NAME                   UP/DOWN REWEIGHT PRIMARY-AFFINITY 
    -1 13.07996 root default                                                  
    -2  4.35999     host pod1-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                                  
    -4  4.35999     host pod1-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 
    -5  4.35999     host pod1-osd-compute-3                                   
     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

    5. Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettosa e attendere la sincronizzazione dei dati, in quanto potrebbero essere necessarie alcune ore per completare la procedura. Per ulteriori informazioni, fare riferimento al documento sulla sostituzione dei componenti server

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

    Errore di un singolo disco rigido su un server OSPD

    1. Se il guasto delle unità HDD viene rilevato in UCS 240M4, che funge da nodo OSPD, si consiglia di eseguire questi controlli prima di avviare la procedura di sostituzione a caldo del disco guasto.

    2. Controllare lo stato dello stack 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

    3. Verificare se tutti i servizi undercloud sono in stato caricato, attivo e in esecuzione dal nodo OSPD. 

    [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-openvswitch-agent.service          loaded active running OpenStack Neutron Open vSwitch Agent
    neutron-ovs-cleanup.service                loaded active exited  OpenStack Neutron Open vSwitch Cleanup Utility
    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.

    37 loaded units listed. Pass --all to see loaded but inactive units, too.
    To show all installed unit files use 'systemctl list-unit-files'.

    4. Se i controlli di integrità sono corretti, procedere con la procedura di sostituzione a caldo del disco difettoso e attendere la sincronizzazione dei dati, in quanto potrebbe richiedere un paio d'ore per completare. Per ulteriori informazioni, fare riferimento al documento sulla sostituzione dei componenti server

    5. Ripetere queste procedure di controllo dello stato per confermare che lo stato di integrità del nodo OSPD è ripristinato.

    TAC Authored

    Contributo dei tecnici Cisco

    • Aaditya Deodhar
      Cisco Advanced Services

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci

    Questo documento si applica a questi prodotti