Felsökning av failoverkluster

Gäller för:SQL Server

Den här artikeln innehåller information om följande problem:

Grundläggande felsökningssteg

Det första diagnostiksteget är att köra en ny klusterverifieringskontroll. Mer information om verifiering finns i Skapa ett redundanskluster: Verifiera konfigurationen. Detta kan slutföras utan avbrott i tjänsten eftersom det inte påverkar några onlineklusterresurser.

Verifiering kan köras när som helst när funktionen Redundansklustring har installerats, inklusive innan klustret har distribuerats, när klustret skapas och när klustret körs. Faktum är att ytterligare tester körs, som kontrollerar att bästa praxis följs när klustret används, för högtilgängliga belastningar. Bland dessa dussintals tester påverkar bara några utförandet av klusterarbetsbelastningar, och alla dessa tillhör lagringskategorin. Därför är det enkelt att undvika förstörande tester genom att hoppa över hela denna kategori.

Redundanskluster levereras med ett inbyggt skydd för att förhindra oavsiktlig nedtid när du kör lagringstesterna vid validering. Om klustret har några onlinegrupper när valideringen initieras och lagringstesterna fortfarande är valda, uppmanas användaren att bekräfta om de vill köra alla tester (och orsaka stilleståndstid) eller hoppa över att testa diskarna i alla onlinegrupper för att undvika driftstopp. Om hela lagringskategorin inte har testats visas inte den här uppmaningen. Detta möjliggör klusterverifiering utan avbrott.

Så här återskapar du klustret

  1. I snapin-modulen Failover-kluster i konsolträdet kontrollerar du att Failover Cluster Management har valts och väljer sedan Verifiera en konfiguration under Hantering.

  2. Följ anvisningarna i guiden för att ange servrarna och testerna och köra testerna. Sidan Sammanfattning visas efter att testerna har körts.

  3. När du fortfarande är på sidan Sammanfattning väljer du Visa rapport för att visa testresultaten.

    Om du vill visa resultatet av testerna när du har stängt guiden kan du se %SystemRoot%\Cluster\Reports\Validation Report date and time.html var %SystemRoot% är mappen där operativsystemet är installerat (till exempel C:\Windows).

  4. Om du vill visa hjälpartiklar som hjälper dig att tolka resultaten väljer du Mer om klusterverifieringstester.

Om du vill visa hjälpartiklar om klusterverifiering när du har stängt guiden går du till snapin-modulen Redundanskluster och väljer Hjälp, väljer Hjälpavsnitt, väljer fliken Innehåll , expanderar innehållet för hjälpen för redundansklustret och väljer Verifiera en konfiguration av redundanskluster. När verifieringsguiden har slutförts visar sammanfattningsrapporten resultatet. Alla tester måste passera med antingen en grön bockmarkering eller i vissa fall en gul triangel (varning). När du letar efter problemområden (röda X eller gula frågetecken) i den del av rapporten som sammanfattar testresultaten väljer du ett enskilt test för att granska informationen. Eventuella röda X-problem måste lösas innan du felsöker SQL Server-problem.

Installera uppdateringar

Att installera uppdateringar är en viktig del av att undvika problem med systemet. Användbara länkar:

Återställning vid fel på failoverkluster

Vanligtvis beror redundansklusterfel på ett av två orsaker:

  • Maskinvarufel i en nod i ett kluster med två noder. Det här maskinvarufelet kan orsakas av ett fel på SCSI-kortet eller i operativsystemet.

    Om du vill återställa från det här felet tar du bort den misslyckade noden från redundansklustret med installationsprogrammet för SQL Server, åtgärdar maskinvarufelet med datorn offline, säkerhetskopiera datorn och lägger sedan till den reparerade noden i redundansklusterinstansen igen.

    För mer information, se Skapa en ny Always On Failover-klusterinstans (installation) och Återställ från fel på failover-klusterinstansen.

  • Operativsystemfel. I det här fallet är noden offline, men är inte oåterkalleligt bruten.

    Återställ noden och testa redundans för att återställa från ett operativsystemfel. Om SQL Server-instansen inte failar över korrekt måste du använda installationsprogrammet för SQL Server för att ta bort SQL Server från failover-klustret, utföra nödvändiga reparationer, återställa datorn och sedan lägga till den reparerade noden till failover-klusterinstansen igen.

    Det kan ta tid att återställa från operativsystemfel på det här sättet. Om operativsystemets fel enkelt kan återställas bör du undvika att använda den här tekniken.

    För mer information, se Skapa en ny Always On Failover-klusterinstans (installation) och Återställ från fel på failover-klusterinstansen.

Lösa vanliga problem

I följande lista beskrivs vanliga användningsproblem och hur du löser dem.

Problem: Felaktig användning av kommandotolkssyntax för att installera SQL Server

Problem 1: Det är svårt att diagnostisera installationsproblem när du använder växeln /qn från kommandotolken, eftersom växeln /qn undertrycker alla installationsdialogrutor och felmeddelanden. Om växeln /qn har angetts skrivs alla installationsmeddelanden, inklusive felmeddelanden, till installationsloggfiler. Mer information om loggfiler finns i Visa och läsa loggfiler för SQL Server-installationsprogrammet.

Lösning 1: Använd växeln /qb i stället för växeln /qn . Om du använder växeln /qb visas det grundläggande användargränssnittet i varje steg, inklusive felmeddelanden.

Problem: SQL Server kan inte ansluta till nätverket när det har migrerats till en annan nod

Problem 1: SQL Server-tjänstkonton kan inte kontakta en domänkontrollant.

Lösning 1: Kontrollera händelseloggarna efter tecken på nätverksproblem, till exempel kortfel eller DNS-problem. Kontrollera att du kan pinga domänkontrollanten.

Problem 2: Lösenord för SQL Server-tjänstkontot är inte identiska på alla klusternoder, eller så startar noden inte om en SQL Server-tjänst som har migrerats från en misslyckad nod.

Lösning 2: Ändra lösenorden för SQL Server-tjänstkontot med SQL Server Configuration Manager. Om du inte gör det, och du ändrar lösenorden för SQL Server-tjänstkontot på en nod, måste du också ändra lösenorden på alla andra noder. SQL Server Configuration Manager gör detta automatiskt.

Problem: SQL Server kan inte komma åt klusterdiskarna

Problem 1: Inbyggd programvara eller drivrutiner uppdateras inte på alla noder.

Lösning 1: Kontrollera att alla noder använder rätt versioner av inbyggd programvara och samma drivrutinsversioner.

Problem 2: En nod kan inte återställa klusterdiskar som har migrerats från en misslyckad nod på en delad klusterdisk med en annan enhetsbeteckning.

Lösning 2: Diskenhetsbeteckningarna för klusterdiskarna måste vara desamma på båda servrarna. Om de inte är det granskar du den ursprungliga installationen av operativsystemet och Microsoft Cluster Service (MSCS).

Problem: Fel i en SQL Server-tjänst orsakar redundans

Resolution: För att förhindra att specifika tjänster svikta vilket gör att SQL Server-gruppen redundansväxlar konfigurerar du dessa tjänster med Cluster Administrator i Windows enligt följande:

  • Avmarkera kryssrutan Påverka gruppen på fliken Avancerat i dialogrutan Egenskaper för fulltext . Men om SQL Server orsakar en felövergång startar tjänsten för fulltextsökning om.

Problem: SQL Server startar inte automatiskt

Resolution: Använd Klusteradministratör i MSCS för att starta ett redundanskluster automatiskt. SQL Server-tjänsten ska vara inställd på att starta manuellt. Klusteradministratören ska konfigureras i MSCS för att starta SQL Server-tjänsten. Mer information finns i Hantera tjänster.

Problem: Nätverksnamnet är offline och du kan inte ansluta till SQL Server med TCP/IP

Problem 1: DNS misslyckas med klusterresursen inställd på att kräva DNS.

Lösning 1: Korrigera DNS-problemen.

Problem 2: Ett duplicerat namn finns i nätverket.

Lösning 2: Använd nbtstat för att hitta dubblettnamnet och åtgärda sedan problemet.

Problem 3: SQL Server ansluter inte med namngivna pipes.

Lösning 3: Om du vill ansluta med namngivna pipes skapar du ett alias med SQL Server Configuration Manager för att ansluta till rätt dator. Om du till exempel har ett kluster med två noder (Nod A och Nod B) och en redundansklusterinstans (Virtsql) med en standardinstans kan du ansluta till servern som har resursen Nätverksnamn offline med hjälp av följande steg:

  1. Avgör på vilken nod gruppen som innehåller instansen av SQL Server körs med hjälp av klusteradministratören. I det här exemplet är det Nod A.

  2. Starta SQL Server-tjänsten på datorn med net start. Mer information om hur du använder net start finns i Starta SQL Server manuellt.

  3. Starta SQL Server SQL Server Configuration Manager på Nod A. Visa det pipe-namn som servern lyssnar på. Det bör likna \\.\$$\VIRTSQL\pipe\sql\query.

  4. Starta SQL Server Configuration Manager på klientdatorn.

  5. Skapa ett alias SQLTEST1 för att ansluta sig via Named Pipes till det angivna pipe-namnet. Det gör du genom att ange Nod A som servernamn och redigera pipe-namnet till \\.\pipe\$$\VIRTSQL\sql\query.

  6. Anslut till den här instansen med aliaset SQLTEST1 som servernamn.

Problem: SQL Server-installationen misslyckas i ett kluster med fel 11001

Problem: En överbliven registernyckel i HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster.

Resolution: Kontrollera att MSSQL.X registerdatafilen inte används för tillfället och ta sedan bort klusternyckeln.

Problem: Klusterinstallationsfel: "Installationsprogrammet har inte tillräcklig behörighet för att komma åt den här katalogen: <enhet>\Microsoft SQL Server. Installationen kan inte fortsätta. Logga in som administratör eller kontakta systemadministratören"

Utfärda: Det här felet orsakas av en DELAD SCSI-enhet som inte är korrekt partitionerad.

Resolution: Återskapa en enskild partition på den delade disken med hjälp av följande steg:

  1. Ta bort diskresursen från klustret.
  2. Ta bort alla partitioner på disken.
  3. Kontrollera i diskegenskaperna att disken är en grundläggande disk.
  4. Skapa en partition på den delade disken, formatera disken och tilldela en enhetsbeteckning till disken.
  5. Lägg till disken i klustret med klusteradministratören (cluadmin).
  6. Kör SQL Server-installationsprogrammet.

Problem: Program kan inte registrera SQL Server-resurser i en distribuerad transaktion

Problem: Eftersom Microsoft Distributed Transaction Coordinator (MS DTC) inte är helt konfigurerad i Windows kan program misslyckas med att ansluta SQL Server-resurser i en distribuerad transaktion. Det här problemet kan påverka länkade servrar, distribuerade frågor och fjärranslutna procedurer som använder distribuerade transaktioner. Mer information om hur du konfigurerar MS DTC finns i Innan du installerar redundansklustring.

Resolution: För att förhindra sådana problem måste du helt aktivera MS DTC-tjänster på servrarna där SQL Server är installerat och MS DTC har konfigurerats.

Om du vill aktivera MS DTC fullt ut använder du följande steg:

  1. Öppna Administrationsverktyg på Kontrollpanelen och öppna sedan Datorhantering.

  2. I den vänstra rutan i Datorhantering expanderar du Tjänster och program och väljer sedan Tjänster.

  3. I den högra rutan i Datorhantering högerklickar du på Koordinator för distribuerad transaktion och väljer Egenskaper.

  4. I fönstret Distributed Transaction Coordinator väljer du fliken Allmänt och väljer sedan Stoppa för att stoppa tjänsten.

  5. I fönstret Distributed Transaction Coordinator (Distribuerad transaktionskoordinator ) väljer du fliken Inloggning och anger inloggningskontot NT AUTHORITY\NetworkService.

  6. Välj Använd och OK för att stänga fönstret Distribuerad transaktionskoordinator . Stäng fönstret Datorhantering . Stäng fönstret Administrationsverktyg .

Problem: SQL Server Agent kan inte ansluta till en redundansklusterinstans med flera undernät på ett anpassat portnummer

Problem: SQL Server Agent kan inte ansluta till den lokala Database Engine när alla följande villkor är uppfyllda:

  1. SQL Server installeras som en redundant klusterinstans för flera subnät.
  2. Failover-klusterinstansen är en standardinstans.
  3. Database Engine lyssnar på en fast TCP-port utöver standard-1433.
  4. SQL Server Agent ansluter till den lokala instansen under uppstart.

För en multisubnätsinstans i ett redundanskluster använder den initiala SQL Server Agent-anslutningen MultiSubnetFailover=Yes. Denna inställning gör att klienten använder TCP. Anslutningen växlar inte över till delat minne eller namngivna rör. När måladressen är (local) och ingen port anges försöker anslutningen ansluta via TCP-port 1433. Anslutningen misslyckas om Database Engine inte lyssnar på den porten.

Du kan se en koppling liknande följande i en ODBC-spårning:

DRIVER=ODBC Driver 17 for SQL Server;SERVER=(local);APP=SQLAgent - Initial Boot Probe;DATABASE=master;MultiSubnetFailover=YES;

Lösning: Skapa ett TCP-alias som styr SQL Server Agent-anslutningen till det virtuella nätverksnamnet och den konfigurerade TCP-porten för failover-klusterinstansen. Konfigurera aliaset på varje nod som kan vara värd för failover-klusterinstansen.

Steg 1: Bekräfta den konfigurerade TCP-porten

  1. På den aktiva noden, öppna SQL Server Configuration Manager.
  2. Expandera SQL Server Network Configuration och välj sedan Protokoll för MSSQLSERVER.
  3. Öppna TCP/IP och välj sedan fliken IP-adresser .
  4. Om Listen All är inställt på Ja, notera värdet på TCP-porten under IPAll.
  5. Om Listen All är satt till Nej, notera TCP-portvärdet för varje aktiverad IP-adress som används av failover-klusterinstansen.
  6. Bekräfta att SQL Server-felloggen visar att Database Engine lyssnar på den förväntade porten.

Mer information finns i Konfigurera SQL Server för att lyssna på en specifik TCP-port.

Steg 2: Skapa TCP-alias på varje klusternod

Slutför dessa steg på varje nod som kan hosta failover-klusterinstansen:

  1. Öppna konfigurationsverktyget för SQL Server-klientaliasen som gäller för den installerade SQL Server-versionen.
  2. Skapa ett nytt alias.
  3. I Alias Name, ange ett unikt namn för den lokala SQL Server Agent-anslutningen. Använd samma aliasnamn på varje nod.
  4. Välj TCP/IP som protokoll.
  5. I Server, ange det virtuella nätverksnamnet för failover-klusterinstansen. Ange inte namnet på den fysiska noden.
  6. I Port No, ange den fasta TCP-porten som identifierades i steg 1.
  7. Spara aliaset.

För detaljerade instruktioner och versionskrav, se Skapa eller ta bort ett serveralias för användning av en klient.

Important

Ett SQL Server-alias är en klientkonfiguration. Skapa ett identiskt alias på varje nod som kan äga failover-klusterinstansen. Annars kan SQL Server Agent misslyckas efter att instansen flyttat till en nod där aliaset inte är konfigurerat.

Steg 3: Konfigurera SQL Server Agent att använda aliaset

  1. I SQL Server Management Studio, koppla upp dig till failover-klusterinstansen.
  2. I Object Explorer, expandera instansen.
  3. Högerklicka på SQL Server Agent och välj sedan Egenskaper.
  4. Under Välj en sida, välj Anslutning.
  5. I Alias lokal värdserver, ange aliasnamnet som skapats i steg 2.
  6. Välj OK.
  7. Starta om SQL Server-agenten.

För mer information, se Sätt ett SQL Server-alias för tjänsten SQL Server Agent.

Steg 4: Validera konfigurationen

  1. Bekräfta att SQL Server Agent startar korrekt.
  2. Gå igenom loggen för SQL Server Agent och bekräfta att agenten har anslutit sig till den avsedda lokala Database Engine-instansen.
  3. Kör ett enkelt SQL Server Agent-jobb för att bekräfta att jobb kan ansluta till instansen.
  4. När det inte skulle störa normala affärsaktiviteter, flytta failover-klusterinstansen till en annan möjlig ägarnod.
  5. Bekräfta att SQL Server Agent startar och att testjobbet lyckas på den noden.
  6. Upprepa testet för varje möjlig ägarnod.

Använda utökade lagrade procedurer och COM-objekt

När du använder utökade lagrade procedurer med en konfiguration för redundanskluster måste alla utökade lagrade procedurer installeras på en SQL Server-beroende klusterdisk. Detta säkerställer att när en nod växlas över, kan de utökade lagrade procedurerna fortfarande användas.

Om de utökade lagrade procedurerna använder COM-komponenter måste administratören registrera COM-komponenterna på varje nod i klustret. Informationen för att läsa in och köra COM-komponenter måste finnas i registret för den aktiva noden för att komponenterna ska kunna skapas. I annat fall finns informationen kvar i registret på den dator där COM-komponenterna först registrerades.

Relaterat innehåll

  • Last updated on