Sdílet prostřednictvím

Dostupnost prostřednictvím redundance – Azure SQL Database

  • Článek

Platí pro: Azure SQL Database

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

Přehled

SQL Database 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. 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 problémy:
    • rack, kde běží stroje, na kterých běží vaše služba
    • 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 (virtuální jádro) Vzdálené úložiště Ano Yes
Pro důležité obchodní informace (virtuální jádro) Místní úložiště Ano Yes
Hyperscale (virtuální jádro) Hyperškálování Ano Yes
Basic (DTU) Vzdálené úložiště Yes No
Standard (DTU) Vzdálené úložiště Yes No
Premium (DTU) Místní úložiště Ano Yes

Další informace o konkrétních smlouvách SLA pro různé úrovně služeb najdete 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 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.

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 tempdb model jsou databáze připojeného disku SSD, a naplánovat mezipaměť, fond vyrovnávací paměti a fond columnstore v paměti. Tento bezstavový uzel provozuje Azure Service Fabric, který inicializuje databázový stroj, řídí stav 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 (.mdf a .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. Přesunutí nemá vliv na data ve službě Azure Blob Storage a k nově inicializovanému procesu databázového stroje se připojí soubory dat a protokolů. 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 Pro důležité obchodní informace

Úroveň služby Premium nákupního modelu založeného na DTU a úroveň služby Pro důležité obchodní informace nákupního modelu založeného na virtuálních jádrech používají 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) do jednoho uzlu. Vysoká 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é 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 pořadí a zajišťuje, aby data byla zachována na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud dojde k selhání primární repliky nebo čitelné sekundární repliky z nějakého důvodu, vždy existuje plně synchronizovaná replika, na kterou se má převzít služby při selhání. Převzetí služeb při selhání inicializovala služba 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í kvora. 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á Čtení se škálováním na více instancí. Poskytuje 100% dodatečnou výpočetní kapacitu bez dalších poplatků za operace jen pro čtení, jako jsou analytické úlohy, z primární repliky.

Hyperškálování úrovně služby

Architektura úrovně služby Hyperscale je popsaná v architektuře distribuovaných funkcí.

Diagram znázorňující funkční architekturu Hyperscale

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 necoveringová mezipaměť tempdb RBPEX a model databáze atd. na připojeném disku SSD a plán mezipaměti, fond vyrovnávací paměti a fond columnstore 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é můžou sloužit jako cíle převzetí služeb při selhání.
  • 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ý stránkovací server má spárovaný stránkový server v konfiguraci 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 Pro důležité obchodní informace pro obecné účely a hyperškálování nákupního modelu založeného na virtuálních jádrech a pouze úroveň služby Premium nákupního modelu založeného na DTU – úrovně služby Basic a Standard nepodporují redundanci zón.

Zatímco každá úroveň služby implementuje zónovou redundanci odlišně, všechny implementace zajišťují cíl bodu obnovení (RPO) s nulovou ztrátou potvrzených dat při převzetí služeb při selhání.

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

Zónově redundantní konfigurace pro úroveň služby Pro obecné účely se nabízí pro bezserverové i zřízené výpočetní prostředky 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 tempdb model jsou databáze připojeného disku 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 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í.

Zónově redundantní verze architektury vysoké dostupnosti pro úroveň služby Pro obecné účely je znázorněna následujícím diagramem:

Diagram zónově redundantní konfigurace pro obecné účely

