Cloudová migrace slibuje efektivitu, ale pro pracovní zátěž Microsoft SQL Server „levnější“ infrastruktura často vede k přemrštěnému plýtvání. Při nasazování na burstable instance – jako je Azure B-Series, AWS T-Series nebo GCP E2 – organizace často upadnou do specifické licenční pasti, kde se starší modely založené na jádru střetávají s moderním měřením služeb.
Tato zpráva rozebírápravidlo „4jádrové minimum“., odhaluje skryté"I/O daň"omezování burstable storage a vysvětluje, proč vás nízkonákladové virtuální počítače mohou stát dvojnásobek softwarových poplatků při poskytování omezeného výkonu. Analyzujeme konkrétní rizika"Ukrást čas"a vyčerpání kreditů, které vám pomohou vyhnout se ekonomickým nástrahám provozování podnikových databází na zlomkovém hardwaru.
Licencování SQL Server: Analýza napříč cloudy | GigXP
GigXP
Tech Intelligence / Enterprise Database / Aktualizováno v říjnu 2025
Ekonomika odpadu: SQL Server na Burstable Cloud CPU
Výzkumný tým
Migrace cloudu změnila vztah mezi poskytováním infrastruktury a licencováním softwaru. Cloud computing slibuje elasticitu a efektivitu. Platíte za to, co používáte. Starší softwarové licenční rámce, konkrétně ty Microsoft SQL Server, zůstávají zakořeněny ve fyzických hardwarových paradigmatech. Toto tření je nejzřetelnější při nasazení SQL Serveru na „burstable“ výpočetní instance: B-series v Microsoft Azure, T-series v Amazon Web Services (AWS) a E2 nebo N1 typy počítačů se sdíleným jádrem v Google Cloud Platform (GCP).
Burstable instance jsou navrženy tak, aby demokratizovaly přístup k výpočtům pro občasné pracovní zátěže. Představují klamavou hodnotu pro databázové aplikace. Náklady na infrastrukturu 2-vCPU burstable Virtual Machine (VM) jsou zanedbatelné. Závazky týkající se licencí na software vytvářejí vysoké „náklady“, které narušují celkové náklady na vlastnictví (TCO). Závazek, že každé prostředí virtuálního operačního systému (OSE) musí licencovat minimálně čtyři jádra, nutí organizace platit za neexistující kapacitu při využívání malých velikostí instancí.
Základní problém
U malých burstable instancí se náklady na softwarovou licenci neškálují lineárně s infrastrukturou. VM se 2 vCPU má stejné licenční náklady jako VM se 4 vCPU. To zdvojnásobí náklady na software na jádro pro menší stroj.
1. Licenční past
Moderní cloudová ekonomika spoléhá na granulární měření. Burstable instance prodává cykly CPU jako nástroj. Uživatel si zakoupí základní část fyzického jádra a nasbírá kredity během období nečinnosti. Tento model se opírá o statistickou pravděpodobnost, že ne všichni tenanti na fyzickém hostiteli prasknou současně.
Microsoft SQL Server používá model licencování založený na jádru navržený k zachycení hodnoty na základě potenciálního výpočetního výkonu. Od roku 2012 Microsoft váže ceny na počet procesorových jader. Pravidlo „4jádrové minimum“ diktuje, že i když virtuální stroj funguje na jediném virtuálním jádru, zákazník si musí zakoupit čtyři základní licence. To platí pro SQL Server 2022 a aktualizace 2025.
Obrázek 1: „Value Gap“ mezi náklady na infrastrukturu a náklady na povinné licence (odhad. hodinové USD).
Tento rozpor vytváří „hodnotovou past“. Nízká hodinová sazba infrastruktury láká uživatele k nasazení, kde náklady na licence softwaru výrazně převyšují náklady na infrastrukturu.
2. Technická architektura: Riziko „ukrást čas“.
Výkon na burstable instancích závisí na interakci mezi plánovačem databázového stroje a řízením prostředků hypervizoru.
Ve standardních případech poskytuje hypervizor pevné mapování pro vCPU. V burstable instancích jsou fyzická jádra přepsána. Hypervizor to zvládá pomocí kreditního plánovače. Když požadavek na virtuální počítač překročí svůj základní nárok, plánovač zkontroluje zůstatek kreditu.
- Pozitivní bilance:Plánovač umožňuje virtuálnímu počítači spotřebovávat fyzické cykly až do limitu burst.
- Nulový zůstatek:Plánovač omezuje VM. Omezuje dobu provádění na základní procento.
Pro SQL Server je toto omezení neprůhledné. Operační systém může CPU vnímat jako dostupný. Instrukce nejsou prováděny fyzickým hardwarem. Tím se vytvoří „Steal Time“ nebo „Hypervisor Wait“. Hostující OS se chce spustit, ale je nedobrovolně pozastaven.
Spirála smrti
SQL Server využívá kooperativní multitasking prostřednictvím operačního systému SQL Server (SQLOS). Vlákna dobrovolně uvolňují CPU, aby umožnila běh ostatním pracovníkům. U omezené instance hypervizor zruší plánování vCPU z fyzického jádra. Vlákno SQL se zaseklo. Ostatní vlákna čekající na prostředky zamčené zmrazeným vláknem se začnou otáčet. To spálí zbývající kapacitu CPU v marné smyčce.
Obrázek 2: Simulace algoritmu Token Bucket v reálném čase. Podívejte se, jak rychlá spotřeba vyčerpává banku.
3. Skryté náklady „I/O Tax“.
Zatímco kredity CPU přitahují největší pozornost, úložný subsystém burstable instancí představuje bezprostřednější hrozbu pro stabilitu databáze. SQL Server používá protokol WAL (Write-Ahead Logging). Každá změna musí být zapsána do protokolu transakcí na disku před potvrzením transakce.
Burstable instance (jako Azure B-series v1 nebo AWS T3) omezují propustnost úložiště (MB/s) a IOPS na základě velikosti instance. Instance 2 vCPU má často základní propustnost pouhých 8 MB/s. Pokud vyprázdnění protokolu transakcí dosáhne tohoto stropu, stroj SQL se pozastaví a shromažďuje sePAGEIOLATCHčeká.
Operační riziko
Během „burst“ událostí uživatelé často připisují CPU za zpomalení, ale 60 % výkonových lístků burstable instance ve skutečnosti omezuje úložiště. CPU nečinně čeká na disk, přesto „vnímaná“ pomalost vede administrátory k upgradu instance, což dále zvyšuje plýtvání licencí.
4. Paradox okna údržby
Úlohy údržby databáze – přestavby indexů, kontroly konzistence (DBCC CHECKDB) a statistické aktualizace – jsou náročné na zdroje. Na vyhrazeném hardwaru tyto běží mimo pracovní dobu bez jakýchkoliv postihů. Na burstable instancích tyto úlohy spotřebovávají nashromážděné kredity CPU.
Noční přestavba indexu ve 2:00 může kreditní banku zcela vyčerpat. Když pracovní den začíná v 8:00, instance má 0 kreditů a pracuje na svém základním výkonu (často 10 % až 20 % jádra). „Ranní špička“ uživatelských přihlášení zasáhne omezený server a způsobí časové limity.
Simulace vyčerpání kreditu
| Aktivita | Trvání | Zatížení CPU | Úvěrový dopad |
|---|---|---|---|
| Nečinný (denní) | 1 hodina | 5% | +6 kreditů(Čistý zisk) |
| Obnovení indexu | 30 minut | 100% | -30 kreditů(Rychlý odtok) |
| Ranní přihlášení | 15 min | 80% | Přiškrcený(Pokud je banka prázdná) |
5. Zúčtování platformy a nákladové modely
Každý velký poskytovatel cloudu nakládá s touto architekturou jinak. Pomocí filtru níže zobrazíte specifika vaší platformy.
Všechny platformy
Blankyt
AWS
GCP
| Platforma | Instance Family | Klíčový mechanismus | Licenční riziko |
|---|---|---|---|
| Blankyt | B-Series (v1 a v2) | Úvěrové bankovnictví. Tvrdý plyn, když kredity zmizí na v1. | PAYG cena zahrnuje minimální přirážku pro 4 jádra. Disk IO často vázne před CPU. |
| AWS | Řada T (T3/T3a) | Režim „Neomezený“ je ve výchozím nastavení povolen. | Finanční riziko. Pokud budete praskat příliš dlouho, zaplatíte přeplatky. Může překročit náklady na vyhrazenou instanci. |
| GCP | Sdílené jádro E2 | Přísné časové dělení (např. 0,5 vCPU trvalé). | Žádné slevy na trvalé užívání (SUD) na E2. Licenční náklady jsou v porovnání s dílčím hardwarem vysoké. |
Analýza Azure řady B
Řada B trpí nízkými limity propustnosti disku. Zápisy protokolu transakcí SQL Server jsou na to citlivé. Pokud protokol nelze vyprázdnit na disk, databáze se zastaví bez ohledu na kredity CPU. Azure Hybrid Benefit vám umožňuje přinést licence, ale stále spálíte 4 jádra oprávnění pro 2jádrový virtuální počítač.
Analýza AWS T-Series
Instance T3 mají výchozí režim „Neomezený“. Po vyčerpání kreditů instance praskne pomocí přebytečných kreditů účtovaných zhruba za 0,05 USD za hodinu vCPU. Pokud SQL Server vstoupí do smyčky spinlock, běží na 100 procent CPU neomezeně dlouho, což zčtyřnásobí hodinové náklady.
Analýza GCP E2
GCP používá typy počítačů se sdíleným jádrem, jako je e2-micro a e2-small. Tyto nabízejí trvalé záruky výkonu. Instance E2 se nekvalifikují pro slevy za trvalé užívání, což zužuje cenový rozdíl mezi nimi a standardními instancemi.
6. Strategická doporučení
„Nejlevnější“ varianta v ceníku je často nejméně efektivní. Minimální 4jádrová daň činí úspory nákladů u 2-vCPU přerušitelných instancí marginální ve srovnání s riziky výkonu.
Použít Web Edition:Pro veřejné úlohy má SQL Server Web Edition mnohem nižší cenu. Toto je jediný ekonomicky racionální způsob, jak používat praskavé instance pro výrobu.
Přepnout na PaaS:Azure SQL Database Serverless nebo AWS Aurora Serverless abstraktní jádro licencování. Platíte za vCore sekundy. Pokud se databáze pozastaví, účtování se zastaví.
Pouze vývoj:Použijte bezplatnou Developer Edition pro neprodukční prostředí na burstable hardwaru, abyste eliminovali náklady na licence.
Často kladené otázky
Platí pro SQL Server Express 4jádrové minimum?
Ne. SQL Server Express je zdarma k použití na libovolném počtu jader, i když je omezen omezeními enginu (1 GB RAM, 10 GB velikost DB).
Přečtěte si více:Upgrade SQL Server 2022: Oprava snížení výkonu z SQL 2016
Mohu zakázat hyperthreading, abych ušetřil na licencích?
Obecně ne. I když můžete hyperthreading zakázat na AWS (Optimize CPU), minimální požadavek na nákup od společnosti Microsoft zůstává 4 jádra na OSE. Snížením instance 2-vCPU na 1-vCPU se nesníží účet.
Je T3 Unlimited levnější než M5?
Pouze v případě, že vaše průměrné využití CPU zůstane pod základní úrovní (20 až 40 procent). Pokud běžíte trvale vysoko, přebytečné kreditní poplatky učiní T3 Unlimited dražší než fixní instance M5.
Vyhýbá se SQL Server na Linuxu (kontejnery) základnímu minimu?
Ne. Licencování kontejnerů (Kubernetes/Docker) vyžaduje, abyste licencovali vCPU dostupné pro kontejner. Pro každý kontejner (nebo prostředí OSE) však stále platí pravidlo o 4 jádrech. Nemůžete roztočit 10 kontejnerů s 1 jádrem a zaplatit za 10 jader; musíte zaplatit za 40 jader.
© 2025 GigXP Research. Všechna práva vyhrazena.