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.