Tecnologias Aplicadas - El Blog de Patricio Cerda

VMware finalmente lanza vCenter Operations Management Suite!

2012-01-25T11:08:00.000-03:00

Hola a todos!

El dia de hoy VMware acaba de lanzar finalmente su nueva suite de gestión "vCenter Operations Management Suite", la cual habia sido anunciada previamente en el VMworld 2011 en Copenhagen.

Esta suite permite gestionar la performance de la plataforma VMware recolectando las estadisticas desde vCenter Server creando una serie de interfaces que nos entregan información sobre el estado de nuestra plataforma. No solo eso, un gran factor que diferencia esta suite de otras soluciones similares, es la habilidad de preveer el crecimiento en el uso de recursos y posibles problemas de performance que se puedan presentar, realizando una serie de analisis a partir de la información estadistica existente.

Esta nueva suite presenta un dashboard o panel de control completamente nuevo, y además se incluye las funcionalidades de CapacityIQ y otras herramientas de analisis. El objetivo es darle al area TI la información que necesita para determinar la mejor distribución de recuros, y tomar las acciones preventivas que sean necesarias en forma proactiva.

vCenter Operations Management Suite está formada de 2 componentes, los cuales detallaremos a continuación, y que se encuentran fuertemente integrados entre ellos.

vCenter Operations Manager 5.0
En esta nueva versión, vCenter Operations incluye:

Gestionar la performance y capacidad de multiples servidores de vCenter.
El Dashboard ahora incluye más información relevante, asi como marcadores mejorados para medir la salud, el riesgo y la eficiencia de la infraestructura virtual.

Se incluyen tambien las llamadas "Smart Alerts" o alertas inteligentes. Estas son basicamente alertas proactivas que proveen de una advertencia temprana sobre posibles issues, de manera que el personal de TI pueda identificar cualquier problema de salud, performance o capacidad antes de que este se produzca y afecta el funcionamiento de la plataforma, impactando a los usuarios. Se incluye un analisis automatico de la causa raiz de las alertas, de manera de poder enfocarse justamente en la causa raiz en vez de enfrentarse a alertas falsas.

Ahora CapacityIQ se encuentra integrado con vCenter Operations, de manera de poder correlacionar los datos de capacidad, utilización, eficiencia y riesgo, asi como permite tambien conseguir la utilización optima de la plataforma e identificar los recursos que están siendo desperdiciados.

Del mismo modo, en algunas ediciones de la Suite, se incluirá vCenter Chargeback Manager 2.0, de manera de poder realizar mediciones de costos, asi como analisis y reportes de la capacidad, desde el punto de vista financiero.
vCenter Operations Manager 5, incluye tambien, de manera integrada, a vCenter Configuration Manager, que permite realizar una correlacion automatica de los eventos de cambios en la plataforma, con la información de performance y salud. De esta manera, si se detecta algun problema de performance, será posible determinar si está relacionado a algún cambio realizado.

vCenter Infrastructure Navigator 1.0

Esta herramienta incluida en la suite permite descubrir aplicaciones (Application Awareness) en la infraestructura, y mapear sus dependencias para asi poder lograr una mayor visibilidad de las aplicaciones que se están ejecutando en las MVs, y sus inter-relaciones. Se integra facilmente con vCenter Server, y provee de un descubrimiento continuo de aplicaciones y sus dependencias en la plataforma virtual.

Application Awareness incluye además una base de conocimiento que ayuda a identificar en forma facil y precisa las aplicaciones.

vCenter Infrastructure Navigator, se integra además con Site Recovery Manager para asi descubrir las interdependencias incluidas en los planes de protección de SRM.

Con estas herramientas es posible entender como un problema de performance podria afectar a una aplicacion incluyendo sus dependencias. Por ejemplo, problemas en un servidor de base de datos podría afectar a un servidor web o un servidor de aplicaciones.

Comentarios Finales
vCenter Operations Management Suite se licenciará por MVs, y las licencias se vendrán por paquetes de MVs. Una vez que se cuente con los valores finales, podremos ver que tan competitiva puede ser esta solución de gestión de performance, respecto a las soluciones de terceros existentes en el mercado. Cabe recordar que hasta ahora, el valor de las licencias de vCenter Operations ha impedido una adopción más rapida de esta excelente solución.

Resumiendo, vCenter Operations Management Suite permite:

Una interfaz integrada y altamente automatizada para la gestión de performance, capacidad y configuración.
Consola de administración que permite integrarse con soluciones de terceros.
Analisis de cumplimiento y remediación continuos.
Capacidad de analisis que permite que la solución aprenda por si misma el comportamiento "normal" en un ambiente dinamico como lo es una infraestructura virtual.

Finalmente, recordar que la gestión de la performance se vuelve cada vez más importante en una plataforma virtual, más aun cuando la infraestructura va creciendo en el tiempo creando más MV y/o agregando recursos a las MVs existentes. Por este motivo, soluciones como la que se esta lanzando en esta ocasión, nos facilitan la vida a la hora de gestionar los recursos en VMware.

Ahora solo queda ver esta suite en accion, y espero poder presentarles un informe más acabado sobre su funcionamiento.

Llevar o no nuestros servicios a la Cloud?

2012-01-17T19:44:00.000-03:00

Ya hemos hablado hace poco sobre lo que es Cloud Computing y sus diferentes beneficios, pero no todo es color de rosas... Es importante que discutamos las eventuales desventajas del Cloud Computing, o en que circunstancias no es apropiado para una compañia, especificamente cuando hablamos de una Cloud Pública.

A continuación detallaremos algunas desventajas o contraindicaciones respecto a migrar a una infraestructura de Cloud Pública.

Servicios poco personalizables: Por lo general, las aplicaciones incluidas en el esquema SaaS son algo de lo que podemos disponer, pero no modificar. Que implica esto, que si un cliente requiere de funcionalidades especificas para su negocio, como se hace usualmente con el software a medida, no va a poder obtenerlo en la nube.
Alta latencia: Este es uno de los grandes problemas a los que se enfrenta una infraestructura de nube publica, al utilizar las conexiones WAN con las que el usuario accede a sus servicios en la nube. Esto hace que una nube publica no sea recomendable en situaciones donde se ejecutarán aplicaciones con grandes cantidades de datos que requieren una muy baja latencia y/o fuertes requerimientos de transferencia de datos.
Privacidad y Seguridad: El reto más grande al que se afrontan las compañias que quiere llevar sus servicios a la nube, es la privacidad y seguridad de los datos. Si bien el proveedor se comprometa a mantener controles de seguridad en la infraestructura y a asegurar la privacidad de la información que almacenan, aun permanece latente el riesgo si consideramos que la información se encontrará viajando permanentemente en la red, y será almacenada en una infraestructura que no puede ser controlada directamente por el cliente. En consecuencia, en una Cloud pública permanece el riesgo de que la información sea interceptada o modificada por terceros.
Regulaciones y Legislación Vigente: Donde debemos considerar que aun no existe un marco legal para ambientes de prestación de servicios en la nube. Consideremos que no es posible delegar la responsabilidad sobre la información, por lo que ante los organismos reguladores es la empresa la responsable de la información, aun cuando no tenga un control sobre la infraestructura donde esta información se hospeda. Es muy importante entonces averiguar con que medidas de seguridad y privacidad cuenta el proveedor. En consecuencia, una nube pública no es lo más recomendable en situaciones donde se necesita cumplir una serie de regulaciones de seguridad requeridas por aspectos legales.

Resumiendo un poco lo que ya he expuesto, Gartner ha identificado los 7 principales obstaculos en el camino a la Cloud:

La confianza del proveedor: Externalizar sus aplicaciones y datos corporativos conlleva hacerlo con alguien de total confianza, que le asegure la calidad del servicio, los términos de confidencialidad de su relación contractual, etc.
Conformidad legal: Al final, el responsable en caso de infracción es el propietario de la información. Por ello, los proveedores de Cloud Computing deberán estar abiertos a cualquier tipo de auditoría externa y a tomar y cumplir cuan medida sea necesaria para garantizar el cumplimiento de la normativa y, con ello, la seguridad de sus clientes.
Localización de los datos: Es uno de los puntos fuertes del Cloud Computing pero también uno de sus riesgos. Poder acceder a los datos en cualquier momento, independientemente de dónde estén localizados, debe estar garantizado para el cliente.
Protección de la información: Porque se comparten recursos pero esto no puedo ir en menoscabo de la confidencialidad de los datos del cliente, que deberá estar garantizada en todo momento.
Recuperación: Desconocer la localización de la información no puede implicar jamás que no existan las medidas necesarias de seguridad y replicación para garantizar su recuperación en caso de desastre o pérdida de los mismos.
Colaboración con la Justicia: Acatamiento de las leyes de protección y seguridad de la información, independientemente de que ésta varíe según las normas propias del país donde se localicen los datos y aplicaciones del usuario.
Una relación ‘para toda la vida’: La sostenibilidad del proveedor tiene que estar garantizada. Fusiones, quiebras, cualquier cambio en su negocio no puede dejar ‘indefenso’ al cliente y, por ello, se establecerá un compromiso de continuidad a largo plazo en la relación en los propios términos del contrato.

Ahora, estas son desventajas que poco a poco los proveedores de servicios de Cloud podrán ir superando a medida que la tecnología avanza. Sin embargo, existen otras preocupaciones que han generado controversia (y lo seguirán haciendo), por ejemplo el hecho de que como usuarios estaremos perdiendo el control sobre el software y sobre los datos. Alguna de estas preocupaciones son:

El discurso sobre la “escalabilidad ilimitada” con “disponibilidad inmediata” no es tal. Todos los recursos son FINITOS. Al llegar a una cierta necesidad de rendimiento puede ser necesario cambiar de proveedor y este proceso no es tan sencillo y rapido como algunos intentan vender.
Quien nos asegura que realmente ningún administrador en el proveedor de servicios de Cloud no esté leyendo nuestros correos, o revisando nuestros archivos, muchos de ellos confidenciales? Esto ocurre con frecuencia en infraestructuras tradicionales, y en una Cloud Pública este riesgo aumenta exponencialmente.
Como confiar en un proveedor de servicios de Cloud, cuando grandes corporaciones como Google o Microsoft han sufrido de perdidas de datos. Si compañias de este calibre tienen fallas asi, aun cuando no son frecuentes, como confiar en proveedores más pequeños? Ni hablar de nuestra realidad tercermundista, donde es preocupante la frecuencia con que uno se encuentra con clientes que no tienen respaldada su información critica. Los proveedores de servicios de Cloud NO están ajenos a esta realidad.
Como asegurarnos de que no tengamos que depender del proveedor de Cloud de por vida? Esto considerando además los costos que puede llegar a tener la portabilidad, y aun peor si consideramos aspectos de compatibilidad entre un proveedor de servicios y otro. Que seguridad tengo de que si en un par de años me quiero cambiar de proveedor, pueda hacerlo sin trabas administrativas y/o tecnicas?

Según Richard Stallman (Fundador de Free Software Foundation), los programas basados en Web como los servicios de Google (Gmail, Google Apps, etc.) son simplemente una trampa, y forzarán a las personas a comprar sistemas cerrados y propietarios, que irán aumentando sus precios en el tiempo.

Esto es una opinión un poco extrema, pero refleja la preocupación que algunos tienen respecto al avance del Cloud Computing en las compañias.

En algunas consultas que se han hecho a los ejecutivos de las compañias, éstos a pesar de reconocer las ventajas del Cloud Computing y ser conscientes de ellas, declaran dos claros frenos que evitan todavía su adopción

Las amenazas de seguridad
La pérdida del control de datos y sistemas.

Estas preocupaciones hacen que algunos aun prefieran confiar en sus sistemas internos existentes antes de migrar los servicios a la nube.

Bien, ya tenemos claras las desventajas y/o contraindicaciones de migrar nuestros servicios a una infraestructura de Cloud Pública. Ahora, cual es nuestra alternativa?

Ante todo tenemos que tener en consideración que el Cloud Computing no nos obliga migrar a la nube pública todos nuestros servicios a la vez. Una alternativa muy razonable, y que probablemente será la tendencia en la mayoria de las compañias, es combinar Cloud Privada y Cloud Pública en una Cloud Hibrida, donde se evalua las necesidades de cada uno de los servicios de la compañia, y si estos pueden ser o no llevados a una nube pública.

Todos tenemos claro los beneficios y ventajas que nos trae el Cloud Computing, pero debemos ser conscientes de que no todo lo que brilla es oro y es importante conocer ambos lados de la moneda antes de decidir si llevar o no nuestros servicios a la nube. Esto es aún más critico para quienes trabajamos como consultores, donde debemos asesorar a nuestros clientes en sus dudas y preocupaciones respecto al Cloud Computing.

Espero les haya sido de utilidad y les sea interesante.

Que es el Cloud Computing y cuales son sus ventajas?

2012-01-16T23:54:00.003-03:00

Hola a todos, en esta ocasión hablaremos un poco acerca de qué es el Cloud Computing y cómo podemos sacar provecho de las ventajas que nos ofrece.

Que es el Cloud Computing?

En terminos simples, el Cloud Computing es un nuevo paradigma que nos permite ofrecer TI como Servicio. Con Cloud Computing, todo lo que se encuentra en el Datacenter de una compañía es ofrecido como un servicio.

Cloud Computing permite ofrecer de manera conveniente y a demanda, recursos y servicios altamente disponibles tanto desde la red privada como la red pública. Permite a los usuarios acceder a un catálogo estándar de servicios, respondiendo a las necesidades del negocio de forma flexible y permitiendo adaptarse a las demandas de los usuarios en el tiempo.

Su principal característica es el uso de recursos compartidos y la independencia de la infraestructura, lo cual permite al usuario disponer siempre de los mismos servicios independientemente donde este se encuentre ubicado.

Las características de Cloud Computing son:

Servicio a demanda
Pool de recursos independiente de la ubicación
Elasticidad y flexibilidad
Servicio medible

El Cloud Computing aporta una serie de ventajas al negocio, permitiéndole contar con:

Una infraestructura dinámica
Un alto grado de automatización
Una gran movilidad de recursos
Una elevada capacidad de adaptación a la demanda variable.
Facilidad para facturación de los servicios en función del consumo.

Tipos de Cloud

Cuando hablamos de Cloud Computing, debemos reconocer los diferentes tipos de Cloud que existen:

Cloud Privada: Infraestructura on-demand implementada y administrada exclusivamente por la organización, que controla que servicios ofrecer . Una Cloud Privada es una la mejor opción para las compañías que necesitan una alta protección de datos y asegurar el acceso continuo a los servicios sin la dependencia del acceso a Internet.

Cloud Pública: Infraestructura on-demand implementada de manera que puede ser accedida de manera pública y desde internet.

Generalmente ofrecida por empresas de comunicación y datacenter.
Servicios accedidos de manera estándar desde internet.

Muchos clientes diferentes pueden estar utilizando los mismos servidores, sistemas de almacenamiento, infraestructura de red, etc., sin que los usuarios finales tengan conciencia de que están compartiendo la infraestructura con otros clientes.

Cloud Hibrida: En una Cloud Hibrida se combinan los modelos de nubes públicas y privadas, donde el cliente es propietario de una parte de la infraestructura, mientras comparte otra. Este modelo de Cloud es el que en teoría sería el más atractivo para las organizaciones y el que más se desarrollara con el tiempo. Una Cloud hibrida trabaja bajo el concepto de federación y portabilidad.

Capas de Cloud Computing

Así como existen distintos tipos de Cloud, una Cloud puede estar a su vez subdividida en las siguientes capas

Software como servicio (SaaS). Es la capa más alta del Cloud Computing. Se ofrece directamente el software como servicio on-demand y en modalidad multitenance (una sola instancia del software que corre en la infraestructura y sirve a múltiples organizaciones de clientes), sin tener que preocuparnos de la plataforma donde se encuentra desarrollado, o la infraestructura desde donde el Software se ejecuta. Ejemplo, Google docs, Salesforce.com, Microsoft Office 365

Plataforma como servicio (PaaS). Es la segunda capa del Cloud Computing, donde se ofrece directamente un sistema operativo y un entorno donde desarrollar un servicio. Cuando se habla de PaaS se refiere a una plataforma que proporciona un conjunto de facilidades y herramientas para soportar un ciclo completo de desarrollo de un determinado software, incluyendo el hosting del producto resultante. Entre esas herramientas están IDEs, bases de datos, servidores de aplicaciones, gestores de fuentes, integración continua, software de trabajo colaborativo, etc. Ejemplo, Microsoft Azure, Google App Engine, VMware Cloud Foundry.

Infraestructura como servicio (IaaS). Es la capa inferior del Cloud Computing, donde básicamente se ofrecen los recursos de almacenamiento CPU, memoria y red para que podamos instalar el sistema operativo de nuestra elección, y desarrollemos en el Framework que deseemos. Ejemplo, vCloud Express de VMware, Amazon Web Services

Ventajas de la infraestructura de Cloud Computing

Desde el punto de vista económico

Reducción de Costos (CAPEX/OPEX). Esto considerando que los proveedores de Cloud Computing utilizan infraestructuras altamente eficientes y con altos radios de utilización, reduciendo el costo total de operación y mantención de la infraestructura, repartiendo además los costos entre todos los clientes a los que se presta el servicio. Esto aplica también en nubes privadas, utilizando las funcionalidades de facturación interna o Chargeback. Se reducen los costos en la inversión inicial de la infraestructura y los costos de operación.
Infraestructura a medida. Facilita las labores de dimensionamiento de la infraestructura en un proyecto determinado, eliminando la complejidad de calcular las proyecciones de crecimiento del negocio, permitiendo un escalamiento de la plataforma on-demand, según las necesidades del negocio, y reduciendo el riesgo de sobredimensionar una infraestructura que después no será utilizada a plenitud.
Mayor eficiencia. Aumenta la eficiencia en el uso de utilizando sistemas que se encarguen de monitorear el uso de los recursos y administrarlos de manera eficiente para reducir los costos de manera automática y eficiente, a través de llamados de petición o liberación de recursos al proveedor del servicio.
Costo basado en uso. Donde cada cliente paga por lo que está realmente utilizando, y no por toda una infraestructura que se podría contar en un Datacenter, y que frecuentemente es subtilizada.
Calidad de Servicio. Permite contar con niveles de servicio (SLA) con mayores tiempos de disponibilidad. Es posible contar con diferentes niveles de servicio dependiendo del cliente y su negocio.

Desde el punto de vista Técnico

Automatización. Permite automatizar la gestión de la infraestructura mediante scripts u otras soluciones, permitiendo desplegar nuevas aplicaciones, o gestionar recursos de manera automática apalancando las APIs incluidas en la infraestructura.
Escalabilidad. Ya sea en forma automática o en forma manual, es posible escalar los recursos que una aplicación necesita en forma dinámica y on-demand. Del mismo modo es posible realizar escalamiento de recursos de forma proactiva para atender aumentos de la demanda a través de predicciones basadas en patrones históricos de uso de los servicios.
Movilidad. Existe una independencia del dispositivo y la ubicación, lo que permite que los usuarios puedan acceder a los sistemas usando un navegador de Internet independiente de su ubicación geográfica y del sistema operativo o computador.
Disponibilidad. La infraestructura y arquitectura de un Data Center diseñado como una Cloud, esta especialmente diseñada con alta redundancia para asegurar la Continuidad Operacional y la Continuidad del Negocio. Además, es posible usar la amplia distribución geográfica de la infraestructura de un proveedor de Cloud Computing para la replicación de ambientes en varias locaciones alrededor del mundo en minutos.

Espero les haya servido para entender un poco más sobre la Cloud. Si quiere más información pueden revisar los siguientes links:

Impacto de la virtualización en la estrategia de Respaldo y Disaster Recovery

2012-01-08T01:17:00.001-03:00

Hasta hace no muchos años, antes de que la virtualización entrara fuertemente en el Datacenter de las compañias, respaldar la información critica podia llegar a ser un desafio. Aun más, el proceso de restauración podia llegar a ser una pesadilla en muchos casos, y muchas veces este proceso no podia ser completado exitosamente.

En este punto debemos separar además el termino "Restauración" de "Recuperación". Si bien en muchos casos podemos llegar a restaurar los archivos requeridos, hay mucho camino aun por recorrer para poder llevar a cabo una Recuperación exitosa del servicio o aplicación requerida

En un ambiente fisico tradicional, los fabricantes de soluciones de respaldo tradicionales muchas veces se conformaban con el hecho de extraer los datos desde los respaldos y llevarlos a un almacenamiento accesible para su uso, lo cual claramente no es suficiente si consideramos que el proceso no estara completo si la aplicación que requiere el dato restaurado no ha podido volver a estar operativa.

Por otro lado, las soluciones de respaldo estaban pensadas principalmente para poder respaldar y restaurar datos. Con el uso de agentes especializados, los fabricantes sumaron soporte para el respaldo y restauración de aplicaciones y servicios como Bases de Datos, Servidores de correo, etc. Estos agentes, si bien solucionaban esa necesidad puntual, aumentaban drasticamente el costo de la solución de respaldo, asi como también su complejidad.

Aun más, en un ambiente fisico existe un desafio aun mayor... ¿Qué sucede si el servidor ha fallado completamente y es necesario recuperarlo desde cero?

Una alternativa es reinstalar el sistema operativo y las aplicaciones/servicios, con la correspondiente configuración, para luego restaurar los datos almacenados en los respaldos... Pero esto toma demasiado tiempo no? De hecho una solución asi en muchos casos es inaceptable para servidores de misión critica, debido a que podria tardar horas en el mejor de los casos.

Para enfrentar este desafió, la mayoria de las soluciones de respaldo cuentan con capacidades de restauración "Bare Metal", que permiten una restauración desde cero, pero este tipo de soluciones suelen ser poco confiables, debido a que dependen mucho del hardware de reemplazo, donde un pequeño cambio puede provocar que las restauraciones fallen.

Y el desafio final en ambientes fisicos, es que el proceso de recuperación rara vez involucra a un unico servidor. Por ejemplo, ante la falla del Storage que soporta la aplicación (por ejemplo en una configuración en Clúster), o cuando el Datacenter completo sufre una caida, el proceso de restauración involucrará varias capas (tiers) de servidores, lo cual muchas veces debe ser realizado en un orden especifico para asegurar que el proceso sea exitoso.

Todos estos desafios que enfrenta una infraestructura fisica tradicional, hacen que poder contar con una estrategia de Recuperación ante Desastres y de Continuidad de Negocios sea extremadamente dificil. Ni hablar de procedimientos para probar los respaldos, proceso que podria durar por siempre....

La llegada de la virtualización.
Con la aparición de la virtualización y su explosiva adopción, especialmente con VMware, todos los paradigmas de gestión de un Datacenter sufieron un cambio profundo, especialmente los procedimientos relacionados a Disaster Recovery y Bussines Continuity.

Las antiguas soluciones de respaldo, asi como los procedimientos de recuperación ante desastres, si bien aun pueden ser utilizados en los ambientes virtualizados, estan lejos de ser eficientes y debieran ser reemplazados por soluciones y procedimientos acorde, que puedan aprovechar todas los beneficios que la virtualización nos entrega.

Si bien la virtualización nos ayuda a enfrentar de mejor manera los desafios antes mencionados, esta es solo parte de la solución. La otra parte son las soluciones de Respaldo y Disaster Recovery que nos ofrecen los principales actores de la virtualización (VMware, Microsoft y Citrix), asi como las soluciones especializadas de terceros (Veeam, Quest, Symantec, CA, etc.).

Con las soluciones de respaldo y Disaster Recovery diseñadas para ambientes virtuales, cada servidor (máquina virtual) puede ser protegido completamente en un unico proceso de respaldo, aprovechando uno de los pilares de la virtualización, que no es otro que la ENCAPSULACIÓN de la MV en un conjunto de archivos.

Luego de realizar un respaldo full, al comunicarse directamente con el hypervisor, las soluciones de respaldo pueden realizar respaldos parciales (incrementales) almacenando solo los cambios o bloques modificados de la MV respecto al ultimo respaldo. Adicionalmente las soluciones de respaldo actuales utilizan metodos avanzados de compresión y deduplicación, lo que permite un uso más eficiente de los recursos de almacenamiento y del ancho de banda en la red de respaldos.

Para que los respaldos sean consistentes, las soluciones de respaldo para ambientes virtualizados están basadas principalmente en los Snapshots de las máquinas virtuales, lo cual permite mantener multiples puntos de recuperación o versiones de respaldos.

Ahora lo escencial... ¿En que mejoran los procesos de recuperación?
Con la virtualización y las soluciones de respaldo y Diaster Recovery pensadas para ambientes virtuales, es posible recuperar una máquina virtual completa desde un respaldo, sin preocuparse de los problemas de compatibilidad de hardware que presentaban las soluciones Bare Metal tradicionales, porque como deben recordar, las máquinas virtuales son 100% independientes del hardware físico que las hospedan!

Esto nos permite restaurar una o más máquinas virtuales en otro host o incluso en otro Site si es necesario, siendo de gran ayuda al momento de aplicar los procedimientos de Disaster Recovery

Mejor aun, si la situación asi lo requiere, y dependiendo de la solución de respaldo utilizada, es posible recuperar archivos especificos desde el respaldo de la MV, no siendo necesaria la restauración de la MV completa. Del mismo modo, y dependiendo de la "inteligencia" de la solución de respaldo elegida, es posible realizar restauraciones granulares a nivel de aplicación, como puede ser un correo en un buzon Exchange, o un registro en una BD SQL/Oracle.

Algunos productos de Respaldo y Disaster Recovery tienen la habilitad de realizar una recuperación "in-place", que permite acelerar el proceso de recuperación montando la máquina virtual respaldada desde el mismo repositorio de respaldos, lo cual nos permite tener nuestros servicios operativos en forma casi instantanea en algunos casos, aun cuando tengan una performance degradada. Una vez el servicio se encuentra restaurado, el administrador TI puede utilizar funcionalidades como Storage vMotion de vSphere para mover "en caliente" la MV al dispositivo de almacenamiento principal, sin ninguna interrupción, y normalizando la performance de dicho servicio.

Si requerimos soluciones de Disaster Recovery y Bussines Continuity, como el uso de Sites de Contingencia, apalancando la Virtualización y las tecnologias de respaldo modernas es posible pensar en sitios replicados y procedimientos de Failover y Failback de maneras que serían mucho más complejas de implementar en los ambientes fisicos tradicionales.

Con soluciones como VMware Site Recovery Manager, Veeam Backup and Replication y Quest vRanger, es posible contar con sitios replicados en ubicaciones remotas, donde ya no es requisito fundamental la compatibilidad entre los dispositivos de almacenamiento (SAN) existentes en el sitio principal y en el de contingencia.
De hecho, si asi lo requieren, el sitio de contingencia podria incluso funcionar sin un almacenamiento centralizado (SAN o NAS), utilizando nada más que almacenamiento local en cada host. Claramente no es la situación ideal, pero cuando el presupuesto es escaso, es una solución bastante valida.

Un ultimo punto, pero no menos importante, es la posibilidad de probar los respaldos para asegurarnos que estos sean recuperables en caso que lo necesitemos. Con la virtualización y las soluciones de respaldo y Disaster Recovery, es más sencillo generar ambientes aislados o sandbox virtuales donde poder comprobar que los respaldos sean recuperables y funcionales, sin afectar a los servicios productivos, y en tiempos mucho más acotados que en ambientes físicos tradicionales.

Como pueden ver, al virtualizar un Datacenter se deben introducir cambios bastante profundos en la manera en que se gestiona la plataforma y en los procedimientos que llevan a cabo los administradores de TI en diversas situaciones, en especial en lo relacionado a la Recuperación ante Desastres y Continuidad de Negocios.

Espero que les haya resultado interesante y que les sea de utilidad.

VMware View 5: Persona Management

2012-01-03T23:30:00.001-03:00

Hola a todos, hoy hablaremos sobre View 5, especificamente de la nueva funcionalidad "Persona Management".

Persona Management, disponible en la versión Premier de VMware View 5, permite preservar los perfiles de usuario y sincronizarlos dinamicamente con un Repositorio remoto de perfiles. Expande la funcionalidad de Windows Roaming Profiles y mejora la performance de este, pudiendo ser una solución alternativa a Roaming Profiles.

El perfil de cada usuario es una colección de datos y configuraciónes utilizados por cada usuario cuando inicia una sesión en Windows. El perfil de cada usuario se almacena por defecto en el siguiente directorio:

Windows XP: c:\documents and settings\%username%\
Windows 7: c:\users\%username%

El perfil de usuario incluye una variedad de información generada por el usuario, como por ejemplo:

Apariencia del escritorio, como por ejemplo el wallpaper, combinacion de colores, uso de Aero en Windows 7, etc.
Parametros de configuración de aplicaciones, como preferencias de usuario para su uso, barras de herramientas, configuración de correo en Microsoft Outlook, etc.

Persona Management es una mejora considerable para preservar el perfil de los usuarios, especialmente en Pools Flotantes de escritorios virtuales. En versiones anteriores, esto solo era posible utilizando escritorios dedicados para cada usuario (Ejemplo, Pool de Composer con Discos Persistentes).

Desafios en la gestión de perfiles
En un escritorio fisico tradicional, todos los cambios que realiza un usuario en su perfil son almacenados en el disco local.

En una infraestructura de escritorios virtuales, existen dos tipos de escritorios:

Dedicados (o persistentes), donde a cada usuario se le asigna un escritorio, el cual seguirá usando cada vez que inicie sesión en VMware View.
Utilizando escritorios dedicados, los perfiles de usuario pueden ser almacenados en un disco de datos persistente, no obstante esta no es una solución optima para escenarios de Disaster Recovery y Business Continuity. Adicionalmente, los discos persistentes no se integran bien con las soluciones de respaldo corporativas.
Flotantes (No persistentes), donde el usuario obtiene un escritorio aleatoriamente cada vez que inicia sesión. En este caso, en versiones anteriores, el usuario pierde todos los datos de perfil al cerrar sesión. Cada vez que el usuario inicia sesión en un pool de escritorios flotantes, el usuario experimenta el estar iniciando sesión por primera vez en Windows, incluyendo la apariencia del escritorio y todas las preferencias y configuraciones de las aplicaciones.

VMware View 5 incluye Persona Management que permite preservar el perfil de los usuarios en un repositorio compartido en la red, permitiendo recuperarlo cada vez que el usuario inicia sesión, sin importar si se encuentra en un escritorio dedicado o flotante.

Como funciona Persona Management?

View Persona Management incluye politicas de grupo que se pueden importar facilmente en Active Directory, y que permiten habilitar View Persona para los usuarios de View, asi como tambien configurar otros parámetros, como la ubicación del repositorio de perfiles. Algo a destacar es que View Persona Management no realiza cambios en las cuentas de usuario de Active Directory para poder gestionar los perfiles.

Adicionalmente, al instalar el Agente View en los escritorios, se debe instalar el componente para View Persona incluido en el Agente de View 5.

En el caso de utilizar aplicaciones virtualizadas con ThinApp, la data del sandbox de ThinApp puede tambien ser almacenada en el perfil del usuario que está almacenado en el repositorio central de Persona Management, sin impactar significativamente en los tiempos de inicio de sesión.

Los perfiles de usuario son sincronizados dinamicamente con el repositorio remoto de perfiles. View Persona no requiere el uso de Windows Roaming Profiles, pero si este ultimo ya se encuentra implementado, es posible utilizar el repositorio existente como repositorio de perfiles de View Persona.

Al usar Persona Management se obtienen mejoras importantes en el tiempo que toma el escritorio para abrir y cerrar sesión.

Durante el inicio de sesión, View descarga solo los archivos que Windows necesita, como los archivos de registro del usuario. Otros archivos son copiados al escritorio cuando el usuario o la aplicación los abre. En resumen, el la información del perfil es descargada por View Persona a medida que el usuario lo necesita.
View copia periodicamente los cambios recientes hechos en el perfil local, al repositorio remoto. Por defecto el intervalo de sincronizacion es de 10 minutos, el cual puede ser personalizado.
Durante el cierre de sesión, solo los archivos que fueron actualizados desde la ultima replicación son copiados en el repositorio remoto de perfiles.

En conclusión, View Persona Management permite que los usuarios tengan una experiencia consistente desde un inicio de sesión a otro, sin importar si se encuentran en un pool flotante o dedicado.

vSphere 5: Host Power Management (HPM)

2011-12-14T16:30:00.000-03:00

Hola a todos,

Una de las nuevas features incluidas en vSphere 5, y de la que poco se ha hablado, es vSphere Host Power Management o simplemente HPM.

HPM es una tecnica que permite ahorrar energia poniendo ciertas partes de un servidor o dispositivo en un estado de energia reducido, cuando el servidor o dispositivo se encuentra inactivo o no necesita funcionar a plena capacidad.

HPM no debe confundirse con DPM (Distributed Power Management), el cual distribuye MVs entre hosts fisicos en un cluster, intentando liberar uno o más hosts para apagarlos completamente. HPM ahorra energia manteniendo los hosts encendidos en todo momento. Ambas features pueden ser utilizadas simultaneamente permitiendo un ahorro de energía mayor.

HPM administra la energia utilizando los estados de performance y energia de Advanced Configuration and Power Interface (ACPI). Con el lanzamiento de vSphere 5, la politica de administración de energia por defecto está basada en DVFS (Dynamic Voltage and Frequency Scaling). Esta tecnologia utiliza los estados de performance del procesador y permite que parte de la energia sea ahorrada utilizando el procesador a una menor frecuencia y voltaje, mientras aun se deja suficiente tiempo de CPU disponible para mantener niveles de performace aceptables en la mayoria de los ambientes.

Host Power Management en ESXi 5

vSphere HPM en ESXi 5 se encuentra diseñado para reducir el consumo de energia en los hosts ESXi.

ESXi 5 incluye cuatro diferentes politicas de energia que están basadas en el uso de los estados de performance ACPI (P-States) del procesador, y en los estados de energia ACPI (C-States) del procesador.

Los P-States pueden ser utilizados para ahorrar energia cuando la carga de trabajo en ejecución sobre el host no requiere una capacidad completa de CPU. Los C-States pueden ahorrar energia solo cuando la CPU tiene una cantidad significativa de tiempo disponible, por ejemplo, cuando la CPU está esperando que una operación de I/O se complete.

Politicas de Energia HPM en ESXi5
ESXi cuenta con las siguientes politicas de energia:

High Performance: Esta politica maximiza la performance, y no utiliza ninguna funcionalidad de gestión de energia. Esta es la politica por defecto para ESX/ESXi 4.x.
Balanced: Esta politica está diseñada para reducir el consumo de energia del host, mientras se tiene poco o ningún impacto en la performance. Esta es la politica por defecto para ESXi 5
Low Power: Esta politica está diseñada para reducir en forma más agresiva el consumo de energia del host, al riesgo de reducir la performance.
Custom: Esta politica parte con la misma configuración que la politica "Balanced", pero permite que parametros individuales sean modificados. Si el hardware del host no permite al sistema operativo gestionar la energia, el unico parametro disponible es "Not Supported".

Para cambiar la politica a utilizar, deben ir a la sección "Configuration" del Host, y luego seleccionar Power Management en la sección "Hardware".

Espero que les haya resultado interesante. Si quieren saber más de HMP, incluyendo su funcionamiento y best practices, pueden revisar el siguiente Whitepaper:

Host Power Management in VMware vSphere 5

Regalo de navidad de Veeam! Licencias NFR de Veeam Backup and Replication 6

2011-12-14T15:21:00.000-03:00

Como un regalo especial de fin de año, Veeam nuevamente esta entregando licencias gratuitas, esta vez del recientemente lanzado Veeam Backup and Replication v6.

Estas licencias están disponibles para VMware vExperts, VMware Certified Professionals y VMware Certified Instructors. Del mismo modo, y considerando que ahora se cuenta con soporte para Hyper-V, estas licencias NFR pueden ser obtenidas tambien por Microsoft Certified Professionals y Microsoft MVPs.

