Best practice for en Microsoft SQL Server

Skal du installere en ny Microsoft SQL Server, og er du i tvivl om hvordan denne server skal bestykkes og konfigureres for at opnå bedst mulig performance? Denne spørgsmål bliver tit stillet men sjældent besvaret i detaljer.

Det korte svar nu til dags er typisk; at man skal installere SQL på dedikeret hardware med masser af RAM, og at man skal undgå at virtualisere SQL. Det lange svar er: det afhænger. Begge svar er delvis korrekt, men de adresserer ikke software delen af Microsoft SQL Server - altså selve installationen og konfiguration.

 

Skal vi virtualisere SQL?

Ved at virtualisere SQL, risikerer man at udsætte ens server og derfor applikationer over for lange svartider og lange IO køer (IO Queues). Det er to ting (blandt mange, mange andre), som vil have katastrofale effekter på performance. SQL er nemlig utrolig følsom overfor responstid, og det som er et hæftende træk i en virtuel miljø er højere svartider, især på storage hvis det underliggende storage lag kører på et SAN som konsoliderer og leverer storage ressourcer til flere hundrede servere. Lange svartider og lange køer til storage set fra SQL Serveren, vil i sidste ende kunne mærkes i applikationen af brugere. Det er ligeså vigtigt at kunne dedikere CPU og hukommelses ressourcer som har ultra korte responstider.

I SQL har ressource typer en anden prioritering end på feks. en Web server. Nummer et er altid hurtig storage, herefter kommer hurtig CPU og hurtig hukommelse på anden og tredje plads. Selv om applikationen kan køre helt eller delvist i SQL serverens hukommelse, hurtig storage skal altid være første prioritet.

 

Ok, så må det blive en fysisk installation…

Hvis du har mulighed for det så ja, men Ikke nødvendigvis. Problemet med lange svartider og lange IO køer på serveren kan skyldes flere ting: Langsomme CPU’er, manglende hukommelse eller forkert konfiguration, men typisk er storage den ressource som tager skylden. Overbelastning af storage controllere på SAN, over-provisionering af tilgængelig IO på diske til servere og link typer som kan have iboende (negative) træk på responstid (FC, iSCSI mm.). Hvis du oplever problemer i en eller flere af disse områder på dit SAN, så kan du forvente at få dårlig SQL performance. Her vil man anbefale at installere SQL på lokal storage, som ikke deles med andre servere. Lokal storage som er installeret lokal på serveren vil have kortere svartider, og kortere IO køer.

 

Men mine svartider og IO køer ser fine ud, er det okay at virtualisere?

Det afhænger.

  • Hvor mange IO’er vil det nye SQL Server generere til og fra SANet?
  • Har det eksisterende SAN nok IO kapacitet tilovers efter SQL serveren går i drift?
  • Hvilken arbejdsmængde og type vil SQL serveren have? Vil den være konstant forbundet til storage for at opdatere og læse databaser eller sker det en gang imellem (OLTP vs OLAP)?

Det er tre spørgsmål du skal kunne besvare for ellers risikerer du at belaste SANet efter SQL serveren går i drift. Da et SAN har det formål, at levere konsolideret kapacitets ressourcer som andre servere har adgang til, kan du risikere at belaste ikke blot SANet men også de andre servere som skal bruge de ressourcer som den leverer, ved at frarøve dem de tilgængelig IO’er, Responstid mm. som de skal bruge.

Hvis du har hurtige CPU som ikke er over-provisionerede, masser af hukommelse, masser af kapacitet, masser af tilgængelige IO’er og ultra korte svartider, så kan du roligt virtualisere SQL. Men husk nu at installere og konfigurere både styresystemet og SQL Server korrekt, for ellers kan du risikere at skabe lange svartider og lange IO køer lokalt på serveren.

 

 

 

 

I følgende video vil i se en af Draware’s specialister installere Windows Server 2012 R2 samt SQL Server 2014 SP2 på en dedikeret virtuel host i VMware, som har dedikeret NVMe storage, fra start til slut uden pause. Videoen varer ca. 30 minutter og dækker minimum kravene samt opsætnings procedure for en typisk SQL installation. Der er ingen Next, Next, Finish her…

Vær opmærksom på, at visse opsætnings procedure bliver ikke gennemgået. Disse procedurer omfatter blandt andet:

- Tildeling af statisk IP adresse
- Tilknytning af server til domain
- Installation og konfiguration af antivirus
- Oprettelse af SQL Jobs som automatisk Backup

De første to procedure udføres typisk efter styresystemet er klargjort og konfigureret, og før Microsoft SQL Server software bliver installeret (16:00 i videoen). De sidste to procedure udføres efter Microsoft SQL Server software bliver installeret. Husk at konfigurere tidszone i styresystemet samt scan exclusions/exceptions i antivirus agenten for Microsoft SQL Server mapper.

 

 

OBS OBS OBS

Husk for alt i verden, at installere Microsoft SQL Server med den rigtige Collation: SQL_Latin1_General_CP1_CI_AS

Denne SQL Collation er defineret som default hvis man installerer SQL på en styresystem med US lokalitet. Hvis SQL installeres på en styresystem med Dansk lokalitet vil default Collation være sat til Danish_Norwegian_CI_AS, og dette vil have negative effekter på SQL performance. Du skal også sikre dig, at alle fremtidige databaser som vil køre på denne SQL server skal være konfigureret med SQL_Latin1_General_CP1_CI_AS Collation. Hvis du ikke sørger for disse ting kan du risikere at skulle geninstallere SQL Server og starte med en ny database. Ved at lade styresystemets lokalitet være default US, kan du sikre dig, at alle fremtidige databaser som oprettes på denne SQL server vil blive konfigureret med SQL_Latin1_General_CP1_CI_AS Collation som default.

 

COM_EASYBLOG_PREV_RECIPE
COM_EASYBLOG_NEXT_RECIPE
 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Thursday, 04 June 2020