Reemplazo de los componentes defectuosos en el servidor UCS C240 M4 - vEPC

Introducción

Este documento describe los pasos requeridos para substituir a los componentes defectuosos mencionados aquí en un servidor del sistema de la Computación unificada (UCS) en un Ultra-M puesto que funciona la red virtual de StarOS de los host (VNFs). 

• FREGONA del reemplazo del módulo dual in-line memory (DIMM)
• Falla del controlador de FlexFlash
• Error de estado sólido de la unidad (SSD) 
• Error de confianza del módulo de la plataforma (TPM)
• Error del caché de la incursión
• Error caliente del adaptador del bus del regulador de la incursión (HBA)
• Error de la canalización vertical PCI
• Error de Intel X520 10G del adaptador de PCIe
• Modular LAN-en el error de la placa madre (MLOM)
• BANDEJA DE VENTILACIÓN RMA
• Error CPU

Antecedentes

Ultra-M es una solución móvil virtualizada preembalada y validada de la base del paquete que se diseña para simplificar el despliegue de VNFs. OpenStack es el encargado virtualizado de la infraestructura (VIM) para Ultra-M y consiste en estos tipos de nodo:

• Cálculo
• Disco del almacenamiento del objeto - Cálculo (OSD - Cálculo)
• Regulador
• Plataforma de OpenStack - Director (OSPD)

La arquitectura de alto nivel de Ultra-M y los componentes implicados se representan en esta imagen:

Este documento se piensa para el personal de Cisco que es familiar con la plataforma de Cisco Ultra-M y detalla los pasos requeridos ser realizado en el nivel de OpenStack y de StarOS VNF a la hora del reemplazo componente en el servidor. 

Nota: Ultra la versión M 5.1.x se considera para definir los procedimientos en este documento.

Abreviaturas

VNF	Función de la red virtual
CF	Función de control
SF	Función de servicio
Salida	Regulador elástico del servicio
FREGONA	Método de procedimiento
OSD	Discos del almacenamiento del objeto
HDD	Unidad de disco duro
SSD	Unidad de estado sólido
VIM	Encargado virtual de la infraestructura
VM	Máquina virtual
EM	Encargado del elemento
UAS	Servicios de ultra automatización
UUID	Universal Identificador único

Flujo de trabajo de la fregona 

Prerrequisitos

Salvaguardia

Antes de que usted substituya a un componente defectuoso, es importante controlar al estado actual de su entorno de la plataforma de OpenStack del Red Hat. Se recomienda le control el estado actual para evitar las complicaciones cuando el proceso de reemplazo está prendido. Puede ser alcanzado por este flujo de reemplazo.

En caso de la recuperación, Cisco recomienda tomar una salvaguardia de la base de datos OSPD con el uso de estos pasos:

[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

Este proceso se asegura de que un nodo pueda ser substituido sin afectar a la Disponibilidad de cualquier caso. También, es salvaguardia recomendada la configuración de StarOS especialmente si el nodo compute/OSD-compute que se substituirá recibe la máquina virtual de la función de control (CF) (VM).

Nota: Si el servidor es el nodo del regulador, proceda al "" de la sección, si no continúe con la siguiente sección.

Componente RMA - Nodo Compute/OSD-Compute 

Identifique las VM recibidas en el nodo Compute/OSD-Compute

Identifique las VM que se reciben en el servidor. Puede haber dos posibilidades:

• El servidor contiene solamente la función de servicio (SF) VM:

[stack@director ~]$ nova list --field name,host | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  
pod1-compute-10.localdomain    |

  

• Servidor contiene función de control (CF) /Elastic servicios regulador (salida)/elemento encargado ()/ultra EM combinación de los servicios de la automatización (UAS) de VM:
  
  

[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     |
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     | pod1-compute-8.localdomain     |
| 75528898-ef4b-4d68-b05d-882014708694 | VNF2-ESC-ESC-0                                             | pod1-compute-8.localdomain     |
| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                             | pod1-compute-8.localdomain     |

Nota: En la salida mostrada aquí, la primera columna corresponde universal al Identificador único (UUID), la segunda columna es el nombre VM y la tercera columna es el hostname donde está presente la VM. Los parámetros de esta salida serán utilizados en las secciones posteriores.

Potencia agraciada apagado

Encajone los host solamente SF VM de 1. nodos del cálculo

Emigre el indicador luminoso LED amarillo de la placa muestra gravedad menor SF al estado espera

• Ábrase una sesión al StarOS VNF e identifique el indicador luminoso LED amarillo de la placa muestra gravedad menor que corresponde al SF VM. Utilice el UUID del SF VM identificado de la sección “identifican las VM recibidas en el nodo Compute/OSD-Compute”, e identifican el indicador luminoso LED amarillo de la placa muestra gravedad menor que corresponde al UUID:

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 8:
  Card Type               : 4-Port Service Function Virtual Card
  CPU Packages            : 26 [#0, #1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25]
  CPU Nodes               : 2
  CPU Cores/Threads       : 26
  Memory                  : 98304M (qvpc-di-large)
  UUID/Serial Number      :  49AC5F22-469E-4B84-BADC-031083DB0533

• Controle el estatus del indicador luminoso LED amarillo de la placa muestra gravedad menor:

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Active         No         
 2: CFC      Control Function Virtual Card           Standby        -          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -  

• Si el indicador luminoso LED amarillo de la placa muestra gravedad menor está en el estado activo, mueva el indicador luminoso LED amarillo de la placa muestra gravedad menor al estado espera:

  [local]VNF2# card migrate from 8 to 10

Parada normal SF VM de salida

• Ábrase una sesión al nodo salida que corresponde al VNF y controle el estatus del SF VM:
  
  

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                    VM_ALIVE_STATE
                     VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                    VM_ALIVE_STATE</state>
<snip>

• Pare el SF VM con el uso de su nombre VM. (El nombre VM conocido de la sección “identifica las VM recibidas en el nodo Compute/OSD-Compute”):
  
  

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d

•  Una vez que se para, la VM debe ingresar el estado del CIERRE:

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                    VM_ALIVE_STATE
                    VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    VM_ALIVE_STATE
                    VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
                    VM_SHUTOFF_STATE</state>

Host CF/ESC/EM/UAS del nodo del caso 2. Compute/OSD-Compute

Emigre el indicador luminoso LED amarillo de la placa muestra gravedad menor de los CF al estado espera

• Ábrase una sesión al StarOS VNF e identifique el indicador luminoso LED amarillo de la placa muestra gravedad menor que corresponde a los CF VM. Utilice el UUID de los CF VM identificados de la sección “identifican las VM recibidas en el nodo”, y encuentran el indicador luminoso LED amarillo de la placa muestra gravedad menor que corresponde al UUID:
  
  

[local]VNF2# show card hardware
Tuesday might 08 16:49:42 UTC 2018
<snip>
Card 2:
  Card Type               : Control Function Virtual Card
  CPU Packages            : 8 [#0, #1, #2, #3, #4, #5, #6, #7]
  CPU Nodes               : 1
  CPU Cores/Threads       : 8
  Memory                  : 16384M (qvpc-di-large)
  UUID/Serial Number      : F9C0763A-4A4F-4BBD-AF51-BC7545774BE2
<snip>

• Controle el estatus del indicador luminoso LED amarillo de la placa muestra gravedad menor:
  
  

[local]VNF2# show card table
Tuesday might 08 16:52:53 UTC 2018
Slot         Card Type                               Oper State     SPOF  Attach
-----------  --------------------------------------  -------------  ----  ------
 1: CFC      Control Function Virtual Card           Standby        -
 2: CFC      Control Function Virtual Card           Active         No          
 3: FC       4-Port Service Function Virtual Card    Active         No         
 4: FC       4-Port Service Function Virtual Card    Active         No         
 5: FC       4-Port Service Function Virtual Card    Active         No         
 6: FC       4-Port Service Function Virtual Card    Active         No         
 7: FC       4-Port Service Function Virtual Card    Active         No         
 8: FC       4-Port Service Function Virtual Card    Active         No         
 9: FC       4-Port Service Function Virtual Card    Active         No         
10: FC       4-Port Service Function Virtual Card    Standby        -

• Si el indicador luminoso LED amarillo de la placa muestra gravedad menor está en el estado activo, mueva el indicador luminoso LED amarillo de la placa muestra gravedad menor al estado espera:
  
  

[local]VNF2# card migrate from 2 to 1

CF y EM VM de la parada normal de salida

• Ábrase una sesión al nodo salida que corresponde al VNF y controle el estatus de las VM:
  
  

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229
                    VM_ALIVE_STATE</state>
                    VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    VM_ALIVE_STATE
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  507d67c2-1d00-4321-b9d1-da879af524f8
                  dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                  9ffec58b-4b9d-4072-b944-5413bf7fcf07
                SERVICE_ACTIVE_STATE
                    VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea
                    VM_ALIVE_STATE</state>
<snip>

• Pare los CF y el EM VM uno a uno con el uso de su nombre VM. (El nombre VM conocido de la sección “identifica las VM recibidas en el nodo Compute/OSD-Compute”):
  
  

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229

[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli vm-action STOP VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea

  

• Después de que pare, las VM deben ingresar el estado del CIERRE:
  
  

[admin@VNF2-esc-esc-0 ~]$ cd /opt/cisco/esc/esc-confd/esc-cli
[admin@VNF2-esc-esc-0 esc-cli]$ ./esc_nc_cli get esc_datamodel | egrep --color "<state>|<vm_name>|<vm_id>|<deployment_name>"
<snip>
<state>SERVICE_ACTIVE_STATE</state>
                    VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>
                    VM_SHUTOFF_STATE</state>
                    VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-
                    VM_ALIVE_STATE
<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>
                  507d67c2-1d00-4321-b9d1-da879af524f8
                  dc168a6a-4aeb-4e81-abd9-91d7568b5f7c
                  9ffec58b-4b9d-4072-b944-5413bf7fcf07
                SERVICE_ACTIVE_STATE
                    VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>
                    <state>VM_SHUTOFF_STATE</state>
<snip>

Emigre salida al modo de reserva

• Ábrase una sesión a salida recibida en el nodo y controle si está en el estado principal. Si sí, cambie salida al modo de reserva:
  
  

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


[admin@VNF2-esc-esc-0 ~]$ sudo service keepalived stop
Stopping keepalived:                                       [  OK  ]

[admin@VNF2-esc-esc-0 ~]$ escadm status
1 ESC status=0 In SWITCHING_TO_STOP state. Please check status after a while.

[admin@VNF2-esc-esc-0 ~]$ sudo reboot
Broadcast message from admin@vnf1-esc-esc-0.novalocal
       (/dev/pts/0) at 13:32 ...
The system is going down for reboot NOW!

Nota: Si se va el componente defectuoso a ser substituido en el nodo del OSD-cálculo, ponga el Ceph en el mantenimiento en el servidor antes de que usted proceda con el reemplazo componente. 

[admin@osd-compute-0 ~]$ sudo ceph osd set norebalance
set norebalance

[admin@osd-compute-0 ~]$ sudo ceph osd set noout
set noout

[admin@osd-compute-0 ~]$ sudo ceph status
    cluster eb2bb192-b1c9-11e6-9205-525400330666
     health HEALTH_WARN
            noout,norebalance,sortbitwise,require_jewel_osds flag(s) set
     monmap e1: 3 mons at {tb3-ultram-pod1-controller-0=11.118.0.40:6789/0,tb3-ultram-pod1-controller-1=11.118.0.41:6789/0,tb3-ultram-pod1-controller-2=11.118.0.42:6789/0}
            election epoch 58, quorum 0,1,2 tb3-ultram-pod1-controller-0,tb3-ultram-pod1-controller-1,tb3-ultram-pod1-controller-2
     osdmap e194: 12 osds: 12 up, 12 in
            flags noout,norebalance,sortbitwise,require_jewel_osds
      pgmap v584865: 704 pgs, 6 pools, 531 GB data, 344 kobjects
            1585 GB used, 11808 GB / 13393 GB avail
                 704 active+clean
  client io 463 kB/s rd, 14903 kB/s wr, 263 op/s rd, 542 op/s wr

Substituya al componente defectuoso del nodo Compute/OSD-Compute

Potencia apagado el servidor especificado. Los pasos para substituir a un componente defectuoso en el servidor UCS C240 M4 se pueden referir de: 

Reemplazo de los componentes del servidor

Restablezca las VM

 Encajone los host solamente SF VM de 1. nodos del cálculo

 Recuperación SF VM de salida

• El SF VM estaría en el estado de error en la lista de la Nova:
  
  

[stack@director  ~]$ nova list |grep VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
| 49ac5f22-469e-4b84-badc-031083db0533 | VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     | ERROR  | -          | NOSTATE     | 

  

• Recupere el SF VM de salida:
  
  

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

• Vigile yangesc.log:
  
  

admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d].

• Asegúrese de que el indicador luminoso LED amarillo de la placa muestra gravedad menor SF suba como SF espera en el VNF

Encajone 2. host CF del nodo Compute/OSD-Compute, salida, EM y UAS

  Recuperación de UAS VM

• Controle el estatus del UAS VM en la lista de la Nova y suprímalo:

[stack@director ~]$ nova list | grep VNF2-UAS-uas-0
| 307a704c-a17c-4cdc-8e7a-3d6e7e4332fa | VNF2-UAS-uas-0                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.10; VNF2-UAS-uas-management=172.168.10.3
[stack@tb5-ospd ~]$ nova delete VNF2-UAS-uas-0
Request to delete server VNF2-UAS-uas-0 has been accepted.

• Para recuperar los autovnf-uas VM, ejecute el script del uas-control para controlar el estado. Debe señalar un error. Entonces ejecútese otra vez con --fije la opción para reconstruir el UAS que falta VM:
  
  

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts/
[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS
2017-12-08 12:38:05,446 - INFO: Check of AutoVNF cluster started
2017-12-08 12:38:07,925 - INFO: Instance 'vnf1-UAS-uas-0' status is 'ERROR'
2017-12-08 12:38:07,925 - INFO: Check completed, AutoVNF cluster has recoverable errors

[stack@director scripts]$ ./uas-check.py auto-vnf VNF2-UAS --fix
2017-11-22 14:01:07,215 - INFO: Check of AutoVNF cluster started
2017-11-22 14:01:09,575 - INFO: Instance VNF2-UAS-uas-0' status is 'ERROR'
2017-11-22 14:01:09,575 - INFO: Check completed, AutoVNF cluster has recoverable errors
2017-11-22 14:01:09,778 - INFO: Removing instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Removed instance VNF2-UAS-uas-0'
2017-11-22 14:01:13,568 - INFO: Creating instance VNF2-UAS-uas-0' and attaching volume ‘VNF2-UAS-uas-vol-0'
2017-11-22 14:01:49,525 - INFO: Created instance ‘VNF2-UAS-uas-0'

• Ábrase una sesión a los autovnf-uas. Espere algunos minutos y UAS debe volver al buen estado:

VNF2-autovnf-uas-0#show uas
uas version 1.0.1-1
uas state ha-active
uas ha-vip 172.17.181.101
INSTANCE IP   STATE  ROLE
-----------------------------------
172.17.180.6  alive  CONFD-SLAVE
172.17.180.7  alive  CONFD-MASTER
172.17.180.9  alive  NA

Nota: Si uas-check.py --el arreglo falla, usted puede ser que necesite copiar este fichero y ejecutarse otra vez.

[stack@director ~]$ mkdir –p /opt/cisco/usp/apps/auto-it/common/uas-deploy/
[stack@director ~]$ cp /opt/cisco/usp/uas-installer/common/uas-deploy/userdata-uas.txt /opt/cisco/usp/apps/auto-it/common/uas-deploy/

  

Recuperación de salida VM

• Controle el estatus de salida VM de la lista de la Nova y suprímalo:

stack@director scripts]$ nova list |grep ESC-1
| c566efbf-1274-4588-a2d8-0682e17b0d41 | VNF2-ESC-ESC-1                                                 | ACTIVE | -          | Running     | VNF2-UAS-uas-orchestration=172.168.11.14; VNF2-UAS-uas-management=172.168.10.4                                                                                                 |
[stack@director scripts]$ nova delete VNF2-ESC-ESC-1
Request to delete server VNF2-ESC-ESC-1 has been accepted.

• De AutoVNF-UAS, encuentre la transacción del despliegue salida y en el registro para la transacción para encontrar la línea de comando boot_vm.py para crear el caso salida:
  
  

ubuntu@VNF2-uas-uas-0:~$ sudo -i
root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI    
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show transaction
TX ID                                 TX TYPE          DEPLOYMENT ID    TIMESTAMP                         STATUS
-----------------------------------------------------------------------------------------------------------------------------
35eefc4a-d4a9-11e7-bb72-fa163ef8df2b  vnf-deployment   VNF2-DEPLOYMENT  2017-11-29T02:01:27.750692-00:00  deployment-success
73d9c540-d4a8-11e7-bb72-fa163ef8df2b  vnfm-deployment  VNF2-ESC         2017-11-29T01:56:02.133663-00:00  deployment-success


VNF2-uas-uas-0#show logs 73d9c540-d4a8-11e7-bb72-fa163ef8df2b | display xml
<config xmlns="http://tail-f.com/ns/config/1.0">
  <logs xmlns="http://www.cisco.com/usp/nfv/usp-autovnf-oper">
    <tx-id>73d9c540-d4a8-11e7-bb72-fa163ef8df2b</tx-id>
    <log>2017-11-29 01:56:02,142 - VNFM Deployment RPC triggered for deployment: VNF2-ESC, deactivate: 0
2017-11-29 01:56:02,179 - Notify deployment
..
2017-11-29 01:57:30,385 - Creating VNFM 'VNF2-ESC-ESC-1' with [python //opt/cisco/vnf-staging/bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username ****** --os_password ****** --bs_os_auth_url http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username ****** --bs_os_password ****** --esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --encrypt_key ****** --user_pass ****** --user_confd_pass ****** --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3 172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh --file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py --file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

Salve la línea boot_vm.py secuencia de comandos shell a un fichero (esc.sh) y ponga al día todas las líneas del ***** username y del ***** de la contraseña con la información correcta (típicamente core/<PASSWORD>). Usted necesita quitar – la opción del encrypt_key también. Para los user_pass y los user_confd_pass, usted necesita utilizar el formato – username: contraseña (admin de ejemplo: <PASSWORD>).

• Encuentre el URL para bootvm.py de los ejecutar-config y del wget el bootvm.pyfile a los autovnf-uas VM.  En este caso, 10.1.2.3 es el IP Auto-TIC la VM:

root@VNF2-uas-uas-0:~# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on VNF2-uas-uas-0
VNF2-uas-uas-0#show running-config autovnf-vnfm:vnfm
…
configs bootvm
  value http:// 10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
!

root@VNF2-uas-uas-0:~# wget http://10.1.2.3:80/bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
--2017-12-01 20:25:52--  http://10.1.2.3 /bundles/5.1.7-2007/vnfm-bundle/bootvm-2_3_2_155.py
Connecting to 10.1.2.3:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 127771 (125K) [text/x-python]
Saving to: ‘bootvm-2_3_2_155.py’
100%[=====================================================================================>] 127,771  --.-K/s   in 0.001s
2017-12-01 20:25:52 (173 MB/s) - ‘bootvm-2_3_2_155.py’ saved [127771/127771]

• Cree un fichero de /tmp/esc_params.cfg:
  
  

root@VNF2-uas-uas-0:~# echo "openstack.endpoint=publicURL" > /tmp/esc_params.cfg

• Ejecute secuencia de comandos shell para desplegar salida del nodo UAS:
  
  

root@VNF2-uas-uas-0:~# /bin/sh esc.sh
+ python ./bootvm.py VNF2-ESC-ESC-1 --flavor VNF2-ESC-ESC-flavor --image 3fe6b197-961b-4651-af22-dfd910436689
 --net VNF2-UAS-uas-management --gateway_ip 172.168.10.1 --net VNF2-UAS-uas-orchestration --os_auth_url 
http://10.1.2.5:5000/v2.0 --os_tenant_name core --os_username core --os_password <PASSWORD> --bs_os_auth_url 
http://10.1.2.5:5000/v2.0 --bs_os_tenant_name core --bs_os_username core --bs_os_password <PASSWORD> 
--esc_ui_startup false --esc_params_file /tmp/esc_params.cfg --user_pass admin:<PASSWORD> --user_confd_pass 
admin:<PASSWORD> --kad_vif eth0 --kad_vip 172.168.10.7 --ipaddr 172.168.10.6 dhcp --ha_node_list 172.168.10.3
172.168.10.6 --file root:0755:/opt/cisco/esc/esc-scripts/esc_volume_em_staging.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_volume_em_staging.sh 
--file root:0755:/opt/cisco/esc/esc-scripts/esc_vpc_chassis_id.py:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc_vpc_chassis_id.py 
--file root:0755:/opt/cisco/esc/esc-scripts/esc-vpc-di-internal-keys.sh:/opt/cisco/usp/uas/autovnf/vnfms/esc-scripts/esc-vpc-di-internal-keys.sh

• Ábrase una sesión a nueva salida y verifique el estado de reserva:
  
  

ubuntu@VNF2-uas-uas-0:~$ ssh admin@172.168.11.14
…
   ####################################################################
   #   ESC on VNF2-esc-esc-1.novalocal is in BACKUP state.
   ####################################################################

[admin@VNF2-esc-esc-1 ~]$ escadm status
0 ESC status=0 ESC Backup Healthy

[admin@VNF2-esc-esc-1 ~]$ health.sh
============== ESC HA (BACKUP) ===================================================
ESC HEALTH PASSED

Recupere los CF y EM VM de salida

• Controle el estatus de los CF y del EM VM de la lista de la Nova. Deben estar en el estado de error:
  
  

[stack@director ~]$ source corerc
[stack@director ~]$ nova list --field name,host,status |grep -i err   
| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | None                                 | ERROR|
| f9c0763a-4a4f-4bbd-af51-bc7545774be2 | VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229     |None                                 | ERROR

     

• La clave al master salida, ejecuta la recuperación-VM-acción para cada EM y CF afectados VM. Sea paciente. Salida programaría la acción de recuperación y puede ser que no suceda durante unos minutos. Vigile yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO <VM-Name>

[admin@VNF2-esc-esc-0 ~]$ sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8
[sudo] password for admin: 

Recovery VM Action
/opt/cisco/esc/confd/bin/netconf-console --port=830 --host=127.0.0.1 --user=admin --privKeyFile=/root/.ssh/confd_id_dsa --privKeyType=dsa --rpc=/tmp/esc_nc_cli.ZpRCGiieuW
<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
  <ok/>
</rpc-reply>

[admin@VNF2-esc-esc-0 ~]$ tail -f /var/log/esc/yangesc.log
…
14:59:50,112 07-Nov-2017 WARN  Type: VM_RECOVERY_COMPLETE
14:59:50,112 07-Nov-2017 WARN  Status: SUCCESS
14:59:50,112 07-Nov-2017 WARN  Status Code: 200
14:59:50,112 07-Nov-2017 WARN  Status Msg: Recovery: Successfully recovered VM [VNF2-DEPLOYMENT-_VNF2-D_0_a6843886-77b4-4f38-b941-74eb527113a8]

• Ábrase una sesión al nuevo EM y verifique que estado EM está para arriba:
  
  

ubuntu@VNF2vnfddeploymentem-1:~$ /opt/cisco/ncs/current/bin/ncs_cli -u admin -C
admin connected from 172.17.180.6 using ssh on VNF2vnfddeploymentem-1
admin@scm# show ems
EM            VNFM
ID  SLA  SCM  PROXY
---------------------
2   up   up   up
3   up   up   up

• El registro en el StarOS VNF y verifica que el indicador luminoso LED amarillo de la placa muestra gravedad menor de los CF esté en el estado espera

   

Error de la recuperación salida de la manija

En caso de que salida no pueda comenzar la VM debido a un estado inesperado, Cisco recomienda cómo realizar un intercambio salida reiniciando salida del master. El intercambio salida tardaría alrededor de un minuto. Ejecute el script “health.sh” en nueva salida del master para controlar si el estatus está para arriba. Domine salida para comenzar la VM y para fijar el estado VM. Esta tarea de la recuperación tomaría hasta 5 minutos para completar.

Usted puede vigilar /var/log/esc/yangesc.log y /var/log/esc/escmanager.log. Si usted no ve que la VM consigue recuperada después de 5-7 minutos, el usuario necesitaría ir hacer la recuperación manual de la VM afectada.

Auto-despliegue la actualización de la configuración

• De AutoDeploy VM, corrija el autodeploy.cfg y substituya el servidor viejo del cálculo por el nuevo. Entonces la carga substituye en el confd_cli. Este paso se requiere para la desactivación del despliegue satisfactorio más adelante:

root@auto-deploy-iso-2007-uas-0:/home/ubuntu# confd_cli -u admin -C
Welcome to the ConfD CLI
admin connected from 127.0.0.1 using console on auto-deploy-iso-2007-uas-0
auto-deploy-iso-2007-uas-0#config
Entering configuration mode terminal
auto-deploy-iso-2007-uas-0(config)#load replace autodeploy.cfg
Loading.     14.63 KiB parsed in 0.42 sec (34.16 KiB/sec)

auto-deploy-iso-2007-uas-0(config)#commit
Commit complete.
auto-deploy-iso-2007-uas-0(config)#end

• Recomience el uas-confd y los servicios autodeploy después del cambio de configuración:

root@auto-deploy-iso-2007-uas-0:~# service uas-confd restart
uas-confd stop/waiting
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service uas-confd status
uas-confd start/running, process 14078

root@auto-deploy-iso-2007-uas-0:~# service autodeploy restart
autodeploy stop/waiting
autodeploy start/running, process 14017
root@auto-deploy-iso-2007-uas-0:~# service autodeploy status
autodeploy start/running, process 14017

Componente RMA - Nodo del regulador

Control previó

                                                   

• De OSPD, la clave al regulador y verifica que las PC estén en un buen estado – tres Online y Galera de los reguladores muestran los tres reguladores como master. 

Nota: Un racimo sano requiere 2 controladores activos así que verifique que los dos reguladores que permanecen sean en línea y activos.

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec  4 00:46:10 2017                        Last change: Wed Nov 29 01:20:52 2017 by hacluster via crmd on pod1-controller-0
3 nodes and 22 resources configured

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

Full list of resources:
 ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
 ip-11.120.0.49  (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 ]
 ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started 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-2 ]
     Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
 my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-0
 my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-0
 my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-0

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

Mueva el racimo del regulador al modo de mantenimiento

• Utilice las PC se agrupan en el regulador que se pone al día en el recurso seguro:

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

• Controle el estatus de las PC otra vez y asegúrese de que las PC se agrupan parado en este nodo:

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec  4 00:48:24 2017                        Last change: Mon Dec  4 00:48:18 2017 by root via crm_attribute on pod1-controller-0
3 nodes and 22 resources configured

Node pod1-controller-0: standby

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

Full list of resources:
 ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
 ip-11.120.0.49  (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-1 pod1-controller-2 ]
     Stopped: [ pod1-controller-0 ]
Master/Slave Set: galera-master [galera]
     Masters: [ pod1-controller-1 pod1-controller-2 ]
     Slaves: [ pod1-controller-0 ]
 ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started 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-2 ]
     Slaves: [ pod1-controller-1 ]
     Stopped: [ pod1-controller-0 ]
 ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
 my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1
 my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1
 my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

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

También, el estatus de las PC en los otros 2 reguladores debe mostrar el nodo como recurso seguro.

Substituya al componente defectuoso del nodo del regulador

Potencia apagado el servidor especificado. Los pasos para substituir a un componente defectuoso en el servidor UCS C240 M4 se pueden referir de: 

Reemplazo de los componentes del servidor

Potencia en el servidor

• La potencia en el servidor y verifica que suba el servidor:

[stack@tb5-ospd ~]$ source stackrc
[stack@tb5-ospd ~]$ nova list |grep pod1-controller-0
| 1ca946b8-52e5-4add-b94c-4d4b8a15a975 | pod1-controller-0  | ACTIVE | -          | Running     | ctlplane=192.200.0.112 |

• Ábrase una sesión al regulador afectado, quite al modo de reserva con el uso de unstandby. Verifique que el regulador venga en línea con el racimo y Galera muestra los tres reguladores como master. Esto pudo tardar algunos minutos:

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

[heat-admin@pod1-controller-0 ~]$ sudo pcs status
Cluster name: tripleo_cluster
Stack: corosync
Current DC: pod1-controller-2 (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Mon Dec  4 01:08:10 2017                        Last change: Mon Dec  4 01:04:21 2017 by root via crm_attribute on pod1-controller-0
3 nodes and 22 resources configured

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

Full list of resources:
 ip-11.118.0.42  (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 ip-11.119.0.47  (ocf::heartbeat:IPaddr2):           Started pod1-controller-2
 ip-11.120.0.49  (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 ]
 ip-11.120.0.47  (ocf::heartbeat:IPaddr2):           Started 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-2 ]
     Slaves: [ pod1-controller-0 pod1-controller-1 ]
 ip-10.84.123.35            (ocf::heartbeat:IPaddr2):           Started pod1-controller-1
 openstack-cinder-volume          (systemd:openstack-cinder-volume):            Started pod1-controller-2
 my-ipmilan-for-pod1-controller-0        (stonith:fence_ipmilan):  Started pod1-controller-1
 my-ipmilan-for-pod1-controller-1        (stonith:fence_ipmilan):  Started pod1-controller-1
 my-ipmilan-for-pod1-controller-2        (stonith:fence_ipmilan):  Started pod1-controller-2

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

• Usted puede controlar algunos de los servicios del monitor tales como ceph que están en un estado sano:

[heat-admin@pod1-controller-0 ~]$ sudo ceph -s
    cluster eb2bb192-b1c9-11e6-9205-525400330666
     health HEALTH_OK
     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 70, quorum 0,1,2 pod1-controller-0,pod1-controller-1,pod1-controller-2
     osdmap e218: 12 osds: 12 up, 12 in
            flags sortbitwise,require_jewel_osds
      pgmap v2080888: 704 pgs, 6 pools, 714 GB data, 237 kobjects
            2142 GB used, 11251 GB / 13393 GB avail
                 704 active+clean
  client io 11797 kB/s wr, 0 op/s rd, 57 op/s wr