Vysvětlení možností PaaS pro nasazení SQL Serveru v Azure
Platforma jako služba (PaaS) poskytuje kompletní prostředí pro vývoj a nasazení v cloudu, které lze použít pro jednoduché cloudové aplikace a pokročilé podnikové aplikace.
Azure SQL Database a Azure SQL Managed Instance jsou součástí nabídky PaaS pro Azure SQL.
Azure SQL Database – Součástí řady produktů založených na modulu SQL Serveru v cloudu. Poskytuje vývojářům velkou flexibilitu při vytváření nových aplikačních služeb a podrobných možností nasazení ve velkém měřítku. SQL Database nabízí řešení s nízkou údržbou, které může být skvělou volbou pro určité úlohy.
Spravovaná instance Azure SQL – Nejvhodnější je pro většinu scénářů migrace do cloudu, protože poskytuje plně spravované služby a možnosti.
Každá nabídka poskytuje určitou úroveň správy nad infrastrukturou, která se liší podle stupně nákladové efektivity.
Modely nasazení
Azure SQL Database je k dispozici ve dvou různých modelech nasazení:
Jednoúčelová databáze – Jedna databáze, která se účtuje a spravuje na úrovni databáze. Jednotlivé databáze spravujete jednotlivě z hlediska škálování a velikosti dat. Každá databáze nasazená v tomto modelu má vlastní vyhrazené prostředky, i když je nasazená na stejný logický server.
Elastické fondy – Skupina databází, které jsou spravovány společně a sdílejí společnou sadu prostředků. Elastické fondy poskytují nákladově efektivní řešení modelu aplikace softwaru jako služby, protože prostředky se sdílejí mezi všemi databázemi. Prostředky můžete nakonfigurovat na základě nákupního modelu založeného na jednotce DTU nebo nákupního modelu založeného na virtuálních jádrech.
Nákupní model
Všechny služby v Azure podporují fyzický hardware a máte možnost vybrat si mezi dvěma různými nákupními modely:
Jednotka databázové transakce (DTU)
Nákupní model založený na DTU se počítá na základě vzorce, který kombinuje výpočetní prostředky, úložiště a vstupně-výstupní prostředky. Je to dobrá volba pro zákazníky, kteří chtějí jednoduché, předem nakonfigurované možnosti prostředků.
Nákupní model DTU se dodává v několika různých úrovních služeb, jako je Basic, Standard a Premium. Každá úroveň má různé možnosti, které poskytují širokou škálu možností při výběru této platformy.
Z hlediska výkonu se úroveň Basic používá pro méně náročné úlohy, zatímco úroveň Premium se používá pro náročné požadavky na úlohy.
Výpočetní prostředky a prostředky úložiště jsou závislé na úrovni DTU a poskytují celou řadu možností výkonu s pevným limitem úložiště, uchováváním záloh a náklady.
Další informace o nákupním modelu DTU najdete v přehledu nákupního modelu založeného na DTU.
virtuální jádro
Nákupní model založený na virtuálních jádrech umožňuje zakoupit zadaný počet virtuálních jader na základě vašich úloh. vCore je výchozí nákupní model při nákupu prostředků Azure SQL Database. Databáze virtuálních jader mají specifický vztah mezi počtem jader a velikostí paměti a úložištěm, které databáze poskytuje. Nákupní model virtuálních jader podporuje Azure SQL Database i Spravovaná instance Azure SQL.
Databáze vCore můžete zakoupit i ve třech různých úrovních služeb.
| Úroveň služby | Nejlepší pro | Typ úložiště | Oneskorení přenosu | Úrovně výpočtů | Funkce odolnosti | Maximální velikost databáze |
|---|---|---|---|---|---|---|
| Pro obecné účely | Úlohy pro obecné účely | Azure Premium Storage | Vyšší než BC | Nasazené, bezserverové | není k dispozici | 4 TB (terabajtů) |
| Pro důležité obchodní informace | Vysoce výkonné úlohy | Místní disky SSD | Nejnižší | Poskytnuto | Integrovaná replika jen pro čtení, nejvyšší odolnost proti selhání | 4 TB (terabajtů) |
| Hyperscale | Rozsáhlé databáze | Azure Premium Storage | Liší se | Poskytnuto | Jedinečná architektura pro škálování | 100 TB |
Úroveň služby Pro obecné účely nabízí dvě možnosti výpočetních prostředků: Zřízené abezserverové. Dělené prostředky se předem přidělují a účtují se každou hodinu podle konfigurace virtuálních jader, ideální pro konzistentní úlohy. Bezserverové prostředky se automaticky škálují na základě poptávky a účtují se za sekundu, což je nákladově efektivní pro proměnné úlohy.
Bezserverová architektura
Pojem "Bezserverový" může být zavádějící, protože službu Azure SQL Database stále nasadíte na logický server pro připojení. Bezserverová úroveň je výpočetní úroveň, která automaticky škáluje prostředky nahoru nebo dolů na základě poptávky po úlohách. Pokud už úloha nevyžaduje výpočetní prostředky, databáze se pozastaví a během neaktivního období se bude účtovat jenom úložiště. Po pokusu o připojení se databáze obnoví a zpřístupní se.
Nastavení pro řízení pozastavení se nazývá zpoždění automatického pozastavení s minimální hodnotou 60 minut a maximální hodnotou sedmi dnů. Pokud databáze zůstane po danou dobu nečinná, pozastaví se.
Jakmile je databáze po zadanou dobu neaktivní, pozastaví se až do následného pokusu o připojení. Konfigurace rozsahu automatického škálování výpočetních prostředků a zpoždění automatického pozastavení ovlivňuje výkon databáze a náklady na výpočetní prostředky.
Aplikace využívající bezserverovou architekturu by měly být nakonfigurované tak, aby zpracovávaly chyby připojení a zahrnovaly logiku opakování, protože připojení k pozastavené databázi generuje chybu připojení.
Dalším rozdílem mezi bezserverovým a standardním modelem virtuálních jader služby Azure SQL Database je, že bez serveru můžete zadat minimální a maximální počet virtuálních jader. Omezení paměti a vstupně-výstupních operací jsou úměrná zadanému rozsahu.
Obrázek znázorňuje obrazovku konfigurace bezserverové databáze na webu Azure Portal. Máte možnost vybrat minimální hodnotu poloviny virtuálního jádra (vCore) a maximum až 16 virtuálních jader.
Bezserverová aplikace není plně kompatibilní se všemi funkcemi ve službě Azure SQL Database, protože některé z nich vyžadují neustálé spouštění procesů na pozadí, například:
- Geografická replikace
- Dlouhodobé uchovávání záloh
- Databáze úloh v elastických úlohách
- Synchronizační databáze v synchronizaci dat SQL (Synchronizace dat je služba, která replikuje data mezi skupinou databází).
Poznámka:
Serverless je aktuálně podporováno pouze na úrovni General Purpose v nákupním modelu vCore.
Zálohy
Jednou z nejdůležitějších funkcí nabídky Platformy jako služby je zálohování. V takovém případě systém automaticky provádí zálohy bez jakéhokoli zásahu od vás. Geograficky redundantní úložiště objektů blob Azure ukládá tyto zálohy a ve výchozím nastavení je uchovává po dobu 7 až 35 dnů v závislosti na úrovni služby databáze. Databáze úrovně Basic a vCore mají výchozí hodnotu sedm dnů uchovávání a správci můžou tuto hodnotu upravit pro databáze virtuálních jader. Dobu uchovávání můžete prodloužit konfigurací dlouhodobého uchovávání (LTR), která umožňuje uchovávat zálohy po dobu až 10 let.
Abyste zajistili redundanci, můžete také použít geograficky redundantní úložiště objektů blob, které je přístupné pro čtení. Toto úložiště by replikovalo zálohy databáze do sekundární oblasti podle vašich preferencí. V případě potřeby byste také mohli číst z této sekundární oblasti. Ruční zálohování databází se nepodporuje a platforma zamítne všechny požadavky na to.
Zálohy databáze se provádějí podle daného plánu:
- Plný – jednou týdně
- Rozdílový – každých 12 hodin
- Protokol– Každých 5 až 10 minut v závislosti na aktivitě protokolu transakcí
Tento plán zálohování by měl splňovat potřeby většiny cílů bodu obnovení a času (RPO/RTO), ale každý zákazník by měl vyhodnotit, jestli splňuje vaše obchodní požadavky.
Pro obnovení databáze je k dispozici několik možností. Vzhledem k povaze platformy jako služby nemůžete databázi ručně obnovit pomocí konvenčních metod, jako je například vydání příkazu RESTORE DATABASET-SQL .
Bez ohledu na to, která metoda obnovení je implementována, není možné obnovit existující databázi. Pokud je potřeba obnovit databázi, musí být stávající databáze před zahájením procesu obnovení vyřazena nebo přejmenována. Mějte také na paměti, že v závislosti na úrovni služby platformy nejsou doby obnovení zaručené a můžou se lišit. Doporučujeme otestovat proces obnovení, abyste získali základní ukazatel, jak dlouho by mohlo obnovení trvat.
Obnovení pomocí webu Azure Portal – Pomocí webu Azure Portal máte možnost obnovit databázi na stejný logický server pro Azure SQL Database nebo můžete pomocí obnovení vytvořit novou databázi na novém serveru v libovolné oblasti Azure.
Obnovení pomocí skriptovacího jazyka – K obnovení databáze je možné využít PowerShell i Azure CLI.
Poznámka:
Zálohování pouze kopírování do úložiště objektů blob v Azure je k dispozici pro službu SQL Managed Instance. SQL Database tuto funkci nepodporuje.
Další informace o automatizovaných zálohách najdete v tématu Automatizované zálohy – Azure SQL Database a Azure SQL Managed Instance.
Aktivní geografická replikace
Geografická replikace je funkce provozní kontinuity, která asynchronně replikuje databázi až do čtyř sekundárních replik. Vzhledem k tomu, že transakce jsou potvrzeny primární (a jeho repliky ve stejné oblasti), transakce se odesílají do sekundárních souborů, které se mají přehrát. Vzhledem k tomu, že se tato komunikace provádí asynchronně, volající aplikace nemusí čekat na potvrzení transakce sekundární replikou, než SQL Server vrátí řízení volajícímu.
Sekundární databáze jsou čitelné a lze je použít k přesměrování zátěže jen pro čtení, čímž se uvolní prostředky pro transakční úlohy na primárním serveru nebo umístění dat blíže ke koncovým uživatelům. Sekundární databáze mohou být navíc ve stejné oblasti jako primární nebo v jiné oblasti Azure.
Převzetí služeb při selhání můžete iniciovat buď ručně uživatelem, nebo programově aplikací. Pokud dojde k převzetí služeb při selhání, můžete aktualizovat připojovací řetězce aplikace tak, aby odrážely nový koncový bod toho, co je nyní hlavní databází.
Skupiny pro selhání systému
Skupiny převzetí služeb při selhání jsou založené na technologii používané v geografické replikaci, ale poskytují jediný koncový bod pro připojení. Hlavním důvodem použití skupin převzetí služeb při selhání je, že poskytují koncové body, které je možné využít ke směrování provozu do příslušné repliky. Vaše aplikace se může po selhání připojit bez nutnosti změny připojovacího řetězce.