Dostupnost prostřednictvím redundance – Azure SQL Database
Platí pro:
Azure SQL DatabaseSQL databáze v prostředí Fabric
Tento článek popisuje architekturu služby Azure SQL Database a databáze SQL ve Fabric, která dosahuje dostupnosti díky místní redundanci a vysoké dostupnosti díky zónové redundanci.
Přehled
Azure SQL Database a SQL databáze v prostředí Fabric běží na nejnovější stabilní verzi databázového stroje SQL Server v operačním systému Windows se všemi příslušnými opravami. SQL Database automaticky zpracovává důležité úlohy údržby, jako jsou opravy, zálohy, upgrady modulu Windows a SQL a neplánované události, jako jsou základní hardware, software nebo selhání sítě. Pokud se databáze nebo elastický fond ve službě SQL Database opraví nebo převezme služby při selhání, výpadek nebude mít vliv, pokud ve své aplikaci použijete logiku opakování. SQL Database se může rychle obnovit i za nejdůležitějších okolností a zajistit tak, aby vaše data byla vždy dostupná. Většina uživatelů si nevšimne, že se upgrady provádějí nepřetržitě.
Azure SQL Database ve výchozím nastavení dosahuje dostupnosti prostřednictvím místní redundance a zpřístupňuje databázi během:
- Operace správy iniciované zákazníkem, které vedou ke krátkému výpadku
- Operace údržby služeb
- Problémy s následujícími položkami:
- rack, kde jsou umístěny servery, které pohánějí vaši službu
- fyzický počítač, který je hostitelem databázového stroje SQL
- Další problémy s databázovým strojem SQL
- Další potenciální neplánované místní výpadky
Výchozí řešení dostupnosti je navržené tak, aby se zajistilo, že se potvrzená data nikdy neztratí kvůli selháním, že operace údržby nemají vliv na vaši úlohu a že databáze není jediným bodem selhání ve vaší softwarové architektuře.
Pokud ale chcete minimalizovat dopad na data v případě výpadku celé zóny, můžete dosáhnout vysoké dostupnosti povolením redundance zóny. Bez redundance zón dochází k převzetí služeb při selhání místně ve stejném datovém centru, což může vést k nedostupnosti databáze, dokud se nevyřeší výpadek – jediný způsob, jak provést zotavení, je prostřednictvím řešení zotavení po havárii, jako je geografické převzetí služeb při selhání prostřednictvím aktivní geografické replikace, skupin převzetí služeb při selhání nebo geografického obnovení geograficky redundantního zálohování. Další informace najdete v přehledu kontinuity podnikových procesů.
Existují tři modely architektury dostupnosti:
- Model vzdáleného úložiště založený na oddělení výpočetních prostředků a úložiště Závisí na dostupnosti a spolehlivosti úrovně vzdáleného úložiště. Tato architektura cílí na rozpočtově orientované podnikové aplikace, které mohou tolerovat určité snížení výkonu během údržby.
- Místní model úložiště založený na clusteru procesů databázového stroje. Spoléhá na skutečnost, že existuje vždy kvorum dostupných uzlů databázového stroje. Tato architektura cílí na klíčové aplikace s vysokým výkonem vstupně-výstupních operací, vysokou rychlostí transakcí a zaručuje minimální dopad na výkon vaší úlohy během údržby.
- Model Hyperscale, který používá distribuovaný systém vysoce dostupných komponent, jako jsou výpočetní uzly, stránkovací servery, služba protokolů a trvalé úložiště. Každá komponenta podporující databázi Hyperscale poskytuje vlastní redundanci a odolnost proti selháním. Výpočetní uzly, stránkovací servery a služba protokolu běží v Azure Service Fabric, která řídí stav jednotlivých komponent a podle potřeby provádí převzetí služeb při selhání dostupným uzlům, které jsou v pořádku. Trvalé úložiště využívá Azure Storage s nativními možnostmi vysoké dostupnosti a redundance. Další informace najdete v tématu Architektura Hyperscale.
V rámci každého ze tří modelů dostupnosti sql Database podporuje možnosti místní redundance a zónové redundance. Místní redundance zajišťuje odolnost v rámci datacentra, zatímco zónová redundance zvyšuje odolnost tím, že chrání před výpadky zóny dostupnosti v rámci oblasti.
Následující tabulka uvádí možnosti dostupnosti na základě úrovní služby:
| Úroveň služby | Model vysoké dostupnosti | Místně redundantní dostupnost | Zónově redundantní dostupnost |
|---|---|---|---|
| Obecné účely (vCore) | Vzdálené úložiště | Ano | Ano |
| Kritické pro podnikání (vCore) | Místní úložiště | Ano | Ano |
| Hyperscale (vCore) | Hyperscale | Ano | Ano |
| Základní (DTU) | Vzdálené úložiště | Ano | Ne |
| Standard (DTU) | Vzdálené úložiště | Ano | Ne |
| Premium (DTU) | Místní úložiště | Ano | Ano |
Další informace o konkrétních smlouvách SLA pro různé úrovně služeb si přečtěte ve SLA pro Azure SQL Database.
Dostupnost prostřednictvím místní redundance
Místně redundantní dostupnost je založená na ukládání databáze do místně redundantního úložiště (LRS), které kopíruje data třikrát v rámci jednoho datacentra v primární oblasti a chrání vaše data v případě místního selhání, jako je například malá síť nebo selhání napájení. LRS je možnost redundance s nejnižšími náklady a nabízí nejnižší odolnost v porovnání s jinými možnostmi. Pokud dojde k rozsáhlé havárii, jako je požár nebo záplava v rámci oblasti, můžou být všechny repliky účtu úložiště využívajícího LRS ztraceny nebo neobnovitelné. Pokud chcete data dál chránit při použití možnosti místně redundantní dostupnosti, zvažte použití odolnější možnosti úložiště pro zálohy databáze. To neplatí pro databáze Hyperscale, kde se stejné úložiště používá pro datové soubory i zálohy.
Místně redundantní dostupnost je k dispozici pro všechny databáze ve všech úrovních služby a také cíl bodu obnovení (RPO), což značí, že ztráta dat je nulová.
Úrovně služby Basic, Standard a Pro obecné účely
Úrovně služby Basic a Standard nákupního modelu založeného na DTU a úrovně služby Pro obecné účely nákupního modelu založeného na virtuálních jádrech používají model dostupnosti vzdáleného úložiště pro bezserverové i zřízené výpočetní prostředky. Na následujícím obrázku jsou uvedeny čtyři různé uzly s oddělenými výpočetními a úložnými vrstvami.
Model dostupnosti vzdáleného úložiště obsahuje dvě vrstvy:
- Bezstavová výpočetní vrstva, která spouští proces databázového enginu a obsahuje pouze přechodná a uložená data v mezipaměti, jako jsou databáze
tempdbamodelna připojeném SSD disku, a mezipaměť plánu, vyrovnávací paměť a columnstore fond v paměti. Tento bezstavový uzel je provozován službou Azure Service Fabric, jež inicializuje databázový stroj, kontroluje zdraví uzlu a v případě potřeby provádí převzetí služeb při selhání do jiného uzlu. - Stavová datová vrstva s databázovými soubory (
.mdfa.ldf) uloženými ve službě Azure Blob Storage. Azure Blob Storage má integrované funkce dostupnosti dat a redundance. Zaručuje, že každý záznam v souboru protokolu nebo stránce datového souboru se zachová i v případě, že dojde k chybovému ukončení procesu databázového stroje.
Při každém upgradu databázového stroje nebo operačního systému nebo zjištění selhání přesune Azure Service Fabric proces bezstavového databázového stroje do jiného bezstavového výpočetního uzlu s dostatečnou bezplatnou kapacitou. Data ve službě Azure Blob Storage zůstávají bez změny při přesunu a soubory dat a protokolů se připojí k nově inicializovanému procesu databázového enginu. Tento proces zaručuje vysokou dostupnost, ale při přechodu může docházet k určitému snížení výkonu, protože nový proces databázového stroje začíná studenou mezipamětí.
Úroveň služby Premium a Kritická pro podnikání
Úroveň služby Premium nákupního modelu založeného na DTU a úroveň služby Business Critical nákupního modelu založeného na vCore používají model dostupnosti lokálního úložiště, který integruje výpočetní prostředky (proces databázového stroje) a úložiště (místně připojené SSD) do jednoho uzlu. Vysoká dostupnost se dosahuje replikací výpočetních prostředků i úložiště do dalších uzlů.
Podkladové databázové soubory (.mdf/.ldf) jsou umístěné v připojeném úložišti SSD, aby poskytovaly pro vaši úlohu velmi nízkou latenci vstupně-výstupních operací. Vysoká dostupnost se implementuje pomocí technologie podobné skupinám dostupnosti AlwaysOn SQL Serveru. Cluster obsahuje jednu primární repliku, která je přístupná pro úlohy zákazníků se čtením a zápisem, a až tři sekundární repliky (výpočetní prostředky a úložiště) obsahující kopie dat. Primární replika neustále odesílá změny do sekundárních replik v daném pořadí a zajišťuje, aby data byla spolehlivě uložena na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud z nějakého důvodu dojde k selhání primární repliky nebo čtecí sekundární repliky, vždy existuje plně synchronizovaná replika pro převzetí při selhání. Převzetí služeb při selhání je inicializováno službou Azure Service Fabric. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, která zajistí, že cluster bude mít dostatečný počet replik pro zachování kvóra. Po dokončení převzetí služeb při selhání se připojení Azure SQL automaticky přesměrují na novou primární repliku nebo čitelnou sekundární repliku.
Model dostupnosti místního úložiště navíc zahrnuje možnost přesměrovat připojení Azure SQL jen pro čtení na jednu ze sekundárních replik. Tato funkce se nazývá Škálované čtení. Poskytuje 100% dodatečnou výpočetní kapacitu bez dalších poplatků pro operace pouze ke čtení, jako jsou analytické úlohy, odlehčením z primární repliky.
Hyperskálová úroveň služby
Architektura úrovně služby Hyperscale je popsaná v architektuře distribuovaných funkcí.
Model dostupnosti v Hyperscale zahrnuje čtyři vrstvy:
- Bezstavová výpočetní vrstva, která spouští procesy databázového stroje a obsahuje pouze přechodná data a data uložená v mezipaměti, jako je například neodkrývající mezipaměť RBPEX, databáze
tempdbamodelatd. na připojeném disku SSD, a dále pak plán mezipaměti, vyrovnávací fond a columnstore fond v paměti. Tato bezstavová vrstva zahrnuje primární výpočetní repliku a volitelně i několik sekundárních výpočetních replik, které mohou v případě selhání sloužit jako cíle převzetí služeb. - Bezstavová vrstva úložiště vytvořená stránkovými servery. Tato vrstva je distribuovaný úložný modul pro procesy databázového stroje běžící na výpočetních replikách. Každý stránkový server obsahuje pouze přechodná data a data uložená v mezipaměti, například pokrytí mezipaměti RBPEX na připojeném disku SSD a datové stránky uložené v mezipaměti v paměti. Každý server stránky má zdvojený server stránky v uspořádání aktivně-aktivně, aby poskytoval vyrovnávání zatížení, redundanci a vysokou dostupnost.
- Vrstva úložiště stavového transakčního protokolu vytvořená výpočetním uzlem, který spouští proces služby protokolu, cílovou zónu transakčního protokolu a dlouhodobé úložiště transakčních protokolů. Cílová zóna a dlouhodobé úložiště používají Službu Azure Storage, která poskytuje dostupnost a redundanci transakčního protokolu a zajišťuje odolnost dat pro potvrzené transakce.
- Stavová vrstva úložiště dat se soubory databáze (.mdf/.ndf), které jsou uložené ve službě Azure Storage a aktualizují se stránkovými servery. Tato vrstva používá funkce dostupnosti dat a redundance služby Azure Storage. Zaručuje, že každá stránka v datovém souboru se zachová i v případě, že dojde k chybě procesů v jiných vrstvách architektury Hyperscale nebo pokud výpočetní uzly selžou.
Výpočetní uzly ve všech vrstvách Hyperscale běží v Azure Service Fabric, které řídí stav každého uzlu a podle potřeby provádí převzetí služeb při selhání dostupným uzlům, které jsou v pořádku.
Další informace o vysoké dostupnosti v Hyperscale najdete v tématu Vysoká dostupnost databáze v Hyperscale.
Vysoká dostupnost prostřednictvím zónové redundance
Zónově redundantní dostupnost zajišťuje, že se vaše data rozdělí mezi tři zóny dostupnosti Azure v primární oblasti. Každá zóna dostupnosti je samostatné fyzické umístění s nezávislým napájením, chlazením a sítí.
Zónově redundantní dostupnost je k dispozici pro databáze v úrovních služby Business Critical, Obecný účel a Hyperscale nákupního modelu založeného na virtuálních jádrech , a pouze v úrovni služby Premium nákupního modelu založeného na DTU – úrovně služby Basic a Standard nepodporují zónovou redundanci.
Zatímco každá úroveň služby implementuje zónovou redundanci odlišně, všechny implementace zajišťují cíl obnovy dat (RPO) s nulovou ztrátou potvrzených dat při selhání.
Úroveň služby pro obecné účely
Konfigurace zónové redundance pro úroveň služby Obecného použití je nabízena jak pro bezserverové, tak i zřízené výpočetní kapacity pro databáze v nákupním modelu virtuálních jader. Tato konfigurace využívá Azure Zóny dostupnosti k replikaci databází napříč několika fyzickými umístěními v rámci oblasti Azure. Výběrem zónově redundance můžete vytvořit novou a stávající bezserverovou a zřízenou jednoúčelovou databázi a elastické fondy odolné vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra bez jakýchkoli změn logiky aplikace.
Zónově redundantní konfigurace pro úroveň Pro obecné účely má dvě vrstvy:
- Stavová datová vrstva se soubory databáze (.mdf/.ldf), které jsou uložené v ZRS (zónově redundantní úložiště). Pomocí ZRS se data a soubory protokolů synchronně kopírují napříč třemi fyzicky izolovanými zónami dostupnosti Azure.
- Bezstavová výpočetní vrstva, která spouští proces sqlservr.exe a obsahuje pouze přechodná data a data uložená v mezipaměti, jako jsou databáze
tempdbamodelna připojeném SSD, a plán mezipaměti, fond vyrovnávací paměti a fond columnstore v paměti. Tento bezstavový uzel provozuje Azure Service Fabric, který inicializuje sqlservr.exe, řídí stav uzlu a v případě potřeby provádí převzetí služeb při selhání do jiného uzlu. Pro zónově redundantní bezserverové a zřízené databáze obecného účelu jsou uzly s volnou kapacitou snadno dostupné v jiných zónách dostupnosti pro případ převzetí služeb při selhání.
Zónově redundantní verze architektury vysoké dostupnosti pro úroveň služby Pro obecné účely je znázorněna následujícím diagramem:
- Informace o regionální dostupnosti najdete v tématu Dostupnost funkce redundance zón pro obecné účely v jednotlivých oblastech pro službu Azure SQL Database.
- Pro zónově redundantní dostupnost je aktuálně ve vybraných oblastech možnost zvolit údržbové okno odlišné od výchozího. Další informace najdete v tématu Dostupnost časového období údržby v jednotlivých oblastech pro službu Azure SQL Database.
- Zónově redundantní konfigurace je dostupná jenom v SQL Database, pokud je vybraný hardware řady Standard (Gen5).
- Zónová redundance není dostupná pro úrovně služby Basic a Standard v nákupním modelu DTU.
Úrovně služeb Premium a Renatní pro podnikání
Pokud je pro úroveň služby Premium nebo Business Critical povolená redundance zón, repliky se umístí do různých dostupnostních zón ve stejném regionu. Aby se zabránilo jedinému bodu selhání, řídicí prstenec je také duplikován napříč několika zónami jako tři přístupové prstence (GW). Směrování na konkrétní okruh brány řídí Azure Traffic Manager. Vzhledem k tomu, že zónově redundantní konfigurace v úrovních služeb Premium nebo Business Critical používá své stávající repliky k umístění do různých zón dostupnosti, můžete ji povolit bez dalších poplatků. Výběrem zónově redundantní konfigurace můžete vytvořit Premium nebo Business Critical databáze a elastické fondy, které jsou odolné vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra, aniž by bylo potřeba cokoliv měnit v logice aplikace. Na zónově redundantní konfiguraci můžete také převést všechny existující databáze Premium nebo Business Critical, nebo elastické fondy.
Zónově redundantní verze architektury vysoké dostupnosti je znázorněna následujícím diagramem:
Při konfiguraci databází Premium nebo Business Critical s zónovou redundancí zvažte následující skutečnosti:
- Aktuální informace o oblastech, které podporují zónově redundantní databáze, najdete v tématu Podpora služeb v jednotlivých oblastech.
- Pro zónově redundantní dostupnost je momentálně dostupný ve vybraných oblastech výběr údržbového okna odlišného od výchozího. Další informace najdete v tématu Dostupnost časového období údržby v jednotlivých oblastech pro službu Azure SQL Database.
Úroveň služby hyperscale
Pro databáze ve vrstvě služby Hyperscale je možné nakonfigurovat zónovou redundanci. Další informace najdete v tématu Vytvoření zónově redundantní databáze Hyperscale.
Povolení této konfigurace zajišťuje odolnost na úrovni zóny prostřednictvím replikace napříč Zóny dostupnosti pro všechny vrstvy Hyperscale. Výběrem zónově redundance můžete zajistit odolnost databází Hyperscale vůči mnohem větší sadě selhání, včetně katastrofických výpadků datacentra, bez jakýchkoli změn logiky aplikace. Všechny oblasti Azure, které mají Zóny dostupnosti podporují zónově redundantní databázi Hyperscale. Podpora redundance zón pro hyperscale PRMS a MOPRMS hardware je dostupná v určitých oblastech. Další informace najdete v tématu dostupnost hyperškálování řady Premium podle oblastí pro službu Azure SQL Database.
Zónově redundantní dostupnost se podporuje v samostatných databázích Hyperscale i v elastických fondech Hyperscale. Další informace naleznete v tématu Hyperscale elastické pooly.
Následující diagram znázorňuje základní architekturu zónově redundantních databází Hyperscale:
Berte v úvahu následující omezení:
Zónově redundantní konfiguraci je možné zadat pouze během vytváření databáze. Toto nastavení nelze po zřízení prostředku změnit. Pomocí kopírování databáze, obnovení k určitému bodu v čase nebo vytvoření geografické repliky aktualizujte zónově redundantní konfiguraci pro existující databázi Hyperscale. Pokud používáte jednu z těchto možností aktualizace, a cílová databáze se nachází v jiné oblasti než zdrojová nebo pokud se redundance úložiště zálohování databáze cílové liší od zdrojové databáze, operace kopírování bude záviset na velikosti dat.
Pro zónově redundantní dostupnost vyberte časové období údržby jiné než výchozí nastavení je aktuálně dostupné ve vybraných oblastech. Další informace najdete v tématu Dostupnost časového období údržby v jednotlivých oblastech pro službu Azure SQL Database.
Při migraci databáze na Hyperscale pomocí webu Azure Portal aktuálně není možné určit redundanci zón. Redundanci zón je ale možné zadat pomocí Azure PowerShellu, Azure CLI nebo rozhraní REST API při migraci existující databáze z jiné úrovně služby Azure SQL Database na Hyperscale. Tady je příklad s Azure CLI:
az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`K povolení zónově redundantní konfigurace pro Hyperscale se vyžaduje alespoň 1 replika výpočetního uzlu s vysokou dostupností a použití úložiště zálohování, které je zónově redundantní nebo geograficky-zónově redundantní.
Redundantní dostupnost zón databáze
V Azure SQL Database je server logický konstruktor, který funguje jako centrální bod správy pro kolekci databází. Na úrovni serveru můžete spravovat přihlášení, metodu ověřování, pravidla brány firewall, pravidla auditování, zásady detekce hrozeb a skupiny převzetí služeb při selhání. Data související s některými z těchto funkcí, jako jsou přihlášení a pravidla brány firewall, jsou uložená v master databázi. Podobně se data některých zobrazení dynamické správy, například sys.resource_stats, ukládají také do master databáze.
Při vytvoření databáze s zónově redundantní konfigurací na logickém serveru master se databáze přidružená k serveru automaticky vytvoří i zónově redundantní. Tím se zajistí, že v zónovém výpadku zůstanou aplikace používající databázi nedotčené, protože funkce závislé na master databázi, jako jsou přihlášení a pravidla brány firewall, jsou stále dostupné. Způsob, jak udělat databázi zónově redundantní, je asynchronní proces, který bude na pozadí chvíli trvat, než se dokončí.
Pokud žádná z databází na serveru není zónově redundantní nebo když vytváříte prázdný server, master databáze přidružená k serveru není zónově redundantní.
Ke kontrole vlastnosti databáze můžete použít Azure PowerShell nebo Azure CLI nebo rozhraní REST API:ZoneRedundantmaster
Pomocí následujícího ukázkového příkazu zkontrolujte hodnotu vlastnosti ZoneRedundant pro master databázi.
Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"
Testování odolnosti proti chybám aplikace
Vysoká dostupnost je základní součástí platformy SQL Database, která transparentně funguje pro vaši databázovou aplikaci. Uvědomujeme si však, že možná budete chtít otestovat, jak by operace automatického převzetí služeb při selhání zahájené během plánovaných nebo neplánovaných událostí ovlivnily aplikaci před jejím nasazením do produkčního prostředí. Převzetí služeb při selhání můžete ručně aktivovat voláním speciálního rozhraní API pro restartování databáze nebo elastického fondu. V případě zónově redundantní bezserverové databáze nebo zřízené databáze pro obecné účely nebo elastického fondu by volání rozhraní API vedlo k přesměrování připojení klientů k nové primární zóně dostupnosti, která se liší od zóny dostupnosti původní primární. Kromě testování toho, jak převzetí služeb při selhání ovlivní stávající relace databáze, můžete také ověřit, jestli dojde ke změně výkonu end-to-end vlivem změn latence sítě. Vzhledem k tomu, že operace restartování je rušivá a velký počet z nich může natížit platformu, je pro každou databázi nebo elastický fond povolený každých 15 minut pouze jedno volání převzetí služeb při selhání.
Další informace o vysoké dostupnosti a zotavení po havárii ve službě Azure SQL Database najdete v kontrolním seznamu pro vysokou dostupnost nebo zotavení po havárii.
Převzetí služeb při selhání je možné zahájit pomocí PowerShellu, rozhraní REST API nebo Azure CLI:
| Typ nasazení | PowerShell | REST API | Azure CLI |
|---|---|---|---|
| Databáze | Invoke-AzSqlDatabaseFailover | Přepnutí databáze při selhání | az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI. |
| Elastický fond | Invoke-AzSqlElasticPoolFailover | Selhání elastického poolu | az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI. |
Důležité
Příkaz failover není k dispozici pro čitelné sekundární repliky Hyperscale databází.
Závěr
Azure SQL Database nabízí integrované řešení s vysokou dostupností, které je hluboce integrované s platformou Azure. Je závislý na Service Fabric pro detekci a obnovení selhání, na úložišti objektů Blob v Azure pro ochranu dat a na Zónách Dostupnosti kvůli vyšší odolnosti proti chybám. Kromě toho SQL Database používá technologii skupiny dostupnosti Always On ze SQL Serveru k synchronizaci dat a zotavení po selhání. Kombinace těchto technologií umožňuje aplikacím plně realizovat výhody modelu smíšeného úložiště a podporuje nejnáročnější smlouvy SLA.
Související obsah
Další informace najdete tady: