lunes, 17 de febrero de 2025

Unificar varios Collector en un mismo Sizer

 Un caso que nos podemos encontrar es el de una empresa con distintos vCenters, ya puede ser en la misma, o distintas ubicaciones. Las razones pueden ser varias, desde separaciones fisicas por temas de licenciamiento, a necesidades de versión por compatibilidad legacy, o bien por gestion en grandes entornos, donde un solo vCenter no puede soportar todas las VMs, y han decidido dividir la infraestructura en varios entornos, según funciones.

Pero todo evoluciona, y puede ser necesario unificar entornos por distintas razones, desde reducción de huella de carbono, a costes, o simplemente, aprovechar la potencia de nuevas generaciones para pasarse a un entorno hiperconvergente y de gestión más simple. El problema es que cuando ejecutas unas RVtools o, mejor, unas Collector de Nutanix, nos encontramos que apuntan a un vCenter. Uno solo. Dentro, puedes tener uno 10 o 100 clústeres, pero sólo te da los datos de ese único vCenter. 

¿Y si queremos unificar los vCenters? ¿Me veré obligado a introducir a mano todos los datos del entorno en el Sizer? ¡Pues no! Se pueden subir varias fuentes al mismo Sizer, y luego ahí ya te gestionas las VMs como pertenecientes a un clúster único, o te las divides en clústeres a tu gusto, tal y como te indiqué en este otro post.

Partimos de la importación de datos del Collector de un vCenter:

Aquí, cada uno tiene sus preferencias, a mi me gusta hacerlo con las siguientes opciones:


En Powered VMs, lo optimo sería Powered ON only, pero si no conoces las causas del apagado de las VMs, y para no pillarnos los dedos con la capacidad, prefiero seleccionar Powered ON and OFF. Más abajo, en Workloads, si mascas VMs podrás ver las cargas con las que trabaja el Sizer por VMs, hasta un máximo de 1000 VMs. Si no, se unificaran por carga en perfiles de VM (Small, Medium, Large, etc...). Si marcamos "retain to cluster mapping", en caso de haber varios clusters, las delimitará de esa manera. Si no, las meterá todas en un mismo cluster. 

NOTA: Cluster mapping falla mas que una escopeta de feria, si ves que el Sizer da fallos, desmarca esta opción. Te tocará crear los clusters manualmente.

Vale, ya tenemos nuestro Collector cargado, con 74 VMs, como podemos comprobar en la pestaña "Workloads". El trabajo que sigue para cargar otro vCenter es tan sencillo como, en la misma pestaña, a la derecha, y casi a la misma altura que "workloads", tenemos el botón "import". 

Lo pulsamos, y nos llevará a una pantalla familiar. Solo nos queda cargar el nuevo collector que queremos sumar.

Como se puede ver, este nuevo vCenter era mas pequeño, apenas tiene 12 VMs mas. 

Podemos ir a las pestaña "Solution" para ver cómo cambia la solucion configurada, pero me interesa que echéis un vistazo al texto en azul, "View Workload Source & Import history". Pinchamos sobre el enlace, y nos abrirá una ventana flotante que nos indica los archivos con los que está trabajando:

Podemos ver el nombre y fecha de los dos archivos que hemos subido: el archivo con el que creamos el Sizer, y el archivo subido posteriormente. Veréis también un botón de "Upload Source File" que a fecha de hoy, podría estar como podría no estar, ya que no funciona. Si lo pulsas hace el proceso de subir un Collector, pero no lo aplica, de manera que hay que subirlo de la misma manera que he explicado anteriormente.

Si te ha gustado el articulo, puedes invitarme a un café ;)

domingo, 16 de febrero de 2025

Configurar el Sizer para un Stretched cluster

 Un problema que nos podemos encontrar a la hora de tratar con el Nutanix Sizer, ya sea partiendo de unas RVtools o bien de un Collector, viene cuando se te presenta el dimensionamiento de un Stretched Cluster con vSAN. Ninguna de las dos herramientas de recolección de datos te va a separar las zonas, y tampoco vienen identificadas como dos clústeres distintos: precisamente de eso va la solución, ¿no? De esta manera, seremos nosotros los que tendremos que trabajar un poquito sobre el Sizer. ¡Vamos alla!

Partimos de unas RVtools (o Collector), que nos van a mostras algo similar a esto:

Vale, esto es raro, porque no debería ser necesario un Witness para el numero de hosts que tiene en cada extremo del clúster, así que supongo que habrán ampliado 1 nodo en algún momento. Pero ese no es el problema. El problema realmente es el modo en el que la herramienta dimensionará los requisitos de la solución. Lo hará como un único clúster en una única ubicación. ¡Esto cambia mucho la foto de los requerimientos! Tomamos como ejemplo la imagen superior. Partimos de un total de 6 host mas el witness, y lo que sizer nos da como solución es lo siguiente:

