Uno de los mecanismos clásicos para alta disponibilidad en SQL Server son las instancias clusterizadas. Una instancia clusterizada se instala sobre un cluster de Windows y permite a la instancia que en caso de fallo hardware o software en el nodo activo la instancia pueda arrancar en otro nodo. Esta tecnología de alta disponibilidad, aunque Microsoft la está relegando a un segundo lugar a favor de los Grupos de Disponibilidad, sigue siendo la más extendida en la mayor parte de los entornos productivos.

Una de las ventajas de las instancias clusterizadas es su compatibilidad absoluta con todas las aplicaciones actuales y heredadas. Básicamente si una aplicación funciona correctamente en una instancia sin clusterizar lo podrá hacer también en una instancia en cluster. Esta característica de “transparencia” es única y personalmente considero que crítica en muchos entornos donde no pueden asumir las complejidades de otras soluciones o el coste de adaptación. Además, en un escenario activo/pasivo el nodo pasivo no requiere de licenciamiento adicional.

Partiendo de que las instancias clusterizadas pueden ser una buena solución en muchos escenarios y que actualmente están en uso en multitud de sistema tiene sentido que nos planteemos cómo podríamos abordar una migración a Azure de uno de estos sistemas. Para configurar una instancia en failover cluster en Azure necesitamos un cluster con al menos dos nodos virtuales que estén dentro de un dominio de Windows. La configuración de un cluster de Windows en Azure no tiene mucho misterio por lo que me centraré en la parte más novedosa que consiste en el uso de Azure File Storage como almacenamiento SMB 3.0 como sustituto del clásico “disco compartido”. Comentaremos de forma breve el entorno de partida para contextualizar el resto de pasos. Partiremos de un cluster de, en este ejemplo, tres nodos:

FCI1

Al tratarse de nodos Windows Server 2016 y utilizaremos Cloud Witness configurado contra una cuenta de storage ubicada en otro datacenter para el witness:

FCI2

FCI3

Antes de poder realizar la instalación de nuestra instancia de SQL Server en cluster tenemos que crear nuestro Azure FIle Storage. Para ello desde el portal de Azure crearemos una nueva cuenta de almacenamiento y una vez esté creada añadiremos un recurso compartido de archivos:

FCI4

Crearemos por ejemplo varios shares para datos, log y bases de datos de sistema:

FCI20

Las URLs de acceso y las rutas UNC a utilizar serán las siguientes:

  • https://sql2016cluster.file.core.windows.net/data –> \\sql2016cluster.file.core.windows.net\data
  • https://sql2016cluster.file.core.windows.net/log –> \\sql2016cluster.file.core.windows.net\log
  • https://sql2016cluster.file.core.windows.net/system–> \\sql2016cluster.file.core.windows.net\system

A continuación necesitamos obtener la clave/token que nos permita el acceso a la cuenta de storage. Para ello seleccionaremos el apartado de claves de nuestra cuenta y copiaremos cualquiera de las dos claves activas:

FCI6

Antes de realizar la instalación de SQL Server en cluster conectaremos con la cuenta de servicio que vamos a utilizar para el motor de SQL Server a cada uno de los nodos para almacenar las credenciales. Una vez conectados, ejecutaremos el siguiente comando (sustituyendo el nombre de la cuenta de storage y la key por la que hemos obtenido en el paso anterior):

cmdkey /add:sql2016cluster.file.core.windows.net /user:sql2016cluster /pass:jgtLt0pKa5+mcwiYR2oo/b370mwrECoWHeQACDdnnuUHeFCm8J/DZExdXuXq2F85A1bMqJ9u4ii3FvMh6RsRdw==

El siguiente paso será conectar la unidad con el veterano comando “net use”:

net use * \\sql2016cluster.file.core.windows.net\data /persistent:yes

Comprobaremos que podemos acceder a la ruta de red sin problemas:

FCI7

Repetiremos el proceso para el resto de unidades, log, tempdb y system y nos aseguraremos que funcionan:

FCI18

El siguiente paso será realizar una instalación de SQL Server en cluster. Para ello elegiremos la opción de añadir una nueva instancia en cluster:

FCI8

Seguiremos los pasos como si se tratara de otra instalación con unas pocas diferencias. Cuando nos encontremos en el paso de elegir los discos compartidos del cluster, no tendremos ninguno de ellos, simplemente continuaremos al siguiente paso:

FCI9

A continuación, cuando indicamos la IP flotante para nuestro Network Name, deberemos configurar una IP que se encuentre balanceada en Azure, por ejemplo mediante un ILB. La configuración del ILB la podemos hacer vía powershell mediante un script similar al siguiente:

