Sdílet prostřednictvím


Spolehlivost ve službě Azure SQL Managed Instance

Spravovaná instance Azure SQL je plně spravovaný databázový stroj PaaS (Platforma jako služba). Poskytuje téměř 100% kompatibilitu funkcí s SQL Serverem. Azure SQL Managed Instance zpracovává většinu funkcí správy databází, jako je upgrade, opravy, zálohování a monitorování bez zásahu uživatele. Běží na nejnovější stabilní verzi databázového stroje SQL Serveru a opraveného operačního systému s integrovanou vysokou dostupností.

Při používání Azure je spolehlivost sdílenou odpovědností. Microsoft nabízí celou řadu možností, které podporují odolnost a obnovení. Zodpovídáte za pochopení toho, jak tyto možnosti fungují ve všech službách, které používáte, a výběrem možností, které potřebujete ke splnění vašich obchodních cílů a cílů dostupnosti.

Tento článek popisuje, jak zajistit odolnost služby Azure SQL Managed Instance vůči nejrůznějším potenciálním výpadkům a problémům, včetně přechodných chyb, výpadků zón dostupnosti a výpadků oblastí. Popisuje také, jak můžete použít zálohy k zotavení z jiných typů problémů, jak zvládnout údržbu služeb a zvýrazní některé klíčové informace o smlouvě o úrovni služeb (SLA) spravované instance Azure SQL.

Doporučení pro produkční nasazení pro spolehlivost

U většiny produkčních nasazení služby SQL Managed Instance zvažte následující doporučení:

Přehled architektury spolehlivosti

Spravované instance SQL pro obecné účely běží na jednom uzlu, který spravuje Azure Service Fabric . Při každém upgradu databázového stroje nebo operačního systému nebo zjištění selhání funguje služba SQL Managed Instance se službou Service Fabric k přesunutí procesu bezstavového databázového stroje do jiného bezstavového výpočetního uzlu, který má dostatečnou bezplatnou kapacitu. Databázové soubory se ukládají ve službě Azure Blob Storage, která má integrované funkce redundance. Data a soubory protokolu se odpojí od původního výpočetního uzlu a připojí se k nově inicializovanému procesu databázového stroje.

Spravované instance SQL pro důležité obchodní informace používají v clusteru několik replik. Cluster obsahuje dva typy replik:

  • Jedna primární replika s přístupem k zákaznickým úlohám pro čtení a zápis

  • Až pět sekundárních replik (výpočetních prostředků a úložiště), které obsahují kopie dat

Primární replika průběžně a postupně odesílá změny do sekundárních replik, což zajišťuje zachování dat na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tento proces zaručuje, že pokud primární nebo sekundární replika s možností čtení nebudou k dispozici, bude plně synchronizovaná replika vždy dostupná pro převzetí služeb při selhání.

SQL Managed Instance a Service Fabric iniciují přepnutí na záložní kopii mezi replikami. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, aby byl zajištěn dostatečný počet replik v clusteru 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 na čitelnou sekundární repliku na základě připojovacího řetězce.

Redundancy

Ve výchozím nastavení služba SQL Managed Instance dosahuje redundance rozložením výpočetních uzlů a dat do jednoho datacentra v primární oblasti. Tento přístup chrání vaše data během následujících očekávaných a neočekávaných výpadků:

  • Operace správy iniciované zákazníkem, které vedou ke krátkému výpadku

  • Operace údržby služeb

  • Selhání sítě nebo napájení v malém měřítku

  • Problémy a výpadky datacentra, které zahrnují následující komponenty:

    • Stojan pro servery, kde běží stroje, které zajišťují chod vaší služby

    • 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

  • Problémy s databázovým strojem SQL

  • Potenciální neplánované lokalizované výpadky

Další informace o tom, jak služba SQL Managed Instance poskytuje redundanci, najdete v tématu Dostupnost prostřednictvím redundance místních a zón.

Odolnost proti přechodným chybám

Přechodné chyby jsou krátká, přerušovaná selhání ve složkách. V distribuovaném prostředí, jako je cloud, se vyskytují často a jsou normální součástí provozu. Přechodné chyby se opravují po krátké době. Je důležité, aby vaše aplikace mohly zpracovávat přechodné chyby, obvykle opakováním ovlivněných požadavků.