En N+1, una preciosa solución basada en 4 host. Sin entrar en cargas de trabajo, a priori, es una reducción importante de hardware. Pero falsa. De hecho, si quisiéramos mantener la solución de 2 zonas unidas por ejemplo con Nutanix Metro Cluster o Sync Replication, no tendríamos los nodos mínimos para conformar un clúster decente en Nutanix (recordemos, 3 mínimo. Que si, se puede con 2 e incluso 1, pero solo como ROBO, no valdría para lo que se plantea). Así que vamos a "forzar" el segundo cluster en el sizer. 

Para ello, pinchamos sobre "workloads":

Justo donde pone "Cluster1", todo a la derecha, veremos el símbolo de un engranaje con el texto "Modify", Si pinchamos ahí, nos saldrá una pantalla con los ajustes del clúster. Si vamos abajo del todo, veremos que todas las VMs se han configurado para funcionar en un solo clúster. Tendremos que configurarlo para que funcione en 2 clusters realmente. Para ello cerramos esta pantalla de configuración, y volvemos a nuestra pantalla de Workloads. A continuación, seleccionaremos las VMs que van al segundo cluster (si, a mano), marcando la casilla de selección de la izquierda. Una vez hayamos seleccionado tantas como consideremos oportuno, pinchamos sobre "add":

Veremos que ahora, si nos desplazamos hacia abajo, en la sección de clúster, tenemos la opción de crear uno nuevo:

Una vez creado el nuevo clúster, tenemos la opción de mover posteriormente más VMs, de manera más fácil, desde el botón "Bulk / Change" y seleccionando "Move Workloads". Cada vez que hagas esto, verás que la parte Solution tarda un poco, pues estará redimensionando la carga de los servidores, y evaluando los modelos que se ajustan a las necesidades. Es por ello que es importante dedicarle un poco de tiempo a seleccionar VMs, ya que si tienes, pongamos 10 VMs, no es lo mismo meter 10 que 50 al nuevo cluster, ni meter VMs ligeras que VMs con cargas pesadas...


Cambia tanto como las imágenes 3 y la siguiente, de este post. En la 3, sobre la que hemos trabajado el ejercicio, podemos ver que la solución pedía 4 host. En cambio, en la foto que veremos a continuación, vemos una solución más simple con 3 nodos en cada una de las ubicaciones:

Es por esto que es importante no solo realizar un export al Sizer, sino también analizar los datos con los que trabajamos, ya que la foto final puede variar muchísimo si no tenemos en cuenta la configuración real del entorno.

Si te ha gustado el articulo, puedes invitarme a un café ;)

lunes, 3 de febrero de 2025

VMUG Madrid retoma su actividad

 ¡Buenas noticias para la comunidad de usuarios de VMware de Madrid! El VMUG Madrid está de regreso y listo para retomar su papel como epicentro de intercambio de conocimientos, experiencias y networking para todos los entusiastas de VMware.

🌟 ¡Estamos de vuelta y más fuertes que nunca! 🌟

Tras un año lleno de cambios emocionantes en el ecosistema de VMware, ha llegado el momento de volver a conectar. VMUG Madrid regresa con energía renovada, nuevos objetivos y muchas ganas de crear un espacio donde podamos:

  • 📊 Aprender de expertos y de las experiencias de otros usuarios.

  • 🙌 Compartir conocimientos, ideas y buenas prácticas.

  • 🚀 Crecer como profesionales y como comunidad.

🍻 vBeers para Celebrar el Relanzamiento 🍻

Y como toda buena reunión empieza con un buen brindis, te invitamos a unas vBeers informales para celebrar esta nueva etapa.

🗓️ Fecha: Jueves 20 de febrero, a partir de las 18:00
📍 Lugar: The Clover Irish Tavern, C/ Valle de Pinares Llanos 8, 28100 Madrid

Será la oportunidad perfecta para:

  • 👥 Reencontrarnos con antiguos miembros.

  • 🌐 Conocer a nuevas caras en la comunidad.

  • 🔊 Ponernos al día sobre las últimas novedades de VMware.

🌟 ¡Queremos Escucharte! 🌟

Este relanzamiento no solo es para ti, sino contigo. Queremos conocer:

  • 🚀 Tus intereses y temas favoritos.

  • 💡 Tus ideas para futuros eventos.

  • 📊 Tus necesidades para seguir creciendo en el mundo VMware.

Tu opinión es fundamental para que VMUG Madrid siga siendo una comunidad única y relevante.

¡No te pierdas esta oportunidad de ser parte activa del futuro de VMUG Madrid!

Vuelve a conectar, aprende algo nuevo, comparte tus experiencias y, sobre todo, ¡disfruta de unas cervezas bien frías con la mejor comunidad tech de Madrid! 

¡Tendremos precio promocional para todas las consumiciones, por cortesía de The Clover!

...y por supuesto, ¡¡¡síguenos en @VMUGMadrid !!!


Enlace de registro, -->AQUI <--