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

VMware elimina la caducidad de sus certificaciones

Todos los poseedores de una certificación de VMware estamos de enhorabuena, ya que a partir del 5 de Febrero de 2019, VMware elimina la necesidad de re certificación cada dos años con el fin de mantener dicha certificación activa.

A partir de ahora, la certificación que tengas se mantiene, y podrás realizar las renovaciones cuando consideres. Con este fin, también se modifican los nombres de las certificaciones (aunque este cambio lo realizaron en un anuncio previo). Me explico: si no tienes certificación, o la tienes y quieres actualizar, los exámenes a los que te presentes tendrán la misma nomenclatura, por ejemplo, VCA, VCP6-DCV... La diferencia es que tu certificado indicará el tipo de examen y el año en que lo realizaste. Esto es, en vez de por ejemplo tener un certificado VCP6-DCV, será un certificado VCP-DCV 2019, incluyendo esta denominación los exámenes de las versiones 6.5 y 6.7, pero no diferenciandolos.

Otro cambio: los certificados no demasiado antiguos, serán activados de nuevo:

Ademas, esta activacion te permite realizar una actualización de tus certificados, siempre que el salto entre versiones no sea superior a 3 versiones. En el siguiente gráfico lo verás más claro:

Resumiendo: los que tuvieron el VCP4-DCV y no lo actualizaron, lo han perdido. Pero hablamos de no menos de 5 años atrás. Por el contrario, todos los demás estamos de enhorabuena, ya que este cambio nos dará mayor flexibilidad para presentarnos a los exámenes.

Ya para rematar, os dejo el video oficial de VMware comentando estos cambios,

Y el enlace a la hoja de FAQ. Si aún así te quedan dudas, puedes escribirles a certification@vmware.com

Cerrar sesiones Terminal Services (RDP) en remoto

Ultimamente me encuentro muchas sesiones desconectadas en servidores, consumiendo un usuario de RDP que te imposibilita para poder iniciar sesión, con el conocido mensaje

Hasta que Microsoft no elimine el botoncito de cerrar la ventana de sesión pulsando la X de la esquina de la ventana, siempre habrá gente que se deje su sesión bloqueando otras conexiones, de manera que vamos a desempolvar un par de comandos de sistema que nos permitirán solventar rápidamente este inconveniente.

Lo primero, es ver qué sesiones hay en ejecución que nos bloquean nuestro acceso. Para ello, utilizamos el comando "query session /server:192.168.1.12" obviamente, sin las comillas, y poniendo la ip de nuestro servidor.

Este comando nos mostrará distintas columnas, pero las que más nos interesa serán el nombre de usuario, su ID de sesión, y su estado (no sea que vayamos a echar a alguien de realmente esté conectado).

Ya conociendo el ID de sesion que queremos cerrar, seguimos con el siguiente comando:
rwinsta sessionid /server:aqui_la_ip_del_servidor. Por ejemplo, rwinsta 1 /server:192.168.1.12 por seguir con el ejemplo anterior.

Arriba puedes ver la secuencia de los dos comandos, y de nuevo el primer comando para que veas la sesión cerrada. Ahora ya podríamos abrir una sesión nueva.

Hay otra manera de acceder via RDP a las bravas, sin hacer este chequeo previo. Consiste en utilizar el comando "mstsc /v:ip_del_server /admin", por ejemplo, mstsc /v:192.168.1.12. Esto fuerza la apertura de la conexión remota, pidiendonos nuestras credenciales de acceso. Para ello, nuestro usuario debe ser administrador de la máquina.

NOTA: si no funciona, asegúrate de ejecutar la ventana de terminal con permisos de administrador

La impresionante placa Odroid-H2 ya a la venta

Como ya comentamos en este artículo, Odroid es una marca de productos de HardKernel con muchas posibilidades para los makers. Te permiten desde montarte tu mini consola estilo Gameboy de juegos retro, pasando por soliciones tipo NAS, o los clásicos media center, usualmente con procesadores ARM de distintas capacidades.

Esta vez, la gente de HardKernel sacan a la venta el Odroid H2, un nuevo dispositivo más potente que los anteriores, pero además de eso, con numerosos cambios, siendo el más notable, el procesador empleado, ya que es el primero que emplean tipo x86. Concretamente, un Intel J4105, un procesador de la gama Celeron.

Las características generales son las siguientes:

• Intel Quad-core processor J4105 (14nm) with 4MiB Cache, up to 2.5Ghz(Single Thread) or 2.3Ghz (Multi Thread).
• Dual-channel Memory DDR4-PC19200 (2400MT/s)
• Total 32GiB RAM Space with two SO-DIMM slots
• 4 x PCIe 2.0 for one M.2 NVMe storage
• 2 x Gbit Ethernet ports
• 2 x SATA 3.0
• Instrucciones SSE4.2 accelerator (SMM, FPU, NX, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES)
• Intel UHD Graphics 600 (Gen9.5 LP GT1) up to 700Mhz
• HDMI 2.0 and DP 1.2 multiple 4K/60Hz video outputs

Como sistema operativo recomiendan Ubuntu 18, aunque con sus capacidades puedes ejecutar Windows sin problemas, si así prefieres.

Como todos los productos de HardKernel, para demostrar las capacidades de la placa indican que puede emular sin dificultad a la Wii, y así se puede ver en este video:

De todas maneras, con semejante potencia, puede más bien reemplazar a cualquier PC para uso ofimático, sin mayores problemas.

Sólo un pequeño detalle...cuidado con las 2 conexiones M2 para almacenamiento NVMe, no valen los M2 SATA, y es fácil confundirlos.

Solo añadir que el envío del producto se inició el 27 de Noviembre, de manera que cabe la posibilidad de agotamiento de stock para estas navidades. El enlace de compra lo puedes encontrar AQUI. Está a 111$, lo que significa que machaca a cualquier Intel NUC y similares del mercado.

...Y según termino el post, observo que ya se quedaron sin stock, a pesar de ponerse hace tan solo 1 dia a la venta. Con esta placa pasará seguramente lo que con las Odroid Go, habrá que estar rápido para su adquisición, puesto que son un caramelo para cacharrear con ellas.