Všechny aplikace hostované v cloudu by měly při komunikaci se všemi cloudovými rozhraními API, databázemi a dalšími komponentami postupovat podle pokynů pro zpracování přechodných chyb Azure. Další informace najdete v tématu Doporučení pro zpracování přechodných chyb.

Spravovaná instance SQL automaticky zpracovává důležité úlohy údržby, jako jsou opravy, zálohy a upgrady databázového stroje SQL a Windows. Zpracovává také neplánované události, jako jsou selhání hardwaru, softwaru nebo sítě. Sql Managed Instance se může rychle zotavit i za nejdůležitějších okolností, což zajišťuje, že vaše data budou vždy dostupná. Většina uživatelů si nevšimne, že se upgrady provádějí nepřetržitě.

Pokud je instance aktualizována nebo přepne při selhání, je výpadek minimální, pokud ve své aplikaci použijete logiku opakování. Odolnost aplikace můžete otestovat na přechodné chyby.

Odolnost proti chybám zóny dostupnosti

Poznámka:

Redundance zón není v současné době dostupná pro úroveň služby Pro obecné účely příští generace.

Zóny dostupnosti jsou fyzicky oddělené skupiny datacenter v rámci oblasti Azure. Když jedna zóna selže, mohou služby přejít na jednu ze zbývajících zón.

Když povolíte zónově redundantní konfiguraci, můžete zajistit, aby vaše spravovaná instance SQL byla odolná vůči velké sadě selhání, včetně katastrofických výpadků datacentra, bez jakýchkoli změn logiky aplikace.

Sql Managed Instance dosahuje redundance zón umístěním bezstavových výpočetních uzlů do různých zón dostupnosti. Spoléhá na stavové ZRS připojené k danému uzlu, který aktuálně obsahuje aktivní proces databázového stroje SQL. Pokud dojde k výpadku, proces databázového stroje SQL se aktivuje na jednom z bezstavových výpočetních uzlů, které pak přistupují k datům ve stavovém úložišti.

Sql Managed Instance dosahuje redundance zón umístěním replik spravované instance SQL do několika zón dostupnosti. Aby se zabránilo jedinému bodu selhání, řídicí okruh se také duplikuje napříč více zónami. Provoz řídicí vrstvy se směruje do vyrovnávače zatížení, který je také nasazený napříč zónami dostupnosti. Azure Traffic Manager řídí směrování provozu z řídicí roviny do nástroje pro vyrovnávání zatížení.

Požadavky

  • Podpora oblastí: Redundance zón pro službu SQL Managed Instance je podporována ve vybraných oblastech. Další informace najdete v tématu Podporované oblasti.

  • Redundance úložiště zálohování: Pokud chcete povolit redundanci zón pro spravovanou instanci SQL, nastavte redundanci úložiště zálohování na ZRS nebo geograficky zónově redundantní úložiště (GZRS).

Náklady

Když povolíte redundanci zón, vzniknou dodatečné náklady za spravovanou instanci SQL a zónově redundantní zálohy. Další informace najdete na stránce s cenami.

Můžete ušetřit tím, že se zavazujete používat výpočetní prostředky za zvýhodněnou sazbu po dobu, která zahrnuje zónově redundantní instance na úrovni služby Pro důležité obchodní informace. Další informace najdete v tématu Rezervace pro službu SQL Managed Instance.

Konfigurujte podporu zón dostupnosti

Tato část vysvětluje, jak nakonfigurovat podporu zóny dostupnosti pro spravované instance SQL:

  • Povolení redundance zón: Informace o konfiguraci redundance zón u nových a existujících instancí najdete v tématu Konfigurace redundance zóny.

    Všechny operace škálování pro službu SQL Managed Instance, včetně povolení redundance zón, probíhají online a vyžadují minimální až žádný výpadek. Další informace naleznete v tématu Doba trvání operací správy.

  • Zakázání redundance zóny: Redundanci zón můžete zakázat stejným postupem, jak povolit redundanci zón. Tento proces je online operace podobná upgradu standardní úrovně služby. Na konci procesu se instance migruje z zónově redundantní infrastruktury na infrastrukturu s jednou zónou.

Chování, když jsou všechny zóny v pořádku

