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é ;)

A vueltas con la nube privada: ¿qué es la nube privada?

 Hablando con compañeros sobre el concepto de nube privada observé que ha evolucionado rápidamente, no solo debido a las compañías de virtualización de entornos, sino también debido a los grandes hiperescalares con sus nuevos servicios.

Por poner un ejemplo fácil... antes se podía considerar una nube privada a un Sharepoint: un entorno web, solo accesible desde tu empresa en muchos casos, y que te daba acceso a recursos, archivos, etc...  Este concepto fue evolucionando a todo tipo de recursos informáticos, accesibles desde cualquier parte, pero localizados físicamente en la infraestructura de la empresa, y accesibles a ellos a través de una VPN, habitualmente.

Imagen de kjpargeter en Freepik

Luego llegaron AWS, GCP, Azure, proponiendo a las empresas nuevos conceptos de consumo, como el SaaS, y el IaaS. A partir de ese momento, empresas como VMware o Nutanix, centradas primero en la virtualización, y luego en la hiperconvergencia, empezaron a pivotar hacia la nube. Es lógico, si la gente quiere pagar solo lo que consume, démosles lo que quieren. Empiezan a aparecer los productos clásicos adaptados a la nube, y la nube híbrida (que da para otro post entero). No solo puedes contratar en los grandes hiperescalares servidores dedicados a los que ponerles un ESXi, por ejemplo, es que se llegan a acuerdos que posibilitan servicios como la infraestructura de servicios clásica, pero fácilmente desplegables en la nube, en lo que se define como SDDC (Software Defined Data Center, o centro de datos como servicio).

Llegados a este punto, tenemos claramente definida la nube privada como era en sus orígenes, puramente On-Prem, pero también tenemos esa misma nube privada en la nube. Tanto es asi, que parece que el primer concepto casi desaparezca. Para ello, vamos a ver unas cuantas definiciones, todas coincidentes, sobre qué es nube privada, empezando por VMware:

Una nube privada virtual es una instancia de nube privada que está alojada y ubicada dentro de la infraestructura de un proveedor de nube pública. Se diferencia de los demás tipos de nube privada en que no se encuentra dentro las instalaciones de la propia organización ni en el partner de coubicación.

Una nube privada alojada se ubica en el proveedor de nube y puede residir en las instalaciones o en un centro de datos. Estos recursos no se comparten con otras organizaciones y los gestiona el proveedor de servicios de nube. Todas las actualizaciones y tareas de mantenimiento son responsabilidad del proveedor de nube.

Enlace: https://www.vmware.com/es/topics/glossary/content/private-cloud.html#:~:text=Una%20nube%20privada%20alojada%20se,responsabilidad%20del%20proveedor%20de%20nube

Os facilito también la definición de Nutanix:

Una nube privada es un entorno informático para una organización específica, con ventajas de nube pública pero alojado en el centro de datos de una empresa o mediante un proveedor externo. Las nubes privadas son conocidas por su fiabilidad, escalabilidad y seguridad y, por lo tanto, a menudo son la opción de infraestructura elegida para las cargas de trabajo empresariales.

Enlace: https://www.nutanix.com/es/info/private-cloud

Hasta ahora, las definiciones de dos de los grandes fabricantes de soluciones de virtualización, adaptando su producto al nuevo paradigma. Vamos ahora con las definiciones de los hiperescalares:

Empezamos con la definición de AWS:

Una nube privada es un entorno de computación en la nube dedicado a una única organización. Cualquier infraestructura en la nube consta de recursos de computación subyacentes, como la CPU y el almacenamiento, que se aprovisionan bajo demanda a través de un portal de autoservicio. En una nube privada, todos los recursos se encuentran aislados y bajo el control de una única organización. Por tanto, la nube privada también se conoce como nube interna o corporativa.

Enlace: https://aws.amazon.com/es/what-is/private-cloud/#:~:text=Una%20nube%20privada%20es%20un,de%20un%20portal%20de%20autoservicio

