Vysoká dostupnost a Azure SQL DatabaseHigh-availability and Azure SQL Database

Cílem architektury vysoké dostupnosti v Azure SQL Database je zaručit, že je vaše databáze v provozu a bude běžet 99,99% času, aniž byste se museli starat o dopad na operace údržby a výpadky.The goal of the High Availability architecture in Azure SQL Database is to guarantee that your database is up and running 99.99% of time, without worrying about the impact of maintenance operations and outages. Azure automaticky zpracovává důležité úlohy údržby, jako jsou třeba opravy, zálohování, upgrady Windows a SQL, a také neplánované události, jako je například základní hardware, software nebo selhání sítě.Azure automatically handles critical servicing tasks, such as patching, backups, Windows and SQL upgrades, as well as unplanned events such as underlying hardware, software, or network failures. Pokud je podkladová instance SQL opravena nebo převezme služby při selhání, nemůžete si všimnout, pokud ve své aplikaci použijete logiku opakování .When the underlying SQL instance is patched or fails over, the downtime is not noticeable if you employ retry logic in your app. Azure SQL Database můžete rychle obnovit i v nejdůležitějších případech, které zajistí, že vaše data jsou vždycky k dispozici.Azure SQL Database can quickly recover even in the most critical circumstances ensuring that your data is always available.

Ř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í.The high availability solution is designed to ensure that committed data is never lost due to failures, that maintenance operations do not affect your workload, and that the database will not be a single point of failure in your software architecture. 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.There are no maintenance windows or downtimes that should require you to stop the workload while the database is upgraded or maintained.

K dispozici jsou dva modely architektury s vysokou dostupností, které se používají v Azure SQL Database:There are two high-availability architectural models that are used in Azure SQL Database:

  • Standardní model dostupnosti založený na oddělení výpočetních prostředků a úložiště.Standard availability model that is based on a separation of compute and storage. Spoléhá se na vysokou dostupnost a spolehlivost vzdálené vrstvy úložiště.It relies on high availability and reliability of the remote storage tier. Tato architektura cílí na rozpočtově orientované podnikové aplikace, které mohou tolerovat některé snížení výkonu během údržby.This architecture targets budget-oriented business applications that can tolerate some performance degradation during maintenance activities.
  • Model dostupnosti Premium, který je založen na clusteru procesů databázového stroje.Premium availability model that is based on a cluster of database engine processes. Spoléhá na to, že je vždy kvorum dostupných uzlů databázového stroje.It relies on the fact that there is always a quorum of available database engine nodes. 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.This architecture targets mission critical applications with high IO performance, high transaction rate and guarantees minimal performance impact to your workload during maintenance activities.

Azure SQL Database běží na nejnovější stabilní verzi SQL Server databázový stroj a operační systém Windows a většina uživatelů si nevšimnete, že se upgradují průběžně.Azure SQL Database runs on the latest stable version of SQL Server Database Engine and Windows OS, and most users would not notice that upgrades are performed continuously.

Dostupnost úrovně služeb Basic, Standard a Pro obecné účelyBasic, Standard, and General Purpose service tier availability

Tyto úrovně služeb využívají standardní architekturu dostupnosti.These service tiers leverage the standard availability architecture. 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.The following figure shows four different nodes with the separated compute and storage layers.

Oddělení výpočtů a úložiště

Standardní model dostupnosti obsahuje dvě vrstvy:The standard availability model includes two layers:

  • 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.A stateless compute layer that runs the sqlservr.exe process and contains only transient and cached data, such as TempDB, model databases on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. 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.This stateless node is operated by Azure Service Fabric that initializes sqlservr.exe, controls health of the node, and performs failover to another node if necessary.
  • Stavová Datová vrstva s databázovými soubory (. mdf/. ldf), které jsou uložené v úložišti objektů BLOB v Azure.A stateful data layer with the database files (.mdf/.ldf) that are stored in Azure Blob storage. Služba Azure Blob Storage má vestavěnou funkci dostupnosti dat a redundance.Azure blob storage has built-in data availability and redundancy feature. Zaručuje, že každý záznam v souboru protokolu nebo na stránce v datovém souboru se zachová i v případě selhání procesu SQL Server.It guarantees that every record in the log file or page in the data file will be preserved even if SQL Server process crashes.

Pokaždé, když je databázový stroj nebo operační systém upgradovaný, nebo dojde k selhání, Azure Service Fabric přesune bezstavový proces SQL Server na jiný bezstavový výpočetní uzel s dostatečnou volnou kapacitou.Whenever the database engine or the operating system is upgraded, or a failure is detected, Azure Service Fabric will move the stateless SQL Server process to another stateless compute node with sufficient free capacity. 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 procesu SQL Server.Data in Azure Blob storage is not affected by the move, and the data/log files are attached to the newly initialized SQL Server process. Tento proces garantuje 99,99% dostupnost, ale během přechodu může dojít k výraznému snížení výkonu, protože nová instance SQL Server začíná studenou mezipamětí.This process guarantees 99.99% availability, but a heavy workload may experience some performance degradation during the transition since the new SQL Server instance starts with cold cache.

Dostupnost úrovně služeb Premium a Pro důležité obchodní informacePremium and Business Critical service tier availability

Úrovně služeb Premium a Pro důležité obchodní informace využívají model dostupnosti Premium, který integruje výpočetní prostředky (SQL Server proces databázového stroje) a úložiště (místně připojená jednotka SSD) na jednom uzlu.Premium and Business Critical service tiers leverage the Premium availability model, which integrates compute resources (SQL Server Database Engine process) and storage (locally attached SSD) on a single node. 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.High availability is achieved by replicating both compute and storage to additional nodes creating a three to four-node cluster.

Cluster uzlů databázového stroje

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í.The underlying database files (.mdf/.ldf) are placed on the attached SSD storage to provide very low latency IO to your workload. Vysoká dostupnost se implementuje pomocí technologie podobné SQL Server skupinám dostupnosti Always On.High availability is implemented using a technology similar to SQL Server Always On Availability Groups. Cluster zahrnuje jednu primární repliku (SQL Server proces), která je přístupná pro úlohy zákazníka pro čtení i zápis, a až tři sekundární repliky (výpočetní výkon a úložiště) obsahující kopie dat.The cluster includes a single primary replica (SQL Server process) that is accessible for read-write customer workloads, and up to three secondary replicas (compute and storage) containing copies of data. 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.The primary node constantly pushes changes to the secondary nodes in order and ensures that the data is synchronized to at least one secondary replica before committing each transaction. 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í.This process guarantees that if the primary node crashes for any reason, there is always a fully synchronized node to fail over to. Převzetí služeb při selhání iniciuje Service Fabric Azure.The failover is initiated by the Azure Service Fabric. 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).Once the secondary replica becomes the new primary node, another secondary replica is created to ensure the cluster has enough nodes (quorum set). Po dokončení převzetí služeb při selhání se připojení SQL automaticky přesměrují do nového primárního uzlu.Once failover is complete, SQL connections are automatically redirected to the new primary node.

Model dostupnosti Premium navíc nabízí možnost přesměrovat připojení SQL jen pro čtení na jednu ze sekundárních replik.As an extra benefit, the premium availability model includes the ability to redirect read-only SQL connections to one of the secondary replicas. 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.This feature is called Read Scale-Out. It provides 100% additional compute capacity at no extra charge to off-load read-only operations, such as analytical workloads, from the primary replica.

Dostupnost vrstvy služeb s škálovatelným škálovánímHyperscale service tier availability

Architektura vrstvy služeb s více instancemi je popsaná v tématu Architektura distribuovaných funkcí.The Hyperscale service tier architecture is described in Distributed functions architecture.

Funkční architektura s škálovatelným škálováním

