Entradas con la etiqueta ‘hyper-v’
Plataformas cloud open source y su integración con Amazon
En el anterior artículo os presenté las características de la nueva versión de Eucalpytus, plataforma IaaS para construir clouds públicas y privadas. Una de las principales características de Eucalyptus es su integración con el API de Amazon. La pregunta que nos planteamos hoy es si ésta es una estrategia adecuada o no. Gracias a un artículo de Lauren Nelson, analista de Forrester, intentaremos dar respuesta a esta pregunta.
La realidad es que el 48% de los clientes de servicios cloud públicos utilizan algún servicio de Amazon. La posibilidad de que plataformas cloud ofrezcan integrarse con Amazon puede hacer que sean más atractivas para nuevos posibles clientes. De este modo, la adopción de servicios cloud se incrementará.
Actualmente, los principales proyectos open source para gestionar clouds son OpenStack, CloudStack y Eucalyptus. Éstos se presentan como una alternativa a Amazon Web Services (AWS), pero dos de ellos (CloudStack y Eucalyptus) han «copiado» el API de Amazon para permitir la compatibilidad con ciertas plataformas de AWS.
Por el contrario, OpenStack ha escogido de momento no clonar el API de Amazon. Según OpenStack, copiar el API de Amazon no produce una copia exacta de los servicios y características de ésta y, por lo tanto, puede no escalar adecuadamente de acuerdo a las necesidades de los usuarios. RackSpace, una de las principales empresas detrás del proyecto OpenStack, ha promulgado la necesidad de que exista una plataforma realmente abierta que se establezca como alternativa a las plataformas cloud propietarias.
Según Nelson, tiene bastante sentido el hecho de que plataformas cloud utilicen el API de Amazon ya que sus servicios tienen un alto nivel de adopción. Lo que los usuarios no quieren es nuevas APIs, quieren más estandarización. Por lo tanto, no tener en cuenta las oportunidades de interoperar con Amazon, podrían aislar los esfuerzos realizados en ciertas plataformas open source.
Construye tu propia cloud privada con Eucalyptus
Eucalyptus es el principal competidor de OpenStack en lo que se refiere a fabricantes de plataformas IaaS para construir clouds privadas y públicas. Eucalyputs está posicionado en el segmento de clientes que no quieren atarse a un determinado fabricante de tecnología de virtualización (hypervisor).
El pasado mes de Junio, Eucalyputs liberó la versión 3.1 de su producto. La nueva versión completa el proceso de reestructuración de la plataforma que comenzó con la versión 3.0. En este sentido, entre los cambios más significativos podemos encontrar mejoras en lo que se refiere a modularidad, permitiendo a desarrollares externos crear plug-ins y herramientas que añaden funcionalidades a la plataforma cloud.
A continuación os indicamos otras mejoras introducidas en la nueva versión de Eucalyptus:
- Permite crear desarrollos cloud bajo demanda en la última version de RHEL con Amazon EC2, Amazon EBS, Amazon S3 y Amazon IAM. Para ello permite utilizar plataformas de virtualización Red Hat Enterprise Virtualization y VMware. .
- Servicio FastStart, un sistema de auto-servicio automatizado que permite crear máquinas virtuales en menos de 20 minutos.
- Plug-ins para añadir funcionalidades a la plataforma cloud.
Eucalyptus vs OpenStack
Las principales diferencias entre Eucalyptus y OpenStack son:
- OpenStack está desarrollando su propia API. Es conocida la relación entre Eucalyptus y Amazon. Esta relación permite a Eucalyptus utilizar y desarrollar servicios basados en el API de Amazon Web Services.
- Eucalyptus es es un producto paquetizado, mientras que OpenStack es un conjunto de componentes a veces sin relación entre ellos.
- La integración de Eucalyptus con Amazon EC2, permite a los usuarios mover cargas de trabajo entre nubes públicas de Amazon y su nube privada basada en Eucalyptus. Esto no es posible en OpenStack.
- Tiene soporte para múltiples hypervisores: VMware ESXi, KVM, Xen y Microsoft Hyper-V.
Beneficios derivados de utilizar distintos hypervisores
En el actualidad, el 90% de las empresas de 100 empleados o más, han adoptado algún tipo de solución de virtualización. Pero en realidad, la mayoría ligeramente se ha beneficiado de todo el potencial que les puede aportar. Según un informe reciente de Gartner, la utilización de los servidores en los centros de datos es sólo del 18%, prácticamente el mismo porcentaje que hace cuatro años.
La virtualización no sólo permite ahorrar costes, también permite a las empresas obtener plataformas IT más ágiles, más fácilmente replicables y adaptables a las necesidades de los usuarios. Pero para que las empresas puedan obtener esos beneficios, deben superar desafíos como: el hecho de tener centros de datos más heterogéneos, falta de herramientas de gestión centralizadas, etc. Otra barrera al despliegue de la virtualización es utilizar tecnología de un único fabricante de virtualización, lo cual puede producir ineficiencias o perde oportunidades de crecimiento por no desplegar la tecnología de hypervisor más adecuada a nuestra infraestructura.
Un modo de optimizar e incrementar el despliegue de la infraestructura de virtualización, es utilizar más de un hypervisor. Si somos capaces de centralizar la administración de múltiples hypervisores podemos obtener beneficios en lo que se refiere a reducción de costes de licencias, evita que dependamos de un único fabricante, incrementa el nivel de consolidación, facilita la construcción de una solución cloud o permite una integración más eficiente de todas nuestras aplicaciones. Para ello es fundamental disponer de una infraestructura de gestión que soporte soluciones de virtualización y de hardware heterogéneas. De este modo seremos capaces de manejar nuestra infraestructura de virtualización desde una única plataforma.
Como integrar tácticas de Alta Disponibilidad en infraestructuras virtuales
La virtualización de servidores permite a las empresas reducir el número de servidores físicos, en ocasiones en un ratio de 20 a 1. Cada Host físico es capaz de ejecutar múltiples cargas de trabajo en producción. Por lo tanto, en un entorno de virtualización somos muy dependientes de la disponibilidad de los Host sobre los que se ejecutan nuestras máquinas virtuales.
Dependiendo del tipo de empresa, es probable que necesiten que sus aplicaciones estén funcionando continuamente. Con el objetivo de garantizar una alta disponibilidad a nuestra aplicaciones, podemos utilizar una combinación de técnicas. Actualmente existen principalmente cuatro técnicas de hacer que las aplicaciones ejecutándose en nuestras máquinas virtuales estén siempre disponibles:
- Clusters de Host físicos.
- Clusters Guest Failover.
- Clusters Network Load Balancing (NLB).
- Máquinas virtuales tolerantes a fallos.
Cada una de estas opciones puede dar a nuestras máquinas virtuales un nivel específico de disponibilidad. La importancia de que una determinada aplicación esté siempre funcionando marcará el método a escoger.
Utilizar una configuración en cluster de alta disponibilidad (HA) nos permite poder tratar potenciales incidencias en nuestro entorno:
Protegemos el sistema de fallos en los Hosts físicos: en la mayoría de los sistemas de alta disponibilidad, cuando un Host falla las máquinas virtuales que ejecuta son migradas a otros Hosts (incurriendo en pérdida de servicio durante el reinicio de la máquina virtual); o las aplicaciones que se ejecutan dentro de una máquina virtual son movidas a otras máquinas virtuales (resultando en una menor pérdida de servicio). También nos podemos proteger contra pérdidas de servicio utilizando técnicas como la tolerancia a fallos. Por ejemplo VMware tiene el producto VMware Fault Tolerance que nos permite tener una máquina virtual imagen protegiéndonos frente a corrupción de datos y pérdidas de servicio.
Podemos seguir ejecutando aplicaciones durante períodos de mantenimiento de los Host físicos: las máquinas virtuales serán migradas a los otros Hosts disponibles en el cluster evitando pérdidas de servicio.
Dinámicamente podemos mover las cargas de trabajo de una máquina a otra: nos aseguramos de que las aplicaciones se ejecutan con un rendimiento óptimo.
¿Qué estrategia HA es mejor?
La importancia de la aplicación para la empresa determinará qué método deberemos utilizar. Como mínimo deberemos configurar un cluster HA entre los Host físicos.
Un cluster HA nos permitirá obtener dos niveles de continuidad de servicio:
- Ejecución no-continua de máquinas virtuales. Si un Host falla, todas las máquinas que está ejecutando serán transferidas a otros hosts reiniciándose automáticamente.
- Ejecución continua de máquinas virtuales durante operaciones de mantenimiento. Podemos transferir las máquinas a otros hosts disponibles sin pérdida de servicio.
Single-Site y Multi-Site Clusters
Los clusters single-site se basan en la utilización de almacenamiento compartido. Por ejemplo, VMware utiliza dos tecnologías para construir un cluster de alta disponibilidad: HA y su sistema de ficheros VMFS (sistema de ficheros que permite a múltiples hosts físicos conectarse al mismo contenedor de almacenamiento). VMFS requiere un sistema de almacenamiento SAN (iSCSI o Fiber Channel) o NFS. Los clusters VMware pueden soportar hasta 32 nodos.
Los sistemas Citrix también utilizan un sistema de almacenamiento compartido y pools de recursos. A diferencia de otros sistemas que se basan en un sistema de base de datos para gestionar la alta disponibilidad, cada Host Citrix XenServer almacena su propia copia de la configuración de pool de recursos. De este modo se elimina un potencial punto de fallo. Al igual que VMware, los clusters Citrix soportan hasta 32 nodos.
Por último, Microsoft Hyper-V utiliza la tecnología Windows Server 2008 Failover Clustering para crear clusters HA. Los cluster Hyper-V single-site requieren un sistema de almacenamiento compartido y soportan hasta 16 nodos. Hyper-V también soporta clusters multi-site que abarcan más de una localización física. De este modo podemos hacer frente a desastres que afecten a uno de nuestros centros de datos. Para dar soporte a clusters multi-site, Hyper-V soporta tecnologías DAS (no requiere almacenamiento compartido) que deben ser sincronizadas mediante herramientas de replicación.
En todos estos sistemas, cuando un cluster detecta que un nodo falla de manera completa, el servicio de cluster mueve las máquinas virtuales a otros nodos disponibles. A diferencia de una migración en vivo entre nodos, este proceso de migración reinicia la máquina virtual en el nuevo nodo, incurriendo en una pérdida de servicio.
Hay que recordar que se deben tener recursos disponibles en cada Host físico del cluster para soportar el movimiento de máquinas virtuales. Por ejemplo, VMware muestra un mensaje de error si los recursos disponibles no son suficientes.
Clusters tolerantes a fallos
Como hemos comentado, un cluster a nivel de Host no incluye a las aplicaciones que se están ejecutando en las máquinas virtuales. Por lo tanto, no se asegura que la aplicación se ejecute en caso de que un Host falle.
Algunas aplicaciones como Microsoft Exchange no se comportan adecuadamente bajo este modelo y pueden incurrir en pérdidas de datos cuando tiene lugar una transferencia entre Hosts. Para este tipo de aplicaciones tenemos que pensar en construir clusters de alta disponibilidad a nivel de máquina virtual. De este modo aseguraremos la disponibilidad y estabilidad de nuestras aplicaciones en caso de fallo físico o de aplicación.
Estos clusters tolerantes a fallos trabajan sólo para cargas de trabajo stateful. Para cargas de trabajo stateless tendremos que utilizar clusters NLB, también soportado a nivel de capa de máquina virtual.
Para construir este tipo de soluciones, tendremos que preparar complejas configuraciones a nivel de máquina virtual (ver imagen inferior un ejemplo). A diferencia de otros fabricantes, VMware dispone del producto Fault Tolerance. Gracias a este producto creamos imágenes en vivo de máquinas virtuales que se sincronizan continuamente permitiéndonos obtener de manera sencilla alta disponibilidad a todos los niveles.
¿Qué tecnología de hypervisor de virtualización elegir?
Hoy vamos a hablar de 10 hypervisores existentes en el mercado, presentando sus pros y contras y aspectos a tener en cuenta a la hora de elegir cual se adapta más a nuestras necesidades.
Antes de presentar los distintos hypervisores es necesario que diferenciemos entre los tipos de tecnologías existentes: bare-metal y hosted.
Hypervisores Bare-metal
Un hypervisor bare-metal no funciona bajo un sistema operativo instalado sino que tiene acceso directo sobre los recursos hardware. Esto significa que obtendremos un mejor rendimiento, escalabilidad y estabilidad. Por contra, en este tipo de tecnología de virtualización el hardware soportado es más limitado ya que normalmente es construido con un conjunto limitado de drivers.
La tecnología bare-metal se adapta mejor a centros de datos empresariales. Esto es porque dispone de características avanzadas como la administración de recursos, alta disponibilidad, seguridad y administración centralizada de la infraestructura de virtualización.
Entre los hypervisores de este tipo encontramos: VMware ESX o ESXi, Microsoft Hyper-V, Citrix XenServer u Oracle VM.
VMware ESX y ESXi
VMware es el fabricante con la tecnología de virtualización más madura del mercado. Ofrece características avanzadas y escalabilidad. En contra tiene los altos costes de licenciamiento.
Microsoft Hyper-V
Desde su lanzamiento, Hyper-V se ha convertido en un serio competidor de VMware ESX (ESXi). En contra tiene que no dispone de ciertas características avanzadas disponibles en los productos de VMware. De todos modos, como no podía ser de otra forma, se integra perfectamente con los productos Windows. Para aquellos que no necesitan funcionalidades avanzadas, puede ser un producto perfecto para llevar a cabo su proyecto de virtualización.
Citrix XenServer
Citrix también tiene una plataforma de virtualización basada en el proyecto open source Xen. El hypervisor es gratis, pero de igual modo a como pasa con VMware ESXi, no dispone de características avanzadas. Éstas se obtienen a partir de licencias que ofrecen gestión avanzada, automatización y alta disponibilidad.
Oracle VM
De igual modo a Citrix, Oracle ha desarrollado su hypervisor a partir del proyecto Xen. El producto de Oracle no presenta funcionalidades avanzadas que podemos encontrar en otros hypervisores bare-metal. Además su ciclo de desarrollo es lento y limitado, por lo que no puede competir con los productos de VMware, Microsoft o Citrix. Sin embargo, como es lógico, es un producto que se adapta perfectamente a los productos de Oracle.
Hypervisores Hosted
A diferencia de un hypervisor bare-metal, un hypervisor hosted requiere que instales primero un sistema operativo sobre el cual se instalará el software de virtualización, de igual modo a como se instala cualquier aplicación. Esta tecnología presenta una compatibilidad mayor con el hardware que la bare-metal, debido a que es el propio sistema operativo el que se encarga de gestionar los drivers.
Por el contrario, presenta claras desventajas. Al no tener acceso directo sobre el hardware, y funcionar bajo un sistema operativo, se incrementa la utilizació de recursos lo cual puede degradar el rendimiento de la máquina virtual. Pensemos en que el sistema operativo tendrá sus propias aplicaciones y servicios funcionando lo cual está quitando recursos disponibles a las máquinas virtuales que se ejecuten.
Este tipo de tecnología es típica de utilizar en estaciones de trabajo, principalmente para propósitos de testing, desarrollo o para aquellos que necesiten ejecutar más de un sistema operativo.
Los hypervisores hosted más populares son: VMware Workstation/Fusion/Player/Server, Microsoft Virtual PC, Oracle VM VirtualBox, Red Hat Enterprise Virtualization (KVM) y Parallels Desktop.
VMware Workstation/Fusion/Player/Server
VMware Player es un hypervisor gratuito que sólo puede ejecutar una única máquina virtual, no permitiendo crear nuevas máquinas virtuales.
VMware Workstation es un hypervisor más robusto con algunas características avanzadas como soporte para snapshots o guardado de estado. Es disponible pagando en torno a 189 USD. Se suele utilizar en entornos de testing o desarrollo. VMware Fusion es una versión limitada de Workstation para Mac.
VMware Server es una plataforma de virtualización similar a la versión Workstation pero con ciertas limitaciones. Por ejemplo sólo soporta un snapshot por máquina virtual. Este hypervisor está diseñado para ser administrado vía red y está optimizado para ejecutar cargas de trabajo tipo servidor. Desde 2009 VMware ha detenido el desarrollo de este software, pero sigue siendo una alternativa a la utilización de ESXi.
Microsoft Virtual PC
En 2003 Microsoft adquirió la tecnología Virtual PC de la empresa Conectix. Su última versión, Windows Virtual PC es gratuita y sólo corre bajo Windows 7. Únicamente soporta la ejecución de sistemas operativos Windows. Un uso común de Virtual PC es la ejecución de versiones antiguas de Windows.
Oracle VM VirtualBox
VirtualBox es una tecnología madura con un rendimiento razonable y características avanzadas bajo un presupuesto ajustado. A pesar de ser gratuito, VirtualBox comparte características con vSphere e Hyper-V. Por lo tanto, es una alternativa a tener en cuenta frente a tecnologías más caras.
Red Hat Enterprise Virtualization
Red Hat Kernel-Based Virtual Machine o KVM presenta características de las soluciones hosted y bare-metal. KVM convierte el kernel de Linux en un hypervisor, de tal modo que las máquinas virtuales tienen acceso directo sobre el hardware físico. KVM ofrece características avanzadas de nivel empresarial y viene con un sistema de administración bajo Windows para realizar la gestión de múltiples hosts (de modo similar a vSphere).
Parallels Desktop
El producto de Parallels Desktop es conocido en su versión para Mac, siendo muy similar a VMware Fusion. Parallels también tiene una versión de escritorio para Windows o Linux. Adicionalmente, tiene una edición más potente llamada Parallels Server para Mac, que dispone de características avanzadas. Es un producto razonable en cuanto a prestaciones/precio.
Conclusiones
Todos estos productos están disponibles de forma gratuita (ya sea en modo evaluación o gratis). Por lo tanto recomendamos que pruebes los hypervisores y veas cuál se ajusta mejor a tus necesidades.
No se debe intentar que el hypervisor elegido haga más de para lo que está diseñado. Por ejemplo, no esperes que un servidor Exchange con un número elevado de cuentas de correo y/o tráfico tenga un rendimiento óptimo sobre una solución hosted.
Recuerda que las máquinas virtuales pueden ser migradas entre distintas tecnologías de virtualización. En el caso de que la tecnología escogida no se ajuste a tus necesidades, puedes migrar tus máquinas virtuales a otra tecnología de virtualización.
Bienvenido a Virtualizamos
