Nastavení zotavení po havárii pro SQL Server

Tento článek popisuje, jak pomoct chránit back-end SQL Serveru aplikace. Provedete to pomocí kombinace technologií provozní kontinuity a zotavení po havárii (BCDR) SQL Serveru a Azure Site Recovery.

Než začnete, ujistěte se, že rozumíte možnostem zotavení po havárii SQL Serveru. Mezi tyto schopnosti patří:

  • Clustering s podporou převzetí služeb při selhání
  • Skupiny dostupnosti Always On
  • Zrcadlení databáze
  • Přesouvání protokolu
  • Aktivní geografická replikace
  • Skupiny automatického převzetí služeb při selhání

Kombinování technologií BCDR s Site Recovery

Volba technologie BCDR pro obnovení instancí SQL Serveru by měla být založená na vašich potřebách cíle doby obnovení (RTO) a cíle bodu obnovení (RPO), jak je popsáno v následující tabulce. Zkombinujte Site Recovery s operací převzetí služeb při selhání zvolené technologie a orchestrujte obnovení celé aplikace.

Typ nasazení Technologie BCDR Očekávané RTO pro SQL Server Očekávaný cíl bodu obnovení pro SQL Server
SQL Server na virtuálním počítači azure infrastruktura jako služba (IaaS) nebo v místním prostředí. Skupiny dostupnosti Always On Doba potřebná k tomu, aby sekundární replika byla primární. Vzhledem k tomu, že replikace do sekundární repliky je asynchronní, dojde ke ztrátě dat.
SQL Server na virtuálním počítači Azure IaaS nebo v místním prostředí. Clustering s podporou převzetí služeb při selhání (AlwaysOn FCI) Doba potřebná k převzetí služeb při selhání mezi uzly. Vzhledem k tomu, že FCI AlwaysOn používá sdílené úložiště, je stejné zobrazení instance úložiště k dispozici při převzetí služeb při selhání.
SQL Server na virtuálním počítači Azure IaaS nebo v místním prostředí. Zrcadlení databáze (režim s vysokým výkonem) Doba potřebná k vynucení služby, která používá zrcadlový server jako záložní pohotovostní server. Replikace je asynchronní. Zrcadlová databáze může poněkud zaostávat za primární databází. Prodleva je obvykle malá. Může se ale stát velkým, pokud je systém hlavního nebo zrcadlového serveru pod velkým zatížením.

Expediční protokol může být doplněním zrcadlení databáze. Jedná se o příznivou alternativu k asynchronnímu zrcadlení databáze.
SQL jako platforma jako služba (PaaS) v Azure

Tento typ nasazení zahrnuje izolované databáze a elastické fondy.
Aktivní geografická replikace 30 sekund po aktivaci převzetí služeb při selhání

Při aktivaci převzetí služeb při selhání pro jednu ze sekundárních databází se všechny ostatní sekundární databáze automaticky propojily s novým primárním serverem.
Cíl bodu obnovení (RPO) 5 sekund.

Aktivní geografická replikace používá technologii AlwaysOn SQL Serveru. Asynchronně replikuje potvrzené transakce v primární databázi do sekundární databáze pomocí izolace snímků.

U sekundárních dat je zaručeno, že nikdy nemají částečné transakce.
SQL jako PaaS nakonfigurovaný s aktivní geografickou replikací v Azure

Tento typ nasazení zahrnuje spravované instance, elastické fondy a izolované databáze.
Skupiny automatického převzetí služeb při selhání RTO 1 hodinu. Cíl bodu obnovení (RPO) 5 sekund.

Skupiny automatického převzetí služeb při selhání poskytují sémantiku skupiny nad aktivní geografickou replikací. Používá se ale stejný asynchronní mechanismus replikace.
SQL Server na virtuálním počítači Azure IaaS nebo v místním prostředí. Replikace s využitím Azure Site Recovery RTO je obvykle kratší než 15 minut. Další informace najdete ve verzi SLA RTO, kterou poskytuje Site Recovery. Jedna hodina pro konzistenci aplikace a pět minut pro konzistenci chyb. Pokud hledáte nižší cíl bodu obnovení, použijte jiné technologie BCDR.

Poznámka:

Při ochraně úloh SQL pomocí Site Recovery je potřeba vzít v úvahu několik důležitých aspektů:

  • Site Recovery je nezávislá na aplikacích. Site Recovery může pomoct chránit jakoukoli verzi SQL Serveru nasazenou v podporovaném operačním systému. Další informace najdete v matici podpory pro obnovení replikovaných počítačů.
  • Můžete se rozhodnout použít Site Recovery pro jakékoli nasazení v Azure, Hyper-V, VMware nebo fyzické infrastruktuře. Postupujte podle pokynů na konci tohoto článku o tom, jak pomoct chránit cluster SQL Serveru pomocí Site Recovery.
  • Ujistěte se, že míra změn dat zjištěná na počítači spadá do limitů Site Recovery. Rychlost změn se měří v bajtech zápisu za sekundu. U počítačů s Windows můžete tuto míru změn zobrazit tak , že ve Správci úloh vyberete kartu Výkon . Sledujte rychlost zápisu jednotlivých disků.
  • Site Recovery podporuje replikaci instancí clusteru s podporou převzetí služeb při selhání na Prostory úložiště s přímým přístupem. Další informace najdete v tématu povolení Prostory úložiště s přímým přístupem replikace.

Při migraci úloh SQL do Azure se doporučuje použít pokyny k výkonu SQL Serveru na virtuálních počítačích Azure.

Zotavení po havárii aplikace

Site Recovery orchestruje testovací převzetí služeb při selhání a převzetí služeb při selhání celé aplikace pomocí plánů obnovení.

Existuje několik předpokladů, které zajistí, aby byl váš plán obnovení plně přizpůsobený podle vašich potřeb. Každé nasazení SQL Serveru obvykle vyžaduje nasazení služby Active Directory. Potřebuje také připojení pro vaši aplikační vrstvu.

Krok 1: Nastavení služby Active Directory

Nastavte službu Active Directory v sekundární lokalitě pro obnovení, aby SQL Server běžel správně.

  • Malý podnik: Máte několik aplikací a jeden řadič domény pro místní lokalitu. Pokud chcete převzít služby při selhání celé lokality, použijte replikaci Site Recovery. Tato služba replikuje řadič domény do sekundárního datacentra nebo do Azure.
  • Střední až velké podniky: Možná budete muset nastavit další řadiče domény.
    • Pokud máte velký počet aplikací, máte doménovou strukturu Active Directory a chcete převzít služby při selhání aplikací nebo úlohou, nastavte jiný řadič domény v sekundárním datacentru nebo v Azure.
    • Pokud k obnovení do vzdálené lokality používáte skupiny dostupnosti AlwaysOn, nastavte na sekundární lokalitě nebo v Azure jiný řadič domény. Tento řadič domény se používá pro obnovenou instanci SQL Serveru.

Pokyny v tomto článku předpokládají, že řadič domény je k dispozici v sekundárním umístění. Další informace najdete v postupech, které pomáhají chránit službu Active Directory pomocí Site Recovery.

Krok 2: Zajištění připojení k jiným úrovním

Po spuštění databázové vrstvy v cílové oblasti Azure se ujistěte, že máte připojení k aplikacím a webovým vrstvám. Proveďte nezbytné kroky předem, abyste ověřili připojení s testovacím převzetím služeb při selhání.

Informace o tom, jak navrhovat aplikace pro důležité informace o připojení, najdete v těchto příkladech:

Krok 3: Spolupráce s funkcí AlwaysOn, aktivní geografickou replikací a skupinami automatického převzetí služeb při selhání

Technologie BCDR AlwaysOn, aktivní geografická replikace a skupiny automatického převzetí služeb při selhání mají sekundární repliky SQL Serveru spuštěného v cílové oblasti Azure. Prvním krokem pro převzetí služeb při selhání aplikace je zadat tuto repliku jako primární. Tento krok předpokládá, že už máte řadič domény v sekundární oblasti. Tento krok nemusí být nutný, pokud se rozhodnete provést automatické převzetí služeb při selhání. Převzetí služeb při selhání webu a aplikačních vrstev pouze po dokončení převzetí služeb při selhání databáze

Poznámka:

Pokud jste pomohli chránit počítače SQL pomocí Site Recovery, stačí vytvořit skupinu obnovení těchto počítačů a přidat jejich převzetí služeb při selhání v plánu obnovení.

Vytvořte plán obnovení s virtuálními počítači aplikační a webové vrstvy. Následující kroky ukazují, jak přidat převzetí služeb při selhání databázové vrstvy:

  1. Naimportujte skripty pro převzetí služeb při selhání skupiny dostupnosti SQL na virtuálním počítači Resource Manageru i klasickém virtuálním počítači. Naimportujte skripty do svého účtu Azure Automation.

    Button to deploy the Resource Manager template to Azure.

  2. Přidejte skript ASR-SQL-FailoverAG jako předběžnou akci první skupiny plánu obnovení.

  3. Podle pokynů dostupných ve skriptu vytvořte automatizační proměnnou. Tato proměnná poskytuje název skupin dostupnosti.

Krok 4: Provedení testovacího převzetí služeb při selhání

Některé technologie BCDR, jako je SQL AlwaysOn, nativně nepodporují testovací převzetí služeb při selhání. Následující přístup doporučujeme pouze při použití těchto technologií.

  1. Nastavte azure Backup na virtuálním počítači, který je hostitelem repliky skupiny dostupnosti v Azure.

  2. Před aktivací testovacího převzetí služeb při selhání plánu obnovení obnovte virtuální počítač ze zálohy pořízené v předchozím kroku.

    Screenshot showing window for restoring a configuration from Azure Backup

  3. Vynuťte vynucovat kvorum ve virtuálním počítači, které bylo obnoveno ze zálohy.

  4. Aktualizujte IP adresu naslouchacího procesu tak, aby byla adresa dostupná v testovací síti převzetí služeb při selhání.

    Screenshot of rules window and IP address properties dialog

  5. Přineste posluchače online.

    Screenshot of window labeled Content_AG showing server names and statuses

  6. Ujistěte se, že nástroj pro vyrovnávání zatížení v síti s podporou převzetí služeb při selhání má jednu IP adresu z front-endového fondu IP adres odpovídající každému naslouchacímu procesu skupiny dostupnosti a virtuálnímu počítači s SQL Serverem v back-endovém fondu.

    Screenshot of window titled

    Screenshot of window titled

  7. V pozdějších skupinách obnovení přidejte převzetí služeb při selhání aplikační vrstvy následované webovou vrstvou pro tento plán obnovení.

  8. Proveďte testovací převzetí služeb při selhání plánu obnovení a otestujte kompletní převzetí služeb při selhání vaší aplikace.

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

Po přidání skriptu v kroku 3 a jeho ověření v kroku 4 můžete provést převzetí služeb při selhání plánu obnovení vytvořeného v kroku 3.

Kroky převzetí služeb při selhání pro aplikační a webové vrstvy by měly být stejné v testovacím převzetí služeb při selhání i v plánech obnovení převzetí služeb při selhání.

Jak pomoct s ochranou clusteru SQL Serveru

Pro cluster s edicí SQL Server Standard nebo SQL Serverem 2008 R2 doporučujeme použít replikaci Site Recovery k ochraně SQL Serveru.

Z Azure do Azure a z místního prostředí do Azure

Site Recovery neposkytuje podporu clusteru hostů při replikaci do oblasti Azure. Edice SQL Server Standard také neposkytuje nízkonákladové řešení zotavení po havárii. V tomto scénáři doporučujeme chránit cluster SQL Serveru do samostatné instance SQL Serveru v primárním umístění a obnovit ho v sekundární lokalitě.

  1. Nakonfigurujte jinou samostatnou instanci SQL Serveru v primární oblasti Azure nebo v místní lokalitě.

  2. Nakonfigurujte instanci tak, aby sloužila jako zrcadlo pro databáze, které chcete chránit. Nakonfigurujte zrcadlení v režimu vysoké bezpečnosti.

  3. Nakonfigurujte Site Recovery v primární lokalitě pro virtuální počítače Azure, Hyper-V nebo VMware a fyzické servery.

  4. Replikace Site Recovery slouží k replikaci nové instance SQL Serveru do sekundární lokality. Protože se jedná o vysoce bezpečnostní zrcadlovou kopii, synchronizuje se s primárním clusterem, ale replikuje se pomocí replikace Site Recovery.

    Image of a standard cluster that shows the relationship and flow among a primary site, Site Recovery, and Azure

Aspekty navrácení služeb po obnovení

U clusterů SQL Server Standard vyžaduje navrácení služeb po obnovení po neplánovaném převzetí služeb při selhání zálohování a obnovení SQL Serveru. Tato operace se provádí z instance zrcadla do původního clusteru s opětovným zřízením zrcadla.

Nejčastější dotazy

Jak sql Server získá licenci při použití s Site Recovery?

Replikace Site Recovery pro SQL Server je pokryta výhodou zotavení po havárii Software Assurance. Toto pokrytí platí pro všechny scénáře Site Recovery: místní zotavení po havárii Azure a zotavení po havárii Azure IaaS mezi oblastmi. Další informace najdete na stránce s cenami služby Azure Site Recovery.

Bude Site Recovery podporovat moji verzi SQL Serveru?

Site Recovery je nezávislá na aplikacích. Site Recovery může pomoct chránit jakoukoli verzi SQL Serveru nasazenou v podporovaném operačním systému. Další informace najdete v matici podpory pro obnovení replikovaných počítačů.

Funguje ASR s transakční replikací SQL?

Vzhledem k tomu, že SLUŽBA ASR používá kopírování na úrovni souborů, sql nemůže zaručit synchronizaci serverů v přidružené topologii replikace SQL v době převzetí služeb při selhání ASR. To může způsobit selhání agentů logreader nebo distribuce kvůli neshodě LSN, což může přerušit replikaci. Pokud převzetí služeb při selhání vydavatele, distributora nebo odběratele v topologii replikace, musíte znovu sestavit replikaci. Doporučuje se znovu inicializovat předplatné SQL Serveru.

Další kroky

  • Přečtěte si další informace o architektuře Site Recovery.
  • Další informace o řešeních s vysokou dostupností pro obnovení v sekundární oblasti Azure najdete v případě SQL Serveru v Azure.
  • V případě SLUŽBY SQL Database najdete další informace o možnostech provozní kontinuity a vysoké dostupnosti pro obnovení v sekundární oblasti Azure.
  • V případě počítačů s SQL Serverem v místním prostředí najdete další informace o možnostech vysoké dostupnosti pro obnovení ve službě Azure Virtual Machines.