Sustitución de PCRF del servidor informático UCS C240 M4

Introducción

Este documento describe los pasos necesarios para sustituir un servidor informático defectuoso en una configuración Ultra-M que aloja Cisco Policy Suite (CPS) Virtual Network Functions (VNF).

Antecedentes

Este documento está dirigido al personal de Cisco familiarizado con la plataforma Cisco Ultra-M y detalla los pasos necesarios para llevarse a cabo en el nivel de VNF de OpenStack y CPS en el momento de la sustitución del servidor informático.

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

Comprobación de estado

Antes de sustituir un nodo de cálculo, es importante comprobar el estado actual de su entorno de Red Hat OpenStack Platform. Se recomienda que verifique el estado actual para evitar complicaciones cuando el proceso de reemplazo de Compute está activado.

Paso 1. Desde la implementación de OpenStack (OSPD). 

[root@director ~]$ su - stack
[stack@director ~]$ cd ansible
[stack@director ansible]$ ansible-playbook -i inventory-new openstack_verify.yml  -e platform=pcrf

Paso 2. Verifique el estado del sistema a partir del informe de estado del ultram que se genera cada quince minutos.

[stack@director ~]# cd /var/log/cisco/ultram-health

Paso 3. Verifique el archivo ultram_health_os.report. Los únicos servicios deben mostrar como XXX estado son neutron-sriov-nic-agent.service.

Paso 4. Para verificar si rabbitmq se ejecuta para todos los controladores ejecutados desde OSPD.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo rabbitmqctl eval 'rabbit_diagnostics:maybe_stuck().'" ) & done

Paso 5. Verificar que el stonith esté habilitado

[stack@director ~]# sudo pcs property show stonith-enabled

Paso 6. Para todos los controladores, verifique el estado del PCS.

• Todos los nodos del controlador se inician bajo haproxy-clone.
• Todos los nodos del controlador están activos bajo galera.
• Todos los nodos del controlador se inician bajo Rabbitmq.
• 1 nodo del controlador es Activo y 2 En espera bajo redis.

 Paso 7. De OSPD.

[stack@director ~]$ for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo pcs status" ) ;done 

Paso 8. Verifique que todos los servicios openstack estén activos, desde OSPD ejecute este comando.

[stack@director ~]# sudo systemctl list-units "openstack*" "neutron*" "openvswitch*"

Paso 9. Verifique que el estado de CEPH sea HEALTH_OK para los controladores.

[stack@director ~]# for i in $(nova list| grep controller | awk '{print $12}'| sed 's/ctlplane=//g') ; do (ssh -o StrictHostKeyChecking=no heat-admin@$i "hostname;sudo ceph -s" ) ;done

Paso 10. Verifique los registros de componentes de OpenStack. Busque cualquier error:

Neutron:
[stack@director ~]# sudo tail -n 20 /var/log/neutron/{dhcp-agent,l3-agent,metadata-agent,openvswitch-agent,server}.log

Cinder:
[stack@director ~]# sudo tail -n 20 /var/log/cinder/{api,scheduler,volume}.log

Glance:
[stack@director ~]# sudo tail -n 20 /var/log/glance/{api,registry}.log

Paso 11. Desde OSPD realice estas verificaciones para API.

[stack@director ~]$ source 
     
     

[stack@director ~]$ nova list

[stack@director ~]$ glance image-list

[stack@director ~]$ cinder list

[stack@director ~]$ neutron net-list

Paso 12. Verifique el estado de los servicios.

Every service status should be “up”:
[stack@director ~]$ nova service-list

Every service status should be “ :-)”:
[stack@director ~]$ neutron agent-list

Every service status should be “up”:
[stack@director ~]$ cinder service-list

Copia de seguridad

En caso de recuperación, Cisco recomienda realizar una copia de seguridad de la base de datos OSPD con 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 asegura que un nodo se pueda reemplazar sin afectar la disponibilidad de ninguna instancia. Además, se recomienda realizar una copia de seguridad de la configuración de CPS.

Para realizar una copia de seguridad de las VM CPS, desde la VM Cluster Manager:

[root@CM ~]# config_br.py -a export --all /mnt/backup/CPS_backup_$(date +\%Y-\%m-\%d).tar.gz

or

[root@CM ~]# config_br.py -a export --mongo-all --svn --etc --grafanadb --auth-htpasswd --haproxy /mnt/backup/$(hostname)_backup_all_$(date +\%Y-\%m-\%d).tar.gz

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

Identifique las VM alojadas en el servidor informático:

[stack@director ~]$ nova list --field name,host,networks | grep compute-10
| 49ac5f22-469e-4b84-badc-031083db0533 |  VNF2-DEPLOYM_s9_0_8bc6cc60-15d6-4ead-8b6a-10e75d0e134d     |  pod1-compute-10.localdomain    | Replication=10.160.137.161; Internal=192.168.1.131; Management=10.225.247.229; tb1-orch=172.16.180.129

Nota: En el resultado que se muestra aquí, la primera columna corresponde al identificador único universal (UUID), la segunda columna es el nombre de la máquina virtual y la tercera columna es el nombre de host donde está presente la máquina virtual. Los parámetros de este resultado se utilizan en secciones posteriores.

Inhabilitar los servicios PCRF que residen en la máquina virtual para ser apagados

Paso 1. Inicie sesión en IP de administración de la VM:

[stack@XX-ospd ~]$ ssh root@
     
     
[root@XXXSM03 ~]# monit stop all

Paso 2. Si la VM es un SM, OAM o árbitro, además, detenga los servicios de sessionmgr:

[root@XXXSM03 ~]# cd /etc/init.d
[root@XXXSM03 init.d]# ls -l sessionmgr*
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27717
-rwxr-xr-x 1 root root 4399 Nov 28 22:45 sessionmgr-27721
-rwxr-xr-x 1 root root 4544 Nov 29 23:47 sessionmgr-27727

Paso 3. Para cada archivo titulado sessionmgr-xxxxx, ejecute service sessionmgr-xxxxx stop:

  

[root@XXXSM03 init.d]# service sessionmgr-27717 stop

  

Eliminar el nodo de cálculo de la lista de agregación de Nova

Paso 1. Enumere los agregados nova e identifique el agregado que corresponde al servidor informático basado en el VNF alojado por él. Normalmente, tendría el formato <VNFNAME>-SERVICE<X>:

[stack@director ~]$ nova aggregate-list
+----+-------------------+-------------------+
| Id | Name              | Availability Zone |
+----+-------------------+-------------------+
| 29 | POD1-AUTOIT   | mgmt              |
| 57 | VNF1-SERVICE1 | -                 |
| 60 | VNF1-EM-MGMT1 | -                 |
| 63 | VNF1-CF-MGMT1 | -                 |
| 66 | VNF2-CF-MGMT2 | -                 |
| 69 | VNF2-EM-MGMT2 | -                 |
| 72 | VNF2-SERVICE2 | -                 |
| 75 | VNF3-CF-MGMT3 | -                 |
| 78 | VNF3-EM-MGMT3 | -                 |
| 81 | VNF3-SERVICE3 | -                 |
+----+-------------------+-------------------+

   En este caso, el servidor informático que se va a reemplazar pertenece a VNF2. Por lo tanto, la lista de agregación correspondiente es VNF2-SERVICE2.

