Netbackup para OpenStack

Introducción

Gracias a Netbackup para OpenStack vamos a poder proteger las cargas que se ejecutan en este entorno mediante una consola que se integra con las herramientas nativas y que va a permitir crear políticas para definir el nivel de protección deseado.

Este agente captura instantáneas de las cargas de trabajo (aplicaciones, sistemas operativos, redes, configuraciones, datos y metadatos) de forma completa o incremental. Se almacenan en un Universal Share de MSDP y posteriormente se pueden duplicar a cualquier otro repositorio de Netbackup.

Gracias a la integración con horizon, se tiene una consola multitenant que permite delegar la administración de las copias de seguridad a los propietarios de las cargas de trabajo.

En cuanto a la arquitectura, Netbackup añade varios componentes al entorno de OpenStack:

Estos componentes van a ser similares a los que ya incorpora OpenStack (Nova, Cinder, Glance, etc…) Los componentes de Netbackup son los siguientes:

El componente principal (NBOSVM) se despliega con una imagen de máquina virtual qcow2. Es necesario al menos una instancia aunque ser recomiendan tres para poder formar un clúster y tener alta disponibilidad frente a fallos. Este servidor va a orquestar todos los trabajos interactuando con OpenStack y con la infraestructura de copias de seguridad de Netbackup.

Una API para gestionar los datamover (NBOSDMAPI), es un módulo python que se despliega en los nodos donde se ejecuta el servicio nova-api.

Un datamover (NBOSDM), es también un módulo python que se despliega en los nodos de cómputo y que realizará movimiento de datos.

Un plugin para OpenStack horizon que se instala en todos los nodos que ejecutan el servicio horizon.

El repositorio de copias de seguridad será un Universal Share que permite almacenar los datos en el MSDP utilizando NFS.

A nivel de comunicaciones se van a utilizar los siguientes servicios/puertos:

Configuración

Instalación de NBOSVM

Este componente se tiene que desplegar en un servidor KVM fuera de la infraestuctura de OpenStack y tiene los siguientes requisitos:

• 8 vcpu
• 24 GB de RAM
• 40 GB de disco (se proporciona la imagen ya creada)

Este componente se ha testeado y verificado con la siguiente configuraicón:

• Red Hat Enterprise Linux 8.9
• Virsh, libvirt 2.0.0 y superior
• QEMU 2.0.0 y superior
• qemu-img 2.6.0 y superior

La configuración de la VM se hará utilizando cloud-init, para ello tendremos que crear 2 ficheros con la configuración y generar una imagen ISO. Los ficheros son los siguientes

# cat meta-data
instance-id: nbosvm
network-interfaces: |
   auto eth0
   iface eth0 inet static
   address 10.0.0.251
   netmask 255.255.255.0
   gateway 10.0.0.1
   dns-nameservers 10.0.0.1

Es importante que el instance-id coincida con el nombre de la máquina virtual en virsh.

#cat user-data
#cloud-config
chpasswd:
  list: |
    root:password1
    stack:password2
  expire: False

Crearemos una imagen iso con el siguiente comando:

# genisoimage  -output nbos-firstboot-config.iso -volid cidata -joliet -rock user-data meta-data

A continuación, descomprimiremos el fichero descargado de veritas con el disco qcow2 (por ejemplo en la version 10.5.0.1 tiene el nombre nbos-appliance-10.5.0.1.1005.qcow2.txz) y desplegaremos la máquina virtual con el siguiente comando (personalizandolo para nuestro entorno)

virt-install -n nbosvm  --memory 24576 --vcpus 8 --os-type linux --disk nbos-appliance-10.5.0.1.1005.qcow2,device=disk,bus=virtio,size=40 --network bridge=virbr0,model=virtio --network bridge=virbr1,model=virtio --graphics none --import --disk path=nbos-firstboot-config.iso,device=cdrom

Una vez desplegada la máquna, es importante desactivar que se configure en cada arranque, para ello ejecutaremos el siguiente comando:

touch /etc/cloud/cloud-init.disabled

Instalación de componentes de OpenStack

En este ejemplo, se hace la instalación sobre RHOSP 17.1. Lo primero será descargar el fichero con los scripts (nbos-cfg-scripts-10.5.0.1.1005.tar.gz en el caso de la 10.5.0.1):

