Nuevo fling – vSphere Replication Capacity Planning Appliance

Que tal gente, el día de hoy vamos a hablar rápidamente de un nuevo fling que nos entrega VMware Labs… vSphere Replication Capacity Planning Appliance (¿Nombre largo? :D). Recordemos que estos “flings” son herramientas o “previews” de tecnología que no tienen soporte por parte de VMware (aunque muchas veces estas tecnologías son agregadas a productos existentes).

¿Que es vSphere Replication Capacity Planning Appliance?

Este appliance virtual esta pensado para poder darnos una idea de la cantidad de información que estaremos replicando a través de vSphere Replication (replicación por medio de el hipervisor IP). Nos permite conocer el tráfico que estaría sucediendo a través de nuestros enlaces para replicar una VM en especifico, esto es muy útil ya que para poder dimensionar correctamente el ancho de banda y los RPOs para las VMs necesitamos conocer que tan “rápido” cambia la VM o esta teniendo cambios a nivel de los distintos bloques que constituyen su almacenamiento virtual, tratando de hacer esto de manera manual significa poder conocer el ritmo al cual cambia la VM, después tener esto a la mano debemos calcular lo que tomaría enviar estos cambios o “deltas” a través de nuestro enlace (sin considerar la replicación inicial de la VM donde se envía toda la VM), la formula se vería de la siguiente manera sin haber modificado ningún parámetro avanzado de buffers:

Size of changed data (bits) / Transfer speed (bps)= Transfer Time (seconds)

(esta fórmula la pueden encontrar en el articulo de Kene Wernebug, Sr. Technical Marketing Architect de  BC/DR en VMware)

Pero este cálculo manual tiende a poder fallar, a tomar mucho tiempo y no ser tan preciso, es por eso que parte del equipo de desarrolladores de vSphere Replication se dieron a la tarea de crear este fling sencillo de utilizar para podernos apoyar en el dimensionamiento de nuestras replicaciones a través de vSphere.

Básicamente este appliance simula la replicación de una VM en específico que nosotros seleccionemos, en base a esto nos muestra la cantidad de ancho de banda utilizado y el “delta” (cambios en la VM) o información que sería enviada a la ubicación de DR a través de el enlace.

¿Como utilizo este appliance?

Uno de los puntos que me gusto bastante es la simplicidad para configurar este appliance, simplemente importamos el appliance a vCenter a partir de un .OVF, configuramos su IP y ¡Voila! esta listo para utilizarse:

VRapplianceUna vez que tenemos arriba el appliance virtual a través de SSH debemos ejecutar un comando para poder definir que VM estará siendo analizada:

./bin/configureReplication –vc IPDEVM –vcuser USUARIODEVCENTER –vcpass PASSWORD –lwd IPDEAPPLIANCE –vmname NOMBREDEVMASERANALIZADA

Con este comando estaremos dictando que vCenter es el que aloja la VM que necesitamos analizar, el appliance de vSphere Replication Capacity Planning y las credenciales necesarias para poder acceder a vCenter, una vez ejecutado el comando podemos ver que se comienza con la simulación:

replicacioncomandoA partir de 10 a 15 minutos podemos abrir un navegador y apuntar a la IP de nuestro appliance para poder observar la información que esta recolectando, esta información es mostrada en intervalos de horas, días, semanas y meses considerando 2 valores, LWD traffic que sería el ancho de banda utilizado y Delta Size que se trata de la información enviada (que ha cambiado de la VM) con esto (tomando en cuenta que monitoreamos todo el ciclo de producción de la VM) podemos dimensionar vSphere Replication y definir los RPOs que seremos capaces de cumplir:

infosizingiis7hispavirt

¿Donde encuentro este Fling?

Recordemos que este y muchos mas flings son publicados en el sitio web de VMware labs:

labs.vmware.com

Los invito a darle un vistazo a todos los flings que están disponibles, existen bastantes que son muy útiles.

vSphere App HA deepdive

Que tal gente, el día de hoy vamos a hablar sobre una tecnología que a mis ojos parece tener bastante potencial, claramente estaremos hablando de una versión 1.0 del producto por lo que debemos comprender que muchas cosas iran siendo agregadas conforme el tiempo pase. Esta vez voy a hablarles de vSphere App High Availability, tecnología de VMware que fue liberada a con vSphere 5.5, como lo podemos notar en su nombre es alta disponibilidad para nuestras aplicaciones vamos a darle un vistazo:

¿Que es vSphere App HA?

Todos conocemos (¿O eso creo?) vSphere HA, que nos permite brindar alta disponibilidad a nivel de VM protegiéndola contra caídas de infraestructura… a grandes rasgos realiza un reinicio de las VMs fallidas en un servidor que se haya caído o tenga problemas. ¿Pero que pasa con las aplicaciones?, digamos que tenemos un servidor ESXi funcional, la VM con el servicio esta siendo ejecutada sin ningún problema, pero dentro de esta vm en el sistema operativo guest la aplicación/servicio esta caído, en este caso HA nunca reiniciaría la VM debido a que esto no forma parte de su “responsabilidad” aquí es donde entra vSphere App HA, que en conjunto con Hyperic nos brinda la capacidad monitorear los servicios que están dentro de una VM para poder definir políticas que nos permitan ejecutar acciones correctivas para mantener la disponibilidad del servicio o aplicación que tenga dicha VM.

El poder de este producto es brindado por hyperic, para poder tener monitoreo dentro de nuestras VMs necesitamos instalar el agente de Hyperic en cada VM que tenga servicios soportados que queramos protejer con App HA. En el laboratorio de Hispavirt podemos ver como tengo el appliance virtual de Hyperic para este fin:

HypericOVA En este servidor de Hyperic iremos agregando todos los agentes para que se puedan monitorear los servicios que existen en dichas VMs.

App HA interactua con vSphere y Hyperic a través de un plugin de NGC (Next Generation Client) o el vSphere Web Client, que nos permite apuntar a un servidor de hyperic para registrar el servicio (existen algunos pasos que debemos de realizar en hyperic para tener las alarmas de vCenter funcionando esto lo pueden encontrar aquí) este plugin lo brinda el appliance virtual de App HA:

hypericconfvcenter

Una vez lista la configuración podemos comenzar a crear políticas para proteger los servicios que son descubiertos por el agente de Hyperic en nuestras VMs, para esta versión se tiene una lista definida de servicios soportados donde podemos encontrar los siguientes:

  • Apache Tomcat 6 y 7
  • IIS 6, 7 y 8
  • MS SQL 2005, 2008, 2008 R2 y 2012
  • Sharepoint 2007 y 2010
  • SpringSource tc Runtime 6 y 7

En el laboratorio me di a la tarea de crear una VM con Windows 2008R2 y IIS7, donde instale y configuré el agente de Hyperic para que esta fuera registrada en el inventario:

instalacionhypericUna vez instalado debemos verificar que es presentado en el “auto discovery” de hyperic y lo agregamos a nuestros recursos:

autodiscoveryiishypericCuando ya tenemos lista la VM dentro de Hyperic podemos comenzar con la creación de políticas, para que estas sean asignadas a dichas VM y así proteger el servicio o aplicación que este ejecutándose dentro de ella, para motivos de la demostración seleccione las siguientes opciones para un servicio de IIS7:

RemediacionAppHA Que son las opciones de “remediación” ofrecidas en el caso que el servicio de la VM se encuentre abajo. Podemos notar que tenemos la principal función que es “reiniciar” el servicio, donde definimos cuanto tiempo le toma iniciar a este servicio, en este caso puse 2 minutos aunque claro que esto debe de ir de la mano de lo que se tarde en su ambiente, después seleccione la opción de “Restart the VM in the event that the service is unstable” que nos permite dictarle a App HA que si no es capaz de levantar el servicio en repetidas ocasiones durante una ventana de tiempo definida (en este caso 2 veces en 10 minutos) que proceda a reiniciar la VM ya que puede ser un problema mas complicado a nivel del sistema operativo y un reinicio ayude a resolverlo.

Aquí pueden ver que mi política quedo creada y lista para ser asignada a la VM que tiene IIS7:

politicadefinidaAppHADespués debemos asignar esta política a la VM que será protegida con AppHA, para esto vamos a nuestro vSphere Web Client y seleccionamos nuestro vCenter Server, donde veremos una pestaña llamada “Monitor” y dentro de esta pestaña tendremos una nueva sección agregada por App HA “Application Availability” donde podremos agregar nuestra política:

políticaAppHAaplicada

Una vez aplicada la política si tenemos una caída del servicio App HA nos dará un aviso en el “status” y tomará cartas en el asunto para poder levantarlo, también podemos notar que se envía una alarma de vCenter Server:

iis7abajoAppHaComo podemos ver la configuración, creación de políticas y el como trabaja App HA es bastante amigable, en mi caso no me tarde mas de 15 minutos en dejar lista la configuración de vCenter y Hyperic (de hecho me tarde mas tiempo en descargar los appliances de App HA y Hyperic). En esta versión tenemos la capacidad de proteger servicios con un mecanismo sencillo, claramente como lo dice su nombre se trata de “alta disponibilidad” a diferencia de una tolerancia a fallos que nos podría dar un servicio de cluster a nivel de la aplicación, pero para muchos casos de uso esta alta disponibilidad funciona cubre las necesidades o los SLAs definidos.

¿Que necesito para poder tener App HA?

Como han visto a lo largo del articulo necesitamos de algunos componentes “extra” de lo que viene siendo vSphere (ESXi y vCenter) que son:

  • Hyperic
  • App HA (appliance virtual)

En el caso de Hyperic podemos optar por el appliance virtual que ya incluye el servidor y la base de datos como parte de un vApp, para poder cubrir el máximo de agentes que están soportados por App HA que son 400,necesitaríamos una configuración “medium” para el servidor de Hyperic (4vCPUs y 8GB de RAM) mientras que para la base de datos necesitaríamos una configuración “medium” (4vCPUs y 6GB RAM), como podemos ver para Hyperic estaríamos hablando de una cantidad de recursos de alrededor de 14GB en RAM y 8vCPUs, esto sin considerar que tengamos mas de 500 agentes a monitorear lo cual no podría ser cubierto por un “conjunto” de vCenter + Hyperic + App HA (la relación es 1:1:1).

En el caso del appliance de App HA los requerimientos son bastante bajos, 2 vCPUs, 4GB RAM, 20GB en disco y 1Gbps en red. Con respecto a la plataforma que estará monitoreando vSphere App HA trabaja con Hyperic 5.7+, ESXi 5.5 y vCenter 5.5.

Una duda que he encontrado (que yo mismo tuve en su momento) fue el hecho de el licenciamiento de Hyperic, si consideramos que estaremos monitoreando varias instancias de sistema operativo podríamos pensar que necesitaríamos una licencia para cada uno de estos en lo que a Hyperic se refiere, pero esto no es correcto, con el simple hecho de importar el appliance virtual de Hyperic y contar con vSphere Ent+ tenemos todo cubierto, si… sin necesidad de licenciamiento de Hyperic.

 

 

 

Openstack… ¿Que es?, ¿Que NO es?

Openstack

NOTA: Aquí comparto con ustedes lo que yo he aprendido a lo largo del tiempo, no es la verdad absoluta ni pretendo ser experto en el tema (al menos en el momento que escribo este articulo) por lo que si en este articulo notan errores o áreas que puedan ser mejoradas, modificadas, etc. Por favor ¡Comenten!  Recuerden que estamos acá para compartir conocimiento y ser lo mas acertados posible.

Que tal gente, el día de hoy les voy a hablar sobre algo que esta en todos,TODOS lados… que al igual que el cloud computing o “computo de nube” ha sido repetido una y otra vez hasta que nos (Hemos ¿cansado?) familiarizado con el. En esta ocasión estaré hablando sobre Openstack, daremos un vistazo a que es Openstack, que necesidades o casos de uso cubre y donde exactamente estaría situado en nuestro datacenter o en el stack de software y de igual manera estaré hablando de que NO es openstack.

En VMworld asistí a varias sesiones de Openstack debido a que mi interés ha crecido bastante por lo que me dí a la tarea de dejar de ser alguien que lee sobre el tema y pasar a ser alguien que conozca openstack y pueda contribuir a la comunidad de habla hispana sobre este tema.

¿Que es Openstack?

Openstack es un conjunto de proyectos “open-source” o de codigo abierto, en sus inicios quienes contribuyeron con mas código fué rackspace y la NASA. Este conjunto de proyectos y grupo de empresas/desarrolladores tienen como objetivo el construir una plataforma de nube, como tal Openstack podría considerarse como un CMP o “Cloud Management Platform” que permite orquestrar y gestionar distintos aspectos de una infraestructura para dar servicios de nube. Si quisieramos hacer una analogía contra el stack de VMware, Openstack estaría al mismo nivel de vCAC (aunque podría compararse en ciertos puntos con vCD).

Lo interesante de OpenStack es su capacidad de extensibilidad a través de APIs que son “faciles” de consumir (muy al estilo de AWS), públicos y son “vendor free”, por lo que muchos service providers han volteado a ver a OpenStack como un posible elemento clave para su infraestructura. Esta pensado de manera modular de tal manera que en base a los requerimientos de “nube” que se necesiten entregar podemos ir integrando distintos proyectos a nuestra arquitectura.

Existen varios proyectos que conforman a Openstack, vamos a revisar los mas relevantes (para quienes venimos de un mundo VMware):

archopenstackImagen compartida por Scott Lowe @scott_lowe

  • OpenStack Compute (Nova)  – Este componente y/o proyecto de OpenStack se encarga de el ciclo de vida de las “instancias” que si lo comparamos con vSphere serían “VMs”, se comunica con los distintos hipervisores a través de APIs específicos a cada uno (KVM, ESXi, QEMU, Xen, y demás) para instanciar o crear estas VMs decidiendo donde deberán ser ejecutas las mismas y brindando los distintos servicios que estas requieren. Al igual que todos los componentes de OpenStack tiene APIs para su integración y consumo del servicio. En el caso especifico de VMware OpenStack ofrece dos “drivers” vmwareapi.VMwareESXDriver y vmwareapi.VMwareVCDriver para integrarse y poder hablar con vSphere, el primer driver nos permite consumir recursos de ESXi directamente mientras que el segundo permite consumir recursos desde un vCenter (construcciones lógicas como un cluster de DRS).

novahypshow(Cluster de vCenter registrado en Nova)

  • Glance – este servicio nos permite almacenar “imágenes” para nuestras “instancias” o VMs, estas imágenes pueden ser almacenadas en formatos como ISO, OVF, etc.. Puede trabajar en conjunto con Swift para poder contar con almacenamiento sea local,  S3 de Amazon, etc.

horizonimages(imagenes disponibles vistas desde horizon)

glance(Detalles de la imagen a través de glance)

  • Swift – almacenamiento de “objetos”, nos permite almacenar archivos considerados como objetos, pero estos al final del día no serán montados como directorios o utilizados como puntos de montaje, tiene una estructura de contenedores donde serán almacenados los distintos objetos.
  • Cinder – Cinder nos permite presentar almacenamiento de bloque directamente a las instancias, este proyecto surgió como la evolución de novavolume (que forma parte de nova) que permite montar almacenamiento de bloque a través iSCSI directamente a las instancias para que a través de LVM estas puedan utilizar dicho espacio como persistente. De igual manera nos permite presentar NFS a las instancias.

cindertest1GB(Prueba de volumen 1GB)

  • Neutron (antes Quantum) – este proyecto nos permite entregar networking a nuestras instancias, trabaja de la mano de distintos fabricantes para entregar el acceso, por ejemplo VMware a través de NSX, Cisco, etc…
  • Horizon – este proyecto nos ofrece gestión de OpenStack desde una interfaz web, aquí podemos crear instancias, modificarlas, gestionar swift, conectarnos a una consola de VM, etc, etc…

horizonopenstack

  • Keystone – servicio de identidad, maneja el autenticación, acceso y permisos a distintos componentes como nova, swift, cinder, y demás. Tiene su propio API (RESTful) para el consumo e integración con 3eros. Nos permite gestionar usuarios, grupos y roles. Trabaja a través de “tokens” para brindar acceso a los demás servicios una vez que se ha autenticado a un usuario.

rolestenantskeystone

Como podemos ver distintos proyectos conforman el “framework” de OpenStack, en este articulo no tocamos todos los proyectos que están allá afuera, pero estaré escribiendo artículos de mayor profundidad en los proyectos y tratar de hablar sobre los que aquí no fueron descritos.

¿Que NO es Openstack?

OpenStack no es:

  • Un producto – como lo hemos visto a lo largo del articulo se trata de un conjunto de servicios, que constituyen una nube. Es open source, por lo que el código esta allá afuera y lo podemos modificar para nuestras necesidades e incluso contribuir de vuelta a la comunidad. Este conjunto de código es mantenido y controlado por la fundación OpenStack.
  • Virtualización (hipervisor) – pudimos ver que Nova compute habla con hipervisores para poder crear instancias y demás, pero quien virtualiza es el hipervisor en cuestión… ej. ESXi, XenServer, KVM, etc… No nos confundamos, cuando estamos creando un ambiente de nube no necesitamos decidir si vamos a irnos por VMware o por OpenStack (al menos en esa capa de virtualización) ya que OpenStack esta en una capa muy arriba de la nube, podría competir con vCD y vCAC hablando específicamente de VMware y con otras CMPs de 3eros que están allá afuera.
  • 100% Gratis – Recordemos que aunque el código sea abierto y que nosotros podemos construir nuestra infraestructura a partir de OpenStack no quiere decir que los costos para mantenerlo, entrenamiento, troubleshooting, gestión y mantenimiento de capas que estén por debajo (ej. vSphere, networking, storage, etc.) sean gratuitas. Los Distros mas grandes de Linux están comenzando a ofertar su “sabor” o flavor de OpenStack, tenemos a Red Hat, a Canonical, etc. en este caso claramente se tendrá un costo no por el código si no por el soporte y demás.
  • Solo para Service Providers – OpenStack puede ser utilizado por cualquier tipo de empresa, no solo SPs, claramente la modularidad y facilidad de consumo a través de APIs es lo que hace tan interesante OpenStack para los SPs.

Algunos casos de Uso

OpenStack ofrece la capacidad de IaaS muy al estilo de AWS, donde las cargas,instancias o VMs, como nosotros nos guste llamarlas no son del todo tratadas a un nivel tan especifico como lo podemos hacer a nivel de vSphere+vCD, vSphere+vCD+vCAC, esto debido a que no existen mecanismos para el control de los SLAs (alta disponibilidad, control de “noisy neighbors (NetIOC,SIOC, etc)”, donde tal vez el brindar alta disponibilidad lo realizamos a través de la aplicacion/gOS, donde básicamente tenemos que diseñar para el fallo. Ambientes enterprise donde manejemos aplicaciones tier1 que tienen que cumplir al 100% con sus SLAs, tener manera de asegurar el rendimiento y demás (básicamente consentirlas mas :D) en este punto se verían mas beneficiadas de ambientes basados en vSphere.

Les recomiendo TOTALMENTE leer dos artículos de Massimo Re Ferre @mreferre sobre este tema donde podrán entender el principio de como se tratan a las cargas en distintos tipos de nube y cuales son indicadas para que tipo de aplicación y/o servicio:

http://it20.info/2012/12/vcloud-openstack-pets-and-cattle/

http://it20.info/2011/04/tcp-clouds-udp-clouds-design-for-fail-and-aws/

Entonces, regresando al tema de VMware vs OpenStack, mas bien les diría que piensen en OpenStack sobre “(aquí va el hipervisor/CMP)”…

Actualizando almacenamiento en homelab – LenovoEMC PX6-300D

Que tal gente, el día de hoy les quiero compartir los resultados a nivel de almacenamiento que tuve al actualizar mi infraestructura de networking y almacenamiento. Para mi laboratorio tengo un rendimiento bastante satisfactorio, se agregaron 2 nuevos componentes, Switch de capa 3 Cisco SG200-26 y nuevos discos para mi antiguo y siempre confiable PX6-300D.

En el switch se activó jumbo frames (MTU 9000) para la comunicación de iSCSI por lo que el payload de cada paquete es mucho mayor, pudiendo asi optimizar la transmisión de información.

LenovoEMC LifeLine 4.0

Con la actualización de mi almacenamiento a la última versión de su sistema operativo (LifeLine) se agregaron capacidades bastante interesantes, en este caso estaremos enfocándonos al cache de SSD, es importante notar que no se trata de soporte o capacidad de conectar discos duros de SSD al almacenamiento y utilizarlos como espacio para presentarlo a los clientes.

Screen Shot 2013-08-20 at 12.35.20 PM

SSD caching básicamente nos permite crear pooles de discos de estado solido para acelerar las escrituras y lecturas a los volúmenes que estamos presentando, en este caso estaría realizando cache de toda la información que es accedida de manera intensa en los discos de estado solido para que sean servidos desde esta capa con un acceso mucho mas rápido que el de los discos duros tradicionales.Screen Shot 2013-08-20 at 1.05.09 PM Como podemos ver en la imagen tengo creado un pool de SSD caching con 100GB (disco de 120GB) de espacio, este es utilizado para almacenar todos aquellos archivos/info que son accedidos con mayor frecuencia. Como pueden ver tengo un Arreglo con nivel de RAID5 constituido por 5 discos SATA 3 con cache de 64MB, el problema esta en que este arreglo solo soporta operación a SATA2, debido al RAID5 me quedo con una cantidad de 7.2 TB utilizables.

Números, impacto de SSD caching

En el momento que me enteré que la nueva versión de LifeLine ofrecía SSD caching quize comparar el rendimiento que estaba presentando mi almacenamiento y el que presentaría con los nuevos discos, un RAID5 y SSD caching.

  • Layout de almacenamiento previa a la actualización:
  • 6 Discos SATA2 (16MB de cache) 250GB c/u, RAID0.
  • Layout de almacenamiento post actualización:
  • 5 Discos SATA3 (64MB de cache) 2TB c/u,RAID5, SSD Kingston Hyperx SATA3 120GB (SSD cache)

 

Para poder determinar el rendimiento que presentaba mi almacenamiento y el que presentaría después de actualizarlo decidí utilizar el fling de VMware llamado I/O Analyzer, aplicando dos distintos perfiles de iometer (claramente no son perfiles de cargas reales de trabajo) Max_IOPS y Max_Write_Throughput. Recordemos que previamente tenia RAID0 por lo que no se tenia ninguna penalidad de RAID y después de la actualización se tiene un RAID5 con penalidad de 4 IOPs por cada escritura.

  • Rendimiento Previo, 17044 IOPS máximo y una velocidad de escritura máxima de 111MBPS:

Screen Shot 2013-08-20 at 1.39.18 PMMax IOPS

Screen Shot 2013-08-20 at 1.39.04 PMMax write throughput

  • Rendimiento Actual 19573 IOPS máximo y una velocidad de escritura máxima de 112 MBPS:

Screen Shot 2013-08-20 at 1.42.31 PMScreen Shot 2013-08-20 at 1.47.33 PM

Como podemos notar aún considerando la penalidad del RAID5 (para mas información de RAID hacer click aquí) y teniendo un disco duro menos al agregar el pool de SSD para cache pude mejorar el rendimiento de mi almacenamiento “modesto” para mi laboratorio casero, creo que casí 20k de IOPS es algo bastante bueno para correr mis VMs y demos.

Lo que sigue es poder agregar un segundo puerto para mi comunicación de iSCSI y determinar que mejora en rendimiento podría representar agregar un LACP entre mi PX6300D y mis ESXi.

 

Tip para agregar SCVMM 2012 en vCAC 5.2

Que tal gente, el día de hoy me encuentro configurando mi ambiente demo en el laboratorio donde estoy incluyendo como endpoints para mi instancia de vCAC (vCloud Automation Center), SCVMM 2012 gestionando Hyper-v 2008R2, KVM (CentOS 6.4) y claramente vSphere 5.1, vCD será incluido en un futuro en conjunto con XenServer.

Deje lista la instalación de SCVMM 2012 SP1, cree un cluster y me disponía a crear un endpoint en mi instancia de vCAC 5.2, esto para poder comenzar a jugar con los recursos que me proporcionaría Hyper-v, y lo primero que me vino a la cabeza fue el instalar el agente para Hyper-v para después agregar un endpoint que reflejara los recursos que se estarían descubriendo a través de este agente (En este caso ya no se requiere del agente de Hyper-v, esto se realiza nativamente). Agregué las credenciales con las cuales me estaría conectando a dicho endpoint y me dispuse a crear el endpoint virtual de tipo SCVMM:

Endpoint creado

Como pueden ver el endpoint fue agregado sin ninguna novedad y lo único que faltaba era realizar una sincronización de sus recursos para después crear un grupo enterprise.

Así que esta vez hice click derecho sobre dicho endpoint de SCVMM, y ejecute el workflow de “Data Collection”:

Screen Shot 2013-07-11 at 6.43.28 PM

Esto debe de ejecutar un conjunto de tareas (en este caso powershell) que obtienen los recursos disponibles de dicha instancia de SCVMM, para esto podemos ver el resultado de dicho workflow haciendo click en “Workflow History”

Screen Shot 2013-07-11 at 6.46.42 PM

Y bueno analizando lo que se me presentaba, podía ver que la última tarea que estaba siendo ejecutada por el DEM (worker) era un workflow llamado “ScvmmEndpointDataCollection” y que este no era reconocido como un cmdlet (esto por powershell) y claramente la tarea aparecía como fallida.

Revisando algunos de los requerimientos en la guía de instalación de vCloud Automation Center 5.2 (específicamente en la página 61 “SCVMM Requirements”) pude notar que NO cumplia con los requerimientos para registrar una instancia de SCVMM:

The DEM must have access to the SCVMM PowerShell module installed with the console

Por lo que lo primero que revisando en nuestra primera y única herramienta de referencias exactas (Google) pude encontrar el blog de Mike Laverick, donde especificaba esto, confirmando así que lo que debía realizar era la instalación de el VMM console que forma parte de SCVMM, conecté el .iso de SCVMM a mi instancia de vCAC:

cd

y comencé con la instalación (importante notar que requieren PowerShell v3.0 para poder instalarlo):

vmmconsole

Screen Shot 2013-07-11 at 7.03.56 PM

Una vez instalado podemos notar que se agregan los módulos para la gestión de VMs, ahora es necesario cambiar la política de ejecución de PowerShell a “RemoteSigned” o “Unrestricted” Por lo que ejecuté Powershell e ingresé el comando:

set-executionpolicy -executionpolicy unrestricted

Screen Shot 2013-07-11 at 7.06.21 PM

Una vez realizado esto, decidí ejecutar de nuevo la recolección de datos de el endpoint (SCVMM), teniendo resultados satisfactorios:

Screen Shot 2013-07-11 at 7.09.49 PM

Con esto ya era cuestión de crear un grupo enterprise para poder seleccionar los nuevos recursos que habían sido descubiertos y poder verificar que efectivamente se estaba recolectando la información de dicho endpoint:

Screen Shot 2013-07-11 at 7.13.02 PM

Y pues bueno yendo al endpoint y seleccionando “View Compute Resources” ya podía ver que todo estaba listo para continuar:

Screen Shot 2013-07-11 at 7.14.58 PM

Conociendo vCenter Log insight

Que tal gente, el día de hoy les voy a hablar sobre un producto que VMware liberó en un estado beta y que en este punto se encuentra de manera gratuita y abierta para su prueba, vCenter Log Insight. Este producto llega a cubrir un área de oportunidad en VMware que es la de tener análisis a nivel de logs, sabemos que contábamos en los días de vSphere 4 con el recolector de logs de la vMA (vilogger) o que en este tiempo podemos utilzar el syslog collector de vCenter Server… ¿Pero en realidad lo que queremos es solo “recolectar los logs”? ¿o queremos contar con un análisis avanzado de los mismos?. Si nos tomamos algo de tiempo para revisar la industria podemos notar que existen soluciones como Splunk que precisamente nos permite el análisis y recolección de logs a nivel de nuestra infraestructura es aquí donde queremos tener un producto 100% integrado con VMware para poder tener un análisis continuo, preciso y que sin importar la versión de nuestros productos funcione. Es por eso que VMware adquirió a través de Pattern Insight la tecnología para sentar las bases para este nuevo producto, que en este momento conocemos como vCenter Log Insight.

¿Que nos ofrece vCenter Log Insight?

Análisis de información provista por los distintos sistemas que estén enviando sus logs, este producto no se limita a VMware, estaremos revisando un concepto llamado “content packs” donde proveedores podrían ofrecer queries específicos para el análisis de sus productos. Podríamos estar hablando de las siguientes capacidades a grandes rasgos:

  • Análisis de información en tiempo real – se cuenta con la capacidad de realizar queries a la información que esta siendo almacenada en el momento en la base de datos de log insight
  • Definición de esquema en el momento – creación de queries personalizados con filtros y elementos específicos.

Screen Shot 2013-07-03 at 12.13.11 PM

  • Ejecución de queries en información no estructurada – la información que esta siendo almacenada no tiene un esquema definido notros definimos bajo que criterios será analizada.
  • Pensado para el análisis de un volumen de información muy grande (big data)

¿Como se instala y configura?

Algo bastante interesante de vCenter log insight es el hecho de su simplicidad, la instalación y configuración inicial es a través de un OVA:

Screen Shot 2013-07-03 at 12.41.26 PM

En este OVA seleccionamos el almacenamiento y variables de OVF como IP, DNS, subnet mask, etc. Una vez importada tenemos una VM funcional dentro de nuestra infraestructura

importada

Cuando nuestro appliance este listo solo necesitamos apuntar desde un navegador a la ip de este, para poder terminar la configuración:

Welcome

Aquí configuraremos credenciales de administrador,licencia, notificaciones NTP (¡100% BASICO! por timestamps):

NTP

Por último tenemos otras dos configuraciones muy importantes, la integración con VMware (vC y vC Ops) y data archiving:

integracion

Bastante interesante la funcionalidad de “launch in context”

que nos permite desde vC Ops (vC Ops 5.7.1+) analizar un objeto y poder realizar un query directamente a Log Insight

Screen Shot 2013-07-02 at 11.18.45 AM

Data archiving nos permite retener información por mas tiempo, debido a que la información “viva” o en la cual podemos

realizar un análisis estará siendo almacenada dentro de la base de datos, la información mas “vieja” estará siendo exportada

hacia este repositorio de NFS donde será comprimida y podremos importarla en el caso que se requiera un análisis de la misma

Una vez terminada la configuración es necesario un reinicio y con eso tendremos nuestro sistema arriba y funcionando:

listo

en este caso solo registré vCenter Server por lo que nos falta algunos pasos para poder terminar la configuración, al menos en mi laboratorio requiero monitorear los servidores ESXi.

Lo primero es cambiar el password del usuario root, para esto abrimos una consola y accedemos a la línea de comando:

login

Donde ingresaremos las credenciales “root” y de password solo un enter (password vacio), con esto podremos cambiar el password de root. Una vez listo vamos a utilizar una herramienta llamada “configure-esxi” que nos permite configurar el servidor de syslog de manera masiva para todos los servidores ESXi que esten siendo gestionados por una instancia de vCenter server, claramente esta no es la única opción, podemos realizarlo a través del vSphere client, vSphere Web client, Powershell, esxcli etc etc… pero este es el método mas sencillo desde mi punto de vista. Necesitamos ingresar los siguientes comandos:

cd opt/vmware/bin   –> cambiamos el working directory a donde se encuentra la herramienta

./configure-esxi -u (ususario) -s (vcenter) -t (server de syslog)

comando

Algo extraño, tal vez un bug sucede en el momento que configuramos syslog para nuestros servidores ESXi… si nosotros queremos confirmar que el servidor de syslog fue correctamente configurado desde el vSphere Web client o el vSphere client no veremos ningún servidor, pero podemos verificar que efectivamente esto esta listo a través de la herramienta de configure-esxi con el switch “-q”

query

Una vez listos nuestros servidores ESXi podemos analizar la información que es enviada a nuestro sistema de Log Insight:

hosts-dashboard

Integración con vCenter Operations

Como les comenté podemos integrar vCenter Log Insight con vC Ops para poder crear alarmas a partir de datos no estructurados, es decir, podemos realizar un query a la información que esta almacenada en la BD de vCenter Log Insight y a partir de ella crear una alarma que sea enviada a su vez a vC Ops cada vez que se encuentren los criterios y el esquema definido en la información que va siendo recibida, vamos a revisar un ejemplo para la creación de una alarma a partir de latencia a nivel de storage:

Screen Shot 2013-07-03 at 1.52.26 PMEn la imagen podemos ver un filtro de información para poder obtener latencia a nivel de SCSI

Screen Shot 2013-07-03 at 1.55.41 PMAquí podemos ver la creación del esquema a partir de la información que se nos esta mostrando

Screen Shot 2013-07-03 at 2.02.12 PMEn esta imagen podemos ver la creación de una tabla a partir de un máximo y un grupo de dispositivos, esto después lo estaremos convirtiendo a una “alarma” o notificación a nivel de vC Ops

Screen Shot 2013-07-03 at 2.05.26 PMEstas alarmas se verán reflejadas directamente en vC ops

Screen Shot 2013-07-03 at 2.07.24 PM

¿Que son los Dashboards?

Algo bastante interesante es la capacidad que tenemos de compartir ciertos grupos de gráficas e información especifica, en el caso de vCenter Log Insight tenemos algunos dashboards incluidos que son provistos por el content pack de vSphere (explicaremos mas adelante que es un content pack) como lo podemos ver en la imagen:

Screen Shot 2013-07-03 at 5.39.49 PM

El concepto de dashboard nos da la capacidad de poder crear conjuntos de gráficas a partir de queries con información relevante para nosotros o para el grupo de admins de vSphere, lo interesante es que podemos compartir estos dashboards para que sean de uso público o podemos tener dashboards privados:

Screen Shot 2013-07-03 at 5.45.13 PM

Es interesante saber que esto permite a terceros el integrar análisis de sus propios productos con información especifica obtenida a partir de  querys realizados a los logs que son enviados a vCenter Log Insight. Crear un dashboard es bastante sencillo, aquí podemos ver el ejemplo para agregar un dashboard o crecer uno existente:

Screen Shot 2013-07-03 at 6.05.14 PMNos vamos a “interactive analysis” y ahí creamos un query para obtener la info que necesitamos, en este caso pueden ver que agregue dos elementos, el nombre de un host y que contuviera “error” para todo el tiempo que se ha monitoreado. Hacemos click en la esquina superior izquierda “add to dashboard”:

Screen Shot 2013-07-03 at 6.12.33 PMAquí podemos agregar el análisis de información y la gráfica a un dashboard existente o podemos crear un nuevo dashboard, que incluso podemos compartir con mas usuarios con acceso a vCenter Log Insight:

Screen Shot 2013-07-03 at 6.14.56 PMUna vez creado podemos encontrarlo en el menú de “dashboards” en la pantalla principal.

¿Que son los content packs?

Screen Shot 2013-07-03 at 8.49.45 PMLos content packs son un conjunto de queries que se entregan con el fin de analizar la información recolectada, en el caso de la versión beta de vCenter Log Insight contamos con el content pack de vSphere claramente provisto por VMware para poder analizar ciertos componentes clave. Los content packs pueden incluir:

  • Queries
  • Alertas
  • Dashboards
  • Extracciones de información a partir de campos clave

Como usuario podemos crear nuestro propio content pack, básicamente es exportar todo nuestro contenido:

Screen Shot 2013-07-03 at 9.04.03 PM

Dimensionamiento y consideraciones

  • El appliance virtual de vCenter Log Insight tiene como recursos iniciales 2 vCPUs y 8GB en RAM con 144GB en disco duro de los cuales 100GB están pensados para almacenar la información que le es enviada. En la siguiente tabla podemos encontrar algunos lineamientos para el dimensionamiento según la carga que presentará el appliance virtual:

Screen Shot 2013-07-03 at 9.20.36 PM

El calculo del almacenamiento que necesitamos lo podemos obtener de la siguiente manera:

calculamos la cantidad de tiempo que estaremos almacenando la información vs la cantidad de host (ver tabla), por ej. 100 hosts ESXi = 15GB aprox de almacenamiento si la queremos almacenar 7 dias sería:

15*7=105GB (esto es la cantidad de espacio para almacenar los datos de manera “raw”)

después debemos considerar temas como en índice otro tipo de metadata de dicha información por lo que multiplicaremos la cantidad requerida de espacio para almacenar dichos datos en forma “raw” o cruda por 1.6:

105*1.6=168GB

Considerando que el appliance virtual tiene un espacio dedicado de 100GB por default para el almacenamiento de datos al menos deberíamos agregar 68GB extras.

Agregar espacio de disco duro es tan simple como apagar el appliance virtual, agregar un nuevo disco, encenderla y el LVM de linux reconocerá el disco y lo agregará al grupo de LVM.

  • Otra consideración importante es la autenticación en esta versión solo es LOCAL (no se soporta AD, LDAP,etc.)
  • No se cuenta con clusterización en esta versión por lo que la única manera para poder escalar es agregando recursos al appliance virtual o agregando varias appliances virtuales y distribuyendo la colección de los entre estas (de manera manual).

 

 

VDP – Notas y tips

Que tal gente, el día de hoy les voy a hablar sobre un producto que a mi parecer es extremadamente necesario y llega a cubrir las necesidades de respaldo de ciertos segmentos de negocio como lo es SMB. La VDP o VMware Data Protection viene a remplazar a lo que antes conocíamos como VDR o VMware Data Recovery. Se cuentan con dos versiones, VDP o VDPA (vSphere Data Protection Advanced).

El objetivo de este post es enlistar para ustedes todos aquellos puntos y tips a considerar cuando tengamos VDP, vamos a darle un vistazo a lo que es la VDP.

vSphere Data Protection es una solución de respaldo entregada por VMware pensada para ambientes pequeños a medianos, la cual está basada en tecnología de EMC Avamar y nos ofrece lo siguiente:

  • Respaldo y recuperación completa de VMs
  • Restauración a nivel de archivos para usuario final
  • Integración con vSphere Web Client
  • Deduplicación a nivel de los respaldos
  • Uso de CBT (Change Block Tracking) y los APIs de VADP
  • VDP esta disponible con vSphere en las versiones Essentials+, Standard, Enterprise y Enterprise+.
  • Chequeos de integridad periódicos automáticos (con capacidad de poder ejecutarlos de manera manual).

Componentes y arquitectura

La VDP es entregada en un paquete .ova y este appliance tiene requerimientos de 4 vCPUs y 4GB de RAM el sistema operativo de este appliance es SLES 11 64 bits. Para poderla importar y manejar necesitamos un vCenter 5.1 y esta solo podrá ser gestionada desde el cliente web de vSphere (el cliente C# quedó descartado).

Se cuentan con distintos servicios que proveen la funcionalidad de respaldo y gestión de todos los trabajos de respaldo a nivel de la VDP, estos son los componentes principales (no todos):

  • VDP-Server: este componente permite la integración con todo el motor de Avamar se ejecuta sobre un servidor Apache Tomcat
  • Avamar MC: Avamar Management Services, es un conjunto de servicios y APIs para la gestión de Avamar
  • MCS: Management Console Server, provee administración centralizada para la calendarización, monitoreo y gestión de los trabajos. Este envía trabajos a los 8 distintos procesos de proxy disponibles en el appliance encargados de realizar los distintos trabajos de respaldo a través de tres distintos agentes, Avagent,AvVcbImage y AvTar, a través de los cuales determina la cantidad de información que ha cambiado en la VM y toma la decisión de respaldar de manera completa la VM (si el cambio es mayor al 25% de lo que se tiene en el GSAN) o utilizar  CBT en el caso de ser menor. Toda actividad, mensajes y errores son almacenados en el log “/usr/local/avamar/var/mc/server_log/mcserver.log.0”
  • GSAN: Global Storage Area Network es el componente de la VDP hace las funciones de servidor de almacenamiento. Toda actividad, mensajes y errores son almacenados en el log “/data01/cur/gsan.log”

Consideraciones de diseño/dimensionamiento

  • Se soporta hasta 10 appliances de VDP por instancia de vCenter
  • Se tiene un límite de 2TB de respaldo por appliance virtual (espacio deduplicado) o 100 VMs por appliance.
  • Se cuenta con 3 distintas configuraciones de deduplication store (espacio de almancenamiento):
  1. 0.5 TB – Consumiendo 850GB de espacio en disco*
  2. 1 TB – Consumiendo 1600GB de espacio en disco*
  3. 2 TB – Consumiendo 3100GB de espacio en disco*

*(debido a los checkpoints que crea el appliance para consistencia)

  • Se tiene un máximo de 8 operaciones de respaldo concurrentes, esto debido a que se cuenta con 8 distintos proxys manejados por el proceso de MCS (Management Console Server).

Para realizar el dimensionamiento de los appliances necesarios de VDP se recomienda tener la siguiente información:

  • Numero y tipo de VMs (contiene datos de sistema de archivos o de base de datos)
  • Cantidad de información (tamaño)
  • Periodos de retención
  • Cuan rápido cambia o se modifica la información de dichas VMs

Recomendaciones y limitantes

  • Contar con resolución de nombres a través de DNS (esto es ESCENCIAL)
  • En el caso del appliance virtual de VDP debemos dimensionar de manera correcta debido a que no podemos crecerla en un futuro (distinto a lo que sucede con la versión advanced)
  • Se requiere de las VMware tools para poder realizar la restauración a nivel de archivos (FLR)
  • Se puede utilizar contenedores para realizar los respaldos esto quiere decir que básicamente podemos respaldar a nivel de Datacenter, RP, Host,Folder, etc , con lo que se incluirán todas las VMs que estén almacenadas en dichos contenedores, la ventaja claramente es que puede apoyarnos en reducir el tiempo de administración en nuestro ambiente pero esto también conlleva la responsabilidad de monitorear de manera muy puntual la capacidad remanente en los appliances virtuales de VDP.
  • Debemos considerar el realizar restauraciones de los respaldos que se tienen, siempre desmarcando la casilla de “Restore to original location” esto para poder asegurar que nuestros respaldos estan integros y funcionales.
  • Se recomienda colocar los appliances virtuales de VDP cerca de aquellas VMs a respaldar, esto debido a que se utiliza SCSI hot-add para respaldarlas, manteniendo cerca el appliance virtual logramos quitar tráfico de nuestra red (ej. WAN) y que todo sea local.

VDPA – vSphere Data Protection Advanced

Se cuentan con dos maneras para poder adquirir VDPA, puede ser a la carta (como un SKU por CPU) o a través de los acceleration Kits Enterprise y Enterprise+ de vSOM (vSphere with Operations Management). Esta versión incluye lo siguiente:

  • Soporte para respaldar hasta 400 VMs por appliance
  • Se entrega el appliance con 2TB iniciales en el deduplication store, con la capacidad de poder agregar de manera dinámica espacio hasta llegar a los 8TB por appliance. Claramente en el momento de agregar mayor capacidad también necesitamos crecer los appliances en cuanto a memoria RAM se refiere
  • Se cuenta con agentes para respaldar Microsoft Exchange y Microsoft SQL Server a nivel del gOS, esto requiere de la instalación de un agente dentro de la VM que nos permite lograr un nivel de deduplicación mayor del que se logra a través de el respaldo de imagen, restaurar la aplicación o una base de datos en especifico y tener respaldos consistentes a nivel de aplicación (utilizando VSS de Microsoft).
  • Se cuenta con un wizard para poder actualizar de VDP a VDPA manteniendo las tareas de respaldo y la información existente.

En la siguiente tabla podemos ver las capacidades de ambas versiones:

VDP-VDPA