Contenido

Introducción

Antecedentes

Abreviaturas

Flujo de trabajo del MoP

Sustitución de la placa base en la configuración Ultra-M

Sustitución de la placa base en el nodo informático

Identificación de las VM alojadas en el nodo de informática

Apagado Graceful

Caso 1. Compute Node Hosts solamente SF VM

Caso 2. Host de nodo de cálculo CF/ESC/EM/UAS

Sustitución de la placa madre

Restauración de las VM

Caso 1. Compute Node Hosts solamente SF VM

Caso 2. Host de nodo de cómputo UAS, ESC, EM y CF

Sustitución de la placa base en el nodo de cómputo OSD

Poner Ceph en modo de mantenimiento

Identificación de las VM alojadas en el nodo Osd-Compute

Apagado Graceful

Caso 1. OSD-Compute Node Hosts CF/ESC/EM/UAS

Caso 2. OSD-Compute Node Hosts Auto-Deploy/Auto-It/EM/UAS

Realizar una copia de seguridad de la CDB de la implementación automática

Copia de seguridad de System.cfg desde Auto-IT

Sustitución de la placa madre

Alejar el Ceph del modo de mantenimiento

Restauración de las VM

Caso 1. OSD-Compute Node Hosts CF, ESC, EM y UAS

Caso 2. OSD-Compute Node Hosts Auto-It, Auto-Deploy, EM y UAS

Recuperación de VM Auto-IT

Sustitución de la placa madre en el nodo del controlador

Verifique el estado del controlador y coloque el clúster en modo de mantenimiento

Sustitución de la placa madre

Restaurar estado del clúster

Introducción

Este documento describe los pasos necesarios para reemplazar la placa base defectuosa de un servidor en una configuración Ultra-M que aloja las funciones de red virtual (VNF) de StarOS.

Antecedentes

Ultra-M es una solución de núcleo de paquetes móviles virtualizada validada y empaquetada previamente diseñada para simplificar la implementación de VNF. OpenStack es el Virtualized Infrastructure Manager (VIM) para Ultra-M y consta de estos tipos de nodos:

- Informática

- Disco de almacenamiento de objetos - Compute (OSD - Compute)

- Controlador

- Plataforma OpenStack: Director (OSPD)

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

Arquitectura UltraM

Este documento está dirigido al personal de Cisco que está familiarizado con la plataforma Cisco Ultra-M y detalla los pasos que se deben realizar en el nivel de VNF OpenStack y StarOS en el momento de la sustitución de la placa base en un servidor.

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

Abreviaturas

VNF

Función de red virtual

CF

Función de control

SF

Función de servicio

ESC

Controlador de servicio elástico

MOP

Método de procedimiento

OSD

Discos de almacenamiento de objetos

HDD

Unidad de disco duro

SSD

Unidad de estado sólido

VIM

Administrador de infraestructura virtual

VM

Máquina virtual

EM

Administrador de elementos

UAS

Servicios de ultra automatización

UUID

Identificador Universalmente Único

Flujo de trabajo del MoP

Flujo de trabajo de alto nivel del procedimiento de reemplazo

Sustitución de la placa base en la configuración Ultra-M

En una configuración Ultra-M, puede haber situaciones en las que se requiera un reemplazo de placa madre en estos tipos de servidor: Compute, OSD-Compute y Controller.

Nota: Los discos de arranque con la instalación de OpenStack se sustituyen después de que se produzca la sustitución de la placa base. Por lo tanto, no es necesario volver a agregar el nodo a la nube excesiva. Una vez que el servidor se enciende después de la actividad de reemplazo, se inscribe de nuevo en la pila de nube superpuesta.

Sustitución de la placa base en el nodo informático

Antes de la actividad, las máquinas virtuales alojadas en el nodo Informática se apagan correctamente. Una vez que se ha reemplazado la placa base, se restauran las máquinas virtuales.

Identificación de las VM alojadas en el nodo de informática

Identifique las VM alojadas en el servidor informático. Puede haber dos posibilidades:

El servidor de cómputo sólo contiene la máquina virtual SF:

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

El servidor informático contiene la combinación CF/ESC/EM/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 el resultado que se muestra aquí, la primera columna corresponde al UUID, la segunda columna es el nombre de VM y la tercera columna es el nombre de host donde está presente la VM. Los parámetros de este resultado se utilizarán en las secciones siguientes.

