Contenido

Introducción

Antecedentes

Flujo de trabajo de la fregona

Abreviaturas

prerrequisitos

Salvaguardia OSPD

Identifique las VM recibidas en el nodo del OSD-cálculo

Potencia agraciada apagado

El nodo del OSD-cálculo del caso 1. recibe CF/ESC/EM/UAS

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

CF y EM VM de la parada normal de salida

Emigre salida al modo de reserva

Quite el nodo del OSD-cálculo de la lista del agregado de Nova

Auto-despliegan/Auto-IT/EM/UAS de los host del nodo del OSD-cálculo del caso 2.

Salvaguardia que el BDC de Auto-despliega

Salvaguardia system.cfg de las Auto-TIC

Eliminación del nodo del OSD-cálculo

Nodo del OSD-cálculo de la cancelación de la lista del servicio

Agentes del neutrón de la cancelación

Cancelación de Nova y de la base de datos irónica

La cancelación de se nubla

Instale el nuevo nodo del cálculo

Agregue el nuevo nodo del OSD-cálculo al nublar

Fije las configuraciones del reemplazo del servidor

Restablezca las VM

Encajone 1. nodos del OSD-cálculo que reciben los CF, salida, EM y UAS

Adición a la lista del agregado de Nova

Recuperación de UAS VM

Recuperación de salida VM

Recupere los CF y EM VM de salida

El nodo del OSD-cálculo del caso 2. que recibe las Auto-TIC, Auto-despliega, EM y UAS

La recuperación de Auto-despliega la VM

Recuperación de las Auto-TIC VM

Error de la recuperación salida de la manija

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

Activación de los Syslog

Introducción

Este documento describe los pasos que se requieren para substituir un disco defectuoso del almacenamiento del objeto (OSD) - computa el servidor en un Ultra-M puesto que funciona la red virtual de StarOS de los host (VNFs).

Antecedentes

Ultra-M es una solución móvil virtualizada preembalada y validada de la base del paquete diseñada 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

- 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 que se requieren ser realizados en el nivel de OpenStack y de StarOS VNF a la hora del reemplazo del servidor del cálculo.

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

Flujo de trabajo de la fregona

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

Prerrequisitos

Salvaguardia OSPD

Antes de que usted substituya un nodo del OSD-cálculo, 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 del cálculo está prendido. Puede ser alcanzado por este flujo de reemplazo.

En caso de la recuperación, Cisco le recomienda toma una salvaguardia de la base de datos OSPD (DB) 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 del cálculo que se substituirá recibe los CF VM.

Identifique las VM recibidas en el nodo del OSD-cálculo

Identifique las VM que se reciben en el servidor del cálculo. Puede haber dos posibilidades:

El servidor del OSD-cálculo contiene la combinación EM/UAS/Auto-Deploy/Auto-IT de VM:

[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 del cálculo contiene la combinación CF/ESC/EM/UAS de VM:

[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 la salida mostrada aquí, la primera columna corresponde al 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.

Verifique que Ceph tenga capacidad disponible para permitir que un solo servidor OSD sea quitado:

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

GLOBAL:

SIZE       AVAIL      RAW USED     %RAW USED

13393G     11804G        1589G         11.87

POOLS:

NAME        ID    USED      %USED     MAX AVAIL     OBJECTS

rbd         0          0         0         3876G           0

metrics     1     4157M      0.10         3876G      215385

images      2     6731M      0.17         3876G         897

backups     3         0         0         3876G           0

volumes     4      399G      9.34         3876G      102373

vms         5      122G      3.06         3876G       31863

Verifique que estatus del árbol del osd del ceph esté para arriba en el servidor del OSD-cálculo:

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

Los procesos de Ceph son activos en el servidor del OSD-cálculo:

[root@pod1-osd-compute-1 ~]# systemctl list-units *ceph*

UNIT                              LOAD   ACTIVE SUB     DESCRIPTION

var-lib-ceph-osd-ceph\x2d11.mount loaded active mounted /var/lib/ceph/osd/ceph-11

var-lib-ceph-osd-ceph\x2d2.mount  loaded active mounted /var/lib/ceph/osd/ceph-2

var-lib-ceph-osd-ceph\x2d5.mount  loaded active mounted /var/lib/ceph/osd/ceph-5

var-lib-ceph-osd-ceph\x2d8.mount  loaded active mounted /var/lib/ceph/osd/ceph-8

ceph-osd@11.service               loaded active running Ceph object storage daemon

ceph-osd@2.service                loaded active running Ceph object storage daemon

ceph-osd@5.service                loaded active running Ceph object storage daemon

ceph-osd@8.service                loaded active running Ceph object storage daemon

system-ceph\x2ddisk.slice         loaded active active  system-ceph\x2ddisk.slice

system-ceph\x2dosd.slice          loaded active active  system-ceph\x2dosd.slice

ceph-mon.target                   loaded active active  ceph target allowing to start/stop all ceph-mon@.service instances at once

ceph-osd.target                   loaded active active  ceph target allowing to start/stop all ceph-osd@.service instances at once

ceph-radosgw.target               loaded active active  ceph target allowing to start/stop all ceph-radosgw@.service instances at once

ceph.target                       loaded active active  ceph target allowing to start/stop all ceph*@.service instances at once

Inhabilite y pare cada caso de Ceph y quite cada caso del OSD y del unmount el directorio. Relance para cada caso de Ceph:

[root@pod1-osd-compute-1 ~]# systemctl disable ceph-osd@11

[root@pod1-osd-compute-1 ~]# systemctl stop ceph-osd@11

[root@pod1-osd-compute-1 ~]# ceph osd out 11

marked out osd.11.

[root@pod1-osd-compute-1 ~]# ceph osd crush remove osd.11

removed item id 11 name 'osd.11' from crush map

[root@pod1-osd-compute-1 ~]# ceph auth del osd.11

updated

[root@pod1-osd-compute-1 ~]# ceph osd rm 11

removed osd.11

[root@pod1-osd-compute-1 ~]# umount /var/lib/ceph.osd/ceph-11

[root@pod1-osd-compute-1 ~]# rm -rf /var/lib/ceph.osd/ceph-11

or

El script de Clean.sh se puede utilizar para realizar esta tarea:

[heat-admin@pod1-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd

ceph-11 ceph-3 ceph-6 ceph-8

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

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

#!/bin/sh

set -x

CEPH=`sudo ls /var/lib/ceph/osd`

for c in $CEPH

do

i=`echo $c |cut -d'-' -f2`

sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd out $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1)

sleep 2

sudo ceph osd rm $i || (echo "error rc:$?"; exit 1)

sleep 2

sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1)

sleep 2

done

sudo ceph osd tree

Después de todo los procesos OSD se han emigrado/se han suprimido, el nodo se pueden quitar del nublar.

Nota: Cuando se quita Ceph, VNF HD RAID entrará el estado degradado pero el HD-disco debe todavía ser accesible.

Potencia agraciada apagado

El nodo del OSD-cálculo del caso 1. recibe CF/ESC/EM/UAS

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 del OSD-cálculo, 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>

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

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 del OSD-cálculo.

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

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

<state>VM_SHUTOFF_STATE</state>

<snip>

Emigre salida al modo de reserva

Ábrase una sesión a salida recibida en el nodo del cálculo 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!

Quite el nodo del OSD-cálculo de la lista del agregado de Nova

Enumere los agregados de la Nova e identifique el agregado que corresponde al servidor del cálculo basado en el VNF recibido por ella. Generalmente, estaría del formato <VNFNAME>-EM-MGMT<X> y <VNFNAME>-CF-MGMT<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 del OSD-cálculo pertenece a VNF2. Así pues, los agregados que corresponden serían VNF2-CF-MGMT2 y VNF2-EM-MGMT2.

Quite el nodo del OSD-cálculo del agregado identificado:

nova aggregate-remove-host <Aggregate> <Host>

[stack@director ~]$ nova aggregate-remove-host VNF2-CF-MGMT2 pod1-osd-compute-0.localdomain

[stack@director ~]$ nova aggregate-remove-host VNF2-EM-MGMT2 pod1-osd-compute-0.localdomain

[stack@director ~]$ nova aggregate-remove-host POD1-AUTOIT   pod1-osd-compute-0.localdomain

Verifique si el nodo del OSD-cálculo se ha quitado de los agregados. Ahora, asegúrese de que el host no sea mencionado bajo agregados:

nova aggregate-show <aggregate-name>

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

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

[stack@director ~]$ nova aggregate-show POD1-AUTOIT

Auto-despliegan/Auto-IT/EM/UAS de los host del nodo del OSD-cálculo del caso 2.

Salvaguardia que el BDC de Auto-despliega

La salvaguardia los datos autodeploy del confd BDC periódicamente o después de que cada activación/desactivación y salva el fichero a un servidor de reserva. Auto-Desplegar no es redundante y si se pierden estos datos, será difícil desactivar el despliegue.

Ábrase una sesión Auto-para desplegar la VM y el directorio de reserva del confd BDC:

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: Copie autodeploy_cdb_backup.tar al servidor de reserva.

Salvaguardia system.cfg de las Auto-TIC

Lleve la salvaguardia del fichero system.cfg el salvaguardia-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: Los procedimientos que se realizarán para un Cierre elegante de EM/UAS recibido en OSD-Compute-0 son lo mismo en ambos el caso. Refiera a Case.1 para lo mismo.

Eliminación del nodo del OSD-cálculo

Los pasos mencionados en esta sección son comunes con independencia de las VM recibidas en el nodo del cálculo.

Nodo del OSD-cálculo de la cancelación de la lista del servicio

Suprima el servicio del cálculo de la lista del servicio:

[stack@director ~]$ source corerc

[stack@director ~]$ openstack compute service list | grep osd-compute-0

| 404 | nova-compute     | pod1-osd-compute-0.localdomain     | nova     | enabled | up    | 2018-05-08T18:40:56.000000 |

openstack compute service delete <ID>

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

Suprima los agentes del neutrón

Suprima el agente asociado viejo del neutrón y abra el agente del vswitch para el servidor del cálculo:

[stack@director ~]$ openstack network agent list | grep osd-compute-0

| c3ee92ba-aa23-480c-ac81-d3d8d01dcc03 | Open vSwitch agent | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-openvswitch-agent |

| ec19cb01-abbb-4773-8397-8739d9b0a349 | NIC Switch agent   | pod1-osd-compute-0.localdomain     | None              | False  | UP    | neutron-sriov-nic-agent   |

openstack network agent delete <ID>

[stack@director ~]$ openstack network agent delete c3ee92ba-aa23-480c-ac81-d3d8d01dcc03

[stack@director ~]$ openstack network agent delete ec19cb01-abbb-4773-8397-8739d9b0a349

Cancelación de Nova y de la base de datos irónica

Suprima un nodo de la lista de la Nova y de la base de datos irónica y verifiqúelo:

[stack@director ~]$ source stackrc

[stack@al01-pod1-ospd ~]$ nova list | grep osd-compute-0

| c2cfa4d6-9c88-4ba0-9970-857d1a18d02c | pod1-osd-compute-0 | ACTIVE | -          | Running     | ctlplane=192.200.0.114 |

[stack@al01-pod1-ospd ~]$ nova delete c2cfa4d6-9c88-4ba0-9970-857d1a18d02c

nova show <compute-node> | grep hypervisor

[stack@director ~]$ nova show pod1-osd-compute-0 | grep hypervisor

| OS-EXT-SRV-ATTR:hypervisor_hostname  | 4ab21917-32fa-43a6-9260-02538b5c7a5a

ironic node-delete <ID>

[stack@director ~]$ ironic node-delete 4ab21917-32fa-43a6-9260-02538b5c7a5a

[stack@director ~]$ ironic node-list (node delete must not be listed now)

La cancelación de se nubla

Cree un archivo de secuencia de comandos nombrado delete_node.sh con el contenido como se muestra. Asegúrese de que las plantillas mencionadas sean lo mismo que las que está usadas en el script de deploy.sh usado para el despliegue 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-name> <UUID>

[stack@director ~]$ source stackrc

[stack@director ~]$ /bin/sh delete_node.sh

+ openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack 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

Espere la operación de la pila de OpenStack para moverse al estado COMPLETO:

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

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

Instale el nuevo nodo del cálculo

- Los pasos para instalar un nuevo servidor UCS C240 M4 y los pasos iniciales de la disposición se pueden referir de:

Instalación del servidor de Cisco UCS C240 M4 y guía del servicio

- Después de la instalación del servidor, inserte los discos duros en las ranuras respectivas como el servidor viejo

- Ábrase una sesión al servidor con el uso del IP CIMC

- Realice la mejora BIOS si el firmware no está según la versión recomendada usada previamente. Los pasos para la mejora BIOS se dan aquí:

Guía de actualización BIOS del servidor de los montajes en bastidor de la serie C de Cisco UCS

- Verifique el estatus de las unidades físicas. Debe ser Unconimaged bueno

- Cree una unidad virtual de las unidades físicas con el nivel 1 RAID

Almacenamiento > regulador modular de la incursión de Cisco 12G SAS (SLOT-HBA) > información física de la unidad

Nota: Esta imagen es para el fin de ilustración solamente, en real, el OSD-cálculo CIMC que usted verá siete unidades físicas en las ranuras (1,2,3,7,8,9,10) en el buen estado Unconfigured pues no se crea ningunas unidades virtuales de ellas.

El almacenamiento > el regulador modular de la incursión de Cisco 12G SAS (SLOT-HBA) > información del controlador > crean la unidad virtual de las unidades físicas inusitadas

Seleccione el VD y configurelo “fijan como unidad de arranque”

Activan IPMI sobre el LAN: Admin > servicios de comunicación > servicios de comunicación

Neutralización hyperthreading: El cálculo > el BIOS > configuran BIOS > avanzaron > configuración del procesador

- Similar a BOOTOS VD creado con la comprobación conduce 1 y 2, crean cuatro más unidades virtuales como

DIARIO > de la unidad número física 3

OSD1 > de la unidad número física 7

OSD2 > de la unidad número física 8

OSD3 > de la unidad número física 9

OSD4 > de la unidad número física 10

- En el extremo, las unidades y las unidades virtuales de la comprobación deben ser similares tal y como se muestra en de la imagen:

unidadesde la comprobación de las unidades virtuales

Nota: La imagen mostrada aquí y los pasos para la configuración mencionados en esta sección están referente a la versión de firmware 3.0(3e) y pudo haber variaciones mínimas si usted trabaja en otras versiones.

Agregue el nuevo nodo del OSD-cálculo al nublar

Los pasos mencionados en esta sección son comunes con independencia de la VM recibida por el nodo del cálculo.

Agregue el servidor del cálculo con un diverso índice.

Cree un fichero add_node.json con solamente los detalles del nuevo servidor del cálculo que se agregará. Asegúrese de que el número del índice para el nuevo servidor del OSD-cálculo no se haya utilizado antes. Típicamente, incremente el valor más alto siguiente del cálculo.

Ejemplo: Estaban lo más arriba posible anteriormente OSD-Compute-0 así que OSD-Compute-3 creado en caso del sistema 2-vnf.

Nota: Sea atento del formato del json.

[stack@director ~]$ cat add_node.json

{

"nodes":[

{

"mac":[

"<MAC_ADDRESS>"

],

"capabilities": "node:osd-compute-3,boot_option:local",

"cpu":"24",

"memory":"256000",

"disk":"3000",

"arch":"x86_64",

"pm_type":"pxe_ipmitool",

"pm_user":"admin",

"pm_password":"<PASSWORD>",

"pm_addr":"192.100.0.5"

}

]

}

Importe el fichero del 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.

Ejecute la introspección del nodo con el uso del UUID conocido del 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       |

Agregue los IP Addresses a custom-templates/layout.yml bajo OsdComputeIPs. En este caso, cuando usted substituye OSD-Compute-0 usted agrega ese direccionamiento al extremo de la lista para cada tipo:

OsdComputeIPs:

internal_api:

- 11.120.0.43

- 11.120.0.44

- 11.120.0.45

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

tenant:

- 11.117.0.43

- 11.117.0.44

- 11.117.0.45

- 11.117.0.43   << and here

storage:

- 11.118.0.43

- 11.118.0.44

- 11.118.0.45

- 11.118.0.43   << and here

storage_mgmt:

- 11.119.0.43

- 11.119.0.44

- 11.119.0.45

- 11.119.0.43   << and here

Ejecute el script de deploy.sh que fue utilizada previamente para desplegar la pila, para agregar el nuevo nodo del cálculo a la pila del nublar:

[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

Espere el estatus de la pila de OpenStack para ser COMPLETO:

[stack@director ~]$  openstack stack list

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

| ID                                   | Stack Name | Stack Status    | Creation Time        | Updated Time         |

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

| 5df68458-095d-43bd-a8c4-033e68ba79a0 | pod1       | UPDATE_COMPLETE | 2017-11-02T21:30:06Z | 2017-11-06T21:40:58Z |

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

Controle que el nuevo nodo del OSD-cálculo está en el estado activo:

[stack@director ~]$ source stackrc

[stack@director ~]$ nova list |grep osd-compute-3

| 0f2d88cd-d2b9-4f28-b2ca-13e305ad49ea | pod1-osd-compute-3    | ACTIVE | -          | Running     | ctlplane=192.200.0.117 |

[stack@director ~]$ source corerc

[stack@director ~]$ openstack hypervisor list |grep osd-compute-3

| 63 | pod1-osd-compute-3.localdomain    |

Registro en los nuevos procesos de Ceph del servidor y del control del OSD-cálculo. Inicialmente, el estatus estará en HEALTH_WARN como Ceph se recupera:

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

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_WARN

223 pgs backfill_wait

4 pgs backfilling

41 pgs degraded

227 pgs stuck unclean

41 pgs undersized

recovery 45229/1300136 objects degraded (3.479%)

recovery 525016/1300136 objects misplaced (40.382%)

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e986: 12 osds: 12 up, 12 in; 225 remapped pgs

flags sortbitwise,require_jewel_osds

pgmap v781746: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1553 GB used, 11840 GB / 13393 GB avail

45229/1300136 objects degraded (3.479%)

525016/1300136 objects misplaced (40.382%)

477 active+clean

186 active+remapped+wait_backfill

37 active+undersized+degraded+remapped+wait_backfill

4 active+undersized+degraded+remapped+backfilling

Pero después de un período breve (20 minutos), devoluciones de Ceph a un estado HEALTH_OK:

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

cluster eb2bb192-b1c9-11e6-9205-525400330666

health HEALTH_OK

monmap e1: 3 mons at {Pod1-controller-0=11.118.0.40:6789/0,Pod1-controller-1=11.118.0.41:6789/0,Pod1-controller-2=11.118.0.42:6789/0}

election epoch 58, quorum 0,1,2 Pod1-controller-0,Pod1-controller-1,Pod1-controller-2

osdmap e1398: 12 osds: 12 up, 12 in

flags sortbitwise,require_jewel_osds

pgmap v784311: 704 pgs, 6 pools, 533 GB data, 344 kobjects

1599 GB used, 11793 GB / 13393 GB avail

704 active+clean

client io 8168 kB/s wr, 0 op/s rd, 32 op/s wr

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

ID WEIGHT   TYPE NAME                         UP/DOWN REWEIGHT PRIMARY-AFFINITY

-1 13.07996 root default

-2        0     host pod1-osd-compute-0

-3  4.35999     host pod1-osd-compute-2

1  1.09000         osd.1                          up  1.00000          1.00000

4  1.09000         osd.4                          up  1.00000          1.00000

7  1.09000         osd.7                          up  1.00000          1.00000

10  1.09000         osd.10                         up  1.00000          1.00000

-4  4.35999     host pod1-osd-compute-1

2  1.09000         osd.2                          up  1.00000          1.00000

5  1.09000         osd.5                          up  1.00000          1.00000

8  1.09000         osd.8                          up  1.00000          1.00000

11  1.09000         osd.11                         up  1.00000          1.00000

-5  4.35999     host pod1-osd-compute-3

0  1.09000         osd.0                          up  1.00000          1.00000

3  1.09000         osd.3                          up  1.00000          1.00000

6  1.09000         osd.6                          up  1.00000          1.00000

9  1.09000         osd.9                          up  1.00000          1.00000

Configuraciones del reemplazo del servidor del poste

Después de agregar el servidor al nublar, refiera por favor al link abajo para aplicar las configuraciones que estaban previamente presentes en el servidor viejo:

Restablezca las VM

Encajone 1. nodos del OSD-cálculo que reciben los CF, salida, EM y UAS

Adición a la lista del agregado de Nova

Agregue el nodo del OSD-cálculo a los agregado-host y verifique si se ha agregado el host. En este caso, el nodo del OSD-cálculo se debe agregar los agregados al host de los CF y EM.

nova aggregate-add-host <Aggregate> <Host>

[stack@director ~]$ nova aggregate-add-host VNF2-CF-MGMT2 pod1-osd-compute-3.localdomain

[stack@director ~]$ nova aggregate-add-host VNF2-EM-MGMT2 pod1-osd-compute-3.localdomain

[stack@direcotr ~]$ nova aggregate-add-host POD1-AUTOIT   pod1-osd-compute-3.localdomain

nova aggregate-show <Aggregate>

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

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

[stack@director ~]$ nova aggregate-show POD1-AUTOITT

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@director ~]$ 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. La espera durante unos minutos y UAS deben 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 CONTRASEÑA core/< >). 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: < CONTRASEÑA >).

