Introducción a la virtualización. VCenter.
En el último episodio de Inseguros configuramos un entorno con dos Host ESXi 5.5 compartiendo almacenamiento proporcionado por una SAN virtual gestionada por FREENAS.
Hoy vamos a continuar con esta seria de artículos de introducción a la virtualización, instalando VCenter.
VCenter es una aplicación, o conjunto de ellas que nos permite acceder a las funcionalidades avanzadas que trae el producto ESXi. En un entorno Microsoft estaríamos hablando del componente Virtual Machine Manager de System Center 2012.
Como aplicación podemos instalarla de varias maneras. Como un fichero OVF ( Open Virtualization Format) desplegada como un appliance (como una máquina virtual) que podemos descargar desde la web. También podemos instalarla bajo un servidor Windows, virtual o físico. Si elegimos la primera opción, es tan sencillo como descargar el fichero, copiarlo hacia nuestro DataStore del host Esxi que queremos usar para albergar la máquina, e importarlo. Automágicamente se crearán los discos duros y los ficheros de configuración de la máquina virtual. Internamente VCenter usa un motor de base de datos Postgresql. En cada versión las especificaciones cambian, pero a la fecha de hoy podremos gestionar tan solo 5 Host ESXi con este tipo de base de datos. Como base de datos externa podemos usar SOLO ORACLE. Money Money Money. Si instalamos VCenter bajo un sistema Windows podrá emplear tanto SQL Express (gratuita) como SQL Server. Si nos decidimos por esta opción, tenemos que tener en cuenta que debemos gestionar todo el sistema operativo Windows que hay por debajo de VCenter. Si usamos el appliance virtual, estaremos usando una versión especial de Suse Linux, por lo que a priori el mantenimiento es mínimo.
Una de las cosas que más me llamó la atención sobre VCenter es que no se instala bajo tecnologías de Fault Tolerance. Un elemento tan crítico debería implementarlo. Sin embargo desde VMware indican que no es necesario ya que VCenter almacena toda la información en la base de datos, y es esta la que debe ser asegurada, ya que el despliegue de VCenter en un nuevo servidor, como veremos aquí, es cuestión de unos pocos minutos. Yo me quedo con VMM de Ms como pudimos ver aquí, instalar fault tolerance es cuestión de unos pocos minutos, y garantizas el servicio...
**queda claro con esto que solo vamos a instalar VSphere en uno de los dos HOST ESXi...***
Otra de las cosas que no me agradan mucho es el consumo de recursos. VCenter se va a gastar 6Gb de RAM para el solito. Hablando con expertos en la materia consiguen "tunning" hasta unos 4 Gb de RAM, pero me parece muchísimo si lo comparamos con los modestos 2-4Gb que puede consumir Virtual Machine Manager de System Center.
Pensar que con la virtualización queremos conseguir abstracción de la capa Hardware mediante Software, para poder realizar "tareas". Estas tareas pueden ser recuperación ante desastres. En un entorno bien configurado, si necesitamos XX Gb de RAM para un servidor/servicio, debemos reservar otros tantos en un segundo nodo, para hacer nuestra plataforma tolerante a fallos, o al menos alta disponibilidad... Es un handicap que mucha gente pasa por alto, y en el momento de caídas de elementos físicos, se encuentran con que no tienen capacidad para albergar estas Máquinas virtuales que hemos ido creando a golpe de click.
Vamos a al menú File, y deploy OVF. Seleccionamos el fichero OVA que hemos descargado y en unos cuantos clicks tenemos appliance desplegado, que no configurado.
Arrancamos la máquina virtual que se ha creado con VSphere y seguimos el proceso de configuración por defecto que nos propone el instalador, salvo el direccionamiento IP. El usuario es root y la password es Vmware. Como buen experto en seguridad que eres, no cambies esta clave nada más empezar el proceso. A lo largo de varias instalaciones he tenido problemas con esto. Te recomiendo que no cambies esta clave al menos hasta 30 minutos desde que se instaló. Quizás algún experto pueda aclararnos el por qué !!!
Debemos configurar el servidor de tiempo, el mismo que hemos usado en toda nuestra infraestructura. Esto es algo básico a la par que importante.
Ahora configuramos los datos del direccionamiento IP.
Ya tenemos configurado VCenter. Podemos acceder con el mismo cliente que usamos para acceder al ESXi, el VSphere Client, esta vez indicando la IP del appliance Vcenter, no la del Host ESXi. Hasta VmWare recomienda solo usar VCenter para manejar los hosts, para evitar incoherencias si configuramos aspectos de las dos maneras.
Como podéis ver, es muy similar a cuando entramos en ESXi. Lo primero que vamos a hacer es crear un DataCenter que albergará todos los equipos que tenemos a nuestra disposición. Se recomienda agrupar los DataCenter con un criterio más o menos parecido al de Site de Active Directory, es decir, grupo de recursos unidos por enlaces de alta velocidad. No tiene sentido tener una delegación en Madrid y otra en Barcelona bajo un mismo Datacenter, si físicamente están ubicados en distintos emplazamientos.
Añadimos los dos hosts ESXi que vamos a manejar.
Ya debes ver los dos equipos ESXi bajo el datacenter.
Ahora vamos a pasar directamente a trabajar con Fault Tolerance. Antes de nada vamos a definir unos conceptos.
VMotion es la solución de Vmware para mover máquinas entre distintos HOST. Sería el equivalente a Live Migrations de Microsoft. Ambos en caliente.
Storage VMotion sería la solución de Vmware para mover máquinas virtuales, con su almacenamiento.
HA en VmWare es alta disponibilidad. Esto implica caída del servicio desde que se cae un servidor, hasta que se inicia la máquina virtual en otro servidor ESXi.
Faul Tolerance es tolerancia a fallos cero, en el que caídas de servidores ESXi no interrumpirían el servicio de la máquina virtual.
Esta de moda el término SLA (Services Level Agreement) en el que establecemos distintos parámetros de calidad de servicio. El término 99.9% SLA suele referirse al tiempo que permanece activo un servicio, por ejemplo, la aplicación de la empresa. Cuanto es 99.9% ? es mucho tiempo de caídas de servicio? poco?
365 días x 24 horas= 8760 horas al año.
99.9% de 8760 son 98 horas, 4 días de caída de servicio al año.
99.99% de 8760 es 1 hora.
En que SLA consideras que se mueven tus aplicaciones críticas? Cuanto crees que es tolerable para tus usuarios?
Nos ponemos con ello. Debemos tener al menos una máquina virtual configurado en el almacenamiento compartido, y dependiente de uno de los hosts ESXi.
El proceso de creación de una máquina virtual en ESXi esta muy documentado, por lo que os sugiero que uséis cualquier documento disponible, pero teniendo en cuenta configurar el almacenamiento de la máquina virtual en el DataStore usado bajo FreeNas ( no usar datastore local).
http://www.josemariagonzalez.es/2011/10/03/como-crear-maquinas-virtuales-vsphere-esxi-5.html
Espero que os guste el artículo, y mientras que creáis la máquina virtual, nos vemos en el próximo artículo.
Gracias por leerme.
Hoy vamos a continuar con esta seria de artículos de introducción a la virtualización, instalando VCenter.
VCenter es una aplicación, o conjunto de ellas que nos permite acceder a las funcionalidades avanzadas que trae el producto ESXi. En un entorno Microsoft estaríamos hablando del componente Virtual Machine Manager de System Center 2012.
Como aplicación podemos instalarla de varias maneras. Como un fichero OVF ( Open Virtualization Format) desplegada como un appliance (como una máquina virtual) que podemos descargar desde la web. También podemos instalarla bajo un servidor Windows, virtual o físico. Si elegimos la primera opción, es tan sencillo como descargar el fichero, copiarlo hacia nuestro DataStore del host Esxi que queremos usar para albergar la máquina, e importarlo. Automágicamente se crearán los discos duros y los ficheros de configuración de la máquina virtual. Internamente VCenter usa un motor de base de datos Postgresql. En cada versión las especificaciones cambian, pero a la fecha de hoy podremos gestionar tan solo 5 Host ESXi con este tipo de base de datos. Como base de datos externa podemos usar SOLO ORACLE. Money Money Money. Si instalamos VCenter bajo un sistema Windows podrá emplear tanto SQL Express (gratuita) como SQL Server. Si nos decidimos por esta opción, tenemos que tener en cuenta que debemos gestionar todo el sistema operativo Windows que hay por debajo de VCenter. Si usamos el appliance virtual, estaremos usando una versión especial de Suse Linux, por lo que a priori el mantenimiento es mínimo.
Una de las cosas que más me llamó la atención sobre VCenter es que no se instala bajo tecnologías de Fault Tolerance. Un elemento tan crítico debería implementarlo. Sin embargo desde VMware indican que no es necesario ya que VCenter almacena toda la información en la base de datos, y es esta la que debe ser asegurada, ya que el despliegue de VCenter en un nuevo servidor, como veremos aquí, es cuestión de unos pocos minutos. Yo me quedo con VMM de Ms como pudimos ver aquí, instalar fault tolerance es cuestión de unos pocos minutos, y garantizas el servicio...
**queda claro con esto que solo vamos a instalar VSphere en uno de los dos HOST ESXi...***
Otra de las cosas que no me agradan mucho es el consumo de recursos. VCenter se va a gastar 6Gb de RAM para el solito. Hablando con expertos en la materia consiguen "tunning" hasta unos 4 Gb de RAM, pero me parece muchísimo si lo comparamos con los modestos 2-4Gb que puede consumir Virtual Machine Manager de System Center.
Pensar que con la virtualización queremos conseguir abstracción de la capa Hardware mediante Software, para poder realizar "tareas". Estas tareas pueden ser recuperación ante desastres. En un entorno bien configurado, si necesitamos XX Gb de RAM para un servidor/servicio, debemos reservar otros tantos en un segundo nodo, para hacer nuestra plataforma tolerante a fallos, o al menos alta disponibilidad... Es un handicap que mucha gente pasa por alto, y en el momento de caídas de elementos físicos, se encuentran con que no tienen capacidad para albergar estas Máquinas virtuales que hemos ido creando a golpe de click.
Vamos a al menú File, y deploy OVF. Seleccionamos el fichero OVA que hemos descargado y en unos cuantos clicks tenemos appliance desplegado, que no configurado.
Arrancamos la máquina virtual que se ha creado con VSphere y seguimos el proceso de configuración por defecto que nos propone el instalador, salvo el direccionamiento IP. El usuario es root y la password es Vmware. Como buen experto en seguridad que eres, no cambies esta clave nada más empezar el proceso. A lo largo de varias instalaciones he tenido problemas con esto. Te recomiendo que no cambies esta clave al menos hasta 30 minutos desde que se instaló. Quizás algún experto pueda aclararnos el por qué !!!
Debemos configurar el servidor de tiempo, el mismo que hemos usado en toda nuestra infraestructura. Esto es algo básico a la par que importante.
Ahora configuramos los datos del direccionamiento IP.
Ya tenemos configurado VCenter. Podemos acceder con el mismo cliente que usamos para acceder al ESXi, el VSphere Client, esta vez indicando la IP del appliance Vcenter, no la del Host ESXi. Hasta VmWare recomienda solo usar VCenter para manejar los hosts, para evitar incoherencias si configuramos aspectos de las dos maneras.
Como podéis ver, es muy similar a cuando entramos en ESXi. Lo primero que vamos a hacer es crear un DataCenter que albergará todos los equipos que tenemos a nuestra disposición. Se recomienda agrupar los DataCenter con un criterio más o menos parecido al de Site de Active Directory, es decir, grupo de recursos unidos por enlaces de alta velocidad. No tiene sentido tener una delegación en Madrid y otra en Barcelona bajo un mismo Datacenter, si físicamente están ubicados en distintos emplazamientos.
Añadimos los dos hosts ESXi que vamos a manejar.
Ya debes ver los dos equipos ESXi bajo el datacenter.
Ahora vamos a pasar directamente a trabajar con Fault Tolerance. Antes de nada vamos a definir unos conceptos.
VMotion es la solución de Vmware para mover máquinas entre distintos HOST. Sería el equivalente a Live Migrations de Microsoft. Ambos en caliente.
Storage VMotion sería la solución de Vmware para mover máquinas virtuales, con su almacenamiento.
HA en VmWare es alta disponibilidad. Esto implica caída del servicio desde que se cae un servidor, hasta que se inicia la máquina virtual en otro servidor ESXi.
Faul Tolerance es tolerancia a fallos cero, en el que caídas de servidores ESXi no interrumpirían el servicio de la máquina virtual.
Esta de moda el término SLA (Services Level Agreement) en el que establecemos distintos parámetros de calidad de servicio. El término 99.9% SLA suele referirse al tiempo que permanece activo un servicio, por ejemplo, la aplicación de la empresa. Cuanto es 99.9% ? es mucho tiempo de caídas de servicio? poco?
365 días x 24 horas= 8760 horas al año.
99.9% de 8760 son 98 horas, 4 días de caída de servicio al año.
99.99% de 8760 es 1 hora.
En que SLA consideras que se mueven tus aplicaciones críticas? Cuanto crees que es tolerable para tus usuarios?
Nos ponemos con ello. Debemos tener al menos una máquina virtual configurado en el almacenamiento compartido, y dependiente de uno de los hosts ESXi.
El proceso de creación de una máquina virtual en ESXi esta muy documentado, por lo que os sugiero que uséis cualquier documento disponible, pero teniendo en cuenta configurar el almacenamiento de la máquina virtual en el DataStore usado bajo FreeNas ( no usar datastore local).
http://www.josemariagonzalez.es/2011/10/03/como-crear-maquinas-virtuales-vsphere-esxi-5.html
Espero que os guste el artículo, y mientras que creáis la máquina virtual, nos vemos en el próximo artículo.
Gracias por leerme.