Solo se requiere registrarse para recibir las licencias Veeam para propositos de Evaluación, Demostración y Entrenamiento.

Para quienes estén interesados este es el link:
http://www.veeam.com/news/holiday-gift-from-veeam-free-veeam-backup-and-replication-v6-licenses-for-your-lab155.html

vSphere 5: What's New - Performance

2011-12-14T12:19:00.000-03:00

Con el lanzamiento de vSphere 5 se obtienen una serie de mejoras en la performance de nuestra plataforma VMware, las cuales detallaremos a continuación.

Las mejoras de performance se dividen en 5 pilares, los cuales detallaremos brevemente:

Mejoras a nivel de vCenter Server
Mejoras a nivel de capacidad de computo
Mejoras a nivel de almacenamiento
Mejoras a nivel de networking
Mejoras a nivel de vMotion

Mejoras a nivel de vCenter Server
vSphere 5 incluye mejoras en la escalabilidad que permite, por ejemplo, un mayor número de máquinas virtuales por clúster. Aún con esta mayor escalabilidad, vSphere 5 incluye una serie de mejoras en la performance relacionadas a las operaciones de administración en vCenter Server, así como también en las funcionalidades relacionadas con High Availability (HA):

Hasta un 120% de mejora en el throughput (operaciones/minuto) de las operaciones de administración en vCenter. Por ejemplo, en el encendido/apagado/migración/registro de máquinas virtuales.
Una mejora del 25% al 75% en la latencia de las operaciones de administración, dependiendo del tipo de operación.
La configuración de un cluster HA puede ser realizada hasta 9 veces más rápido en vSphere 5, dependiendo del tamaño del cluster.
En vSphere 5 se puede realizar el failover de hasta un 60% más de máquinas virtuales, en el mismo periodo, respecto a versiones anteriores
El tiempo mínimo de recuperación, desde la falla hasta que la primera máquina virtual es reiniciada, ha sido mejorado en un 44.4%
El tiempo promedio para el failover de máquinas virtuales ha sido mejorado en un 14%.
El Slot size por defecto para la CPU ahora es de solo 32Mhz, permitiendo un mayor radio de consolidación en comparación con versiones anteriores.

Mejoras a nivel de capacidad de computo

vSphere 5 soporta hasta 32 vCPU y hasta 1TB de vMEM por máquina virtual, lo cual permite que aplicaciones Tier 1 y de misión critica alcancen una mayor performance.
Mejoras en el scheduler de la CPU en arquitecturas Intel SMT, permitiendo una mejora del 10% al 30% en la performance de las aplicaciones, dependiendo de la carga de trabajo.
En vSphere 5 se incluye Virtual NUMA o vNUMA, que expone la topología NUMA al sistema operativo de las máquinas virtuales, permitiendo que el sistema operativo y aplicaciones hagan un mejor uso de la arquitectura NUMA del host. Se requiere Virtual Hardware versión 8.
vSphere 5 permite a los usuarios configurar un caché para Swap en un disco de estado sólido o SSD. De esta manera, cuando Transparent Page Sharing, Ballooning y la Compresión de memoria no han sido suficientes para obtener los recursos de memoria requeridos, el proceso de swapping se realizará en ésta cache en vez de utilizar un archivo normal de swap en disco. Esto permite una mejora importante en la performance reduciendo la latencia en escenarios de escasez de memoria.

Mejoras a nivel de almacenamiento

vSphere 5 Storage I/O control ahora soporta NFS y “shares” basados en NAS. Esto permite regular dinámicamente el acceso de múltiples máquinas virtuales a recursos de I/O compartidos en un clúster, basados en los shares asignados a las máquinas virtuales.

Mejoras a nivel de Networking

vSphere 5 incluye mejoras en NetIOC, donde agrega funcionalidades de QoS (802.1p) y permite la creación de Resource Pools para limitación de anchos de banda.
vSphere 5 incluye splitRxMode, una nueva funcionalidad para dividir el costo de la replicacion de paquetes para multicast entre varias CPUs físicas, permitiendo que vSphere 5 sea una plataforma altamente escalable y eficiente para receptores de multicast. En versiones previas, la replicación de paquetes para multicast es hecha usando un único contexto, y en escenarios con una alta densidad de máquinas virtuales por host, esto puede provocar cuellos de botella y causar perdida de paquetes. SplitRxMode puede ser habilitado en una virtual NIC VMXNET3, y permite dividir el costo del procesamiento de paquetes recibidos en multiples contextos, mejorando significativamente la performance de multicast.

Mejoras a nivel de vMotion

vSphere 5 permite que vMotion sature en forma efectiva el ancho de banda de un adaptador de red 10GbE durante una migración, reduciendo los tiempos de transferencia en una operación de vMotion.
Se permite el uso de multiples adaptadores de red para las operaciones de vMotion, donde el VMkernel balanceara la carga del trafico de vMotion, en forma transparente, sobre todas las vmknics con vMotion habilitado, tratando de saturar todas las conexiones para distribuir el trafico de vMotion, incluso en operaciones unicas de vMotion.
Se incluye una nueva funcionalidad de “Metro vMotion” que provee de una mejor performance sobre redes con alta latencia y aumenta los limites de latencia para redes de vMotion de 5ms a 10ms.
Se incluye soporte de Live Migration para Storage (Storage vMotion) con el uso de I/O Mirroring. Esto permite una mayor movilidad de máquinas virtuales, mantenimiento con zero downtime, y balanceo de carga de almacenamiento manual y automatico.

Conclusión

Como podemos ver, vSphere 5 incluye un numero importante de mejoras a nivel de performance, lo cual nos permite virtualizar aplicaciones de cualquier envergadura, tanto en pequeños ambientes, como en grandes implementaciónes con aplicaciones de mision critica y Tier-1.

Para mayor información, pueden revisar el siguiente White Paper de VMware con todo el detalle de las novedades de vSphere 5, relacionados con la performance:

http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-50-Performance-Technical-Whitepaper.pdf

Nace vZion Consultores!

2011-12-12T12:45:00.000-03:00

Hola a todos! Les quería comentar acerca de un nuevo desafió personal en el que me he embarcado desde hace algunos días, que es la formación de una compañía dedicada a la Virtualización y Cloud Computing en Chile.

Finalmente esta idea sale a la luz en la forma de vZion Consultores, de la cual soy co-fundador, donde ya somos Partners tanto de VMware como de Veeam Software, y estamos trabajando ya en nuevas alianzas y partnerships con importantes actores en la industria de la virtualización.

Desde ya les comento que este Blog seguirá activo y actualizado periódicamente, y agradezco enormemente las visitas y el apoyo que aquí he conseguido.

Si quieren saber más de vZion Consultores pueden visitarnos en nuestro sitio web (www.vzion.net), asi como también en las redes sociales como Twitter, Facebook y Linkedin.

Gracias a todos!

Veeam Backup and Replication 6 - Finalmente disponible

2011-11-30T12:07:00.000-03:00

Finalmente, a partir de ayer se encuentra disponible Veeam Backup & Replication v6, el cual es posible descargar en modo de evaluación para que puedan probar todas sus nuevas funcionalidades.

En un post anterior detallé las novedades de esta nueva versión de esta premiada solución de Veeam.

Entre las novedades podemos indicar:

Una nueva arquitectura distribuida
Soporte para Hyper-V
Mejoras importantes en la funcionalidad de Replicación con Failback incluido.
Nueva funcionalidad Quick Migration

Una descripción más detallada la pueden encontrar en el sitio de Veeam y en el articulo de What's New publicado anteriormente en este Blog.

Acceso directo con credenciales en vClient

2011-11-23T16:56:00.003-03:00

En vClient existen algunos parámetros que nos podrían facilitar el acceso a 1 o varios servidores ESXi o vCenter's. Si estás aburrido de ingresar las credenciales cada vez que te conectar a tu plataforma puedes crear un acceso directo con las credenciales listas, de tal manera que al hacer dos clic conecte al servidor predefinido con las credenciales agregadas previamente. ¿Cómo? Los parámetros que VMware provee para esto son:

-u (username)
-s (servername o IP)
-p (password)

de tal manera que podemos crear un acceso directo con el siguiente path en el "Destino":

"C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe" -u root -s 192.168.0.150 -p Contraseña2010

Hay que ser claro si en indicar que la contraseña no queda encriptada, cualquier usuario que quiera editar el acceso directo podría encontrarse con las credenciales de acceso a la plataforma por lo que se recomienda ser cuidadoso en el uso de estos parámetros.

Acá tambien podemos hacer uso del parámetro -passthroughAuth para acceder con las credenciales de sesión de windows por ejemplo:

"C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe" -passthroughAuth -s vcenter.testing.local

VMware View 5: Implementando escritorios virtuales

2011-11-17T02:15:00.000-03:00

Hola a todos!
En el ultimo VMworld efectuado en Las Vegas, se realizó el lanzamiento oficial de VMware View 5. A continuación hablaremos un poco más de esta nueva versión y del proceso de instalación y configuración.

Anteriormente publiqué un post con las mejoras de View 5 respecto a sus antecesores, donde destacan mejoras en el protocolo PCoIP, uso de aplicaciones en 3D, y View Persona Management, que permite el uso y administración de perfiles moviles sobre escritorios virtuales. Sobre este ultimo punto entraremos más en detalle en esta serie de articulos.

Introducción
VMware View es la solución de virtualización de escritorios de VMware, que nos permite simplificar la gestión de los escritorios, mientras se aumenta la seguridad y control sobre la plataforma.

VMware View permite entregar una experiencia personalizada y de calidad a los usuarios finales, permitiendo una mayor disponibilidad y agilidad en los servicios de escritorio, respecto a los PCs tradicionales, reduciendo ademas el TCO en hasta un 50%.

Experiencia de usuario final
A diferencia de los PCs tradicionales, los escritorios View no están atados a los computadores fisicos, sino que residen en una nube y los usuarios finales pueden acceder a sus escritorios virtuales cuando lo necesiten, y desde cualquier ubicación. Gracias al protocolo PCoIP, VMware View entrega una experiencia de usuario final mas rica, flexible y adaptable, en diferentes condiciones de conectividad.

Control y gestión
VMware View permite aumentar el control sobre los escritorios, aplicaciones y datos, entregandolos y gestionandolos como servicios centralizados.
A traves de una unica consola administrativa, se puede contar con visibilidad sobre todos los servicios de escritorio, mientras se facilitan las tareas al area TI de provisionar escritorios, asi como la gestión de parches y actualizaciones.

Características de VMware View
Entre las caracteristicas de VMware View podemos nombrar:

Uso de múltiples monitores
Imprimir desde un escritorio virtual a cualquier impresora local o en red que se encuentre definida en el dispositivo cliente.
Acceso a dispositivos USB y otros perifericos que se encuentren conectado en el dispositivo Thin Client.
Uso de VMware HA para entregar alta disponibilidad a los escritorios virtuales.
Integración con Active Directory para administrar los escritorios virtuales y politicas
Uso de template o imagen maestra para crear y provisionar grupos de escritorios virtuales rapidamente (View Composer)
Administración de perfiles móviles utilizando View Persona Management
Acceso desde distintas ubicaciones, incluyendo conexiones a través de la WAN sin necesidad de VPN.

Componentes de VMware View

Los componentes de la arquitectura de VMware View los he detallado anteriormente al hablar de View 4.5, y en esta nueva versión los componentes son basicamente los mismos.

Dispositivos Cliente
View Connection Server
View Client
View Agent
View Administrator
View Composer
View Transfer Server
View Securitu Server

Protocolos de conexión remota

VMware View con PCoIP
PCoIP provee una experiencia optimizada para la implementación de un ambiente de escritorio completo, incluyendo aplicaciones, imagenes, audio y video para un amplio rango de usuarios en la LAN o a traves de la WAN. PCoIP puede compensar un aumento en la latencia o en la reducción del ancho de banda para asegurar que los usuarios finales pueden permanecer productivos sin importar de las conficiones de red.

