Sustitución de OSD-Compute UCS 240M4 - CPAR
Contenido
Introducción
Este documento describe los pasos necesarios para sustituir un disco de almacenamiento de objetos (OSD) - servidor informático defectuoso en una configuración Ultra-M.
Este procedimiento se aplica a un entorno Openstack con la versión NEWTON en el que ESC no administra CPAR y CPAR se instala directamente en la máquina virtual (VM) implementada en Openstack.
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 Virtual Infrastructure Manager (VIM) para Ultra-M y consta de estos tipos de nodos:
- Informática
- OSD - Informática
- Controlador
- Plataforma OpenStack: Director (OSPD)
La arquitectura de alto nivel de Ultra-M y los componentes involucrados se ilustran en esta imagen:
Este documento está dirigido al personal de Cisco que está familiarizado con la plataforma Cisco Ultra-M y detalla los pasos necesarios para llevarse a cabo en OpenStack y Redhat Operating System (OS).
Abreviaturas
| MoP | Método de procedimiento |
| OSD | Discos de almacenamiento de objetos |
| OSPD | Director de plataforma OpenStack |
| 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 único universal |
Flujo de trabajo de MoP
Copia de seguridad
Antes de reemplazar un nodo Compute, es importante verificar el estado actual de su entorno Red Hat OpenStack Platform. Se recomienda que verifique el estado actual para evitar complicaciones cuando el proceso de reemplazo Compute está activado. Se puede lograr con este flujo de reemplazo.
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.
- Identifique las VM alojadas en el nodo de informática OSD.
- Identifique las VM alojadas en el servidor.
[stack@director ~]$ nova list --field name,host | grep osd-compute-0 | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |
Cierre de la aplicación CPAR
Paso 1. Abra cualquier cliente Secure Shell (SSH) conectado a la red y conéctese a la instancia CPAR.
Es importante no cerrar las 4 instancias AAA dentro de un sitio al mismo tiempo, hacerlo de una manera a una.
Paso 2. Para apagar la aplicación CPAR, ejecute el comando:
/opt/CSCOar/bin/arserver stop
Mensaje "Cisco Prime Access Registrar Server Agent shutdown complete". debe aparecer.
ERROR: You cannot shut down Cisco Prime Access Registrar while the
CLI is being used. Current list of running
CLI with process id is:
2903 /opt/CSCOar/bin/aregcmd –s
En este ejemplo, la ID de proceso resaltada 2903 debe terminar antes de que el CPAR pueda ser detenido. Si este es el caso, ejecute el comando para terminar este proceso:
kill -9 *process_id*
A continuación, repita el paso 1.
Paso 3. Para verificar que la aplicación CPAR fue efectivamente cerrada, ejecute el comando:
/opt/CSCOar/bin/arstatus
Estos mensajes deben aparecer:
Cisco Prime Access Registrar Server Agent not running Cisco Prime Access Registrar GUI not running
Tarea de instantánea de VM
Paso 1. Introduzca el sitio web de la interfaz gráfica de usuario de Horizonte correspondiente al sitio (ciudad) en el que se está trabajando.
Cuando accede a Horizonte, la pantalla observada es la que se muestra en esta imagen.
Paso 2. Navegue hasta Project > Instancias como se muestra en esta imagen.
Si el usuario utilizado fue CPAR, en este menú solo aparecen las 4 instancias AAA.
Paso 3. Cierre sólo una instancia a la vez y repita todo el proceso en este documento. Para apagar la máquina virtual, navegue hasta Acciones > Cerrar instancia como se muestra en la imagen y confirme su selección.
Paso 4. Valide que la instancia se cerró de hecho comprobando el estado = Apagar y el estado de energía = Apagar como se muestra en esta imagen.
Este paso finaliza el proceso de cierre del CPAR.
Instantánea de VM
Una vez que las máquinas virtuales CPAR están inactivas, las instantáneas pueden tomarse en paralelo ya que pertenecen a equipos independientes.
Los cuatro archivos QCOW2 se crean en paralelo.
Tome una instantánea de cada instancia de AAA. (25 minutos -1 hora) (25 minutos para las instancias que utilizaron una imagen de cola como fuente y 1 hora para las instancias que utilizan una imagen sin procesar como origen)
- Inicie sesión en la GUI de OpenStack de POD Horizon.
- Una vez iniciada la sesión, navegue hasta la sección Project > Compute > Instancias del menú superior y busque las instancias AAA como se muestra en esta imagen.
3. Haga clic en Crear instantánea para continuar con la creación de la instantánea (esto debe ejecutarse en la instancia AAA correspondiente) como se muestra en esta imagen.
4. Una vez que se ejecuta la instantánea, haga clic en Imágenes y verifique que todos terminen y no informen de problemas, como se muestra en esta imagen.
5. El siguiente paso es descargar la instantánea en un formato QCOW2 y transferirla a una entidad remota, en caso de que la OSPD se pierda durante este proceso. Para lograr esto, identifique la instantánea ejecutando el comando glance image-list en el nivel OSPD.
[root@elospd01 stack]# glance image-list +--------------------------------------+---------------------------+ | ID | Name | +--------------------------------------+---------------------------+ | 80f083cb-66f9-4fcf-8b8a-7d8965e47b1d | AAA-Temporary | | 22f8536b-3f3c-4bcc-ae1a-8f2ab0d8b950 | ELP1 cluman 10_09_2017 | | 70ef5911-208e-4cac-93e2-6fe9033db560 | ELP2 cluman 10_09_2017 | | e0b57fc9-e5c3-4b51-8b94-56cbccdf5401 | ESC-image | | 92dfe18c-df35-4aa9-8c52-9c663d3f839b | lgnaaa01-sept102017 | | 1461226b-4362-428b-bc90-0a98cbf33500 | tmobile-pcrf-13.1.1.iso | | 98275e15-37cf-4681-9bcc-d6ba18947d7b | tmobile-pcrf-13.1.1.qcow2 | +--------------------------------------+---------------------------+
6. Una vez que identifique la instantánea que se descargará (la marcada en verde), puede descargarla en un formato QCOW2 con el comando glance image-download como se muestra.
[root@elospd01 stack]# glance image-download 92dfe18c-df35-4aa9-8c52-9c663d3f839b --file /tmp/AAA-CPAR-LGNoct192017.qcow2 &
- El & envía el proceso al fondo. Se tarda algún tiempo en completar esta acción, una vez que se hace, la imagen se puede encontrar en el directorio /tmp.
- Al enviar el proceso a segundo plano, si se pierde la conectividad, también se detiene el proceso.
- Ejecute el comando disown -h para que en caso de que se pierda la conexión SSH, el proceso se ejecute y termine en el OSPD.
7. Una vez finalizado el proceso de descarga, es necesario ejecutar un proceso de compresión, ya que esa instantánea podría llenarse con ZEROES debido a procesos, tareas y archivos temporales manejados por el sistema operativo. El comando que se utilizará para la compresión de archivos es virt-sparsify.
[root@elospd01 stack]# virt-sparsify AAA-CPAR-LGNoct192017.qcow2 AAA-CPAR-LGNoct192017_compressed.qcow2
Este proceso puede tardar algún tiempo (entre 10 y 15 minutos). Una vez terminado, el archivo resultante es el que debe transferirse a una entidad externa como se especifica en el paso siguiente.
Para lograr esto, se requiere la verificación de la integridad del archivo, ejecute el siguiente comando y busque el atributo "corrupto" al final de su salida.
[root@wsospd01 tmp]# qemu-img info AAA-CPAR-LGNoct192017_compressed.qcow2 image: AAA-CPAR-LGNoct192017_compressed.qcow2 file format: qcow2 virtual size: 150G (161061273600 bytes) disk size: 18G cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false
- Para evitar un problema donde se pierde la OSPD, la instantánea creada recientemente en formato QCOW2 debe transferirse a una entidad externa. Antes de iniciar la transferencia de archivos, debe verificar si el destino tiene suficiente espacio disponible en disco, ejecute el comando df -kh para verificar el espacio de memoria. Un consejo es transferirla temporalmente al OSPD de otro sitio con el SFTP sftp root@x.x.x.x" donde x.x.x.x es la IP de un OSPD remoto. Para acelerar la transferencia, el destino se puede enviar a varios OSPD. De la misma manera, puede ejecutar el comando scp *name_of_the_file*.qcow2 root@ x.x.x.x:/tmp (donde x.x.x.x es la IP de un OSPD remoto) para transferir el archivo a otro OSPD.
- Identifique las VM alojadas en el nodo de informática OSD.
- Identifique las VM alojadas en el servidor.
[stack@director ~]$ nova list --field name,host | grep osd-compute-0 | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | pod2-stack-compute-4.localdomain |
- Verifique que CEPH tenga capacidad disponible para permitir que se elimine un único servidor OSD.
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph df GLOBAL: SIZE AVAIL RAW USED %RAW USED 13393G 11088G 2305G 17.21 POOLS: NAME ID USED %USED MAX AVAIL OBJECTS rbd 0 0 0 3635G 0 metrics 1 3452M 0.09 3635G 219421 images 2 138G 3.67 3635G 43127 backups 3 0 0 3635G 0 volumes 4 139G 3.70 3635G 36581 vms 5 490G 11.89 3635G 126247
- Verifique que el estado del árbol de osd esté activo en el servidor de osd-compute.
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY -1 13.07996 root default -2 4.35999 host pod2-stack-osd-compute-0 0 1.09000 osd.0 up 1.00000 1.00000 3 1.09000 osd.3 up 1.00000 1.00000 6 1.09000 osd.6 up 1.00000 1.00000 9 1.09000 osd.9 up 1.00000 1.00000 -3 4.35999 host pod2-stack-osd-compute-1 1 1.09000 osd.1 up 1.00000 1.00000 4 1.09000 osd.4 up 1.00000 1.00000 7 1.09000 osd.7 up 1.00000 1.00000 10 1.09000 osd.10 up 1.00000 1.00000 -4 4.35999 host pod2-stack-osd-compute-2 2 1.09000 osd.2 up 1.00000 1.00000 5 1.09000 osd.5 up 1.00000 1.00000 8 1.09000 osd.8 up 1.00000 1.00000 11 1.09000 osd.11 up 1.00000 1.00000
- Los procesos CEPH están activos en el servidor de osd-compute.
[heat-admin@pod2-stack-osd-compute-0 ~]$ systemctl list-units *ceph* UNIT LOAD ACTIVE SUB DESCRIPTION var-lib-ceph-osd-ceph\x2d0.mount loaded active mounted /var/lib/ceph/osd/ceph-0 var-lib-ceph-osd-ceph\x2d3.mount loaded active mounted /var/lib/ceph/osd/ceph-3 var-lib-ceph-osd-ceph\x2d6.mount loaded active mounted /var/lib/ceph/osd/ceph-6 var-lib-ceph-osd-ceph\x2d9.mount loaded active mounted /var/lib/ceph/osd/ceph-9 ceph-osd@0.service loaded active running Ceph object storage daemon ceph-osd@3.service loaded active running Ceph object storage daemon ceph-osd@6.service loaded active running Ceph object storage daemon ceph-osd@9.service loaded active running Ceph object storage daemon system-ceph\x2ddisk.slice loaded active active system-ceph\x2ddisk.slice system-ceph\x2dosd.slice loaded active active system-ceph\x2dosd.slice ceph-mon.target loaded active active ceph target allowing to start/stop all ceph-mon@.service instances at once ceph-osd.target loaded active active ceph target allowing to start/stop all ceph-osd@.service instances at once ceph-radosgw.target loaded active active ceph target allowing to start/stop all ceph-radosgw@.service instances at once ceph.target loaded active active ceph target allowing to start/stop all ceph*@.service instances at once LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type.
14 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'.
- Desactive y detenga cada instancia de la ceph y quite cada instancia de osd y desmonte el directorio. Repita el procedimiento para cada instancia de la cepa.
[heat-admin@pod2-stack-osd-compute-0 ~]# systemctl disable ceph-osd@0 [heat-admin@pod2-stack-osd-compute-0 ~]# systemctl stop ceph-osd@0 [heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd out 0
- marcado como osd.0.
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd crush remove osd.0
- id de elemento eliminado 0 name 'osd.0' del mapa de aplastamiento
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph auth del osd.0
- actualizado
[heat-admin@pod2-stack-osd-compute-0 ~]# ceph osd rm 0
- osd.0 eliminado
[heat-admin@pod2-stack-osd-compute-0 ~]# umount /var/lib/ceph.osd/ceph-0 [heat-admin@pod2-stack-osd-compute-0 ~]# rm -rf /var/lib/ceph.osd/ceph-0
O bien,
- Se puede utilizar la secuencia de comandos Clean.sh para esta tarea a la vez.
[heat-admin@pod2-stack-osd-compute-0 ~]$ sudo ls /var/lib/ceph/osd ceph-0 ceph-3 ceph-6 ceph-9
[heat-admin@pod2-stack-osd-compute-0 ~]$ /bin/sh clean.sh [heat-admin@pod2-stack-osd-compute-0 ~]$ cat clean.sh
#!/bin/sh set -x CEPH=`sudo ls /var/lib/ceph/osd` for c in $CEPH do i=`echo $c |cut -d'-' -f2` sudo systemctl disable ceph-osd@$i || (echo "error rc:$?"; exit 1) sleep 2 sudo systemctl stop ceph-osd@$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd out $i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd crush remove osd.$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph auth del osd.$i || (echo "error rc:$?"; exit 1) sleep 2 sudo ceph osd rm $i || (echo "error rc:$?"; exit 1) sleep 2 sudo umount /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1) sleep 2 sudo rm -rf /var/lib/ceph/osd/$c || (echo "error rc:$?"; exit 1) sleep 2 done sudo ceph osd tree
Después de que se hayan migrado/eliminado todos los procesos OSD, el nodo se puede quitar de la nube excesiva.
Apagado Graceful
- Apagar el nodo
- Para apagar la instancia: nova stop <INSTANCE_NAME>
- Puede ver el nombre de la instancia con el estado apagado.
[stack@director ~]$ nova stop aaa2-21 Request to stop server aaa2-21 has been accepted. [stack@director ~]$ nova list +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+ | 46b4b9eb-a1a6-425d-b886-a0ba760e6114 | AAA-CPAR-testing-instance | ACTIVE | - | Running | tb1-mgmt=172.16.181.14, 10.225.247.233; radius-routable1=10.160.132.245; diameter-routable1=10.160.132.231 | | 3bc14173-876b-4d56-88e7-b890d67a4122 | aaa2-21 | SHUTOFF | - | Shutdown | diameter-routable1=10.160.132.230; radius-routable1=10.160.132.248; tb1-mgmt=172.16.181.7, 10.225.247.234 | | f404f6ad-34c8-4a5f-a757-14c8ed7fa30e | aaa21june | ACTIVE | - | Running | diameter-routable1=10.160.132.233; radius-routable1=10.160.132.244; tb1-mgmt=172.16.181.10 | +--------------------------------------+---------------------------+---------+------------+-------------+------------------------------------------------------------------------------------------------------------+
- Eliminación de nodos
Los pasos mencionados en esta sección son comunes independientemente de las VM alojadas en el nodo informático.
Elimine OSD-Compute Node de la lista de servicios.
- Elimine el servicio informático de la lista de servicios:
[stack@director ~]$ openstack compute service list |grep osd-compute | 135 | nova-compute | pod2-stack-osd-compute-1.localdomain | AZ-esc2 | enabled | up | 2018-06-22T11:05:22.000000 | | 150 | nova-compute | pod2-stack-osd-compute-2.localdomain | nova | enabled | up | 2018-06-22T11:05:17.000000 | | 153 | nova-compute | pod2-stack-osd-compute-0.localdomain | AZ-esc1 | enabled | up | 2018-06-22T11:05:25.000000 |
- openstack cómputo service delete <ID>
[stack@director ~]$ openstack compute service delete 150
Eliminar agentes neutrales
- Elimine el agente de neutrones asociado antiguo y abra el agente de vswitch para el servidor de equipos:
[stack@director ~]$ openstack network agent list | grep osd-compute-0 | eaecff95-b163-4cde-a99d-90bd26682b22 | Open vSwitch agent | pod2-stack-osd-compute-0.localdomain | None | True | UP | neutron-openvswitch-agent |
- openstack network agent delete <ID>
[stack@director ~]$ openstack network agent delete eaecff95-b163-4cde-a99d-90bd26682b22
Eliminar de base de datos irónica
- Elimine un nodo de la base de datos irónica y verifíquelo:
[root@director ~]# nova list | grep osd-compute-0 | 6810c884-1cb9-4321-9a07-192443920f1f | pod2-stack-osd-compute-0 | ACTIVE | - | Running | ctlplane=192.200.0.109 | [root@al03-pod2-ospd ~]$ nova delete 6810c884-1cb9-4321-9a07-192443920f1f
- nova show < compute -node> | hipervisor grep
[root@director ~]# source stackrc [root@director ~]# nova show pod2-stack-osd-compute-0 | grep hypervisor | OS-EXT-SRV-ATTR:hypervisor_hostname | 05ceb513-e159-417d-a6d6-cbbcc4b167d7
- ironic node-delete <ID>
[stack@director ~]$ ironic node-delete 05ceb513-e159-417d-a6d6-cbbcc4b167d7 [stack@director ~]$ ironic node-list
El nodo eliminado no debe aparecer ahora en la lista de nodos irónica.
Eliminar de Overcloud
- Cree un archivo de script denominado delete_node.sh con el contenido como se muestra. 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-name> <UUID>
[stack@director ~]$ source stackrc [stack@director ~]$ /bin/sh delete_node.sh + openstack overcloud node delete --templates -e /usr/share/openstack-tripleo-heat-templates/environments/puppet-pacemaker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /home/stack/custom-templates/network.yaml -e /home/stack/custom-templates/ceph.yaml -e /home/stack/custom-templates/compute.yaml -e /home/stack/custom-templates/layout.yaml -e /home/stack/custom-templates/layout.yaml --stack pod2-stack 7439ea6c-3a88-47c2-9ff5-0a4f24647444 Deleting the following nodes from stack pod2-stack: - 7439ea6c-3a88-47c2-9ff5-0a4f24647444 Started Mistral Workflow. Execution ID: 4ab4508a-c1d5-4e48-9b95-ad9a5baa20ae real 0m52.078s user 0m0.383s sys 0m0.086s
- 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 | pod2-stack | UPDATE_COMPLETE | 2018-05-08T21:30:06Z | 2018-05-08T20:42:48Z | +--------------------------------------+------------+-----------------+----------------------+----------------------+
Instalar 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
- Después de la instalación del servidor, inserte los discos duros en las ranuras respectivas como el servidor antiguo.
- 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
- Verifique el estado de las unidades físicas. Debe ser Unconfigured Good:
Vaya a Storage > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Physical Drive Info como se muestra en esta imagen.
- Cree una unidad virtual desde las unidades físicas con RAID Nivel 1:
Vaya a Almacenamiento > Cisco 12G SAS Modular Raid Controller (SLOT-HBA) > Información del controlador > Crear unidad virtual desde unidades físicas no usadas como se muestra en esta imagen.
- Seleccione el VD y configure Set as Boot Drive como se muestra en la imagen.
- Habilitar IPMI sobre LAN:
Vaya a Admin > Communication Services > Communication Services como se muestra en la imagen.
- Desactivar hiperHiperhilado:
Vaya a Compute > BIOS > Configure BIOS > Advanced > Processor Configuration como se muestra en la imagen.
- Al igual que BOOTOS VD creado con las unidades físicas 1 y 2, cree cuatro unidades virtuales más como:
JOURNAL > From physical drive number 3 OSD1 > From physical drive number 7 OSD2 > From physical drive number 8 OSD3 > From physical drive number 9 OSD4 > From physical drive number 10
- Al final, las unidades físicas y virtuales deben ser similares a las que se muestran en las imágenes.
Agregar un nuevo nodo de informática OSD a la nube excesiva
Los pasos mencionados en esta sección son comunes independientemente de la VM alojada por el nodo informático.
- Agregue el servidor Compute 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 fue osd-compute-17, por lo tanto, creó osd-compute-18 en el caso del sistema 2-vnf.
[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 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.
- Ejecute introspección de nodo con el uso de 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 |
- Agregue las direcciones IP a custom-templates/layout.yml en Osd Compute IPs. En este caso, al reemplazar osd-compute-0, agrega esa dirección al final de la lista para cada tipo
OsdComputeIP:
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 Deploy.sh que se utilizó anteriormente para implementar la pila, para agregar el nuevo nodo de cálculo a la pila de nube excesiva:
[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 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 | +--------------------------------------+------------+-----------------+----------------------+----------------------+
- Verifique que el nuevo nodo de cálculo esté en 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 |
- Inicie sesión en el nuevo servidor de cómputo y verifique los procesos de recepción. Inicialmente, el estado se encuentra en HEALTH_WARN mientras la 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 corto (20 minutos), CEPH regresa 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
Restaurar VM
Recuperación de instancias con Snapshot
Es posible volver a implementar la instancia anterior con la instantánea tomada en pasos anteriores.
Paso 1. (Opcional) Si no hay ninguna instantánea de VM anterior disponible, conéctese al nodo OSPD donde se envió la copia de seguridad y SFTP la copia de seguridad de vuelta a su nodo OSPD original. El uso de sftp root@x.x.x.xwhere x.x.x.x es la IP de un OSPD original. Guarde el archivo de instantánea en el directorio /tmp.
Paso 2. Conéctese al nodo OSPD donde se reimplementa la instancia.
Utilice las variables de entorno con este comando:
# source /home/stack/pod1-stackrc-Core-CPAR
Paso 3. Para utilizar la instantánea como una imagen, es necesario cargarla en el horizonte como tal. Ejecute el siguiente comando para hacerlo.
#glance image-create -- AAA-CPAR-Date-snapshot.qcow2 --container-format bare --disk-format qcow2 --name AAA-CPAR-Date-snapshot
El proceso se puede ver en el horizonte como se muestra en esta imagen.
Paso 4. En Horizon, navegue hasta Project > Instancias y haga clic en Lauch Instance como se muestra en esta imagen.
Paso 5. Ingrese el nombre de la instancia y elija la zona de disponibilidad como se muestra en esta imagen.
Paso 6. En la ficha Source, elija la imagen para crear la instancia. En el menú Seleccionar origen de arranque, seleccione imagen, se muestra una lista de imágenes, elija la que se cargó previamente haciendo clic en su + y como se muestra en esta imagen.
Paso 7. En la pestaña Sabor, elija el sabor AAA haciendo clic en el símbolo +, como se muestra en esta imagen.
Paso 8. Por último, navegue hasta la pestaña Red y elija las redes que necesita la instancia haciendo clic en el + signo+. Para este caso, seleccione diámetro-soutable1, radius-routable1 y tb1-mgmt como se muestra en esta imagen.
Paso 9. Por último, haga clic en Iniciar instancia para crearla. El progreso se puede monitorear en Horizon como se muestra en esta imagen.
Después de unos minutos, la instancia se implementará completamente y estará lista para su uso.
Creación y asignación de direcciones IP flotantes
Una dirección IP flotante es una dirección enrutable, lo que significa que se puede alcanzar desde el exterior de la arquitectura Ultra M/Openstack, y es capaz de comunicarse con otros nodos desde la red.
Paso 1. En el menú superior Horizonte, navegue hasta Admin > Floating IPs.
Paso 2. Haga clic en Asignar IP al proyecto.
Paso 3. En la ventana Asignar IP Flotante , seleccione el Pool del que pertenece la nueva IP flotante, el Proyecto donde se va a asignar y la nueva Dirección IP Flotante misma.
Por ejemplo:
Paso 4. Haga clic en Asignar IP flotante.
Paso 5. En el menú superior Horizonte, vaya a Proyecto > Instancias.
Paso 6. En la columna Acción, haga clic en la flecha que apunta hacia abajo en el botón Crear instantánea, se debe mostrar un menú. Seleccione la opción Asociar IP flotante.
Paso 7. Seleccione la dirección IP flotante correspondiente que se utilizará en el campo IP Address, y elija la interfaz de administración correspondiente (eth0) de la nueva instancia donde se va a asignar esta IP flotante en el puerto que se va a asociar. Consulte la siguiente imagen como ejemplo de este procedimiento.
Paso 8. Por último, haga clic en Asociar.
Habilitar SSH
Paso 1. En el menú superior Horizonte, vaya a Proyecto > Instancias.
Paso 2. Haga clic en el nombre de la instancia/VM que se creó en la sección Almuerzo de una nueva instancia.
Paso 3. Haga clic en Consola. Esto mostrará la CLI de la máquina virtual.
Paso 4. Una vez que se muestre la CLI, introduzca las credenciales de inicio de sesión correctas:
Nombre de usuario: raíz
Contraseña cisco123 como se muestra en esta imagen.
Paso 5. En la CLI, ejecute el comando vi /etc/ssh/sshd_config para editar la configuración ssh.
Paso 6. Una vez abierto el archivo de configuración de SSH, presione I para editar el archivo. A continuación, busque la sección mostrada aquí y cambie la primera línea de PasswordAuthentication no a PasswordAuthentication yes.
Paso 7. Presione ESC e ingrese :wq! para guardar los cambios del archivo sshd_config.
Paso 8. Ejecute el comando service sshd restart.
Paso 9. Para probar que los cambios de configuración de SSH se han aplicado correctamente, abra cualquier cliente SSH e intente establecer una conexión segura remota usando la IP flotante asignada a la instancia (es decir, 10.145.0.249) y la raíz del usuario.
Establecer sesión SSH
Paso 1. Abra una sesión SSH con la dirección IP de la VM/servidor correspondiente donde se instala la aplicación, como se muestra en esta imagen.
Inicio de instancia de CPAR
Siga estos pasos, una vez que la actividad se haya completado y los servicios CPAR puedan restablecerse en el Sitio que se cerró.
Paso 1. Vuelva a iniciar sesión en Horizon, navegue hasta Project > Instance > Start Instance.
Paso 2. Verifique que el estado de la instancia sea Activo y que el estado de energía esté En ejecución como se muestra en esta imagen.
Comprobación de estado posterior a la actividad
Paso 1. Ejecute el comando /opt/CSCOar/bin/arstatus a nivel del sistema operativo:
[root@wscaaa04 ~]# /opt/CSCOar/bin/arstatus Cisco Prime AR RADIUS server running (pid: 24834) Cisco Prime AR Server Agent running (pid: 24821) Cisco Prime AR MCD lock manager running (pid: 24824) Cisco Prime AR MCD server running (pid: 24833) Cisco Prime AR GUI running (pid: 24836) SNMP Master Agent running (pid: 24835) [root@wscaaa04 ~]#
Paso 2. Ejecute el comando /opt/CSCOar/bin/aregcmd en el nivel del sistema operativo e ingrese las credenciales de administración. Verifique que CPAr Health sea 10 de 10 y que salga de CPAR CLI.
[root@aaa02 logs]# /opt/CSCOar/bin/aregcmd
Cisco Prime Access Registrar 7.3.0.1 Configuration Utility
Copyright (C) 1995-2017 by Cisco Systems, Inc. All rights reserved.
Cluster:
User: admin
Passphrase:
Logging in to localhost
[ //localhost ]
LicenseInfo = PAR-NG-TPS 7.2(100TPS:)
PAR-ADD-TPS 7.2(2000TPS:)
PAR-RDDR-TRX 7.2()
PAR-HSS 7.2()
Radius/
Administrators/
Server 'Radius' is Running, its health is 10 out of 10
--> exit
Paso 3. Ejecute el comando netstat | diámetro grep y verifique que se hayan establecido todas las conexiones DRA.
El resultado mencionado aquí es para un entorno en el que se esperan links Diámetro. Si se muestran menos enlaces, esto representa una desconexión del DRA que se debe analizar.
[root@aa02 logs]# netstat | grep diameter tcp 0 0 aaa02.aaa.epc.:77 mp1.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:36 tsa6.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:47 mp2.dra01.d:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:07 tsa5.dra01:diameter ESTABLISHED tcp 0 0 aaa02.aaa.epc.:08 np2.dra01.d:diameter ESTABLISHED
Paso 4. Compruebe que el registro de TPS muestra las solicitudes que está procesando el CPAR. Los valores resaltados representan el TPS y son a los que debe prestar atención.
El valor de TPS no debe ser superior a 1500.
[root@wscaaa04 ~]# tail -f /opt/CSCOar/logs/tps-11-21-2017.csv 11-21-2017,23:57:35,263,0 11-21-2017,23:57:50,237,0 11-21-2017,23:58:05,237,0 11-21-2017,23:58:20,257,0 11-21-2017,23:58:35,254,0 11-21-2017,23:58:50,248,0 11-21-2017,23:59:05,272,0 11-21-2017,23:59:20,243,0 11-21-2017,23:59:35,244,0 11-21-2017,23:59:50,233,0
Paso 5. Busque cualquier mensaje de "error" o "alarma" en name_radius_1_log.
[root@aaa02 logs]# grep -E "error|alarm" name_radius_1_log
Paso 6. Para verificar la cantidad de memoria que utilizó el proceso CPAR, ejecute el comando:
top | grep radius
[root@sfraaa02 ~]# top | grep radius 27008 root 20 0 20.228g 2.413g 11408 S 128.3 7.7 1165:41 radius
Este valor resaltado debe ser inferior a 7 Gb, que es el máximo permitido en el nivel de aplicación.
Comentarios