Guia rápida de VMware Cloud en AWS

Con el fin de ofrecer una forma rápida y sencilla de ayudar a los clientes a empezar a trabajar con VMware Cloud en AWS, VMware ha publicado un póster con el nombre de VMware Cloud en AWS Quick Reference. 

Click para agrandar

Este póster está dividido en cinco secciones, cada una de ellas con títulos hipervinculados, que proporcionan información adicional, con la excepcion de la sección de Reglas del Firewall donde se puede hacer clic en cada uno de los subtítulos en lugar del encabezado principal. El póster es también una buena representación visual de los diferentes tipos de conectividad dentro de VMware Cloud en AWS.

Este es un pequeño resumen de lo que vas a encontrar en cada una de las 5 secciones:

• Descripción general de la infraestructura: Un diagrama de alto nivel que muestra las relaciones entre el centro de datos local, VMware Cloud en AWS SDDC y los servicios nativos de AWS.
• Red Empresarial HCX: Un diagrama detallado que cubre los componentes HCX, conectividad, flujos y puertos utilizados entre el centro de datos local y VMware Cloud en AWS.
• Topología de Direct Connect: Esta sección muestra los componentes y la topología general de la utilización de AWS Direct Connect (DX) para la conectividad entre el centro de datos local y VMware Cloud en AWS.
• NSX-T AWS Connected VPC: Este diagrama presenta una visión general de cómo se produce la comunicación entre VMware Cloud en AWS VPC y el VPC de un cliente si utiliza servicios nativos AWS.
• Reglas del firewall: La sección final incluye una lista de las reglas más comunes del firewall utilizadas entre el centro de datos local y VMware Cloud en AWS para Management Gateway, HCX y Site Recovery.

El enlace a este poster para su descarga en PDF lo puedes encontrar AQUI.

Pero si te gustan este tipo de resúmenes en formato poster, AQUI podras encontrar unos cuantos más (el poster de referencia de VMware PowerCLI es impresionante).

Ya llega el AWS Summit 2019 en Madrid

Como todos los años, ya tenemos encima el AWS Summit 2019 en Madrid. De nuevo será en el Ifema, y la fecha elegida, el 7 de Mayo. Este año será especialmente interesante puesto que del anterior Summit a este se han introducido muchas herramientas para IA y Machine Learning, ademas de mejorar apartados clásicos como por ejemplo EC2 y S3, por mencionar un par.

La agenda de este año es la siguiente:

09:00 - 10:00 Registro y Expo
10:00 - 10:30 Bienvenida e introducción - Miguel Álava, Director AWS
10:30 - 12:30 Keynote - Mai-Lan Tomsen Bukovec, Vice President and General Manager,  Amazon S3, AWS
12:30 - 13:00 Coffee Break
13:00 - 13:45 Sesiones
13:45 - 15:00 Lunch Break y Expo
15:00 - 19:00 Sesiones

El plato fuerte del evento suelen ser las sesiones en diversas salas. Este año, tendremos estas para elegir:

13:00 - 13:45: Cómo escoger el tipo de Base de Datos correcto para tus aplicaciones
15:00 - 15:45: Patrones de diseño para NoSQL

16:00 - 16:45: Bases de datos relacionales escalables con Amazon Aurora  

17:15 - 18:00: Plataformas de Datos Modernas en AWS

18:15 - 19:00: Analítica sin Servidores con Amazon S3, Amazon Athena and Amazon Quicksight

Y aquí tenemos el video de presentación de este año:

Como todos los años, habrá una zona para hablar con los expertos de AWS donde resolverán tus dudas, o bien podras visitar los stands de los más importantes partners de AWS que podrán aconsejarte tanto de sus propios productos, como de lo que se puede hacer con ellos en conjunción con AWS.

Por cierto, el link para registrarse, AQUI. Si estás interesado en los servicios de AWS, este evento es un MUST en tu agenda.

¡Nos vemos en el AWS Summit 2019!

Compartir disco RDM para cluster en VMware

A la hora de configurar un cluster con VMs en VMware una de las prácticas habituales ha sido hacerlo "a la antigua", con tu conector iSCSI, y la publicación de un volumen por este medio a los distintos nodos. Pero hay una forma más fácil de presentar el disco para quorum, y más eficaz: vamos a presentarle directamente un disco RDM.

Partimos de que ya tenemos creado nuestro disco RDM en el datastore que estemos utilizando. Supongamos que queremos presentar el disco a un cluster de sólo 2 nodos.

Lo primero que debemos hacer es agregarle a nuestra VM una nueva controladora SCSI. Editamos la configuracion de la VM, y en la parte inferior de la ventana, expandimos el menú de "nuevo dispositivo" y seleccionamos "controladora SCSI". Pulsamos agregar.

Expandimos el menú de la nueva controladora SCSI:

Debemos cambiar el primer valor, poniendo el uso compartido de bus SCSI en "físico". El tipo de bus se puede dejar como está, pero yo lo suelo cambiar a VMware Paravirtual.  Son prácticamente iguales, pero este último está más optimizado para un número alto de IOPs. Una vez modificado el tipo y el uso de la controladora, aceptamos.

Una vez agregada la controladora, agregaremos el disco RDM. Como antes, editamos la configuracion de la VM, y en el cuadro de nuevo dispositivo, lo expandimos y seleccionamos "Disco RDM"

Seleccionamos el disco que queremos agregar, en este caso un pequeño disco de 10 GB de prueba, y damos a aceptar.

Ok, la parte que viene ahora es importante: expandimos la ventana del nuevo disco, de manera que todavia no salimos de la ventana de configuracion de la VM. La ultima opcion del disco que se muestra es "nodo de dispositivo virtual", y por defecto apunta a la controladora SCSI 0 que viene con la VM por defecto. Bien, pues cambiamos este valor a la controladora SCSI 1 que agregamos anteriormente

Ahora si, pulsamos aceptar, y dejamos configurado el disco RDM en la nueva controladora SCSI 1. Ya hemos terminado con el primer nodo.

Para el segundo nodo, prácticamente repetimos los pasos, con una pequeña variante. Los pasos serian estos:
Agregamos la controladora SCSI, como hicimos con el primer nodo, y modificamos los valores exactamente de la misma manera: uso compartido físico, y tipo VMware Paravirtual. Aceptamos.
Volvemos a editar la configuración del segundo nodo, para agregar un nuevo dispositivo, pero esta vez seleccionamos "disco duro existente". El disco que agregaremos será el VMDK que se habrá presentado al anterior nodo. Si no sabes la ubicación exacta, cancela la ventana, editas la configuración del primer nodo para ver dónde se encuentra el disco RDM, y vuelves a editar el segundo nodo ,para agregar ese disco. IMPORTANTE: editar este nuevo disco duro existente para que también funcione con la controladora SCSI 1 que agregamos anteriormente.

Con esto, ya tenemos presentado el disco RDM a los dos nodos. Por cierto, esto funciona tanto para VMs con SO Linux como Windows

Como calcular la sobresuscripcion de CPU

La principal ventaja que podemos encontrar a la visualización de nuestras máquinas reside en la posibilidad de aprovechar mejor los recursos de nuestro hardware, normalmente infrautilizados con un único servicio por servidor. O lo que es lo mismo, donde antes teníamos un servidor cuya única función podía ser, por ejemplo, un Domain Controller que normalmente nunca en su vida vería su CPU llegando ni al 10% de uso, ahora en esa misma máquina física podemos montar un ESXi que soporte, un número x de máquinas virtuales que nos permita exprimir esos recursos. Esto es posible mendiante la sobresuscripcion de recursos.

Dejando fuera el espacio en disco, que normalmente estará alojado en un datastore, los recursos que vamos a exprimir normalmente son CPU y RAM. En este post, nos centraremos en la CPU.

Primero, vamos a diferenciar entre el procesador físico y el virtual. Por una parte tenemos los pCPU, los procesadores que trae el host que soportará el funcionamiento de las máquinas virtuales. Vamos a tomar como ejemplo, el siguiente caso:

Aquí vemos un servidor con un solo socket instalado. Ese socket contiene 6 cores, o pCPUs, que con hyperthreading activado, funcionan como si hubiera 12 pCPUs. Por eso vemos que indica que tiene 6 cores, pero 12 procesadores lógicos.

Por otra parte tenemos los vCPUs, los procesadores virtuales asociados a este equipo. Supongamos que este servidor aloja 6 VM´s con 4 vCPUs cada una. Esto haría un total de 24 vCPUs corriendo solo tan solo 12 pCPUs. Esto es posible porque las vCPUs son, eso, virtuales. Realmente lo que asignas son una serie de recursos físicos máximos a esa máquina virtual. O dicho de otra manera, un porcentaje máximo de tiempo de procesador del que puede hacer uso del pool de recursos del host físico que la soporta. Y como normalmente las máquinas no hacen un uso intensivo del procesador, esto significa que puedes asignar más recursos virtuales que recursos físicos tiene la máquina.

¿Y cuantos vCPUs puedes asignar por pCPU? 

Pues según las tablas de máximos asignables en vSphere 6.7, nos encontramos con 32 vCPUs por núcleo. En la imagen de arriba vemos que tenemos un vSphere 5 licenciado para un unico socket, con lo que no da para jugar con muchas máquinas, pero si fuera un vSphere 6.7 significa que podríamos tener hasta 12x32 CPUs = 384 vCPUs corriendo en ese host. Menuda salvajada, ¿verdad?

Esto no quiere decir que aunque podamos asignar tantos procesadores a las VMs, debamos hacerlo. Existe un ratio recomendado de sobresuscripcion de procesadores, que varia según distintas fuentes de información. Un ratio clásico seria un 4:1, o sea, 4 vCPUs por pCPU, pero otros recomiendan hasta un ratio 8:1.

Ahora bien, lo suyo es realmente hacer el cálculo de uso en función del consumo de tus VM´s. Como decía, no es lo mismo una VM con una función de File Server que una VM con un Oracle BI, por ejemplo.

Cómo realizar un cálculo de vCPUs

El valor más valioso con el que vamos a contar para realizar el cálculo de las vCPUs que necesitamos en nuestra VM es el valor "CPU Ready" en el host. Este valor nos informa del tiempo que la VM está esperando a que el host asigne recursos de pCPU a nuestros vCPUs

Se recomienda que el CPU Ready esté por debajo del 5%. Para ello, recurriremos a la gráfica del vCenter. Los cálculos se realizan mediante la siguiente fórmula: 

(x ms / 20.000 ms) * 100 = %rdy

Pero es más fácil utilizar una tabla de cálculo rápido, por ejemplo, esta:

1% = 200ms
5% = 1000ms
10% = 2000ms
100% = 20000ms

Estos cálculos son por vCPU, de forma que mirando las máquinas que estamos tomando como ejemplo, con 4 vCPUs, las cifras se cuadruplicarán. O sea, una máquina con un Average de 4.000 ms pero con 4 vCPUs tendra un equivalente a 1.000 ms/vCPU, y por tanto un 5% de tiempo de espera de planificacion de procesador, algo aceptable.

Click en la imagen para agrandar

En este caso, he puesto en la gráfica los siguientes valores:

Esto ayuda a leer la gráfica sin entrar en los cálculos de antes. Si os fijáis en la imagen grande anterior, obtenemos para la VM del ejemplo un tiempo de planificación ligeramente superior al 5%, lo que es aceptable, en los límites. Habría que ver cómo se comporta la VM con una carga de trabajo intensa.

Espero que no haya resultado muy confuso. Al final, una vez pones los valores de Usage Average Percentual en la gráfica, la cosa se simplifica mucho.

A modo de curiosidad, os dejo este LINK a los valores máximos de configuración de vSphere 6.5, para que veais a dónde se puede llegar con esta herramienta