$mySubID = “1243hsgd-2352-4454-f245-87dasjfa87fd6”
$mySubName = Suscripcion
$rgnameNE = “SQL2016”
$locationNE = “North Europe” 
Login-AzureRmAccount
Get-AzureRmSubscription SubscriptionName $mySubName | Select-AzureRmSubscription 
$FrontEndConfigurationName = ILBClusterfront
$BackendConfiguratioName = ILBClusterback
$LoadBalancerName = ILBCluster  
$subname = ‘Subnet1’ # Provide the Subnet name in which the SQL Nodes are placed
$ILBIP = ‘10.1.1.100’ # Provide the IP address for the Listener or Load Balancer 
$subnet = Get-AzureRMVirtualNetworkResourceGroupName
$rgnameNE | Get-AzureRMVirtualNetworkSubnetConfig name $subname
$FrontConfig=New-AzureRMLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationNamePrivateIpAddress $ILBIPSubnetId $subnet.Id
$BackConfig=New-AzureRMLoadBalancerBackendAddressPoolConfig -Name $BackendConfiguratioName 
# Una vez creado el primer nodo del cluster
New-AzureRMLoadBalancer -Name $LoadBalancerNameResourceGroupName $rgnameNE -Location $locationNEFrontendIpConfiguration $FrontConfigBackendAddressPool $BackConfig  
$ClusterNetworkName = “Cluster Network 2”
$IPResourceName = “SQL IP Address 2 (SQLCLUSTER)” $CloudServiceIP = “10.1.1.100”
Import-Module FailoverClusters 
Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{“Address”=“$CloudServiceIP”;“ProbePort”=“59999;SubnetMask=”255.255.255.255″;“Network”=“$ClusterNetworkName”;“OverrideAddressMatch”=1;“EnableDhcp”=0}

Cuando configuremos las rutas para nuestra instalación deberemos indicar las rutas UNC anteriormente conectadas:

FCI10

Se nos pedirá confirmación de que somos conscientes de que debemos asignar los permisos adecuados a la ruta UNC de forma manual:

FCI12

Para tempdb no utilizaremos estas rutas de red, utilizaremos discos locales. Si disponemos de una unidad temporal D:, que se apoya en discos SSD locales, podemos utilizarla para este fin sin que suponga un coste añadido. Como curiosidad indicaremos que en el asistente de la instalación no se ha tenido en cuenta esta posibilidad, imposibilitando el seleccionar una ruta UNC para las carpetas de tempdb, forzándonos a elegir una unidad física. Sin embargo, el wizard si nos permite escribir la ruta UNC para el log, cosa que no haremos, pero que deja clara la falta de consistencia en este punto de la instalación:

FCI11

Una vez finalizada la instalación nos iremos al administrador de cluster y comprobaremos que ya tenemos un nuevo rol de tipo SQL Server ejecutando en el nodo recién instalado:

FCI13

A continuación procederemos a añadir un segundo nodo al cluster lanzando el instalador desde el nuevo nodo:FCI14

El proceso será más sencillo ya que la configuración se reutilizará de la anterior instalación. Básicamente tendremos que selecciona la instancia a la que queremos añadir un nodo y reintroducir las contraseñas de las cuentas de servicio cuando se nos solicite:

FCI15

No olvidemos tampoco crear la carpeta c:\tempdb que configuramos en el nodo anterior. Cuando finalice la instalación estaremos listos para la prueba de fuego, lanzar un failover entre los dos nodos.

FCI16

En unos segundos tendremos la instancia funcionando en el nuevo nodo.

FCI17

FCI19

En este post hemos visto cómo podemos instalar una instancia SQL Server clusterizada sin necesidad de almacenamiento clásico de cluster. Ante una migración de una instancia en cluster a máquinas virtuales en Azure esta es una de las soluciones que nos permiten abordarla. Para sistemas que requieran un rendimiento elevado esta solución puede no ser adecuada debido a que el almacenamiento actual de Azure File Storage está basado en almacenamiento clásico y no en almacenamiento premium. Esperamos que en no mucho tiempo el equipo de Azure File Storage publique “Azure File Storage Premium” para tener un servicio SMB 3.0 de alto rendimiento 🙂

Rubén Garrigós

Rubén Garrigós is an expert in high-availability enterprise solutions based on SQL Server design, tuning, and troubleshooting. Over the past fifteen years, he has worked with Microsoft data access technologies in leading companies around the world. He currently is a Microsoft SQL Server and .NET applications architect with SolidQ. Ruben is certified by Microsoft as a Solution Expert on the Microsoft Data Platform (MSCE: Data Platform) and as a Solution Expert on the Microsoft Private Cloud (MSCE: Private Cloud). As a Microsoft Certified Trainer (MCT), Ruben has taught multiple official Microsoft courses as well as other courses specializing in SQL Server. He has also presented sessions at official events for various Microsoft technologies user groups.