sql >> Databáze >  >> RDS >> Database

Důležitost výběru správné velikosti virtuálního počítače Azure

Migrace místní instance SQL Serveru do Azure Virtual Machine (VM) je běžnou metodou migrace do Azure. IT odborníci jsou obeznámeni s rozsahem velikosti virtuálních počítačů s ohledem na vCPU, paměť a kapacitu úložiště. Společnost Microsoft nabízí několik typů a velikostí virtuálních počítačů pro potřeby organizace. Uvidíte typy označené jako Family na Azure Portal při určování velikosti virtuálního počítače.

Typy a velikosti virtuálních počítačů

Microsoft pomohl věci zjednodušit vytvořením více typů virtuálních strojů. Typy jsou zaměřeny na definování strojů podle účelu. Různé typy jsou:

  • Obecný účel – Vyvážený poměr CPU k paměti, malé až střední databáze
  • Optimalizace pro výpočet – vysoký poměr CPU k paměti, středně zatížené webové servery a aplikační servery
  • Optimalizovaná paměť – Vysoký poměr paměti k CPU, relační databázové servery, střední až velké mezipaměti a analýzy v paměti
  • Optimalizováno úložiště – Vysoká propustnost disku a IO
  • GPU – náročné vykreslování grafiky a úpravy videa
  • Vysoce výkonný výpočet – nejrychlejší a nejvýkonnější virtuální stroje s CPU

V rámci každého typu/rodiny je na výběr z mnoha velikostí. Velikosti vám nabízejí možnosti pro počet vCPU, RAM a datových disků. Počet datových disků určí maximální IOPS (IOPS znamená vstupně/výstupní operace za sekundu.) a celková velikost určí velikost dostupného dočasného úložiště. Některé velikosti také podporují prémiové úložiště, které by mělo být požadavkem pro produkční SQL Server.

Možnosti obrazu virtuálního počítače

Při výběru obrázku pro SQL Server máte několik možností. Můžete si vybrat pouze OS, jako je Linux nebo Windows, nebo si můžete vybrat obrázek s již nainstalovaným OS a SQL Serverem. V současné době dávám přednost výběru obrazu pouze s OS, abych si mohl nainstalovat SQL Server a nakonfigurovat jej tak, jak se mi líbí. Když zvolíte obraz galerie s předinstalovaným SQL Serverem, nainstalují se všechny součásti, které jsou zahrnuty v ISO pro danou verzi, a já ne vždy potřebuji nainstalované Integration Services nebo Analysis Services.

Úvahy o velikosti virtuálního počítače

Výběr virtuálního počítače Azure se může zdát přímočarý, s výběrem velikosti na základě počtu vCPU, paměti a dostatečného úložiště pro vaše databáze, ale vidím, že zákazníci mají problémy s výkonem související s úložištěm. Běžným trendem je vybrat si virtuální počítač založený výhradně na vCPU, paměti a úložné kapacitě bez srovnávání aktuálních požadavků IO a propustnosti. Když vytvoříte virtuální počítač Azure v Azure Portal, můžete filtrovat možnosti na základě následujícího:

  • Velikost
  • Generování
  • Rodina
  • RAM/paměť
  • Podpora prémiového úložiště
  • Počet vCPU
  • Dočasný disk OS

Jakmile vyberete možnosti filtru, pokud existují, zobrazí se seznam dostupných serverů. V seznamu se zobrazí velikost virtuálního počítače, nabídka, rodina, vCPU, RAM, počet podporovaných datových disků, maximální IOPS, dočasné úložiště (D:), pokud je podporován prémiový disk, a odhadovaná cena. Vyfiltroval jsem následující na podporovaném prémiovém disku a velikosti začínající písmenem E pro optimalizaci paměti.

Co se však nezobrazuje, je povolená propustnost na virtuální počítač. Propustnost měří rychlost přenosu dat do az paměťového média v megabajtech za sekundu.

Propustnost lze vypočítat pomocí následujícího vzorce

MB/s =IOPS * KB na IO / 1 024

Pomocí tohoto vzorce by KB na IO byla velikost vašeho bloku. Pokud formátujete data a jednotky protokolů na 64 kB, vzorec pro virtuální počítače E2s_v3, E4-2s_v3 a E8-2s_v3 s 3 200, 6 400 a 12 800 IOPS by byl:

MB/s =3 200 * 64/1 024 nebo 200 MB/s
MB/s =6 400 * 64/1 024 nebo 400 MB/s
MB/s =12 800 * 64/1 024 nebo 800 MB/s

Výpočty propustnosti založené na IOPS každého virtuálního počítače s velikostí bloku 64 kB nejsou příliš špatné. Tato čísla neberou v úvahu žádné sankce za zápis pro RAID. Každý z těchto virtuálních počítačů jsem otestoval pomocí CrystalDiskMark. Čísla, která jsem získal pro propustnost, se ani zdaleka neblížily tomu, co odhadovaly výpočty.

Srovnávací test

Poskytl jsem tři virtuální počítače stejné rodiny, ale různých velikostí, a každý se 2 vCPU. Specifikace virtuálních strojů byly:

  • E2s_v3 – 2 vCPU – 16 GB RAM – 3 200 IOPS – Podpora až 4 datových disků
  • E4-2s_v3 – 2 vCPU – 32 GB RAM – 6 400 IOPS – Podpora až 8 datových disků
  • E8-2s_v3 – 2 vCPU – 64 GB RAM – 12 800 IOPS – Podpora až 16 datových disků
  • Datový disk P60 – Premium SSD – 16 000 IOPS

Na každém virtuálním počítači jsem zřídil prémiový disk P60 s kapacitou 8 TB. Tento disk inzeroval 16 000 IOPS, což by při velikosti bloku 64 kB mohlo podporovat propustnost 1 000 MB/s, nicméně dokumentace Azure uvádí, že disk poskytuje propustnost 500 MB/s.

CrystalDiskMark je nástroj pro testování diskových jednotek s otevřeným zdrojovým kódem pro Windows a je založen na nástroji Diskspd společnosti Microsoft. Nástroj měří sekvenční a náhodný výkon čtení a zápisu.

V horní části nástroje jsou některé rozevírací seznamy. Číslo 5 je počet opakování testu, který bude spuštěn. Další je 1GiB, to je velikost testovacího souboru. Pro skutečný produkční test by to mělo být dostatečně velké, aby se zabránilo zasažení mezipaměti. Verze 7.0 podporuje až 64 GiB soubor. Poslední je disk, na kterém chcete provést test.

Jakmile provedete výběr, můžete kliknout na Vše a zahájit sérii testu. Test bude procházet různými sekvenčními a náhodnými operacemi čtení/zápisu. Pokud plánujete srovnávat skutečné produkční servery, buďte opatrní. Tento test zatěžuje váš disk a může výrazně ovlivnit produkční zátěž. Preferováno by bylo po pracovní době nebo během období údržby.

Rozhodl jsem se spustit 5 iterací testu se souborem 32 GiB na disku P60, což byla jednotka E:.

VM E2s_v3 dosáhl maximální rychlosti pod 50 MB/s, což je mnohem méně než 200 MB, které jsme vypočítali.

VM E4-2s_v3 dosahoval maximální rychlosti pod 100 MB/s místo 400 MB/s.

VM E8-2s_v3 dosahoval maximální rychlosti pod 200 MB/s namísto odhadovaných 800 MB/s.

Proč nižší propustnost?

Na základě mých dřívějších výpočtů by 3 200 IOPS při velikosti bloku 64 kB mělo produkovat propustnost 200 MB, ale čísla blízko tomu jsem neviděl, dokud jsem neměl disk s 16 000 IOPS na virtuálním počítači, který podporuje až 12 800 IOPS. Důvodem je, že každá velikost virtuálního počítače má limit pro propustnost. Pokud se podíváte do dokumentace pro rodinu virtuálních počítačů s optimalizovanou pamětí, zjistíte, že maximální propustnost disku bez mezipaměti E2s je 3 200 IOPS / 48 MB/s, maximální propustnost disku bez mezipaměti E4 je 6 400 IOPS / 96 MB/s a maximální propustnost disku E8 bez mezipaměti propustnost je 12 800 IOPS / 192 MBps. Tato čísla se shodují s výsledky, které jsem získal pomocí CrystalDiskMark.

I když můžete alokovat velmi velké disky, které mají dostatek IOPS a podporují vysokou propustnost, velikost virtuálního počítače může velmi dobře omezovat vaši propustnost.

Před migrací jakékoli zátěže SQL Serveru do Azure by mělo být velkou prioritou srovnávání vašich aktuálních potřeb propustnosti.

Závěr

Chápu, že IOPS je jednotka měření, kterou poskytují výrobci disků a prodejci úložišť, a to je v pořádku. Pokud však jde o testování úložiště, máme tendenci se více soustředit na čísla propustnosti. Je to jen matematický problém, ale pokud se nezabýváte srovnáváním úložiště a prováděním výpočtů od IOPS po propustnost na základě velikosti bloku, může to být matoucí.

Co mě znepokojuje, je skutečnost, že při výběru velikosti virtuálního počítače není jasné omezení propustnosti. Jednotkou měření pro úložiště IO je IOPS. Při 3 200 IOPS s velikostí bloku 64 kB bych mohl být kolem 200 MB/s, ale můj VM byl omezen na 48 MB/s. Mnoho IT profesionálů zjistilo, že mají problémy s výkonem disku a škálovalo své úložiště na větší a rychlejší disk (více IOPS) s očekáváním lepšího výkonu, jen aby zjistili, že to jejich problém nevyřešilo. Problém je v tom, že velikost virtuálního počítače omezovala jejich propustnost. Škálování na vyšší velikost virtuálního počítače by problém vyřešilo, ale stojí to za to. V mém příkladu byla E4 dvakrát dražší než E2, nicméně zdvojnásobila paměť a propustnost, přičemž si zachovala stejný vCPU. E8 byla dvojnásobná oproti E4 a zdvojnásobila propustnost a paměť, při zachování stejného vCPU. Zachování stejného počtu vCPU znamená, že by se mi nezvýšily náklady na základní licenci SQL Server.

Nakonec musíte porovnat své aktuální požadavky na propustnost a ujistit se, že velikost virtuálního počítače Azure nebo jakéhokoli virtuálního počítače odpovídá vašim potřebám. Nesoustřeďte se pouze na benchmark vašeho místního úložiště, analyzujte, co vaše pracovní zatížení potřebuje a podle toho velikost.


  1. Správa uživatelských účtů, role, oprávnění, autentizace PHP a MySQL -- Část 5

  2. Připojení Pythonu k databázi MySQL pomocí konektoru MySQL a příkladu PyMySQL

  3. Chyba PostgreSQL při pokusu o vytvoření rozšíření

  4. Chyba Heroku PostgreSQL GROUP_BY v aplikaci Rails