Configurare il cluster di dischi condivisi SLES per SQL Server
Si applica a:
SQL Server - Linux
Questa guida fornisce istruzioni per la creazione di un cluster di dischi condivisi a due nodi per SQL Server in SLES (SUSE Linux Enterprise Server). Il livello di clustering si basa su SUSE High Availability Extension (HAE), a sua volta basato su Pacemaker.
Per altre informazioni su configurazione dei cluster, opzioni degli agenti delle risorse, gestione, procedure consigliate e suggerimenti, vedere SUSE Linux Enterprise High Availability Extension 12 SP2.
Prerequisiti
Per completare lo scenario end-to-end seguente, sono necessari due computer per distribuire il cluster a due nodi e un altro server per configurare la condivisione NFS. I passaggi seguenti illustrano come verranno configurati questi server.
Installare e configurare il sistema operativo in ogni nodo del cluster
Il primo passaggio consiste nel configurare il sistema operativo nei nodi del cluster. Per questa procedura dettagliata, usare SLES con una sottoscrizione valida per il componente aggiuntivo a disponibilità elevata.
Installare e configurare SQL Server in ogni nodo del cluster
Installare e configurare SQL Server in entrambi i nodi. Per istruzioni dettagliate, vedere Installare SQL Server in Linux.
Designare un nodo come primario e l'altro come secondario, ai fini della configurazione. Usare questi termini per la parte seguente di questa guida.
Nel nodo secondario arrestare e disabilitare SQL Server. L'esempio seguente arresta e disabilita SQL Server:
sudo systemctl stop mssql-server sudo systemctl disable mssql-serverNota
In fase di configurazione, viene generata una chiave master del server per l'istanza di SQL Server e viene inserita in
/var/opt/mssql/secrets/machine-key. In Linux, SQL Server viene sempre eseguito come account locale denominato mssql. Poiché si tratta di un account locale, l'identità non è condivisa tra i nodi. È quindi necessario copiare la chiave di crittografia dal nodo primario a ogni nodo secondario, in modo che ogni account mssql locale possa accedervi per decrittografare la chiave master del server.Nel nodo primario creare un account di accesso di SQL Server per Pacemaker e concedere l'autorizzazione di accesso per eseguire
sp_server_diagnostics. Pacemaker usa questo account per verificare quale nodo sta eseguendo SQL Server.sudo systemctl start mssql-serverConnettersi al database
masterdi SQL Server con l'account “sa” ed eseguire i comandi seguenti:USE [master] GO CREATE LOGIN [<loginName>] with PASSWORD= N'<loginPassword>' GRANT VIEW SERVER STATE TO <loginName>Nel nodo primario arrestare e disabilitare SQL Server.
Seguire le istruzioni della documentazione SUSE per configurare e aggiornare il file hosts per ogni nodo del cluster. Il file "hosts" deve includere l'indirizzo IP e il nome di ogni nodo del cluster.
Per controllare l'indirizzo IP del nodo corrente, eseguire:
sudo ip addr showImpostare il nome computer in ogni nodo. Assegnare a ogni nodo un nome univoco di 15 caratteri o meno. Per impostare il nome computer, aggiungerlo a
/etc/hostnameusando YAST o manualmente.L'esempio seguente mostra
/etc/hostscon l'aggiunta di due nodi denominatiSLES1eSLES2.127.0.0.1 localhost 10.128.18.128 SLES1 10.128.16.77 SLES2Tutti i nodi del cluster devono poter accedere l'uno all'altro tramite SSH. Strumenti come hb_report o crm_report (per la risoluzione dei problemi) e History Explorer di Hawk richiedono l'accesso a SSH tra i nodi senza password, in caso contrario possono raccogliere dati solo dal nodo corrente. Nel caso in cui si usi una porta SSH non standard, usare l'opzione -X. Vedere la pagina di manuale. Se, ad esempio, la porta SSH è 3479, richiamare un oggetto crm_report con:
crm_report -X "-p 3479" [...]Per altre informazioni, vedere la guida all'amministrazione.
Nella sezione successiva si configurerà la risorsa di archiviazione condivisa, in cui verranno spostati i file di database.
Configurare la risorsa di archiviazione condivisa e spostare i file di database
Sono disponibili varie soluzioni per fornire spazio di archiviazione condiviso. Questa procedura dettagliata illustra la configurazione dello spazio di archiviazione condiviso con NFS. È opportuno seguire le procedure consigliate e usare Kerberos per proteggere NFS:
Se non ci si attiene al materiale sussidiario, chiunque possa accedere alla rete ed effettuare lo spoofing dell'indirizzo IP di un nodo SQL, riuscirà ad accedere ai file di dati. Come sempre, assicurarsi di creare un modello di rischio per il sistema prima di usarlo nell'ambiente di produzione.
Un'altra opzione di archiviazione consiste nell'usare la condivisione file SMB:
Configurare un server NFS
Per configurare un server NFS, vedere i passaggi seguenti nella documentazione di SUSE: Configuring NFS Server.
Configurare tutti i nodi del cluster per la connessione alla risorsa di archiviazione condivisa NFS
Prima di configurare il client NFS per montare il percorso dei file di database di SQL Server in modo da puntare alla posizione di archiviazione condivisa, assicurarsi di salvare i file di database in un percorso temporaneo per poterli copiare in un secondo momento nella condivisione:
Solo nel nodo primario salvare i file di database in una posizione temporanea. Lo script seguente crea una nuova directory temporanea, copia i file di database nella nuova directory e rimuove i file di database obsoleti. Poiché SQL Server viene eseguito come utente locale mssql, è necessario assicurarsi che dopo il trasferimento dei dati alla condivisione montata, l'utente locale abbia accesso in lettura/scrittura alla condivisione.
su mssql mkdir /var/opt/mssql/tmp cp /var/opt/mssql/data/* /var/opt/mssql/tmp rm /var/opt/mssql/data/* exitConfigurare il client NFS in tutti i nodi del cluster:
Nota
È consigliabile seguire le procedure consigliate di SUSE e le raccomandazioni relative all'archiviazione NFS a disponibilità elevata: Highly Available NFS Storage with DRBD and Pacemaker.
Verificare che SQL Server venga avviato correttamente con il nuovo percorso del file. Eseguire questa operazione in ogni nodo. A questo punto, un solo nodo alla volta eseguirà SQL Server. Non possono essere eseguiti contemporaneamente perché entrambi proveranno ad accedere ai file di dati simultaneamente. Per evitare l'avvio accidentale di SQL Server in entrambi i nodi, usare una risorsa cluster del file system per assicurarsi che la condivisione non venga montata due volte da nodi diversi. I comandi seguenti avviano SQL Server, controllano lo stato e quindi arrestano SQL Server.
sudo systemctl start mssql-server sudo systemctl status mssql-server sudo systemctl stop mssql-server
A questo punto, entrambe le istanze di SQL Server sono configurate per l'esecuzione con i file di database nello spazio di archiviazione condiviso. Il passaggio successivo consiste nel configurare SQL Server per Pacemaker.
Installare e configurare Pacemaker in ogni nodo del cluster
In entrambi i nodi del cluster creare un file per archiviare nome utente e password di SQL Server per l'accesso a Pacemaker. Il comando seguente crea e popola questo file:
sudo touch /var/opt/mssql/secrets/passwd sudo echo '<loginName>' >> /var/opt/mssql/secrets/passwd sudo echo '<loginPassword>' >> /var/opt/mssql/secrets/passwd sudo chown root:root /var/opt/mssql/secrets/passwd sudo chmod 600 /var/opt/mssql/secrets/passwdTutti i nodi del cluster devono essere in grado di accedere uno all'altro tramite SSH. Strumenti come hb_report o crm_report (per la risoluzione dei problemi) e History Explorer di Hawk richiedono l'accesso a SSH tra i nodi senza password, in caso contrario possono raccogliere dati solo dal nodo corrente. Nel caso in cui si usi una porta SSH non standard, usare l'opzione -X. Vedere la pagina di manuale. Se, ad esempio, la porta SSH è 3479, richiamare un oggetto hb_report con:
crm_report -X "-p 3479" [...]Per altre informazioni, vedere i requisiti di sistema e consigli nella documentazione di SUSE.
Installare l'estensione per la disponibilità elevata. Per installare l'estensione, seguire la procedura nell'articolo SUSE seguente:
Installation and Setup Quick Start (Guida introduttiva all'installazione e alla configurazione)
Installare l'agente delle risorse FCI per SQL Server. Eseguire i comandi seguenti in entrambi i nodi:
sudo zypper addrepo -fc https://packages.microsoft.com/config/sles/12/mssql-server-2017.repo sudo zypper --gpg-auto-import-keys refresh sudo zypper install mssql-server-haConfigurare automaticamente il primo nodo. Il passaggio successivo consiste nel configurare un cluster a un nodo in esecuzione configurando il primo nodo, SLES1. Seguire le istruzioni nell'articolo SUSE Setting Up the First Node (Configurazione del primo nodo).
Al termine, verificare lo stato del cluster con
crm status:crm statusDovrebbe indicare che il nodo, SLES1, è configurato.
Aggiungere nodi a un cluster esistente. Aggiungere quindi il nodo SLES2 al cluster. Seguire le istruzioni nell'articolo SUSE Adding the Second Node (Aggiunta del secondo nodo).
Al termine, verificare lo stato del cluster con crm status. Se il secondo nodo è stato aggiunto correttamente, l'output sarà simile al seguente:
2 nodes configured 1 resource configured Online: [ SLES1 SLES2 ] Full list of resources: admin_addr (ocf::heartbeat:IPaddr2): Started SLES1Nota
admin_addr è la risorsa cluster IP virtuale configurata durante l'installazione iniziale del cluster a un nodo.
Procedure di rimozione. Se si vuole rimuovere un nodo dal cluster, usare lo script di bootstrap ha-cluster-remove. Per altre informazioni, vedere Overview of the Bootstrap Scripts (Panoramica degli script di bootstrap).
Configurare le risorse cluster per SQL Server
I passaggi seguenti illustrano come configurare la risorsa cluster per SQL Server. Sono presenti due impostazioni che è necessario personalizzare.
- Nome risorsa SQL Server: nome della risorsa SQL Server cluster.
- Valore timeout: il valore di timeout indica per quanto tempo il cluster attende mentre una risorsa viene portata online. Per SQL Server, corrisponde al tempo previsto perché SQL Server porti online il database
master.
Aggiornare i valori dello script seguente per il proprio ambiente. Eseguire su un nodo per configurare e avviare il servizio in cluster.
sudo crm configure
primitive <sqlServerResourceName> ocf:mssql:fci op start timeout=<timeout_in_seconds>
colocation <constraintName> inf: <virtualIPResourceName> <sqlServerResourceName>
show
commit
exit
Lo script seguente, ad esempio, crea una risorsa in cluster di SQL Server denominata mssqlha.
sudo crm configure
primitive mssqlha ocf:mssql:fci op start timeout=60s
colocation admin_addr_mssqlha inf: admin_addr mssqlha
show
commit
exit
Una volta eseguito il commit della configurazione, SQL Server verrà avviato nello stesso nodo della risorsa IP virtuale.
Per altre informazioni, vedere Configuring and Managing Cluster Resources (Command Line) (Configurazione e gestione delle risorse cluster - Riga di comando).
Verificare che SQL Server sia avviato.
Per verificare che SQL Server sia avviato, eseguire il comando crm status:
crm status
Gli esempi seguenti illustrano i risultati quando Pacemaker è stato avviato correttamente come risorsa cluster.
2 nodes configured
2 resources configured
Online: [ SLES1 SLES2 ]
Full list of resources:
admin_addr (ocf::heartbeat:IPaddr2): Started SLES1
mssqlha (ocf::mssql:fci): Started SLES1
Gestire le risorse cluster
Per gestire le risorse cluster, vedere l'articolo di SUSE seguente: Managing Cluster Resources (Gestione di risorse cluster)
Failover manuale
Nonostante le risorse siano configurate per effettuare automaticamente il failover (o la migrazione) ad altri nodi del cluster in caso di errore hardware o software, è anche possibile spostare manualmente una risorsa in un altro nodo del cluster usando l'interfaccia utente grafica di Pacemaker o la riga di comando.
Per questa attività usare il comando migrate. Ad esempio, per eseguire la migrazione della risorsa SQL a un nodo del cluster denominato SLES2, eseguire:
crm resource
migrate mssqlha SLES2
Contenuto correlato
- SUSE Linux Enterprise High Availability Extension - Administration Guide (SUSE Linux Enterprise High Availability Extension - Guida all'amministrazione)
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per