Instala Azure Stack PoC... ¡en Azure!

No, no es 1 de abril ni 28 de diciembre, así que esta publicación no es ninguna broma. Uno de los grandes problemas que tenemos los profesionales de infraestructura a la hora de estudiar Azure Stack es que el hardware necesario para ejecutarlo no es apto para bolsillos individuales o entornos domésticos; por lo que dependemos de tener uno a nuestro alcance para estudiarlo.

¿No sería genial poder instalarlo en Azure para así tener una forma de establecer un laboratorio sin incurrir en grandes costes? Pero un momento... El fin de Azure Stack es traer Azure a tu datacenter... Si instalamos Azure Stack en Azure, estamos trayendo Azure a Azure y establecer una paradoja computacional de proporciones similares a buscar "Google" en Google.

¿Dónde comienza todo esto Doc? En el anuncio de Microsoft del pasado 13 de julio de 2017 sobre la disponibilidad general de las nuevas instancias de tipo Dv3 y Ev3...

A día de escribir estas líneas, Microsoft NO soporta instalar Azure Stack PoC sobre Azure y por tanto este escenario no debería ser utilizado en ningún caso como prueba de concepto o PoC; sino más bien como experimento de entorno de desarrollo sujeto a problemas impredecibles.

Nuevas instancias de máquinas virtuales tipo Dv3 y Ev3

Hace muy poquitos días, concretamente el pasado 13 de julio, Microsoft presentó las nuevas instancias tipo Dv3 y Ev3 de máquinas virtuales. La nueva familia E no es más que un renombrado de las D11-D14, caracterizadas por su gran capacidad en cuanto memoria RAM.

Esta nueva generación vá más allá de la mera actualización de CPU y RAM que hemos tenido hasta la fecha y en ellas encontramos:

• Su CPU es el Intel® Haswell 2.4 GHz E5-2673.
• Tienen habilitado Hyper Threading. Esto quiere decir que un core virtual (vCPU) no ya no mapea necesariamente a un core físico. Este cambio propicia que las cargas de trabajo que están certificadas para ejecutarse sobre Dv2 no lo estén de forma automática para Dv3 o Ev3, como ocurre por ejemplo con la certificación para SAP.
• Como consecuencia del punto anterior, las máquinas virtuales Dv3 y Ev3 cuestan del orden de un 28% menos que las Dv2. ¡Pero cuidado con el dimensionamiento de CPUs!
• Son las primeras familias de máquinas que se ejecutan sobre el hipervisor de Windows Server 2016. ¡Esto significa que tienen la virtualización anidada (Nested Virtualization en la literatura anglosajona) habilitada!

Virtualización anidada

La virtualización anidada es una característica de Hyper-V en Windows Server 2016 que permite ejecutar una máquina virtual dentro de una máquina virtual tal cual Origen, el brillante largometraje de Christopher Nolan.

Como podréis imaginar, tener una máquina virtual dentro de otra máquina virtual no es computacionalmente una situación óptima, pero nos puede dar mucho juego en Azure para escenarios que antes sencillamente no eran posibles, como ejecutar los emuladores de las herramientas de desarrollo de Visual Studio.

Azure Stack está basado en la virtualización de Hyper-V, por lo que ahora que la tenemos disponible en Azure... ¡podríamos utilizarla para instalarlo! No soy el primero en ello, ya que Daniel Neumann -TSP de Microsoft- ya comentaba haberlo conseguido.

Crazy thing. Azure Stack Development Kit up and running on an Azure E16s_v3 VM with nested virtualization. #Azure #AzureStack pic.twitter.com/osUKltdHBW

— Daniel Neumann (@neumanndaniel) 14 de julio de 2017

En su artículo, Daniel explica cómo instalar Azure Stack en Azure como prueba de las capacidades de la Nested Virtualization. Sin embargo, su aproximación es la siguiente:

