Substituição de OSD-Compute UCS 240M4 - CPAR

Introduction

Este documento descreve as etapas necessárias para substituir um OSD (Object Storage Disk, disco de armazenamento de objeto) com falha - Computar o servidor em uma configuração Ultra-M.

Este procedimento se aplica a um ambiente Openstack com versão NEWTON em que ESC não gerencia CPAR e CPAR é instalado diretamente na Máquina virtual (VM) implantada no Openstack.

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 Virtual Infrastructure Manager (VIM) para Ultra-M e consiste nos seguintes tipos de nó:

• Computação
• OSD - Computação
• Controlador
• Plataforma OpenStack - Diretor (OSPD)

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

Este documento destina-se aos funcionários da Cisco que estão familiarizados com a plataforma Cisco Ultra-M e detalha as etapas necessárias para serem executadas no OpenStack e no sistema operacional (SO) Redhat.

Note: A versão Ultra M 5.1.x é considerada para definir os procedimentos neste documento.

Abreviaturas

MoP	MétodoProcedimento
OSD	Discos de Armazenamento de Objeto
OSPD	OpenStack Platform Diretor
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

  

Backup

Antes de substituir um nó de computação, é importante verificar o estado atual do ambiente da plataforma Red Hat OpenStack. Recomenda-se que você verifique o estado atual para evitar complicações quando o processo de substituição Compute estiver ativo. Isso pode ser feito por meio desse fluxo de substituição.

Em caso de recuperação, a Cisco recomenda fazer um backup do banco de dados OSPD com o uso destas etapas:

[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

Esse processo garante que um nó possa ser substituído sem afetar a disponibilidade de quaisquer instâncias.

Note: Certifique-se de ter o instantâneo da instância para que você possa restaurar a VM quando necessário. Siga o procedimento sobre como fazer um snapshot da VM.

1. Identifique as VMs hospedadas no nó OSD-Compute.
2. Identifique as VMs hospedadas no servidor.

  

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

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. Os parâmetros dessa saída são usados em seções subsequentes. 

Desligamento do aplicativo CPAR

Etapa 1. Abra qualquer cliente Secure Shell (SSH) conectado à rede e conecte-se à instância do CPAR.

É importante não desligar todas as 4 instâncias de AAA em um site ao mesmo tempo, fazer isso de uma forma por uma.

Etapa 2. Para desligar o aplicativo CPAR, execute o comando:

/opt/CSCOar/bin/arserver stop

Uma mensagem "Cisco Prime Access Registrar Server Agent desligado concluído". deve aparecer.

Note: Se um usuário deixou uma sessão da Interface de Linha de Comando (CLI) aberta, o comando arserver stop não funcionará e essa mensagem será exibida.

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

Neste exemplo, a ID de processo 2903 destacada precisa ser encerrada para que o CPAR possa ser interrompido. Se esse for o caso, execute o comando para encerrar este processo:

kill -9 *process_id*

Em seguida, repita a Etapa 1.

Etapa 3. Para verificar se o aplicativo CPAR foi realmente desligado, execute o comando:

/opt/CSCOar/bin/arstatus

Essas mensagens devem aparecer:

Cisco Prime Access Registrar Server Agent not running
Cisco Prime Access Registrar GUI not running

Tarefa de Instantâneo da VM

Etapa 1. Digite o site da GUI do Horizon que corresponde ao Site (Cidade) em que está sendo trabalhado.

Quando você acessa o Horizon, a tela observada é a mostrada nesta imagem.

Etapa 2. Navegue até Project > Instances como mostrado nesta imagem.

Se o usuário usado foi CPAR, somente as 4 instâncias AAA aparecem neste menu.

Etapa 3. Desligue apenas uma instância de cada vez e repita todo o processo neste documento. Para desligar a VM, navegue para Ações > Desligar instância como mostrado na imagem e confirme sua seleção.

Etapa 4. Confirme se a instância foi realmente desligada verificando o Status = Desligamento e Estado de energia = Desligar como mostrado nesta imagem.

Esta etapa encerra o processo de encerramento do CPAR.

Instantâneo de VM

Quando as VMs CPAR estiverem desativadas, os snapshots podem ser obtidos em paralelo, pois pertencem a computadores independentes.

Os quatro arquivos QCOW2 são criados em paralelo.

Faça um instantâneo de cada instância AAA. (25 minutos - 1 hora) (25 minutos para instâncias que usaram uma imagem qcou como origem e 1 hora para instâncias que usaram uma imagem bruta como origem)

1. Faça login na GUI do Horizon do Openstack do POD.
2. Depois de fazer login, navegue até a seção Project > Compute > Instances no menu superior e procure as instâncias de AAA como mostrado nesta imagem.

3. Clique em Create Snapshot para continuar com a criação do snapshot (isso precisa ser executado na instância AAA correspondente), como mostrado nesta imagem.

4. Depois que o snapshot for executado, clique em Images e verifique se todos terminam e relatam nenhum problema como mostrado nesta imagem.

5. A próxima etapa é baixar o snapshot em um formato QCOW2 e transferi-lo para uma entidade remota, caso o OSPD seja perdido durante esse processo. Para conseguir isso, identifique o snapshot executando o comando glance image-list no nível 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. Depois de identificar o snapshot a ser baixado (o marcado em verde), você pode baixá-lo em um formato QCOW2 com o comando glance image-download como mostrado.

[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &

• O& envia o processo para o plano de fundo. Leva algum tempo para concluir esta ação, uma vez concluída, a imagem pode ser localizada no diretório /tmp.
• Ao enviar o processo ao segundo plano, se a conectividade for perdida, o processo também será interrompido. 
• Execute o comando disown -h para que, caso a conexão SSH seja perdida, o processo ainda seja executado e concluído no OSPD.

7. Quando o processo de download for concluído, um processo de compactação precisará ser executado, pois esse snapshot poderá ser preenchido com ZEROES devido a processos, tarefas e arquivos temporários tratados pelo SO. O comando a ser usado para compactação de arquivos é virt-sparsify.

[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2

Esse processo pode levar algum tempo (cerca de 10 a 15 minutos). Uma vez concluído, o arquivo resultante é aquele que precisa ser transferido para uma entidade externa conforme especificado na próxima etapa.

A verificação da integridade do arquivo é necessária, para que isso ocorra, execute o próximo comando e procure o atributo "corrupt" (corrompido) no final de sua saída.

[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 

• Para evitar um problema em que o OSPD é perdido, o snapshot recém-criado no formato QCOW2 precisa ser transferido para uma entidade externa. Antes de iniciar a transferência de arquivos, você deve verificar se o destino tem espaço em disco disponível suficiente. Execute o comando df -kh para verificar o espaço de memória. Um conselho é transferi-lo temporariamente para o OSPD de outro site com o SFTP sftp root@x.x.x.x" onde x.x.x.x é o IP de um OSPD remoto. Para acelerar a transferência, o destino pode ser enviado a vários OSPDs. Da mesma forma, você pode executar o comando scp *name_of_the_file*.qcou2 root@ x.x.x.x:/tmp (onde x.x.x.x é o IP de um OSPD remoto) para transferir o arquivo para outro OSPD. 

1. Identifique as VMs hospedadas no nó OSD-Compute. 
2. Identifique as VMs hospedadas no servidor.

  

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

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. Os parâmetros dessa saída são usados em seções subsequentes.

• Verifique se o CEPH tem capacidade disponível para permitir que um único servidor OSD seja removido. 

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df

GLOBAL:

    SIZE       AVAIL      RAW USED     %RAW USED
    13393G     11088G        2305G         17.21

POOLS:
    NAME        ID     USED      %USED     MAX AVAIL     OBJECTS
    rbd         0          0         0         3635G           0
    metrics     1      3452M      0.09         3635G      219421
    images      2       138G      3.67         3635G       43127
    backups     3          0         0         3635G           0
    volumes     4       139G      3.70         3635G       36581
    vms         5       490G     11.89         3635G      126247

• Verifique se o status do ceph osd tree está ativo no servidor osd-compute. 

[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

• Os processos CEPH estão ativos no servidor osd-compute.

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

UNIT                             LOAD   ACTIVE SUB     DESCRIPTION
var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0
var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3
var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6
var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9
ceph-osd@0.service               loaded active running Ceph object storage daemon
ceph-osd@3.service               loaded active running Ceph object storage daemon
ceph-osd@6.service               loaded active running Ceph object storage daemon
ceph-osd@9.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'. 

•  Desabilite e pare cada instância do ceph e remova cada instância do osd e desmonte o diretório. Repita para cada instância do ceph.

[heat-admin@pod2-stack-osd-compute-0  ~]# systemctl disable ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0

• marcado como osd.0.
  
  

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0

• removeu o nome 'osd.0' da id do item do mapa de esmagamento
  
  

[heat-admin@pod2-stack-osd-compute-0  ~]# ceph auth del osd.0

• atualizado em
  
  

[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0

• osd.0 removido

[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0

[heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0

 Ou,

• O script Clean.sh pode ser usado para esta tarefa de uma só vez.

[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd
ceph-0  ceph-3  ceph-6  ceph-9

[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh

[heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh

#!/bin/sh
set -x
CEPH=`sudo ls /var/lib/ceph/osd`
for c in $CEPH
do
   i=`echo $c |cut -d'-' -f2`
   sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd out $i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)
   sleep 2
   sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)
   sleep 2
done

sudo ceph osd tree 

Depois que todos os processos OSD forem migrados/excluídos, o nó poderá ser removido da nuvem geral.

Note: Quando o CEPH é removido, o VNF HD RAID entra no estado Degraded, mas o disco rígido ainda precisa estar acessível.

Desligamento normal

• Desligar nó

1. Para desligar a instância: nova stop <INSTANCE_NAME>
2. Você pode ver o nome da instância com o status 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                 |

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

• Exclusão de nó

As etapas mencionadas nesta seção são comuns independentemente das VMs hospedadas no nó de computação.

Exclua o nó de computação OSD da lista de serviços.

• Exclua o serviço de computação da lista de serviços:

  [stack@director ~]$ openstack compute service list |grep osd-compute
  
  | 135 | nova-compute     | pod2-stack-osd-compute-1.localdomain | AZ-esc2  | enabled | up    | 2018-06-22T11:05:22.000000 |
  
  | 150 | nova-compute     | pod2-stack-osd-compute-2.localdomain | nova     | enabled | up    | 2018-06-22T11:05:17.000000 |
  
  | 153 | nova-compute     | pod2-stack-osd-compute-0.localdomain | AZ-esc1  | enabled | up    | 2018-06-22T11:05:25.000000 |

• openstack computação service delete <ID>

[stack@director ~]$ openstack compute service delete 150 

Excluir Agentes Neutron

• Exclua o antigo agente de nêutrons associado e o agente de vswitch aberto para o servidor computacional:

  [stack@director ~]$ openstack network agent list | grep osd-compute-0
  
  | eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None              | True  | UP    | neutron-openvswitch-agent |

• openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22

Excluir do banco de dados irônico

• Exclua um nó do banco de dados irônico e verifique-o:

[root@director ~]#  nova list | grep osd-compute-0
| 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.109 |

[root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f

• nova show < compute-node> | hipervisor grep

[root@director ~]# source stackrc

[root@director ~]#  nova show pod2-stack-osd-compute-0 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 05ceb513-e159-417d-a6d6-cbbcc4b167d7      

• ironic node-delete <ID>

[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7
[stack@director ~]$ ironic node-list 

O nó excluído não deve estar listado agora na ironic node-list.

Excluir do Overcloud

• Crie um arquivo de script chamado delete_node.sh com o conteúdo como mostrado. Certifique-se de que os modelos mencionados sejam os mesmos usados no script Deployment.sh usado para a implantação da pilha:

• delete_node.sh:

openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack <stack-name> <UUID>

[stack@director ~]$ source stackrc
[stack@director ~]$ /bin/sh delete_node.sh
+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444
Deleting the following nodes from stack pod2-stack:
- 7439ea6c-3a88-47c2-9ff5-0a4f24647444
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

real   0m52.078s
user   0m0.383s
sys    0m0.086s

• Aguarde até que a operação da pilha do OpenStack passe para o estado COMPLETO:

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

Instalar novo nó de computação

• As etapas para instalar um novo servidor UCS C240 M4 e as etapas de configuração inicial podem ser consultadas a partir de:

Guia de instalação e serviços do servidor Cisco UCS C240 M4

• Após a instalação do servidor, insira os discos rígidos nos respectivos slots como o servidor antigo.
• Faça login no servidor usando o CIMC IP.
• Execute a atualização do BIOS se o firmware não estiver de acordo com a versão recomendada usada anteriormente. As etapas para a atualização do BIOS são fornecidas aqui:

Guia de atualização do BIOS de servidor com montagem em rack Cisco UCS C-Series

• Verifique o status das unidades físicas. Ele deve ser Não configurado como Bom:

Navegue até Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info (Armazenamento > Controlador RAID modular SAS Cisco 12G) conforme mostrado nesta imagem.

• Crie uma unidade virtual a partir das unidades físicas com RAID Nível 1:

Navegue até Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Controller Info > Create Virtual Drive from Unused Physical Drives conforme mostrado nesta imagem.

• Selecione o VD e configure Set as Boot Drive (Definir como unidade de inicialização) conforme mostrado na imagem.

• Ativar IPMI na LAN:

Navegue até Admin > Communication Services > Communication Services conforme mostrado na imagem.

  

• Desativar hiperthreading:

Navegue até Compute > BIOS > Configure BIOS > Advanced > Processor Configuration conforme mostrado na imagem.

• Semelhante ao BOOTOS VD criado com unidades físicas 1 e 2, crie mais quatro unidades virtuais como:
  
  

  JOURNAL > From physical drive number 3
  
  OSD1 > From physical drive number 7
  
  OSD2 > From physical drive number 8
  
  OSD3 > From physical drive number 9
  
  OSD4 > From physical drive number 10
  

  
  
• No final, as unidades físicas e virtuais devem ser semelhantes como mostrado nas imagens.

Note: A imagem mostrada aqui e as etapas de configuração mencionadas nesta seção referem-se à versão de firmware 3.0(3e) e pode haver pequenas variações se você trabalhar em outras versões.

Adicionar novo nó de computação OSD à nuvem extra

As etapas mencionadas nesta seção são comuns independentemente da VM hospedada pelo nó de computação.

• Adicionar servidor de computação com um índice diferente.

Crie um arquivo add_node.json com apenas os detalhes do novo servidor de computação a ser adicionado. Certifique-se de que o número de índice do novo servidor de computação não tenha sido usado antes. Normalmente, incremente o próximo valor de computação mais alto.

Exemplo: O mais alto anterior foi o osd-compute-17, portanto, criou o osd-compute-18 no caso do sistema de 2 vnf. 

Note: Lembre-se do formato json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "<MAC_ADDRESS>"
            ],
            "capabilities": "node:osd-compute-3,boot_option:local",
            "cpu":"24",
            "memory":"256000",
            "disk":"3000",
            "arch":"x86_64",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"<PASSWORD>",
            "pm_addr":"192.100.0.5"
        }
    ]
}

• Importar o arquivo json. 

[stack@director ~]$ openstack baremetal import --json add_node.json
Started Mistral Workflow. Execution ID: 78f3b22c-5c11-4d08-a00f-8553b09f497d
Successfully registered node UUID 7eddfa87-6ae6-4308-b1d2-78c98689a56e
Started Mistral Workflow. Execution ID: 33a68c16-c6fd-4f2a-9df9-926545f2127e
Successfully set all nodes to available.

• Execute a introspecção de nó com o uso do UUID observado na etapa anterior.

[stack@director ~]$ openstack baremetal node manage 7eddfa87-6ae6-4308-b1d2-78c98689a56e
[stack@director ~]$ ironic node-list |grep 7eddfa87
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | manageable         | False       |

[stack@director ~]$ openstack overcloud node introspect 7eddfa87-6ae6-4308-b1d2-78c98689a56e --provide
Started Mistral Workflow. Execution ID: e320298a-6562-42e3-8ba6-5ce6d8524e5c
Waiting for introspection to finish...
Successfully introspected all nodes.
Introspection completed.
Started Mistral Workflow. Execution ID: c4a90d7b-ebf2-4fcb-96bf-e3168aa69dc9
Successfully set all nodes to available.

[stack@director ~]$ ironic node-list |grep available
| 7eddfa87-6ae6-4308-b1d2-78c98689a56e | None | None                                 | power off   | available          | False       |

• Adicione endereços IP a custom-templates/layout.yml em Osd Compute IPs. Nesse caso, ao substituir o osd-compute-0, você adiciona esse endereço ao final da lista para cada tipo

OsdComputeIPs:

internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take osd-compute-0 .43 and add here

    tenant:

    - 11.117.0.43

    - 11.117.0.44

    - 11.117.0.45

    - 11.117.0.43   << and here

    storage:

    - 11.118.0.43

    - 11.118.0.44

    - 11.118.0.45

    - 11.118.0.43   << and here

    storage_mgmt:

    - 11.119.0.43

    - 11.119.0.44

    - 11.119.0.45

    - 11.119.0.43   << and here

• Execute o script Deployment.sh que foi usado anteriormente para implantar a pilha, para adicionar o novo nó de computação à pilha da nuvem: 

  [stack@director ~]$ ./deploy.sh
  ++ openstack overcloud deploy --templates -r /home/stack/custom-templates/custom-roles.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml --stack ADN-ultram --debug --log-file overcloudDeploy_11_06_17__16_39_26.log --ntp-server 172.24.167.109 --neutron-flat-networks phys_pcie1_0,phys_pcie1_1,phys_pcie4_0,phys_pcie4_1 --neutron-network-vlan-ranges datacentre:1001:1050 --neutron-disable-tunneling --verbose --timeout 180
  …
  Starting new HTTP connection (1): 192.200.0.1
  "POST /v2/action_executions HTTP/1.1" 201 1695
  HTTP POST http://192.200.0.1:8989/v2/action_executions 201
  Overcloud Endpoint: http://10.1.2.5:5000/v2.0
  Overcloud Deployed
  clean_up DeployOvercloud: 
  END return value: 0
  
  real   38m38.971s
  user   0m3.605s
  sys    0m0.466s

• Aguarde até que o status da pilha de openstack seja concluído:

[stack@director ~]$  openstack stack list
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |
+--------------------------------------+------------+-----------------+----------------------+----------------------+
| 5df68458-095d-43bd-a8c4-033e68ba79a0 | ADN-ultram | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |
+--------------------------------------+------------+-----------------+----------------------+----------------------+

• Verifique se o novo nó de computação está no estado Ativo:

[stack@director ~]$ source stackrc
[stack@director ~]$ nova list |grep osd-compute-3
| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc
[stack@director ~]$ openstack hypervisor list |grep osd-compute-3
| 63 | pod1-osd-compute-3.localdomain    |

• Faça login no novo servidor osd-compute e verifique os processos ceph. Inicialmente, o status está em HEALTH_WARN quando o ceph se recupera.

• [heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s
  
      cluster eb2bb192-b1c9-11e6-9205-525400330666
       health HEALTH_WARN
              223 pgs backfill_wait
              4 pgs backfilling
              41 pgs degraded
              227 pgs stuck unclean
              41 pgs undersized
              recovery 45229/1300136 objects degraded (3.479%)
              recovery 525016/1300136 objects misplaced (40.382%)
       monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}
              election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2
       osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs
              flags sortbitwise,require_jewel_osds
        pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects
              1553 GB used, 11840 GB / 13393 GB avail
              45229/1300136 objects degraded (3.479%)
              525016/1300136 objects misplaced (40.382%)
                   477 active+clean
                   186 active+remapped+wait_backfill
                    37 active+undersized+degraded+remapped+wait_backfill
                     4 active+undersized+degraded+remapped+backfilling 

• Mas após um curto período (20 minutos), CEPH retorna a um estado HEALTH_OK.

[heat-admin@pod1-osd-compute-3 ~]$ sudo ceph -s

    cluster eb2bb192-b1c9-11e6-9205-525400330666
     health HEALTH_OK

     monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}
            election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2
     osdmap e1398: 12 osds: 12 up, 12 in
            flags sortbitwise,require_jewel_osds
      pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects
            1599 GB used, 11793 GB / 13393 GB avail
                 704 active+clean
  client io 8168 kB/s wr, 0 op/s rd, 32 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        0     host pod1-osd-compute-0
-3  4.35999     host pod1-osd-compute-2
 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 pod1-osd-compute-1
 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
 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

Restaurar VMs

Recuperar instância com instantâneo

É possível reimplantar a instância anterior com o snapshot realizado nas etapas anteriores.

Etapa 1. (Opcional) Se não houver nenhum snapshot de VM anterior disponível, conecte-se ao nó OSPD onde o backup foi enviado e faça o SFTP de volta ao nó OSPD original. Usar sftp root@x.x.x.xwhere x.x.x.x é o IP de um OSPD original. Salve o arquivo de snapshot no diretório /tmp.

Etapa 2. Conecte-se ao nó OSPD onde a instância é reimplantada.

Origem das variáveis de ambiente com este comando:

             

 # source /home/stack/pod1-stackrc-Core-CPAR

Etapa 3. Para usar o snapshot como uma imagem, é necessário carregá-lo no horizonte como tal. Execute o próximo comando para fazer isso.

#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot

O processo pode ser visto no horizonte como mostrado nesta imagem.

Etapa 4. No Horizon, navegue para Project > Instances e clique em Lauch Instance como mostrado nesta imagem.

Etapa 5. Digite o Nome da instância e escolha a Zona de disponibilidade conforme mostrado nesta imagem.

Etapa 6. Na guia Origem, escolha a imagem para criar a instância. No menu Selecionar fonte de inicialização, selecione imagem, uma lista de imagens é mostrada, escolha a que foi carregada anteriormente clicando em seu + sinal e como mostrado nesta imagem.

Passo 7. Na guia Flavor, escolha o sabor AAA clicando no + sinal como mostrado nesta imagem.

Etapa 8. Finalmente, navegue até a guia Rede e escolha as redes de que a instância precisa clicando no sinal +. Nesse caso, selecione diâmetro-soutable1, radius-routable1 e tb1-mgmt como mostrado nesta imagem.

Etapa 9. Finalmente, clique em Iniciar instância para criá-la. O progresso pode ser monitorado no Horizon é como mostrado nesta imagem.

Após alguns minutos, a instância será completamente implantada e pronta para uso.

Criar e atribuir um endereço IP flutuante

Um endereço IP flutuante é um endereço roteável, o que significa que ele pode ser alcançado de fora da arquitetura Ultra M/Openstack e pode se comunicar com outros nós da rede.

Etapa 1. No menu superior do Horizon, navegue até Admin > IPs flutuantes.

Etapa 2. Clique em Alocar IP para Projeto.

Etapa 3. Na janela Alocar IP Flutuante, selecione o Pool do qual o novo IP flutuante pertence, o Projeto ao qual ele será atribuído e o novo Endereço IP Flutuante em si.

Por exemplo:

                                                       

Etapa 4. Clique em Alocar IP Flutuante.

Etapa 5. No menu superior do Horizon, navegue até Project > Instances.

Etapa 6. Na coluna Ação, clique na seta que aponta para baixo no botão Criar instantâneo, um menu deve ser exibido. Selecione a opção Associar IP flutuante.

Passo 7. Selecione o endereço IP flutuante correspondente destinado a ser usado no campo Endereço IP e escolha a interface de gerenciamento correspondente (eth0) da nova instância onde esse IP flutuante será atribuído na Porta a ser associada. Consulte a próxima imagem como um exemplo deste procedimento.

Etapa 8. Finalmente, clique em Associar.

Habilitar SSH

Etapa 1. No menu superior do Horizon, navegue até Project > Instances.

Etapa 2. Clique no nome da instância/VM que foi criada na seção Iniciar uma nova instância.

Etapa 3. Clique em Console. Isso exibirá a CLI da VM.

Etapa 4. Depois que a CLI for exibida, insira as credenciais de login adequadas:

Nome de usuário: root

Senha: cisco123 como mostrado nesta imagem.

Etapa 5. Na CLI, execute o comando vi /etc/ssh/sshd_config para editar a configuração do ssh.

Etapa 6. Quando o arquivo de configuração SSH estiver aberto, pressione I para editar o arquivo. Em seguida, procure a seção mostrada aqui e altere a primeira linha de PasswordAuthentication no para PasswordAuthentication yes.

Passo 7. Pressione ESC e digite :wq! para salvar as alterações no arquivo sshd_config.

Etapa 8. Execute o comando service sshd restart.

Etapa 9. Para testar se as alterações na configuração do SSH foram aplicadas corretamente, abra qualquer cliente SSH e tente estabelecer uma conexão segura remota usando o IP flutuante atribuído à instância (por exemplo, 10.145.0.249) e a raiz do usuário.

Estabelecer sessão SSH

Etapa 1. Abra uma sessão SSH com o endereço IP da VM/servidor correspondente onde o aplicativo está instalado, como mostrado nesta imagem.

Início da instância do CPAR

Siga estas etapas, depois que a atividade tiver sido concluída e os serviços CPAR puderem ser restabelecidos no Site que foi encerrado.

Etapa 1. Faça login novamente no Horizon, navegue para Project > Instance > Start Instance.

Etapa 2. Verifique se o status da instância está Ativo e se o estado de energia está Em execução como mostrado nesta imagem.

Verificação de integridade pós-atividade

Etapa 1. Execute o comando /opt/CSCOar/bin/arstatus no nível do SO:

[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 ~]#

Etapa 2. Execute o comando /opt/CSCOar/bin/aregcmd no nível do SO e insira as credenciais de administrador. Verifique se CPAr Health é 10 em 10 e se a CLI CPAR de saída é CLI.

[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

  

Etapa 3. Execute o comando netstat | diâmetro de grep e verifique se todas as conexões DRA estão estabelecidas.

  

A saída mencionada aqui é para um ambiente em que os links de diâmetro são esperados. Se menos links forem exibidos, isso representa uma desconexão do DRA que precisa ser analisada.

[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

  

Etapa 4. Verifique se o registro TPS mostra solicitações sendo processadas pelo CPAR. Os valores destacados representam o TPS e esses são os que você precisa prestar atenção.

O valor do TPS não deve exceder 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

Etapa 5. Procure qualquer mensagem de "erro" ou "alarme" em name_radius_1_log.

  

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

Etapa 6. Para verificar a quantidade de memória usada pelo processo CPAR, execute o 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

Esse valor destacado deve ser inferior a 7 Gb, que é o máximo permitido no nível do aplicativo.