cd /home/stack
gunzip /home/stack/nbos-cfg-scripts-10.5.1029.tar.gz
cd nbos-cfg-scripts/
tar xvf ../nbos-cfg-scripts-10.5.1029.tar
cd redhat-director-scripts/rhosp17.1/

Añadiremos los modulos de puppet

/home/stack/nbos-cfg-scripts/redhat-director-scripts/rhosp17.1/scripts
(undercloud) [stack@undercloud scripts]$ ./upload_puppet_module.sh
Creating tarball...
Tarball created.
renamed '/tmp/puppet-modules-wI6rZdP/puppet-modules.tar.gz' -> '/var/lib/tripleo/artifacts/overcloud-artifacts/puppet-modules.tar.gz'
Creating heat environment file: /home/stack/.tripleo/environments/puppet-modules-url.yaml

Añadiremos los servicios para Netbackup, en el fichero

/usr/share/openstack-tripleo-heat-templates/roles_data.yaml

Hay que añadirlos al final de la lista de servicios para cada tipo de nodo, en el nodo de control añadiremos nbosdmapi y en el de computo nbosdm:

…..
- name: Controller
……
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::nbosdmapi
….
- name: Compute
….
    - OS::TripleO::Services::OVNMetadataAgent
    - OS::TripleO::Services::nbosdm

El paso siguiente es subir las imagenes para los contenedores al registro que estemos usando, que se puede comprobar con el siguiente comando:

(undercloud) [stack@undercloud nbos]$ openstack tripleo container image list | grep keystone
| docker://undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-keystone:17.1                   |
| docker://undercloud.ctlplane.localdomain:8787/rhosp-rhel9/openstack-barbican-keystone-listener:17.1 |

En nuestro caso es undercloud.ctlplane.localdomain.

Descargaremos las imagenes (en este caso el fichero nbos-rhosp17.1-10.5.0.1.1005.tar.gz), las descomprimiremos y las subiremos al repositorio con el script prepare_nbos_images.sh:

mkdir /home/stack/nbos
tar xvzf nbos-rhosp17.1-10.5.0.1.1005.tar.gz

cd /home/stack/nbos-cfg-scripts/redhat-director-scripts/rhosp17.1/scripts

(undercloud) [stack@undercloud scripts]$ sudo ./prepare_nbos_images.sh undercloud.ctlplane.localdomain 10.5.0.1.1005-rhosp17.1 /home/stack/nbos/nbos-rhosp17.1-10.5.0.1.1005
Getting image source signatures
Copying blob 524c7feb48af done
Copying blob aa27caa5be94 done
Copying blob 6eec554ff4bd done
Copying blob 54aefed4940d done
Copying blob fc25fcc702fb done
Copying blob b5106c59b1e9 skipped: already exists
Copying config 4768bb1cb7 done
Writing manifest to image destination
Storing signatures
Loaded image: localhost/nbosdm:10.5.0.1.1005-rhosp17.1
Getting image source signatures
Copying blob 5b5cbd918f70 done
Copying blob 54aefed4940d skipped: already exists
Copying blob b5106c59b1e9 skipped: already exists
Copying blob 6eec554ff4bd skipped: already exists
Copying blob 524c7feb48af skipped: already exists
Copying config 8cc8337144 done
Writing manifest to image destination
Storing signatures
Loaded image: localhost/nbosdmapi:10.5.0.1.1005-rhosp17.1
Getting image source signatures
Copying blob 524c7feb48af skipped: already exists
Copying blob 54aefed4940d skipped: already exists
Copying blob 80fc1b83676e done
Copying blob 3ed9b07184fc done
Copying blob b5106c59b1e9 skipped: already exists
Copying config f40f6ed752 done
Writing manifest to image destination
Storing signatures
Loaded image: localhost/nbos-horizon-plugin:10.5.0.1.1005-rhosp17.1
..............

y por último editaremos el fichero /home/stack/nbos-cfg-scripts/redhat-director-scripts/rhosp17.1/environments/nbos_env.yml y personalizaremos la contraseña en el campo nbosdmPassword. Desplegaremos la configuración con el comando adaptado a nuestro entorno (revisar la documentación), como este por ejemplo:

openstack overcloud deploy \
--log-file overcloud_deployment.log \
--templates /usr/share/openstack-tripleo-heat-templates/ \
--stack overcloud \
-n /home/stack/templates/network_data.yaml \
-r /home/stack/templates/roles_data.yaml \
-e /home/stack/templates/overcloud-baremetal-deployed.yaml \
-e /home/stack/templates/overcloud-networks-deployed.yaml \
-e /home/stack/templates/overcloud-vip-deployed.yaml \
-e /home/stack/containers-prepare-parameter.yaml \
-e /home/stack/templates/overcloud-images.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/enable-swap.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dvr-ha.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/low-memory-usage.yaml \
-e /home/stack/templates/custom-network-configuration.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/disable-telemetry.yaml \
-e /home/stack/templates/custom-overcloud.yaml \
-e /home/stack/nbos-cfg-scripts/redhat-director-scripts/rhosp17.1/environments/nbos_env.yaml

Si todo ha ido bien, tras el despliegue veremos en los nodos de control los contenedores con el plugin de horizon y el nbosdmapi:

[tripleo-admin@overcloud-controller0 ~]$ sudo podman ps | grep nbos
9dd94b438a64  undercloud.ctlplane.localdomain:8787/nbos-horizon-plugin:10.5.0.1.1005-rhosp17.1    kolla_start           2 days ago     Up 2 hours (healthy)              horizon
1d511a618514  undercloud.ctlplane.localdomain:8787/nbosdmapi:10.5.0.1.1005-rhosp17.1              kolla_start           45 hours ago   Up 2 hours                        nbosdmapi

Y en los nodos de computo el nbosdm:

[tripleo-admin@overcloud-compute0 ~]$ sudo podman ps | grep nbos
1c55dc33da13  undercloud.ctlplane.localdomain:8787/nbosdm:10.5.0.1.1005-rhosp17.1                         kolla_start           46 hours ago  Up 3 hours                        nbosdm

Configuración NBOSVM

Para registrar nuestro servidor NBOSVM en nuestra infraestructura, necesitaremos crear una cuenta de servicio. Para ello, con la clave api de un usuario de Netbackup que tenga el rol de «Default Security Administrator» ejecutaremos el siguiente comando:

curl --insecure --location --request POST  \
  'https://rhosp-mas01.epereira-dom01.local:1556/netbackup/security/service-principal-configs' \
  -H 'accept: application/vnd.netbackup+json;version=11.0' \
  -H 'Content-Type: application/vnd.netbackup+json;version=11.0' \
  -H 'Authorization: CLAVE_API_USUARIO_ROL_DEFAULT_SECURITY' \
  -d '{
  "data": {
    "type": "servicePrincipalConfiguration",
    "attributes": {
      "servicePrincipalId": "Service_Principal_NBOSVM",
      "servicePrincipalType": "OPENSTACK",
      "servicePrincipalApiKeyExpireAfterDays": "P365D",
      "isSecurityAdmin": true,
      "accessDefinitions": [
          
        {
          "namespace": "|SECURITY|USERS|API-KEYS|",
          "operations": [
 
            "|OPERATIONS|VIEW|"
          ]
        },
        {
          "namespace": "|SECURITY|SERVICE-PRINCIPAL|",
          "operations": [
 
            "|OPERATIONS|VIEW|"
          ]
        },
        {
          "namespace": "|ASSETS|OPENSTACK|",
          "operations": [
            "|OPERATIONS|ADD|",
            "|OPERATIONS|VIEW|",
             "|OPERATIONS|UPDATE|",
            "|OPERATIONS|ASSETS|OPENSTACK|RESTORE_ORIGINAL|",
            "|OPERATIONS|ASSETS|OPENSTACK|RESTORE_ALTERNATE|",
            "|OPERATIONS|ASSETS|OPENSTACK|PROTECT|"
          ]
        },
        {
          "namespace": "|PROTECTION|PROTECTION_PLAN|",
          "operations": [
            "|OPERATIONS|VIEW|",
            "|OPERATIONS|PROTECTION|PROTECTION_PLAN|SUBSCRIBE|"
          ]
        },
        {
          "namespace": "|PROTECTION|POLICIES|",
          "operations": [
            "|OPERATIONS|PROTECTION|POLICIES|MANUAL-BACKUP|",
            "|OPERATIONS|VIEW|"
          ]
        },
        {
          "namespace": "|CREDENTIALS|",
          "operations": [
 
            "|OPERATIONS|ADD|",
            "|OPERATIONS|UPDATE|",
            "|OPERATIONS|DELETE|"
          ]
        },
        {
          "namespace": "|MANAGE|NBOSVM-SERVER|",
          "operations": [
            "|OPERATIONS|ADD|",
            "|OPERATIONS|UPDATE|",
             "|OPERATIONS|DELETE|"
          ]
        },
        {
          "namespace": "|MANAGE|JOBS|",
          "operations": [
            "|OPERATIONS|ADD|",
            "|OPERATIONS|VIEW|"
          ]
        },
        {
          "namespace": "|STORAGE|STORAGE-SERVERS|",
          "operations": [
            "|OPERATIONS|VIEW|"
          ]
        },
        {
          "namespace": "|STORAGE|STORAGE-SERVERS|UNIVERSAL-SHARES|",
          "operations": [
            "|OPERATIONS|VIEW|"
          ]
        },
        {
           "namespace": "|MANAGE|IMAGES|",
           "operations": [
             "|OPERATIONS|VIEW|"
          ]
        }
      ]
    }
  }
}'

Este comando nos devolverá una cuenta de servicio (Service_Principal_NBOSVM) y una apiKey que tendremos que guardar para registrar nuestra máquina NBOSVM.

Para hacer esta configuración, entraremos con un navegador a la dirección ip que le hemos dado (fichero meta-data). El usuario por defecto es admin y la contraseña por defecto es password, nos obliga a cambiarla al hacer login. Veremos un asistente donde meteremos los datos de nuestro entorno para hacer el registro:

Una vez rellenos los datos pulsaremos el botón «submit» para que se lance la configuración:

Configuración de copias de seguridad

Una vez realizada la configuración, será necesario crear un protection plan en Netbackup de tipo OpenStack:

Crearemos una planificación donde seleccionaremos la frecuencia, y la retención para los snapshots y para el destino final:

Elegiremos el destino de backup:

Será necesario introducir un Universal Share como almacenamiento intermedio:

Veremos en la pestaña permisos la cuenta de servicio que hemos creado:

Una vez creado el protection plan, iremos a la consola de horizon, en la pestaña de administración veremos una pestaña «NBOS Backup Admin» donde podremos consultar información de nuestra infraestructura desplegada:

En esta consola revisaremos que en «Nodes» sale nuestro nodo de Netbackup para OpenStack desplegado:

Así como los datamover:

En la pestaña «Protection Plan» veremos los planes de protección que hemos creado, y podremos suscribirlos a los proyectos existentes:

Una vez que hemos asociado el plan de protección al proyecto, desde él podremos elegir las máquinas que queremos proteger (pestaña NBOS Backups -> Protection). Primero le daremos un nombre:

Posteriormente seleccionaremos las instancias a proteger:

Y el plan de protección que queremos utilizar:

Y podremos lanzar si queremos copias de seguridad bajo demanda:

Estas copias de seguridad lanzarán varios trabajos en nuestro primary, uno primer trabajo para realizar los snapshots (que tendrán una retención inferior) y un repositorio de Netbackup para almacenar las copias durante un mayor plazo (backup from snapshot):

Para restaurar las copias de seguridad, iremos a la pestaña protection, y entrando en el plan de protección que hemos creado veremos los puntos de recuperación para elegir de cual queremos recuperarlo. Si es reciente podremos elegir recuperar desde el snapshot o repositorio de Netbackup:

Podremos elegir restaurar nuestra máquina virtual con otro nombre seleccionando «selective restore» del desplegable:

Será posible cambiar la configuración de red:

Así como cambiar el nombre para hacer la restauración, el tamaño y otras opciones:

Por último se lanzará la restauración de la máquina virtual:

De esta forma podremos proteger las cargas de OpenStack de forma eficiente para poder cumplir nuestros RPOs y RTOs aprovechando todas las características de las copias de seguridad completas de las máquinas virtuales.

Referencias

NetBackup™ for OpenStack Administrator’s Guide