Este texto de AWS está muy bien porque explica el concepto de nube en todas sus formas.

Continúo con Google:

Una nube privada es un modelo de implementación de computación en la nube en el que todos los recursos de la nube están dedicados a un solo cliente o a una organización de usuario. La nube privada, a veces llamada nube privada interna o corporativa, proporciona muchos beneficios de los entornos de computación en la nube, incluidas la escalabilidad, la flexibilidad y la entrega más rápida del servicio.

Enlace: https://cloud.google.com/discover/what-is-a-private-cloud?hl=es-419

Finalizamos con Microsoft:

Una nube privada está compuesta por recursos informáticos en la nube que utiliza exclusivamente una empresa u organización. La nube privada puede ubicarse físicamente en el centro de datos local de tu organización u hospedarse un proveedor de servicios externo. Sin embargo, en una nube privada, los servicios y la infraestructura siempre se mantienen en una red privada, y el hardware y software se dedican únicamente a tu organización.

Enlace: https://azure.microsoft.com/es-es/resources/cloud-computing-dictionary/what-are-private-public-hybrid-clouds/

Esta definición es perfecta.

En resumen: Una nube privada puede alojarse en una nube publica. La diferencia con la nube publica es que los recursos están dedicados íntegramente al cliente. Ademas, según el tipo de nube privada, la gestión de los elementos de software que componen la infraestructura puede estar gestionada por el cliente, o por la empresa facilitadora de los servicios. Lo importante del concepto es que todo se encuentra dentro de una red privada, y el hardware, a diferencia del de los servicios públicos, no es compartido, sino dedicado. El punto clave de la nube privada es que el concepto viene a ser el mismo, pero deslocalizando el hardware: tanto da que la empresa compre "hierro", como que lo "alquile" al hiperescalar de su elección. Esta misma explicación la facilita de manera más resumida el enlace de la definición de Google con las siguientes palabras: 

Antes, las nubes privadas se ejecutaban de forma local, pero ahora es posible ejecutar servicios de nube privada mediante la infraestructura alquilada en los centros de datos de un proveedor de servicios en la nube.

Me quedo con mi explicación, pero esta última condensa la nube privada en apenas 2 lineas.

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

Preparar un disco de Citrix para Azure

Ahora que todas las empresas están moviendo elementos a la nube, evaluando costos y rendimiento, se dará el caso de querer mover VMs antiguas, instaladas, y en sistemas como Citrix, a entornos como Azure.

Tenemos la ventaja que el formato de discos de los XenCenter será un .vhd, igual que el que maneja Azure. Pero aun así si intentamos la subida, obtendremos un error:

The upload size in bytes 17989773824 - 512 bytes for the VHD footer (17989773312 in this case) must be a multiple of MiB.". Esto es debido a que debemos adaptar el tamaño de los bloques de disco a 1 MiB. Para ello, debemos lanzar una serie de comandos de powershell para verificar el tamaño del bloque. Estos comandos son los siguientes:

$vhd = Get-VHD -Path C:\test\MyNewVM.vhd

$vhd.Size % 1MB

Aquí normalmente dará un valor de "0"

$vhd.FileSize - $vhd.Size

Normalmente da un valo entre 512 y algo como 82720062976

También en el caso de que el disco sea un .vhdx, y para arreglarlo, utilizamos el siguiente comando:

Convert-VHD -Path C:\test\MyVM.vhdx -DestinationPath C:\test\MyNewVM.vhd -VHDType Fixed

Tambien puedes utilizarlo siendo un vhd, para pasarlo a vhd, con el sufijo "fixed"

Pero para realizar todo esto, tenemos un problema adicional: no se encontrarán los comandos necesarios en PowerShell:

Para solventarlo, debemos instalar el servicio de Hyper-V en el equipo que lanzará el comando. Vale con los servicios indicados en la captura:

