Entradas con la etiqueta ‘maquina virtual’

Del modelo P2V a V2C. ¿Qué debemos tener en cuenta si nos movemos a la nube?

Antes de la explosión de servicios en la nube, y con las tecnologías de virtualización maduras, las empresas se preocupaban de cómo migrar sus servidores físicos a plataformas de virtualización. A este modelo lo conocemos como physical-to-virtual (P2V).

En P2V los responsables IT se preocupan de qué servidores físicos se adaptan mejor a un entorno de virtualización. Existen herramientas que permiten automatizar el proceso de virtualización y, salvo alguna excepción, la mayoría de servidores físicos pueden ser virtualizados.

En la actualidad, con cada vez más proveedores cloud en el mercado, el modelo ha cambiado a ser virtual-to-cloud (V2C). De igual modo que en P2V, no todas las máquinas virtuales (VM) se adaptan a un entorno cloud. En este sentido, los responsables IT deberían considerar varios aspectos:

 

Costes de transferencia

El modelo cloud computing, basado en capacidades ilimitadas, reemplaza la relación entre  hardware y costes por otro basado en el consumo de recursos (CPU, red, memoria, almacenamiento, etc.). Este modelo permite a las empresas conseguir grandes ahorros de costes.

Antes de iniciar un proceso V2C, deberemos prestar atención a cuantos recursos utilizan nuestras máquinas virtuales (prácticamente todas las plataformas de virtualización nos permiten obtener métricas). De este modo, podremos calcular nuestros costes y prevenir sorpresas una vez que nuestra máquina virtual haya sido migrada a la nube.

 

Monitorización y verificación

Antes de mover tus máquinas virtuales a un proveedor cloud, planifica como vas a monitorizarlas. De este modo podremos asegurarnos que nuestro proveedor se ajusta a nuestras expectativas.

 

Herramientas de migración

Mientras que existen muchas herramientas en el mercado para realizar migraciones tipo P2V, existen pocas para realizar migraciones V2C.

En la actualidad existen soluciones (como Racemi, AppZero y Citrix NetScaler), pero éstas son dependientes de una plataforma en concreto y tienden a ser unidireccionales. Es decir, podemos mover máquinas virtuales a la nube pero no en sentido contrario. Es posible que tengamos que cambiar de proveedor o nuestras necesidades requieran de traer las máquinas virtuales de vuelta a nuestro data center.

 

Conexión entre proveedor y cliente

El modelo cloud falla cuanta la capacidad de red entre el proveedor y nuestra red no se ajusta a nuestra demanda. Por ejemplo, podemos tener un servicio de Exchange en la nube y tener un rendimiento muy bajo si la red entre nuestro Outlook y el servidor no es capaz de soportar toda la demanda de nuestros usuarios.

Por lo tanto, los responsables IT deberán establecer sistemas de monitorización y medida del uso de red para poder vigilar el estado y adelantarse a posibles cambios en la demanda.

Share

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.

Share

vSphere Storage DRS. Nueva funcionalidad de vSphere 5

Ayer os presentábamos a grandes rasgos las mejoras introducidas en la versión 5 de vSphere. Hoy vamos a profundizar en una de las innovaciones introducidas: Storage DRS.

En vSphere 4 apareció el concepto DRS (Distributed Resource Scheduler) aplicado a procesamiento. Esta característica permitía de manera automática distribuir la ejecución de las máquinas virtuales entre los hosts disponibles en función de la carga de éstos.

Ahora VMware aplica el concepto DRS al almacenamiento. De este modo, vSphere es capaz de alojar dinámicamente máquinas virtuales en un determinado «storage» en función de las entradas/salidas (I/O) y el espacio ocupado en el mismo. De este modo se reducen los esfuerzos en las decisiones a tomar en el alojamiento de una determinada máquina virtual así como en la monitorización del almacenamiento.

Para poder aplicar DRS, vSphere 5 introduce el concepto de cluster de datastore. Un cluster de almacenamiento es, desde la perspectiva de un administrador, un conjunto de discos (datastores) agregados en una única unidad. Cuando se crea un cluster de este tipo, Storage DRS puede administrar los recursos de almacenamiento de igual manera a como hace DRS a nivel de procesamiento para un cluster de hosts, balanceando la carga entre los discos disponibles en el cluster.

En la siguiente imagen se muestra un cluster de 12TB formado por cuatro datastores de 3TB.

 

En este esquema, durante la creación de una máquina virtual es posible seleccionar un cluster DRS como destino para almacenar sus discos virtuales. A continuación, el sistema es capaz de detectar, en función de la carga en I/O y espacio utilizado, el datastore sobre el que se almacenará inicialmente la máquina virtual. De este modo se minimiza el riesgo de cuellos de botella e impactos en el rendimiento por agregar una nueva máquina virtual.

Storage DRS también permite crear reglas de afinidad (affinity rules) que controlan que discos virtuales deberían estar alojadas o no en un mismo datastore dentro de un cluster. Aunque por defecto, los discos virtuales de una misma máquina virtual se alojan juntos en el mismo datastore, existen tres tipos de reglas de afinidad:

  • VMDK Anti-Affinity: discos virtuales de una máquina virtual con múltiples discos virtuales son alojados en diferentes datastores.
  • VMDK Affinity: discos virtuales son alojados juntos en un mismo datastore.
  • VM Anti-Affinity: dos máquinas virtuales específicas, incluídos sus discos, son alojados en diferentes datastores.

 

Share

Las novedades de vSphere 5. La nueva plataforma de virtualización de VMware

Como os dijimos en un post anterior, ayer 12 de Julio fue el día elegido por VMware para lanzar su nueva plataforma de virtualización: vSphere 5.  Sin entrar en detalles, os vamos a presentar a grandes rasgos las novedades de esta nueva versión:

Servicios de Infraestructura: computación, almacenamiento y red

Computación

  • Nueva versión del hypervisor ESXi que incluye mejoras en el rendimiento, escalabilidad, fiabilidad, seguridad y gestión. VMware se centra en único hypervisor (ESXi) y descarta seguir desarrollando ESX.
  • vSphere Auto Deploy. Nuevo modelo  que permite desplegar y parchear hosts en minutos y de manera más eficiente.
  • Nueva generación de hardware virtual con la versión 8 de máquinas virtuales. VMware las denomina Super VMsy presentan las siguientes caractarísticas:
    • Hasta 32 vCPU por VM
    • Hasta 1TB de memoria RAM por VM
    • Soporte para graficos 3D para ejecutar Windows Aero y aplicaciones basicas 3D en las VMs.
    • Soporte de dispositivos USB 3.0. Se soportan dispositivos USB 3.0 atachados al equipo que ejecuta vSphere Web Client o vSphere Client, para que esto puedas ser conectados a una MV. Por ahora no está soportado la conexión de dispositivos USB 3.0 directamente en los hosts ESXi.
  • Soporte para productos de la compañía Apple. OS X Server 10.6 (Snow Leopard) está disponible como sistema operativo invitado (guest) para máquinas virtuales.

Almacenamiento

  • vSphere Storage DRS. Gestión mejorada y más eficiente en el uso de recursos de almacenamiento evitando los cuellos de botella en el Storage. Es posible agrupar y administrar datastores similares como un unico recurso balanceado llamado Datastore Cluster. Storage DRS realiza la ubicación inicial de los archivos VMDK y recomendaciones de migraciones para evitar cuellos de botella de I/O y utilización de espacio.
  • Gestión de políticas inteligente de los recursos del datacenter para automatizar procesos que antes se realizaban de forma manual. Por ejemplo el parcheado de hosts vSphere, ubicación dinámica, balanceo y perfiles de almacenamiento con diferentes niveles de servicio.
  • Nueva versión de VMFS (vSphere File System) con una escalabilidad y rendimiento mejorada.
  • Control I/O en almacenamiento NFS que permite establecer shares y límites en este tipo de datastores.
  • Programa vSphere Storage API . Extensiones para interactuar con arrays cuando se utiliza Storage DRS.

Red

  • Nuevos controles I/O de red por máquina virtual que permiten aplicar diferentes niveles de servicio.
  • Mejoras en los switches distribuidos que permiten aumentar la visibilidad del tráfico a través de NetFlow. Mejoras en la monitorización y resolución de incidencias a través de un analizador de puertos (Switched Port AnalyzerSPAN) y soporte para LLDP (Link Layer Discovery Protocol).

Servicios de Aplicación: disponibilidad y seguridad

Disponibilidad

  • Modelo más simple y completo de alta disponibilidad y recuperación ante desastres.
  • Mejoras en vMotion que permite la migración de máquinas virtuales en redes con latencias grandes.

Seguridad

  • Nuevo servicio ESXi Firewall que restringe el acceso a servicios específicos por dirección IP o Subred. Útil para componentes de terceros que requieren acceso a la red.

Gestión de Servicios

  • Gestión flexible de clouds híbridas desde un panel simple y a través de un navegador web.
  • Amplio soporte de diferentes proveedores de software y hardware, incluyendo más de 1.400 proveedores independientes de software (ISV) que permiten ejecutar más de 2.500 aplicaciones en vSphere.
Share

Bienvenido a Virtualizamos

Virtualizamos es un proyecto de la empresa nerion que nace con el objetivo de convertirse en un portal de referencia en el mundo de la virtualización y el cloud computing.
Suscripción a Virtualizamos
Entradas antiguas por mes
Twitter
nerion - Registro Dominios, Hosting y Housing Profesional