Systemavbrott och fel är smärtsamma för DBA:er, men ännu mer för kunderna. Dagens användare förväntar sig nästan 100 procent tillgänglighet, och allt mindre är orsak till irritation om du har tur och förlust av en kund om du inte har det.
Ett av DBA:s primära mål är att hjälpa till att säkerställa att SQL Server-instanser och databaser förblir online och fungerar efter ett fel eller avbrott. En metod för att öka tillgängligheten är att ställa in Windows Server Failover-kluster med SQL Server.
Ett failover-kluster är en grupp servrar som arbetar tillsammans för att upprätthålla tillgängligheten för dina applikationer och tjänster i händelse av ett avbrott eller fel. I grund och botten tar failover-klustret all data som finns i en SQL Server-instans och installerar den i ett delat lagringsförråd – vanligtvis på ett SAN – som kan nås från olika servrar.
För att hjälpa dig att komma igång på vägen mot hög tillgänglighet har vi sammanställt de nio bästa vad som bör göras och inte göras för att konfigurera ditt SQL Server-failover-kluster så att du kan minimera nedtid för databasen.
1. Hoppa inte över klustervalidering.
Innan du installerar ett kluster är det absolut nödvändigt att du kör validering för att kontrollera konfigurationen. Om detta är ett nytt kluster vill du köra alla tester.
När klustret är konfigurerat och du har fullständigt installerat och konfigurerat dina SQL Server-instanser på klustret, kör validering när du gör ändringar. Det är viktigt att se till att valideringsresultaten är korrekta innan du skickar ditt SQL Server-failover-kluster till live så att du inte behöver schemalägga driftstopp för att åtgärda missade problem.
2. Konfigurera kvorum väl.
Om du vill behålla din SQL Server online, se till att du har konfigurerat kvorum korrekt i failover-klustret. Denna Microsoft-dokumentation ger djupgående instruktioner om hur du uppnår detta, men höjdpunktsrullen innehåller dessa bästa metoder:
- Utvärdera om kvorumet varje gång din klusterkonfiguration ändras
- Tilldela ett vittne för att få ett udda antal röster
- Ta bort röster när det är lämpligt
- Använd funktionen "Dynamiskt kvorum" för att dynamiskt justera nodröster
Det är viktigt att notera att det mest effektiva sättet att konfigurera kvorum kommer att variera beroende på Windows-version, antal noder och hur tillförlitlig nätverkskommunikation är mellan noderna,
3. Välj inte fel version av Windows eller SQL Server.
Den här låter som en enkel sak, men det tål alltid att upprepas. Se till att du väljer den senaste versionen av Windows Server och se till att du använder Enterprise- eller Datacenter-versionen. Håll dig också till en version av SQL Server för att göra det enkelt. Om du följer dessa två metoder blir ditt kluster lättare att hantera och hålla online.
4. Köp rätt hårdvara.
Det kan vara svårt att anpassa hårdvaran till ett SQL Server-kluster. Du vill till exempel inte slösa pengar på för mycket minne, men att ha för lite kan påverka prestandan.
När du utvecklar din plan för att skapa ditt SQL Server-kluster, se till att bekräfta att dina hårdvarubehov uppfylls för rätt mängd minne, att din nätverksväg är redundant och att du har utvärderat dina SSD-behov korrekt.
5. Lägg inte för många noder i ett kluster.
Du kan bli frestad att placera alla dina noder i ett kluster, men det är bättre att hålla fast vid en till två noder per kluster. Kom ihåg att varje gång du applicerar en patch eller en uppdatering till ett kluster måste du testa att varje instans fortfarande fungerar på varje nod. Ju färre noder i ett kluster, desto mindre stilleståndstid för varje instans när du misslyckas med den över varje nod.
6. Planera dina noder och instanser.
Failover-kluster är inte enstaka, så du måste utvärdera dina behov och planera därefter. Ett bra ställe att börja är genom att svara på dessa frågor och skräddarsy ditt kluster efter behov:
- Hur många klusternoder behöver vi?
- Hur många SQL Server-instanser kommer vi att installera?
- Hur många Windows failover-kluster passar våra behov och budget?
- Vilken typ av lagring kommer vi att använda?
- Hur ser vår iscensättningsmiljö ut?
7. Anta inte att dina applikationer kommer att övervinnas på ett elegant sätt.
Lita aldrig på att din SQL Server-instans körs som den var innan en failover inträffade. Vissa applikationer kanske inte automatiskt kommer tillbaka online efteråt, och beroende på applikationen kan det ta ett tag innan du märker det.
Gör det till en standardpraxis att inkludera applikationstestning med varje migrering till ett failover-kluster.
8. Omvärdera dina SQL Server-konfigurationsinställningar.
När du börjar planeringsfasen för att skapa SQL Server-failover-kluster, är det ett bra tillfälle att ta en ny titt på dina konfigurationsinställningar. Kontrollera till exempel att du använder de bästa inställningarna för saker som minnesallokering på kluster med flera instanser.
9. Slappna inte av med din namnkonvention.
Ta dig tid nu att namnge dina klusterkomponenter noggrant och spara dig själv en enorm huvudvärk när du försöker ansluta till servern senare. Här är några idéer för att skapa en effektiv namnkonvention:
- Se till att namnet identifierar typen av komponent som du märker. Är det ett kluster, en fysisk server, SQL Server-instans eller Distributed Transaction Coordinator?
- Installera BGINFO för att visa servernamnet på skrivbordet för varje server i klustret. Detta gör det enkelt att hitta rätt databaser.
- Var konsekvent när du lägger till ytterligare noder eller installerar en annan SQL Server-instans i klustret. Om du håller fast vid din namnkonvention kommer det inte bara att förenkla saker för dig nu utan också göra det lättare att hitta servrar för dem som behöver dem senare.