Creare un cluster

Questa sezione passi attraverso le attività di build necessarie per creare il WSFC (Windows Server Failover Cluster) e il gruppo di disponibilità.

Questa guida presuppone che tu:

  • Avere almeno due server che eseguono Windows 2019 e SQL Server 2019 a cluster.
  • Avere un bastione host con accesso Internet esterno.
  • Avere distribuito la directory attiva.

Installare la funzione Failover Clustering

  1. RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell.

  2. Aggiungere il gruppo SQL Admins al gruppo local Remote Management Users così gli utenti di questo gruppo, possono eseguire comandi remoti.

  3. Consente la porta TCP in entrata 5022 nel server in quanto questa porta viene utilizzata per il traffico di gruppo di disponibilità. Installare la funzione Failover Clustering e quindi riavviare il server:

    $domainnb = "<NB_Domain>"
    $group = $domainnb + "\SQLAdmins"
    Add-LocalGroupMember -Group "Remote Management Users" -Member $group
    New-NetFirewallRule -DisplayName 'SQL-AG-Inbound' -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 5022
    Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
    Restart-Computer -Force
    
  4. Ripetere per il secondo server SQL.

Creare un WSFC e abilitare SQL Always On

  1. RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell.

  2. Eseguire un test di convalida del cluster. Ignorare qualsiasi "una coppia di interfacce di rete" avvisi, in quanto questo è normale per questa distribuzione.

  3. Se non ci sono errori creano un cluster WSFC con un nome di wsfc01 che include i due server SQL <hostname1> e <hostname2>. L'opzione -ManagementPointNetworkType Distributed utilizza l'indirizzo IP del nodo del server virtuale che significa che l'indirizzamento IP secondario sull'interfaccia non è richiesto. Questa opzione crea un DNN (Distributed Network Name), che instrada il traffico verso l'appropriata risorsa clustered.

  4. Il quorum del cluster viene quindi configurato per Node e Maggiori disco utilizzando una condivisione di file su fs01, \\fs01\clusterwitness-wsfc01

    $sqldb01 = "<hostname1>"
    $sqldb02 = "<hostname2>"
    Test-Cluster -Node $sqldb01, $sqldb02
    New-Cluster -Name wsfc01 -Node $sqldb01, $sqldb02 -ManagementPointNetworkType Distributed
    Set-ClusterQuorum -NodeAndFileShareMajority \\fs01\clusterwitness-wsfc01
    Enable-SqlAlwaysOn -ServerInstance sqldb01, sqldb02 -Force
    

Questa attività non deve essere ripetuta sul secondo nodo

Crea una condivisione file

Il database da replicare deve essere eseguito e ripristinato nelle istanze secondarie, è necessaria una condivisione di file per facilitare questa operazione. Sul server bastione creare una directory e condividerla in modo da poter tenere un backup del database dal server SQL principale e ripristinato sul server SQL secondario. La directory e la condivisione devono essere accessibili dall'account SQL Service in quanto il backup viene eseguito dall'account di servizio per il database.

  1. Sull'host bastione, aprire una sessione PowerShell.

    $domainnb = "<NB_Domain>"
    $user = $domainnb + "\sqlsvc"
    New-Item -Path "C:\" -Name "TempShare" -ItemType "directory"
    $ACL=Get-ACL -Path "C:\TempShare"
    $AccessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($user,"FullControl","Allow")
    $ACL.SetAccessRule($AccessRule)
    $ACL | Set-Acl -Path "C:\TempShare"
    New-SmbShare -Name "TempShare" -Path "C:\TempShare" -FullAccess $user
    

Creare gli endpoint

  1. RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell.

  2. Per partecipare ai gruppi Always On availability, un'istanza server richiede il proprio endpoint, che utilizza la porta TCP 5022 per inviare e ricevere traffico tra le istanze server che ospitano repliche di disponibilità.

  3. I seguenti comandi PowerShell sono utilizzati per configurare questi endpoint, Hadr_endpoint sulle istanze SQL predefinite (DEFAULT) sui server SQL; <hostname1>`` and <hostname2> e abilita la crittografia tra gli endpoint:

    $sqldb01 = "<hostname1>"
    $sqldb02 = "<hostname2>"
    $domainnb = "<NB_Domain>"
    $user = $domainnb + "\sqlsvc"
    $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb01 + "\DEFAULT"
    $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb02 + "\DEFAULT"
    $endpoint1 = New-SqlHadrEndpoint Hadr_endpoint -Port 5022 -Path $pathsqldb01 -Encryption Required -EncryptionAlgorithm Aes -Owner $user
    Set-SqlHadrEndpoint -InputObject $endpoint1 -State "Started"
    $endpoint2 = New-SqlHadrEndpoint Hadr_endpoint -Port 5022 -Path $pathsqldb02 -Encryption Required -EncryptionAlgorithm Aes -Owner $user
    Set-SqlHadrEndpoint -InputObject $endpoint2 -State "Started"
    

Per concedere le autorizzazioni di connessione al servizio di dominio utilizzato dagli endpoint sono necessari i seguenti passaggi. Se questo passo non viene fatto, le porte endpoint non inizieranno e non appariranno in una elencazione netstat -a :

  1. Avviare SQL Server Management Studio (SSMS) sull'host di replica principale e collegarsi alla replica principale.
  2. Espandere Sicurezza, fare clic con il tasto destro del mouse e selezionare Nuovo Login.
  3. Fare clic su Ricerca e inserire l'account utente \sqlserver\sqlsvc, quindi fare clic su OK.
  4. Fare clic con il tasto destro del mouse sul login creato e selezionare Proprietà.
  5. Clicca su Securables e quindi Cerca.
  6. Nella finestra di dialogo Aggiungi oggetti selezionare oggetti specifici e fare clic su OK.
  7. Nella finestra di dialogo Seleziona oggetti, fare clic su Tipi di oggetti e selezionare Endpoints.
  8. Fare clic su Sfoglia per selezionare il nome oggetto.
  9. Selezionare Hadr_endpoint e fare clic su OK.
  10. Nel permesso per Hadr_endpoint, concedere esplicitamente il permesso di connessione a questo oggetto.

Creare un database di test

Per configurare un gruppo di disponibilità, un database deve essere disponibile sul nodo principale e quindi una copia di questo database disponibile sul nodo secondario. Questa attività crea un database di test e quindi utilizzando un'operazione di backup e ripristino, tramite una condivisione di file, copia il database sul nodo secondario.

  1. RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell. È importante impostare la modalità di ripristino a Full per i database utilizzati nei gruppi di disponibilità:

    $sql = "
    CREATE DATABASE [TestDatabase]
     CONTAINMENT = NONE
     ON  PRIMARY
    ( NAME = N'TestDatabase', FILENAME = N'D:\MSSQL15.MSSQLSERVER\MSSQL\DATA\TestDatabase.mdf' , SIZE = 1048576KB , FILEGROWTH = 262144KB )
     LOG ON
    ( NAME = N'MyDatabase_log', FILENAME = N'E:\MSSQL15.MSSQLSERVER\MSSQL\Logs\TestDatabase_log.ldf' , SIZE = 524288KB , FILEGROWTH = 131072KB )
    GO
    
    USE [master]
    GO
    ALTER DATABASE [TestDatabase] SET RECOVERY FULL
    GO
    
    ALTER AUTHORIZATION ON DATABASE::[TestDatabase] TO [sa]
    GO "
    Invoke-SqlCmd -ServerInstance sqldb01 -Query $sql
    
  2. Preparare il database secondario utilizzando i comandi Backup-SqlDatabase e Restore-SqlDatabase per creare un backup del TestDatabase su <hostname1> su TempShare su <file_share_host>, l'istanza del server SQL che ospita la replica principale. Ripristinare il backup su <hostname2>, che ospita la replica secondaria. Il parametro NoRecovery restore deve essere utilizzato.

    $sqldb01 = "<hostname1>"
    $sqldb02 = "<hostname2>"
    $filesharehost = "<file_share_host>"
    $backupfiledata = "\\" + $filesharehost +"\TempShare\TestDatabase.bak"
    $backupfilelog = "\\" + $filesharehost +"\TempShare\TestDatabase.trn"
    Backup-SqlDatabase -Database "TestDatabase" -ServerInstance $sqldb01 -BackupFile $backupfiledata -CopyOnly
    Backup-SqlDatabase -Database "TestDatabase" -BackupFile $backupfilelog -ServerInstance $sqldb01 -BackupAction Log -CopyOnly
    Restore-SqlDatabase -Database "TestDatabase" -BackupFile $backupfiledata -ServerInstance $sqldb02 -NoRecovery  
    Restore-SqlDatabase -Database "TestDatabase" -BackupFile $backupfilelog -ServerInstance $sqldb02 -RestoreAction Log -NoRecovery
    

Il nuovo database secondario è nello stato RIPRISTINO. Fino ad essere unito al gruppo di disponibilità, non è accessibile.

Creare un gruppo di disponibilità

I database aggiunti a un gruppo di disponibilità sono noti come database di disponibilità. Quando si aggiungono database, il database deve essere un database online, read-write ed esistere sull'istanza server che ospiterà la replica principale nel WSFC. Se aggiunto, il database si unisce al gruppo di disponibilità come database principale e rimane disponibile per i client. Nessun database secondario esiste fino a quando i backup del database principale vengono ripristinati sull'istanza del server che diventerà la replica secondaria. Il nuovo database secondario è nello stato RIPRISTINO finché non viene unito al gruppo di disponibilità. Fare riferimento a Utilizza seeding automatico per inizializzare una replica secondaria per un gruppo Always On disponibilità se il metodo di backup e ripristino non viene utilizzato.

  1. RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell.

  2. Per assicurarsi di non ottenere errori di percorso poi utilizzare Invoke-SQLCmd che costringe il caricamento della libreria SQL PowerShell che è poi accessibile tramite l'albero dell'unità PowerShell. PowerShell tratta gli oggetti in SQL Server simili ai file in una directory. Sostituire <hostname1> con il nome host del server SQL:

    invoke-sqlcmd
    cd SQLSERVER:\SQL\<hostname1>
    
  3. Per creare il gruppo di disponibilità, il comando New-SqlAvailabilityReplica con il parametro -AsTemplate, viene utilizzato per creare un oggetto di disponibilità in memoria - replica per ciascuna delle due repliche di disponibilità da inserire nel gruppo di disponibilità. Poi, il gruppo di disponibilità viene creato utilizzando il comando New-SqlAvailabilityGroup e facendo riferimento agli oggetti di replica di disponibilità. Il AutomatedBackupPreference Primary viene utilizzato per specificare che i backup devono sempre verificarsi sulla replica principale mentre -FailureConditionLevel OnCriticalServerErrors specifica che il failover automatico viene innescato quando si verifica un errore del server critico. È possibile utilizzare l'opzione -SeedingMode Automatic che consente il seeding diretto come questo metodo non richiede il backup e il ripristino di una copia del database principale. Per SQL 2019 il numero di versione è 15.

    Fare riferimento alla documentazione Nuovo - SqlDisponabilityGroup per le descrizioni di altri parametri.

    $sqldb01 = "<hostname1>"
    $sqldb02 = "<hostname2>"
    $sqldb01fqdn = "<fqdn1>"
    $sqldb02fqdn = "<fqdn2>"
    $endpointurl1 "TCP://" + $sqldb01fqdn + ":5022"
    $endpointurl2 "TCP://" + $sqldb02fqdn + ":5022"
    $pathsqldb01 = "SQLSERVER:\SQL\" + $sqldb01 +" \DEFAULT"
    $primaryReplica = New-SqlAvailabilityReplica -Name $sqldb01 -EndpointURL $endpointurl1 -AvailabilityMode "SynchronousCommit" -FailoverMode "Automatic" -Version 15 -AsTemplate  
    $secondaryReplica = New-SqlAvailabilityReplica -Name $sqldb02 -EndpointURL $endpointurl2 -AvailabilityMode "SynchronousCommit" -FailoverMode "Automatic" -Version 15 -AsTemplate
    New-SqlAvailabilityGroup -Name "AG01" -Path $pathsqldb01 -AvailabilityReplica @($primaryReplica,$secondaryReplica) -Database "TestDatabase" -ClusterType WSFC -AutomatedBackupPreference Primary -FailureConditionLevel OnCriticalServerErrors
    
  4. Unire la replica secondaria al gruppo di disponibilità con i seguenti comandi. Congiunge il database secondario nello stato ONLINE e inizializza la sincronizzazione dei dati con il database principale corrispondente. La sincronizzazione dei dati è il processo mediante il quale le modifiche ad un database principale vengono riprodotte su un database secondario. La sincronizzazione dei dati comporta il database principale che invia i record di registrazione delle transazioni al database secondario.

    $sqldb02 = "<hostname2>"
    $pathsqldb02 = "SQLSERVER:\SQL\" + $sqldb02 + " \DEFAULT"
    Join-SqlAvailabilityGroup -Path $pathsqldb02 -Name "AG01" -ClusterType WSFC
    
  5. Avviare la sincronizzazione dei dati congiungendo ogni database secondario al gruppo di disponibilità:

    $sqldb02 = "<hostname2>"
    $agpathsqldb02 = "SQLSERVER:\SQL\" + $sqldb02 + " \DEFAULT\AvailabilityGroups\AG01"
    Add-SqlAvailabilityDatabase -Path $agpathsqldb02 -Database "TestDatabase"
    
  6. Utilizzare il comando dir per verificare il contenuto del nuovo gruppo di disponibilità, ad esempio dir SQLSERVER:\SQL\sqldb01\DEFAULT\AvailabilityGroups\AG01.

Creare il nome di rete distribuito del gruppo di disponibilità

Con SQL Server su IBM Cloud VPC, il DNN (Distributed Network Name) indirizza il traffico verso l'appropriata risorsa clustered. Il listener (DNN) sostituisce il listener di gruppo di disponibilità VNN (Virtual Network Name) tradizionale quando utilizzato con i gruppi Always On disponibilità e semplifica la distribuzione in un ambiente cloud.

Gli ascoltatori DNN sono progettati per ascoltare una porta unica. La voce DNS per il nome del listener si risolverà in tutti gli indirizzi IP delle repliche nel gruppo di disponibilità. Dal momento che SQL Server ascolta la porta 1433, la porta 1433 non può essere utilizzata per nessun listener DNN.

RDP al primo server SQL che utilizza un utente dall'account di gruppo SQL Admins e apre una sessione PowerShell e utilizza i seguenti comandi; per creare una risorsa DNN con il nome di dnnlsnr-6789, configura DNS sul server DNS AD della risorsa DNN, avvia la risorsa DNN, aggiunge la dipendenza dalla risorsa del gruppo di disponibilità alla risorsa DNN e infine riimposta la risorsa del gruppo di disponibilità.

$ag = "AG01"
$dns = "dnnlsnr"
$port = "6789"
Add-ClusterResource -Name $port -ResourceType "Distributed Network Name" -Group $ag
Get-ClusterResource -Name $port | Set-ClusterParameter -Name DnsName -Value $dns
Start-ClusterResource -Name $port
$Dep = Get-ClusterResourceDependency -Resource $ag
if ( $Dep.DependencyExpression -match '\s*\((.*)\)\s*' ) {$DepStr = "$($Matches.1) or [$port]"} else {$DepStr = "[$port]"}
Set-ClusterResourceDependency -Resource $ag -Dependency "$DepStr"
Stop-ClusterResource -Name $ag
Start-ClusterResource -Name $ag

Utilizzare il seguente comando per consentire il TCP 6789 tramite il firewall di Windows:

New-NetFirewallRule -DisplayName 'SQL-dnnlsnr-6789-Inbound' -Profile Domain -Direction Inbound -Action Allow -Protocol TCP -LocalPort 6789