Rozwiązywanie problemów z awariami wystąpień klastra trybu failover programu SQL Server przy użyciu grupowych kont usług zarządzanych (gMSA)

Dotyczy: SQL Server w Windows

Podsumowanie

Ten artykuł pomaga rozwiązywać problemy z instalacją, dodawaniem węzła, uruchamianiem i przełączaniem awaryjnym wystąpienia klastra trybu failover (FCI) programu SQL Server, gdy usługa SQL Server jest uruchomiona na grupowym koncie usługi zarządzanej (gMSA). Obejmuje pobieranie zarządzanych haseł na każdym potencjalnym węźle właściciela, uprawnienia specyficzne dla węzła i parametry uruchamiania, nieukończony stan Setup oraz awarie zasobów klastra.

Przed rozpoczęciem zapoznaj się z wymaganiami wstępnymi i uruchom listę kontrolną szybkiego sprawdzania poprawności w temacie Rozwiązywanie problemów SQL Server z konfiguracją, uruchamianiem i błędami uwierzytelniania przy użyciu agentów gMSA.

Symptoms

  • Instalacja FCI nie powiedzie się podczas walidacji konta.
  • Operacja dodawania węzła zgłasza niespójne informacje dotyczące konta serwisowego.
  • SQL Server rozpoczyna się od wiersza polecenia, ale nie za pośrednictwem klastra.
  • Tryb failover kończy się niepowodzeniem, ponieważ brakuje parametrów uruchamiania lub konfiguracji specyficznych dla węzła.

Przyczyna

Awarie FCI mogą obejmować pobieranie haseł, niekompletne metadane instalacji, parametry uruchamiania specyficzne dla węzła, uprawnienia różniące się w zależności od węzła, dostęp do magazynu lub kontrole kondycji usługi klastra. Przyczyną specyficzną dla gMSA jest to, że co najmniej jeden z możliwych węzłów właściciela nie jest upoważniony do pobrania zarządzanego hasła, więc instancja działa na niektórych węzłach, a na innych kończy się niepowodzeniem.

Diagnozowanie awarii instancji klastra trybu failover

  1. Uruchom listę kontrolną szybkiej weryfikacji dla każdego możliwego węzła właściciela i porównaj wyniki.

    Uruchom następujące polecenia na każdym węźle, który może pełnić rolę właściciela.

    Test-ADServiceAccount -Identity 'SQLgMSA'
sc.exe qmanagedaccount MSSQLSERVER
Get-ClusterResource | Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

  2. Porównaj tożsamość usługi, stan konta zarządzanego, obowiązujące prawa i parametry uruchamiania między węzłami.

    Oczekiwany wynik:Test-ADServiceAccount na każdym możliwym węźle będącym właścicielem zwracane jest True, a konfiguracja usługi i parametry uruchamiania są spójne dla tego samego wystąpienia klastra trybu failover (FCI).

  3. Przejrzyj historię konfiguracji dla anulowanych lub nieukończonych operacji dodawania węzła.

  4. Zbierz dziennik błędów SQL Server i dziennik klastra dla tego samego przejścia zasobów.

    Wygeneruj dziennik klastra, uruchamiając następujące polecenie.

    Get-ClusterLog -UseLocalTime -Destination C:\Temp

Rozwiązywanie problemów z błędami wystąpienia klastra trybu failover

Użyj rozwiązania zgodnego z dowodami z kroków diagnostycznych.

Autoryzowanie każdego możliwego węzła właściciela w celu pobrania hasła zarządzanego

Nadaj uprawnienia każdemu potencjalnemu węzłowi właściciela do pobrania zarządzanego hasła, a następnie ponownie przetestuj przełączanie awaryjne dla każdego węzła. Jeśli gMSA autoryzuje poszczególne konta komputerów, Set-ADServiceAccount zastępuje pełną listę autoryzowanych podmiotów zabezpieczeń. Najpierw sprawdź bieżącą wartość i uwzględnij każdy podmiot, który musi zachować uprawnienia.

# Review the gMSA configuration
Get-ADServiceAccount -Identity "SQLgMSA" `
    -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

# If individual computer accounts are used, authorize each possible owner node
Set-ADServiceAccount -Identity "SQLgMSA" `
    -PrincipalsAllowedToRetrieveManagedPassword "NODE1$","NODE2$","NODE3$"

# Verify the gMSA from each possible owner node
Invoke-Command -ComputerName NODE1,NODE2,NODE3 {
    Test-ADServiceAccount -Identity "SQLgMSA"
}

Jeśli grupa zabezpieczeń autoryzuje gMSA, dodaj do niej możliwe węzły właściciela zamiast zastępować istniejące podmioty zabezpieczeń gMSA.

Add-ADGroupMember -Identity "SQL-FCI-gMSA-Nodes" `
    -Members "NODE1$","NODE2$","NODE3$"

Aby uzyskać więcej informacji, zapoznaj się z następującymi artykułami:

Skoryguj uprawnienia właściwe dla węzła, parametry uruchamiania lub niekompletny stan Setup

Popraw potwierdzone uprawnienia specyficzne dla węzła, parametry uruchamiania lub niekompletny stan konfiguracji. Uruchom następujące polecenia w każdym węźle i porównaj wyniki. Zastąp <InstanceID> element identyfikatorem wystąpienia, takim jak MSSQL16.MSSQLSERVER.

# Verify the SQL Server service account on each node
Get-CimInstance Win32_Service -Filter "Name='MSSQLSERVER'" |
    Select-Object Name, StartName, State, StartMode

# Compare SQL Server startup parameters on each node
reg query "HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceID>\MSSQLServer\Parameters"

# Check the SQL Server Windows service configuration
sc.exe qc MSSQLSERVER

Użyj SQL Server Configuration Manager, aby poprawić różnice parametrów uruchamiania zamiast ręcznie edytować rejestr. Aby uzyskać więcej informacji, zapoznaj się z następującymi artykułami:

Jeśli awaria zasobu klastra nie jest powiązana z kontem usługi, użyj następujących poleceń, aby przejrzeć role klastrowane, zasoby klastra i dziennik klastra.

# List clustered roles and their current owner/state
Get-ClusterGroup

# List cluster resources and their current state
Get-ClusterResource |
    Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

# Identify SQL Server-related cluster resources
Get-ClusterResource |
    Where-Object { $_.ResourceType -like "*SQL*" } |
    Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

# Generate cluster logs
New-Item -ItemType Directory -Path "C:\ClusterLogs" -Force
Get-ClusterLog -UseLocalTime -Destination "C:\ClusterLogs"

Moduł FailoverClusters PowerShell udostępnia polecenia cmdlet Get-ClusterGroup, Get-ClusterResource i Get-ClusterLog. Aby uzyskać więcej informacji na temat tych cmdletów, zobacz następujące artykuły:

Aby uzyskać informacje o błędach specyficznych dla SQL Server, zobacz następujące artykuły:

Utwórz ponownie brakujące klucze rejestru specyficzne dla zasobów

Aby ponownie utworzyć brakujące klucze rejestru specyficzne dla zasobów, wykonaj kroki opisane w temacie Ręczne ponowne tworzenie kluczy rejestru specyficznych dla zasobów. Przed wprowadzeniem udokumentowanych zmian rejestru zidentyfikuj zasoby klastra SQL Server i utwórz kopię zapasową rejestru klastra.

# Identify the SQL Server cluster resources
Get-ClusterResource |
    Where-Object { $_.ResourceType -like "*SQL*" } |
    Format-Table Name, ResourceType, State, OwnerGroup

# Back up the cluster registry before making documented registry changes
New-Item -ItemType Directory -Path "C:\Temp" -Force
reg export "HKLM\Cluster" "C:\Temp\ClusterRegistryBackup.reg" /y

Caution

Nie kopiuj wartości rejestru między niepowiązanymi wystąpieniami. Przed wprowadzeniem zmiany sprawdź identyfikator wystąpienia, ścieżki magazynu współdzielonego, rolę klastrową i węzeł.

Zbieranie danych diagnostycznych

Jeśli problem nadal będzie występować po wykonaniu tych kroków, zbierz dane diagnostyczne z każdego węzła, który może być właścicielem, w tym dziennik klastra dotyczący tego samego przejścia zasobu. Informacje o danych specyficznych dla gMSA i standardowych dziennikach programu SQL Server, które należy zebrać, można znaleźć w sekcji Zbieranie danych diagnostycznych w omówieniu rozwiązywania problemów z usługą gMSA. Użyj tych danych, aby kontynuować dochodzenie lub otworzyć zgłoszenie do działu pomocy technicznej.

Treści powiązane

  • Ostatnia aktualizacja o