Encuentre el URL para guardar 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

Ejecútese 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 el 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.

El nodo del OSD-cálculo del caso 2. que recibe las Auto-TIC, Auto-despliega, EM y UAS

La recuperación de Auto-despliega la VM

De OSPD, si auto-despliegue la VM fue afectada pero todavía muestra ACTIVE/Running, usted necesitará suprimirlo primero. Si auto-despliegue no fue afectado, saltan a la recuperación de Auto-él la VM:

[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

Auto-despliegue una vez se suprime, la crean otra vez con el mismo direccionamiento del 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 fichero Autodeploy.cfg, el ISO y el archivo TAR del confd_backup de su servidor de reserva a la VM autodeploy y los ficheros del confdcdb del restore del archivo TAR de reserva:

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 el confd fuera cargado correctamente controlando transacciones anteriores. Ponga al día el autodeploy.cfg con un nuevo nombre del OSD-cálculo. Refiera el toSection - FinalStep: Configuración de AutoDeploy de la actualización:

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 las Auto-TIC VM

De OSPD, si auto-VM fue afectado pero aún las demostraciones como ACTIVE/Running, necesita ser suprimida. Si auto-no fue afectado, salte a la VM 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

Ejecútelo auto--vnf script del estacionamiento y reconstrúyalo auto-:

[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, auto-dirección IP es 10.1.2.8. Esto tardará algunos minutos para cargar:

[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 ficheros VNF system.cfg de OSPD Auto-despliegan el directorio a auto-él VM:

[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 del EM y UAS VM son lo mismo en ambos los casos. Refiera a la sección Case.1 para lo mismo.

Maneje el error de la recuperación salida

En caso de que salida no pueda comenzar la VM debido a un estado inesperado, Cisco recomienda que usted realiza 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 fijar el estado VM. Esta tarea de la recuperación tomará hasta cinco 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á ir hacer la recuperación manual de la VM afectada.

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

De AutoDeploy VM, corrija el auto-deploy.cfg y substituya el servidor viejo del OSD-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 Auto-despliegue los servicios 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

Activación de los Syslog

Para activar los Syslog para el servidor UCS, los componentes de Openstack y las VM recuperadas, siguen por favor las secciones

“Vuelva a permitir el Syslog para los componentes UCS y de Openstack” y “active el Syslog para el VNFs” en el link abajo: