Instalación de vShield Edge (firewall a nivel de grupo de puertos)

Dentro de los productos vShiel de vmware podemos encontrar vShiel Edge que no es más que un firewall a nivel de grupo de puertos de switch virtual, que nos permite proteger y aislar máquinas virtuales sin tener que usar VLANs.

El esquema de funcionamiento sería el siguiente:

 

En el esquema podemos ver que las máquinas a proteger o aislar se conectan a un grupo de puertos de un switch virtual, al configurar vShield Edge en este grupo de puertos se crea una máquina virtual con conexión a la red externa y a la red interna protegida. Esta máquina virtual será el Gateway de nuestras máquinas protegidas y así podremos configurar el firewall, NAT, DHCP y hasta VPNs del vShield Edge de este grupo de puertos según la seguridad que necesitemos.

A continuación se detallan los pasos a seguir para su instalación y configuración:

• Desplegar el OVA de vShield Manager que nos permite administrar todos los componentes de vShield, entre ellos vShield Edge.

          IMPORTANTE: Necesitamos 8GB de RAM Y 2 terjetas de red

•  Configurar los parámetros de red de vShield Manager

• Abrir una consola de la máquina virtual vShiel Manager 
• Entrar con usuario admin y password default 
• Teclear enable y password default
• Teclear el comando setup e introducir los datos de red

• Entrar en la interface web de vShield Manager para conectar con Virtual Center, con usuario admin y password default

• Registrar el Plug-in del cliente vSphere

• Instalar las licencias de vShield Edge, ya sean de prueba o definitivas han de introducidas en el administrador de licencias de Virtual Center.
• Desde el vSphere Client seleccionar la pestaña vShield del host a configurar, aceptar el certificado de seguridad y instalar el servicio vShield Edge Port Group Isolation (esta funcionalidad es opcional y sólo está disponible en instalaciones sobre switchs virtuales distribuidos)
• En la pestaña vShield Edge del grupo de puertos a proteger introducir los siguientes datos:
• External: datos de red de la máquina virtual vShield Edge para que tenga acceso a la red externa.
• Internal: datos de la red interna a proteger, esta será la puerta de enlace de las máquinas conectadas a este grupo de puertos
• Install

  

• Una vez instalado nos parecerán las pestañas Firewal, NAT, DHCP, VPN y LOAD BALANCER que podremos configurar según necesidades
• Por defecto el firewall está configurado “ALLOW”, deberemos configurar las reglas según necesidad. Por ejemplo:

 

• Para que las máquinas tengan acceso a Internet deberemos configurar el NAT de salida (SNAT)

 

Esta configuración simplemente nos permite controlar la entrada y salida de las máquinas virtuales conectadas en este grupo de puertos, pero se puede configurar DHCP, VPNs e includo un balanceador de carga.

Actualizar ESX(i) desde consola

De un tiempo a esta parte instalamos las servidores dedicados a Virtual Center, Veeam Backup y Monitoring en máquinas virtuales ubicadas en los discos locales de un host ESXi , fuera de los clusters HA/DRS.

Esto es un problema a la hora de instalar parches que requieren poner los host en modo mantenimiento, pues el servicio Update Manager no se puede utilizar al no poder iniciar el Virtual Center. Como ya no disponemos del viejo Host Update, sólo nos queda actualizar estos ESX(i) desde consola.

En esta ocasión actualizaremos mediante un paquete zip que podremos descargar desde la página de Descarga de Parches de ESX/ESXi.

A continuación nos conectaremos vía SSH al host en cuestión y seguiremos los siguientes pasos:

  

1. Escanear parches disponibles
   
   
   
   ~ # esxupdate --bundle https://hostupdate.vmware.com/software/VUM/OFFLINE/release-254-20101122-192599/ESXi410-201011001.zip scan
   
   ESXi410-201011001.zip           ############################# [100%]
   
   
   Applicable bulletins with updates are listed.
   ----Bulletin ID----- --------Date------- ----Summary-----
   ESXi410-201011401-BG 2010-11-29T08:00:00 Updates Firmware
   Esxupdate local cache states:
    Location: /tmp/updatecache
    Available space: 4004 [MB]
   
   
2. Desempaquetar los parches
   
   
   
   ~ # esxupdate --bundle https://hostupdate.vmware.com/software/VUM/OFFLINE/release-254-20101122-192599/ESXi410-201011001.zip stage
   
   Unpacking deb_vmware-esx-firmware_4.1.0-0.2.320137 ############################################ [100%]
   
   
3. Si la actualización lo requiere poner el host en mantenimiento
   
4. Instalar los parches

   ~ # esxupdate --bundle https://hostupdate.vmware.com/software/VUM/OFFLINE/release-254-20101122-192599/ESXi410-201011001.zip update

   Installing packages :deb_vmware-esx-firmware_4.1.0-0.2.320.. ############################################ [100%]

   
   

   The update completed successfully, but the system needs to be rebooted for the

   changes to be effective.

5. Rebotar el host si la instalación lo requiere 
6. Comprobar si la instalación se ha realizado correctamente

   ~ # esxupdate query

   ----Bulletin ID----- -----Installed----- ----Summary-----

   ESXi410-201011401-BG 2010-12-16T14:44:42 Updates Firmware

   
   
7. Salir del modo mantenimiento

Multipathing con iniciadores iSCSI o HBAs SAS en vSphere

Para configurar en vSphere la conexión a una SAN iSCSI con iniciadores software, el esquema de conexión físico sería el siguiente:

En este escenario cada host ESX(i) dispone de dos tarjetas de 1Gb., conectadas a dos switchs de Gb., donde se han de conectar los respectivos puertos iSCSI de la SAN para proporcionar redundancia. Es necesario habilitar Jumbo Frames en los puertos iSCSI de la SAN, en los switchs físicos y en los switchs virtuales de los hosts para disponer de mayor rendimiento.

El quid del multipathing lo encontramos en la configuración del los switchs virtuales de los hosts. En primer lugar se han de crear dos grupos de puertos  del tipo VMkernel para almacenamiento iSCSI, con las dos tarjetas asignadas para este fin, dejando en el primer grupo la primera tarjeta activa y la otra tarjeta en stand by, y configurando el segundo grupo a la inversa. En la SAN deberemos configurar en cada controladora un puerto con el rango de red del primer grupo y el otro puerto con el rango del segundo grupo. De este modo conseguimos cuatro caminos, de los cuales dos estarán activos y los otros dos en stand by.

Finalmente hemos de configurar en el storage de cada ESX(i) la administración de los paths, escogiendo para cada datastorage (LUN) el modo de selección del path de acceso. Si queremos aprovechar los dos caminos disponibles equitativamente seleccionaremos Round Robin, pero también podemos utilizar el modo Fixed para asignar un camino preferido a cada LUN y si falla la tarjeta o la controladora implicada automáticamente saltaría al otro camino hasta que el preferido vuelva a estar disponible.

En la conexión a una DAS vía HBAs SAS el multipathing no está disponible, pues sólo es posible tener un camino activo para cada LUN, quedando el otro en stand by. El esquema de conexión sería el siguiente:

En este caso disponemos de dos HBAs a 6Gb conectadas directamente a las controladoras de la cabina DAS. Es importante destacar que para que los hosts seleccionen el mejor camino y proporcionen un mejor rendimiento en caso de caida de alguna HBA debemos marcar como método de selección VMW_PSD_FIXED_AP.

Diferentes escenarios para plataforma vSphere

Hasta ahora los escenarios de virtualización con los que he trabajado han sido principalmente dos:

• La tradicional alta disponibilidad con SAN de por medio y redundancia de electrónica

 

• ESX(i)s activo-activo (para pequeños clientes) utilizando la funcionalidad de replicación de Veeam B&R para replicar las máquinas entre los ESX(i). Con ello disponemos de máquinas de emergencia para servidores críticos con una menor inversión.

El esquema anterior es un ejemplo donde las máquinas vCenter y Veeam B&R están dentro de los mismos servidores activo-activo por un tema de costes, pero lo ideal sería disponer de un tercer servidor ESX(i) para independizar la administración del entorno de producción.

• La aparición de las cabinas DAS (Direct Attached Storage) con conexión SAS directa a los ESX(i)s nos permite diseñar un nuevo esquema de alta disponibilidad, eliminando electrónica de red y lo que es más importante ampliando el ancho de banda entre la cabina y los hosts hasta 6Gbs. Esta configuración tiene como limitación el número de hosts a conectar, pues al no haber switch, disponemos de tantas conexiones como tarjetas tenga la cabina, si tenemos 4 por controladora y queremos redundancia estaremos limitados a 4 hosts.

 

Veeam B&R: Instant Recovery

Excelente funcionalidad de la nueva versión de Veeam B&R que es capaz de montar como unidad NFS las imágenes de las VMs en los host ESX(i), permitiendo arrancarlas incluso con la máquina original en marcha.

En menos de un minuto la máquina está recuperada, luego se puede migrar al entorno de producción usando Storage vMotion y si no lo tenemos disponible también se puede hacer migración en frío con la máquina parada.

Por si la máquina original está en producción, al recuperarla, por defecto la tarjeta de red está deshabilitada. Ideal para realizar pruebas de restauración, y una vez finalizadas las comprobaciones, se desmonta y en otro minutillo desaparece del inventario