Microsoft RDP
Microsoft Remote Desktop Connection (RDC) utiliza RDP para transmitir datos. RDP es un protocolo multicanal que permite a los usuarios conectarse remotamente a un computador.

Software HP RGS
En View 5.0 el soporte para HP RGS ha sido removido

Requisitos
View Connection Server
Para la instalación de View Connection Server se debe contar con un servidor de 32 o 64 bits dedicado, ya sea fisico o virtual que cumpla los siguientes requerimientos (estos aplican también para las instancias de replica o servidores de seguridad):

Procesador Pentium IV o superior. Se recomienda un servidor con 4 CPUs.
Conexión a red 10/100Mbps. Se recomienda 1Gbps.
2GB de memoria RAM o superior (4GB para Windows 2008). Se debe contar con al menos 10GB de RAM en implementaciones de 50 o más escritorios virtuales.
Windows Server 2003 R2 32-bits y 2008 R2 64-bits
VMware vSphere 4.0 U3 o superior
VMware vSphere 4.1 U1 o superior
VMware vSphere 5.0 o superior

Nota: No usar redes WAN para conectar instancias replicadas de View Connection Server

View Composer
View Composer 2.7 se instala solo sobre sistemas operativos de 64 bits. View Composer debe ser instalado en el mismo servidor (fisico o virtual) donde se encuentre instalado vCenter Server.

VMware vSphere 4.0 U3 o superior
VMware vSphere 4.1 U1 o superior
VMware vSphere 5.0 o superior
Windows Server 2008 R2
Una instancia de SQL Server u Oracle para los datos de Composer. De ser posible utilizar el mismo servidor de base de datos utilizado por vCenter.

View Agent
A continuación un detalle de los sistemas operativos soportados para View Agent:

Windows 7 32 y 64 bits
Windows Vista SP1/SP2 32-bits
Windows XP SP3 32-bits
Windows Server 2008 Terminal Server 64-bits
Windows Server 2008 R2 Terminal Server 64-bits
Windows Server 2003 Terminal Server 32-bits
Windows Server 2003 R2 Terminal Server 32-bits
Nota: Si se utilizará Windows 7 como escritorio virtual, el host que lo hospede debe ser ESX 4.0 U2 o superior o ESXi 4.1 o superior.

View Client
A continuación un detalle de los sistemas operativos soportados para View Client:

Windows 7 32 y 64 bits
Windows Vista SP1/SP2 32-bits
Windows XP SP3 32-bits

Instalación y Configuración de VMware View

Habiendonos introducido a VMware View 5.0 y conociendo sus requerimientos, a continuación detallaremos el proceso de Instalación y Configuración de VMware View:

Preparación de Active Directory
Instalación de VMware View Connection Server 5.0
Instalación de VMware View Composer 2.7
Configuración Inicial
Creando y Optimizando los Escritorios Virtuales
Creación de un Pool Manual de escritorios virtuales.
Creación de un Pool automatico de escritorios virtuales.
View Persona Management

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware:

vSphere: Qué es y cómo funciona Beacon Probing

2011-11-14T19:16:00.000-03:00

Hola a todos!

En esta ocasión hablaremos sobre los mecanimos de detección de fallas en la red, en una plataforma VMware, especificamente de Beacon Probing.

Beacon Probing es un mecanismo de deteccion de fallas en la red que envia y escucha Sondas o paquetes Beacon (Beacon Probes) en todas las NICs configuradas en Team (NIC Teaming), y utiliza esta información junto con el estado del link para identificar fallas en algún enlace uplink. Beacon Probing detecta fallas como desconexión de cables y fallas de energia de los switches fisicos contiguos, asi como tambien en los switches downstream (switches que no estan conectados directamente al host).

Como funciona Beacon Probing?

Periodicamene un host ESX/ESXi envia broadcast de paquetes beacon desde todos los uplinks en un team. La idea es que el Switch fisico reenvie todos los paquees a los otros puertos en el mismo dominio broadcast. Debido a lo anterior, se espera que los miembros de un Team vean los paquetes Beacon enviados por otros miembros del Team. Si un uplink no recibe correctamente 3 paquetes beacon consecutivos, dicho uplink es marcado como fallido. Esta falla puede encontrarse en el link al Switch fisico al que se conecta el host, o en un link downstream.

El uso de Beacon Probing es util en Teams con 3 o más uplinks. Cuando hay solo 2 NICs en un team configurado con Beacon Probing y uno de ellos pierde conectividad, no queda claro cual NIC debe ser sacada de servicio, debido a que ninguna de ellas recibe los paquetes beacon generados por los uplinks del Team.

Usando al menos 3 NICs en un Team es posible detectar hasta N-2 fallas, donde N es el numero de NICs en el Team antes de alcanzar una situación de deteccion ambigua de fallas. Por ejemplo:

Si un Team cuenta con 4 NICs, utilizando la formula de N-2, es posible detectar fallas de hasta 2 NICs en el Team, antes de que Beacon Probin deje de ser efectivo y entregue resultados ambiguos.

Se recomienda habilitar Beacon Probing en los siguientes casos:

El Team cuenta con 3 o más NICs.
Cuando las fallas de link downstream (links que no se conectan directamente al host) pueden impactar la disponibilidad.
Cuando Link State Tracking no se encuentra disponible en el Switch Fisico.

Espero que les sea de utilidad

vSphere 5: Soporte Virtual Numa (vNUMA)

2011-11-04T13:11:00.000-03:00

En un post anterior describimos la arquitectura NUMA y como esta se integraba con los mecanismos de administración de recursos en vSphere 4.x.

En vSphere 5, si bien la arquitectura base no sufrió cambios, se introduce el soporte para exponer la topologia NUMA virtual a los sistemas operativos de las máquinas virtuales, lo cual permite mejorar la performance facilitando el uso de las optimizaciones NUMA tanto por el sistema operativo, como por las aplicaciones "NUMA-aware" en las MVs.

La topologia NUMA virtual o vNUMA se encuentra disponible en MVs que utilizan hardware virtual version 8, y está habilitado por defecto cuando el numero de vCPU es mayor a 8. Esto ultimo es posible de cambiar modificando el parametro avanzado "numa.vcpu.min".

vNUMA permite que los sistemas operativos y aplicaciones dentro de una MV puedan tomar decisiones NUMA-aware más inteligentes respecto a la asignación de memoria fisica y procesos/threads.

El soporte vNUMA es de mucha utlidad en grandes MVs, las cuales necesariamente utilizan más de un nodo NUMA en un host.
Esto permite un aumento significativo en la performance para aplicaciones intensivas en el uso de memoria, permitiendo alcanzar una performance muy cercana a la performance nativa en el mundo fisico.

Mayor información la pueden obtener en los siguientes links:

VSP2884 - What's New in Performance for VMware vSphere 5.0 (VMworld)
vSphere Resource Management Guide

vSphere 5: Cambios en el calculo de Slot Size.

2011-10-29T00:20:00.000-03:00

En un post anterior detallamos como se realiza el calculo del Slot Size, y su relación con el funcionamiento de HA en vSphere 4.1, cuando esté ultimo se encuentra configurado con el Control de Admision habilitado, utilizando la politica de tolerancia a fallas de 1 o más hosts.

Con el lanzamiento de vSphere 5, el calculo de Slot Size sufrió un pequeño pero importante cambio, lo cual permite un radio de consolidación aun mayor.

En esta ocasión no explicaremos todo el proceso de calculo del Slot Size, y los Slots disponibles en un cluster HA, ya que lo explicamos previamente en el post ya mencionado y el proceso es basicamente el mismo. A continuación detallaremos el cambio realizado en vSphere 5, y en como afecta al funcionamiento de HA.

Slot Size

Para calcular el Slot Size, VMware realiza los siguientes cálculos:

HA calcula el Slot Size de la CPU, según la mayor reserva de CPU entre todas las máquinas virtuales del Cluster. Si no hay reservas, el valor por defecto para el Slot Size es de 32Mhz.
HA calcula el Slot Size de la Memoria con la mayor reserva de memoria entre todas las maquinas virtuales del Cluster ,más el valor de "Memory Overhead". Si no hay reservas, se utiliza el valor de "Memory Overhead".

He aquí donde observamos el cambio, pequeño pero muy importante, que se ha introducido para HA en vSphere 5, ya que ahora el Slot Size por defecto para la CPU, es ahora de solo 32 Mhz, mientras que en vSphere 4.1 era de 256 Mhz. Esto quiere decir que si no se utilizan reservas de CPU en un clúster dado, el Slot Size será solo de 32 Mhz, permitiendo el encendido de más Máquinas Virtuales en un clúster HA, mientras se respeta la política de Control de Admision.

El resto del proceso del calculo de Slots disponibles en Cluster HA es el mismo utilizado en vSphere 4.1 y que detallamos en el siguiente post:

http://www.patriciocerda.com/2011/04/vmware-ha-y-slot-size.html

Para mayores detalles sobre como funciona HA en vSphere 5, pueden leer el siguiente post publicado recientemente en este blog:

http://www.patriciocerda.com/2011/09/vsphere-5-como-funciona-ha-y.html

La guia oficial de Disponibilidad en vSphere 5 la pueden encontrar en el siguiente link:

http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-availability-guide.pdf

Espero les sea de utilidad.

vSphere 5: Eliminar warning en ESXi por Shell y SSH habilitado

2011-10-24T00:00:00.000-03:00

Hola a todos!

Solo un pequeño tip sobre como eliminar el warning que se genera en los hosts ESXi al momento de habilitar SSH remoto, o la Shell local en dichos hosts. Este warning es mostrado como una medida de seguridad proactiva para asegurar que los administradores de la plataforma virtual son conscientes de que el acceso remoto ha sido habilitado para dicho host.

Importante: Se debe destacar que como buena practica de seguridad, tanto SSH como la Shell local NO debieran estar habilitados en los hosts ESXi.

Al momento de habilitar SSH en un host ESXi, se muestra el siguiente warning a traves de vSphere Client:

Para poder eliminar este warning, debemos seleccionar el host ESXi en el inventario, dirigirnos a la sección "Configuration" y seleccionar "Advanced Settings" en el menú "Software"

En la ventana que se abre a continuación, seleccionar en el panel izquierdo la opción UserVars. Una vez seleccionado, buscar el parametro UserVars.SupressShellWarning, el cual por defecto se encuentra con el valor 0. Para eliminar el warning, el parametro debe ser modificado dejandolo con el valor 1.

Presionamos OK para guardar los cambios, con lo cual el warning desaparece de forma inmediata, sin necesidad de reiniciar el host ESXi.

Nota: Estas instrucciones aplican solo en vSphere 5. En vSphere 4.x, la unica manera de quitar este warning es deshabilitando SSH.

Espero les haya sido de utilidad. Saludos a todos!!!

Nuevo sponsor del Blog - Veeam!

2011-10-11T13:10:00.000-03:00

Hola a todos!

Solo una pequeña nota para contarles de que a partir de esta semana, Veeam Software se ha transformado en el primer sponsor de este humilde Blog.

Ya he publicado algunos artículos sobre los productos de Veeam, y espero seguirles informando de las novedades que vayan apareciendo acerca de sus soluciones.

Gracias a todos por seguir este Blog, y a Veeam por el apoyo.

Como customizar mensajes en vCenter 4.1

2011-10-05T10:37:00.010-03:00

1.- Los mensajes de eventos que maneja vCenter, se encuentran ubicados en el servidor de vCenter dentro de "Program Files\VMware\Infrastructure\VirtualCenter Server\locale".

2.- Dentro de esa carpeta encontraremos varias subcarpetas con nombres como de, en, fr, ja, etc… que hacen referencia al idioma. Por defecto la instalación en inglés utilizará los mensajes contenidos en “en_US”, carpeta que no siempre existe, por lo tanto sacamos una copia a la carpeta en para pegarla en la misma ubicación bajo el nombre “en_US”.

3.- Abrimos la carpeta en_US (o la correspondiente al idioma que ha sido instalado vCenter) y abrimos los archivos con Notepad o nuestro editor de texto preferido.

4.- Modificamos el mensaje del evento, guardamos, reiniciamos el servicio de vCenter y listo..!! nuestro mensaje ha quedado customizado según nuestra necesidad.

vSphere: Importancia de la alineación de particiones.

2011-10-04T00:33:00.002-03:00

El alineamiento de las particiones es un problema conocido en los sistemas de archivos, tanto en servidores fisicos como virtuales. El correcto alineamiento de las particiones en las MVs y de los datastores VMFS, evita la degradación en la performance de I/O, por lo que se considera una buena practica.

Muchos creen que este problema se limita solo al mundo físico, debido a que las VMs no utilizan arreglos RAID sino uno o más discos VMDK, por lo que no requieren de alineamiento de particiones. GRAN ERROR! A pesar de que las MV no utilicen RAID dentro de su sistema operativo, los archivos VMDK utilizados por las MVs se encuentran montados en LUNs, las cuales SI utilizan RAID. Recordar que las LUNs en una SAN están formadas por arreglos de discos en RAID.

Importancia del alineamiento de discos en VMware.
Muchos analisis de performance han destacado el hecho de que el apropiado alineamiento de discos para particiones VMFS y sistemas de archivos NTFS mejoran la performance de I/O, asi como reduce la latencia y aumenta el throughput.

VMware reporta que el throughput puede aumentar hasta un 62% (con un promedio de 12%), mientras que la latencia se reduce hasta un 33% (con un promedio de 10%), al contar con un apropiado alineamiento e discos.

En un ambiente SAN, la unidad de hardware más pequeña usada por un Storage SAN para construir una LUN a partir de multiples discos fisicos, es llamado chunk o stripe. Para optimizar el I/O, los chunks son usualmente mucho más grande que los sectores. De este modo, una petición de I/O SCSI que intenta leer un sector, en realidad lee un chunk.

Como segunda capa se encuentra el sistema de archivos para máquinas virtuales, o VMFS, el cual está formado de bloques.

Finalmente, la tercera capa es el archivo de discos de la MV (VMDK), y está formado de clusters, debido a que se encuentra formateado con el sistema de archivos NTFS (para el caso de SO Microsoft).

La siguiente figura que tomo prestada desde un articulo de VMware, muestra que una estructura de almacenamiento desalineada puede causar muchas operaciones de I/O adicionales, cuando solo un cluster es leido por el sistema operativo de la MV.

Como la figura muestra, al intentar leer un cluster de disco se podría provocar lecturas en hasta 3 chunks en la LUN de la SAN.

Del mismo modo, la siguiente figura muestra las mejoras en un volumen NTFS alineado apropiadamente con el volumen VMFS y la LUN de la SAN.

Como la figura muestra, al intentar leer un cluster de disco se realizan lecturas en solo 1 chunk en la LUN de la SAN.

Alineamiento de VMFS
Los datastores VMFS estarán siempre alineados si ellos son creados utilizando el vSphere Client. Por lo anterior, se recomienda evitar el uso del comando vmkfstools para crear un Datastore.

Una partición VMFS alineada utiliza un offset de 128 (64KB) como punto de inicio. Si se utiliza vmkfstools, la partición utiliza un offset de 63 (por defecto) como punto de inicio, por lo que queda desalineada.

Para verificar la alineación de VMFS, utilizar el comando "fdisk -lu" y asegurar de que el offset efectivamente es 128.

Si desean crear una particion alineada utilizando vmkfstools, o se desea alinear una partición VMFS desalineada, utilizar los pasos detallados en el siguiente LINK, en la sección "Align VMFS to LUN".

Alineamiento de MV
En el sistema de archivos NTFS, la unidad de datos más pequeña es una unidad de asignación o clúster. Para los discos de datos es posible cambiar el tamaño del clúster, sin embargo, para el volumen de sistema el tamaño del cluster debe ser de 4KB para que el sistema bootee apropiadamente.

Sistemas operativos en arquitecturas x86 crean particiones con un MBR (master boot record) que consume 63 sectores de offset. Esto se debe al antiguo codigo de las BIOS de los PCs que usaban cilindros, cabezales y sectores para el direccionamiento, en vez de utilizar LBA (logical block addressing).

Como saber si lo discos de la MV están desalineados?
Recordar en primer lugar que los sistemas x86 utilizan los primeros 63 sectores para el MBR. Usualmente hay 512 bytes por sector, por lo que 63 sectores corresponde a 32.256 bytes.

Si consideramos que el volumen de sistema en Windows está formateado con un tamaño de cluster de 4KB (4096 bytes) podemos determinar que la partición no se encuentra correctamente alineada, dividiendo los 32.236 bytes contenidos en los 63 sectores, por los 4096 bytes del tamaño del cluster, lo cual NO nos entrega un valor entero (7,875). La partición no se encontrará alineada con el limite de 4KB a menos que el punto de inicio sea divisible en forma exacta por 4096.

Para alinear la partición, se debiera utilizar un offset de 64KB (65.536 bytes) como punto de inicio, lo cual al dividirlo por el tamaño del cluster (4096 bytes), nos da un valor entero indicando que la partición se encuentra alineada. Este offset de 64KB coincide además con el offset utilizado en las particiones VMFS al crearlas utilizando el cliente vSphere.

A pesar de que Windows escribe datos en el disco en clusters de 4KB, Windows XP, 2000 y 2003, en forma incorrecta, comienzan a escribir datos a partir del sector 63 debido a la arquitectura de la MBR (Master Boot Record). Esto significa, que al momento de escribir datos, parte de estos son escritos en un bloque del datastore VMFS, y los restantes son escritos en el siguiente bloque. Esto implica que en cada operación de lectura y escritura, se deben acceder a dos bloques en vez de solo uno, afectando fuertemente la performance. Esto afecta a cualquier volumen creado en dichos sistemas operativos, a menos que se configure adecuadamente con diskpart.

Se debe destacar que en sistemas operativos Windows Server 2008 y superior, las particiones se encuentran alineadas correctamente por defecto, lo cual no ocurre en versiones anteriores como Windows Server 2003.

En Windows 2008 se utiliza un offset de 1024KB como punto de inicio de una partición de 4GB a 2TB. Para discos más pequeños, el offset utilizado es de 64KB. Con esto podemos estar seguros que una partición en Windows 2008 siempre estará alineada. (LINK)

Antes de Windows 2008, las particiones NTFS necesitaban ser alineadas manualmente utilizando la utilidad diskpart. Aunque el procedimiento es simple, el alineamiento debe ser hecho al momento de crear la partición, antes de que esta sea formateada. Al intentar ajustar la alineación de particiones posteriormente, toda la data existente en el disco será destruida.

Para sistemas operativos que no se encuentran alineados por defecto, se recomienda trabajar con un Template de una MV cuyas particiones hayan sido alineadas previamente, lo cual permite ahorrar tiempo de implementación de nuevas MVs.

Se debe destacar que alinear el volumen de booteo dentro de una MV, no es recomendado ni requerido. Esto se debe a que en general, las aplicaciones que tienen un uso de I/O intensivo, son ubicadas en un disco dedicado para esos datos, y no en el disco de booteo, por lo que solo se requiere alinear los discos de datos.

Recomendaciones
Se recomienda alinear los discos de las MVs en las siguientes circunstancias:

Al usar Templates de MVs. Las particiones de Datos debieran estar siempre alineadas
Particiones de MVs que tengan un uso intensivo de I/O como FileServers, Bases de Datos, o almacenes de Exchange.

Del mismo modo, no se recomienda alinear los discos en las siguientes circunstancias:

Discos de sistema (boot) de una MV, a menos que haya una buena razón para hacerlo.
Alinear todas las MV solo por hacerlo. Se recomienda analizar si existirá una real mejora en la performance luego de alinear los discos, de lo contrario, puede que el esfuerzo involucrado en el proceso no valga la pena.

Links de interes

Un interesante articulo sobre una herramienta para detectar MV desalineadas: http://blog.e2h.net/2011/05/31/alineacion-vmfs-y-maquina-virtual/
Whitepaper de alineación de particiones en ESX 3 (aun muy util): http://www.vmware.com/pdf/esx3_partition_align.pdf
Explicación del alineamiento en Windows 2008: http://frankdenneman.nl/2009/05/windows-2008-disk-alignment/
Interesante articulo de Duncan Epping para alinear los discos virtuales de una VM: http://www.yellow-bricks.com/2010/04/08/aligning-your-vms-virtual-harddisks/
Best Practices de performance en vSphere 4: http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.1.pdf
Articulo de Alineación de Storage en sitio VMware: http://communities.vmware.com/docs/DOC-11458

Veeam Backup and Replication 6 - What's New!

2011-09-28T01:50:00.001-03:00

En algunas semanas más Veeam Software hará el lanzamiento de la nueva versión de su producto Veeam Backup & Replication 6.

Una de las novedades que Veeam ha revelado, es el soporte para Hyper-V, además de el soporte para vSphere porsupuesto =) Lo interesante es que desde una unica consola se podrán realizar respaldos y restauraciones, tanto de hosts ESX/ESXi, como de hosts Hyper-V, permitiendo una administración completamente centralizada.

No obstante lo anterior, SureBackup (validacion automatica de respaldos) e Instant VM Recovery (Ejecutar una VM desde el almacen de respaldos), no estarán disponibles aún para Hyper-V en este nuevo lanzamiento. Todas las otras nuevas funcionalidades estarán disponibles tanto para Hyper-V como para vSphere.

A continuación un resumen de las nuevas caracteristicas de Veeam Backup 6, las cuales fueron anunciadas en el VMworld 2011 en Las Vegas. La presentación la pueden descargar desde el siguiente link, además, para los asistentes al VMworld, está disponible la grabación de la sesión (SPO3981) en el sitio www.vmworld.com.

Arquitectura:
Ahora podemos observar una arquitectura distribuida, pudiendo separar los roles.

Antes:

Servidor de Backup

Ahora:

Servidor de Backup: Administración y balanceo de carga
Servidor Proxy: Obtener datos del origen
Servidor Repositorio: Escribir los datos en el repositorio.

Esta arquitectura provee mejoras significativas en la replicacion para ESXi, asi como tambien permite realizar respaldos en almacenamiento remoto, sobre la WAN, pensado especialmente para infraestructuras Cloud.

Además, esta nueva arquitectura permite un deploy y mantención automatica, asi como un balanceo de carga inteligente.

Se incluye además un balanceo de carga inteligente, dentro y entre los jobs.

Finalmente, esta arquitectura simplifica el crecimiento de la plataforma en el tiempo:

Proxies ligeros
Deploy y mantención automatica
Streamlines ROBO (remote office/branch office) e implementaciones a gran escala.

Replicación
La funcionalidad de replicacion tiene además una serie de nuevas funcionalidades, que le permiten competir bastante bien con lo que es Site Recovery Manager 5.

Re-IP on failover
Real failback
Seed from backup
Replica mapping
Preserve thin disks
Replicate to cluster
Traffic throttling

Quick Migration

Se incluye un asistente para migrar una o más MVs:

Desde un host a otro
Desde un datastore a otro
Ambos

Quick Migration es Instant VM Recovery aware.
Utiliza vMotion y Storage vMotion si es que están disponibles.
En caso contrario, utiliza la tecnologia de replicación de Veeam:

Entre hosts standalone
A un nuevo storage
etc.

Tambien utiliza, cuando es posible, la nueva tecnologia Veeam SmartSwitch

Elimina el downtime
Pausa el origen -> Copia el estado de la memoria -> Reanudar la MV en el destino.

Otras mejoras

Restauración de archivos en 1 Click
Restauración de MV en 1 Click

Para conseguir mayor información, pueden registrarse a la serie de Webinar que Veeam estará ofreciendo para detallar todas las nuevas funcionalidades del producto.

vSphere 5: Como funciona HA y Recomendaciones

2011-09-19T02:32:00.000-03:00

VMware HA permite que multiples hosts ESXi puedan ser configurados como un cluster para proveer de alta disponibilidad y una rapida recuperacion ante fallos, para todas las máquinas virtuales en dichos hosts.

HA protege la disponibiliad de las siguientes formas:

Protege contra fallas de servidores, reiniciando las máquinas virtuales en otros hosts dentro del cluster.
Protege contra fallas de aplicaciones monitoreando continuamente una máquina virtual, y reseteandola en caso de detectar una falla.

VMware HA cuenta con las siguientes caracteristicas que lo diferencian de otras soluciones de Clustering tradicionales:

No se necesita instalar ningún software especial dentro de la aplicación o máquina virtual. Toda la carga de trabajo es protegida por HA, y después que esta es configurada, no se requiere de otras acciones para proteger a las nuevas máquinas virtuales que se vayan agregando en el tiempo. Estas ultimas serán protegidas automáticamente.
Es posible combinar vSphere HA con DRS (Distributed Resource Scheduler) para proteger contra fallas, y para proveer de balanceo de carga entre todos los hosts dentro de un cluster.
Reducción de costo en hardware y configuración. Una MV puede ser movida entre los hosts, por lo que se evita la necesidad de duplicar la configuración en multiples máquinas como en otras soluciones de clustering. Solo se requiere contar con suficientes recursos para soportar la caida de 1 o más hosts, dependiendo del nivel de protección que se quiera tener.

Como funciona VMware HA?
HA provee de alta disponibilidad a las MV formando clusters donde residen los hosts y dichas MV. Los hosts en un cluster son monitoreados, y ante la falla de un host, las MV que residen en dicho host son reiniciadas en otros hosts que se encuentren disponibles en el cluster.

En versiones anteriores a vSphere 5, en un cluster HA existian los hosts primarios y secundarios, donde los 5 primeros hosts unidos a un cluster HA, funcionaban como primarios, y el resto como secundarios.

En vSphere 5, cuando se crea un cluster HA, uno de los hosts es designado como "Master host" o host maestro, para comunicarse con vCenter Server y monitorear el estado de los otros hosts y sus MV. Este host maestro debe ser capaz de detectar y tratar apropiadamente con los diferentes tipos de fallas que pueden afectar a un host. Se debe distinguir, por ejemplo, entre un host con fallas, de uno que ha llegado a estar aislado en la red.

Hosts maestros y esclavos
Cuando un host es unido a un cluster HA, un agente es instalado y configurado en el host, para comunicarse con otros agentes en el cluster. Cada host en un cluster funciona como maestro o esclavo.

Cuando se habilita HA en un cluster, todos los hosts ACTIVOS participan en una elección para elegir al host maestro del cluster. El host que tenga el mayor numero de datastores montados tiene una ventaja en la elección. Solo existe 1 host maestro por cluster, si este falla, es apagado, o es removido del cluster, se realiza una nueva elección. Estas son las responsabilidades de un host maestro:

Monitorear el estado de los hosts esclavos. Si uno de estos falla o se encuentra aislado, el host maestro identifica que VM necesitan ser reiniciadas.
Monitorear el estado de todas las MV protegidas. Si una MV falla, el host maestro se asegura que ésta sea reiniciada. Además, usando un motor de ubicación, el host maestro tambien determina donde se debiera realizar el reinicio.
Gestiona la lista de hosts y MV protegidas del cluster.
Actua como interfaz de administración con vCenter Server, y reporta el estado de salud del clister.

Los hosts esclavos contribuyen al cluster ejecutando las MV, monitoreando su estado de ejecución, y reportando las actualizaciones de estado al host maestro. Un host maestro, obviamente, tambien puede hospedar y monitorear MV.

Otra de las funciones realizadas por un host maestro, es la protección de MVs. Cuando se protege una MV, HA garantiza que intentará volver a encenderla despues de una falla (failover). Las MV protegidas son aquellas en estado activo, no considerandose las MV apagadas.

vCenter Server reporta si un host es un host maestro - "Running (Master)" - o esclavo - "Connected (Slave)" - usando lo que se conoce como "vSphere HA host state". Este estado es reportado en el tab "Summary" del host, en el vSphere Client, y en la vista de hosts en un Cluster o Datacenter.

Tipos de falla de Host y su Detección.
Como ya mencionamos, el host maestro en un cluster HA es responsable de detectar la falla en un host esclavo, y dependiendo del tipo de falla detectada, las MV en dicho host podrian ser reiniciadas en otro host. Existen 3 tipo de fallas que pueden ser detectadas:

Un host deja de funcionar, por ejemplo, por falla de hardware.
Un host queda aislado en la red.
Un host pierde conectividad con el host maestro.

El monitoreo del estado de los hosts se realiza a traves del intercambio de heartbeats en la red, cada segundo.
Cuando el host maestro deja de recibir estos heartbeats desde los hosts esclavos, se chequea el estado de conexión del host antes de declararlo como fallido. Este chequeo incluye determinar si el host esclavo está intercambiando heartbeats con uno de los datastores, lo cual veremos en más detalle a continuación. También se comprueba si el host responde a las pruebas de Ping enviadas a su IP de administración.

Si ninguna de estas pruebas es exitosa, el host finalmente es considerado como fallido. En este caso las MV de dicho host son reiniciadas en otros hosts del mismo cluster.

En cambio, si el host esclavo sigue intercambiando heartbeats con un datastore, el host maestro asume que es un problema de División de Red o Aislamiento de red, y continua monitoreando el host y sus MV.

Un aislamiento de red de un host ocurre cuando un host se encuentra aún en funcionamiento, pero no existe comunicacion con los agentes HA a través de la red de administración. En estos casos, el host intenta llegar a traves del comando ping a la dirección de aislamiento del cluster. Si esto ultimo también falla, el host se declara a si mismo como aislado en la red. En este caso, el host maestro monitorea las MV que están en ejecución en el host aislado, y actuará según los parametros configurados en el cluster HA, pudiendo, por ejemplo, reiniciar las MV en otro host, o permitiendo que las MV sigan en ejecución en el host aislado, mientras se soluciona el problema.

División de Red
Cuando ocurre algun fallo en la red de administración en un cluster HA, un conjunto de hosts de dicho cluster podria no ser capaz de comunicarse con los otros hosts a traves de dicha red. Esto puede provocar multiples divisiones en un cluster.

Un cluster dividido provoca degradacion en la protección de las MV, y en las funcionalidades de gestion del cluster:

Protección de MV: vCenter permite que las MV sean encendidas, pero es protegida solo si esta corriendo en la misma división en la que se encuentra el host maestro que es reponsable de protegerla.
Gestión del Cluster: En una división, vCenter Server se puede comunicar con solo algunos de los hosts del cluster, y se puede conectar solo a un host maestro. Cambios en la configuración que afecta a HA podrian no tomar efecto hasta solucionar la división, ya que una división podria tener una configuración más nueva que otra.

Nota: Cuando ocurre una división en un cluster HA, solo se pueden agregar host a la división con la que vCenter Server se puede comunicar.

Datastore Heartbeating
Cuando el host maestro en un cluster HA no se puede comunicar con un host esclavo sobre la red de administración, el host maestro utiliza el Datastore Heartbeating para determinar si el host esclavo a fallado, se encuentra en una división de red, o está aislado en la red. Si el host esclavo ha dejado de realizar el Datastore Heartbeating, es considerado como host fallido y sus MV son reiniciadas en otros hosts del cluster.

vCenter Server selecciona un conjunto preferido de datastores para realizar el heartbeating. La seleccion esta pensada para maximizar el numero de hosts que tienen acceso al datastore, y minimizar la posibilidad de que los datastores se encuentren en el mismo Storage o servidor NFS. Esta selección puede ser modificada manualmente, en los parametros de configuración del cluster. Para todos los efectos, solo se pueden utilizar datastores montados en al menos dos de los hosts disponibles.

Adicionalmente, se puede utilizar el atributo das.heartbeatdsperhost, para cambiar el numero de datastores seleccionados por vCenter en cada host. Por defecto se selecciona 2, y el valor maximo es 5.

Control de admisión
HA utiliza control de admisión para asegurarse de que existan suficientes recursos disponibles en el cluster para proveer de alta disponibilidad y asegurarse de que las reservaciones de recursos de las MV sean respetadas.

Existen tres tipos de control de admisión:

A nivel de Host: Se asegura de que un host tenga suficientes recursos para satisfacer las reservaciones de todas las MV que corran en el.
A nivel de Resource Pool:Se asegura de que un RP tenga suficientes recursos para satisfacer las reservaciones, shares, y limites de todas las MV en el.
A nivel de Cluster HA: Se asegura de que se reserven suficientes recursos en un cluster para la recuperación de MV ante la falla de un host.

El control de admision impone restricciones en el uso de recursos y cualquier accion que pudiera violar dichas restricciones, no está permitida, como por ejemplo:

Encender una MV
Migrar una MV otro host, cluster o Resource Pool.
Aumentar la reservacion de memoria o CPU de una MV.

De estos tres tipos de control de admision, solo es posible deshabilitar el control de admisión en un cluster HA. No obstante, esto no es considerado una buena practica, ya que no permite asegurar que las MV sean reiniciadas despues de una falla.

En algunos casos, puede ser necesario deshabilitar el control de admision en forma temporal, por ejemplo, durante el mantenimiento de uno o más hosts en un cluster. En estos casos, se recomienda volver a habilitarlo a la brevedad posible.

Politicas de control de admision
El control de admisión en un cluster HA puede ser configurado con una de las 3 politicas de admisión disponibles:

Tolerar fallas de host en un cluster: permite configurar HA para tolerar un numero especifico de fallas de hosts. Con esta politica de control de admisión, HA se asegura que un numero especifico de hosts puedan fallar, y aun queden suficientes recursos disponibles en el cluster para hospedar a todas las MV de dichos hosts.
En esta politica, HA realiza el control de admisión calculando el Slot Size, lo cual hemos explicado anteriormente.
Porcentaje de recursos reservados en el cluster: Permite configurar HA para controlar la admisión reservando un porcentaje especifico de los recursos de CPU y Memoria para la recuperación ante la falla de uno o más hosts.
Esta politica utiliza las reservaciones de las MV para aplicar el control de admisión. Si una MV no tiene reservas, se aplican los valores por defecto de 0MB de RAM y 256Mhz de CPU.
Especificar hosts para failover: Permite configurar HA para designar hosts especificos como hosts para failover. Con esta politica, cuando un host falla, HA intenta reiniciar sus MVs en uno de los hosts especificados para el failover. Si esto no es posible, por la falla de uno de estos hosts designados, o por falta de recursos suficientes, HA intenta reiniciar las MVs en otros hosts en el cluster.

Para asegurar de que exista capacidad suficiente en un host de failover, se evita que una MV sea encendida, o migrada con vMotion a dicho host. Estos hosts además no son utilizados por DRS para el balanceo de carga.

Elegir una politica de control de admision.
Se debiera elegir una politica de control de admisión para HA, basado en las necesidades de disponibilidad, y en las caracteristicas del cluster. Se deben considerar una serie de factores:

Evitar la fragmentación de recursos, lo cual ocurre cuando hay suficientes recursos en un cluster para las operaciones de failover, no obstante, estos recursos están repartidos en multiples hosts, y por lo tanto no son utilizables porque una MV puede correr sobre solo un host ESXi a la vez. Las politicas "Tolerar fallas de host en un cluster", y "Especificar hosts para failover", se evita esta situacion.
Flexibilidad en la reservación de los recursos para Failover. Cada politica difiere en la granularidad del control que ellas dan cuando reservan recursos del cluster para failover.
Heterogeneidad del Cluster. Un cluster puede ser heterogeneo en terminos de la reservación de recursos de MV, y la capacidad total de recursos en los hosts. En un cluster heterogeneo, la politica "Tolerancia a fallas de hosts" es muy conservadora ya que solo considera las reservaciones de la MV más grande cuando se define el Slot Size, y asume la falla del host más grande cuando se calcula la capacidad de failover actual. Las otras dos politicas no son afectadas por la heterogeneidad del cluster.

Recomendaciones
A continuación una serie de recomendaciones a la hora de planificar/configurar un cluster HA.

