Desplegando una nube privada de VMware en Azure, parte 3: Conectando la infra on-prem con AVS

 Ahora que hemos visto como instalar Microsoft AVS y que hemos accedido al vCenter para ver que todo esta correctamente desplegado, vamos a ver cómo configurar ExpressRoute para permitir la conectividad con los recursos de AVS desde nuestro datacenter on-prem.

Partimos suponiendo que tenemos ExpressRoute ya montado que conecta nuestra infra on-prem con Azure, y que la parte responsable de ese circuito ExpressRoute nos puede facilitar el identificador de recurso y una clave de autenticación.

Empezamos desde Azure, en nuestro recurso AVS. En el menú izquierdo pinchamos en connectivity, y en la ventana principal, en las pestañas que tenemos a nuestra disposición, pinchamos en "ExpressRoute Global Reach":

No hay muchas opciones más allá de hacer click en "Add". Eso nos abre una ventana lateral en la que indicamos nuestra suscripcion y resource group, y donde tenemos que introducir también nuestro "Circuit ID" y nuestra "Authorization key". Una vez los introducimos, pulsamos "create"

Cuando se completa la conexion, vamos a "manage / Identity" donde como ya vimos en el anterior post, podemos ver la IP de conexion a nuestro vCenter, asi como el user y pass. Asi que accedemos a nuestro vCenter, donde podemos ver nuestro cluster sin problemas y sin necesitad de  maquina de salto.

¡No tiene mas complicaciones! Ahora, ¡a trastear con ese cluster AVS!

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

Desplegando una nube privada de VMware en Azure, parte 2: Instalando Microsoft AVS

 Anteriormente, ya vimos como solicitar cuota de hosts en Azure, así como la creación del Resource Group, como preparación previa para el despliegue de Microsoft AVS (Azure VMware Solution). Vamos ahora con AVS.

En nuestro Resource Group, pulsamos sobre "Crear",

Y hacemos una búsqueda para "Azure VMware Solution".

Pulsamos sobre "create", y llegaremos a un breve wizard para el despliegue. La primera pestaña que muestra nos indica los pre-requisitos para el despliegue, consistentes en el Enterprise Agreement para la cuota de host, y una red /22 disponible.

Pulsamos sobre "Next: Basics". Seleccionamos nuestra suscripcion y Resource Group para el despliegue, y en el apartado de detalles de la Private Cloud, indicamos el nombre que le vamos a dar, la region en la que se va a desplegar, y el tamaño del host, donde lo normal es que sea un nodo AV36. Movemos el manejador para seleccionar el numero de hosts. Lo ultimo que pide es facilitar un bloque de direcciones /22 que se utilizara para la gestión del cluster. Hay que tener especial cuidado en que sea un bloque de direcciones unico y que no se solape con otras vnets o redes onprem a las que luego conectemos.

Podemos ir a la pestaña de tags, o directamente "review and create". Veremos un resumen de los "agreements" y de las opciones seleccionadas para la creacion del servicio. Asi que le damos a Create, y esperamos unas horas a que termine de desplegarse.

Ahora conectaremos el AVS Private Cloud a una Azure Virtual Network para que podamos acceder a vCenter y NSX Manager desde un jumpbox que implementaremos en esa red virtual. Crearemos una nueva red virtual de Azure y conectaremos nuestra nube privada AVS a ella con la característica Azure vNet Connect. Asignaremos espacio IP no superpuesto para esta nueva red virtual y crearemos tres subredes dentro de ella.

Así que accedemos al recurso creado, y pulsamos, en el menú izquierdo, en "connectivity"

Abrirá directamente en el panel de "Azure vnet connect". DOnde el menú desplegable de Virtual Network, pulsamos en "create new"

Esto genera una ventana para la configuración de la red virtual. Vamos a utilizar como rango una 192.168.96.0/24, y la vamos a dividir en 3 subnets /27, para gateway, otra para AzureBastion, y otra para management, tal y como puedes ver en la imagen:

Pulsamos OK, y seguidamente, Save:

Con esto, está creada la red que utilizaremos para AVS, dentro de su RG. Si entramos en el RG, veremos algo similar a esto:

A continuación, implementaremos Azure Bastion y una máquina virtual de Windows 10 para usarla como jumpbox administrativo, luego iniciaremos sesión en la máquina virtual de Windows 10 con Bastion para acceder a vCenter.

De nuevo, entramos en nuestro Resource Group, y pulsamos "create", como en la imagen superior. Buscamos "Bastion", y le damos a "create". 

En Project details indicamos la suscripción en la que nos encontramos trabajando, y el Resource Group, el que hemos creado para todo lo que estamos desplegando.

En Instance details, indicamos el nombre que le vamos a dar a Bastión, la región sobre la que se despliega, y el Tier, donde seleccionamos Basic.

En configure Virtual Network, seleccionamos la Vnet que creamos anteriormente, y la subnet que generamos para Bastión (3 imágenes más arriba).

En Public IP Address, seleccionamos "create new", y le damos un nombre reconocible, como se ve en la imagen inferior:

Pulsamos "review & create", donde vamos al resumen de la configuración deseada, y de nuevo, create.

Una vez creado, volvemos de nuevo al RG, y de nuevo, create. Esta vez buscamos "Microsoft Windows 10", seleccionamos un desktop Windows 10 u 11, y le damos a Create.

Seleccionamos la suscription y RG de este despliegue.

En instance details, damos el nombre a la máquina, en availability options no requerimos redundancia, pues será solo una maquina de salto, y en imagen, seleccionamos la más moderna que encontremos. En la captura, la que habia en este momento para Windows 10:

Introducimos username y password para la VM, y en Public inbound ports, seleccionamos "none", y hacemos click en la casilla de "confirm", justo debajo de inbound ports, y vamos a la pestaña Networking:

En Networking seleccionamos la subnet de management, en Public IP seleccionamos "none", en Network Security Group selecionamos "Basic", y en Public inbound ports, None.

Marcamos "review & create", nos sale el resumen habitual de configuración, y de nuevo, create.

Una vez desplegada la VM, nos dará la opción "go to resource". Pulsamos ahí, y nos llevará a la VM recien creada. Pulsamos en Connect, y seleccionamos Bastion, y Use Bastion:

Nos llevará a la pantalla de conexión de Bastión. Introducimos User y pass, lo que introducimos en la creación de la VM, y marcamos el "abrir en nueva ventana":

Por ahora dejamos la conexión en la nueva ventana, y volvemos a Azure. Pinchamos en Home, accedemos a nuestro AVS Private Cloud, vamos a "Identity", y ahí podremos ver nuestra dirección web de acceso:

Introducimos esta dirección en nuestro navegador, aceptamos los mensajes de seguridad, y nos cargará una ventana muy conocida:

Lanzamos el vSphere Client en HTML5. Nos cargará la pantalla de user y pass. Tenemos estos datos en la ventana "identity, que vimos 2 imágenes atrás, justo debajos de la ip de conexión. Copiamos user y pass, y accedemos al entorno. Esto nos mostrará nuestro entorno:

Si pinchamos sobre los hosts podremos ver en summary sus procesadores lógicos y demás detalles.

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

Desplegando una nube privada de VMware en Azure, parte 1: Solicitar cuota de host para Microsoft AVS

Igual que en el post anterior vimos cómo crear un SDDC en AWS, mi intención es explicar cómo hacerlo en Azure. Lamentablemente, en Azure el alta del servicio no es que sea más complicada, es que esta...digamos, menos trabajada que en AWS. Asi que en vez de simplemente generar una VPC para conectar con el SDDC que creamos en AWS, aquí primero hay que generar una suscripción asociada a un Enterprise Agreement, para desde ahí solicitar una cuota de host AVS en la regioon en la que queramos desplegar nueva nube privada.

Los hosts AVS son servidores dedicados y bare-metal, y hay un número finito disponible. La solicitud de cuota de host nos asignará el numero de host que solicitemos. No facturarán por estos hosts hasta que se implementen. Lo que sucede es que puede llevar hasta 5 días en producirse la asignación de los mismos, de manera que hay que planificar bien, y con tiempo, lo que se va a solicitar.

Vamos con los pasos para solicitar esta cuota. Lo primero de todo accedemos a nuestra suscripción de Azure. Seguidamente pinchamos en el menú del portal (las 3 rayitas de la parte superior izquierda), abajo del todo veremos la opcion "Help + support" (ayuda y soporte tecnico). Pinchamos en ella, y en la ventana que aparece, pulsamos en "create a support request.

En la primera pestaña, Basics, En Summary, marcamos "need capacity". En "issue type", marcamos "technical". Esto abre nuevas opciones a marcar. En "suscription" indicamos la suscripción sobre la que requeriremos la cuota de hosts. 

En servicio, marcamos "all services, y selecionamos en los menus desplegables, las siguientes opciones:

- Service type: Azure VMware Solution.

- Resource: General question.

- Problem type: Capacity management Issues.

- Problem subtype: Customer Request for Aditional Host Quota/Capacity.

Pulsamos Next, y vamos a la siguiente pestaña. En "Solutions" no hay mucho que hacer, son enlaces informativos. Pulsamos Next, y continuamos en Details:

Aquí sí tenemos varios elementos sobre los que actuar:

El campo más importante es el de "Descripción", donde indicamos de forma concisa lo que necesitamos. En este caso, y como se puede ver en la siguiente captura, se indica en cada linea, el entorno, la región, y el numero de host, con una descripción tan escueta como "Production", "West US" y "3 Hosts". Hacemos click en "yes" en "share diagnostic information", y marcamos la forma preferida de contacto.

Pulsamos sobre Review + Create, 

...Y terminamos en una pantalla resumen, para poder comprobar los detalles de la petición de soporte, y finalmente pulsar en "create:

Veremos que se inicia la tarea, que podemos comprobar en los mensajes de eventos habituales.

En un plazo de 5 días recibiremos un mail indicando que se ha asignado la cuota de host. Para comprobar que los recursos se han asignado a nuestra suscripción, vamos a Home de nuevo, y en el menú lateral izquierdo, seleccionamos "Resource Providers". En el cuadro de búsqueda de la derecha, buscamos "Microsoft.AVS". Veremos el recurso como registrado, pero si no estuviera registrado, podemos pinchar sobre él y pulsar "register"

Bien, con esto, tenemos el Provider asignado a nuestra suscripción. Ahora debemos crear un Resource Group para nuestra nube privada, y demás objetos asociados.

Crear un RG no tiene mucho misterio, seleccionamos Home / Resource Group /Create, y rellenamos los 3 datos que nos piden, que son la Suscripción, el nombre del resource group, y la región. ¡Lógicamente, la suscripción y región, las mismas donde solicitamos los recursos dedicados!

Pulsamos "review & create", y luego "create".

Con esto, estamos listos para crear nuestra nube privada  Microsoft AVS (Azure VMware Solution).

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

Como crear un SDDC de VMware Cloud on AWS

 Cuando hablamos de poner en marcha un entorno SDDC de VMware Cloud en AWS, lo primero que vamos a necesitar es una conexión con nuestra cuenta de AWS. Esto es prácticamente un pre-requisito para poder proporcionar la conexión de interfaz de red elastica (ENI) a los servicios de AWS.

Para el proceso de implementación, podemos elegir una VPC que nos permita enlazar el SDDC a una subred específica de la VPC. Asi que vamos a ver los pasos para crear una VPC en AWS.

Lo primero de todo, hacemos login en AWS con nuestra cuenta:

Continuamos buscando el servicio VPC que queremos configurar. Lo mejor es ir al buscador y poner "VPC"

Hacemos click en VPC, y seguidamente "Create VPC"

Introducimos el nombre que le vamos a dar, y el rango IPv4 CIDR.

Pulsamos sobre "create VPC".

Hasta ahora, es facilito. Ahora crearemos una subred que nos permitirá conectar al SDDC de VMware Cloud en AWS a traves de la conexion ENI.

Dentro del apartado de VPCs, pulsamos en "subnets", y "create subnet". En el VPC ID, seleccionamos la VPC que generamos anteriormente:

En el apartado "subnet settings", escribimos el nombre de la subnet. En Availability zona, la zona de disponibilidad para la subnet. Aquí hay que tener cuidado, porque hay distintas zonas de disponibilidad, y el SDDC debe estar en la AZ de la subnet. Es importante, el apartado de IPv4 CIDR block, indicar el rango de IP para la subnet. Si la VPC tenia un 10.50.0.0/16, que nos da 65.534 IPs, a esta subnet se le da un 10.50.51.0./24, que nos da 254 IPs para este rango:

Finalmente pulsamos sobre "create subnet". En este caso, creamos una sola subnet, pero es una buena idea crear tantas subnets como zonas de disponibilidad haya en la región donde hayas creado tu VPC (y por tanto, en la que está tu SDDC). En este caso, como se ha creado el ejemplo en us-west, con 4 zonas de disponibilidad, podrían generarse, igual que hemos generado la anterior subnet, pero vamos pulsando sobre el botón de "Add new subnet", remarcado en la imagen superior.

Con las 4 subnets, tendrás esta imagen:

 

Ahora estamos en disposición de crear un SDDC de VMware Cloud en AWS.

Para acceder al servicio, en el navegador, vamos a https://www.vmware.com/cloud-solutions.html y en login, seleccionamos "Cloud services console"

Accedemos con nuestra cuenta, y pinchamos en VMware Cloud on AWS:

Pinchamos, en el listado de la izquierda, en SDDCs, y "create SDDC:

Seleccionamos la región de AWS donde crearla,

