SQL Serverin parhaat käytännöt, osa II: Virtualisoidut ympäristöt

On vuosi 2016, ja joidenkin mielestä SQL Serveriä ei voi käyttää virtuaalikoneessa. SQL Server voi toimia onnistuneesti virtuaalikoneessa, mutta SQL on luonteeltaan resurssiintensiivinen, joten jos aiot virtualisoida SQL:n, sinun on yksinkertaisesti noudatettava parhaita käytäntöjä. Parhaiden käytäntöjen noudattamatta jättäminen voi olla ero huonon ja poikkeuksellisen virtuaalisen SQL Serverin suorituskyvyn välillä. Katso edellinen blogikirjoitukseni yleisistä SQL-palvelinten parhaista käytännöistä, koska ne pätevät myös virtualisoituun ympäristöön.

Virranhallinta

Fyysisen virtuaalikoneen isäntä on asetettava korkealle suorituskyvylle BIOSissa, jotta varmistetaan, että se käynnistää kaikki sylinterit, mikä puolestaan ​​antaa hypervisorille mahdollisuuden varata abstraktit resurssit parhaaksi katsomallaan tavalla. .

Virranhallinta on aina asetettava korkealle suorituskyvylle Windows-virtuaalikoneissa. Balanced on asetus kannettaville tietokoneille, jotka tarvitsevat varavirtaa. Virtuaalisissa koneissa voi olla vakavia suorituskykyongelmia, jos niitä ei ole määritetty oikein. Joissakin ympäristöissä VM:n virranhallinta-asetuksia voidaan hallita hypervisorilla, mutta kun resurssiintensiiviset sovellukset, kuten SQL-palvelin, ovat pelissä, varmista, että Windowsin virranhallinta on asetettu korkealle suorituskyvylle.

Käytä aina SLAT-yhteensopivaa palvelinlaitteistoa

Vaikka se ei välttämättä ole vanhan laitteiston tapauksessa, useimmissa nykyaikaisissa palvelimissa on x64-prosessorit, jotka tukevat SLAT-osoitetta (Second Level Address Translation).

VMware- ja Hyper-V-isännissä tulee käyttää 64-bittisiä x64-suorittimia (AMD tai Intel). On ehdottoman tärkeää, että isäntäprosessori tukee SLAT:ia. SLAT käyttää useita aliaksia.

SLAT mahdollistaa CPU:n ylläpitämisen virtuaalikoneiden käyttämän virtuaalimuistin ja hypervisor-isännän fyysisen muistin välillä. Jos CPU ei pysty suorittamaan tätä muistikartoitusta, hypervisorin tehtävänä on tehdä se. Suorituskykyä ja skaalautuvuutta parannetaan, kun keskusyksikkö suorittaa muistikartoituksen.

Microsoftin tutkimukset ovat osoittaneet, että SLAT:

Älä ajattele sitä liikaa – varmista vain, että taustalla olevan VM-isäntälaitteisto tukee SLAT:ia.

Älä sitoudu liikaa VM-isäntäsuorittimeen

En voi korostaa tätä asiaa tarpeeksi. Jos sitoudut liikaa VM-isäntään ja käytät resurssiintensiivisiä sovelluksia, kuten SQL-palvelinta, joka toimii VM-isäntäkoneissa, kohtaat suorituskykyongelmia ennemmin tai myöhemmin. Ei ole ongelma, jos sinulla on joukko vähän resursseja käyttäviä verkko-/sovelluspalvelimia, jotka jakavat resursseja, koska hypervisor pystyy helposti pysymään ajan tasalla siitä, mikä VM tarvitsee mitäkin resursseja, mutta kun tuot joukkoon resurssiintensiivisiä sovelluksia, se on resepti katastrofiin.

Jos virtualisoitu SQL Server -työkuormasi on erittäin intensiivinen, varmista, että käytät Hyper-V:n tai vSpheren viimeisintä versiota, sillä jokaisessa iteraatiossa on uudet skaalautuvuuden maksimiarvot.

Paras käytäntö virtuaalikoneen, erityisesti sellaisen, joka isännöi resurssiintensiivistä sovellusta, kuten SQL-palvelinta, mitoitusta varten, on varmistaa, että virtuaalikoneelle määritettyjen virtuaalisten suoritinten kokonaismäärä ei ylitä fyysisten suoritinten määrää. pistokkeet (toisin kuin loogiset ytimet), jotka ovat saatavilla isäntäkoneessa.

CPU-valmius

Tätä et halua kohdata, koska se viittaa ylivaroitettuun virtuaalikoneeseen ja/tai isäntään. Prosessorivalmius on aika, jonka VM on valmis (tarvitsee) CPU:n kellojaksoja fyysisessä isännässä, mutta sen on odotettava aikaa saadakseen, koska muut virtuaalikoneet jo käyttävät resursseja.

Valmiusajan laskeminen voi olla tuskaa, koska se riippuu VM-isännässä esitetyn mittarin kyselyvälistä, esim. 20 sekuntia (20 000 millisekuntia):

(CPU:n valmiusarvo / 20 000 ms) x 100 % = Suorituskykyvaikutus prosentteina 20 sekunnin aikaväliä kohti.

Jos ekstrapoloit ajan myötä, näet nopeasti, kuinka tämä heikentäisi suorituskykyä, varsinkin jos käytät tehokkaita sovelluksia, kuten SQL-palvelinta.

Valmiusarvot <5 % vCPU:ta kohden ovat yleensä kunnossa. Valmisarvot >5 % vCPU:ta kohden ovat varoitus, ja sinulla on todennäköisesti jo suorituskyvyn heikkeneminen.

Ilman virheellisiä määrityksiä ei ole ollenkaan vaikeaa löytää CPU-valmiusarvoja >=10 %, mikä johtuu joistakin suurista virtuaalikoneista, joissa on useita vCPU:ita, jotka toimivat muutamalla fyysisellä ytimellä tai vastaavasta vCPU:n ja pCPU:n epäsuhtaudesta.

Jos itse virtuaalikone on ylivaroitettu esim. Virtuaalikoneen, jossa on 8 vCPU:ta, on odotettava, että kaikki 8 pCPU:ta taustalla olevassa VM-isännässä ovat vapaita ennen kuin se saa kellojaksoja. Tässä oikea koko tulee palkkaan. Jos virtuaalikone todella tarvitsee suuren määrän vCPU:ita, lisää ne ehdottomasti. Jos olet määrittämässä kokoa uudelle sovellukselle, lisää vCPU:ita vain, kun seuraat suorituskykyä. Windowsin tehtävienhallinta ei ole loistava suorituskyvyn indikaattori virtualisoidussa ympäristössä, joten seuraa VM-isäntäpuolelta. Jos kaikki vCPU:t ovat maksimissaan, se tarvitsee todennäköisesti lisää vCPU:ita. Jos ei, niin jätä tarpeeksi hyvin rauhaan. Olen nähnyt tilanteita, joissa vCPU:iden poistaminen virtuaalikoneesta itse asiassa paransi sovellusten suorituskykyä kyseisellä virtuaalisella SQL-palvelimella isännöityjen tietokantojen kanssa.

Jos VM-isäntä on ylivaroitettu, kyseisessä isännässä on käynnissä useita virtuaalikoneita, jotka kaikki kilpailevat resursseista. Jos näin on, sinun on siirrettävä jotkin virtuaalikoneet muihin isäntäkoneisiin resurssikilpa-ongelmien lievittämiseksi.

Vastaa CPU-valmiutta Hyper-V:ssä on Perfmon-laskuri Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch, joka on saatavilla Windows Server 2012:sta lähtien.

Hypersäie

Hypersäie on Intelin tekniikka, joka paljastaa kaksi laitteistokontekstia (säiettä) yhdestä fyysisestä ytimestä. Näitä säikeitä kutsutaan loogisiksi prosessoreiksi. On yleinen väärinkäsitys, että hyper-säie kaksinkertaistaa suorittimien tai ytimien määrän. Näin ei yksinkertaisesti ole. Hypersäikeistys parantaa yleistä isäntäsuorituskykyä 10–30 %:sta pitämällä prosessorin putkilinjan kiireisempänä ja antamalla hypervisorille enemmän mahdollisuuksia ajoittaa suorittimen kellojaksoja, joten sinun tulee ehdottomasti hyödyntää hypersäikeistystä ottamalla se käyttöön virtuaalikoneen BIOSissa. isäntäkone.

Ydintä kantaa kohden

NUMA (Epätasainen muistin käyttö) varaa kullekin suorittimelle oman paikallisen muistinsa. CPU ja muisti yhdistettynä tunnetaan NUMA-solmuna. NUMA:n etuna on, että sen avulla prosessori voi käyttää omaa paikallista muistiaan nopeammin kuin ei-paikallinen muisti. Sekä Windows että SQL ovat täysin NUMA-tietoisia ja tekevät säikeiden aikataulutuspäätökset NUMA-topologian perusteella.

vNUMA esittelee fyysisen VM-isännän NUMA-arkkitehtuurin suoraan VM-vieraskäyttöjärjestelmälle. Virtuaalikoneen vNUMA-topologia voi ulottua useisiin fyysisiin NUMA-solmuihin. Kun vNUMA-yhteensopiva VM on kytketty päälle, käyttöjärjestelmälle esitettyä arkkitehtuuria ei voi muuttaa. Tämä on itse asiassa positiivinen asia, koska vNUMA-arkkitehtuurin muuttaminen voi aiheuttaa epävakautta käyttöjärjestelmässä. Tämä rajoitus voi kuitenkin aiheuttaa ongelmia, jos virtuaalikonetta yritetään siirtää toiseen VM-isäntään, jolla on erilainen NUMA-arkkitehtuuri.

vNUMA on oletusarvoisesti käytössä virtuaalikoneissa, joissa on yli 8 vCPU:ta (riippumatta pistokkeiden ja ytimien yhdistelmästä, joka muodostaa pelattavien vCPU:iden määrän).

Paras käytäntö:

Virtuaalivastakkeiden lukumäärän tulee olla yhtä suuri kuin haluamasi vCPU:iden lukumäärä (yksi ydin per liitäntä).

Tämä on oletusasetus virtuaalikonetta luotaessa. Tämä konfiguraatio tunnetaan leveänä ja tasaisena, ja vNUMA esittää optimaalisen vNUMA-topologian vieraskäyttöjärjestelmälle taustalla olevan fyysisen VM-isäntäpalvelimen NUMA-topologian perusteella. Jos virtuaalikoneen konfiguraatio ei ole leveä ja tasainen, vNUMA ei pysty automaattisesti valitsemaan parasta NUMA-kokoonpanoa, vaan se yksinkertaisesti vastaa mitä tahansa syöttämääsi kokoonpanoa, mikä voi johtaa NUMA-topologian yhteensopimattomuuteen, joka vaikuttaa haitallisesti suorituskykyyn.

Lisenssirajoitukset ovat yleisin syy siihen, miksi järjestelmänvalvojat päättivät vastustaa näitä parhaita käytäntöjä. Jos sinun on käytettävä sitä, varmista, että peilaat ainakin fyysisen VM-isännän NUMA-topologian.

CPU Hot-Add

Tämä asetus voi olla pieni saalis 22 – käyttöönotossa ja käytöstä poistamisessa on hyvät ja huonot puolensa.

Ammatit

CPU-hot plugin avulla VM-järjestelmänvalvojat voivat lisätä suorittimia lennossa virtuaalikoneisiin ilman, että virtuaalikonetta tarvitsee sammuttaa ensin. CPU hot plug mahdollistaa dynaamisen resurssien hallinnan ja mahdollisuuden lisätä suorittimia, kun vNUMA:ta ei tarvita (yleensä pienemmät VM:t).

Haitat

Kun CPU Hot Add on käytössä virtuaalikoneessa, se poistaa vNUMA:n automaattisesti käytöstä. SQL-palvelimet, jotka ovat leveämpiä kuin fyysisen palvelimen NUMA-arkkitehtuuri, jossa ne sijaitsevat, eivät näe taustalla olevaa NUMA-arkkitehtuuria, mikä johtaa suorituskyvyn heikkenemiseen.

CPU:n hot-add:n ottaminen käyttöön vai ei, riippuu siitä, kuinka leveä virtuaalikoneesi on. Suositukseni on poistaa prosessorin hot-add käytöstä suuremmissa virtuaalikoneissa, jotka vaativat vNUMA:ta. Ennaltaehkäisy on aina parempi kuin hoito, joten käytä aikaa SQL-palvelimen VM:n suorittimen oikean kokoiseen kokoon sen sijaan, että luottaisit CPU:n hot-add-toimintoon.

CPU-affinity

En suosittele CPU-affiniteettia tuotantokoneissa, koska se rajoittaa hypervisorin kykyä ajoittaa tehokkaasti vCPU:ita fyysiselle palvelimelle.

Älä liioittele VM-isäntämuistia

Tätä ei voi taaskaan korostaa tarpeeksi. Kun määrität SQL VM:n alun perin kokoa, varmista, että isäntä ei ole eikä sitä ylisitota, kun SQL VM käynnistetään. Älä unohda, että VM-isäntäkoneella on oma muisti, jolla voidaan käyttää myös hypervisor-käyttöjärjestelmää!

Muistin varaus

SQL-palvelin on muistisairaus, joten mitä tahansa muistia käytetään, eikä sitä vapauteta. Siksi saattaa olla järkevää asettaa SQL VM:n muistin varaus vastaamaan varatun muistin määrää miinus 4–6 Gt, jotta Windows toimii. Tämä vähentää merkittävästi ilmapallojen ja vaihtojen todennäköisyyttä ja takaa, että virtuaalikone saa tarvitsemansa muistin optimaaliseen suorituskykyyn. Muistivaraukset voivat kuitenkin estää virtuaalikoneiden siirtymisen isäntien välillä, jos kohdeisännällä ei ole varaamatonta muistia, joka on yhtä suuri tai suurempi kuin muistivarauksen koko.

Virtuaalikoneelle varattavan muistin määrän laskeminen:

Dynamic< Dynamic , tämä on ristiriidassa virtualisoinnin perusteiden kanssa, joten saatat hävitä tämän taistelun virtualisoinnin järjestelmänvalvojan kanssa, mutta siitä kannattaa kiistellä. Omistetut resurssit tarkoittavat, että voit taistella VM-isäntäkoneen resursseista pois yhtälöstä.

Muisti on yksi suurimmista tekijöistä SQL Serverin suorituskyvyn kannalta. SQL käyttää muistia sisäiseen puskuriinsa (äskettäin käytetty tieto) ja proseduurivälimuistiin (äskettäin suoritetut T-SQL-komennot). Nämä puskurit tarkoittavat, että SQL Server voi saada tarvitsemansa tiedot ja komennot välimuistista sen sijaan, että joutuisi menemään levylle ja aiheuttamaan siihen liittyviä I/O-ylikustannuksia. SQL Server voi automaattisesti hallita ja kasvattaa puskuri- ja prosessivälimuistiaan työmäärän ja käytettävissä olevan muistin vaatimusten perusteella. Jos muistia ei ole käytettävissä, suorituskyky heikkenee.

Jos virtualisoinnin järjestelmänvalvojasi on sulkenut oman muistin mahdottomaksi, kysy Hyper-V Dynamic Memory- tai VMware-muistin ylisitoutumismäärityksistä.

VMware käsittelee muistia jaettavana resurssina, ja jokaista megatavua muistia pidetään erillisenä jaettuna. Muistin ylisitoutuminen on automatisoitu dynaaminen prosessi, joka ottaa osuudet virtuaalikoneilta, jotka eivät käytä niitä, ja allokoi ne muille virtuaalikoneille tarpeen mukaan.

Muisti palautetaan virtuaalisista koneista, joilla on vähemmän suhteellisia osuuksia, jotta se voidaan antaa virtuaalisille koneille, joilla on enemmän suhteellisia osuuksia, joten varmista, että SQL-VM:llä on riittävän korkea osuuksien painotus.

Hyper-V Dynamic -muisti jakaa myös käyttämättömän muistin dynaamisesti. Molemmissa tekniikoissa virtuaalikoneet säilyttävät 25 % käyttämättömästä muistista tyynynä siltä varalta, että se yhtäkkiä tarvitsee lisää muistia.

On syytä huomata, että SQL 2008:n tai uudemman Datacenter- tai Enterprise-versioiden on tuettava hot-add RAM -muistia. Microsoftin palvelinkäyttöjärjestelmät ovat olleet hot-add-yhteensopivia W2K3r2sp2:sta lähtien.

Älä tallenna tiedostoja samalle levylle

OS-tiedostot, SQL-datatiedostot, SQL-lokitiedostot, SQL-varmuuskopiot jne… päätyvät kaikki samalle VHD:lle, jos rakennat virtuaalikoneen oletusarvolla asetukset ja asenna SQL oletusasetuksilla.

SQL Serverin binaarit, datatiedostot tulee sijoittaa erillisiin VMDK:ihin.

Käytä RAID 10:tä käyttäjätiedoille, lokitiedostoille ja TempDB-tiedostoille parhaan suorituskyvyn ja käytettävyyden saavuttamiseksi.

Katso edellinen viestini SQL-palvelimen parhaista käytännöistä tempdb-koon määrittämisen suhteen.

Johtopäätös

Virtualisoitu SQL Server voi tarjota suorituskyvyn ja skaalautuvuuden tukemaan tuotantotietokantasovelluksia, mikäli parhaita käytäntöjä noudatetaan.

Tämä on moniosainen sarja SQL Serverin parhaista käytännöistä. Lue osa I tästä.

Lähteet:

http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

http://download.microsoft.com/download/6/1/d/61dde9b6-ab46-48ca-8380-d7714c9cb1ab/best_practices_for_virtualizing_and_managing_sql_server_2012.pdf