Tato část popisuje, co očekávat, když je spravovaná instance SQL nakonfigurovaná tak, aby byla zónově redundantní a všechny zóny dostupnosti jsou funkční:

  • Směrování provozu mezi zónami: Během normálních operací se požadavky směrují do uzlu, na kterém běží výpočetní vrstva služby SQL Managed Instance.

  • Replikace dat mezi zónami: Databázové soubory se ukládají ve službě Azure Storage pomocí ZRS, který je připojený k jakému uzlu aktuálně obsahuje aktivní proces databázového stroje SQL.

    Operace zápisu jsou synchronní a nejsou považovány za dokončené, dokud se data úspěšně nereplikují napříč všemi zónami dostupnosti. Tato synchronní replikace zajišťuje silnou konzistenci a nulovou ztrátu dat během selhání zóny. Může ale vést k mírně vyšší latenci zápisu v porovnání s místně redundantním úložištěm.

  • Směrování provozu mezi zónami: Během normálních operací se požadavky směrují na primární repliku vaší spravované instance SQL.

  • Replikace dat mezi zónami: Primární replika průběžně a postupně odesílá změny do sekundárních replik v různých zónách dostupnosti. Tento proces zajišťuje zachování dat na dostatečném počtu sekundárních replik před potvrzením každé transakce. Tyto repliky se nacházejí v různých zónách dostupnosti. Tento proces zaručuje, že pokud primární nebo čitelná sekundární replika z jakéhokoli důvodu nebudou k dispozici, bude plně synchronizovaná replika vždy dostupná pro převzetí služeb při selhání.

    Vzhledem k tomu, že zónově redundantní instance mají repliky v různých datacentrech s určitou vzdáleností, může zvýšená latence sítě zvýšit dobu potvrzení transakce. Toto zvýšení může ovlivnit výkon některých úloh OLTP (Online Transaction Processing). Většina aplikací není citlivá na tuto dodatečnou latenci.

Chování při selhání zóny

Tato část popisuje, co očekávat, když je spravovaná instance SQL nakonfigurovaná tak, aby byla zónově redundantní a jedna nebo více zón dostupnosti není k dispozici:

  • Detekce a odpověď: Spravovaná instance SQL zodpovídá za detekci selhání v zóně dostupnosti a odpovídá na ně. Nemusíte dělat nic, abyste zahájili převzetí zóny.
  • Aktivní požadavky: Pokud je zóna dostupnosti nedostupná, všechny požadavky zpracovávané v vadné zóně dostupnosti se ukončí a musí se opakovat. Pokud chcete, aby vaše aplikace byly odolné vůči těmto typům problémů, přečtěte si pokyny k odolnosti proti přechodným chybám .
  • Přesměrování provozu: Služba SQL Managed Instance spolupracuje s Service Fabric na přesun databázového stroje do vhodného bezstavového výpočetního uzlu, který je v jiné zóně dostupnosti a má dostatečnou bezplatnou kapacitu. Po dokončení převzetí služeb při selhání se nová připojení automaticky přesměrují na nový primární výpočetní uzel.

    Při přechodu z jednoho výpočetního uzlu na druhý výpočetní uzel může dojít k určitému snížení výkonu při vysokém zatížení, protože nový proces databázového stroje začíná studenou mezipamětí.

  • Přesměrování provozu: Služba SQL Managed Instance spolupracuje se službou Service Fabric na výběr vhodné repliky v jiné zóně dostupnosti, aby se stala primární replikou. Jakmile se sekundární replika stane novou primární replikou, vytvoří se další sekundární replika, aby byl zajištěn dostatečný počet replik v clusteru pro zachování kvora. Po dokončení převzetí služeb při selhání se nová připojení automaticky přesměrují na novou primární repliku nebo na čitelnou sekundární repliku na základě připojovacího řetězce.
  • Očekávaný výpadek: Během převzetí služeb při selhání zóny dostupnosti může dojít k malému výpadku. Výpadek je obvykle kratší než 30 sekund, což by vaše aplikace měla tolerovat, pokud dodržuje pokyny k odolnosti vůči přechodným chybám .

  • Očekávaná ztráta dat: Během převzetí služeb při selhání zóny dostupnosti se neočekává žádná ztráta dat pro potvrzené transakce. Probíhající transakce je nutné opakovat.

Obnovení zóny

Když se zóna dostupnosti obnoví, služba SQL Managed Instance pracuje s Service Fabric k obnovení operací v obnovené zóně. Nevyžaduje se žádný zásah zákazníka.

Testování poruch zón

Platforma SQL Managed Instance spravuje směrování provozu, přepnutí při selhání a obnovení pro instance se zónovou redundancí. Vzhledem k tomu, že je tato funkce plně spravována, nemusíte zahajovat ani ověřovat procesy selhání zóny dostupnosti. Můžete ale ověřit zvládání selhání vaší aplikace.

Odolnost proti selháním v celé oblasti

Jednotlivá spravovaná instance SQL se nasadí v rámci jedné oblasti. Sekundární spravovanou instanci SQL ale můžete nasadit v samostatné oblasti Azure a nakonfigurovat skupinu převzetí služeb při selhání.

Skupiny převzetí služeb při selhání

Skupiny pro převzetí služeb při selhání automaticky geograficky replikují vaše data a podle zásad převzetí mohou automaticky nebo ručně převzít funkce v případě regionálního selhání.

Tato část shrnuje klíčové informace o skupinách převzetí služeb při selhání, ale je důležité si projít přehled skupin převzetí služeb při selhání a osvědčené postupy , abyste se dozvěděli více o tom, jak fungují a jak je nakonfigurovat.

Zásady převzetí služeb při selhání

Při vytváření skupiny převzetí služeb při selhání vyberete zásadu převzetí služeb při selhání, která určuje, kdo je zodpovědný za zjištění výpadku a provedení převzetí služeb při selhání. Můžete nakonfigurovat dva typy zásad pro přechod na záložní systém.

  • Převzetí služeb při selhání spravované zákazníkem (doporučeno): Pokud používáte zásady převzetí služeb při selhání spravované zákazníkem, můžete se rozhodnout, jestli provést převzetí služeb při selhání, což nezpůsobí ztrátu dat, nebo vynucené převzetí služeb při selhání, které může mít za následek ztrátu dat. Vynucené převzetí služeb při selhání se používá jako způsob obnovy během výpadků, když primární instance není přístupná.

  • Převzetí služeb při selhání spravované Microsoftem: Převzetí služeb při selhání spravované Microsoftem se používá pouze ve výjimečných situacích k aktivaci vynuceného převzetí služeb při selhání.

Důležité

Využijte možnosti převzetí služeb při poruše spravované zákazníkem k vývoji, testování a implementaci vašich plánů zotavení po havárii. Nespoléhejte na převzetí služeb při selhání spravovaném Microsoftem, které se může používat jenom za extrémních okolností. Převzetí služeb při selhání spravované Microsoftem je pravděpodobně zahájeno pro celou oblast. Nejde ho zahájit pro jednotlivé skupiny převzetí služeb při selhání, spravované instance SQL, předplatná ani zákazníky. Převzetí služeb při selhání může probíhat v různých časech pro různé služby Azure. Doporučujeme použít převzetí služeb při selhání spravované zákazníkem.

Podpora oblastí

Pro spravované instance SQL ve skupině převzetí služeb při selhání můžete vybrat libovolnou oblast Azure. Kvůli vysoké latenci širokých sítí používá geografická replikace mechanismus asynchronní replikace. Pokud chcete snížit zpoždění sítě, vyberte oblasti, které mají připojení s nízkou latencí. Další informace o latenci mezi oblastmi Azure najdete ve statistikách obousměrné latence sítě Azure.

Náklady

Při vytváření více spravovaných instancí SQL v různých oblastech se vám bude účtovat každá spravovaná instance SQL.

Pokud ale vaše sekundární instance nemá připojené žádné úlohy čtení nebo aplikace, můžete ušetřit náklady na licencování tím, že repliku navrhnete jako pohotovostní instanci. Další informace najdete v tématu Konfigurace pohotovostní repliky bez licence pro službu SQL Managed Instance.

Další informace o cenách služby SQL Managed Instance najdete v tématu Informace o cenách služeb.

Konfigurace podpory více oblastí

Informace o konfiguraci skupiny převzetí služeb při selhání najdete v tématu Konfigurace skupiny převzetí služeb při selhání pro službu SQL Managed Instance.

Plánování a řízení kapacit

Během převzetí služeb při selhání se provoz přesměruje do sekundární spravované instance SQL. Je důležité, aby vaše sekundární spravovaná instance SQL byla připravená přijímat provoz. Vytvořte sekundární spravovanou instanci SQL se stejnou úrovní služby, generováním hardwaru a velikostí výpočetních prostředků jako primární instance.

Další informace o škálování spravovaných instancí SQL ve skupině převzetí služeb při selhání najdete v tématu Škálování instancí.

Chování, když jsou všechny oblasti v pořádku

Tato část popisuje, co očekávat, když jsou spravované instance SQL nakonfigurované k použití skupin převzetí služeb při selhání ve více oblastech a všechny oblasti fungují správně:

  • Směrování provozu mezi oblastmi: Během normálních operací přejdou požadavky na čtení i zápis do jedné primární instance v primární oblasti.

    Skupiny převzetí služeb při selhání také poskytují samostatný koncový bod naslouchacího procesu jen pro čtení. Během normálních operací se tento koncový bod připojí k sekundární instanci a směruje provoz jen pro čtení zadaný v připojovacím řetězci.

    Další informace o tom, jak skupiny převzetí služeb při selhání odesílají provoz do jednotlivých instancí a jak můžete směrovat provoz na naslouchací koncový bod pouze pro čtení, najdete v přehledu skupin převzetí služeb při selhání a osvědčených postupech.

  • Replikace dat mezi oblastmi: Ve výchozím nastavení se data replikují asynchronně z primární instance do sekundární spravované instance SQL.

    Vzhledem k tomu, že geografická replikace je asynchronní, pokud provádíte vynucené převzetí služeb při selhání, je možné zaznamenat ztrátu dat. Prodlevu replikace můžete monitorovat, abyste pochopili potenciální ztrátu dat během vynuceného převzetí služeb při selhání. Další informace najdete v kontrolním seznamu DR.

    Pokud potřebujete eliminovat ztrátu dat z asynchronní replikace během převzetí služeb při selhání, nastavte aplikaci tak, aby blokovala volající vlákno do potvrzení, že poslední potvrzená transakce byla přenesená a zajištěná v transakčním protokolu sekundární databáze. Tento přístup vyžaduje vlastní vývoj a snižuje výkon vaší aplikace. Další informace naleznete v tématu Prevence ztráty důležitých dat.

Chování při selhání oblasti

Tato část popisuje, co očekávat, když jsou spravované instance SQL nakonfigurované tak, aby používaly skupiny převzetí služeb při selhání ve více oblastech a došlo k výpadku v primární oblasti:

  • Detekce a odpověď: Odpovědnost za detekci a odpověď závisí na zásadách při selhání, které vaše skupina při selhání používá.

    • Zásady převzetí služeb při selhání spravované zákazníkem: Zodpovídáte za zjištění selhání v oblasti a aktivaci převzetí služeb při selhání nebo vynuceného převzetí služeb při selhání sekundární instanci ve skupině převzetí služeb při selhání.

      Pokud provedete převzetí služeb, služba SQL Managed Instance čeká, až se data synchronizují do sekundární instance před provedením postupu převzetí služeb.

      Pokud provedete vynucené převzetí služeb při selhání, služba SQL Managed Instance okamžitě přepne sekundární instanci na primární roli, aniž by čekala na přenesení nedávných změn z primární instance. Tento typ převzetí služeb při selhání může mít za následek ztrátu dat.

    • Zásady převzetí služeb při selhání spravované Microsoftem: Převzetí služeb při selhání spravované microsoftem se provádí za výjimečných okolností. Když Microsoft aktivuje převzetí služeb při selhání, skupina převzetí služeb při selhání automaticky provede vynucené převzetí služeb při selhání sekundární instanci ve skupině převzetí služeb při selhání. Pro produkční úlohy ale doporučujeme použít zásady převzetí služeb při selhání spravované zákazníkem, abyste mohli řídit, kdy dojde k převzetí služeb při selhání.

  • Aktivní požadavky: Když dojde k převzetí služeb při selhání, všechny požadavky, které se zpracovávají, se ukončí a je nutné je znovu odeslat. Pokud chcete, aby vaše aplikace byly odolné vůči těmto typům problémů, přečtěte si téma Odolnost proti přechodným chybám.

  • Očekávaná ztráta dat: Velikost ztráty dat závisí na tom, jak konfigurujete aplikaci. Další informace najdete v tématu Přehled skupin převzetí služeb při selhání a osvědčené postupy.

  • Očekávaný výpadek: Během převzetí služeb při selhání skupiny může dojít k malému výpadku. Výpadek je obvykle kratší než 60 sekund.

  • Přesměrování provozu: Jakmile skupina převzetí služeb při selhání dokončí proces převzetí služeb při selhání, provoz pro čtení i zápis se automaticky směruje do nové primární instance. Pokud vaše aplikace ve svých připojovacích řetězcích používají koncové body skupiny převzetí služeb při selhání, nemusí po převzetí služeb při selhání upravovat své připojovací řetězce.

Obnovení oblasti

Skupiny převzetí služeb při selhání se po obnovení automaticky nevrátí do primární oblasti, a proto je vaší zodpovědností zahájit navrácení služeb po obnovení.

Testování selhání regionů

Můžete otestovat převzetí služeb skupiny při selhání.

Testování skupiny pro převzetí služeb při selhání je pouze jednou částí testu obnovy po havárii. Další informace naleznete v tématu Provádění cvičení DR.

Zálohování a obnovení

Zálohujte databáze, které chrání před různými riziky, včetně ztráty dat. Zálohy je možné obnovit, aby se zotavily z náhodné ztráty dat, poškození nebo jiných problémů. Zálohování není totéž jako geografická replikace a mají různé účely a snižují různá rizika.

Sql Managed Instance automaticky přebírá úplné, rozdílové a transakční zálohy vašich databází. Další informace o typech záloh, jejich četnosti, možnostech obnovení, nákladech na úložiště a šifrování zálohování najdete v tématu Automatizované zálohy ve službě SQL Managed Instance.

SQL Managed Instance poskytuje integrované automatizované zálohy a také podporuje zálohy jen pro uživatelem iniciované kopírování pro uživatelské databáze. Další informace najdete v tématu Zálohování pouze kopírování.

Replikace zálohování

Při konfiguraci automatizovaných záloh pro spravovanou instanci SQL můžete určit, jak se mají zálohy replikovat. Zálohy nakonfigurované tak, aby se ukládaly na ZRS, mají vyšší úroveň odolnosti. Doporučujeme nakonfigurovat zálohy tak, aby používaly jeden z následujících typů úložiště:

  • ZRS pro odolnost v rámci oblasti, pokud má oblast zóny dostupnosti

  • GZRS za účelem zlepšení odolnosti záloh napříč oblastmi, pokud má oblast zóny dostupnosti a je spárovaná s jinou oblastí

  • GRS, pokud vaše oblast nepodporuje zóny dostupnosti, ale má spárovanou oblast

Další informace o různých typech úložiště a jejich možnostech najdete v tématu Redundance úložiště zálohování.

Geografické obnovení

Schopnost geografického obnovení je základní řešení pro obnovu po havárii, které umožňuje obnovit zálohované kopie do jiné oblasti Azure. Geografické zálohování obvykle vyžaduje značné výpadky a ztrátu dat. Pokud chcete dosáhnout vyšší úrovně obnovitelnosti v případě regionálního přerušení, měli byste nakonfigurovat skupiny převzetí služeb při selhání.

Pokud používáte geografické obnovení, musíte zvážit, jak zajistit dostupnost záloh v sekundární oblasti:

Odolnost vůči údržbě služeb

Když spravovaná instance SQL provádí údržbu vaší instance, zůstane spravovaná instance SQL plně dostupná, ale může podléhat krátkým rekonfiguracím. Při výskytu události údržby můžou klientské aplikace pozorovat krátké přerušení připojení. Vaše klientské aplikace by měly postupovat podle pokynů k odolnosti a přechodným chybám , aby se minimalizovaly účinky.

SQL Managed Instance umožňuje zadat časové období údržby, které se obecně používá pro upgrady služeb a další operace údržby. Konfigurace časového období údržby vám může pomoct minimalizovat vedlejší účinky, jako je automatické převzetí služeb při selhání, během pracovní doby. Můžete také obdržet předběžné oznámení o plánované údržbě.

Další informace najdete v tématu Časové období údržby ve službě SQL Managed Instance.

Smlouva o úrovni služeb

Smlouva o úrovni služeb (SLA) pro služby Azure popisuje očekávanou dostupnost každé služby a podmínky, které musí vaše řešení splnit, aby bylo dosaženo očekávané dostupnosti. Další informace najdete v tématu Smlouvy SLA pro online služby.

Pro službu SQL Managed Instance platí smlouva SLA o dostupnosti pouze v případě, že je vaše virtuální síť Azure správně nakonfigurovaná tak, aby neohrožovala provoz správy. Tato konfigurace zahrnuje velikost podsítě, skupiny zabezpečení sítě (NSG), trasy definované uživatelem (UDR), konfiguraci DNS a další prostředky, které ovlivňují správu a používání síťových prostředků. Další informace o požadované síťové konfiguraci pro službu SQL Managed Instance najdete v tématu Požadavky na síť.