Při konfiguraci databází pro obecné účely s redundancí zón zvažte následující skutečnosti:

  • Pro úroveň Pro obecné účely je konfigurace zónově redundantní obecně dostupná v následujících oblastech:
    • (Afrika) Jihoafrická republika – sever
    • (Asie a Tichomoří) Austrálie – východ
    • (Asie a Tichomoří) Východní Asie
    • (Asie a Tichomoří) Japonsko – východ
    • (Asie a Tichomoří) Korea – střed
    • (Asie a Tichomoří) Jihovýchodní Asie
    • (Asie a Tichomoří) Indie – střed
    • (Asie a Tichomoří) Čína – sever 3
    • (Asie a Tichomoří) Spojené arabské emiráty – sever
    • (Evropa) Francie – střed
    • (Evropa) Německo – středozápad
    • (Evropa) Itálie – sever
    • (Evropa) Evropa – sever
    • (Evropa) Norsko – východ
    • (Evropa) Polsko – střed
    • (Evropa) Evropa – západ
    • (Europe) UK South
    • (Evropa) Švýcarsko – sever
    • (Evropa) Švédsko – střed
    • (Střední východ) Izrael – střed
    • (Střední východ) Katar – střed
    • (Severní Amerika) Kanada – střed
    • (Severní Amerika) USA – východ
    • (Severní Amerika) USA – východ 2
    • (Severní Amerika) USA – středojihoji
    • (Severní Amerika) USA – západ 2
    • (Severní Amerika) USA – západ 3
    • (Jižní Amerika) Brazílie – jih
  • Pro zónově redundantní dostupnost zvolte jiné časové období údržby, než je výchozí, je aktuálně dostupné ve vybraných oblastech.
  • 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 Pro důležité obchodní informace

Pokud je pro úroveň služby Premium nebo Pro důležité obchodní informace povolená redundance zón, repliky se umístí 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říč několika zónami jako tři kruhy brány (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 Pro důležité obchodní informace 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 databázi Premium nebo Pro důležité obchodní informace databáze 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. Na zónově redundantní konfiguraci můžete také převést všechny existující databáze premium nebo Pro důležité obchodní informace nebo elastické fondy.

Zónově redundantní verze architektury vysoké dostupnosti je znázorněna následujícím diagramem:

Diagram zónově redundantní architektury s vysokou dostupností

Při konfiguraci databází Premium nebo Pro důležité obchodní informace s redundancí zón zvažte následující skutečnosti:

Hyperškálování úrovně služby

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 hyperškálování PRMS a MOPRMS je dostupná v oblastech uvedených tady.

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é fondy.

Následující diagram znázorňuje základní architekturu zónově redundantních databází Hyperscale:

Diagram znázorňující 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, pokud je cílová databáze v jiné oblasti než zdroj nebo pokud se redundance úložiště zálohování databáze z cíle liší od zdrojové databáze, bude operace kopírování velikost operace kopírování.

  • Pro zónově redundantní dostupnost zvolte jiné časové období údržby, než je výchozí, je aktuálně dostupné ve vybraných oblastech.

  • 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 hyperškálování se vyžaduje alespoň 1 replika výpočetních prostředků s vysokou dostupností a použití zónově redundantního úložiště zálohování.

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é. master Zónově redundantní databáze je asynchronní proces a dokončení na pozadí bude nějakou dobu trvat.

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:ZoneRedundant master

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í ovlivňuje stávající relace databáze, můžete také ověřit, jestli změní výkon koncového typu kvůli změnám 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řevzetí služeb při selhání databáze az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI.
Elastický fond Invoke-AzSqlElasticPoolFailover Převzetí služeb při selhání elastického fondu az rest se může použít k vyvolání volání rozhraní REST API z Azure CLI.

Důležité

Příkaz převzetí služeb při selhání není k dispozici pro čitelné sekundární repliky databází Hyperscale.

Závěr

Azure SQL Database nabízí integrované řešení s vysokou dostupností, které je hluboce integrované s platformou Azure. Závisí na Service Fabric pro detekci a obnovení selhání, v úložišti objektů blob v Azure pro ochranu dat a na Zóny dostupnosti kvůli vyšší odolnosti proti chybám. Kromě toho SQL Database používá technologii skupiny dostupnosti AlwaysOn z SQL Serveru k synchronizaci dat 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

Další informace najdete tady: