jueves, 31 de octubre de 2013

Resumen del área de sistemas.

Voy a resumir un poco los últimos artículos de INSEGUROS sobre sistemas para poder poner algo de orden.

Si quieres aprender sobre el mundo de la virtualización y el cloud, este humilde blog es una buena manera de obtener muchos conceptos. Será uno de los muchos recursos que debas tomar, pero este es gratis.

Virtualización de escritorios con Windows 1 2 y 3
DHCP redundante con Windows 2012. Aquí.
Token Kerberos y Dynamic Access 1 2 y 3
Branch Cache. Aquí.
Seguridad en Windows 1 2 y 3
Nic Teaming en Windows 2012. Aquí.
Recuperación ante desastres 1, 2, 3, 4 y 5 .
Certificate Services Windows 2012. 1, 2 y 3
ISCSi Target y cluster Sql Server. Aquí
Virtual Machine Manager 2012. aquí
Cluster Hyper-V. Aquí.
Services Manager 2012. Aquí.
Orchestrator 1 3
Configuration Manager 2012. Aquí.
WSUS para System Center. Aquí.
Portal Self Services 1 
Windows Azure. Aquí 

Introducción a la virtualización, almacenamiento, ESXi y Vcenter.



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.





miércoles, 30 de octubre de 2013

Introducción a la virtualización. Install ESXi 5.5 y almacenamiento SAN.

En el post de hoy vamos a iniciar el proceso para crear dos servidores HOST ESXi desde cero. Configuraremos un almacenamiento compartido mediante ISCSi con un servidor virtual FREENAS.

Para realizar esta práctica necesitas haber instalado y configurado el sistema FREENAS de este artículo. Si prefieres usar un almacenamiento bajo Windows, debes tener configurada la parte de ISCSi de este artículo. Perdón, eso en el caso de que no tengas una cabina de discos física disponible para las pruebas.

Para instalar los dos HOST ESXi necesitamos dos ordenadores. Si no tienes dos pc disponibles, puedes usar cualquier Hypervisor tipo 2 ( Vmware Workstatio, player, Parallels, VirtualBox etc). En el artículo no haremos referencia a que estos equipos estén físicos o virtuales. Yo por ejemplo voy a usar un HOST ESXi físico que ya tengo instalado, y usaré uno virtual sobre mi portátil mediante VMware Player.

Lo primero que vamos a hacer es descargar la versión gratuita de Vmware Vsphere ESXI 5.5. Una vez tengamos la imagen ISO descargada, la grabamos a un cd y arrancamos el equipo para instalarlo. Si estás en un laboratorio con VirtualBox, deberás crear una máquina virtual desde cero, y añadirle la ISO al CD-ROM. Debéis configurar 2 CPU virtuales y 4Gb Ram para poder iniciar la instalación. Podéis seguir este manual, gracias al amigo de 1GB de Información.

El proceso de instalación de un HOST ESXi es tan sencillo como esto:










Ahora ya tenemos instalado el sistema operativo que hará de hypervisor tipo 1 ESXi. Recuerdo un día que le explique un poco el asunto a un amigo, y se cabreo cuando instalo el ESXi sobre su equipo físico para sus pruebas, y me dice: Kino esto que es, no puedo hacer nada. En efecto. Hemos instalado el sistema operativo, ahora debemos instalar un cliente, al cual nos conectaremos por red para trabajar con VmWare ESXi. Hablamos de un Kernel de unos 30 MB, no querrás que también tenga interface gráfico...


Accedemos a la URL y descargamos/ejecutamos el cliente.


Seguimos con la consola del ESXi y pulsamos F2 para acceder a las pocas tareas que podemos administrar localmente.



Básicamente vamos a configurar una dirección IP estática, para poder acceder desde el cliente VSphere que hemos instalado en nuestro equipo.



Como podéis leer en la advertencia, desde hace unos versiones hay opciones que no están disponibles mediante el cliente VSphere que hemos instalado, y solo se pueden acceder mediante la consola web de administración. De momento vamos a trabajar con el Client. ya que en la mayoría de sitios se hace referencia a este cliente, y no al WEBClient que de momento, deja bastante que desear.
Este es nuestro HOST ESXi listo para virtualizar.


Lo primero que vamos a hacer es configurar la sincronización con la hora mediante un servidor NTP. Es básico si no quieres tener problemas entre los HOSTS. Para ello, accedemos a Configuration, Time Configuration.



Repetimos esta operación con el segundo Hosts ESXi para tener dos equipos listos para realizar Fault Tolerance.

