vSphere Availability Basics – vMotion

This is the first of a series of technical posts speaking about vSphere Availability.
The intended audience for this is people that might have some experience with VMware, admins that have inherited a solution or such.
Please note, if you are an experienced vSphere Admin you might find this reading kind of boring or easy.

Throughout my years in virtualization support I’ve noticed that some admins that have inherited vSphere Clusters or some App teams whose VMs failed over needed a detailed explanation of how availability features of vSphere work.

vMotion

Let’s admit it, downtime in IT is a bad word. Years ago if you had to do a planned maintenance task such as upgrading firmware or upgrading a host you would have to schedule a change window, most companies avoid this kind of changes since applications can’t (or don’t want to) take downtime.
The main purpose of vMotion is to allow you to migrate your VMs from on ESXi host to another without any interruption to the guest operating system or application. This is what we call a live migration. This process allows IT administrators to perform maintenance on Physical hardware without having to take downtime.

How VMotion Works! (VMotion Explained) - The Geek Pub
Thanks Geek Pub for the image!

How does it work?
Note: this is a high level summary of what happens when you trigger a vMotion. If you want a detailed version please visit this link

When a vMotion request is issued the vCenter Server will perform a compatibility check in which it will validate the following:
– Network communication over vMotion network between source and destination host.
– Access to a shared datastore between source and destination esxi host.
– Is the portgroup created on the destination host?
– Does destination host have the same CPU family and level as source host?

Once all compatibility checks are passed vCenter issues a migration specification to both Source and Destination ESXi that includes:

-The VM that is being migrated
– Virtual Machine configuration (vHardware, settings, etc)
– Source ESXi host
– Destination ESXi host
– vMotion network details.By now the vMotion process should be are arround 22% on the recent tasks process, the VM in the source host will continue funcioning normally.
At this point a copy of all memory pages and vCPU data will begin in the background generating a “shadow VM” on the destinaton host.
Once Memory pages and vCPU pages are finally copied source virtual machine will be Shut Down and the destination VM will be Powered On but boot process will be directed to the copied memory pages.

(Please note data on vDisks will not be migrated on a normal vMotion since the data disks remain on the datastore and it remains unaltered. Vitual disks can be migrated on a storage vMotion. I will cover it on a future post).

Considerations

– Since the moment vMotion is triggered you cannot edit the virtual machine settings. This is a protection mechanism to avoid VMs becoming corrupt.
– At the moment of VM Switchover you might lose up to 3 pings, but not more than that.
– VMs with passtrough devices (Like RAW Device Mappings, Direct Path IO, and such) lose vMotion capabilites. This is because it is not possible to share those devices accross ESXi hosts.
– VMs with operations in progress like snapshots, backups, hang settings can’t be migrated.
– VMs with ISOs mounted will fail to vMotion (check KB https://kb.vmware.com/s/article/2148813)
– VMs with VMware Tools upgrade process in progress will fail to vMotion.
– vMotion will not cover you in a disaster scenario. For that purpose we have vSPhere HA and Fault tolerance (I will speak about them in future posts)

Requirements

– Shared storage access both on source and destination hosts (SAN, NAS, FC, FCoE)
– A VMkernel port for vMotion on each host (if you are using vSphere Standard Switches please make sure to keep the same name across all hosts)

Recommendations

Use the same subnet for vMotion across all hosts
– vMotion requires at least 250 MBps dedicated troghput for vMotion, more troughput ensures quicker migrations.

For further information please check: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenterhost.doc/GUID-3B41119A-1276-404B-8BFB-A32409052449.html

¿Does vMotion cause issues?

vMotion is an excelent tool that has revolutionized the IT market. It helps vSphere and Cloud admins avoid planned maintenance on a daily basis. In a Large size company vMotions happen thousands of times a day without causing any issues.

While there most of the applications in the market (I would say 95%) won’t notice vMotion. Some extemely latency sensitive apps will experience issues when the mgiration happens. For those cases please check this.

About Availability:

The main objective of all the products we will discuss in this series of posts is to provide Business Continuity, either it is to avoid downtime during planned maintenance, minimize (or avoid) downtime during hardware failures or keep business critical applications safe in case any disaster occurs.
None of this products will do the trick if your vSphere design does not take redundancy into consideration (NICs, PSUs, Shared Storage, using multipathing and such)
In addition to that you must be prepared for the lightning to strike and have a Disaster Recovery Plan and test it frequently.

Guia de Backup NSX-V 6.4

Antes de arrancar, vamos a repasar rapido los 3 planos de acción de NSX.
El Management Plane son los componentes que nos permiten administrar la plataforma.
Es imporante entender que el NSX Manager tiene embebidos los templates de los controllers y los edges y está en constante sincronía con el control cluster) sumado a eso, las reglas de firewall distribuído se administran desde acá.

En el Control Plane es donde se administran las funciones del Distributed Logical Switch y el Distributed Logical Router. Por lo que mantiene la información de Switching y Routeo de los hosts consistente y actualizada.

En el Data Plane es donde se da la comunicación (Switching, Routeo y Firewalling). Esta compuesto del vSphere Distributed switch sumado a los componentes de kernel de NSX (VXLAN, Logical Switch, Logical Router, Distributed Firewall).

nsx-planes - jeffreykusters.nl

¿Por qué hacer un backup?

NSX no es más que las reglas de routeo, de firewall y la comunicación entre las maquinas virtuales de nuestro SDDC ¿Por qué haríamos un back-up, no?
No tener backup de NSX puede causar los siguientes problemas:
– Podrías perder acceso de administrador a las redes virtuales.
– Podrías perder las reglas de firewall.
– O lo que es peor podrías tener un incidente.
En el día a día de las operaciones de IT nos encontramos con dos tipos de backups. Backups para prevención de desastres (DR) o para salvaguardar cambios (Change Management).

¿Qué backupear?

Los componentes a realizar backup son los siguientes:

NSX Manager

vSphere Distributed Switches

Si bien hacer un backup de vCenter es igual de importante o más (ya que sin un vCenter perdemos toda administración de NSX-V). Lo voy a cubrir en otro post.

¿Qué pasa con los otros componentes?
Los NSX Edges son VMs stateless (se pueden redeployar a voluntad) y su configuración se guarda en el NSX Manager.
Los NSX Controllers guardan la información de VXLAN, lo que los hace importantes. Pero al estar desplegados en clusters de 3 puede haber uno desconectado (o todos si esta CDO habilitado) por lo que los convierte en componentes prescindibles. Sumado a eso su configuración esta guardada en el NSX Manager y se pueden desplegar y sincronizar en minutos.
Por último, VMware solo soporta el backup de controllers y edges a traves del NSX Manager. (https://kb.vmware.com/s/article/2144087)

NSX Manager – File based backup

El file based backup se configura desde el portal de administración del NSX Manager.
En este link te dejo un documento que explica como configurarlo.
Algo a tener en cuenta: el file based backup no tiene rotación de archivos. Por lo que tendrías que crear una tarea programada o algo similar para limpiar los archivos luego de 2 semanas.

Es importante que usemos SFTP como protocolo de transferencia.
Yo personalmente recomiendo hacer backups del SFTP share con una herramienta de terceros.

¿Cada cuánto hacer los backups?
Como siempre, depende del tamaño y la criticidad de tu deployment.
En este caso particular vamos a hacer los backups automaticos todos los días a las 23:00 hs

En caso de un cambio, simplemente tenemos que ejecutar un backup on demand. Haciendo click en el boton Backup.

¿Cómo restaurar el backup?

Para restaurar un backup vamos a tener que hacer un deploy de un NSX Manager nuevo (en la misma versión) y configurar el SFTP server al que estamos haciendo backup en la parte de Backup & Restore una vez hecho esto nos aparecera la opción restore.

VMware NSX - Backup & Restore VMware NSX Manager Data

Para mas detalles dejo este link

vSphere Distributed Switches

Como ya hablamos antes, NSX corre sobre vDS:
Hacer un backup de un vSphere Distributed Switch es bastante facil. No obstante es importante porque si llegamos a borrar un portgroup y tenemos que recrearlo, tendríamos que recrear también todas las politicas especificas de ese portgroup.
Para hacer un backup on demand de un vDS

Hacemos click derecho en el vDS –> Settings –> Export Configuration.


Lo que va a abrir este wizard.


Seleccionamos la opción Distributed Switch and all portgroups.
Esto nos va a devolver un archivo backup.zip

Ahora, hacer este proceso todos los días es algo tedioso.
Por suerte tenemos este script de PowerCLI que nos permite exportar la configuración de los vSphere distributed switches de forma automatizada.

Vamos a necesitar un host que corra PowerCLI y en el que podamos correr tareas programadas.

Respecto al schedule del script.
Nuevamente es un gran “depende”.
Si en tu infraestructura no propagan nuevos portgroups o logical switches seguido, podes hacerlo cada una vez por mes o on demand. En este caso como se hacen cambios bastante seguido lo estoy corriendo una vez por semana.


Restaurar un vSphere Distributed Switch

Para restaurar un vDS nos paramos en el vSphere Distributed Switch –> Settings –> Restore configuration.

Esto nos va a abrir un wizard que nos va a pedir el archivo de backup.

Seleccionamos el archivo backup.zip y la opcion restore distributed switch and all portgroups. y hacemos click en next.

Nos va a dar un resumen de las configuraciónes que va a aplicar. Hacemos click en finish va a ejecutar el restore.

¿Por qué no usar herramientas de terceros?

De hecho me parece perfecto agregar un punto extra de backup. Aunque no es del todo necesario.
Tengamos en cuenta lo siguiente:

1. No hagas backup de los Controllers, Edges y DLRs como maquinas virtuales. Simplemente usar el NSX manager.
2. Si vas a hacer backups del NSX Manager y usas una herramienta con VADP no uses quiescing.
3. Hacé backups del ftp share.


Espero que les haya servido.

Cualquier duda o consulta me pueden contactar.

Cambiar los certificados en vCloud Director – Tutorial

Hola! La idea de este post es aprender a cambiar los certificados en las celdas de vCloud Director.

Nota:
Cada vez que veas $PASSWORD significa que es una password a reemplazar


Pre-Requisitos

  • Acceso root a las celdas de vCloud
  • Nuevos certificados en formato .PEM
  • Snapshot de la/s celdas de vCloud

Pasos a Seguir

  1. Iniciar sesión con el usuario root a la celda de vCloud en la que vamos a trabajar.
  2. Cambiar al directorio de binarios de vCloud Director
    cd /opt/vmware/vcloud-director/bin/
  3. Obtener el estado de la celda
    ./cell-management-tool -u administrator -p $PASSWORD cell –status
  4. Detener el servicio VCD
    service vmware-vcd stop
  5. Copiar via Winscp los nuevos certificados a la carpeta /tmp/certs
  6. Cambiar el directorio a /tmp/certs
    cd /tmp/certs
  7. Unificar los dos certificados en el archivo “wildcard.pem”
    cat mycert.crt mycert.key > wildcard.pem
    Nota: vCloud director es un producto basado en Linux, por lo que es case sensitive, respetar las mayúsculas y minusulas
  8. Con la herramienta openssl exportar los certificados del archivo .pem a archivos .p12 y definir la función de cada certificado (“http” o “consoleproxy”)
    openssl pkcs12 -export -in wildcard.pem -out wildcard-http.p12 -name http

    openssl pkcs12 -export -in wildcard.pem -out wildcard-console.p12 -name consoleproxy
  9. Realizar un backup de los certificados originales
    cp /opt/vmware/vcloud-director/jre/bin/wildcard-console.p12 wildcard-console.p12-backup

    cp /opt/vmware/vcloud-director/jre/bin/wildcard-http.p12 wildcard-http.p12-backup
  10. Borrar los certificados originales
    rm /opt/vmware/vcloud-director/jre/bin/wildcard-http.p12

    rm /opt/vmware/vcloud-director/jre/bin/wildcard-console.p12

Cambiar los certificados

  1. Copiar todos los archivos con formato “.p12” a la carpeta con los certificados
    cp *.p12 /opt/vmware/vcloud-director/jre/bin/
  2. Dirigirse a la carpeta con los certificados
    cd /opt/vmware/vcloud-director/jre/bin
  3. Importar los certificados y listarlos (la fecha de modificación debe ser la fecha de actualización de certificados)
    ./keytool -importkeystore -deststorepass $PASSWORD -destkeypass $PASSWORD -destkeystore certificates.ks -srcstoretype PKCS12 -srckeystore wildcard-http.p12 -srcstorepass $PASSWORD -alias http

    ./keytool -importkeystore -deststorepass $PASSWORD -destkeypass $PASSWORD -destkeystore certificates.ks -srcstoretype PKCS12 -srckeystore wildcard-console.p12 -srcstorepass $PASSWORD -alias consoleproxy

    ./keytool -keystore certificates.ks -storepass $PASSWORD -storetype JCEKS -list
  4. Copiar el archivo certificates.ks a la keystore
    cp /opt/vmware/vcloud-director/jre/bin/certificates.ks /opt/keystore
  5. Configurar la keystore
    /opt/vmware/vcloud-director/bin/configure
  6. Aparecerá el siguiente mensaje. Introducir la siguiente información:
    Please enter the path to the Java keystore containing your SSL certificates and private Keys:
    /opt/keystore
    Please enter the password for the keystore: $PASSWORD
    Please enter the private password for the 'http' SSL certificate: $PASSWORD
    Please enter the private password for the 'consoleproxy' SSL certificate: $PASSWORD

Reinicio del servicio

  1. Iniciar el servicio de vCloud Director y verificar el estado de la celda:

    cd vcloud-director/bin/
    ./cell-management-tool --status
    service vmware-vcd-start
    ./cell-management-tool -u administrator -p $PASSWORD
    ./cell-management-tool --status

    service vmware-vcd status