Paso 2. Eliminar el nodo de cálculo del agregado identificado (eliminar por nombre de host anotado en la sección Identificar las VM alojadas en el nodo de cálculo 😞

nova aggregate-remove-host 
     
      
       
     

[stack@director ~]$ nova aggregate-remove-host VNF2-SERVICE2 pod1-compute-10.localdomain

Paso 3. Verifique si el nodo de cálculo se elimina de los agregados. Ahora, el Host no debe aparecer en el agregado:

nova aggregate-show 
     
     

[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

Eliminación del nodo de cálculo

Los pasos mencionados en esta sección son comunes independientemente de las VM alojadas en el nodo informático.

Eliminar de Overcloud

Paso 1. Cree un archivo de script denominado delete_node.sh con el contenido como se muestra aquí. Asegúrese de que las plantillas mencionadas sean las mismas que las utilizadas en el script Deploy.sh utilizado para la implementación de la pila.

 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@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 pod1 49ac5f22-469e-4b84-badc-031083db0533
Deleting the following nodes from stack pod1:
- 49ac5f22-469e-4b84-badc-031083db0533
Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae

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

Paso 2. Espere a que la operación de pila OpenStack pase al estado COMPLETE.

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

Eliminar nodo de cálculo de la lista de servicios

Elimine el servicio informático de la lista de servicios:

[stack@director ~]$ source corerc
[stack@director ~]$ openstack compute service list | grep compute-8
| 404 | nova-compute     | pod1-compute-8.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

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

Eliminar agentes neutrales

Elimine el agente neutrón asociado antiguo y abra el agente vswitch para el servidor informático:

[stack@director ~]$ openstack network agent list | grep compute-8
| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |
| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-compute-8.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete 
     
     

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03
[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

Eliminar de la base de datos irónica

Elimine un nodo de la base de datos irónica y verifíquelo.

[stack@director ~]$ source stackrc

nova show 
     
     
       | grep hypervisor 
     

[stack@director ~]$ nova show pod1-compute-10 | grep hypervisor
| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete 
     
     

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a 
[stack@director ~]$ ironic node-list (node delete must not be listed now) 

Instalación del nuevo nodo informático

Los pasos para instalar un nuevo servidor UCS C240 M4 y los pasos de configuración inicial se pueden consultar desde: Guía de instalación y servicio del servidor Cisco UCS C240 M4

Paso 1. Después de la instalación del servidor, inserte los discos duros en las ranuras respectivas como el servidor antiguo.

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

Paso 3. 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

Paso 4. Para verificar el estado de las unidades físicas, navegue hasta Almacenamiento > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Información de unidad física. Debe ser Unconfigured Good

El almacenamiento que se muestra aquí puede ser una unidad SSD.

Paso 5. Para crear una unidad virtual desde las unidades físicas con RAID Nivel 1, navegue hasta Almacenamiento > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Información del controlador > Crear unidad virtual desde unidades físicas no usadas

Paso 6. Seleccione el VD y configure Set as Boot Drive, como se muestra en la imagen.

Paso 7. Para habilitar IPMI sobre LAN, navegue a Admin > Communication Services > Communication Services, como se muestra en la imagen.

Paso 8. Para inhabilitar el hiperprocesamiento, como se muestra en la imagen, navegue hasta Compute > BIOS > Configure BIOS > Advanced > Processor Configuration.

Nota: La imagen que se muestra aquí y los pasos de configuración mencionados en esta sección están relacionados con la versión de firmware 3.0(3e) y puede haber ligeras variaciones si trabaja en otras versiones

Agregar el nuevo nodo informático a la nube

Los pasos mencionados en esta sección son comunes independientemente de la máquina virtual alojada por el nodo informático.

Paso 1. Agregue el servidor de cómputo con un índice diferente.

Cree un archivo add_node.json con sólo los detalles del nuevo servidor informático que se agregará. Asegúrese de que el número de índice del nuevo servidor informático no se haya utilizado antes. Normalmente, aumente el siguiente valor de cálculo más alto.

Ejemplo: El más alto anterior era compute-17, por lo tanto, se creó compute-18 en el caso del sistema 2-vnf. 

Nota: Tenga en cuenta el formato json.

[stack@director ~]$ cat add_node.json 
{
    "nodes":[
        {
            "mac":[
                "
     
     
       " 
     
            ],
            "capabilities": "node:compute-18,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"
        }
    ]
}

Paso 2. Importe el archivo 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.

  

Paso 3. Ejecute la introspección del nodo con el uso del UUID observado desde el paso 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       |

Paso 4. Agregue las direcciones IP a custom-templates/layout.yml en ComputeIPs. Agregue esa dirección al final de la lista para cada tipo, compute-0 que se muestra aquí como ejemplo.

ComputeIPs:

    internal_api:

    - 11.120.0.43

    - 11.120.0.44

    - 11.120.0.45

    - 11.120.0.43   <<< take 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

Paso 5. Ejecute el script Deploy.sh que se utilizó anteriormente para implementar la pila, para agregar el nuevo nodo de cálculo a la pila de nube superpuesta.

[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

Paso 6. Espere a que se complete el estado de pila de openstack.

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

Paso 7. Verifique que el nuevo nodo de cálculo se encuentre en el estado Activo.

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

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

Restauración de las VM

Adición a la lista de agregación Nova

Agregue el nodo de cálculo al host agregado y verifique si se agrega el host.

nova aggregate-add-host 
     
      
       
     
[stack@director ~]$ nova aggregate-add-host VNF2-SERVICE2 pod1-compute-18.localdomain

nova aggregate-show 
     
     
[stack@director ~]$ nova aggregate-show VNF2-SERVICE2

Recuperación de VM desde Elastic Services Controller (ESC)

Paso 1. La VM está 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     | 

Paso 2. Recupere la máquina virtual de 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

     
     

     
     
  
     
     

Paso 3. 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].

    

Compruebe los servicios de la función de reglas de cobro y políticas (PCRF) de Cisco que residen en VM

Nota: Si la VM está en estado de apagado, enciéndala usando esc_nc_cli de ESC.

Verifique el diagnostics.sh de la VM del cluster manager y si se encuentra algún error para las VM que se recuperan entonces

Paso 1. Inicie sesión en la máquina virtual correspondiente.

[stack@XX-ospd ~]$ ssh root@
     
     
[root@XXXSM03 ~]# monit start all

Paso 2. Si la VM es un SM, OAM o árbitro, además de ello, inicie los servicios de sessionmgr que se detuvieron antes:

Para cada archivo titulado sessionmgr-xxxxx, ejecute service sessionmgr-xxxxx start:

  

[root@XXXSM03 init.d]# service sessionmgr-27717 start

Si el diagnóstico todavía no está claro, realice build_all.sh desde la VM Cluster Manager y luego realice VM-init en la VM correspondiente.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init

Eliminación y reimplementación de una o más VM en caso de que la recuperación ESC falle

Si el comando ESC recovery (anterior) no funciona (VM_RECOVERY_FAILED), elimine y lea las máquinas virtuales individuales.

Obtener la última plantilla ESC del sitio

Desde el portal ESC:

Paso 1. Coloque el cursor sobre el botón Acción azul, se abre una ventana emergente y haga clic en Exportar plantilla, como se muestra en la imagen.

Paso 2. Se presenta una opción para descargar la plantilla en el equipo local, consulte Guardar archivo, como se muestra en la imagen. 

Paso 3. Como se muestra en la imagen, seleccione una ubicación y guarde el archivo para su uso posterior.

Paso 4. Inicie sesión en Active ESC para eliminar el sitio y copie el archivo guardado anterior en ESC en este directorio.

/opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Paso 5. Cambiar directorio a /opt/cisco/esc/cisco-cps/config/gr/tmo/gen:

cd /opt/cisco/esc/cisco-cps/config/gr/tmo/gen

Procedimiento para modificar el archivo

Paso 1. Modifique el archivo de plantilla de exportación.

En este paso, modifica el archivo de plantilla de exportación para eliminar el grupo o grupos de VM asociados a las VM que deben recuperarse.

El archivo de plantilla de exportación es para un clúster específico.

Dentro de ese clúster hay varios vm_groups.  Hay uno o más vm_groups para cada tipo de VM (PD, PS, SM, OM).

Nota: Algunos vm_groups tienen más de una VM.  Todas las VM de ese grupo se eliminarán y volverán a agregar.

Dentro de esa implementación, debe etiquetar uno o más de los vm_groups para su eliminación.

Ejemplo:

               <vm_group>

                  <name>cm</name>

Ahora cambie <vm_group>a <vm_group nc:operation="delete"> y guarde los cambios.

Paso 2. Ejecute el archivo de plantilla de exportación modificada.

Desde la ejecución ESC:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

Desde el portal ESC, debería poder ver una o más VM que se mueven al estado unDeploy y luego desaparecen por completo.

Se puede realizar un seguimiento del progreso en la dirección /var/log/esc/yangesc.log de ESC

Ejemplo:

09:09:12,608 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUEST RECEIVED(UNDER TENANT) =====
09:09:12,608 29-Jan-2018 INFO  Tenant name: Pcrf
09:09:12,609 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:09:29,794 29-Jan-2018 INFO 
09:09:29,794 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:10:19,459 29-Jan-2018 INFO 
09:10:19,459 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:19,459 29-Jan-2018 INFO  Type: VM_UNDEPLOYED
09:10:19,459 29-Jan-2018 INFO  Status: SUCCESS
09:10:19,459 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:10:22,292 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:10:22,292 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:10:22,292 29-Jan-2018 INFO  Status: SUCCESS
09:10:22,292 29-Jan-2018 INFO  Status Code: 200

Paso 3. Modifique el archivo de plantilla de exportación para agregar las VM.

En este paso, modifica el archivo de plantilla de exportación para volver a agregar el grupo o grupos de VM asociados a las VM que se están recuperando.

El archivo de plantilla de exportación se divide en las dos implementaciones (cluster1 / cluster2).

Dentro de cada clúster hay un vm_group. Hay uno o más vm_groups para cada tipo de VM (PD, PS, SM, OM).

Nota: Algunos vm_groups tienen más de una VM.  Se volverán a agregar todas las VM de ese grupo.

Ejemplo:

               <vm_group nc:operation="delete">

                  <name>cm</name>

Cambie <vm_group nc:operation="delete"> a solamente <vm_group> .

Nota: Si es necesario reconstruir las VM porque se reemplazó el Host, es posible que el nombre de host del Host haya cambiado.  Si el nombre de host del HOST ha cambiado, el nombre de host dentro de la sección de ubicación del vm_group deberá actualizarse.

<location>

                      <type>zone_host</type>

                     <enforce>estricto</enforce>

                      <host>wsstackovs-compute-4.localdomain</host>

</location>

Actualice el nombre del host que se muestra en la sección anterior al nuevo nombre de host según lo proporcionado por el equipo Ultra-M antes de la ejecución de este MOP. Después de la instalación del nuevo host, guarde los cambios.

Paso 4. Ejecute el archivo de plantilla de exportación modificada.

Desde la ejecución ESC:

/opt/cisco/esc/esc-confd/esc-cli/esc_nc_cli edit-config /opt/cisco/esc/cisco-cps/config/gr/tmo/gen/
     
     

Desde el portal ESC, debería poder ver que una o más VM reaparecen y, a continuación, en el estado Activo.

Se puede realizar un seguimiento del progreso en la dirección /var/log/esc/yangesc.log de ESC

Ejemplo:

09:14:00,906 29-Jan-2018 INFO  ===== UPDATE SERVICE REQUESTRECEIVED (UNDER TENANT) =====
09:14:00,906 29-Jan-2018 INFO  Tenant name: Pcrf
09:14:00,906 29-Jan-2018 INFO  Deployment name: WSP1-tmo
09:14:01,542 29-Jan-2018 INFO 
09:14:01,542 29-Jan-2018 INFO  ===== CONFD TRANSACTION ACCEPTED  =====
09:16:33,947 29-Jan-2018 INFO 
09:16:33,947 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:16:33,947 29-Jan-2018 INFO  Type: VM_DEPLOYED
09:16:33,947 29-Jan-2018 INFO  Status: SUCCESS
09:16:33,947 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,148 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,148 29-Jan-2018 INFO  Type: VM_ALIVE
09:19:00,148 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,148 29-Jan-2018 INFO  Status Code: 200
|
|
|
09:19:00,275 29-Jan-2018 INFO  ===== SEND NOTIFICATION STARTS =====
09:19:00,275 29-Jan-2018 INFO  Type: SERVICE_UPDATED
09:19:00,275 29-Jan-2018 INFO  Status: SUCCESS
09:19:00,275 29-Jan-2018 INFO  Status Code: 200

Paso 5. Verifique los servicios PCRF que residen en la máquina virtual.

Verifique si los servicios PCRF están inactivos e inícielos.

[stack@XX-ospd ~]$ ssh root@
     
     
[root@XXXSM03 ~]# monsum
[root@XXXSM03 ~]# monit start all

Si la VM es un SM, OAM o árbitro, además, inicie los servicios sessionmgr que se detuvieron antes:

Para cada archivo titulado sessionmgr-xxxxx ejecute service sessionmgr-xxxxx start:

  

[root@XXXSM03 init.d]# service sessionmgr-27717 start

 Si el diagnóstico aún no está claro, realice build_all.sh desde la VM Cluster Manager y luego realice VM-init en la VM respectiva.

/var/qps/install/current/scripts/build_all.sh

ssh VM   e.g. ssh pcrfclient01 
/etc/init.d/vm-init

Paso 6. Ejecute el diagnóstico para comprobar el estado del sistema.

[root@XXXSM03 init.d]# diagnostics.sh

Información Relacionada

• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installati...
  
• Soporte Técnico y Documentación - Cisco Systems