Felsökningsvägledning för problem med att klustertjänsten inte kan starta
Checklista för felsökning
Kontrollera portarna som klustertjänsten använder
Kontrollera att följande portar är öppna för klustertrafik på alla brandväggar:
Port 135: RPC-slutpunktsmappare (Remote Procedure Call) eller DCOM (Distributed Component Object Model).
Port 135: RPC-slutpunktsmappning över användardatagramprotokoll (UDP).
Port 3343: Klusternätverksdrivrutin.
Port 445: Servermeddelandeblock (SMB).
Port 139: NetBIOS-sessionstjänst.
Portar mellan 5 000 och 5 099: Om händelse-ID 1721 loggas när du ansluter till ett kluster som klusteradministratör kan du försöka öppna portarna i det här intervallet (eller andra portar) för RPC-trafik. Portarna stöder kommunikation via RPC om du inte bara skriver ett periodtecken (.).
Det här problemet kan inträffa eftersom klustertjänsten använder minst 100 portar för RPC-kommunikation. Antalet portar som är tillgängliga för klustertjänsten kan bli för litet när andra tjänster använder några av de nödvändiga portarna. Dessa tjänster kan omfatta Windows DNS-tjänsten, Windows Internet Name Service (WINS) eller Microsoft SQL Server-tjänsten.
Portar i intervallet 8011 till 8031: Om brandväggar separerar klusternoderna måste portarna i intervallet 8011 till 8031 vara öppna för internod-RPC-trafik. Annars indikerar fel i klusterloggen att en sponsornod inte är tillgänglig. Dessa fel uppstår eftersom det inte finns tillräckligt med portar tillgängliga för RPC-kommunikation mellan en nod som försöker ansluta till klustret och en nod som kan sponsra den noden.
Mer information om hur du konfigurerar ett nätverk och nätverksportar för ett kluster finns i följande artiklar:
När du har ändrat portinställningarna försöker du ansluta noden igen innan du fortsätter.
Kör klustervalideringsverktyget
Öppna snapin-modulen Klusterhanteraren för växling vid fel (CluAdmin.msc).
Välj Klusterhanteraren för växling vid fel i den övre vänstra kolumnen.
Välj Verifiera konfiguration.
Skriv namnet på varje nod i klustret och välj Lägg till efter var och en.
När alla noder har lagts till i listan Valda servrar: väljer du Nästa.
Välj Kör alla tester (rekommenderas)>Nästa>nästa.
Tillåt att testet slutförs. När du är klar väljer du Visa rapport.
Granska eventuella testresultat som är märkta som Misslyckade eller Varning. Den här informationen kan hjälpa dig att åtgärda problemet genom att vidta åtgärder.
Om du vill hämta en nedladdningsbar fil går du till mappen C:\Windows\Cluster\Reports och öppnar valideringsrapporten (. MHT)-fil.
Kommentar
I Windows Server 2016 och senare versioner är det en .HTM fil.
Kontrollera säkerhetsprinciper som kan påverka klusternoden
I grupprincip objektredigeraren finns dessa principobjekt i Datorkonfiguration\Windows-inställningar\Säkerhetsinställningar\Lokala principer\Tilldelning av användarrättigheter.
Kommentar
Om du vill komma åt inställningarna för den lokala säkerhetsprincipen väljer du Start, skriver lokal säkerhetsprincip och väljer sedan Lokal säkerhetsprincip.
Kontrollera att listan över konton innehåller de konton som ansvarar för att köra klusternoden. Mer information finns i Så här får du åtkomst till den här datorn från nätverket och Inställningen Tillåt inloggning lokalt säkerhetsprincip.
Kontrollera att listan över konton inte innehåller lokala konton. Mer information finns i Så här nekar du åtkomst till den här datorn från nätverket.
Kontrollera att listan över konton och grupper inte innehåller gruppen "Alla". Mer information finns i Neka inloggning lokalt säkerhetsprincipinställning.
När du har ändrat principinställningarna försöker du ansluta noden igen innan du fortsätter.
Inaktivera brandväggar tillfälligt
Inaktivera brandväggen mellan noden och resten av klustret och försök sedan att ta noden online igen. Om noden fortfarande inte är online kan brandväggen vara orsaken.
Viktigt!
Lämna inte den här ändringen på plats när du har slutfört felsökningen. När du har använt den här ändringen för testning returnerar du de här inställningarna till den ursprungliga konfigurationen.
Kontrollera om det finns problem med nätverkets maskinvara och programvara
Kontrollera systemhändelseloggen efter maskinvaru- eller programvarufel som är relaterade till nätverkskorten på den här noden.
Kontrollera nätverkskortet, kablarna och nätverkskonfigurationen för de nätverk som ansluter noderna.
Om du samarbetar med nätverkskorten kontrollerar du att teamindelningskonfigurationen är korrekt.
Kontrollera hubbar, växlar eller bryggor i nätverken som ansluter noderna.
Granska loggfiler
Om du vill identifiera orsaken till problemet läser du logginformationen från flera källor. Till exempel:
I Loggboken går du till Program- och tjänstloggar\Microsoft\Windows\FailoverClustering-Client\Diagnostic och granskar spårningsloggarna för kluster-API:et.
Generera en ny klusterlogg för noden. På servern som kör den berörda noden öppnar du en upphöjd PowerShell-prompt och kör följande cmdlet:
Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime
Följ dessa steg för att generera en mer detaljerad spårning:
Vid en upphöjd PowerShell-prompt kör du följande cmdlet för att starta spårningen:
logman create trace "base_cluster" -ow -o c:\base_cluster.etl -p "Microsoft-Windows-FailoverClustering-Client" 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets
Återskapa problemet.
Om du vill stoppa spårningen kör du följande cmdlet:
Logman stop base_cluster.etl -ets
Om du vill konvertera spårningen kör du följande cmdlet:
Netsh trace convert base_cluster.etl
Kör följande cmdlet för att generera en klusterlogg från data:
Get-ClusterLog -Node 'Local Node Name' -Destination c:\temp -UseLocalTime
Mer information om spårning och andra problem att hålla utkik efter finns i Felsöka skapa klusterfel.