Model dostupnosti v rámci škálování zahrnuje čtyři vrstvy:The availability model in Hyperscale includes four layers:

  • Bezstavová výpočetní vrstva, která spouští procesy sqlservr.exe a obsahuje pouze přechodná data a data uložená v mezipaměti, například nepokrývání mezipaměti RBPEX cache, TempDB, modelová databáze atd. na připojené SSD a v mezipaměti plánů, fondu vyrovnávacích pamětí a fondu columnstore.A stateless compute layer that runs the sqlservr.exe processes and contains only transient and cached data, such as non-covering RBPEX cache, TempDB, model database, etc. on the attached SSD, and plan cache, buffer pool, and columnstore pool in memory. 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í.This stateless layer includes the primary compute replica and optionally a number of secondary compute replicas that can serve as failover targets.
  • Bezstavová vrstva úložiště vytvořená stránkami serverů.A stateless storage layer formed by page servers. Tato vrstva je distribuovaný modul úložiště pro sqlservr.exe procesy běžící na výpočetních replikách.This layer is the distributed storage engine for the sqlservr.exe processes running on the compute replicas. 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.Each page server contains only transient and cached data, such as covering RBPEX cache on the attached SSD, and data pages cached in memory. 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.Each page server has a paired page server in an active-active configuration to provide load balancing, redundancy, and high availability.
  • 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.A stateful transaction log storage layer formed by the compute node running the Log service process, the transaction log landing zone, and transaction log long term storage. 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.Landing zone and long term storage use Azure Storage, which provides availability and redundancy for transaction log, ensuring data durability for committed transactions.
  • 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ů.A stateful data storage layer with the database files (.mdf/.ndf) that are stored in Azure Storage and are updated by page servers. Tato vrstva používá funkce pro dostupnost a redundanci dat Azure Storage.This layer uses data availability and redundancy features of 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ů.It guarantees that every page in a data file will be preserved even if processes in other layers of Hyperscale architecture crash, or if compute nodes fail.

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.Compute nodes in all Hyperscale layers run on Azure Service Fabric, which controls health of each node and performs failovers to available healthy nodes as necessary.

Další informace o vysoké dostupnosti v měřítku najdete v tématu Vysoká dostupnost databáze v měřítku.For more information on high availability in Hyperscale, see Database High Availability in Hyperscale.

Redundantní konfigurace zónyZone redundant configuration

Ve výchozím nastavení se cluster uzlů pro model dostupnosti Premium vytvoří ve stejném datovém centru.By default, the cluster of nodes for the premium availability model is created in the same datacenter. 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.With the introduction of Azure Availability Zones, SQL Database can place different replicas of the Business Critical database to different availability zones in the same region. 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).To eliminate a single point of failure, the control ring is also duplicated across multiple zones as three gateway rings (GW). Směrování na konkrétního okruhu brány se řídí službou Azure Traffic Manager (ATM).The routing to a specific gateway ring is controlled by Azure Traffic Manager (ATM). Vzhledem k tomu, že zóna redundantní konfigurace v úrovních služby Premium nebo Pro důležité obchodní informace nevytváří další redundanci databáze, můžete ji povolit bez dalších poplatků.Because the zone redundant configuration in the Premium or Business Critical service tiers does not create additional database redundancy, you can enable it at no extra cost. Výběrem redundantní konfigurace zóny můžete zajistit, aby vaše databáze Premium nebo Pro důležité obchodní informace 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.By selecting a zone redundant configuration, you can make your Premium or Business Critical databases resilient to a much larger set of failures, including catastrophic datacenter outages, without any changes to the application logic. Můžete také převést všechny existující databáze nebo fondy Premium nebo Pro důležité obchodní informace na zónu redundantní konfigurace.You can also convert any existing Premium or Business Critical databases or pools to the zone redundant configuration.

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.Because the zone redundant databases have replicas in different datacenters with some distance between them, the increased network latency may increase the commit time and thus impact the performance of some OLTP workloads. Do konfigurace s jednou zónou se můžete kdykoli vrátit tím, že zakážete nastavení redundance zóny.You can always return to the single-zone configuration by disabling the zone redundancy setting. Tento proces je online operace podobná standardnímu upgradu vrstvy služeb.This process is an online operation similar to the regular service tier upgrade. 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.At the end of the process, the database or pool is migrated from a zone redundant ring to a single zone ring or vice versa.

Důležité

Redundantní databáze zóny a elastické fondy se momentálně podporují jenom v úrovních služby Premium a Pro důležité obchodní informace ve vybraných oblastech.Zone redundant databases and elastic pools are currently only supported in the Premium and Business Critical service tiers in select regions. Při použití Pro důležité obchodní informace úrovně je redundantní konfigurace zóny dostupná jenom v případě, že je vybraný Gen5 výpočetní hardware.When using the Business Critical tier, zone redundant configuration is only available when the Gen5 compute hardware is selected. Aktuální informace o oblastech, které podporují redundantní databáze zóny, najdete v tématu Podpora služeb v jednotlivých oblastech.For up to date information about the regions that support zone redundant databases, see Services support by region.
Tato funkce není k dispozici ve spravované instanci.This feature is not available in Managed instance.

Redundantní verze architektury s vysokou dostupností v zóně je znázorněna v následujícím diagramu:The zone redundant version of the high availability architecture is illustrated by the following diagram:

redundantní zóna architektury vysoké dostupnosti

Urychlené obnovení databáze (ADR)Accelerated Database Recovery (ADR)

Accelerated Database Recovery (ADR) je nová funkce stroje SQL Database, která významně vylepšuje dostupnost databáze, zejména v případě dlouhotrvajících transakcí.Accelerated Database Recovery (ADR) is a new SQL database engine feature that greatly improves database availability, especially in the presence of long running transactions. Pro jednotlivé databáze, elastické fondy a Azure SQL Data Warehouse jsou aktuálně k dispozici pravidla automatického nasazení.ADR is currently available for single databases, elastic pools, and Azure SQL Data Warehouse.

Testování odolnosti proti chybám aplikaceTesting application fault resiliency

Vysoká dostupnost je základní součástí Azure SQL Database platformy, která je transparentně vhodná pro vaši databázovou aplikaci.High availability is a fundamental part of Azure SQL Database platform that works transparently for your database application. Nicméně víme, ž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í.However, we recognize that you may want to test how the automatic failover operations initiated during planned or unplanned events would impact the application before you deploy it to production. Můžete zavolat speciální rozhraní API pro restartování databáze nebo elastického fondu, ve kterém se zase aktivuje převzetí služeb při selhání.You can call a special API to restart a database or an elastic pool, which will in turn trigger a failover. V případě redundantní databáze nebo elastického fondu zóny 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.In the case of a zone redundant database or elastic pool, the API call would result in redirecting client connections to the new primary in an Availability Zone different from the Availability Zone of the old primary. 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.So in addition to testing how failover impacts existing database sessions, you can also verify if it changes the end-to-end performance due to changes in network latency. 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 nebo elastický fond je každých 30 minut povoleno pouze jedno volání převzetí služeb při selhání.Because the restart operation is intrusive and a large number of them could stress the platform, only one failover call is allowed every 30 minutes for each database or elastic pool.

Převzetí služeb při selhání se dá iniciovat pomocí REST API nebo PowerShellu.A failover can be initiated using REST API or PowerShell. REST API najdete v tématu převzetí služeb při selhání databáze a elastického fondu.For REST API, see Database failover and Elastic pool failover. Informace o PowerShellu najdete v tématu Invoke-AzSqlDatabaseFailover a Invoke-AzSqlElasticPoolFailover.For PowerShell, see Invoke-AzSqlDatabaseFailover and Invoke-AzSqlElasticPoolFailover. Volání REST API lze také provést z Azure CLI pomocí příkazu AZ REST Command.The REST API calls can also be made from Azure CLI using az rest command.

Důležité

Příkaz pro převzetí služeb při selhání není v současnosti k dispozici v úrovni služby a pro spravovanou instanci.The Failover command is currently not available in the Hyperscale service tier and for Managed Instance.

ZávěrConclusion

Azure SQL Database nabízí integrované řešení s vysokou dostupností, které je hluboko integrované s platformou Azure.Azure SQL Database features a built-in high availability solution, that is deeply integrated with the Azure platform. 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.It is dependent on Service Fabric for failure detection and recovery, on Azure Blob storage for data protection, and on Availability Zones for higher fault tolerance. Kromě toho využívá Azure SQL Database technologii skupiny dostupnosti Always On z SQL Server pro replikaci a převzetí služeb při selhání.In addition, Azure SQL database leverages the Always On Availability Group technology from SQL Server for replication and failover. 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.The combination of these technologies enables applications to fully realize the benefits of a mixed storage model and support the most demanding SLAs.

Další krokyNext steps