Microsoft Azure poskytuje databázový stroj Platform as a Service (PaaS) prostřednictvím platformy Azure SQL Database, takže tuto databázi můžeme používat pro cloudové aplikace. Hlavní výhodou Azure SQL Database je umožnění snadného škálování s nulovými prostoji a nevyžaduje žádný proces upgradu verze nebo opravy. Také se nemusíme starat o problémy s hardwarem.
Důležitým aspektem Azure SQL Database je však splnění požadavků na výkon nasazené databáze s minimálními náklady. Nikdo nepochybně nechce platit peníze za nadbytečné zdroje nebo funkce, které nevyužívá nebo neplánuje používat.
V tuto chvíli nabízí Microsoft Azure dva různé modely nákupu, které poskytují nákladovou efektivitu:
- Nákupní model založený na databázové transakční jednotce (DTU).
- Model nákupu založený na virtuálním jádru (vCore)
Rozhodnutí o modelu nákupu přímo ovlivňuje výkon databáze a celkovou výši účtů. Podle mého názoru, pokud nasazená databáze nebude spotřebovávat příliš mnoho zdrojů, bude vhodnější model nákupu založený na DTU.
Nyní probereme podrobnosti o těchto dvou modelech nákupu v následujících částech.
Model nákupu založený na databázové transakční jednotce (DTU)
Abychom lépe porozuměli nákupnímu modelu založenému na DTU, musíme si ujasnit, co dává smysl DTU v Azure SQL Database. DTU je zkratka pro „Database Transaction Unit“ a popisuje metriku jednotky výkonu pro Azure SQL Database. DTU můžeme mít rádi v koňských silách v autě, protože přímo ovlivňuje výkon databáze. DTU představuje směs následujících metrik výkonu jako jedna jednotka výkonu pro Azure SQL Database:
- CPU
- Paměť
- Datové I/O a Log I/O
Hlavní myšlenkou konceptu DTU je nabídnout klientům předkonfigurovanou konfiguraci zdrojů tak, aby se zjednodušilo škálování výkonu v rámci jedné metriky. Pokud například potřebujeme vyšší výkon, můžeme posunout laťku a zvýšit počet DTU v Azure SQL Database.
Nákupní model založený na DTU obsahuje tři různé úrovně služeb a tyto úrovně služeb nabízejí různé DTU a možnosti funkcí. Následující tabulka ilustruje úrovně služeb, které se účastnily nákupního modelu založeného na DTU.
Základní | Standardní | Prémiové | |
Cílová pracovní zátěž | Vývoj a výroba | Vývoj a výroba | Vývoj a výroba |
Dostupnost SLA | 99,99 % | 99,99 % | 99,99 % |
Maximální zachování zálohy | 7 dní | 35 dní | 35 dní |
CPU | Nízká | Nízká, Střední, Vysoká | Střední, Vysoká |
Propustnost IO (přibližná) | 1–5 IOPS na DTU | 1–5 IOPS na DTU | 25 IOPS na DTU |
Latence IO (přibližná) | 5 ms (čtení), 10 ms (zápis) | 5 ms (čtení), 10 ms (zápis) | 2 ms (čtení/zápis) |
Indexování úložiště sloupců | N/A | S3 a vyšší | Podporováno |
OLTP v paměti | N/A | N/A | Podporováno |
Maximální DTU | 5 | 3000 (S12) | 4000 (P15) |
Maximální velikost úložiště | 2 GB | 250 GB | 1 TB |
Jak vidíme, maximální DTU a funkce se liší podle jejich úrovně služeb. V souvislosti s úrovní služeb se také změní cenový model. Například následující konfigurace pro jednu databázi v modelu nákupu založeném na DTU bude 584,00 $ měsíčně.
Elastický bazén
Stručně řečeno, Elastic Pool nám pomáhá automaticky spravovat a škálovat více databází, které mají nepředvídatelné a různé požadavky na zdroje ve sdíleném fondu zdrojů. Prostřednictvím Elastic Pool nepotřebujeme neustále škálovat databáze podle kolísání poptávky po zdrojích. Databáze, které se podílejí na fondu, spotřebovávají zdroje elastického fondu, když jsou potřeba, ale nemohou překročit omezení zdrojů elastického fondu, takže poskytují nákladově efektivní řešení.
Správný odhad DTU pro Azure SQL Database
Poté, co se rozhodneme použít nákupní model založený na DTU, musíme zjistit následující otázku a odpověď s logickými důvody:
- Která úroveň služeb a kolik DTU jsou vyžadovány pro mé pracovní zatížení při migraci na Azure SQL?
Kalkulačka DTU bude hlavním řešením pro odhad požadavků na DTU, když migrujeme místní databáze do Azure SQL Database. Hlavní myšlenkou tohoto nástroje je zachycení různých metrik využití ze stávajícího SQL serveru, které ovlivňují DTU, a poté se pokusí odhadnout přibližně DTU a úroveň služeb ve světle shromážděných využití výkonu. Kalkulačka DTU shromažďuje následující metriky prostřednictvím nástroje příkazového řádku nebo skriptu PowerShell a ukládá tyto metriky do souboru CSV.
- Procesor – % času procesoru
- Logický disk – čtení disku/s
- Logický disk – zápis na disk/s
- Databáze – vyprázdnění logbajtů/s
V tomto článku se naučíme použití nástroje příkazového řádku, protože tento projekt s otevřeným zdrojovým kódem a kódy jsou hostovány na GitHubu. V případě potřeby tak můžeme snadno provádět změny. Po stažení a rozbalení nástroje Command-Line Utility, dva soubory přijdou před nás.
SqlDtuPerfmon.exe.config nám pomáhá určit některé parametry nástroje příkazového řádku:
CsvPath určuje cestu k souboru CSV, kde budou uloženy shromážděné metriky.
SampleInterval určuje, v kolika sekundových intervalech budou vzorky shromažďovány
MaxSamples určuje maximální počet vzorků, které budou shromážděny.
V tomto okamžiku musíme vzít v úvahu některé úvahy o kalkulačce DTU. Kalkulačka DTU shromažďuje celkové využití metrik v počítači. Z tohoto důvodu musí být zastaveny ostatní procesy, které ovlivňují spotřebu CPU, paměti a disku, jinak bude obtížné provést přesný odhad DTU. Dalším problémem je, pokud je to možné, musíme shromáždit využití metrik, které pokrývají časové intervaly špičkové pracovní zátěže. Kalkulačka DTU tak nabízí nejlepší doporučení a my zjistíme maximální požadavek na DTU s přibližnějším odhadem. Nyní spustíme SqlDtuPerfmon.exe a ten začne přímo shromažďovat využití zdrojů a ukládat určený soubor CSV.
Po dokončení sběru využití zdrojů zadáme počet jader a nahrajeme soubor CSV na webovou stránku DTU Calculator.
Když klikneme na tlačítko Vypočítat, nejprve se na obrazovce objeví koláčový graf úrovně služeb/úrovně výkonu a zobrazuje rozdělené návrhy odhadovaných úrovní služeb na řezy s procentuálními podrobnostmi. Podle DTU Calculator bude úroveň Standard - S6 poskytovat uspokojivý výkon pro tuto zátěž.
Hned pod tímto grafem je zobrazen graf DTU v průběhu času a tento graf představuje změny DTU v daném časovém období. Před vyhodnocením tohoto grafu můžeme přidat některé další informace, abychom jej mohli snadněji interpretovat.
Jak vidíte, spojnicový graf představuje nestabilní pracovní zátěž, ale dávalo to větší smysl, když jsme přidali informační poznámky. Podle mého názoru je tento graf velmi užitečný pro pochopení interakce mezi změnami pracovní zátěže a DTU. Můžeme tak provést přesnější odhad požadovaných DTU. Jak jsme uvedli na začátku článku, naším hlavním cílem by mělo být najít nákladově efektivní řešení pro pracovní zátěž.
Tyto návrhy však nevyjadřují přesné požadavky DTU v Azure SQL. Z tohoto důvodu možná budeme muset po nasazení databáze do Azure SQL změnit úroveň služeb nebo model nákupu.
Když klikneme na Zobrazit další podrobnosti, zobrazí se některé další zprávy a tyto zprávy představují jednotlivá doporučení pro využití prostředků CPU, IOPS a Log. Budou velmi užitečné pro pochopení zejména těchto využití.
Model nákupu založený na virtuálním jádru (vCore)
Tento koncept je podobný tradičnímu přístupu, protože jsme schopni rozhodnout o každém zdroji databáze. V tomto modelu můžeme ručně uspořádat možnosti VCores a maximální velikost dat. Nemůžeme však určit paměťový zdroj. Každé virtuální jádro je dodáváno s vyhrazenou pamětí a vyhrazená hodnota paměti závisí na generaci virtuálních jader.
Nakonec si v tomto modelu můžeme vybrat následující úrovně služeb:
- Obecný účel.
- Obchodně kritické.
- Hyperškála
Závěr
V tomto článku jsme prozkoumali modely nákupu Azure SQL Database a odhalili jsme pokyny k použití kalkulačky DTU, abychom mohli odhadnout požadovanou DTU v Azure SQL pro místní databáze.