Doporučené postupy pro SQL Server, část II: Virtualizovaná prostředí

Je rok 2016 a někteří lidé si stále myslí, že SQL Server nelze spustit na virtuálním počítači. SQL Server může úspěšně běžet na virtuálním počítači, ale SQL je ze své podstaty náročný na zdroje, a tak pokud hodláte virtualizovat SQL, musíte jednoduše dodržovat osvědčené postupy. Nedodržování osvědčených postupů může být rozdílem mezi špatným a výjimečným výkonem virtuálního serveru SQL. Přečtěte si prosím můj předchozí příspěvek na blogu o obecných osvědčených postupech pro SQL server, protože tyto platí také ve virtualizovaném prostředí.

Správa napájení

Fyzický hostitel virtuálního počítače by měl být v systému BIOS nastaven na vysoký výkon, aby bylo zajištěno, že spouští všechny válce, což zase umožní hypervizoru alokovat abstrahované zdroje, jak uzná za vhodné. .

Správa napájení by měla být v rámci virtuálních počítačů Windows vždy nastavena na vysoký výkon. Vyvážený je nastavení pro notebooky, které potřebují šetřit energii. Pokud nejsou virtuální počítače správně nakonfigurovány, mohou mít vážné problémy s výkonem. V některých prostředích lze nastavení správy napájení virtuálního počítače ovládat hypervizorem, ale když jsou ve hře aplikace náročné na zdroje, jako je SQL server, ujistěte se, že je správa napájení Windows nastavena na vysoký výkon.

Vždy používejte serverový hardware kompatibilní se SLAT

Ačkoli to nemusí být případ staršího hardwaru, většina moderních serverů má procesory x64, které podporují SLAT (Second Level Address Translation).

Hostitelé VMware a Hyper-V by měli používat 64bitové procesory x64 (AMD nebo Intel). Je naprosto nezbytné, aby hostitelský procesor podporoval SLAT. SLAT má několik aliasů.

SLAT umožňuje CPU udržovat mapování mezi virtuální pamětí používanou virtuálními počítači a fyzickou pamětí na hostiteli hypervizoru. Pokud CPU nemůže provést toto mapování paměti, pak by to musel udělat hypervizor. Výkon a škálovatelnost jsou vylepšeny tím, že mapování paměti provádí CPU.

Studie společnosti Microsoft prokázaly, že SLAT:

Nepřemýšlejte o tom příliš – jen se ujistěte, že hardware základního hostitele virtuálního počítače podporuje SLAT.

Nepřetěžujte hostitelský procesor VM

Tento bod nemohu dostatečně zdůraznit. Pokud přetížíte hostitele virtuálního počítače a na virtuálních počítačích tohoto hostitele virtuálního počítače běží aplikace náročné na zdroje, jako je SQL server, dříve nebo později narazíte na problémy s výkonem. Není problém, pokud máte spoustu webových/aplikačních serverů s nízkou spotřebou zdrojů sdílejících zdroje, protože hypervizor může snadno držet krok s tím, který virtuální počítač potřebuje jaké zdroje, ale když do mixu přidáte aplikace náročné na zdroje, je to recept na katastrofu.

Pokud je vaše vytížení virtualizovaného SQL Serveru vysoce intenzivní, ujistěte se, že používáte nejnovější verzi Hyper-V nebo vSphere, protože každá iterace přichází s novými maximy škálovatelnosti.

Nejlepším postupem pro počáteční dimenzování virtuálního počítače, zejména takového, který bude hostit aplikaci náročná na prostředky, jako je SQL server, je zajistit, aby celkový počet virtuálních CPU přiřazených k virtuálnímu počítači nepřekročil počet fyzických CPU. sockety (na rozdíl od logických jader) dostupné na hostitelském počítači.

CPU Ready

Toto není něco, s čím byste se chtěli setkat, protože to svědčí o přetíženém virtuálním počítači a/nebo hostiteli. CPU ready je doba, po kterou je virtuální počítač připraven (potřebuje) cykly CPU na fyzickém hostiteli, ale musí čekat na získání času, protože jiné virtuální počítače již prostředky využívají.

Výpočet doby připravenosti může být bolestivý, protože závisí na intervalu dotazování pro metriku prezentovanou na hostiteli virtuálního počítače, např. 20 sekund (20 000 milisekund):

(hodnota připravenosti CPU / 20 000 ms) x 100 % = Procentuální vliv na výkon za 20sekundový interval.

Pokud provedete extrapolaci v průběhu času, můžete rychle zjistit, jak by to způsobilo snížení výkonu, zejména pokud používáte vysoce výkonné aplikace, jako je SQL server.

Hodnoty připravenosti < 5 % na vCPU jsou obecně v pořádku. Hodnoty připravenosti >5 % na vCPU jsou varováním a pravděpodobně již dochází ke snížení výkonu.

Bez nesprávné konfigurace není vůbec těžké najít hodnoty připravenosti CPU >=10 % kvůli některým velkým virtuálním počítačům s několika vCPU běžícími na několika fyzických jádrech nebo podobnému nepoměru mezi vCPU a pCPU.

Pokud je samotný virtuální počítač nadměrně zajišťován, např. VM s 8 vCPU musí počkat, až bude všech 8 pCPU na základním hostiteli VM volných, než získá jakékoli hodinové cykly. Zde přichází na řadu správná velikost. Pokud virtuální počítač skutečně potřebuje velký počet vCPU, rozhodně je přidejte. Pokud upravujete velikost pro novou aplikaci, přidávejte vCPU pouze při sledování výkonu. Správce úloh systému Windows není skvělým ukazatelem výkonu ve virtualizovaném prostředí, a proto jej monitoruje ze strany hostitele virtuálního počítače. Pokud jsou všechny vCPU maximalizovány, pravděpodobně bude potřeba více vCPU. Pokud ne, nechte dost na pokoji. Viděl jsem situace, kdy odstranění vCPU z virtuálního počítače ve skutečnosti zlepšilo výkon aplikací s databázemi hostovanými na tomto virtuálním serveru SQL.

Pokud je hostitel virtuálního počítače nadměrně zajišťován, pak na tomto hostiteli běží několik virtuálních počítačů, které všechny soutěží o prostředky. Pokud je to váš případ, měli byste migrovat některé virtuální počítače na jiné hostitele, abyste zmírnili problémy s konflikty zdrojů.

Ekvivalentem CPU ready na Hyper-V je čítač Perfmon Hyper-V Hypervisor Virtual Processor\CPU Čekací doba na odeslání, který je k dispozici od Windows Server 2012.

Hyper-threading

Hyper-threading je technologie Intel, která zpřístupňuje dva hardwarové kontexty (vlákna) z jednoho fyzického jádra. Tato vlákna se označují jako logické CPU. Je běžnou mylnou představou, že hyper-threading zdvojnásobuje počet CPU nebo jader. To prostě není tento případ. Hyper-threading zlepšuje celkovou propustnost hostitele z 10-30% tím, že udržuje procesorový kanál zaneprázdněnější a poskytuje hypervizoru více příležitostí k plánování taktovacích cyklů CPU, takže byste rozhodně měli využít výhody hyper-threading tím, že ho povolíte v BIOSu virtuálního počítače. hostitelský stroj.

Jádra na soket

NUMA (Non-Uniform Memory Access) přiděluje každému CPU jeho vlastní lokální paměť. Kombinace CPU a paměti se nazývá uzel NUMA. Výhodou NUMA je, že umožňuje procesoru přistupovat ke své vlastní lokální paměti rychleji než k nelokální paměti. Windows i SQL jsou plně informovány o NUMA a rozhodují o plánování pro vlákna na základě topologie NUMA.

vNUMA představuje architekturu NUMA fyzického hostitele virtuálního počítače přímo hostujícímu OS virtuálního počítače. Topologie vNUMA virtuálního počítače může zahrnovat více fyzických uzlů NUMA. Po zapnutí virtuálního počítače s podporou vNUMA nelze architekturu prezentovanou operačnímu systému změnit. To je vlastně pozitivní věc, protože změna architektury vNUMA může způsobit nestabilitu operačního systému. Toto omezení však může způsobit problémy, pokud dojde k pokusu o migraci virtuálního počítače na jiného hostitele virtuálního počítače, který má jinou architekturu NUMA.

vNUMA je ve výchozím nastavení povoleno pro virtuální počítače, které mají více než 8 vCPU (bez ohledu na kombinaci soketů a jader, která tvoří počet vCPU ve hře).

Doporučený postup:

Počet virtuálních soketů by se měl rovnat počtu požadovaných vCPU (jedno jádro na soket).

Toto je výchozí nastavení při vytváření virtuálního počítače. Tato konfigurace je známá jako široká a plochá a vNUMA představí hostujícímu operačnímu systému optimální topologii vNUMA na základě topologie NUMA hostitelského serveru fyzického virtuálního počítače. Pokud konfigurace virtuálního počítače není široká a plochá, pak vNUMA nebude moci automaticky vybrat nejlepší konfiguraci NUMA a místo toho bude jednoduše odpovídat jakékoli konfiguraci, kterou jste zadali, což může vést k neshodě topologie NUMA, která má škodlivý vliv na výkon.

Licenční omezení jsou nejčastějším důvodem, proč se správci rozhodli jít proti těmto osvědčeným postupům. Pokud to musíte použít, ujistěte se, že zrcadlíte alespoň topologii NUMA hostitele fyzického virtuálního počítače.

Přidávání za chodu CPU

Toto nastavení může být trochu háček 22 – aktivace a deaktivace má své výhody a nevýhody.

Pros

CPU hot plug umožňuje správcům virtuálních počítačů přidávat CPU do virtuálních počítačů za běhu, aniž by museli virtuální počítač nejprve vypínat. CPU hot plug umožňuje dynamickou správu prostředků a možnost přidávat CPU, když není vyžadována vNUMA (obvykle menší virtuální počítače).

Nevýhody