Ya tenemos preparado Out of a Box el ESXi. Antes de comenzar a instalar máquinas virtuales, vamos a trabajar con los conceptos que comentamos en el post de Almacenamiento y FreeNas para añadir un DataStore en red, que usaremos en ambos equipos ESXi para compartir almacenamiento.

Cuando instalamos un ESXi por defecto crea un vSwitch con dos tipos de puertos, VM y Kernel. Los primeros digamos que serían como bocas de un switch físico que sirven para comunicar las máquinas virtuales entre sí, y contra el mundo físico. Los puertos de tipo Kernel son unos puertos específicos para las tareas internas del equipo.


Para conectar un almacenamiento ISCSi externo por IP, debemos conectar un puerto tipo Kernel ( ya que realmente será el ESXi el que controle el almacenamiento, no las máquinas virtuales).
Entramos en properties del Vswitch0 y añadimos un puerto tipo Kernel, tal y como muestro:




Ahora tenemos a nivel de Networking, todo preparado para añadir un almacenamiento ISCSi. Ahora desde Configuration, Storage Adapters configuramos la "tarjeta" que conectará con el almacenamiento.






Ahora vinculamos el puerto tipo Kernel del Switch para que sea usado por el iniciador ISCSi. y configuramos la dirección del servidor FREENAS.





Bien. Hasta ahora, solo hemos configurado digamos "el cable" que conecta el equipo al almacenamiento. Como vimos en el anterior post, vamos a configurar un DATASTORE para que ESXi almacene sus máquinas virtuales en ese disco en red.
Hasta este punto, en Hyper-V sería tan sencillo como la segunda parte de este post. Configurar desde el panel de control el destino ISCS mediante una IP.

Este procedimiento lo debemos hacer en el segundo HOST ESXi que estamos configurando.

Ahora desde Configuration, Storage, añadimos un nuevo Datastore que use el disco.







Hasta aquí todo bien. Quizás no !!! Existe un Bug en la versión actual de FREENAS 9.1.1 por el que si usamos un disco para ISCSi y lo particionamos, no se puede volver a particionar. Esto es un bug de FREENAS. Si has usado la práctica anterior con FREENAS y has creado una partición NTFS para poder montar esta LUN en un Windows, cuando agregues este almacenamiento a ESXi e intente formatearlo como VMFS vas a tener un error. La solución es crear un Extend en Freenas con otro disco.

Si todo ha ido bien, tendrás dos DataStores disponibles en tu ESXi.
Hasta aquí, en un entorno Hyper-V solo tendríamos que ir al administrador de discos, y particionar el nuevo disco.


Ahora es el turno de realizar este último paso en el segundo HOST hasta el paso del DataStore. Es decir, una vez que conectemos el disco mediante ISCSi, en la sección de DataStores tendremos disponible el disco ya particionado.

Ahora tenemos dos equipos en cierta alta disponibilidad. Si el equipo que ejecuta la máquina virtual se detuviese, podríamos manualmente ir al segundo HOST, importar la máquina virtual al ESXi( solo la configuración, el disco duro virtual no ya que usamos almacenamiento compartido !!!) y arrancarla. Esto conlleva ventana de caída de servicio, mínimo el tiempo de enterarte e iniciar la máquina.

Para hacer uso de las tecnologías de alta disponibilidad automáticas, tolerancia a fallos ( cero downtime) y demás, debemos hacer uso de Vpshere. En sistemas Hyper-V usaríamos el complemento Virtual Machine Manager de System Center.

Vpshere es de pago, aunque podemos probarlo alegremente durante 60 días. Esta es la clave del licenciamiento en la virtualización. El fabricante te ofrece algo básico gratuitamente, y todos los featuring que queremos, los pagamos. Hay algo bueno, y es que Microsoft está ofreciendo todos los servicios relativos a virtualización y cloud en un producto, SYSTEM CENTER 2012 bastante asequible. Los amigos de OpenStack y KVM aquí darían un golpe en la mesa, argumentando que en esos sistemas no hay que pagar. En efecto, pero el coste de configurar Fault Tolerance entre dos host KVM puede que sea bastante superior que pagar la licencia en un sistema propietario y configurarlo en unos minutos... cada uno...

Creo que se ha extendido demasiado este artículo. En el próximo instalaremos Vsphere, el software que va a hacer posible todas las funciones extras para ESXi, y en concreto la "conexión" o "trabajo en grupo" de varios host ESXi.

Gracias por leerme.