No sirve instalar solamente el modulo de PowerShell, deben instalarse los componentes de Hyper-V indicados, prácticamente todos, menos el hypervisor, que no es necesario. Una vez esté instalado, podremos ejecutar los comandos descritos anteriormente, que ahora si, funcionarán correctamente:

Tras esto, solo queda subir el disco a Azure de la manera que cada uno decida. Tenemos la subida desde consola de PowerShell, la subida desde el navegador, y el uso de Azure Storage Explorer. Pero eso ya es historia para otro post.

Antes de subir el disco, hay que tener en cuenta que debe prepararse también el sistema operativo de forma adecuada, no solo el formato del disco, como hemos visto aquí. Es decir, asegurarse de eliminar las Citrix Tools, deshabilitar firewall, habilitar RDP, eliminar tarjetas de red, hacer un sysprep, etc...

IMPORTANTE: aunque el formato de salida de Citrix es vhd, igual que el que puede utilizar Hyper-V, los discos pueden no funcionar, en base a la BIOS elegida. De manera que aunque el proceso es correcto en base a la documentación y consultas a Microsoft, y el disco sube a Azure, la VM creada con este disco y en base a la eleccion de BIOS, puede no funcionar. 

Para que el proceso funcione, hay que tener en cuenta si en Citrix la VM funciona con BIOS o UEFI. En Caso de ser BIOS, a la hora de montar la VM en azure, deberemos seleccionar una nueva VM Gen1. En cambio, si fuese UEFI, debemos seleccionar Gen2. Adicionalmente y antes de subirla, se puede probar a ejecutar el vhd en Hyper-V, que ya que tenemos instalado el servicio...Si funciona, lo hará igualmente en Azure.

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

Aumentar el espacio de reglas en Exchange Online (o365)

 Cada vez recibimos más mails, y para poder lidiar con ellos, cada vez debemos crear más reglas organizativas. Pero si estás trabajando con o365, aun teniendo una licencia e3, te puedes encontrar con el caso de no poder aplicar más reglas, al llegar al límite de espacio aplicable para las mismas.

Si, resulta que O365 tiene un límite por defecto para las reglas ,de 32 kb. En el caso que me he encontrado, esto permite crear hasta unas 130 reglas de correo. Si aun así te quedas corto, es posible modificar dicho límite. 

Para ello, lo primero, conectamos a o365. Pongo aquí los comandos del tirón, aunque tengo otro artículo indicando el proceso. (todo sin comillas).

"connect-msolservice" y pasamos nuestras credenciales

"Set-ExecutionPolicy RemoteSigned" 

"$UserCredential = Get-Credential" y pasamos credenciales

"$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection" Esto es el comando de conexión.

"Import-PSSession $Session -DisableNameChecking"

Ahora sí entramos con los comandos para la modificación de las cuotas de espacio para las reglas:

Empezamos viendo el tamaño de cuota del que dispone con este comando:

Get-Mailbox -Identity "<MailboxIdentity>" | Format-List RulesQuota

Reemplazar <MailboxIdentity> por la cuenta del usuario, por ejemplo, 

Get-Mailbox -Identity "mimail@midominio.com" | Format-List RulesQuota

El valor que dará será normalmente de 32 KB, pero puedes modificarlo hasta los 256 KB. Vamos con el comando de modificación, una vez que hemos visto el valor disponible:

Set-Mailbox -Identity <MailboxIdentity> -RulesQuota "<32 KB to 256 KB>"

Esto seria ,de nuevo por ejemplo, algo así:

Set-Mailbox -Identity mimail@midominio.com -RulesQuota "256 KB"

Tienes más info en este LINK de Microsoft, donde describen cómo aplicar esta modificación a un listado de cuentas, por ejemplo, en vez de a usuarios individuales, pero he preferido no extenderme más, ya que no se da mucho el caso de usuarios que excedan el límite de reglas.