Configurar una instancia administrada de Azure SQL

Como todas las opciones disponibles en Azure y, en particular, hablando de SQL, para la pregunta clásica sobre ¿qué opción es mejor para mí? La respuesta clásica sigue siendo válida y es «Depende».  Su necesidad, su carga de trabajo empresarial o su diseño arquitectónico influirían de manera determinante en su decisión.

En este artículo vamos a explicar paso a paso un enfoque para configurar una nueva instancia administrada de Azure SQL desde ahora, denominada simplemente SQL MI.  Es tan importante distinguir que existen diferentes formas de llegar al mismo resultado, pero lo más importante es comprender los conceptos básicos.

El primer aspecto que debo tener en cuenta es decidir la convención de nomenclatura, para este artículo voy a utilizar la autodescripción de forma que tenga un carácter más educativo.  Tenemos que definir el nombre de nuestro recurso, recuerde que, en pocas palabras, sería un contenedor lógico en el que agrupamos un conjunto de recursos de Azure vinculados a una suscripción específica.

En términos generales, las instancias administradas de SQL forman parte de un clúster virtual y se encuentran en una subred dentro de una red virtual.  Es obligatorio mantener la subred dedicada para las instancias administradas.  Esta imagen muestra una arquitectura de alto nivel de los componentes desde la perspectiva de los componentes de red.

La instancia administrada de SQL tiene un grupo de requisitos de red, principalmente la subred debe tener las siguientes características:

  • Subred dedicada
  • Direcciones IP suficientes
  • Delegación de subred
  • Grupo de seguridad de red (NSG)
  • Tabla de rutas definidas por el usuario

En este enlace encontrará más información al respecto:

https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/connectivity-architecture-overview#network-requirements)

Vamos a crear una nueva instancia administrada de SQL, pero tenemos que empezar por la creación de un nuevo recurso que vamos a llamar AzureLabsSQL. A través de este artículo estamos usando principalmente la consola Azure CLI y Azure PowerShell desde el portal Azure.  En el portal de Azure, localice el icono de Cloud Shell que se encuentra en la parte superior del sitio del portal; el icono se ve como esta imagen

Inmediatamente se abre una nueva ventana en la sección inferior de su sitio de portal, por lo que en nuestro caso vamos a usar Azure CLI, por lo que es necesario escribir az para empezar a ejecutar comandos de Azure CLI.

El siguiente comando creará el nuevo grupo de recursos, en mi caso el -l (ubicación) sería el sur del Reino Unido, y -n(nombre) es AzureLabsSQL

az group create -l "UK South" -n AzureLabsSQL

Ya estamos listos para crear SQL MI, mencioné que debemos crear la VNetwork y la subred con antelación; debe ejecutar los siguientes comandos en Azure CLI:

az network vnet create -g AzureLabsSQL  -n VNetAzureSQL

az network vnet subnet create -g AzureLabsSQL --vnet-name VNetAzureSQL -n SubnetSQLMi --address-prefixes 10.0.0.0/24

En este momento hemos implementado los nuevos objetos, un VName llamado VNetAzureSQL y una subred llamada SubnetSQLMi.  Tenemos que delegar la subred; es un requisito activar la subred y prepararla para asociarla a la nueva instancia administrada de SQL.  Es necesario obtener el identificador de suscripción antes de ejecutar el siguiente script de PowerShell:Managed Instance.  It is required to get the subscriptionId before executing the following PowerShell script:

$scriptUrlBase = 'https://raw.githubusercontent.com/Microsoft/sql-server-samples/master/samples/manage/azure-sql-db-managed-instance/delegate-subnet'

$parameters = @{
    subscriptionId = '2f97b493-86b0-4b7b-b0f1-cba5e3f42dfa'
    resourceGroupName = 'AzureLabsSQL'
    virtualNetworkName = 'VNetAzureSQL'
    subnetName = 'SubnetSQLMi'
    }

Invoke-Command -ScriptBlock ([Scriptblock]::Create((iwr ($scriptUrlBase+'/delegateSubnet.ps1?t='+ [DateTime]::Now.Ticks)).Content)) -ArgumentList $parameters

Este script prepara la subred en tres pasos:

  • Validar: Valida la red virtual y subred seleccionada para los requisitos de redes de instancias administradas SQL.
  • Confirmar: Muestra al usuario un conjunto de cambios que deben realizarse para preparar la subred para la implementación de instancias administradas por SQL. También solicita su consentimiento.
  • Preparar: Configura correctamente la red virtual y la subred.

En mi caso, no había creado ya la tabla de rutas y el grupo de seguridad de red (NSG), pero el script nos permite crearlo automáticamente.

Después de escribir la letra y crearía el nuevo objeto y lo asociaría a la subred y a VNet, mi recomendación es permitir que el script esté a cargo de la creación de estos objetos porque estarán listos y debidamente configurados para la instancia de administración SQL.  Para verificar que todo es correcto, puede ir al grupo de recursos y comprobar el nuevo objeto, por ejemplo:

En este punto, estamos listos para ejecutar el script para implementar nuestra nueva instancia administrada de SQL. Este paso durará varias horas, ¿por qué? Porque se implementa en un aislamiento completo y aporta ventajas de seguridad adicionales, pero el inconveniente es que el aprovisionamiento y el escalado pueden tardar varias horas.

az sql mi create -g AzureLabsSQL -n ManageInstanceLab -l "UK South" -i -u AdminSQL -p Ideragulag2021+ --subnet /subscriptions/2f97b493-86b0-4b7b-b0f1-cba5e3f42dfa/resourceGroups/AzureLabsSQL/providers/Microsoft.Network/virtualNetworks/VNetAzureSQL/subnets/SubnetSQLMi --capacity 4
--storage 32GB --edition GeneralPurpose --family Gen5

Una vez que haya ejecutado el script anterior, debe esperar unas horas, pero es posible abrir otra ventana del portal y comprobar los avances en la creación de este nuevo SQL MI.

Transcurridas unas horas, debería completarse y puede ir a su nuevo SQL MI y ver que se ha implementado correctamente, como muestra esta imagen:

Una vez completado el proceso, tenemos que empezar a trabajar en aspectos relacionados con la conectividad, como he mencionado al principio de este artículo, quiero acceder al nuevo SQL MI desde MI servidor local. Este aspecto es tan importante para determinar la infraestructura de conectividad que la siguiente imagen le ofrece una idea breve de las opciones disponibles para su nuevo servidor.

En nuestro caso, es fundamental configurar primero una subred de puerta de enlace (puertas de enlace VPN de Azure), ya que su definición proporciona conectividad entre las instalaciones del cliente y Azure.  Aquí tiene una sencilla imagen.

Crear una puerta de enlace VPN es obligatorio para el escenario en el que tenemos que conectarnos desde un entorno local, puede hacerlo de varias formas, pero en mi caso, voy a utilizar directamente el portal Azure, en los siguientes enlaces puede profundizar en la explicación sobre los diferentes enfoques

https://docs.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal

Dentro de VNet debe hacer clic en la opción Subnet (Subred)

Una vez que haga clic en él, el siguiente paso consiste en crear una subred de puerta de enlace haciendo clic en el botón de subred de puerta de enlace.

And assign a specific range of IPs

Y asigne un rango específico de IP como este

Antes de continuar con la configuración, es obligatorio utilizar un certificado para la creación de una nueva puerta de enlace VPN, recuerde que es obligatorio para habilitar la comunicación con el servidor local, que es el escenario que estoy presentando en este artículo.  Cada red virtual solo puede tener una puerta de enlace de red virtual de cada tipo. Independientemente de cómo se generó el certificado, es obligatorio como parte de la configuración adecuada, podría generarse para nuestra empresa o en caso de no tenerlo, deberíamos generarlo. 

Aquí vamos a generar un nuevo certificado. Puede obtener más información sobre este proceso en el siguiente artículo:

https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-creating-an-azure-point-to-site-vpn/ba-p/326264

En primer lugar, abra PowerShell y ejecute las siguientes instrucciones; puede personalizar el nombre de su certificado, empezamos con la raíz y más adelante el certificado de cliente.

--Generating a root certificate
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=SQLMIROOT" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign

--Generating a client certificate
New-SelfSignedCertificate -Type Custom -DnsName REBELCLIENT -KeySpec Signature -Subject "CN=SQLMICLIENT" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

Después de ejecutar correctamente el script anterior, debería ver un resultado como este

Para comprobar que los certificados están en su sitio, puede introducirlos en el administrador de certificaciones y verificarlos.

Una vez que hemos creado y verificado el nuevo certificado, debemos exportarlo, comenzando por el Certificado Raíz (SQLMIROOT), señalar el certificado y hacer clic con el botón derecho en – Todas las tareas – Exportar y elegir las opciones como muestran las imágenes

Con respecto al certificado de cliente, no es obligatorio exportarlo, al menos para el alcance de este artículo, porque solo se utilizará el certificado raíz en la VPN de Azure, además de que el certificado de cliente puede instalarse en otros equipos que necesiten conexiones P2S.

En este punto tenemos la materia prima para continuar avanzando.  El siguiente punto consiste en crear una nueva puerta de enlace VPN.  En el portal de Azure, vaya a Todos los servicios y busque Virtual Network Gateway. Una vez que haga clic en el botón Crear y rellenar, recuerde que lo más importante es que la nueva puerta de enlace pertenece a la misma suscripción y región que la red virtual objetivo que estaría asociada a la nueva puerta de enlace.  En nuestro caso, las funciones relacionadas con el tipo de puerta de enlace y VPN son las siguientes:

Una vez completado, debemos ir a la configuración de punto a sitio y llenar un grupo de artículos

El conjunto de direcciones se compone de un rango de IP que pertenecen a nuestra IP de destino dentro de la red donde hemos alojado el servidor local.  En mi caso, simplemente hice un ipconfig y obtuve la gama que usaré:

Con respecto a la sección Certificados raíz, los pasos a seguir para completar el par Nombre/Datos del certificado, debe abrir el certificado generado en la sección anterior.  Podría abrir el certificado con el Bloc de notas y copiar la sección sin COMENZAR CERTIFICADO ni FINALIZAR CERTIFICADO.

En este punto, debe iniciar sesión en el mismo PC en el que generamos los certificados. Si planea usar un PC diferente, debe importar el certificado raíz y los certificados de cliente previamente exportados.  En el portal Azure, debe hacer clic en Configuración de punto a sitio en la puerta de enlace VPN configurada recientemente y hacer clic en Descargar cliente

Una vez descargado, puede explorar el archivo zip que contiene las distintas plataformas disponibles.

Según el sistema operativo de su PC, instale la versión correcta necesaria, vaya a VPN y compruebe que se ha instalado correctamente.

A continuación, haga clic en Connect (Conectar) y se mostrará la siguiente imagen:

Puede verificar la asignación de IP desde el grupo de direcciones VPN, abrir CMD y escribir ipconfig, y debe ver una sección adicional que tenga el nombre de la red virtual creada desde el principio.

Ahora que estamos seguros de la conectividad mediante nuestro certificado, podemos conectarnos desde nuestro PC a la nueva y brillante instancia administrada de Azure SQL, ¿qué debe hacer? Básicamente, abra la aplicación cliente, en mi caso SQL Server Management Studio (SSMS), escriba el nombre del servidor y proporcione nuestro usuario/contraseña configurado en este artículo.  Después de rellenar los campos solicitados como esta imagen:

Por último, tenemos nuestra instancia lista para empezar a trabajar en ella.

Conclusión

A lo largo de este artículo, describimos y configuramos todos los elementos necesarios para que nuestra nueva instancia administrada de Azure SQL estuviera correctamente configurada y lista para ser accesible desde la app local.  Incluye algunos componentes no convencionales como la generación de sus propios certificados.  Espero que esta pequeña introducción sea útil y que pueda empezar a jugar con las ventajas de esta gran opción disponible en el ecosistema Azure, tal y como representa Managed Instance.  Tenga en cuenta que antes de adoptar SQL Managed Instance debe pensar detenidamente si es la opción adecuada para su carga de trabajo y necesidad y requisitos reales, si sus requisitos coinciden con la gran ventaja que ofrece SQL MI, por lo que le animo a empezar a jugar sin miedo, pero tenga en cuenta que la seguridad y el coste son algo que siempre debe poner en primer lugar.