Systemafbrydelser og fejl er smertefulde for DBA'er, men endnu mere for kunderne. Nutidens brugere forventer næsten 100 procent tilgængelighed, og alt mindre er årsag til irritation, hvis du er heldig, og tab af en kunde, hvis du ikke er det.
Et af DBA's primære mål er at hjælpe med at sikre, at SQL Server-instanser og -databaser forbliver online og fungerer efter en fejl eller udfald. En metode til at øge tilgængeligheden er at opsætte Windows Server Failover Clusters med SQL Server.
En failover-klynge er en gruppe af servere, der arbejder sammen for at opretholde tilgængeligheden af dine applikationer og tjenester i tilfælde af udfald eller fejl. Grundlæggende tager failover-klyngen alle de data, der er indeholdt på en SQL Server-instans, og installerer dem i et delt lagerlager - normalt på et SAN - som kan tilgås fra forskellige servere.
For at hjælpe dig med at komme i gang på vejen til høj tilgængelighed har vi samlet de ni bedste, hvad du bør gøre og ikke må, for at konfigurere din SQL Server failover-klynge, så du kan minimere nedetid for databasen.
1. Spring ikke klyngevalidering over.
Før du installerer en klynge, er det bydende nødvendigt, at du kører validering for at kontrollere konfigurationen. Hvis dette er en ny klynge, vil du gerne køre alle testene.
Når klyngen er konfigureret, og du har installeret og konfigureret dine SQL Server-forekomster på klyngen, skal du køre validering, når du foretager ændringer. Det er vigtigt at sikre sig, at valideringsresultaterne er korrekte, før du skubber din SQL Server failover-klynge til live, så du ikke behøver at planlægge nedetid for at løse mistede problemer.
2. Konfigurer kvorum godt.
Hvis du vil beholde din SQL Server online, skal du sikre dig, at du har konfigureret kvorum korrekt i failover-klyngen. Denne Microsoft-dokumentation giver dybdegående instruktioner om, hvordan du opnår dette, men fremhævningsrullen indeholder disse bedste fremgangsmåder:
- Reevaluer kvorum, hver gang din klyngekonfiguration ændres
- Tildel et vidne for at få et ulige antal stemmer
- Fjern stemmer, når det er relevant
- Brug funktionen "Dynamisk kvorum" til dynamisk at justere nodestemmer
Det er vigtigt at bemærke, at den mest effektive måde at konfigurere kvorum på vil variere afhængigt af Windows-versionen, antallet af noder og hvor pålidelig netværkskommunikationen er mellem noderne,
3. Vælg ikke den forkerte version af Windows eller SQL Server.
Denne slags lyder som en no-brainer, men den tåler altid at blive gentaget. Sørg for, at du vælger den seneste version af Windows Server, og sørg for, at du bruger Enterprise- eller Datacenter-versionen. Hold dig også til én version af SQL Server for at holde tingene enkle. Hvis du overholder disse to fremgangsmåder, bliver din klynge nemmere at administrere og holde online.
4. Køb den korrekte hardware.
Det kan være svært at tilpasse din hardware til en SQL Server-klynge. For eksempel vil du ikke spilde penge på for meget hukommelse, men at have for lidt kan påvirke ydeevnen.
Mens du udvikler din plan for oprettelse af din SQL Server-klynge, skal du sørge for at bekræfte, at dine hardwarebehov er opfyldt for den rigtige mængde hukommelse, at din netværkssti er overflødig, og at du nøjagtigt har evalueret dine SSD-behov.
5. Læg ikke for mange noder i én klynge.
Du kan blive fristet til at placere alle dine noder i én klynge, men det er bedre at holde sig til en til to noder pr. klynge. Husk, at hver gang du anvender en patch eller en opdatering til en klynge, skal du teste, at hver forekomst stadig fungerer på hver node. Jo færre noder i en klynge, jo mindre nedetid for hver forekomst, når du fejler den over hver node.
6. Planlæg dine noder og forekomster.
Failover-klynger er ikke one-size-fits-all, så du bliver nødt til at evaluere dine behov og planlægge i overensstemmelse hermed. Et godt sted at starte er ved at besvare disse spørgsmål og skræddersy din klynge efter behov:
- Hvor mange klynge noder har vi brug for?
- Hvor mange SQL Server-instanser vil vi installere?
- Hvor mange Windows failover-klynger passer til vores behov og budget?
- Hvilken slags lager vil vi bruge?
- Hvordan ser vores iscenesættelsesmiljø ud?
7. Gå ikke ud fra, at dine applikationer vil failover elegant.
Stol aldrig på, at din SQL Server-instans kører, som den var før en failover opstod. Nogle applikationer kommer muligvis ikke automatisk online bagefter, og afhængigt af applikationen kan det tage et stykke tid, før du opdager det.
Gør det til en standardpraksis at inkludere applikationstest med hver migrering til en failover-klynge.
8. Reevaluer dine SQL Server-konfigurationsindstillinger.
Når du starter planlægningsfasen med at oprette SQL Server failover-klynger, er det et godt tidspunkt at tage et nyt kig på dine konfigurationsindstillinger. Kontroller for eksempel, at du bruger de bedste indstillinger til ting som hukommelsesallokering på multi-instansklynger.
9. Slap ikke med din navnekonvention.
Tag dig tid nu til at navngive dine klyngekomponenter omhyggeligt og spar dig selv for en massiv hovedpine, når du forsøger at oprette forbindelse til serveren senere. Her er et par ideer til at hjælpe med at etablere en effektiv navnekonvention:
- Sørg for, at navnet identificerer den type komponent, du mærker. Er det en klynge, fysisk server, SQL Server-instans eller Distributed Transaction Coordinator?
- Installer BGINFO for at vise servernavnet på skrivebordet for hver server i klyngen. Dette gør det nemt at finde de rigtige databaser.
- Vær konsekvent, når du tilføjer yderligere noder eller installerer en anden SQL Server-instans på klyngen. Hvis du holder dig til din navnekonvention, vil det ikke kun forenkle tingene for dig nu, men også gøre det nemmere at finde servere for dem, der har brug for dem senere.