• Crear máquina virtual en Azure. Llamémosla LEVEL 1.
• Dentro de la máquina virtual LEVEL 1, crea una máquina virtual anidada, llamémosla LEVEL 2.
• En la máquina virtual LEVEL 2 instala Azure Stack, que crea una serie de máquinas virtuales, llamémolas LEVEL 3.

Como veis, tenemos 3 niveles de virtualización anidada... ¡Servidor piensa que podemos hacerlo con sólo dos instalando Azure Stack directamente en la VM de Azure! ¿Os animáis a intentarlo? ¡Vamos allá!

Creando los recursos en Azure

Vamos a crear una nueva máquina virtual en Azure con las siguientes características:

• Imagen de la galería: Windows Server 2016 Datacenter.
• Grupo de recursos: Recomiendo crear uno nuevo específico para nuestro Azure Stack.
• Tipo de disco: SSD.
• Tipo de instancia: E16S_V3, ¿estás sobrado? Sube a E32S_V3.
• Managed disks: NO. Veremos más adelante por qué.
• Boot diagnostics: SÍ, en esta ocasión son muy importantes.

El resto de opciones de configuración las podéis definir de acuerdo a vuestras preferencias. Veréis que una instancia E16S_V3 tiene un módico precio de 1.264,87 EUR/mes en el momento de escribir estas líneas, por lo que recomiendo encarecidamente activar Auto-Shutdown nada más crear la VM. Una E16S_V3 saldrá aproximadamente a 1,75 EUR/hora y una E32S_V3 a 3,5 EUR/hora aprox.

Preparando los discos

Azure por defecto nos provisiona un disco de 127 GB, sin embargo en la documentación de Azure Stack recomiendan al menos 200 GB. Parece lógico que debamos subir del P10 (128 GB) al P20 (512 GB), por lo que vamos a llevar a cabo esta operación, que el momento de escribir estas líneas sólo parece funcionar en unmanaged disks.

Para hacerlo, ejecutamos este sencillo script, tras el cual nuestra VM se reinicia (artículo completo: expandir la unidad del sistema operativo en Azure):

Login-AzureRmAccount
Select-AzureRmSubscription -SubscriptionName 'my-subscription-name'
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
$vm = Get-AzureRmVM -ResourceGroupName $rgName -Name $vmName
Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName
$vm.StorageProfile.OSDisk.DiskSizeGB = 511
Update-AzureRmVM -ResourceGroupName $rgName -VM $vm
Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName

No olvidéis ir al administrador de discos y expandir la unidad del sistema operativo al tamaño máximo.

Por último, agregamos a la VM los discos de datos. El mínimo recomendado es 4 discos de 250 GB, que... por tamaño y coste quizás sea momento de empezar a asumir establecerlos en HDD. Con crearlos en Azure será suficiente, no es necesario inicializarlos en Windows. Esta es una configuración de ejemplo:

Descargando Azure Stack PoC

Descargamos el Azure Stack SDK desde aquí. No hay que preocuparse por el formulario de registro, es gratuito. Obtendrás un pequeño programa que descarga una serie de archivos que desempaquetará el instalador adjunto, tarea que le llevará unos minutos.

Al hacer esto encontraremos un archivo llamado CloudBuilder.vhdx, que es la imagen base desde la que debemos arrancar para inicializar nuestro entrono. ¿Azure arrancando de un VHDX? No exactamente, aquí haremos el pequeño truco de hacer residir ese VHDX dentro de nuestro VHD real de máquina virtual e instruir al gestor de arranque de Windows a que lo haga directamente desde ese archivo. La instalación hará esto por nosotros.

Por ahora nos limitamos a:

move CloudBuilder.vhdx C:\

Descargando el Azure Stack Deployment script

Aquí la situación empieza a diferir con respecto a lo que encontramos -en el momento de escribir estas líneas- en la documentación oficial que en el momento de escribir estas lineas no se encuentra actualizada.

La que sí está perfectamente al día es la que podemos encontrar en el repositorio de GitHub de las herramientas de Azure Stack.

La base de todo es el script asdk-installer.ps1, que descargamos ejecutando el siguiente script de PowerShell en nuestra VM de Azure Stack:

# Variables
$Uri = 'https://raw.githubusercontent.com/Azure/AzureStack-Tools/master/Deployment/asdk-installer.ps1'
$LocalPath = 'c:\AzureStack_Installer'

# Create folder
New-Item $LocalPath -Type directory

# Download file
Invoke-WebRequest $uri -OutFile ($LocalPath + '\' + 'asdk-installer.ps1')

Ahora tenemos la carpeta C:\AzureStack_Installer con todo listo para comenzar.

Instalación de Azure Stack PoC

¡Ya tenemos todo preparado para iniciar la instalación!

Instalación ASDK parte 1: Preparing the environment

Vayamos a preparar la imagen CloudBuilder.vhdx que nos hemos descargado como sistema operativo base de Azure Stack. Algunas notas:

• No vamos a perder acceso al Windows Server 2016 que hemos creado desde la galería. Las dos opciones estarán disponibles en el gestor de arranque... al que no se puede acceder desde Azure. Sin embargo, tendremos mecanismos para dejar una opción u otra predeterminada.
• La documentación oficial indica que un paso de la instalación necesita acceso físico o KVM a la máquina donde lo estamos instalando; principalmente debido a la parte OOBE de la instalación. Afortunadamente esto ya no es necesario con la versión sobre la que vamos a trabajar.

¡Arranquemos! ¡Abrimos una PowerShell en modo administrador y ejecutamos el script C:\AzureStack_Installer\asdk_installer.ps1! No es necesario ninguna parámetro porque...

¡Sorpresa! ¡El script de instalación es totalmente gráfico! Como es código abierto podéis ver cómo lo han hecho, pero advierto es WPF y por tanto XAML a bajo nivel.

La instalación aquí es muy obvia:

1. Prepare Environment
2. Select CloudBuilder.vhdx, que estará en C:\

Lo siguiente es crucial para hacer una instalación con éxito en Azure, que no es ni más ni menos que establecer la configuración que nos preguntará en asistente OOBE. De esta manera nos evitamos la necesidad de tener acceso físico a la máquina. Esta es una configuración de ejemplo:

¡No actives Static IP configuration! Ya sabemos que esto no gusta en Azure. El asistente no tardará en completar la configuración y nos pedirá reiniciar. Si lo hemos hecho todo OK, podemos presionar Reboot now sin miedo.

Vamos a perder acceso a la máquina por un tiempo, ya que te espera un reinicio largo.

Un reinicio largo

¿Qué está pasando para que el reinicio tarde tanto? Gracias a los Boot diagnostics de Azure podemos hacer seguimiento y comprobar que todo esta bien.

Vamos a ver pistas de qué es lo que está ocurriendo.

¡Ahá! 30 segundos de espera a que el gestor de arranque seleccione la opción Azure Stack. No podemos hacer nada más que esperar...

Parece que Windows Server se está configurando para el hardware que ha detectado, por lo que tendremos que esperar un poco más.

Instalación ASDK parte 2: Install

Una vez la máquina ha vuelto a arrancar, podremos iniciar la sesión en ella mediante RDP, pero en esta ocasión con las credenciales que especificamos en la instalación.

Ahora veremos que la unidad C es CloudBuilder.vhdx mientras que la D es nuestro anterior disco del sistema, que a su vez hospeda C.

Para continuar con la instalación no tenemos más que volver a arrancar el script asdk-installer.ps1, que ahora se encuentra en la unidad D. Estamos en la fase 2 de la instalación.

Seleccionamos Install (podéis ver que hay una opción para volver al sistema operativo original por si hiciera falta).

La siguiente pantalla es muy interesante, ya que vamos a establecer el sistema de identidad de Azure Stack. Tenemos dos opciones: Azure AD o ADFS. ADFS es la obligada en caso de que queramos establecer un entorno no dependiente de conexiones a Internet. Si seleccionamos ADFS no se requiere instalación previa, ya que Azure Stack lleva el suyo propio integrado. Iremos con esta última opción en la instalación.

Si quieres optar por Azure AD es muy trivial crear un nuevo tenant gratuito, puedes seguir instrucciones aquí.

Por otro lado, recordad que la contraseña debe coincidir con la del administrador local.

Después deberemos seleccionar una interfaz de red. Contrario a lo que podíamos imaginar, Azure Stack PoC sólo funciona con una única interfaz. Las demás quedarán deshabilitadas, así que aseguraos de seleccionar la correcta.

Después vendrá la configuración de red de la VM que hace de router BGP y NAT, que debemos configurar como static:

• Ip Address: 172.16.0.2/24
• Gateway: 172.16.0.1

Los demás parámetros son opcionales.

¿Quieres la hora oficial de España en tu Azure Stack PoC? Especifica hora.roa.es como tu Time Server.

Cuando todo esté preparado el asistente nos informa de que está listo para iniciar la instalación, ¡pero NO presionamos en DEPLOY! En su lugar copiaremos los cmdlets que nos informa que va a ejecutar y nos lo llevamos a un espacio temporal (por ejemplo, Notepad) y establecemos nuestra contraseña en el cmdlet ConvertTo-SecureString. Debería ser parecido a:

$adminpass = ConvertTo-SecureString 'mypassword' -AsPlainText -Force
cd C:\CloudDeployment\Setup
.\InstallAzureStackPOC.ps1 -AdminPassword $adminpass -UseADFS -NatIPv4Subnet 172.16.0.0/24 -NatIPv4Address 172.16.0.2 -NatIPv4DefaultGateway 172.16.0.1

Ahora sí que podemos presionar DEPLOY. ¿No ocurre nada? En ese caso lanzamos el script manualmente y veremos como comienza el proceso de instalación.

El script fallará pasados unos minutos. Vamos a solucionar el error.

Un pequeño hack para instalar en Azure

El script de instalación incorpora una batería de tests que comprueba que nuestra máquina es apta para correr Azure Stack, detectando estos van que es una máquina virtual y, por tanto, cancelará la instalación. Vamos a modificar estos tests para asegurarnos que no ocurre.

Las instrucciones son cortesía de este artículo de Thomas Torggler que ya consiguió hacer una instalación de Azure Stack sobre una máquina virtual de VMWare.

Abrimos un cmd y ejecutamos lo sigiuiente:

cd C:\CloudDeployment\Roles\PhysicalMachines\Tests
copy BareMetal.Tests BareMetal.Tests.bak
powershell_ise BareMetal.Tests

Aquí deberemos buscar dos tests específicos. En primer lugar buscar:

foreach ($physicalMachine in $physicalMachines)
{
    It ($BareMetalLocalizedStrings.TestNotVirtualMachine -f @($($physicalMachine.ComputerName))) `
    {
        $physicalMachine.IsVirtualMachine | Should Be $false
    }
}

Y sustituir por:

foreach ($physicalMachine in $physicalMachines)
{
    It ($BareMetalLocalizedStrings.TestNotVirtualMachine -f @($($physicalMachine.ComputerName))) `
    {
        #$physicalMachine.IsVirtualMachine | Should Be $false
    }
}

El segundo lugar deberemos buscar:

foreach ($physicalMachine in $physicalMachines)
{
     It ($BareMetalLocalizedStrings.TestMinimumNumberOfCores -f @($minimumNumberOfCoresPerMachine.ToString(), $($physicalMachine.ComputerName))) `
     {
          ($physicalMachine.Processors.NumberOfEnabledCores | Measure-Object -Sum).Sum | Should Not BeLessThan $minimumNumberOfCoresPerMachine
      }
}

Y sustituir por:

foreach ($physicalMachine in $physicalMachines)
{
     It ($BareMetalLocalizedStrings.TestMinimumNumberOfCores -f @($minimumNumberOfCoresPerMachine.ToString(), $($physicalMachine.ComputerName))) `
     {
          #($physicalMachine.Processors.NumberOfEnabledCores | Measure-Object -Sum).Sum | Should Not BeLessThan $minimumNumberOfCoresPerMachine
      }
}

Guardamos el archivo y nos preparamos para reiniciar la instalación.

Continuando la instalación

Volvemos a ejecutar la instalación con:

cd C:\CloudDeployment\Setup
.\InstallAzureStackPOC.ps1 -Rerun

Momento ideal para almorzar o salir a dar una vuelta, porque va para largo, el siguiente paso no ocurrirá hasta pasados aproximadamente 3 ó 4 horas.

Podréis ver que la salida por pantalla es muy verbose y nos cuenta en todo momento y al detalle lo que está haciendo, cosa que a servidor le encanta.

Llegado un determinado momento, la VM se reiniciará y continuará la instalación con la cuenta:

• Usuario: azurestackadmin@azurestack.local
• Contraseña: la que especificamos en la instalación

Si queremos continuar siguiendo el progreso tendremos que entrar por RDP usando estas credenciales.

Si todo finaliza correctamente, deberíamos ver el deseado COMPLETE: Action 'Deployment'.

¡No hemos terminado! Networking del router BGPNAT

Se supone que la máquina BGPNAT debe tener conexión a Internet para a su vez dársela a los recursos de Azure Stack mediante la SDN; pero si entramos en ella (nos autenticamos con la contraseña que especificamos en la instalación) veremos que no estamos conectados a Internet.

¿Motivo? BGPNAT hace de router y NAT entre la red pública y la red SDN de Azure Stack, siendo en este caso la red pública un VirtualSwitch External de Hyper-V que enlaza con el NIC de Azure.

Como ya he contado en otras ocasiones, a Azure no le gusta que en su red virtual circulen a nivel de Layer 2 adaptadores simulados, distintos de sus recursos NIC y no gobernados por su DHCP.

Vamos a solucionar la situación evitando usar este adaptador. Para ello abrimos la PowerShell como administrador e introducimos los siguientes cmdlets:

New-VMSwitch -Name "NATSwitch" -SwitchType Internal
$NIC=Get-NetAdapter | Out-GridView -PassThru
New-NetIPAddress -IPAddress "172.16.0.1" -PrefixLength 24 -InterfaceIndex $NIC.ifIndex
New-NetNat -Name "NATSwitch" -InternalIPInterfaceAddressPrefix "172.16.0.0/24" -Verbose

Podéis apreciar como la IP coincide con la del gateway NAT que especificamos al inicio de la instalación. Nos aparecerá una ventana en pantalla en la que deberemos hacer doble clic en el interfaz de red vEthernet (NATSwitch).

Si no obtenemos ningún error deberíamos tener nuestro NAT listo para funcionar. Ahora debemos abrir el Hyper-V Manager y seleccionar la VM AzS-BGPNAT01 y abrir los Settings. En el adaptador de red NAT cambiamos el Virtual Switch PublicSwitch por el recién creado NATSwitch. El resultado será similar al de la siguiente captura de pantalla:

Acto seguido probamos la conexión del BPGNAT:

¿Conectados? ¡Enhorabuena! ¡Hemos completado la instalación de Azure Stack!

Iniciando sesión en Azure Stack

Todo lo que nos queda por hacer es comprobar que Azure Stack se está ejecutando correctamente. ¡Probemos a entrar!

• Portal de administración: https://adminportal.local.azurestack.external/
• Portal del tenant: https://portal.local.azurestack.external/

Las credenciales a utilizar son las ya mencionadas, azurestackadmin@azurestack.local. Deberíamos poder ver algo similar a:

¡Y este es el fin de nuestra aventura! Espero que hayas podido llegar hasta aquí y ejecutar tu Azure Stack desde Azure.

Happy Azure Stacking!