Falha de disco rígido único UCS 240M4 Ultra-M - Procedimento de troca a quente - CPS

Opções de download

  • PDF     (350.5 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (264.2 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (235.9 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:21 de setembro de 2018
ID do documento:213713

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

    Introduction

    Este documento descreve as etapas necessárias para substituir a unidade de disco rígido defeituosa em um servidor em uma configuração Ultra-M que hospeda o Cisco Policy Suite (CPS) Virtual Network Function (VNFs).

    Informações de Apoio

    O Ultra-M é uma solução de núcleo de pacotes móveis virtualizados, pré-embalada e validada, projetada para simplificar a implantação de VNFs. O OpenStack é o Virtualized Infrastructure Manager (VIM) para Ultra-M e consiste nos seguintes tipos de nó:

    • Computação
    • Disco de Armazenamento de Objeto - Computação (OSD - Compute)
    • Controlador
    • Plataforma OpenStack - Diretor (OSPD)

    A arquitetura de alto nível da Ultra-M e os componentes envolvidos são mostrados nesta imagem:

    Arquitetura UltraM

    Note: A versão Ultra M 5.1.x é considerada para definir os procedimentos neste documento. Este documento destina-se ao pessoal da Cisco familiarizado com a plataforma Cisco Ultra-M e detalha as etapas necessárias para serem executadas no nível OpenStack no momento da substituição do servidor OSPD.

    Abreviaturas

    VNF   Função de rede virtual
    ESC   Controlador de serviço elástico
    MOP   Método de Procedimento
    OSD   Discos de Armazenamento de Objeto
    HDD   Unidade de disco rígido
    SSD   Unidade de estado sólido
    VIM   Virtual Infrastructure Manager
    VM    Máquina virtual
    EM    Gestor de Elementos
    UAS   Ultra Automation Services
    UUID   Identificador de ID universal exclusivo

    Fluxo de trabalho do MoP

    Falha de HDD única

    1. Cada servidor baremetal será provisionado com duas unidades de disco rígido para atuar como disco de inicialização na configuração do Raid 1. Em caso de falha de um disco rígido, como há redundância de nível Raid 1, a unidade de disco rígido com falha pode ser hot swap (troca a quente).

    2. Consulte o procedimento para substituir um componente defeituoso no servidor UCS C240 M4 aqui: Substituindo os componentes do servidor

    3. Em caso de falha de um disco rígido, apenas o disco rígido defeituoso será trocado a quente e, portanto, não é necessário nenhum procedimento de atualização do BIOS após a substituição de novos discos.

    4. Depois de substituir os discos, aguarde a sincronização de dados entre eles. Pode levar algumas horas para ser concluído.

    5. Em uma solução baseada em OpenStack (Ultra-M), o servidor baremetal UCS 240M4 pode assumir uma das seguintes funções: Computação, OSD-Compute, Controlador e OSPD.

    6. As etapas necessárias para lidar com a falha de HDD única em cada uma dessas funções de servidor são as mesmas e esta seção descreve as verificações de integridade a serem realizadas antes da troca a quente do disco.

    Falha de HDD única em um servidor de computação

    1. Se a falha de unidades de disco rígido for observada no UCS 240M4, que atua como um nó de computação, execute essas verificações de integridade antes de iniciar o procedimento de hot swap do disco defeituoso.

    2. Identifique as VMs em execução neste servidor e verifique se o status das funções está bom.

    Identificar as VMs hospedadas no nó de computação

    Identifique as VMs hospedadas no servidor de computação e verifique se estão ativas e em execução. 

    O servidor de computação contém a combinação VMs CPS/controlador de serviços elásticos (ESC) de VMs:

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

    Note: Na saída mostrada aqui, a primeira coluna corresponde ao UUID (Universal Unique IDentifier), a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente.

    Verificações de integridade

    1. Faça login no ESC hospedado no nó de computação e verifique o status.

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

      

    2. Faça login no UAS hospedado no nó de computação e verifique o status.

    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 as verificações de integridade estiverem corretas, continue com o procedimento de hot swap de disco defeituoso e aguarde a sincronização de dados, pois pode levar algumas horas para ser concluída. Consulte: Substituindo os componentes do servidor

    4. Repita esses procedimentos de verificação de integridade para confirmar se o status de integridade das VMs hospedadas no nó de computação foi restaurado.

    Falha de HDD única em um servidor de controlador

    1. Se a falha das unidades de disco rígido for observada no UCS 240M4, que atua como o nó Controlador, execute essas verificações de integridade antes de iniciar o procedimento Hot Swap do disco defeituoso.

    2. Verifique o status do Pacemaker nos controladores.

    3. Faça login em um dos controladores ativos e verifique o status do Pacemaker. Todos os serviços devem estar em execução nos controladores disponíveis e parados no controlador com falha.

    [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. Verifique o status de MariaDB nos controladores ativos.

    [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

    Verifique se essas linhas estão presentes para cada controlador ativo:

    wsrep_local_state_comment: Synced

    wsrep_cluster_size: 2

     5. Verifique o status do Rabbitmq nos controladores ativos.

    [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 as verificações de integridade estiverem corretas, continue com o procedimento de hot swap de disco defeituoso e aguarde a sincronização de dados, pois pode levar algumas horas para ser concluída. Consulte: Substituindo os componentes do servidor

    7. Repita esses procedimentos de verificação de integridade para confirmar se o status de integridade no controlador foi restaurado.

    Falha de HDD única em um servidor de computação OSD

    Se a falha de unidades de disco rígido for observada no UCS 240M4, que atua como um nó de OSD-Compute, execute essas verificações de integridade antes de iniciar o procedimento de hot swap do disco defeituoso.

    Identificar as VMs hospedadas no nó de computação OSD

      

    1. O servidor de computação contém 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 |

    Note: Na saída mostrada aqui, a primeira coluna corresponde ao (UUID), a segunda coluna é o nome da VM e a terceira coluna é o nome do host onde a VM está presente.

    2. Os processos Ceph estão ativos no servidor OSD-Compute.

    [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. Verifique se o mapeamento do OSD (disco rígido) para o Diário (SSD) está bom.

    [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. Verifique se a integridade do Ceph e o mapeamento da árvore OSD estão bons.

    [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 as verificações de integridade estiverem corretas, continue com o procedimento de hot swap de disco defeituoso e aguarde a sincronização de dados, pois pode levar algumas horas para ser concluída. Consulte Substituindo os componentes do servidor

    6. Repita esses procedimentos de verificação de integridade para confirmar se o status de integridade das VMs hospedadas no nó de computação OSD foi restaurado.

    Falha de HDD única em um servidor OSPD

    1. Se a falha das unidades de disco rígido for observada no UCS 240M4, que atua como um nó OSPD, é recomendável executar essas verificações antes de iniciar o procedimento Hot Swap do disco defeituoso.

    2. Verifique o status da pilha do OpenStack e a lista de nós.

    [stack@director ~]$ source stackrc 
    [stack@director ~]$ openstack stack list --nested
    [stack@director ~]$ ironic node-list
    [stack@director ~]$ nova list

    3. Verifique se todos os serviços em nuvem estão no status carregado, ativo e em execução no nó 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 as verificações de integridade estiverem corretas, continue com o procedimento de hot swap de disco defeituoso e aguarde a sincronização de dados, pois pode levar algumas horas para ser concluída. Consulte Substituindo os componentes do servidor

    5. Repita esses procedimentos de verificação de integridade para confirmar se o status de integridade do nó OSPD foi restaurado.

    TAC Authored

    Colaborado por engenheiros da Cisco

    • Aaditya Deodhar
      Cisco Advanced Services

    Este documento lhe foi útil?

    FeedbackFeedback

    Contate a Cisco

    Este documento se refere a estes produtos