En este Post veremos lo fácil que es desplegar y realizar la configuración inicial del nuevo appliance de vCenter sobre Linux.
En un Post anterior hemos visto las diferencias con el vCenter clásico de Windows que, como mencionamos en dicho Post, se sigue manteniendo.
 
Lo primero que debemos hacer es descargarnos el Appliance.
No sé vosotros pero nosotros, al leer Appliance, fuimos a buscarlo al Marketplace de VMware, en donde están todos los Appliance publicados.
Pues este debemos descargarlo desde la propia web de VMware como el resto de componentes de la Suite vSphere. Con un usuario registrado nos podremos bajar una versión de prueba de 60 días de vSphere totalmente funcional, el cliente de vSphere y, a gusto del consumidor, el vCenter para Windows o el Appliance de vCenter sobre Linux.
La descarga del vCenter Server Appliance está compuesta por 3 ficheros. Un disco de sistema (4GB), un disco de datos (40GB) y un fichero OVF (Open Virtualization Format) para crear la propia VM a partir de los dos discos mencionados anteriormente.
 

Esta mañana tomando un café nos hemos encontrado frente a frente con una evolución de más de 100 años.
Por un lado una registradora National Imperio del año 1904, aún funcionando y en estado impecable, y por el otro el típico TPV touch. 

VMware vSphere 5 Clustering technical deepdive

 

A Octubre de 2011 no hay muchos libros de VMware vSphere 5. Es curioso pero uno de los primeros libros de vSphere 5 publicados es explícitamente sobre Clustering.
El gran Duncan Epping y Frank Denneman presentan 348 páginas en las que desmenuzan HA, DRS, DPM y vSphere Storage DRS.

En esta ocasión Miguel, no sabemos desde donde nos escribe, nos hizo un 2x1.
 
“¿Existe alguna restricción para la cantidad de máquinas virtuales por licencia de procesador?
En caso de que exista: ¿Cuál sería?”
 
Vamos a comenzar comentando que VMware tiene una buena colección de documentación de sus productos, en especial de vSphere. Entre los documentos de vSphere tenemos uno llamado vSphere 5 configuration maximus.
En este documento, de obligada lectura para certificar el VCP, vamos a poder encontrar los máximos de todo, como por ejemplo el tamaño máximo de memoria RAM de un Host o el número máximo de tarjetas de red asignadas a una máquina virtual.
 
En relación a la consulta de Miguel tenemos que aclarar que el documento indica el número máximo de máquinas virtuales por Host, pero no por procesador.

 

En las versiones anteriores de vSphere, cuando queríamos instalar una instancia de vCenter (Vicente para los amigos) para gestionar de forma centralizada nuestros Hosts de vSphere, debíamos disponer de un servidor (físico o virtual) de Windows 2003 o 2008 que no podía ser controlador de dominio, y realizar la instalación del servicio vCenter. Esa instalación debía estar además acompañada de una base de datos que podía estar en el mismo servidor o en otro equipo diferente.
 
En la versión 5 de vSphere podemos elegir entre la instalación clásica de vCenter, sobre un servidor de Windows y una instalación manual, o utilizar el nuevo Appliance de vCenter que funciona sobre Linux.
 

Actualmente es muy común encontrarnos con problemas generados por un desfase horario. Sobre todo si se trata de equipos añadidos al dominio, pero también ocurre con la asignación de fecha y hora a máquinas virtuales, Hosts de vSphere (o Hyper-V) y también con dispositivos.
 
En ese caso lo mejor es cortar por lo sano y establecer un servidor (físico o virtual, lo mismo da) que sea el que asigne a todos los equipos y dispositivos la misma fecha y hora, con distinción de su zona horaria, claro está.
 
Lo mejor de todo es que en la mayoría de los casos ya contamos con ese servidor. La mejor opción probablemente sea utilizar nuestro Directorio Activo. Más precisamente el controlador de dominio que ejecuta el rol de emulador de PDC. Ese servidor es el que se encarga de sincronizar la fecha y la hora a todos los equipos y servidores que son añadidos al dominio.

Siguiendo la regla de causa-efecto, debido a la fiebre de la virtualización tenemos como resultado una proliferación de Maquinas Virtuales que los administradores de sistemas debemos gestionar.
Eso genera la necesidad de monitorizar los diferentes sistemas (Routers, Switches, Almacenamiento, Hosts físicos, Servidores Virtuales, Servicios, Dispositivos, etc) para que nuestro trabajo sea, en la medida de lo posible, pro activo.
Si bien es cierto que muchos sistemas de monitorización recomiendan instalar sus propios agentes, muchas veces resulta muy interesante (y sobre todo liviano a nivel de rendimiento) configurar el sistema SNMP (protocolo estándar de monitorización) en nuestros servidores para que sean gestionados por nuestro sistema de monitorización.
 
Vamos a comenzar revisando los conceptos para luego realizar la instalación del sistema SNMP y configurarlo de forma automática utilizando GPOs.


SNMP Manager: es un equipo (servicio) que envía consultas a un Agente (equipo administrado). En algunos casos el Manager SNMP envía peticiones al Agente para que realice cambios de configuración.