Clúster alta disponibilidad SQL Server 2017

24 octubre 2017
Profesionales IT
Josep Ma Solanes 0
| | |

Esta entrada trata la creación de un clúster alta disponibilidad SQL Server 2017 sobre Windows Server 2016 core, creando un super motor para nuestros datos.

Es una continuación de la serie de entradas relacionadas con el proceso de instalación de un servidor Microsofr SQL Server 2017:

 

Vídeo del artículo en Youtube.

 

Introducción al clúster alta disponibilidad SQL Server

Las instalaciones anteriores están bien, pero cuando todos los datos empresariales se alojan en este motor de base de datos, no es nada adecuado tenerlo en UN único servidor. El motivo principal, cuando este servidor debe detenerse por el motivo que sea, la mayoría de veces por las propias tareas de mantenimiento, dejas a ciegas toda la empresa. Y sí, las tareas de mantenimiento deben hacerse, ya sea en el sistema operativo como en el motor de base de datos.

Si bien en mi vida profesional he visto como se iba de un extremo a otro a la hora de crear y distribuir servidores: desde consolidar las bases de datos en un único servidor, al principio, a casi tener un servidor de base de datos para cada base de datos, no hace tanto. La respuesta adecuada es disponer de un buen motor de base de datos donde consolidar todas las bases de datos corporativas. Creedme si os digo que un servidor SQL Server bien dimensionado puede dar y aguantar mucho. Por lo tanto, para las instalaciones de hoy día me quedo con la estrategia de tener un buen motor compuesto por dos o más servidores SQL Server bien dimensionados y controlados (esto de hacer de administrador o dar la contraseña del sa a todo el mundo se ha acabado, que nos conocemos).

Después de esta introducción, centrémonos en la instalación que vamos a hacer: Un clúster alta disponibilidad de SQL Server 2017 sobre dos servidores Windows Server 2016 core.

El clúster alta disponibilidad SQL Server 2017 sobre Windows Server core nos permite dar alta disponibilidad al servicio de base de datos a nivel de servidores, que no a nivel de base de datos.

Me explico, en una configuración de clúster alta disponibilidad tenemos un servidor ACTIVO, que está ofreciendo el servicio de  base de datos, por lo tanto tiene la carga de todas las bases de datos y está haciendo uso de la memoria y procesador de la máquina. Mientras que el otro servidor se queda en modo PASIVO, está a la espera, sin hacer nada, vaya que se está rascando la barriga.

En caso de pérdida del servidor activo, el servidor pasivo ARRANCARÁ de nuevo el servicio de base de datos y se pondrá a ofrecer el servicio. Cómo bien habéis leído, hay una pérdida de servicio: el servidor activo se detiene mal (hacemos el símil de sacar el cable de electricidad sin parar el servidor), por lo tanto, las transacciones en línea caen y se pierden, las conexiones se deben rehacer de nuevo sobre el nuevo nodo y el servicio se debe arrancar desde 0, con la consiguiente comprobación de la base de datos.

En caso de parada programada del servidor activo, el servidor ACTIVO pasa el servicio al servidor PASIVO de forma ordenada, existiendo una pequeña pérdida de servicio mientras se acaba de traspasar el control, nada que ver al caso anterior.

Es un primer nivel de alta disponibilidad, el de toda la vida. En qué tenemos asegurada la continuidad del servicio en caso de parada de servidores, pero NO el de corrupción de las bases de datos. Ya que los archivos de base de datos son únicos y, en consecuencia, una corrupción en el archivo de base de datos equivale a una corrupción de la misma. Para evitar la corrupción de los archivos de bases de datos tenemos a disposición la característica Always On, que combinado con el clúster alta disponibilidad SQL Server asegura una disponibilidad total del sistema. Esta configuración se tratará en otra entrada.

El montaje que procederemos a realizar es el que muestra el siguiente diagrama:

  • Dos servidores Windows Server 2016 core harán de nodos de clusterización: srvSQL1core y srvSQL2core.
  • Los dos servidores anteriores forman el clúster de gestión: clustersql con un disco de witness (W).
  • Los discos dedicados en el rol de clúster de base de datos son:
    • SQLdb – Volumen K.
    • SQLlogs – Volumen L
    • SQLTempDB – Volumen T
  • Sobre el clúster se monta un nuevo recurso clusterizado de SQL Server, con el nombre SQL2k17.

Centrándonos de nuevo en el clúster alta disponibilidad SQL Server, formado por dos servidores Windows Server 2016 en su edición core y alojando las bases de datos en volúmenes compartidos SAN. En la siguiente tabla se muestran las unidades de disco necesarias, para una instalación mínima en clúster alta disponibilidad

Servidor SQL1 Servidor SQL2 Compartidos (SAN) Finalidad
C C – Sistema operativo propio de cada servidor
E E – Archivos de la aplicación SQL Server en cada servidor
– – W Witness o quorum para el clúster alta disponibilidad
– – K Archivos de bases de datos
– – L Archivos de transacciones de las bases de datos
– – T Base de datos Temporal

Con los discos compartidos conectados en el nodo 1, al igual que la instalación de SQL Server normal, procedemos a preparar los discos. Con la diferencia que tenemos un disco duro más para el Witness y dos servidores en vez de uno.

Desde la consola del primer servidor, arrancar la herramienta de gestión de discos diskpart, escribiendo el comando:

diskpart

Localizamos los discos que tenemos reconocidos por el sistema:

list disk

 

Perfecto, se visualizan los cinco discos a punto para dar formato. Fijaos que están sin conexión.

Empezamos la configuración de los discos por el de aplicaciones. Sistema de archivos NTFS asignado a la unidad E y con la unidad de asignación por defecto.

Seleccionar el primer disco:

Select disk 1

Se pone en línea:

online disk

Eliminar el bloqueo contra escritura:

attribute disk clear readonly

Borrar su posible contenido en cuanto a configuraciones y particiones:

clean

Convertirlo a GPT:

convert gpt

Crear la primera partición primaria con todo el espacio de disco:

create partition primary

Listar los volúmenes que contiene el sistema, debe aparecer el nuevo volumen en crudo (RAW):

list volume

Seleccionar el nuevo volumen (que está en crudo – RAW):

select volume 3

Formatear el volumen con sistema de archivos NTFS y unidad de asignación por defecto, además, le añadimos la etiqueta SQLApps para que nos sea más fácil reconocerlo:

format fs=NTFS label="SQLApps" quick

Asignar la letra de unidad que le corresponda, en mi caso la E:

assign letter=e

Listar los volúmenes para comprobar que todo está correcto:

list volume

Repetir el proceso para el volumen de witness.

list disk
select disk 2
online disk
attribute disk clear readonly
clean
convert gpt
create partition primary
list volume
select volume 4
format fs=NTFS label="Witness" quick
assign letter=W
list volume

Repetir el proceso para el volumen de base de datos, pero esta vez con tipo de sistema de archivos ReFS, unidad de asignación de 64K y unidad de disco K. Ejecuto los list para ir comprobando la creación de los diferentes elementos y poder asegurar que lo que se selecciona es lo correcto:

list disk
select disk 3
online disk
attribute disk clear readonly
clean
convert gpt
create partition primary
list volume
select volume 5
format fs=ReFS unit=64k label="SQLdb" quick
assign letter=K
list volume

Repetir el proceso para el volumen de logs, igual que el anterior, pero con unidad de disco L:

list disk
select disk 4
online disk
attribute disk clear readonly
clean
convert gpt
create partition primary
list volume
select volume 6
format fs=ReFS unit=64k label="SQLlogs" quick
assign letter=L
list volume

Finalmente, creación del volumen para la base de datos TempDB, igual que el anterior, pero con unidad de disco T:

list disk
select disk 5
online disk
attribute disk clear readonly
clean
convert gpt
create partition primary
list volume
select volume 7
format fs=ReFS unit=64k label="SQLTempDB" quick
assign letter=T
list volume

 

Con los volúmenes creados, ya se puede salir del diskpart con un:

exit

Desde la consola del SEGUNDO servidor, arrancar la herramienta de gestión de discos diskpart, escribiendo el comando:

diskpart

Localizamos los discos que tenemos reconocidos por el sistema y configuramos el volumen para la instalación de las aplicaciones SQL Server en el nodo:

list disk
select disk 1
online disk
attribute disk clear readonly
clean
convert gpt
create partition primary
list volume
select volume 3
format fs=NTFS label="SQLApps" quick
assign letter=E
list volume

 

Ahora, a diferencia del nodo 1, sólo hay que poner el resto de discos, que ya hemos preparado en otro servidor, en línea y asignar la unidad que les corresponde:

Seleccionar el primer disco:

Select disk 2
Online disk
list volume
select volume 4
assign letter=W
Select disk 3
Online disk
select volume 5
assign letter=K
Select disk 4
Online disk
select volume 6
assign letter=L
Select disk 5
Online disk
select volume 7
assign letter=T

Listar los volúmenes para comprobar que todo está correcto:

list volume

Con los dos servidores preparados en cuánto a requisitos mínimos, se puede proceder a montar el clúster de alta disponibilidad.

 

Configuración clúster alta disponibilidad de Windows Server para PowerShell

Empezamos añadiendo la característica de clúster de alta disponibilidad a los dos servidores que lo formarán. Desde la PowerShell, comprobamos que la característica está disponible:

get-windowsfeature | Where-Object {$_.DisplayName -like '*clúster*'}

Se debe instalar tanto el servicio, como el módulo para la PowerShell, por lo tanto, se puede instalar todo lo que ha devuelto la consulta anterior con el comando:

get-windowsfeature | Where-Object {$_.DisplayName -like '*clúster*'} | install-windowsfeature

Después de la activación de la característica, se puede comprobar que tenemos disponibles los comandos de PowerShell validando si existe algún clúster, que debe ser que no:

get-cluster

Procedemos a la creación del clúster, que no el servicio de clúster de SQL server. No confundamos los conceptos. El clúster es a partir del cuál se juntan los dos servidores y permite crear ROLES, como el SQL Server, encima. Se asigna un nombre y una dirección IP para la gestión del clúster, que no serán las que se deben utilizar para el clúster de SQL Server. En mi caso, el clúster de gestión se dirá clustersql y tendrá la IP 192.168.1.213.

El comando para crear un nuevo clúster, con un solo nodo (srvsql1core), sin hacer el test de los discos, que lo haremos más adelante, y visualizando el resultado, es:

New-cluster -name "CLUSTERSQL" -node srvsql1core.jmsolanes.local -staticaddress 192.168.1.213 -nostorage -verbose

Obtenemos una advertencia, pero el nuevo clúster se ha creado correctamente. Comprobémoslo con el comando:

Get-Cluster

Añadimos el otro servidor (srvSQL2core) al clúster que se acaba de crear:

Get-Cluster | add-clusternode -name srvsql2core.jmsolanes.net

Comprobamos que se ha añadido correctamente y está levantado:

Get-Cluster | Get-ClusterNode

También comprobamos los discos disponibles para utilizarlos en el clúster, los que hemos preparado al inicio, exceptuando los dos de aplicaciones SQL que se quedan en cada nodo.

Get-ClusterResource

Aquí si que está un poco liada la cosa. No sé exactamente a dónde corresponden los discos, ya que aparecen como Disco de clúster 1, 2, 3 y 4. ¿Pero cuál corresponde a cuál?

Comprobamos primero qué letras son y si son las correctas. Asignamos el clúster a una variable:

$cluster = Get-Cluster

Recorremos los dos servidores buscando sus discos, la capacidad, la etiqueta y la unidad asignada, asignándolo a una variable:

foreach ($node in Get-ClusterNode -Cluster $cluster) {
$tmp += Get-WmiObject -Query "SELECT * FROM Win32_Volume" -ComputerName $node.nodeName}

Listamos el resultado de la variable:

$tmp | Select-Object Label, Capacity, BlockSize, Name

Para asegurar que utilizamos el disco correcto, podemos averiguar en qué partición está asignado el disco del recurso del clúster con los siguientes comandos:

Fijamos el nombre del disco que queremos saber a que partición pertenece, por ejemplo «Disco de clúster 1»:

$NombreRecursoDisco = "Disco de clúster 1"

Averiguamos el recurso de disco:

$RecursoDisco = gwmi MSCluster_Resource -Namespace root/mscluster | ?{$_.Name -eq $NombreRecursoDisco }

Averiguamos el disco duro asociado:

$Disco = gwmi -Namespace root/mscluster -Query "Associators of {$RecursoDisco} Where ResultClass=MSCluster_Disk"

Averiguamos que partición tiene este disco duro:

$Particion = gwmi -Namespace root/mscluster -query "Associators of {$Disco} Where ResultClass=MSCluster_DiskPartition"

Y obtenemos la ruta en la qué está montada la partición:

$Partition | Select Path

Aseguramos que es la que deseamos y etiquetamos el disco con los comandos siguientes:

 

Asignar el disco recurso del clúster a una variable:

$disk1 = Get-ClusterResource -name "Disco de clúster 1"

Cambiar la propiedad Name del objeto:

$disk1.Name = "Witness"

Repetir el proceso para los otros discos:

Averiguar la unidad que tiene montado el recurso de clúster:

$NombreRecursoDisco = "Disco de clúster 2"

$RecursoDisco = gwmi MSCluster_Resource -Namespace root/mscluster | ?{$_.Name -eq $NombreRecursoDisco }

$Disco = gwmi -Namespace root/mscluster -Query "Associators of {$RecursoDisco} Where ResultClass=MSCluster_Disk"

$Particion = gwmi -Namespace root/mscluster -query "Associators of {$Disco} Where ResultClass=MSCluster_DiskPartition"

$Particion | Select Path

Asignar el nombre al disco:

$disk2 = Get-ClusterResource -name "Disco de clúster 2"
$disk2.Name = "SQLdb"

$disk3 = Get-ClusterResource -name "Disco de clúster 3"
$disk3.Name = "SQLlogs"

$disk4 = Get-ClusterResource -name "Disco de clúster 4"
$disk4.Name = "SQLTempDB"

Con los discos de recursos de clúster identificados, procedemos a configurar el disco de Witness del clúster. Establecemos tipo de Witness de nodos y mayoría de disco, asignando el disco etiquetado como Witness:

set-ClusterQuorum -NodeAndDiskMajority "Witness"

Comprobamos que el recurso de disco ha pasado a ser Witness:

get-ClusterResource

El recurso Witness ya pertenece al grupo de clúster.

Ya sólo nos queda validar el clúster, requisito previo a la instalación del clúster alta disponibilidad SQL Server 2017:

get-cluster | test-cluster

Nos podemos encontrar alguna advertencia, pero NO errores para poder continuar con la instalación. Revisando el archivo que genera con el report salimos de dudas.

 

Preparar los archivos de la instalación desatendida del clúster alta disponibilidad SQL Server 2017

Consiste en la creación de un archivo con extensión .INI con los parámetros de configuración del nuevo clúster. Podéis echar un vistazo a la explicación de los parámetros generales en la entrada sobre la instalación de un SQL Server 2017 de forma desatendida. En esta nos centramos sólo a los que hacen referencia al clúster.

Primer nodo del clúster

Archivo para el primer servidor del clúster. Dónde varia el tipo de acción (ACTION), indicando que se trata de crear un nuevo clúster (InstallFailoverCluster):

[OPTIONS]
ACTION="InstallFailoverCluster"
IACCEPTPYTHONLICENSETERMS="True"
IACCEPTROPENLICENSETERMS="True"
SUPPRESSPRIVACYSTATEMENTNOTICE="True"
QUIET="False"
QUIETSIMPLE="True"
ENU="True"
UpdateEnabled="True"
UpdateSource="MU"
USEMICROSOFTUPDATE="False"
FEATURES=SQLENGINE,REPLICATION,FULLTEXT,DQ,CONN
HELP="False"
INDICATEPROGRESS="False"
X86="False"

INSTANCENAME="MSSQLSERVER"
INSTALLSHAREDDIR="E:\Program Files\Microsoft SQL Server"
INSTALLSHAREDWOWDIR="E:\Program Files (x86)\Microsoft SQL Server"
INSTANCEID="MSSQLSERVER"
INSTANCEDIR="E:\Program Files\Microsoft SQL Server"

FTSVCACCOUNT="NT Service\MSSQLFDLauncher"
AGTSVCACCOUNT="jmsolanes\usrdbagent"
SQLSVCACCOUNT="jmsolanes\usrdbengine"

SQLCOLLATION="Modern_Spanish_CI_AS"

SQLSYSADMINACCOUNTS="jmsolanes\Administrator" "jmsolanes\Administradores SQL"
SECURITYMODE="SQL"
FILESTREAMLEVEL="0"

SQLTEMPDBDIR="T:\MSSQL\Data"
SQLTEMPDBFILECOUNT="1"
SQLTEMPDBFILESIZE="8"
SQLTEMPDBFILEGROWTH="64"
SQLTEMPDBLOGFILESIZE="8"
SQLTEMPDBLOGFILEGROWTH="64"
SQLUSERDBDIR="K:\MSSQL\Data"
SQLUSERDBLOGDIR="L:\MSSQL\Logs"

COMMFABRICPORT="0"
COMMFABRICNETWORKLEVEL="0"
COMMFABRICENCRYPTION="0"
MATRIXCMBRICKCOMMPORT="0"

SQLSVCINSTANTFILEINIT="False"

Las opciones para la configuración del clúster se especifican con los siguientes comandos:

Identificar los discos disponibles para el recurso de clúster de SQL Server, indicar los nombres tal como aparecen en el comando de

Get-ClusterResources.

FAILOVERCLUSTERDISKS="SQLdb" "SQLlogs" "SQLtempdb"

Nombre del grupo de recursos del clúster de SQL Server. Ponemos SQL Server (MSSQLSERVER), para indicar que es un SQL Server y el nombre de la instancia, en este caso, la de defecto:

FAILOVERCLUSTERGROUP="SQL Server (MSSQLSERVER)"

La dirección IP, con su máscara y la asociación a la red disponible en el clúster, que tendrá el recurso de clúster SQL. Para saber el nombre exacto de la red disponible en el clúster ejecutáis el comando Get-ClusterNetwork:

FAILOVERCLUSTERIPADDRESSES="IPv4;192.168.1.217;Red de clústeres 1;255.255.255.0"

Nombre del clúster SQL, para el nombre en que se accederá desde el exterior:

FAILOVERCLUSTERNETWORKNAME="SQL2k17"

Directorio para la instancia del SQL Server. Este directorio debe estar compartido en el clúster, por lo tanto, seleccionamos la unidad K. En instalaciones en producción, se aconseja que esté en otro volumen dedicado a tal efecto. En esta entrada compartimos la instancia con las bases de datos:

INSTALLSQLDATADIR="K:"

Directorio para las copias de seguridad de SQL Server. Al igual que el directorio de la instancia, indicar un recurso compartido de red o volumen compartido entre los nodos.

SQLBACKUPDIR="K:\MSSQL\Backup"

El apartado de configuración del clúster SQL quedaría de la siguiente forma, a añadir al final del archivo de configuración:

FAILOVERCLUSTERDISKS="SQLdb" "SQLlogs" "SQLtempdb"
FAILOVERCLUSTERGROUP="SQL Server (MSSQLSERVER)"
FAILOVERCLUSTERIPADDRESSES="IPv4;192.168.1.214;Red de clústeres 1;255.255.255.0"
FAILOVERCLUSTERNETWORKNAME="SQL2k17"

INSTALLSQLDATADIR="K:"
SQLBACKUPDIR="K:\MSSQL\Backup"

 

Segundo nodo del clúster

Archivo para el siguiente servidor del clúster, donde también varia el tipo de acción (ACTION), indicando que se trata de un nuevo nodo para el clúster (AddNode). Este archivo ya es mucho más corto, ya que la mayoría de opciones se definen en el primer servidor:

[OPTIONS]
ACTION="AddNode"
IACCEPTPYTHONLICENSETERMS="True"
IACCEPTROPENLICENSETERMS="True"
SUPPRESSPRIVACYSTATEMENTNOTICE="True"
QUIET="False"
QUIETSIMPLE="True"
ENU="True"
UpdateEnabled="True"
UpdateSource="MU"
USEMICROSOFTUPDATE="False"
HELP="False"
INDICATEPROGRESS="False"
X86="False"

INSTANCENAME="MSSQLSERVER"
FTSVCACCOUNT="NT Service\MSSQLFDLauncher"
AGTSVCACCOUNT="jmsolanes\usrdbagent"
SQLSVCACCOUNT="jmsolanes\usrdbengine"
SQLSVCINSTANTFILEINIT="False"

Y se especifica en qué clúster se añade el nuevo nodo, indicando el grupo de recursos, la IP y el nombre del rol de clúster SQL:

FAILOVERCLUSTERGROUP="SQL Server (MSSQLSERVER)"
CONFIRMIPDEPENDENCYCHANGE="False"
FAILOVERCLUSTERIPADDRESSES="IPv4;192.168.1.217;Red de clústeres 1;255.255.255.0"
FAILOVERCLUSTERNETWORKNAME="SQL2k17"

Archivos utilizados:

 

Configuración del cortafuegos

Antes de lanzar la instalación, y para que no se nos olvide y tengamos problemas de balanceo con la instancia de SQL Server, abrimos los puertos correspondientes TCP 1433 y UDP 1434 en el cortafuegos de los dos servidores:

Abrir los puertos TCP 1433 y UDP 1434

Ejecutar los comandos:

New-NetFirewallRule -Name "SQLServerTCP1433" -DisplayName "SQL Server TCP 1433" -Enabled True -Profile Any -Direction Inbound -Action Allow -Protocol "TCP" -LocalPort 1433
New-NetFirewallRule -Name "SQLServerUDP1434" -DisplayName "SQL Server UDP 1434" -Enabled True -Profile Any -Direction Inbound -Action Allow -Protocol "UDP" -LocalPort 1434

Comprobar que se han creado las dos reglas:

Get-NetFirewallRule |Where-Object{$_.Name -like "*sql*"}

Para deshabilitar las reglas anteriores, en caso que fuese necesario:

Get-NetFirewallRule |Where-Object{$_.Name -like "*sql*"} | Set-NetFirewallRule -Enabled false

 

Configuración de cortafuegos a nivel del servicio SQL

En caso de hacerlo a nivel de servicio y que el ejecutable se encuentre en la ruta indicada, ejecutar el comando:

New-NetFirewallRule -Name "SQLServer2017" -DisplayName "SQL Server 2017" -Enabled True -Profile Any -Direction Inbound -Action Allow -Program 'E:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\Binn\sqlservr.exe'

 

Instalación del clúster alta disponibilidad SQL Server 2017 de forma desatendida

Ya lo tenemos todo preparado. Montamos la imagen de instalación del SQL Server y ejecutamos el comando de instalación desatendida en el primer servidor, proporcionando las contraseñas correspondientes a las cuentas de servicio y al usuario administrador de SQL Server (sa); y el archivo con todos los parámetros de configuración (node1.ini):

.\setup /IAcceptSQLServerLicenseTerms /SQLSVCPASSWORD="Solquer#2017" /AGTSVCPASSWORD="Solquer#2017" /SAPWD="Hola!Hola!" /ConfigurationFile=e:\node1.ini

Dejamos que el sistema vaya haciendo él sólo. Una vez ha terminado se puede comprobar que se ha creado correctamente el rol con el comando:

Get-ClusterResource

Aseguraros que los servicios de SQL Server están en línea. También podéis comprobar que está operativo realizando una conexión con el SQL Management Studio. Es un clúster de un sólo nodo, pero el SQL Server ya es completamente operativo.

 

Es el turno de instalar el segundo servidor, que actuará como pasivo. Con la imagen de instalación del SQL Server montada, ejecutamos el comando indicando el nombre del segundo archivo de configuración desatendida. Las contraseñas del motor y el agente también se tienen que proporcionar ya que debe registrar los servicios con ellas. La del SA no, porque ya está establecida en el primer servidor:

.\setup /IAcceptSQLServerLicenseTerms /SQLSVCPASSWORD="Solquer#2017" /AGTSVCPASSWORD="Solquer#2017" /ConfigurationFile=e:\node2.ini

Con la instalación completada correctamente ahora ya disponemos de un clúster alta disponibilidad SQL Server. Comprobamos que se puede balancear el servicio de clúster del servidor srvSQL1core al servidor srvSQL2core:

Get-ClusterGroup *SQL* |Move-ClusterGroup -Node srvSQL2core

Podemos ver como el propietario del recurso cambia a otro servidor. Comprobamos que el recurso está levantado:

Get-ClusterResource *SQL*

Deben aparecer los diferentes recursos con estado En línea.

Volvemos a conectar al SQL Server para comprobar que todo funciona, eso sí, conectando al nombre del recurso: SQL2k17.

¿Cómo sabemos en que nodo está trabajando el SQL Server? ¡Buena pregunta! La respuesta, ejecutando las siguientes consultas:

SELECT @@SERVERNAME AS [NomSQL]
SELECT SERVERPROPERTY('ComputerNamePhysicalNetBIOS') AS [NomNodeCluster]

La primera nos muestra el nombre del SQL (el recurso de clúster donde se debe conectar todo el munto). La segunda muestra el nombre real del servidor que está ejecutando el SQL Server. En la foto, el clúster se encuentra ejecutándose en el nodo srvSQL2core.

Moviendo el recurso del clúster de nuevo al nodo 1:

Get-ClusterGroup *SQL* | Move-ClusterGroup -Node srvSQL1core

Y refrescando la consulta anterior, cambia el nombre del servidor donde se está ejecutando:

 

¿Y si ya no queremos el nodo y se quiere desinstalar?

El comando para desinstalar el rol SQL Server de la instancia MSSQLSERVER del servidor del clúster es:

.\setup.exe /action=removenode /instancename=MSSQLSERVER /q

Ejecutándolo en los dos nodos nos deja uno sin el SQL Server. Comprobémoslo listando los recursos del clúster, donde los discos vuelven a estar disponibles y el grupo de SQL ha desparecido:

Get-ClusterResource

 

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

Similar Posts by The Author: