Dostupnost prostřednictvím místní redundance a redundance zón – Azure SQL Managed Instance

Platí pro:Azure SQL Managed Instance

Tento článek popisuje architekturu služby Azure SQL Managed Instance, která dosahuje dostupnosti prostřednictvím místní redundance a vysoké dostupnosti prostřednictvím redundance zón.

Přehled

Sql Managed Instance běží na nejnovější stabilní verzi databázového stroje SQL Serveru v operačním systému Windows se všemi příslušnými opravami. Spravovaná instance SQL automaticky zpracovává důležité úlohy údržby, jako jsou opravy, zálohy, upgrady databázového stroje Windows a SQL a neplánované události, jako jsou základní hardware, software nebo selhání sítě. Pokud je instance opravená 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 Managed Instance se může rychle zotavit 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 Managed Instance ve výchozím nastavení dosahuje dostupnosti prostřednictvím místní redundance a zajišťuje, aby vaše instance zvládla přerušení, například:

  • Zákazníkem iniciované operace správy, které způsobí krátký výpadek
  • Operace údržby služeb
  • Problémy a výpadky datových center:
    • Stojan, na kterém běží stroje, na kterých běží vaše služba
    • Fyzický počítač, který je hostitelem virtuálního počítače, na kterém běží databázový stroj SQL.
    • Virtuální počítač, na kterém běží databázový stroj 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 mají minimální dopad na vaši úlohu a že instance 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 vaší instance, dokud se nevyřeší výpadek – jediný způsob, jak provést zotavení, je prostřednictvím řešení zotavení po havárii, například prostřednictvím skupiny 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ů.

Vysoká dostupnost zvyšuje spolehlivost vaší služby tím, že vás chrání před dopadem na:

  • Zóna dostupnosti, která tvoří datové centrum

Na základě úrovně služby existují dva různé modely architektury dostupnosti:

  • Model vzdáleného úložiště je založený na oddělení výpočetních prostředků a úložiště na úrovních služby Pro obecné účely a Další generace, které závisí na dostupnosti a spolehlivosti vzdáleného úložiště a dostupnosti výpočetních clusterů spravovaných službou Azure Service Fabric. Tento model dostupnosti cílí na obchodní aplikace orientované na rozpočet, které mohou tolerovat snížení výkonu během aktivit údržby.
  • Model místního úložiště je založený na clusteru procesů databázového stroje, který spoléhá na kvorum dostupných uzlů databázového stroje v úrovni služby Pro důležité obchodní informace, která mají místní úložiště. Tento místní model úložiště cílí na klíčové aplikace, které mají vysokou rychlost transakcí a vyžadují vysoký výkon vstupně-výstupních operací. Architektura vysoké dostupnosti zaručuje minimální dopad na výkon vaší úlohy během aktivit údržby.

Další informace o konkrétních smlouvách SLA pro různé úrovně služeb najdete v článku SLA pro Azure SQL Managed Instance.

Dostupnost prostřednictvím místní redundance

Místně redundantní dostupnost je založená na ukládání výpočetních uzlů a dat 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í. 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ě nebo dat na výpočetních uzlech 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.

Úroveň služby pro obecné účely

Úroveň služby Pro obecné účely používá architekturu dostupnosti vzdáleného úložiště. 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.

Diagram znázorňující oddělení výpočetních prostředků a úložiště

Model dostupnosti vzdáleného úložiště obsahuje dvě vrstvy:

  • Bezstavová výpočetní vrstva, která spouští proces databázového stroje a obsahuje pouze přechodná data a data uložená v mezipaměti, jako jsou databáze tempdb a model na připojeném SSD a mezipaměť plánů, vyrovnávací fond a fond columnstore v paměti. Tento bezstavový uzel spravuje Azure Service Fabric, který inicializuje databázový modul, monitoruje stav uzlu a v případě potřeby přepne služby při selhání na jiný uzel.
  • Stavová datová vrstva s databázovými soubory (.mdf a .ldf) uloženými ve službě Azure Blob Storage. Azure Blob Storage má integrované funkce dostupnosti dat a redundance. Místně redundantní dostupnost je založená na ukládání dat 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. 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. Přesun nemá vliv na data ve službě Azure Blob Storage a datové a protokolové soubory jsou připojeny k nově inicializovanému procesu databázového stroje. 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 nové generace pro obecné účely

Příští generace General Purpose je architektonická aktualizace stávající úrovně služeb General Purpose, která využívá vylepšenou vzdálenou úložnou vrstvu pro ukládání dat instance a logovacích souborů na Elastic SAN místo stránkových blobů.

Redundance napříč zónami pro úroveň služby Next-gen General Purpose je aktuálně ve verzi Preview. Verze Preview také podporuje pružnou paměť pro zónově redundantní instance na hardwaru řady Premium.

Úroveň služby Pro podnikově kritické úlohy

Úroveň služby Pro důležité obchodní informace používá model dostupnosti místní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) na jednom uzlu. Dostupnost se dosahuje replikací výpočetních prostředků i úložiště do dalších uzlů.

Diagram clusteru uzlů databázového stroje

Podkladové soubory databáze (.mdf/.ldf) se umístí do připojeného úložiště SSD, aby poskytovaly velmi nízkou latenci vstupně-výstupních operací pro vaši úlohu. 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ě), které obsahují kopie dat. Primární replika neustále odesílá změny do sekundárních replik postupně, aby se zajistilo, že se data uchovávají na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud bude primární replika nebo čitelná sekundární replika z jakéhokoli důvodu nedostupná, bude vždy k dispozici zcela synchronizovaná replika, na kterou lze přepnout při selhání. Převzetí služeb při selhání je iniciováno službou Azure Service Fabric. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, aby cluster měl dostatečný počet replik k zachování kvora. Po dokončení převzetí služeb při selhání se připojení k Azure SQL automaticky přesměrují na novou primární repliku (nebo čitelnou sekundární repliku na základě připojovacího řetězce).

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á Read Scale-Out. Poskytuje o 100 % vyšší výpočetní kapacitu bez dalších poplatků, aby odlehčila primární replice od operací jen pro čtení, jako jsou analytické úlohy.

Vysoká dostupnost díky redundanci mezi zónami

Zónově redundantní dostupnost je zajištěna umístěním replik do tří zón dostupnosti Azure v primárním regionu. Každá zóna dostupnosti je samostatné fyzické umístění s nezávislým napájením, chlazením a sítí.

Ve výchozím nastavení se cluster uzlů pro model dostupnosti místního úložiště vytvoří ve stejném datacentru. Po zavedení služby Azure Zóny dostupnosti služba SQL Managed Instance umístí různé repliky do různých zón dostupnosti ve stejné oblasti. Aby se zabránilo jedinému bodu selhání, řídicí okruh se také duplikuje napříč více zónami. Provoz řídicí roviny se pak směruje do nástroje pro vyrovnávání zatížení, který je také nasazený napříč zónami dostupnosti. Směrování provozu z řídicí roviny do nástroje pro vyrovnávání zatížení řídí Služba Azure Traffic Manager (ATM).

Použitím zónově redundantní konfigurace můžete učinit své instance Business Critical, General Purpose nebo Next-gen General Purpose odolné vůči mnohem většímu množství selhání, včetně katastrofických výpadků datových center, bez jakýchkoli změn v logice aplikace. Existující instance můžete převést do zónově redundantní konfigurace. Zónová redundance pro úroveň služby Next-gen General Purpose je aktuálně ve verzi Preview.

Protože zónově redundantní instance mají repliky v různých datových centrech s určitým odstupem mezi sebou, zvýšená latence sítě může prodloužit dobu závazku transakce a tím ovlivnit výkon některých OLTP zátěží. Ke konfiguraci s jednou zónou se můžete kdykoli vrátit zakázáním nastavení redundance zóny. Tento proces je online operace podobná upgradu standardní úrovně služby. Na konci procesu se instance migruje z zónově redundantního okruhu na okruh s jednou zónou nebo naopak.

Pokud chcete začít s redundancí zón pro spravovanou instanci SQL, přečtěte si téma Konfigurace redundance zón. Zkontrolujte dostupnost redundance zón podle oblastí pro službu Azure SQL Managed Instance.

Úroveň služby pro obecné účely

Na úrovni služby Pro obecné účely se redundance zón dosahuje umístěním bezstavových výpočetních uzlů do různých zón dostupnosti a pak spoléhá na stavové zónově redundantní úložiště (ZRS), které je připojené k danému uzlu, který aktuálně obsahuje aktivní proces databázového stroje SQL. V případě výpadku se proces databázového stroje SQL aktivuje na jednom z bezstavových uzlů, které pak přistupují k datům ve stavovém úložišti.

Následující diagram znázorňuje architekturu redundance zóny pro úroveň služby Pro obecné účely:

Diagram architektury redundance zóny na úrovni služby Pro obecné účely

Úroveň služby nové generace pro obecné účely

Redundance napříč zónami pro úroveň služby Next-gen General Purpose je aktuálně ve verzi Preview. Konfigurace s rezervou zón rozděluje komponenty služeb napříč zónami dostupnosti a využívá vylepšenou vrstvu vzdáleného úložiště Elastic SAN. Preview podporuje flexibilní paměť na hardwaru řady Premium, takže můžete paměť upravovat nezávisle na počtu vCore.

Úroveň služby Pro podnikově kritické úlohy

Na úrovni služby Pro důležité obchodní informace se redundance zón dosahuje umístěním výpočetních replik a replik úložiště do různých zón dostupnosti a následným použitím základní technologie skupiny dostupnosti AlwaysOn k replikaci změn dat z primární instance na pohotovostní repliky v jiných zónách dostupnosti. V případě výpadku dojde k automatickému převzetí služeb, které bezproblémově povýší jednu z pohotovostních replik na primární repliku.

Následující diagram znázorňuje architekturu redundance zón pro úroveň služby Business Critical:

Schéma architektury redundance napříč zónami v úrovni služby Business Critical.

Testování odolnosti proti chybám aplikace

Dostupnost je základní součástí platformy SQL Managed Instance, která transparentně funguje pro vaši databázovou aplikaci. Nicméně si uvědomujeme, že byste mohli chtít otestovat, jak automatické operace failoveru zahájené během plánovaných nebo neplánovaných událostí ovlivní aplikaci ještě před nasazením do produkce. Přepnutí při selhání můžete ručně vyvolat pomocí speciálního volání rozhraní API, které slouží k restartování spravované instance. 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 spravovanou instanci povoleno každých 15 minut pouze jedno volání převzetí služeb při selhání.

Během skutečného převzetí služeb při selhání se připojení k instanci přeruší, zatímco služba SQL převezme primární roli na jiném uzlu. Pokud chcete simulovat převzetí služeb při selhání, vyvolejte příkaz, který restartuje proces SQL, aby simuloval spuštění služby, jako by došlo k převzetí služeb při selhání. V porovnání se simulovaným převzetím služeb při selhání však může připojení po delší dobu selhat, protože během skutečného převzetí služeb při selhání se proces SQL stane primárním na jiném virtuálním počítači v rámci clusteru (místně nebo v jiné zóně, pokud je povolená redundance zóny) a během simulovaného převzetí služeb při selhání se proces SQL restartuje na existujícím virtuálním počítači.

Příkaz ručního převzetí služeb při selhání představený v této části se obvykle chová stejným způsobem jak v místně redundantních, tak v zónově redundantních konfiguracích. Příkaz obvykle pouze místně restartuje proces SQL a nespouští přepnutí při selhání na jiný uzel, i když platí několik výjimek. Toto místní převzetí při selhání se liší od převzetí při selhání, k němuž dochází v rámci skupiny převzetí při selhání. Neexistuje však žádné omezení, které zaručuje, že se nový proces spustí na stejném uzlu a může se spustit na jiném uzlu ve stejné zóně dostupnosti nebo v jiné zóně dostupnosti. Místní převzetí služeb při selhání je možné zahájit pomocí PowerShellu, rozhraní REST API nebo Azure CLI:

PowerShell REST API Azure CLI (příkazový řádek nástroje Azure)
Invoke-AzSqlInstanceFailover Spravovaná instance SQL – Převzetí služeb při selhání Příkaz az sql mi failover lze použít k vyvolání volání REST API z Azure CLI.

Automatické interní testy připojení

Aby bylo možné zajistit dostupnost vaší služby, Azure SQL Managed Instance spouští automatické interní testy připojení, které monitorují spolehlivost služby a urychlují detekci problémů. Tyto testy se spouštějí každých 10 sekund z interních IP adres v podsíti spravované instance SQL a mají zanedbatelný dopad na výkon sítě a výkon služby. Jeden test ověřuje konektivitu typu end-to-end tím, že se pokusí o přihlášení pomocí přihlašovacích údajů, u nichž je známo, že selžou (AzureSQLConnectivityChecker), čímž se v protokolech auditu, Extended Events a protokolech chyb SQL vygenerují očekávané záznamy o neúspěšném přihlášení. Tyto položky jsou normální a neoznačují problém se zabezpečením. Další informace, včetně toho, jak identifikovat podpisy testů v protokolech, najdete v tématu Automatické interní testy připojení.

Závěr

Spravovaná instance Azure SQL nabízí integrované řešení s vysokou dostupností, které je hluboce integrované s platformou Azure. Služba závisí na službě Service Fabric při zjišťování selhání a zotavení, na službě Azure Blob Storage při ochraně dat a na Zónách dostupnosti pro vyšší odolnost proti selhání. A pro úroveň služby Business Critical používá spravovaná instance SQL technologii skupin dostupnosti Always On pro replikaci databází a převzetí služeb při 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

  • Last updated on