vysoká dostupnost pro Azure SQL Database a SQL spravovanou instanci

PLATÍ PRO: Azure SQL Database Azure SQL Managed Instance

cílem architektury vysoké dostupnosti v Azure SQL Database a SQL spravované Instance je zaručit, že vaše databáze bude v provozu až 99,99% času, aniž byste se museli starat o dopad operací údržby a výpadků. další informace týkající se konkrétní smlouvy sla pro různé úrovně najdete v tématu sla pro Azure SQL Database a sla pro Azure SQL Managed Instance.

Azure automaticky zpracovává kritické úlohy údržby, jako jsou třeba opravy, zálohování, Windows a Azure SQL upgrady, a také neplánované události, jako je například základní hardware, software nebo selhání sítě. pokud je podkladová databáze v Azure SQL Database opravena nebo převezme služby při selhání, nemůžete si všimnout, pokud ve své aplikaci použijete logiku opakování . SQL Database a SQL spravované Instance si můžete rychle obnovit i v nejdůležitějších případech, které zajistí, že vaše data jsou vždycky k dispozici.

Řešení vysoké dostupnosti je navrženo tak, aby se zajistilo, že potvrzená data nejsou nikdy ztracena z důvodu selhání, že operace údržby neovlivní vaše zatížení a že databáze nebude v rámci softwarové architektury jediným bodem selhání. Neexistují žádná časová období údržby ani výpadky, které by měly vyžadovat, abyste při upgradu nebo údržbě databáze zastavili úlohy.

K dispozici jsou dva modely architektury vysoké dostupnosti:

• Standardní model dostupnosti založený na oddělení výpočetních prostředků a úložiště. Spoléhá se na vysokou dostupnost a spolehlivost vzdálené vrstvy úložiště. Tato architektura cílí na rozpočtově orientované podnikové aplikace, které mohou tolerovat některé snížení výkonu během údržby.
• model dostupnosti Premium , který je založený na clusteru procesů databázového stroje. Spoléhá na to, že je vždy kvorum dostupných uzlů databázového stroje. Tato architektura cílí na kritické aplikace s vysokými nároky na vstupně-výstupní operace, vysokou přenosovou rychlostí a zaručuje minimální dopad na výkon na vaše zatížení během aktivit údržby.

SQL Database a SQL spravované Instance jsou spouštěny v nejnovější stabilní verzi SQL Server databázový stroj a Windows operační systém a většina uživatelů si nevšimnete průběžně s upgradem.

Místně redundantní dostupnost úrovně služeb Basic, Standard a Pro obecné účely

Úrovně služeb Basic, Standard a Pro obecné účely využívají standardní architekturu dostupnosti pro neserverový i zřízený výpočetní výkon. Následující obrázek znázorňuje čtyři různé uzly s oddělenými výpočetními a úložnými vrstvami.

Standardní model dostupnosti obsahuje dvě vrstvy:

• Bezstavová výpočetní vrstva, která spouští sqlservr.exe proces a obsahuje pouze přechodná a data uložená v mezipaměti, jako je například tempdb, modelové databáze na připojené SSD a mezipaměť plánu, fond vyrovnávací paměti a fond columnstore v paměti. tento bezstavový uzel provozuje služba Azure Service Fabric, která inicializuje sqlservr.exe , ovládá stav uzlu a v případě potřeby provede převzetí služeb při selhání jiným uzlem.
• Stavová Datová vrstva s databázovými soubory (. mdf/. ldf), které jsou uložené v úložišti objektů BLOB v Azure. Služba Azure Blob Storage má vestavěnou funkci dostupnosti dat a redundance. Zaručuje, že každý záznam v souboru protokolu nebo na stránce v datovém souboru se zachová i v případě sqlservr.exe , že dojde k chybě procesu.

pokaždé, když je databázový stroj nebo operační systém upgradovaný, nebo dojde k selhání, Azure Service Fabric přesune bezstavový sqlservr.exe proces do jiného bezstavového výpočetního uzlu s dostatečnou volnou kapacitou. Data v úložišti objektů BLOB v Azure nejsou ovlivněná přesunem a soubory dat a protokolů jsou připojené k nově inicializovanému sqlservr.exe procesu. Tento proces garantuje 99,99% dostupnost, ale u velkého zatížení může dojít k výraznému snížení výkonu během přechodu, protože nový sqlservr.exe proces začíná studenou mezipamětí.

Pro obecné účely redundantní dostupnosti zóny služby na úrovni služby (Preview)

Redundantní konfigurace zóny služby pro obecné účely se nabízí pro výpočetní prostředky bez serveru i pro zřizování. Tato konfigurace využívá zóny dostupnosti Azure   k replikaci databází v různých fyzických umístěních v oblasti Azure.Když vyberete redundanci zóny, můžete vytvořit novou a stávající neserverovou a zřízenou izolovanou databázi pro obecné účely a elastické fondy odolné vůči mnohem větším chybám, včetně závažných výpadků datového centra bez jakýchkoli změn aplikační logiky.

Redundantní konfigurace zóny pro vrstvu pro obecné účely má dvě vrstvy:

• Stavová Datová vrstva s databázovými soubory (. mdf/. ldf), které jsou uložené v ZRS (úložiště redundantní v zóně). Pomocí ZRS se soubory dat a protokolů synchronně kopírují do tří zón dostupnosti Azure, které jsou fyzicky izolované.
• Bezstavová výpočetní vrstva, která spouští proces sqlservr.exe a obsahuje pouze přechodná a data uložená v mezipaměti, jako je například TempDB, modelové databáze na připojené SSD a mezipaměť plánu, fond vyrovnávací paměti a fond columnstore v paměti. tento bezstavový uzel je provozován službou 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í jiným uzlem. V případě redundantních databází bez serveru a zřízené databáze pro obecné účely jsou uzly s volnou kapacitou snadno dostupné v jiných Zóny dostupnosti pro převzetí služeb při selhání.

Redundantní verze architektury vysoké dostupnosti pro úroveň služby pro obecné účely je znázorněná v následujícím diagramu:

Premium a Pro důležité obchodní informace místně redundantní dostupnosti úrovně služeb

vrstvy služeb Premium a Pro důležité obchodní informace využívají model Premium dostupnosti, který integruje výpočetní prostředky ( sqlservr.exe procesy) a úložiště (místně připojené jednotky SSD) na jednom uzlu. Vysoká dostupnost se dosahuje replikací výpočetních prostředků i úložiště do dalších uzlů vytvářejících cluster se čtyřmi uzly.

Podkladové soubory databáze (. mdf/. ldf) jsou umístěné v připojeném úložišti SSD, aby bylo možné zajistit velmi nízkou latenci v/v pro vaše zatížení. vysoká dostupnost se implementuje pomocí technologie podobné SQL Server skupinám dostupnosti Always On. Cluster obsahuje jednu primární repliku, která je přístupná pro úlohy zákazníka pro čtení i zápis, a to až ze tří sekundárních replik (výpočetní výkon a úložiště), které obsahují kopie dat. Primární uzel průběžně přenáší změny do sekundárních uzlů v pořadí a před potvrzením každé transakce zajišťuje, aby byla data synchronizována do alespoň jedné sekundární repliky. Tento postup zaručuje, že pokud dojde k selhání primárního uzlu z jakéhokoli důvodu, je vždy plně synchronizovaný uzel, který převezme služby při selhání. Převzetí služeb při selhání iniciuje Service Fabric Azure. Jakmile se sekundární replika pokusí o nový primární uzel, vytvoří se další sekundární replika, která zajistí, že cluster má dostatek uzlů (sada kvora). po dokončení převzetí služeb při selhání se připojení Azure SQL automaticky přesměrují do nového primárního uzlu.

model dostupnosti premium přináší navíc možnost přesměrovat připojení Azure SQL jen pro čtení na jednu ze sekundárních replik. Tato funkce se nazývá horizontální navýšení kapacity čtení. Poskytuje 100% dodatečnou výpočetní kapacitu bez dalších poplatků za vypínání operací jen pro čtení, jako jsou analytické úlohy, z primární repliky.

Premium a Pro důležité obchodní informace redundantní dostupnosti zóny služby vrstvy služeb

Ve výchozím nastavení se cluster uzlů pro model dostupnosti Premium vytvoří ve stejném datovém centru. při zavedení Zóny dostupnosti Azuremůžou SQL Database umístit různé repliky databáze Pro důležité obchodní informace do různých zón dostupnosti ve stejné oblasti. Chcete-li eliminovat jediný bod selhání, je řídicí kanál také duplikován v několika zónách jako tři prstence brány (GS). směrování na konkrétního okruhu brány se řídí Azure Traffic Manager (ATM). vzhledem k tomu, že zóna redundantní konfigurace ve Premium nebo Pro důležité obchodní informace úrovně služeb nevytváří další redundanci databáze, můžete ji povolit bez dalších poplatků. výběrem redundantní konfigurace zóny můžete zajistit, aby vaše Premium nebo Pro důležité obchodní informace databáze byly odolné vůči mnohem většímu počtu selhání, včetně závažných výpadků datacenter, a to bez jakýchkoli změn v aplikační logice. můžete také převést všechny existující Premium nebo databáze Pro důležité obchodní informace nebo fondy na redundantní konfiguraci zóny.

Vzhledem k tomu, že redundantní databáze zóny mají v různých datových centrech repliky s určitou vzdáleností, zvýšení latence sítě může zvýšit dobu potvrzení a tím ovlivnit výkon některých OLTP úloh. Do konfigurace s jednou zónou se můžete kdykoli vrátit tím, že zakážete nastavení redundance zóny. Tento proces je online operace podobná standardnímu upgradu vrstvy služeb. Na konci procesu je databáze nebo fond migrován z zóny redundantního vyzvánění do jediného okruhu zóny nebo naopak.

Redundantní verze architektury s vysokou dostupností v zóně je znázorněna v následujícím diagramu:

Dostupnost vrstvy služeb s škálovatelným škálováním

architektura vrstvy služby s škálovatelným škálováním je popsaná v architektuře distribuovaných funkcí a je aktuálně dostupná jenom pro SQL Database, ne pro SQL spravovanou instanci.

Model dostupnosti v rámci škálování zahrnuje čtyři vrstvy:

• Bezstavová výpočetní vrstva, která spouští sqlservr.exe procesy a obsahuje pouze přechodná data a data uložená v mezipaměti, jako například nepokrývání mezipaměti RBPEX cache, tempdb, modelová databáze atd. na připojené SSD a v paměti plánu, fondu vyrovnávacích pamětí a fondu columnstore. Tato Bezstavová vrstva zahrnuje primární repliku COMPUTE a volitelně také počet sekundárních výpočetních replik, které můžou sloužit jako cíle převzetí služeb při selhání.
• Bezstavová vrstva úložiště vytvořená stránkami serverů. Tato vrstva je distribuovaný modul úložiště pro sqlservr.exe procesy spuštěné ve výpočetních replikách. Každý server stránky obsahuje jenom přechodná data a data uložená v mezipaměti, jako je třeba pokrytí RBPEX cache na připojené SSD a datových stránek uložených v paměti. Každý server stránky má spárovaný stránkovací Server v konfiguraci aktivní-aktivní, aby poskytoval vyrovnávání zatížení, redundanci a vysokou dostupnost.
• Vrstva úložiště protokolu stavových transakcí vytvořená výpočetním uzlem, na kterém běží proces služby protokolování, zóna pro vykládku protokolu transakcí a dlouhodobé ukládání transakčního protokolu. cílová zóna a dlouhodobé úložiště používají Azure Storage, což poskytuje dostupnost a redundanci transakčního protokolu, což zajišťuje odolnost dat pro potvrzené transakce.
• stavová vrstva úložiště dat s databázovými soubory (. mdf/. ndf), které jsou uložené v Azure Storage a jsou aktualizovány pomocí stránkových serverů. Tato vrstva používá funkce pro dostupnost a redundanci dat Azure Storage. Zaručuje, že každá stránka v datovém souboru se zachová i v případě, že procesy v jiných vrstvách selže nebo dojde k selhání výpočetních uzlů.

výpočetní uzly ve všech vrstvách s škálovatelným škálováním běží na Azure Service Fabric, které řídí stav jednotlivých uzlů a v případě potřeby provádějí převzetí služeb při selhání pro dostupné uzly v pořádku.

Další informace o vysoké dostupnosti v měřítku najdete v tématu Vysoká dostupnost databáze v měřítku.

Urychlené obnovení databáze (ADR)

Zrychlené obnovení databáze (ADR) je nová funkce databázového stroje, která významně vylepšuje dostupnost databáze, zejména v případě dlouhotrvajících transakcí. pravidla automatického nasazení jsou v tuto chvíli k dispozici pro Azure SQL Database, azure SQL Managed Instance a azure Synapse Analytics.

Testování odolnosti proti chybám aplikace

Vysoká dostupnost je základní součástí služby SQL Database a platformy SQL Managed Instance, která funguje pro vaši databázovou aplikaci transparentně. Nicméně chápeme, že možná budete chtít otestovat, jaký budou operace automatického převzetí služeb při selhání iniciované během plánovaných nebo neplánovaných událostí mít vliv na aplikaci předtím, než ji nasadíte do produkčního prostředí. Převzetí služeb při selhání můžete aktivovat ručně voláním speciálního rozhraní API pro restartování databáze, elastického fondu nebo spravované instance. V případě zóny redundantního serveru nebo databáze zřízené Pro obecné účely a elastického fondu by volání rozhraní API mělo za následek přesměrování připojení klientů k nové primární databázi v zóně dostupnosti odlišnou od zóny dostupnosti staré primární služby. Takže kromě testování toho, jak převzetí služeb při selhání ovlivňuje stávající databázové relace, můžete také ověřit, jestli se v důsledku změn v latenci sítě změní na koncový výkon. Vzhledem k tomu, že operace restartování je rušivá a velké množství těchto prostředků by mohlo navýšit platformu, pro každou databázi, elastický fond nebo spravovanou instanci je každých 15 minut povoleno pouze jedno volání převzetí služeb při selhání.

Převzetí služeb při selhání se dá iniciovat pomocí PowerShellu, REST API nebo Azure CLI:

Závěr

Azure SQL Database a Azure SQL Managed Instance jsou integrované řešení s vysokou dostupností, které je hluboko integrované s platformou Azure. je závislý na Service Fabric pro detekci selhání a obnovení, v úložišti objektů Blob v Azure pro ochranu dat a na Zóny dostupnosti pro zajištění vyšší odolnosti proti chybám (jak je uvedeno výše v dokumentu, který zatím není použitelný pro Azure SQL Managed Instance). kromě toho SQL Database a SQL spravované Instance využívají technologii skupin dostupnosti Always On z Instance SQL Server pro replikaci a převzetí služeb při selhání. Kombinace těchto technologií umožňuje aplikacím plně realizovat výhody modelu kombinovaného úložiště a podporuje nejnáročnější SLA.

Další kroky

• Informace o zóny dostupnosti Azure
• Informace o Service Fabric
• informace o Azure Traffic Manager
• naučte se iniciovat ruční převzetí služeb při selhání v SQL Managed Instance .
• Další možnosti pro vysokou dostupnost a zotavení po havárii najdete v tématu Kontinuita podnikových aplikací .