Risoluzione dei problemi relativi al clustering di failover

Articolo
04/26/2023

Si applica a:SQL Server

In questo argomento sono disponibili informazioni sugli argomenti seguenti:

Procedura di base per la risoluzione dei problemi.
Recupero da un errore del clustering di failover.
Risoluzione dei problemi più comuni relativi al clustering di failover.
Utilizzo di stored procedure estese e di oggetti COM.

Procedura di base per la risoluzione dei problemi

La prima attività di diagnostica è l'esecuzione del controllo di convalida sul cluster aggiornato. Per informazioni dettagliate sulla convalida, vedere Creare un cluster di failover: convalidare la configurazione. Il controllo può essere completato senza interruzione del servizio, poiché non ha effetto sulle risorse cluster in linea. La convalida può essere eseguita in qualsiasi momento dopo aver installato la funzionalità Clustering di failover, ovvero prima della distribuzione del cluster, durante la sua creazione e mentre il cluster è in esecuzione. In effetti mentre il cluster è in uso vengono eseguiti altri test, che verificano la corretta adozione delle procedure consigliate per i carichi di lavoro a disponibilità elevata. Delle decine di test eseguiti, solo alcuni hanno impatto sui carichi di lavoro del cluster in esecuzione. e rientrano tutti nella categoria di archiviazione, pertanto ignorare l'intera categoria è un modo pratico per evitare test che possono causare interruzioni.
Il clustering di failover prevede una misura di protezione integrata che evita tempi di inattività imprevisti quando si eseguono test di archiviazione durante la convalida. Se il cluster presenta gruppi online all'avvio della convalida e i test di archiviazione restano selezionati, all'utente verrà chiesto di confermare l'esecuzione di tutti i test o di ignorare il test dei dischi di tutti i gruppi in linea, per evitare tempi di inattività. Se l'intera categoria di archiviazione è stata esclusa dal test, il messaggio non viene visualizzato. In questo modo la convalida del cluster avviene senza tempi di inattività.

Procedura di riconvalida del cluster

Nell'albero della console dello snap-in Cluster di Failover, assicurarsi che l'opzione Gestione Cluster di failover sia selezionata e quindi selezionare Convalida una configurazionein Gestione.
Seguire le istruzioni della procedura guidata per specificare i server e i test ed eseguire i test. Successivamente all'esecuzione dei test viene visualizzata la pagina Riepilogo.
Nella pagina Riepilogo fare clic su Visualizza report per visualizzare i risultati del test.

Per visualizzare i risultati dopo aver chiuso la procedura guidata, vedere %SystemRoot%\Cluster\Reports\Validation Report Data e ora.html dove % SystemRoot % rappresenta la cartella in cui è installato il sistema operativo, ad esempio C:\Windows.
Per visualizzare gli argomenti della Guida che consentono di interpretare i risultati, fare clic su Ulteriori informazioni sui test di convalida dei cluster.

Per visualizzare gli argomenti della Guida relativi alla convalida dei cluster dopo aver chiuso la procedura guidata, nello snap-in Cluster di failover fare clic su ?, Guida, selezionare la scheda Contenuto , espandere il contenuto della Guida per il cluster di failover e quindi fare clic su Convalida della configurazione di un cluster di failover. Al termine della procedura guidata di convalida, i risultati verranno visualizzati nel Report di riepilogo . Tutti i test devono essere superati con un segno di spunta verde o, in alcuni casi, un triangolo giallo di avviso. Quando si esaminano aree relative a problemi (X rosse o punti interrogativi gialli) nella parte del report che riepiloga i risultati del test, fare clic su un singolo test per esaminare i dettagli. Tutti i problemi segnalati con una X rossa devono essere risolti prima di passare alla risoluzione dei problemi di SQL Server.

Installare gli aggiornamenti

L'installazione degli aggiornamenti è importante per prevenire i problemi del sistema. Collegamenti utili:

Recupero da un errore del clustering di failover

Sono in genere due le cause di un errore del clustering di failover:

Errore hardware in uno dei nodi di un cluster a due nodi. L'errore hardware può essere causato dal danneggiamento della scheda SCSI o da un errore del sistema operativo.

Per eseguire il recupero in presenza di questo errore, utilizzare il programma di installazione di SQL Server per rimuovere il nodo bloccato dal cluster di failover, risolvere il problema hardware con il computer offline, ripristinare il computer, quindi aggiungere nuovamente il nodo riparato all'istanza del cluster di failover.

Per altre informazioni, vedere Creare un nuovo cluster di failover di SQL Server (programma di installazione) e Recuperare da un errore dell'istanza del cluster di failover.
Errore del sistema operativo. In questo caso, il nodo è offline ma è irrimediabilmente danneggiato.

Per eseguire il recupero in presenza di un errore del sistema operativo, recuperare il nodo e testare il cluster di failover. Se il failover dell'istanza di SQL Server non viene eseguito correttamente, è necessario utilizzare il programma SQL Server Setup per rimuovere SQL Server dal cluster di failover, apportare le necessarie correzioni, ripristinare il computer, quindi aggiungere nuovamente il nodo riparato all'istanza del cluster di failover.

L'utilizzo di questa procedura per eseguire il recupero in presenza di un errore del sistema operativo può richiedere tempo. Se è possibile eseguire il recupero in modo più agevole, evitare di utilizzare questa tecnica.

Per altre informazioni, vedere Creare un nuovo cluster di failover di SQL Server (programma di installazione) e Procedura: Recuperare da un errore dell'istanza del cluster di failover nello scenario 2.

Risoluzione di problemi comuni

Di seguito vengono elencati alcuni problemi comuni relativi all'utilizzo e le rispettive modalità di risoluzione.

Problema: uso non corretto della sintassi del prompt dei comandi per installare SQL Server

Problema 1 : è difficile diagnosticare problemi di installazione quando si usa l'opzione /qn dal prompt dei comandi, perché tale opzione determina l'eliminazione di tutte le finestre di dialogo dell'interfaccia utente e dei messaggi di errore del programma di installazione. Se l'opzione /qn viene specificata, tutti i messaggi del programma di installazione, compresi i messaggi di errore, vengono inseriti nei file di log del programma. Per altre informazioni sui file di log, vedere Visualizzare e leggere i file di log del programma di installazione di SQL Server.

Risoluzione 1: usare l'opzione /qb anziché l'opzione /qn . Se si usa l'opzione /qb , per ogni passaggio verrà visualizzata l'interfaccia utente di base, inclusi i messaggi di errore.

Problema: SQL Server non è in grado di accedere alla rete dopo la migrazione in un altro nodo

Problema 1: gli account del servizio SQL Server non riescono a contattare un controller di dominio.

Risoluzione 1: controllare la presenza di problemi di rete, quali errori della scheda o problemi DNS, nei log eventi. Verificare che sia possibile effettuare il ping del controller di dominio.

Problema 2: le password degli account del servizio SQL Server non sono identiche in tutti i nodi del cluster oppure il nodo non riavvia un servizio SQL Server di cui è stata eseguita la migrazione da un nodo con errori.

Risoluzione 2: modificare le password dell'account del servizio SQL Server tramite Gestione configurazione SQL Server. In caso contrario, se si modificano le password dell'account del servizio SQL Server in un nodo, sarà necessario modificare le password anche in tutti gli altri nodi. Gestione configurazione SQL Server effettua automaticamente questa operazione.

Problema: SQL Server non è in grado di accedere ai dischi del cluster

Problema 1: il firmware o i driver non sono aggiornati in tutti i nodi.

Risoluzione 1: verificare che in tutti i nodi vengano utilizzate le versioni corrette del firmware e le stesse versioni del driver.

Problema 2: un nodo non è in grado di recuperare i dischi del cluster di cui è stata eseguita la migrazione da un nodo bloccato in un disco cluster condiviso che utilizza una diversa lettera di unità.

Risoluzione 2: le lettere di unità disco dei dischi del cluster devono essere identiche su entrambi i server. In caso contrario, modificare l'installazione originale del sistema operativo e del servizio cluster (MSCS, Microsoft Cluster Service).

Problema: un servizio SQL Server in errore determina il failover

Risoluzione: per impedire che un errore in servizi specifici determini il failover del gruppo SQL Server, configurare i servizi tramite Amministrazione cluster in Windows, come descritto di seguito:

Deselezionare la casella di controllo Influisce sul gruppo nella scheda Avanzate della finestra di dialogo Proprietà full-text . Se tuttavia SQL Server causa un failover, il servizio Ricerca full-text verrà riavviato.

Problema: SQL Server non viene avviato automaticamente

Risoluzione: per avviare automaticamente un cluster di failover, utilizzare Amministrazione cluster in MSCS. Impostare il servizio SQL Server per l'avvio manuale. Configurare inoltre Amministrazione cluster in MSCS per l'avvio del servizio SQL Server. Per altre informazioni, vedere Gestione dei servizi.

Problema: il nome di rete è offline e non è possibile connettersi a SQL Server tramite TCP/IP

Problema 1: DNS non è disponibile e la risorsa del cluster è impostata in modo da richiedere DNS.

Risoluzione 1: Risolvere i problemi relativi a DNS.

Problema 2: nella rete è presente un nome duplicato.

Risoluzione 2: utilizzare NBTSTAT per individuare il nome duplicato e risolvere il problema.

Problema 3: SQL Server non esegue la connessione tramite named pipe.

Risoluzione 3: per la connessione tramite named pipe, creare un alias utilizzando Gestione configurazione SQL Server per connettersi al computer appropriato. Se, ad esempio, si usa un cluster con due nodi (Nodo A e Nodo B) e un'istanza del cluster di failover (Virtsql) con un'istanza predefinita, è possibile seguire la procedura seguente per connettersi al server la cui risorsa Nome di rete è offline:

Utilizzare Amministrazione cluster per determinare il nodo in cui è esecuzione il gruppo che contiene l'istanza di SQL Server. In questo esempio si tratta del nodo Node A.
Avviare il servizio SQL Server nel computer tramite net start. Per altre informazioni sull'uso di net start, vedere Avvio manuale di SQL Server.
Avviare Gestione configurazione SQL Server di SQL Server su Nodo A. Visualizzare il nome della pipe sulla quale il server è in attesa. Il nome dovrebbe avere il formato seguente: \\.\$$\VIRTSQL\pipe\sql\query.
Sul computer client, avviare Gestione configurazione SQL Server.
Creare l'alias SQLTEST1 per connettersi alla pipe tramite named pipe. A tale scopo, immettere Nodo A come nome del server e modificare il nome della pipe in \\.\pipe\$$\VIRTSQL\sql\query.
Connettersi all'istanza utilizzando l'alias SQLTEST1 come nome del server.

Problema: impossibile installare SQL Server in un cluster con errore 11001

Problema : Chiave orfana del Registro di sistema in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster]

Risoluzione: accertarsi che l'hive del Registro di sistema MSSQL.X non sia attualmente in uso, quindi eliminare la chiave relativa al cluster.

Problema: errore di installazione del cluster: "Privilegi insufficienti per accedere alla directory: <unità>\Microsoft SQL Server. Accedere come amministratore oppure contattare l'amministratore del sistema"

Problema: questo errore è causato da un'unità condivisa SCSI non partizionata correttamente.

Risoluzione : usare la procedura seguente per ricreare una singola partizione nel disco condiviso:

Eliminare la risorsa disco dal cluster.
Eliminare tutte le partizioni presenti nel disco.
Nelle proprietà del disco verificare che si tratta di un disco di base.
Creare un'unica partizione nel disco condiviso, formattare il disco e assegnarvi una lettera di unità.
Aggiungere il disco al cluster tramite Amministrazione cluster (cluadmin).
Eseguire l'installazione di SQL Server.

Problema: le applicazioni non sono in grado di integrare le risorse di SQL Server in una transazione distribuita

Problema:Microsoft Distributed Transaction Coordinator (MS DTC) non è completamente configurato in Windows, quindi è possibile che le applicazioni non possano visualizzare l'elenco delle risorse SQL Server in una transazione distribuita. Questo problema può interessare server collegati, query distribuite e stored procedure remote che utilizzano transazioni distribuite. Per ulteriori informazioni sulla configurazione di MS DTC, vedere Before Installing Failover Clustering.

Risoluzione: per evitare tali problemi, è necessario abilitare completamente i servizi MS DTC nei server in cui è installato SQL Server e MS DTC è configurato.

Per abilitare completamente MS DTC, effettuare le operazioni seguenti:

Nel Pannello di controllo aprire Strumenti di amministrazionee quindi Gestione computer.
Nel riquadro sinistro di Gestione computer espandere Servizi e applicazionie quindi fare clic su Servizi.
Nel riquadro destro di Gestione computer fare clic con il pulsante destro del mouse su Distributed Transaction Coordinatore quindi scegliere Proprietà.
Nella finestra Distributed Transaction Coordinator fare clic sulla scheda Generale e quindi su Arresta per arrestare il servizio.
Nella finestra Distributed Transaction Coordinator fare clic sulla scheda Connessione e impostare l'account di accesso NT AUTHORITY\NetworkService.
Fare clic su Applica e quindi su OK per chiudere la finestra Distributed Transaction Coordinator . Chiudere la finestra Gestione computer . Chiudere la finestra Strumenti di amministrazione .

Utilizzo delle stored procedure estese e degli oggetti COM

Le stored procedure estese con un clustering di failover devono essere installate in un disco del cluster dipendente da SQL Server. In tal modo quando un nodo cede il controllo a un altro nodo mediante il failover, sarà comunque possibile utilizzare le stored procedure estese.

Se le stored procedure estese utilizzano componenti COM, l'amministratore dovrà registrare i componenti COM in ogni nodo del cluster. Per consentire la creazione dei componenti COM, le informazioni per il caricamento e l'esecuzione dei componenti stessi devono trovarsi nel Registro di sistema del nodo attivo. In caso contrario, le informazioni resteranno nel Registro di sistema del computer in cui i componenti COM sono stati registrati per la prima volta.

Vedi anche

Visualizzare e leggere i file di log del programma di installazione di SQL Server
Funzionamento delle stored procedure estese
Caratteristiche dell'esecuzione di stored procedure estese