Když je na virtuálním počítači povoleno přidávání za běhu CPU, automaticky se deaktivuje vNUMA. SQL servery, které jsou širší než architektura NUMA fyzického serveru, na kterém jsou umístěny, nevidí základní architekturu NUMA, což vede ke snížení výkonu.

Zda povolit nebo nepovolit CPU hot-add, záleží na tom, jak široký bude váš VM. Moje doporučení je zakázat přidávání CPU za běhu pro větší virtuální počítače, které vyžadují vNUMA. Prevence je vždy lepší než léčba, a proto si dejte čas na správnou velikost CPU virtuálního počítače SQL serveru, než abyste se spoléhali na přidávání CPU za chodu jako záložní řešení.

Afinita CPU

Nedoporučuji používat afinitu CPU na produkčních strojích, protože to omezuje schopnost hypervizoru efektivně plánovat vCPU na fyzickém serveru.

Nepřetěžujte paměť hostitele virtuálního počítače

Opět to nelze dostatečně zdůraznit. Při počátečním určování velikosti virtuálního počítače SQL se ujistěte, že hostitel není a nebude přetížen, když je virtuální počítač SQL zapnutý. Nezapomeňte, že hostitelský počítač VM má svou vlastní paměť, aby mohl provozovat také operační systém hypervizor!

Rezervace paměti

SQL server je pamětní prase, takže jakákoliv paměť, kterou mu hodíte, bude použita a nebude uvolněna. Proto může mít smysl nastavit rezervaci paměti pro virtuální počítač SQL tak, aby se rovnala přidělené paměti mínus 4–6 GB pro fungování systému Windows. To výrazně sníží pravděpodobnost bublin a záměny a zaručí, že virtuální stroj dostane paměť, kterou potřebuje pro optimální výkon. Rezervace paměti však mohou zabránit migraci virtuálních počítačů mezi hostiteli, pokud cílový hostitel nemá nerezervovanou paměť stejnou nebo větší, než je velikost rezervace paměti.

Postup výpočtu množství paměti k zajištění pro virtuální počítač:

Vyhrazená vs dynamická paměť

ANO , je to v rozporu se základy virtualizace, takže tento boj s administrátorem virtualizace můžete prohrát, ale stojí za to se o to hádat. Vyhrazené zdroje znamenají, že můžete z rovnice vyřadit boj o zdroje na hostiteli VM.

Paměť je jedním z největších faktorů, pokud jde o výkon SQL Serveru. SQL používá paměť pro svou vnitřní vyrovnávací paměť (nedávno použitá data) a mezipaměti procedur (nedávno prováděné příkazy T-SQL). Tyto vyrovnávací paměti znamenají, že SQL Server může získat data a příkazy, které vyžaduje, z mezipaměti, místo aby musel přecházet na disk a vynakládat související I/O režii. SQL Server může automaticky spravovat a rozšiřovat svou vyrovnávací paměť a mezipaměť procedur na základě požadavků pracovního zatížení a paměti, která je k dispozici. Pokud není k dispozici žádná paměť, bude to mít vliv na výkon.

Pokud váš správce virtualizace vyloučil vyhrazenou paměť, zeptejte se na konfigurace přetížení paměti Hyper-V nebo VMware.

VMware zachází s pamětí jako se sdíleným zdrojem a každý megabajt paměti je považován za individuální sdílenou složku. Překročení paměti je automatizovaný dynamický proces, který odebírá sdílené položky z virtuálních počítačů, které je nepoužívají, a podle potřeby je přiděluje jiným virtuálním počítačům.

Paměť se získává z virtuálních počítačů, které mají méně proporcionální podíly, aby se poskytla virtuálním počítačům s proporcionálnějším podílem, a proto se ujistěte, že virtuální počítač SQL má dostatečně vysokou váhu podílů.

Dynamická paměť Hyper-V také dynamicky distribuuje nevyužitou paměť. V obou technologiích si virtuální počítače ponechají 25 % nevyužité paměti jako polštář pro případ, že by náhle vyžadovaly více paměti.

Stojí za zmínku, že datacenter nebo Enterprise edice SQL 2008 nebo novější jsou vyžadovány pro podporu hot-add RAM. Operační systémy Microsoft pro servery jsou od verze W2K3r2sp2 kompatibilní s hot-add.

Neukládat soubory na stejný disk

Soubory OS, datové soubory SQL, soubory protokolu SQL, zálohy SQL atd... všechny skončí na stejném VHD, pokud vytvoříte virtuální počítač s výchozím nastavením nastavení a nainstalujte SQL s výchozím nastavením.

Binární soubory SQL Serveru, datové soubory by měly být umístěny na samostatných VMDK.

Pro nejlepší výkon a dostupnost použijte RAID 10 pro uživatelská data, soubory protokolu a soubory TempDB.

Podívejte se na můj předchozí příspěvek o doporučených postupech pro SQL server ve vztahu k dimenzování tempdb.

Závěr

Virtualizovaný SQL Server může poskytnout výkon a škálovatelnost pro podporu produkčních databázových aplikací, pokud budou dodržovány osvědčené postupy.

Toto je vícedílná série o doporučených postupech pro SQL Server. Přečtěte si část I.

Zdroje:

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