En el segundo paso, seleccionamos "Connect to AWS Now". Hay que tener en cuenta que, al implementar un SDDC de nodo único, el enlace de la cuenta de AWS puede retrasarse 14 días. Esta opción solo está disponible para una implementación de SDDC de un solo nodo:

Al pulsar sobre Connect to AWS Account, en el menu desplegable que aparece, seleccionamos "connect to an AWS account". Hacemos click en el boton de OPEN AWS CONSOLE WITH CLOUDFORMATION TEMPLATE. CloudFormation el servicio de AWS que permite aprovisionar de forma automática una serie de recursos de AWS.

Veremos una serie de datos como la url del template y el stack name del SDDC, y haciendo un poco de scroll hacia abajo, veremos la casilla de acknowledge que debemos marcar, y seguidamente, "create stack".

Esto nos llevará a una ventana de eventos, que podemos ir refrescando:

Volvemos a la pestaña del navegador de VMware Cloud, y podremos ver que se ha establecido conexión:

Ya podemos seguir con la configuracion del VPC y la subnet. Pulsamos Next para continuar al tercer paso, y en el menu de "choose VPC", seleccionamos, evidentemente, la que generamos anteriormente, igual que su subnet:

Pulsamos Next, y comenzamos con la configuración de la red. En Management Subnet CIDR Block (Bloque CIDR de subred de administración), indicaremos el rango CIDR de todos los componentes de administración del SDDC: hosts ESXi, vCenter, componentes de NSX y cualquier otro componente de administración implementado en el SDDC. Por lo tanto, es importante que sea un rango de direcciones único, que no se superponga con otras direcciones IP de entornos que puedan estar conectados al SDDC. La subred de administración no se puede cambiar después de la creación del SDDC.

Pulsamos next, hacemos click en las dos casillas donde se nos informa que tan pronto continuemos empezará a cobrarse el servicio en facturacion mensual y en coste por uso (tambien nos faiclitan un link sobre precios y promociones) y pulsamos sobre Deploy SDDC:

El despliegue de los elementos lleva entre hora y media a 2 horas. Una vez desplegado, podremos ver nuestro SDDC en la consola:

Podemos pinchar en "details", donde nos indicará el numero de hosts, recursos, y tipo de máquina desplegada en AWS (normalmente i3 para uso común. Para otro tipo de usos, tenemos las i3en, creo recordar...). Podemos ver un aviso indicando un segmento de red creado por defecto para el SDDC. Podemos cerrar el mensaje...

Justo al lado de la pestaña en la que estamos, en summary, tenemos la pestaña Network & Security, que es donde se llevarán a cabo todas las operaciones de redes y seguridad. Desde aquí podemos crear segmentos de red, en los que colocar cargas de trabajo de VM; administrar y configurar reglas de firewall y conectividad externa en general, todas las opciones de red.

En la siguiente pestaña, Add-Ons, complementos disponibles para el servicio VMware Cloud on AWS. Muy importante, el servicio HCX, está disponible para todos los clientes de VMware Cloud on AWS de forma gratuita y permite a los clientes realizar migraciones de VM a gran escala. 

VMware Site Recovery (VSR) es uno de los productos de recuperación ante desastres como servicio de VMware, que permite a los clientes proteger las cargas de trabajo en VMware Cloud on AWS. NSX Advanced Firewall permite implementar políticas de seguridad de red avanzadas. Estos dos servicios, igual que vRealize Automation Cloud (a ver cuando lo renombran a Aria...) son opciones adicionales de pago.

En la pestaña de mantenimiento veremos si hay actualizaciones programadas en el SDDC. Hay que tener en cuenta que VMware Cloud on AWS realiza las actualizaciones en sus sistemas.

En la pestaña de Troubleshooting, podemos realizar pruebas en la infraestructura en ejecución. La prueba actual habilitada es para el modo híbrido vinculado. Con esta función, se podrá confirmar que la red está configurada correctamente para admitir el modo Hybrid Linked.

En la pestaña settings hay info útil del SDDC, como el FQDN, default vCenter user account, dirección de vSphere, dirección del vCenter, etc...

Si nos fijamos en la anterior captura, veremos que sale un mensaje de notificación en la parte de arriba, de "scale up" Si pulsamos sobre él, nos da la opción de escalar nuestro SDDC:

Aquí podemos modificar el numero de hosts, en este caso marcamos añadir 2 mas y pulsando sobre Add hosts, ya los tendríamos:

Tarda pocos minutos en mostrarse el cambio. Y con esto, ya tenemos nuestro SDDC con sus 3 hosts en funcionamiento.

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