Apagado Graceful

Caso 1. Compute Node Hosts solamente SF VM

Inicie sesión en StarOS VNF e identifique la tarjeta que corresponde a SF VM. Utilice el UUID de la VM SF identificada en la sección Identifique las VM alojadas en el nodo de cómputo e identifique la tarjeta 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

<snip>

Compruebe el estado de la tarjeta:

[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 la tarjeta está en estado activo, mueva la tarjeta al estado en espera:

[local]VNF2# card migrate from 8 to 10

Inicie sesión en el nodo ESC que corresponde al VNF y verifique el estado de 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>

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_ALIVE_STATE</state>

<vm_name> VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>

<state>VM_ALIVE_STATE</state>

<snip>

Detenga la máquina virtual SF con el uso de su nombre de máquina virtual. (Nombre de máquina virtual indicado en la sección Identificación de las VM alojadas en la �� de nodos informáticos

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

Una vez detenido, la VM debe ingresar el estado SHUTOFF:

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

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_ALIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d</vm_name>

<state>VM_SHUTOFF_STATE</state>

<snip>

Caso 2. Host de nodo de cálculo CF/ESC/EM/UAS

Inicie sesión en el VNF de StarOS e identifique la tarjeta que corresponde a la VM CF. Utilice el UUID de la VM CF identificada en la sección Identifique las VM alojadas en el nodo de cómputo y busque la tarjeta que corresponda 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>

Compruebe el estado de la tarjeta:

[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 la tarjeta está en estado activo, mueva la tarjeta al estado en espera:

[local]VNF2# card migrate from 2 to 1

Inicie sesión en el nodo ESC que corresponde al VNF y verifique el estado 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>

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_ALIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

<state>VM_ALIVE_STATE</state>

<snip>

Detenga la máquina virtual CF y EM una por una con el uso de su nombre de máquina virtual. (Nombre de máquina virtual indicado en la sección Identificación de las VM alojadas en la �� de nodos informáticos

[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 se detenga, las VM deben ingresar el estado SHUTOFF:

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

<vm_name>VNF2-DEPLOYM_c1_0_df4be88d-b4bf-4456-945a-3812653ee229</vm_name>

<state>VM_SHUTOFF_STATE</state>

<vm_name>VNF2-DEPLOYM_c3_0_3e0db133-c13b-4e3d-ac14-

<state>VM_ALIVE_STATE</state>

<deployment_name>VNF2-DEPLOYMENT-em</deployment_name>

<vm_id>507d67c2-1d00-4321-b9d1-da879af524f8</vm_id>

<vm_id>dc168a6a-4aeb-4e81-abd9-91d7568b5f7c</vm_id>

<vm_id>9ffec58b-4b9d-4072-b944-5413bf7fcf07</vm_id>

<state>SERVICE_ACTIVE_STATE</state>

<vm_name>VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea</vm_name>

VM_SHUTOFF_STATE

<snip>

Inicie sesión en el ESC alojado en el nodo de cálculo y verifique si está en el estado principal. En caso afirmativo, cambie el modo ESC al modo de espera:

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

Sustitución de la placa madre

Los pasos para reemplazar la placa base en un servidor UCS C240 M4 se pueden consultar en la Guía de Instalación y Servicio del Servidor Cisco UCS C240 M4

Inicie sesión en el servidor con la IP de CIMC.

Realice la actualización del BIOS si el firmware no se ajusta a la versión recomendada utilizada anteriormente. Los pasos para la actualización del BIOS se indican a continuación: Guía de actualización del BIOS del servidor de montaje en bastidor Cisco UCS C-Series

Restauración de las VM

Caso 1. Compute Node Hosts solamente SF VM

La VM SF estaría en estado de error en la lista 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 la VM SF del ESC:

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

Monitoree el archivo 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 la tarjeta SF aparezca como SF en espera en el VNF.

Caso 2. Host de nodo de cómputo UAS, ESC, EM y CF

Recuperación de la VM UAS

Verifique el estado de la VM UAS en la lista nova y elimínelo:

[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 la VM AutoVNF-UAS, ejecute el script de verificación de UAS para verificar el estado. Debe informar de un error. A continuación, vuelva a ejecutar con la opción —fix para recrear la VM UAS faltante:

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

Inicie sesión en AutoVNF-UAS. Espere unos minutos y verá que el UAS vuelve al estado correcto:

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

Recuperación de VM ESC

Verifique el estado de la VM ESC de la lista nova y elimínelo:

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.

Desde AutoVNF-UAS, busque la transacción de implementación ESC y en el registro de la transacción, busque la línea de comandos boot_vm.py para crear la instancia ESC:

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

Guarde la línea boot_vm.py en un archivo de script de shell (esc.sh) y actualice todas las líneas de nombre de usuario ***** y contraseña ***** con la información correcta (normalmente core/<PASSWORD>). También debe quitar la opción —encrypt_key. Para user_pass y user_confd_pass, debe utilizar el formato - nombre de usuario: password (ejemplo - admin:<PASSWORD>).

Busque la URL a bootvm.py desde running-config y obtenga el archivo bootvm.py a la VM AutoVNF UAS.  En este caso, 10.1.2.3 es la IP de la VM AutoIT:

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 archivo /tmp/esc_params.cfg:

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

Ejecute el script de shell para implementar ESC desde el 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

Inicie sesión en el nuevo ESC y verifique el estado de la copia de seguridad:

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

Recuperación de VM CF y EM de ESC

Verifique el estado de las VM CF y EM de la lista nova. Deben estar en el estado 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

Inicie sesión en ESC Master, ejecute recovery-vm-action para cada EM y VM CF afectadas. Sé paciente. ESC programa la acción de recuperación y puede que no suceda durante unos minutos. Monitoree el archivo yangesc.log:

sudo /opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli recovery-vm-action DO

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

Inicie sesión en el nuevo EM y verifique que el estado de EM esté activo:

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

Inicie sesión en el VNF de StarOS y verifique que la tarjeta CF esté en estado de espera.

Controlar la falla de recuperación ESC

En los casos en los que ESC no puede iniciar la VM debido a un estado inesperado, se recomienda realizar un switchover ESC reiniciando la ESC maestra. El switchover ESC tarda aproximadamente un minuto. Ejecute el script health.sh en el nuevo Master ESC para verificar si el estado está activo. Master ESC para iniciar la VM y corregir el estado de la VM. Esta tarea de recuperación tarda hasta 5 minutos en completarse.

Puede supervisar /var/log/esc/yangesc.log y /var/log/esc/escmanager.log. Si no ve cómo se recupera la máquina virtual después de 5-7 minutos, el usuario debe ir y realizar la recuperación manual de las máquinas virtuales afectadas.

Sustitución de la placa base en el nodo de cómputo OSD

Antes de la actividad, las VM alojadas en el nodo Compute se apagan con gracia y la Ceph se pone en el modo de mantenimiento. Una vez que se ha reemplazado la placa base, se restauran las VM y se mueve Ceph fuera del modo de mantenimiento.

Poner Ceph en modo de mantenimiento

Verifique que el estado ceh osd tree esté activo en el servidor.

[heat-admin@pod1-osd-compute-1 ~]$ sudo ceph osd tree

ID WEIGHT     TYPE NAME                           UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2    4.35999       host 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

-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

Inicie sesión en el nodo OSD Compute y coloque Ceph en el modo de mantenimiento.

[root@pod1-osd-compute-1 ~]# sudo ceph osd set norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd set noout

[root@pod1-osd-compute-1 ~]# 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 {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 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

Nota: Cuando se elimina el Ceph, el RAID HD VNF entra en el estado Degradado, pero el disco duro aún debe estar accesible.

Identificación de las VM alojadas en el nodo Osd-Compute

Identifique las VM alojadas en el servidor de informática OSD. Puede haber dos posibilidades:

El servidor osd-compute contiene la combinación de VM Element Manager (EM)/UAS/Auto-Deploy/Auto-IT:

[stack@director ~]$ nova list --field name,host | grep osd-compute-0

| c6144778-9afd-4946-8453-78c817368f18 | AUTO-DEPLOY-VNF2-uas-0                                   | pod1-osd-compute-0.localdomain |

| 2d051522-bce2-4809-8d63-0c0e17f251dc | AUTO-IT-VNF2-uas-0                                       | pod1-osd-compute-0.localdomain |

| 507d67c2-1d00-4321-b9d1-da879af524f8 | VNF2-DEPLOYM_XXXX_0_c8d98f0f-d874-45d0-af75-88a2d6fa82ea | pod1-osd-compute-0.localdomain |

| f5bd7b9c-476a-4679-83e5-303f0aae9309 | VNF2-UAS-uas-0                                           | pod1-osd-compute-0.localdomain |

El servidor informático contiene la combinación de VM Control Function (CF)/Elastic Services Controller (ESC)/Element Manager (EM)/ (UAS):

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

| 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 el resultado que se muestra aquí, la primera columna corresponde al UUID, la segunda columna es el nombre de VM y la tercera columna es el nombre de host donde está presente la VM. Los parámetros de este resultado se utilizarán en secciones posteriores.

Apagado Graceful

Caso 1. OSD-Compute Node Hosts CF/ESC/EM/UAS

El procedimiento para obtener una alimentación correcta de las VM CF/ESC/EM/UAS es el mismo independientemente de si las VM están alojadas en el nodo Compute o OSD-Compute. Siga los pasos de Sustitución de la Placa base en el nodo de cálculo para apagar correctamente las VM.

Caso 2. OSD-Compute Node Hosts Auto-Deploy/Auto-It/EM/UAS

Realizar una copia de seguridad de la CDB de la implementación automática

Realice una copia de seguridad de los datos de cdb confd automáticamente o después de cada activación/desactivación y guarde el archivo en un servidor de respaldo. La implementación automática no es redundante y, si se pierden estos datos, no podrá desactivar correctamente la implementación.

Inicie sesión en AutoDeploy VM y realice una copia de seguridad del directorio cdb confd.

ubuntu@auto-deploy-iso-2007-uas-0:~ $sudo -i

root@auto-deploy-iso-2007-uas-0:~#service uas-confd stop

uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:~# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd

root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd#tar cvf autodeploy_cdb_backup.tar cdb/

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb

root@auto-deploy-iso-2007-uas-0:~# service uas-confd start

uas-confd start/running, process 13852

Nota: opy autoDeploy_cdb_backup.tar para realizar una copia de seguridad del servidor.

Copia de seguridad de System.cfg desde Auto-IT

Realice una copia de seguridad del archivo system.cfg para realizar una copia de seguridad del servidor:

Auto-it = 10.1.1.2

Backup server = 10.2.2.2

[stack@director ~]$ ssh ubuntu@10.1.1.2

ubuntu@10.1.1.2's password:

Welcome to Ubuntu 14.04.3 LTS (GNU/Linux 3.13.0-76-generic x86_64)

* Documentation:  https://help.ubuntu.com/

System information as of Wed Jun 13 16:21:34 UTC 2018

System load:  0.02               Processes:           87

Usage of /:   15.1% of 78.71GB   Users logged in:     0

Memory usage: 13%                IP address for eth0: 172.16.182.4

Swap usage:   0%

Graph this data and manage this system at:

https://landscape.canonical.com/

Get cloud support with Ubuntu Advantage Cloud Guest:

http://www.ubuntu.com/business/services/cloud

Cisco Ultra Services Platform (USP)

Build Date: Wed Feb 14 12:58:22 EST 2018

Description: UAS build assemble-uas#1891

sha1: bf02ced

ubuntu@auto-it-vnf-uas-0:~$ scp -r /opt/cisco/usp/uploads/system.cfg root@10.2.2.2:/home/stack

root@10.2.2.2's password:

system.cfg                                                                                                                                                                                                          100%  565     0.6KB/s   00:00

ubuntu@auto-it-vnf-uas-0:~$

Nota: El procedimiento para suministrar el máximo rendimiento a las VM de EM/UAS es el mismo independientemente de si las VM están alojadas en el nodo Compute o OSD-Compute.

Siga los pasos de Sustitución de la Placa base en el nodo de cálculo para apagar correctamente estas VM.

Sustitución de la placa madre

Los pasos para reemplazar la placa base en un servidor UCS C240 M4 se pueden consultar en la Guía de Instalación y Servicio del Servidor Cisco UCS C240 M4

Inicie sesión en el servidor con la IP de CIMC.

Realice la actualización del BIOS si el firmware no se ajusta a la versión recomendada utilizada anteriormente. Los pasos para la actualización del BIOS se indican a continuación: Guía de actualización del BIOS del servidor de montaje en bastidor Cisco UCS C-Series

Alejar el Ceph del modo de mantenimiento

Inicie sesión en el nodo de cómputo OSD y mueva Ceph fuera del modo de mantenimiento.

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset norebalance

[root@pod1-osd-compute-1 ~]# sudo ceph osd unset noout

[root@pod1-osd-compute-1 ~]# sudo ceph status

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 e196: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v584954: 704 pgs, 6 pools, 531 GB data, 344 kobjects

1585 GB used, 11808 GB / 13393 GB avail

704 active+clean

client io 12888 kB/s wr, 0 op/s rd, 81 op/s wr

Restauración de las VM

Caso 1. OSD-Compute Node Hosts CF, ESC, EM y UAS

El procedimiento para restaurar las VM CF/ESC/EM/UAS es el mismo independientemente de si las VM están alojadas en el nodo Compute o OSD-Compute. Siga los pasos del Caso 2. Calcule los Hosts CF/ESC/EM/UAS para restaurar las VM.

Caso 2. OSD-Compute Node Hosts Auto-It, Auto-Deploy, EM y UAS

Recuperación de VM de Implementación Automática

En OSPD, si la VM de implementación automática se ha visto afectada pero sigue mostrando ACTIVE/Running, deberá eliminarla primero. Si la implementación automática no se vio afectada, vaya directamente a Recuperación de VM Auto-it:

[stack@director ~]$ nova list |grep auto-deploy

| 9b55270a-2dcd-4ac1-aba3-bf041733a0c9 | auto-deploy-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.12, 10.1.2.7 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7 --delete

Una vez que se elimina la implementación automática, vuelva a crearla con la misma dirección floatingip:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-deploy-booting.sh --floating-ip 10.1.2.7

2017-11-17 07:05:03,038 - INFO: Creating AutoDeploy deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-17 07:05:03,039 - INFO: Loading image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:14,603 - INFO: Loaded image 'auto-deploy-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-17 07:05:15,787 - INFO: Assigned floating IP '10.1.2.7' to IP '172.16.181.7'

2017-11-17 07:05:15,788 - INFO: Creating instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Created instance 'auto-deploy-ISO-5-1-7-2007-uas-0'

2017-11-17 07:05:42,759 - INFO: Request completed, floating IP: 10.1.2.7

Copie el archivo AutoDeploy.cfg, ISO y el archivo confd_backup tar de su servidor de respaldo para implementar automáticamente VM y restaurar los archivos confd cdb del archivo .tar de copia de seguridad:

ubuntu@auto-deploy-iso-2007-uas-0:~# sudo -i

ubuntu@auto-deploy-iso-2007-uas-0:#  service uas-confd stop

uas-confd stop/waiting

root@auto-deploy-iso-2007-uas-0:# cd /opt/cisco/usp/uas/confd-6.3.1/var/confd

root@auto-deploy-iso-2007-uas-0:/opt/cisco/usp/uas/confd-6.3.1/var/confd# tar xvf /home/ubuntu/ad_cdb_backup.tar

cdb/

cdb/O.cdb

cdb/C.cdb

cdb/aaa_init.xml

cdb/A.cdb

root@auto-deploy-iso-2007-uas-0~# service uas-confd start

uas-confd start/running, process 2036

Verifique que confd se haya cargado correctamente comprobando las transacciones anteriores. Actualice autoDeploy.cfg con el nuevo nombre de osd-compute. Ver Sección- Paso final: Actualizar configuración de AutoDeploy.

root@auto-deploy-iso-2007-uas-0:~# 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#show transaction

SERVICE                                                              SITE

DEPLOYMENT                                                     SITE  TX    AUTOVNF  VNF  AUTOVNF

TX ID          TX TYPE             ID          DATE AND TIME                  STATUS              ID    ID    ID       ID   TX ID

-------------------------------------------------------------------------------------------------------------------------------------

1512571978613  service-deployment  tb5bxb      2017-12-06T14:52:59.412+00:00  deployment-success

auto-deploy-iso-2007-uas-0# exit

Recuperación de VM Auto-IT

En OSPD, si la máquina virtual automática se vio afectada pero sigue mostrándose como ACTIVE/Running, debe eliminarla. Si no se ha visto afectado por la automoción, vaya a la siguiente:

[stack@director ~]$ nova list |grep auto-it

| 580faf80-1d8c-463b-9354-781ea0c0b352 | auto-it-vnf-ISO-2007-uas-0                                     | ACTIVE | -          | Running     | mgmt=172.16.181.3, 10.1.2.8 [stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director ~]$ ./ auto-it-vnf-staging.sh --floating-ip 10.1.2.8 --delete

Vuelva a crear Auto-IT ejecutando el script de desarrollo Auto-IT-VNF:

[stack@director ~]$ cd /opt/cisco/usp/uas-installer/scripts

[stack@director scripts]$ ./auto-it-vnf-staging.sh --floating-ip 10.1.2.8

2017-11-16 12:54:31,381 - INFO: Creating StagingServer deployment (1 instance(s)) on 'http://10.84.123.4:5000/v2.0' tenant 'core' user 'core', ISO 'default'

2017-11-16 12:54:31,382 - INFO: Loading image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2' from '/opt/cisco/usp/uas-installer/images/usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:51,961 - INFO: Loaded image 'auto-it-vnf-ISO-5-1-7-2007-usp-uas-1.0.1-1504.qcow2'

2017-11-16 12:54:53,217 - INFO: Assigned floating IP '10.1.2.8' to IP '172.16.181.9'

2017-11-16 12:54:53,217 - INFO: Creating instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,929 - INFO: Created instance 'auto-it-vnf-ISO-5-1-7-2007-uas-0'

2017-11-16 12:55:20,930 - INFO: Request completed, floating IP: 10.1.2.8

Recargue la imagen ISO. En este caso, la dirección IP de TI automática es 10.1.2.8. Esto tardará unos minutos en cargarse:

[stack@director ~]$ cd images/5_1_7-2007/isos

[stack@director isos]$ curl -F file=@usp-5_1_7-2007.iso http://10.1.2.8:5001/isos

{

"iso-id": "5.1.7-2007"

}

to check the ISO image:

[stack@director isos]$ curl http://10.1.2.8:5001/isos

{

"isos": [

{

"iso-id": "5.1.7-2007"

}

]

}

Copie los archivos VNF system.cfg del directorio de implementación automática de OSPD en la máquina virtual Auto-IT:

[stack@director autodeploy]$ scp system-vnf* ubuntu@10.1.2.8:.

ubuntu@10.1.2.8's password:

system-vnf1.cfg                                                                                               100% 1197     1.2KB/s   00:00

system-vnf2.cfg                                                                                               100% 1197     1.2KB/s   00:00

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ pwd

/home/ubuntu

ubuntu@auto-it-vnf-iso-2007-uas-0:~$ ls

system-vnf1.cfg  system-vnf2.cfg

Nota: El procedimiento de recuperación de EM y UAS VM es el mismo, independientemente de si la VM está alojada en Compute o OSD-Compute. Siga los pasos de Sustituir la motherboard en el nodo de cálculo para apagar correctamente estas VM.

Sustitución de la placa madre en el nodo del controlador

Verifique el estado del controlador y coloque el clúster en modo de mantenimiento

Desde OSPD, inicie sesión en el controlador y verifique que los PC estén en buen estado - los tres controladores Online y Galera muestran los tres controladores como Master.

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-0

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-0

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled

Ponga el clúster en modo de mantenimiento:

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

[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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Sustitución de la placa madre

Los pasos para reemplazar la placa base en un servidor UCS C240 M4 se pueden consultar en la Guía de Instalación y Servicio del Servidor Cisco UCS C240 M4

Inicie sesión en el servidor con la IP de CIMC.

Realice la actualización del BIOS si el firmware no se ajusta a la versión recomendada utilizada anteriormente. Los pasos para la actualización del BIOS se indican a continuación: Guía de actualización del BIOS del servidor de montaje en bastidor Cisco UCS C-Series

Restaurar estado del clúster

Inicie sesión en el controlador que ha sido afectado, quite el modo en espera configurando unstandby. Verifique si el controlador se conecta con el clúster y Galera muestra los tres controladores como maestro. Esto puede tardar unos 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-controller-0 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-1 (stonith:fence_ipmilan): Started pod1-controller-1

my-ipmilan-for-controller-2 (stonith:fence_ipmilan): Started pod1-controller-2

Daemon Status:

corosync: active/enabled

pacemaker: active/enabled

pcsd: active/enabled