Planificar para la renovación de Hardware. Se debe considerar que a medida que el ambiente virtual se vuelve antiguo, el hardware es renovado y/o se agrega nuevo hardware. Estas renovaciones/adiciones en ocasiones pueden provocar problemas de compatibilidad con vMotion. Se debe planificar y configurar un cluster HA pensando en los futuros cambios de hardware, considerando por ejemplo, el uso de Enhanced VMotion Compatibility (EVC)
Planificar el numero de hosts suficientes en un cluster. Se deben considerar los recursos para las operaciones de failover de MV en un cluster HA.
Seleccionar la politica de control de admision correcta, deacuerdo a las necesidades de disponibilidad y a las características del cluster que se ha diseñado.
Al momento de configurar la política de control de admision, no desperdiciar los recursos disponibles. Considerar que:

No todas las MV son de misión critica o primera prioridad
Algunas MV pueden permanecer apagadas por un periodo de tiempo ante la caida de un host
Algunas políticas de control de admisión reservan uno o más hosts para failover, lo cual puede ser un desperdicio de recursos en un cluster pequeño.

Priorizar el reinicio de las MV durante un failover en un cluster HA.
No deshabilitar el Control de Admisión. En ocasiones puede ser necesario deshabilitarlo, por ejemplo durante tareas de mantenimiento de uno o más hosts, no obstante, esto solo debe ser una medida temporal, y el control de admisión debe ser habilitado a la brevedad posible.
Si se utiliza la politica "Porcentaje de recursos reservados en el cluster", esta debe ser ajustada si el tamaño del cluster cambia, por ejemplo, al agregar hosts adicionales al Cluster.
Utilizar hosts similares. Si los hosts en un cluster tienen diferentes recursos disponibles, podrian afectar el funcionamiento de la politica "Tolerar fallas de host en un cluster", ya que esta reserva el host con más recursos en el cluster. Esto es necesario para proteger todas las MV, pero puede provocar un desperdicio importante de recursos.
Utilizar shares cuando sea posible, en lugar de usar reservaciones y limites. El uso desmedido de reservaciones puede afectar el Slot Size utilizado por la politica "Tolerar fallas de host en un cluster".
Asegurar de que todos los hosts en el cluster tengan acceso a los mismos datastores, y a las mismas redes. Esto asegurará que las MV puedan ser reiniciadas en cualquier host al momento de producirse una caida de un host en un cluster.

Espero les haya sido de utilidad, y pronto más novedades en el Blog de Tecnologias Aplicadas!

VMware View 5: What's New!

2011-09-13T03:59:00.000-03:00

Hola a todos, como algunos ya saben, durante el VMworld en Las Vegas se lanzó oficialmente VMware View 5.0 con una serie de mejoras que podemos ver a continuacion:

Servicios View Media para IUC (Integrated Unified Communications). Permite la integración de VoIP y escritorios View para el usuario final, con una arquitectura para proveer una performance optimizada, tanto para el escritorio como para la comunicacion unificada.
Servicios View Media para graficos 3D. Permite el uso de aplicaciones 3D basicas en escritorios View, sin la necesidad de tarjetas graficas o dispositivos clientes especializados.
Gestion de View Persona (Solo disponible en View Premier), asocia dinamicamente un perfil de usuario a un escritorio flotante. De esta forma es posible una gestion más sencilla de los escritorios flotantes, permitiendo que el perfil personalizado de cada usuario persista en cada sesion.
Servicios de extensión de PCoIP, que permite a herramientas basadas en WMI recolectar estadisticas de más de 20 sesiones, para monitoreo, reporte de tendencias, y troubleshooting.
Control de Optimización PCoIP, que permite contar con un protocolo más eficiente, y permite a los administradores configurar los parametros de ancho de banda según el caso de uso, usuario, o requerimientos de red, para consumir hasta un 75% menos de ancho de banda.
Servicios de Continuidad PCoIP, que entrega una gran experiencia al usuario final, sin importar la fiabilidad de la red, detectando interrupciones y reconectando automaticamente la sesión.
Cliente View para Android, para usuarios con tablets basadas en Android para acceder a escritorios virtuales en VMware View.
Parámetros de seguridad avanzados, que permiten un manejo personalizado de los certificados, para aplicar las políticas corporativas.
Soporte vSphere 5, asegura que los servicios de VMware View se ejecuten en la nueva infraestructura de Cloud Computing lanzada recientemente.

La descarga de VMware View tomará algunas semanas en estar disponible, pero ya podemos ver mayor información al respecto de esta nueva versión de View en el siguiente link:

http://www.vmware.com/products/view/overview.html

VMworld 2011 - Las Vegas, Anuncios realizados

2011-09-12T12:36:00.000-03:00

Ya ha pasado poco más de 1 semana desde que terminó el VMworld 2011 en Las Vegas, y vaya si que nos trajo bastantes novedades, especialmente a la hora de las Keynotes. Vamos viendo a continuación lo que nos dejó el mayor evento de virtualización del año.

Al estar acreditado como Blogger, logré una excelente ubicación en la sección de LiveBlogging, durante las Keynotes. Desde aqui pude asistir a las Keynotes, donde se realizaron una serie de anuncios bastante interesantes, los cuales detallaremos a continuación.

Projecto AppBlast: Permite que cualquier aplicacion Windows, Mac o Linux sea presentada en cualquier navegador o dispositivo que sea compatible con HTML5. No se requieren instalar agentes o add-ons en el cliente. Por ejemplo, se podria ejecutar Excel (el original), en un dispositivo iPhone.

Projecto Octopus: Permite al usuario final acceder a sus archivos desde cualquier lugar, y desde cualquier dispositivo. Puede ser mejor descrito como un Dropbox corporativo. Usando Octopus el area de TI tiene un control sobre quienes tienen acceso a los archivos, y la autenticación es gestionada utilizado el servicio de directorio de la empresa, como podria ser Active Directory. Los clientes se encuentran disponibles para varios clientes como Windows, Android y dispositivos Apple. Los documentos pueden ser vistos en el navegador sin tener que usar la aplicacion nativa utilizada para crear el documento. Se pueden configurar distintas politicas, como por ejemplo, cuantas copias estarán disponibles, y cuando espacio en disco puede ser utilizado.
Los agentes de sincronizacion permiten acceder a los archivos, incluso cuando el dispositivo esta sin conexión. Cuando el dispositivo se conecta nuevamente, los documentos serán sincronizados.
Octopus estará disponible durante el primer semestre del 2012, y se podrá descargar como un archivo OVF.
Si desean participar en el beta, pueden inscribirse en www.vmwareoctopus.com.

Proyecto ThinApp Factory: Permitirá encapsular aplicaciones Windows para una mayor utilidad a traves de todos los dispositivos. El concepto es similar a Software as a Service (SaaS).
Proyecto Horizon: La plataforma para la era post PC. Las nuevas actualizaciones a VMware Horizon extiende los beneficios de su motor de identidad, politicas y derechos, para aplicaciones windows y entornos de trabajo movil conectados. Esta solución provee de una plataforma abierta, centrada en el usuario, para ofrecer diferentes tipos de aplicaciones dentro de un catalogo unificado de aplicaciones para un amplio rango de dispositivos.
Horizon Mobile: Basado en VMware Mobile Virtualization Platform (MVP), ofrecerá nuevas funcionalidades que permiten a las organizaciones establecer y gestionar de manera segura los entornos moviles corporativos de los usuarios, en forma asilada de su ambiente movil personal. Gracias a esto, los usuarios tendrán la libertad de elegir un unico dispositivo basado en Android, tanto para uso personal como laboral.
VXLAN: Es un proyecto conjunto con Cisco System, propuesto como una forma de solucionar un problema muy especifico de infraestructuras IaaS, que es el reemplazo de las VLANs con algo más escalable (sobre 16 millones de redes logicas), ideales para construir Clouds.
VMware Essentials: Datacenter in-a-box, usando el vStorage Appliance.
VMware Go: Es un servicio SaaS pensado para pequeña y mediana empresa. Esto permite a las pequeñas y medianas empresas lograr una infraestructura implementada facilmente, utilizando vSphere.
VMware View 5.0: Paul Maritz anunció oficialmente el proximo lanzamiento de View 5, el cual incluye lo siguiente:

Hasta un 60% de mejora en la performance de PCoIP sobre la WAN.
Client Ubiquity: Cliente View en casi cualquier dispositivo.
Integración con VoIP/UC
Gestión de perfiles de usuarios.
Mejora en los graficos 3D

Otros datos interesantes obtenidos de la keynote:

Los usuarios VMUG a nivel mundial han alcazado los 60.000. Un gran logro para las comunidades.
Más de la mitad de los servidores que están siendo implementados hoy en dia, corresponden a máquinas virtuales. El punto de quiebre se produjo el año 2009, donde el numero de máquinas virtuales superó al de los servidores físicos.

Alguien enciende una MV cada 6 segundos!!!
20 millones de MVs corriendo sobre VMware vSphere a nivel mundial.

En cualquier punto del tiempo, hay más operaciones de vMotion de MVs, que aviones en vuelo en todo el mundo. Una operación de vMotion cada 5.5 segundos
Hay sobre 68.000 certificados VCP.
La suite de aplicaciones de VMware Cloud, será homologada a la versión 5.1, cuando se lance vSphere 5.1, de manera de tener una versión homologada para todos los productos que componen esta suite.

Otros lanzamientos

Veeam Backup and Replicator 6: Este lanzamiento lo veremos más en detalle en un proximo articulo.
HP VirtualSystem for VMware: Este es una infraestructura pre-configurada, probada y optimizada, contruida utilizando VMware, asi como tecnologias de servidores, almacenamiento y redes de HP, para proveer de una implementación más sencilla para los usuarios, permitiendo una rapida implementación, disminuyendo la dependencia de los recursos del area de TI.

Como ven, muchas novedades que pronto podremos estar utilizando en nuestros laboratorios. Espero les haya parecido interesante, y pronto más novedades!

VMworld 2011 - Las Vegas, comenzando el primer dia...

2011-08-29T19:41:00.001-03:00

Y aqui estamos ya en el primer dia de VMworld 2011 en Las Vegas. Ayer logré realizar el check-in en el evento, y asi evitar la aglomeración de hoy en la mañana. Por lo que se ha informado por aca, hay más de 20.000 asistentes esta año!!! mucha gente la verdad, y la organizacion del evento ha estado a la altura.

Tuve la oportunidad de asistir a los laboratorios hands-on para hacer pruebas con Autodeploy de vSphere 5, lo cual estuvo bastante interesante. La plataforma de laboratorios implementada es sencillamente monumental, pudiendo haber cerca de 500 usuarios conectados simultaneamente, asi espero poder sacarle provecho en los dias que quedan del evento. Hay muchos laboratorios disponibles, orientados principalmente a las nuevas funcionalidades de vSphere 5 y Cloud Computing.

No hay que olvidar tampoco las sesiones y charlas, y hoy ya he asistido a 2. La primera muy interesante y que detallaré más adelante en otro post, acerca de los 16 mayores errores en la configuración de HA y DRS en una plataforma vSphere. Esta afortunadamente fue muy animada, lo que sirvió para mantenernos despierto considerando que la sesión fue a las 8:30 hrs y yo casi no he dormido desde hace 2 dias =)

Luego estuve en otra sesión, muy interesante tambien, acerca de Metro vMotion. A pesar de lo interesante del tema, y de lo impecable de la presentación, no fue lo que esperaba, ya que fue más orientada a temas de negocio y no tanto a nivel tecnico.

Una ultima mención especial al area de descanso del VMworld 2011, la cual cuenta incluso con cancha de voleyball y toda una ambientación imitando a un parque, incluso con pasto!!! Habia varios tomando una siesta en este sector en los tiempos libres... como estamos en Las Vegas, hay que aprovechar los pocos momentos que hay para descansar =)

Eso por ahora, luego les entregaré mayores detalles sobre la sesión general del VMworld 2011 - Las Vegas, la cual esta a minutos de comenzar. Saludos!!!

vSphere 5 ya disponible para descarga!

2011-08-25T12:38:00.000-03:00

Finalmente ya se encuentra disponible la descarga de vSphere 5 para publico general, pudiendo descargar los medios de instalación desde el sitio de descarga de VMware.

Del mismo modo, se encuentra disponible toda la documentación oficial sobre vSphere en el sitio de documentación de VMware:

Para ver todas las novedades que incluye vSphere 5, pueden ver el post anterior What's New en vSphere 5