AutoLab 1.5 liberado – vSphere 5.5 Ready!

Mucha ha sido la espera pero ya se ha liberado la versión 1.5 de AutoLab que a su vez ha sido soportada por Infinio, gracias a este nuevo sponsor Alastair ha conseguido más tiempo para dedicar al proyecto, AutoLab 1.5 está disponible para todos, a descargar!

Características principales?

Soporte para VSAN!
Soporte para View 5.2 & 5.3
 

Una diferencia a tomar en cuenta con respecto a versiones anteriores es el incremento en la RAM requerida por los vESX, ahora estos necesitan 4G (6G mientras iniciamos VSAN) y son 3 vESX debido a VSAN, podremos disminuir esto a 2G luego de haber desplegado AutoLab.

Enlace para la descarga – http://www.labguides.com/autolab/

AutoLab tiene logo!

VMware Virtual SAN – Proof of Concept Guide

Si está en el proceso de crear un PoC de VSAN, VMware tiene publicado una step-by-step de cómo crear uno y no fallar en el intento. Haciendo uso de este recurso y de los Lab de HOL se aseguraría una implementación de VSAN.

http://www.vmware.com/files/pdf/products/vsan/VMware_Virtual_SAN_POC_Guide.pdf

http://labs.hol.vmware.com/HOL/#lab/562

aaNetworks HomeLAB Actualizaciones!! – Storage.

Hace tiempo que no escribo nada sobre el homelab, muchos cambios le han ocurrido al entorno que uso para pruebas de Virtualización & Redes.

El homelab tuvo su relanzamiento hace más o menos 2 años y hace unos meses ha tenido cambios significativos que han mejorado su rendimiento. Vamos a comenzar por el Almacenamiento.

Desde que tengo homelab el almacenamiento siempre ha sido proporcionado por custom-build, inicialmente era FreeNAS, luego OpenFiler, en un momento Nexenta y de vuelta a OpenFiler, esto simplemente porque no podía hacerme de un Iomega IX o de un Synology, pero ya que el Iomega ha bajado tanto el precio he adquirido 2, uno por ebay y otro ha sido un regalo, el problema de estos era que estaban bricked y volverlos a la vida fue bastante fácil.

Cuento con 2 Whitebox ESXi 5.5 a los cuales les doy conectividad (mediante iSCSI) a 1 iomega IX4-200d con 2x2TB (RAID 1) para un total de 1.8TB de espacio para las VM que necesito, el único inconveniente con esta actualización es que para un equipo de casi 5 años no es fácil lidiar con la carga de IOPS que demandan mis ESXi y más al momento de iniciar varias VMs al mismo tiempo.

Esta configuración está funcionando desde principios de Enero con resultados aceptables, excepto cuando tengo corte de luz y ambos ESXi pierden energía (welcome to DR), al momento de restaurar la energía, todas las VM son arrancadas al mismo tiempo y es ahí cuando tengo ganas de cambiar el IX4-200d.

Voy a llevar versiones del homelab y haciendo cuenta esta es la versión 3.0, la versión 1.0 fue basada en motherboard adquiridos en eBay de la marca Tyan, estos eran bastante grandes y con solo 8G de RAM. En esta versión 3.0, ha cambiado la forma en que administro el homelab ya que ahora cuento con ESXi que están ubicados en verdaderos datacenters y están disponibles 24×7 con buen ancho de banda, por esto decidí que todo lo relacionado a manejo (VCSA, vCloud, vShield, vMA y otros acrónimos que comienzan con “v”) serán desplegados en uno de esos ESXi. Así que ahora en la versión 3.0 los equipos en casa son para recursos de vCloud Director (en proceso).

Desempeño del Almacenamiento actual.

Los IX4-200d en su momento fueron todo un boom en Internet/comunidad VMware, por su precio y porque proporciona iSCSI & NFS (aunque solo NFS está certificado para trabajar con VMware), pero para esta época no son tan geniales. Como decía, son 2, uno con 1.8Tb y otro con 1Tb (ambos en RAID1) y para almacenar las VM son perfectos.

PernixData FVP + SSD to the rescue!

Ya con alrededor de 2 meses usando el homelab v3 había notado la lentitud del almacenamiento cuando realizaba backups con Veeam (lo mejor que usado hasta el momento para respaldar VM) ya que siempre reportaba que el cuello de botella era la Fuente (los IX4-200d), el destino de estos backup es un Mini-ITX con unRAID (tema de otra entrada) y cuenta con un Atom a 1.8, 2Gb de RAM y 4Tb de espacio.

Buscando una solución que no sea adquirir otro almacenamiento o montar otra PC con OpenFiler decidid probar local cache son SSD, no me decidía a hacer esto ya que suponía un costo y no estaba seguro que funcionaria, luego presto atención a PernixData y decido inscribirme en el beta, compro los SSD y manos a la obra.

Saben que, FVP es una maravilla, ahora no siento la necesidad de cambiar los viejos IX4-200d ya que el cache con FVP está rindiendo frutos! Lástima que la licencia sea solo por 60 días, he aplicado para una versión NFR así que ha esperar. Si no consigo la licencia estoy pensando en mover el almacenamiento a VSAN, el único inconveniente es que necesitaría otro ESXi para poder estar en el mínimo requerido. Ha esperar!

OpenWRT en aaNetworks – BGP, Anycast DNS & OpenDNS.

OpenWRT puede ser que no necesite introducción pero aquí va, OpenWRT es un pequeño Linux que se instala en muchos dispositivos embeded. Después de muchos años siendo usuario de m0n0wall luego pfSense y por ultimo Vyatta, decidí usar este pequeño amiguito por el hardware que tengo disponible en este momento, tengo 2 Soekris, uno es 4801 y otro es 4501, ambos productos son bastante viejos.

La instalación en x86 (plataforma de Soekris) fue muy sencilla, estos son los pasos:

  1. descargar http://downloads.openwrt.org/attitude_adjustment/12.09/x86/generic/openwrt-x86-generic-combined-ext4.img.gz
  2. Usando 7-Zip extraer el archivo .img
  3. Usando dd en Linux o WinImage en Windows enviamos la imagen a nuestro CF.
  4. Nos aseguramos de tener la velocidad correcta en el Soekris, esta debe ser igual que la implementada por defecto en OpenWRT (38400).

En este punto deberíamos tener un OpenWRT listo para trabajar con él.

El Soekris 4801 (ELZAR) y el 4501 (WERNSTROM) forman parte de una Mesh VPN usando Tinc. Gracias a esto tengo varias localidades interconectadas vía VPN con poco mantenimiento requerido para funcionar.

En este post me centrare en como he hecho para tener filtro de DNS y Anycast DNS. Anycast es algo que no se ve en una red casera pero mi red desde hace tiempo dejo de ser normal. OpenWRT cuenta con un package manager (opkg) que nos permitirá instalar software para conseguir las funcionalidades que deseamos en nuestro OpemWRT. Lo primero, claro, es tener nuestro OpenWRT funcionando y con el NAT deshabilitado (ese es el caso en mi red), instalaremos  BGP (Quagga) y reconfiguraremos DNSmasq.

Instalando los paquetes.

Quagga es la suite que usaremos para tener BGP (OSPF lo uso para redistribuir rutas a mi Vyatta), esto nos ahorrara trabajo (tengo otros nodos con Quagga) ya que solo tendré que copiar parte de la configuración, cambiar ASN, router ID y otras mínimas líneas de la config.

opkg update

Estos son los paquetes instalados actualmente en ELZAR.

  • quagga
  • quagga-bgpd
  • quagga-libospf
  • quagga-libzebra
  • quagga-ospf6d
  • quagga-ospfd
  • quagga-vtysh
  • quagga-watchquagga
  • quagga-zebra

Ahora toca configurar e iniciar los servicios para tener BGP funcionando. La instalación es por defecto, esto quiere decir que tendremos /etc/quagga donde pondremos los archivos de configuración que se requieren.

Para que BGP (módulo de Quagga) funcione necesitamos tener configurado zebra.conf y bgpd.conf.

Configuración básica de estos archivos.

zebra.conf :

  • hostname -zebra
  • password MiSuperPassword
  • service advanced-vty
  • !
  • line vty
  • access-class vty
  • !

bgpd.conf :

  • hostname -bgpd
  • password MiSuperPassword
  • service advanced-vty
  • !
  • access-list vty permit 127.0.0.0/8
  • access-list vty deny any
  • !
  • line vty
  • access-class vty
  • exec-timeout 0 0
  • !

Con esto podemos iniciar el servicio de Quagga usando /etc/init.d/quagga start, ya tendremos el servicio de BGP funcionando pero aun no es suficiente para que OpenWRT cumpla con la tarea asignada, ahora toca configurar BGP conectándonos a la consola que está disponible en el puerto 2605 (telnet localhost bgpd) y nos pedirá el password que usamos en la configuración base (MiSuperPassword en este ejemplo). Una vez dentro configuraremos nuestro número autónomo, las subredes que anunciaremos desde este router y los vecinos a quienes estaremos anunciando estas subredes.

Esta es la configuración en ELZAR (un poco editada).

  • Current configuration:
  • !
  • hostname elzar-bgpd
  • password MiSuperPassword
  • service advanced-vty
  • !
  • router bgp 64845
  • bgp router-id 10.45.254.9
  • network 10.45.254.9/32
  • network 10.45.255.1/32

Toda la configuración después de estas líneas es relacionada a los vecinos (neighbors) con los cuales el servicio de BGP intercambia rutas.

Internamente son 3 router con BGP que usar el ASN 64845 y están agrupados así:

  • neighbor aaNetworksHQ peer-group
  • neighbor aaNetworksHQ remote-as 64845
  • neighbor aaNetworksHQ override-capability
  • neighbor aaNetworksHQ next-hop-self
  • neighbor aaNetworksHQ soft-reconfiguration inbound

De esta manera solo necesito hacer lo siguiente para establecer relación entre 2 routers con el mismo ASN:

  • neighbor 10.45.252.10 peer-group aaNetworksHQ
  • neighbor 10.45.252.10 update-source 10.45.252.9
  • neighbor 10.45.252.14 peer-group aaNetworksHQ
  • neighbor 10.45.252.14 update-source 10.45.252.13

El router 10.45.252.10 es otro OpenWRT (wernstrom) el cual también funciona como Anycast DNS en mi red local, el router con 10.45.252.14 es un Vyatta que funciona como router para Internet y es quien agrupa todas las rutas que se puede distribuir hacia el OSPF internamente.

Al final terminamos con algo así:

  • router bgp 64845
  • bgp router-id 10.45.254.9
  • network 10.45.254.9/32
  • network 10.45.255.1/32
  • neighbor aaNetworks peer-group
  • neighbor aaNetworks remote-as 64635
  • neighbor aaNetworks update-source aanet
  • neighbor aaNetworks override-capability
  • neighbor aaNetworks soft-reconfiguration inbound
  • neighbor 10.45.252.10 peer-group aaNetworksHQ
  • neighbor 10.45.252.10 update-source 10.45.252.9
  • neighbor 10.45.252.14 peer-group aaNetworksHQ
  • neighbor 10.45.252.14 update-source 10.45.252.13

Ya tenemos a ELZAR conectado (Interfaces dedicadas hacia los demás routers) a sus vecinos e intercambiando rutas, Excelente!.

La idea es que ELZAR y WERNSTROM publiquen la dirección 10.45.255.1 y a su vez estén corriendo DNSmasq que por defecto viene instalado en OpenWRT. Antes de seguir, aquí dejo un pequeño diagrama de red para que se pueda entender la idea.

Otra configuración que debemos realizar es en zebra.conf, allí crearemos las interfaces donde tendremos las direcciones IP con /32, estas son la loopback (usada en router id & la IP para Anycast).

La configuración en ELZAR es la siguiente:

  • Current configuration:
  • !
  • hostname elzar-zebra
  • password MiSuperPassword
  • service advanced-vty
  • !
  • interface aanet
  • ipv6 nd suppress-ra
  • !
  • interface eth0
  • description «testing»
  • ipv6 address 2001:470:b24c:f021::1/126
  • ipv6 nd suppress-ra
  • !
  • interface eth1
  • ipv6 address 2001:470:b24c:ff22::2/126
  • ipv6 nd suppress-ra
  • !
  • interface eth2
  • ipv6 address 2001:470:b24c:dead::9/64
  • ipv6 nd suppress-ra
  • !
  • interface lo
  • ip address 10.45.254.9/32
  • ipv6 address 2001:470:b24c:254::9/128
  • ip address 10.45.255.1/32
  • !
  • access-list vty permit 127.0.0.0/8
  • access-list vty deny any
  • !
  • ip forwarding
  • ipv6 forwarding
  • !
  • !
  • line vty
  • access-class vty
  • !
  • End

Aquí se pueden ver las 2 direcciones IP.

En este momento las direcciones de loopback y la usada para Anycast son visibles en los demás routers de mi red.

Configurando DNSmasq al estilo OpenWRT.

OpenWRT tiene su método de configuración, aunque la mayoría de los paquetes instalables se pueden configurar vía su propio método, algunas veces es mejor hacerlo así.

DNSmasq es configurado desde /etc/config específicamente en el archivo dhcpd.

Luego procedemos a editar el dnsmasq.conf ubicado en /etc, aquí podemos realizar configuración de la forma oficial y soportada por el proyecto de dnsmasq. La configuración es muy extensa pero lo más importante y relacionado con esta entrada es:

  • listen-address=10.45.255.1
  • #Send most DNS lookups to opendns.com
  • server=208.67.222.222
  • server=208.67.220.220
  • #aaNetworks request to internal servers
  • server=/aanetworks.org/172.22.35.66
  • #server=/aanetworks.org/10.45.254.7
  • server=/172.in-addr.arpa/172.22.35.66
  • server=/10.in-addr.arpa/172.22.35.66
  • server=/aanetworks.local/172.22.35.50
  • server=/aanetworks.local/172.22.35.100

No me gusta que OpenDNS me responda bogus-nxdomain así que agregamos lo siguiente:

  • #blocked opendns.com bogus-nx
  • bogus-nxdomain=67.215.65.130
  • bogus-nxdomain=67.215.65.132
  • bogus-nxdomain=208.67.222.222
  • bogus-nxdomain=208.67.220.220

Reiniciamos DNSmasq para probar que nuestro IP para Anycast DNS sea utilizado como IP preferido para escuchar en los puertos de DNS.

Desde un cliente de la red, con una dirección de 172.22.35.0/26 esto es lo que tenemos cuando hacemos un dnslookup.

También un traceroute desde el mismo cliente que se realizó el nslookup.

Removiendo un vCenter no existente en vCloud Director.

Hace un tiempo que tenía instalado y funcionando vCloud Director en el homelab pero el vCenter en ese momento sufrió un accidente y fue reemplazado por un vCSA en un ESXi remoto (en OVH). El problema fue que toda la configuración realizada en ese vCenter se perdió, en ese momento no le di importancia.

Hace unos días decidid seguir jugando un poco más con vCloud pero quería recuperar la instalación de vCloud & vShield. vShield fue fácil, eliminar el plugin usando instrucciones encontradas aquí (https://communities.vmware.com/docs/DOC-10847).

vCloud fue un poco problemático, cada vez que intentaba eliminar el vCenter este me mostraba un error donde me decía que aun tenia dependencias de vCenter configuradas en algún sitio. Estas dependencias eran 2 host ESXi que fueron preparados desde vCloud.

Al final encontré un KB (2057335) donde explicaba como remover datasotre problemáticos en vCloud, decidi probar algo y además de las instrucciones de eliminar información de la base de datos, agregue el contenido de la tabla managed_server en la cual se encontraban los 2 ESXi.

 

Luego de realizar estos pasos podemos hacer un detach a nuestro viejo vCenter.