Clúster alta disponibilitat SQL Server 2017

24 octubre 2017
  • es Español
    • Professionals TIC
    Josep Ma Solanes 0
    | | | |

    Aquesta entrada tracta la creació d’un clúster alta disponibilitat SQL Server 2017 sobre Windows Server 2016 core, creant un super motor per les nostres dades.

    És una continuació de la sèrie d’entrades relacionades amb el procés de instal·lació d’un servidor Microsoft SQL Server 2017:

     

    Vídeo de l’article a Youtube.

     

    Introducció al clúster alta disponibilitat SQL Server

    Les instal·lacions anteriors estan bé, però quan totes les dades empresarials s’allotgen en aquest motor de base de dades, no és gens adequat tenir-ho en UN únic servidor. El motiu principal, quan aquest servidor s’ha d’aturar pel motiu que sigui, la majoria de vegades per les pròpies tasques de manteniment, deixes a cegues tota l’empresa. I sí, les tasques de manteniment s’han de fer, ja sigui al sistema operatiu com al motor de base de dades.

    Si bé en la meva vida professional he vist com s’anava d’un extrem a un altre a l’hora de crear i distribuir servidors: des de consolidar les bases de dades en un únic servidor, al principi, a gairebé tenir un servidor de base de dades per a cada base de dades, no fa tant. La resposta adequada és disposar d’un bon motor de base de dades on consolidar totes les bases de dades corporatives. Creieu-me si us dic que un servidor SQL Server ben dimensionat pot donar i aguantar molt. Per tant, per les instal·lacions d’avui en dia em quedo amb l’estratègia de tenir un bon motor composat per dos o més servidors SQL Server ben dimensionats i controlats (això de fer administrador o donar la contrasenya del sa a tothom s’ha acabat, que ens coneixem).

    Després d’aquesta introducció, centrem-nos en la instal·lació que anem a fer: Un clúster alta disponibilitat de SQL Server 2017 sobre dos servidors Windows Server 2016 core.

    El clúster alta disponibilitat SQL Server 2017 sobre Windows Server core ens permet donar alta disponibilitat al servei de base de dades a nivell de servidors, que no a nivell de base de dades.

    M’explico, en una configuració de clúster alta disponibilitat tenim un servidor ACTIU, que està oferint el servei de base de dades, per tant té la càrrega de totes les bases de dades i està fent ús de la memòria i processador de la màquina. Mentre que l’altre servidor resta en mode PASSIU, està a l’espera, sense fer res, vaja que s’està tocant la panxa.

    En cas de pèrdua del servidor actiu, el servidor passiu ARRANCARÀ de nou el servei de base de dades i es posarà a oferir el servei. Com bé heu llegit, hi ha una pèrdua de servei: el servidor actiu s’atura malament (fem el símil a treure el cable d’electricitat sense aturar el servidor), per tant, les transaccions en línia cauen i es perden, les connexions s’han de refer de nou sobre el nou node i el servei s’ha d’arrencar des de 0, amb la conseqüent comprovació de la base de dades.

    En cas d’aturada programada del servidor actiu, el servidor ACTIU passa el servei al servidor PASSIU de forma ordenada, existint una petita pèrdua de servei mentre s’acaba de traspassar el control, res a veure al cas anterior.

    És un primer nivell d’alta disponibilitat, el de tota la vida. En què tenim assegurada la continuïtat del servei en cas d’aturada de servidors, però NO el de corrupció de les bases de dades. Ja què els fitxers de base de dades són únics i, en conseqüència, una corrupció al fitxer de base de dades equival a una corrupció de la mateixa. Per evitar la corrupció dels fitxers de bases de dades tenim a disposició la característica Always On, que combinat amb el clúster alta disponibilitat SQL Server assegura una disponibilitat total del sistema. Aquesta configuració es tractarà en una altra entrada.

    El muntatge que procedirem a realitzar és el què mostra el següent diagrama:

    • Dos servidors Windows Server 2016 core faran de nodes de clusterització: srvSQL1core i srvSQL2core.
    • Els dos servidors anteriors formen el clúster de gestió: clustersql amb un disc de witness (W).
    • Els discs dedicats a al rol de clúster de base de dades són:
      • SQLdb – Volum K.
      • SQLlogs – Volum L
      • SQLTempDB – Volum T
    • Sobre el clúster es munta un nou recurs clusteritzat de SQL Server, amb el nom SQL2k17.

    Centrant-nos de nou al clúster alta disponibilitat SQL Server, format per dos servidors Windows Server 2016 en la seva edició core i allotjant les bases de dades en volums compartits SAN. En la següent taula es mostren les unitats de disc necessàries, per una instal·lació mínima en clúster alta disponibilitat

    Servidor SQL1 Servidor SQL2 Compartits (SAN) Finalitat
    C C – Sistema operatiu propi de cada servidor
    E E – Fitxers de l’aplicació SQL Server en cada servidor
    – – W Witness o quorum pel clúster alta disponibilitat
    – – K Fitxers de bases de dades
    – – L Fitxers de transaccions de les bases de dades
    – – T Base de dades Temporal

    Amb els discs compartits connectats al node 1, a l’igual que la instal·lació de SQL Server normal, procedim a preparar els discs. Amb la diferència que tenim un disc dur més pel Witness i dos servidors en comptes d’un.

    Des de la consola del primer servidor, arrancar l’eina de gestió de discs diskpart, escrivint la comanda:

    diskpart

    Localitzem els discs que tenim reconeguts pel sistema:

    list disk

     

    Perfecte, es visualitzen els cinc discs a punt per donar format. Fixeu-vos que estan sense connexió.

    Comencem la configuració dels discs pel d’aplicacions. Sistema de fitxers NTFS assignat a la unitat E i amb la unitat d’assignació per defecte.

    Seleccionar el primer disc:

    Select disk 1

    Es posa en línia:

    online disk

    Eliminar el bloqueig contra escriptura:

    attribute disk clear readonly

    Esborrar el seu possible contingut en quan a configuracions i particions:

    clean

    Convertir-lo a GPT:

    convert gpt

    Crear la primera partició primària amb tot l’espai de disc:

    create partition primary

    Llistar els volums que conté el sistema, ha d’aparèixer el nou volum en cru (RAW):

    list volume

    Seleccionar el nou volum (que està en cru – RAW):

    select volume 3

    Formatar el volum amb sistema de fitxers NTFS i unitat d’assignació per defecte, a més, li afegim l’etiqueta SQLApps perquè ens sigui més fàcil reconèixer-lo:

    format fs=NTFS label="SQLApps" quick

    Assignar la lletra d’unitat que li correspongui, en el meu cas la E:

    assign letter=e

    Llistar els volums per comprovar que tot és correcte:

    list volume

    Repetir el procés pel volum 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 procés pel volum de base de dades, però aquest cop amb tipus de sistema de fitxers ReFS, unitat d’assignació de 64K i unitat de disk K. Executo els list per anar comprovant la creació dels diferents elements i poder assegurar que el què es selecciona és el correcte:

    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 procés pel volum de logs, igual que l’anterior, però amb unitat de disk 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

    Finalment, creació del volum per la base de dades TempDB, igual que l’anterior, però amb unitat de disk 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

     

    Amb els volums creats, ja es pot sortir del diskpart amb un:

    exit

    Des de la consola del SEGON servidor, arrancar l’eina de gestió de discs diskpart, escrivint la comanda:

    diskpart

    Localitzem els discs que tenim reconeguts pel sistema i configurem el volum per la instal·lació de les aplicacions SQL Server al node:

    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

     

    Ara, a diferència del node 1, només cal posar la resta de discs, que ja hem preparat en l’altre servidor, en línia i assignar la unitat que els correspon:

    Seleccionar el primer disc:

    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

    Llistar els volums per comprovar que tot és correcte:

    list volume

    Amb els dos servidors preparats en quan a requisits mínims, es pot procedir a muntar el clúster d’alta disponibilitat.

     

    Configuració clúster alta disponibilitat de Windows Server per PowerShell

    Comencem afegint la característica de clúster d’alta disponibilitat als dos servidors que el formaran. Des de la PowerShell, comprovem que la característica està disponibile:

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

    Cal instal·lar tant el servei, com el mòdul per la PowerShell, per tant, es pot instal·lar tot el què ha retornat la consulta anterior amb la comanda:

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

    Després de l’activació de la característica, es pot comprovar que tenim disponibles les comandes de PowerShell validant si existeix cap clúster, que ha de ser que no:

    get-cluster

    Procedim a la creació del clúster, que no el servei de clúster de SQL server. No confonguem els conceptes. El clúster és a partir del qual s’ajunten els dos servidors i permet crear ROLS, com el SQL Server, a sobre. S’assigna un nom i una adreça IP per la gestió del clúster, que no seran les que s’han d’utilitzar pel clúster de SQL Server. En el meu cas, el clúster de gestió es dirà clustersql i tindrà la IP 192.168.1.213.

    La comanda per crear un nou clúster, amb un sol node (srvsql1core), sense fer el test dels discs, que ho farem més endavant, i visualitzant el resultat, és:

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

    Obtenim una advertència, però el nou clúster s’ha creat correctament. Comprovem-ho amb la comanda:

    Get-Cluster

    Afegim l’altre servidor (srvSQL2core) al clúster que s’acaba de crear:

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

    Comprovem que s’ha afegit correctament i està aixecat:

    Get-Cluster | Get-ClusterNode

    També comprovem els discs disponibles per utilitzar-los en el clúster, els que hem preparat a l’inici, exceptuant els dos d’aplicacions SQL que es queden a cada node.

    Get-ClusterResource

    Aquí si que està una mica liada la cosa. No sé exactament a on corresponen els discs, ja que apareixen com a Disco de clúster 1, 2, 3 i 4. Però quin correspon a quin?

    Comprovem primer quines lletres són i si són els correctes. Assignem el clúster a una variable:

    $cluster = Get-Cluster

    Recorrem els dos servidors buscant els seus discs, la capacitat, l’etiqueta i la unitat assignada, assignant-ho a una variable:

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

    Llistem el resultat de la variable:

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

    Per assegurar que utilitzem el disc correcte, podem esbrinar en quina partició està assignat el disc del recurs del clúster amb les següents comandes:

    Fixem el nom del disc que volem saber a quina partició pertany, per exemple “Disco de clúster 1”:

    $NombreRecursoDisco = "Disco de clúster 1"

    Esbrinem el recurs de disc:

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

    Esbrinem el disc dur associat:

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

    Esbrinem quina partició té aquest disc dur:

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

    I obtenim la ruta a la què està muntada la partició:

    $Partition | Select Path

    Assegurem que és la que desitgem i etiquetem el disc amb les comandes següents:

     

    Assignar el disc recurs del clúster a una variable:

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

    Canviar la propietat Name de l’objecte:

    $disk1.Name = "Witness"

    Repetir el procés pels altres discs:

    Esbrinar la unitat que té muntada el recurs 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

    Assignar el nom al disc:

    $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"

    Amb els discs de recursos de clúster identificats, procedim a configurar el disc de Witness del clúster. Establim tipus de Witness de nodes i majoria de disc, assignant el disc etiquetat com a Witness:

    set-ClusterQuorum -NodeAndDiskMajority "Witness"

    Comprovem que el recurs de disc ha passat a ser Witness:

    get-ClusterResource

    El recurs Witness ja pertany al grup de clúster.

    Ja només ens queda validar el clúster, requisit previ a la instal·lació del clúster alta disponibilitat SQL Server 2017:

    get-cluster | test-cluster

    Ens podem trobar alguna advertència, però NO errors per poder continuar amb la instal·lació. Revisant el fitxer que genera amb el report sortim de dubtes.

     

    Preparar els fitxers de la instal·lació desatesa del clúster alta disponibilitat SQL Server 2017

    Consisteix en la creació d’un fitxer amb extensió .INI amb els paràmetres de configuració del nou clúster. Podeu donar una ullada a l’explicació dels paràmetres generals a l’entrada sobre la instal·lació d’un SQL Server 2017 de forma desatesa. En aquesta ens centrem només als que fan referència al clúster.

    Primer node del clúster

    Fitxer pel primer servidor del clúster. On varia el tipus d’acció (ACTION), indicant que es tracta de crear un nou 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"

    Les opcions per la configuració del clúster s’especifiquen amb les següents comandes:

    Identificar els discs disponibles pel recurs de clúster de SQL Server, indicar els noms tal com apareixen a la comanda de Get-ClusterResources.

    FAILOVERCLUSTERDISKS="SQLdb" "SQLlogs" "SQLtempdb"

    Nom del grup de recursos del clúster de SQL Server. Posem SQL Server (MSSQLSERVER), per indicar que és un SQL Server i el nom de la instància, en aquest cas, la de defecte:

    FAILOVERCLUSTERGROUP="SQL Server (MSSQLSERVER)"

    L’adreça IP, amb la seva màscara i l’associació a la xarxa disponible en el clúster, que tindrà el recurs de clúster SQL. Per saber el nom exacte de la xarxa disponible en el clúster executeu la comanda Get-ClusterNetwork:

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

    Nom del clúster SQL, pel nom en que s’hi accedirà des de l’exterior:

    FAILOVERCLUSTERNETWORKNAME="SQL2k17"

    Directori per la instància del SQL Server. Aquest directori ha d’estar compartit en el clúster, per tant, seleccionem la unitat K. En instal·lacions en producció, s’aconsella que estigui en un altre volum dedicat a tal efecte. En aquesta entrada compartim la instància amb les bases de dades:

    INSTALLSQLDATADIR="K:"

    Directori per les còpies de seguretat de SQL Server. A l’igual que el directori de la instància, indicar un recurs compartit de xarxa o volum compartit entre els nodes.

    SQLBACKUPDIR="K:\MSSQL\Backup"

    L’apartat de configuració del clúster SQL quedaria de la següent forma, a afegir al final del fitxer de configuració:

    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"

     

    Segon node del clúster

    Fitxer pel següent servidor del clúster, on també varia el tipus d’acció (ACTION), indicant que es tracta d’un nou node pel clúster (AddNode). Aquest fitxer ja és molt més curt, ja que la majoria d’opcions es defineixen 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"

    I s’especifica en quin clúster s’afegeix el nou node, indicant el grup de recursos, la IP i el nom 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"

    Fitxers utilitzats:

     

    Configuració del tallafocs

    Abans de llançar la instal·lació, i perquè no se’ns oblidi i tinguem problemes de balanceig amb la instància de SQL Server, obrim els ports corresponents TCP 1433 i UDP 1434 en el tallafocs dels dos servidors:

    Obrir els ports TCP 1433 i UDP 1434

    Executar les comandes:

    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

    Comprovar que s’han creat les dues regles:

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

    Per deshabilitar les regles anteriors, en cas que fos necessari:

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

     

    Configuració de tallafocs a nivell del servei SQL

    En cas de fer-ho a nivell de servei i que l’executable es trobi a la ruta indicada, executar la comanda:

    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'

     

    Instal·lació del clúster alta disponibilitat SQL Server 2017 de forma desatesa

    Ja ho tenim tot preparat. Muntem la imatge de instal·lació del SQL Server i executem la comanda d’instal·lació desatesa en el primer servidor, proporcionant les contrasenyes corresponents als comptes de servei i a l’usuari administrador de SQL Server (sa); i el fitxer amb tots els paràmetres de configuració (node1.ini):

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

    Deixem que el sistema vagi fent ell sol. Un cop ha acabat es pot comprovar que s’ha creat correctament el rol amb la comanda:

    Get-ClusterResource

    Assegureu que els serveis de SQL Server estan en línia. També podeu comprovar que està operatiu realitzant una connexió amb l’SQL Management Studio. És un clúster d’un sol node, però el SQL Server ja és completament operatiu.

     

    És el torn d’instal·lar el segon servidor, que actuarà com a passiu. Amb la imatge de instal·lació del SQL Server muntada, executem la comanda indicant el nom del segon fitxer de configuració desatesa. Les contrasenyes del motor i l’agent també s’han de proporcionar ja què ha de registrar els serveis amb elles. La del SA no, perquè ja està establerta en el primer servidor:

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

    Amb la instal·lació completada correctament ara ja disposem d’un clúster alta disponibilitat SQL Server. Comprovem que es pot balancejar el servei de clúster del servidor srvSQL1core al servidors srvSQL2core:

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

    Podem veure com el propietari del recurs canvia a l’altre servidor. Comprovem que el recurs està aixecat:

    Get-ClusterResource *SQL*

    Han d’aparèixer els diferents recursos amb estat En línia.

    Tornem a connectar al SQL Server per comprovar que tot funciona, això sí, connectant al nom del recurs: SQL2k17.

    Com sabem en quin node esta treballant l’SQL Server? Bona pregunta! La resposta, executant les següents consultes:

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

    La primera ens mostra el nom del SQL (el recurs de clúster on s’ha de connectar tothom). La segona mostra el nom real del servidor que està executant l’SQL Server. En la foto, el clúster es troba executant-se en el node srvSQL2core.

    Movent el recurs del clúster de nou al node 1:

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

    I refrescant la consulta anterior, canvia el nom del servidor on s’està executant:

     

    I si ja no volem el node i es vol desinstal·lar?

    La comanda per desinstal·lar el rol SQL Server de la instància MSSQLSERVER del servidor del clúster és:

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

    Executant-la als dos nodes ens deixa un sense el SQL Server. Comprovem-ho llistant els recursos del clúster, on els discs tornen a estar disponibles i el grup d’SQL ha desaparegut:

    Get-ClusterResource

     

     

    T’ha agradat l’article? El pots compartir a les xarxes socials. També pots deixar la teva opinió, comentari o suggeriment. Gràcies!

    Similar Posts by The Author: