Zotavení po havárii SharePoint Serveru 2013 v Microsoft Azure
Pomocí Azure můžete vytvořit prostředí pro zotavení po havárii pro místní farmu SharePointu. Tento článek popisuje, jak navrhnout a implementovat toto řešení.
Podívejte se na video s přehledem zotavení po havárii SharePoint Serveru 2013.
Když vaše místní prostředí SharePointu zasáhne havárie, je nejvyšší prioritou znovu rychle zprovoznění systému. Zotavení po havárii se SharePointem je rychlejší a jednodušší, pokud už máte v Microsoft Azure spuštěné prostředí zálohování. Toto video vysvětluje hlavní koncepty prostředí sharepointového teplého převzetí služeb při selhání a doplňuje úplné podrobnosti dostupné v tomto článku.
Tento článek použijte s následujícím modelem řešení: Zotavení po havárii SharePointu v Microsoft Azure.
Použití služeb infrastruktury Azure k zotavení po havárii
Mnoho organizací nemá prostředí pro zotavení po havárii pro SharePoint, jehož sestavení a údržba v místním prostředí může být nákladné. Služby infrastruktury Azure poskytují přesvědčivé možnosti pro prostředí zotavení po havárii, která jsou flexibilnější a levnější než místní alternativy.
Mezi výhody používání služeb infrastruktury Azure patří:
Méně nákladových prostředků Udržujte a plaťte za méně prostředků než místní prostředí pro zotavení po havárii. Počet prostředků závisí na tom, které prostředí pro zotavení po havárii zvolíte: studený pohotovostní režim, teplý pohotovostní režim nebo aktivní pohotovostní režim.
Lepší flexibilita prostředků V případě havárie snadno navyšte kapacitu obnovovací sharepointové farmy tak, aby splňovala požadavky na zatížení. Škálování na více instancí, když už prostředky nepotřebujete.
Nižší závazek datacentra Místo investic do sekundárního datacentra v jiné oblasti použijte služby infrastruktury Azure.
Existují méně složité možnosti pro organizace, které teprve začínají s zotavením po havárii, a pokročilé možnosti pro organizace s vysokými požadavky na odolnost. Definice studeného, teplého a horkého pohotovostního prostředí se při hostování prostředí na cloudové platformě trochu liší. Následující tabulka popisuje tato prostředí pro vytvoření farmy obnovení SharePointu v Azure.
Tabulka: Prostředí pro obnovení
| Typ prostředí pro obnovení | Popis |
|---|---|
| Horké | Farma s plnou velikostí je zřízená, aktualizovaná a spuštěná v pohotovostním režimu. |
| Teplé | Farma je sestavená a virtuální počítače jsou spuštěné a aktualizované. Obnovení zahrnuje připojení databází obsahu, zřizování aplikací služby a procházení obsahu. Farma může být menší verzí produkční farmy a pak škálovat na více instancí, aby obsloužila celou uživatelskou základnu. |
| Studené | Farma je plně sestavená, ale virtuální počítače se zastaví. Údržba prostředí zahrnuje občasné spuštění virtuálních počítačů, opravy, aktualizaci a ověření prostředí. V případě havárie spusťte úplné prostředí. |
Je důležité vyhodnotit cíle doby obnovení vaší organizace (RTO) a cíle bodů obnovení (RPO). Tyto požadavky určují, které prostředí je nejvhodnější investicí pro vaši organizaci.
Pokyny v tomto článku popisují, jak implementovat teplé pohotovostní prostředí. Můžete ho také přizpůsobit studenému pohotovostnímu prostředí, i když potřebujete postupovat podle dalších postupů pro podporu tohoto typu prostředí. Tento článek nepopisuje, jak implementovat aktivní pohotovostní prostředí.
Další informace o řešeních zotavení po havárii najdete v tématech Koncepty vysoké dostupnosti a zotavení po havárii v SharePointu 2013 a Volba strategie zotavení po havárii pro SharePoint 2013.
Popis řešení
Řešení zotavení po havárii v aktivním pohotovostním režimu vyžaduje následující prostředí:
Místní produkční farma SharePointu
Obnovovací sharepointová farma v Azure
Připojení site-to-site VPN mezi těmito dvěma prostředími
Následující obrázek znázorňuje tyto tři prvky.
Obrázek: Prvky řešení teplého pohotovostního režimu v Azure
SQL Server přesouvání protokolů pomocí replikace distribuovaného systému souborů DFS (Distributed File System) slouží ke kopírování záloh databází a transakčních protokolů do farmy pro obnovení v Azure:
DfsR přenáší protokoly z produkčního prostředí do prostředí pro obnovení. Ve scénáři sítě WAN je služba DFSR efektivnější než odesílání protokolů přímo na sekundární server v Azure.
Protokoly se přehrávají do SQL Server v prostředí pro obnovení v Azure.
Databáze obsahu SharePointu dodané protokolem nepřipojujete do prostředí pro obnovení, dokud se neprovede cvičení obnovení.
Pomocí následujících kroků obnovte farmu:
Zastavte odesílání protokolů.
Ukončení přijímání provozu do primární farmy
Přehrajte poslední transakční protokoly.
Připojte databáze obsahu k farmě.
Obnovte aplikace služeb z databází replikovaných služeb.
Aktualizujte záznamy DNS (Domain Name System) tak, aby ukazovaly na farmu obnovení.
Spusťte úplné procházení.
Doporučujeme, abyste tyto kroky pravidelně zkoušeli a zdokumentovali je, abyste měli jistotu, že vaše obnovení proběhne hladce. Připojení databází obsahu a obnovení aplikací služeb může nějakou dobu trvat a obvykle zahrnuje určitou ruční konfiguraci.
Po provedení obnovení poskytuje toto řešení položky uvedené v následující tabulce.
Tabulka: Cíle obnovení řešení
| Položky | Popis |
|---|---|
| Weby a obsah | Weby a obsah jsou k dispozici v prostředí pro obnovení. |
| Nová instance vyhledávání | V tomto řešení s aktivním pohotovostním režimem se vyhledávání neobnoví z vyhledávacích databází. Komponenty vyhledávání ve farmě obnovení jsou nakonfigurovány co nejpodobně jako produkční farma. Po obnovení webů a obsahu se spustí úplná procházení, která znovu sestaví index vyhledávání. Nemusíte čekat na dokončení procházení, aby byly weby a obsah k dispozici. |
| Služby | Služby, které ukládají data v databázích, se obnovují z databází dodaných protokolem. Služby, které neukládají data v databázích, se jednoduše spustí. Ne všechny služby s databázemi je potřeba obnovit. Následující služby není potřeba obnovovat z databází a je možné je jednoduše spustit po převzetí služeb při selhání: Shromažďování dat o využití a stavu Stavová služba Automatizace wordu Jakákoli jiná služba, která nepoužívá databázi |
Při řešení složitějších cílů obnovení můžete spolupracovat se službou Microsoft Consulting Services (MCS) nebo partnerem. Tyto informace jsou shrnuty v následující tabulce.
Tabulka: Další položky, které může řešit MCS nebo partner
| Položky | Popis |
|---|---|
| Synchronizace vlastních řešení farmy | V ideálním případě je konfigurace farmy obnovení identická s produkční farmou. Ve spolupráci s konzultantem nebo partnerem můžete vyhodnotit, jestli se vlastní řešení farmy replikují a jestli je tento proces zavedený pro udržování synchronizovaných dvou prostředí. |
| Připojení k místním zdrojům dat | Replikace připojení k back-endovým datovým systémům, jako jsou zálohovaná připojení řadiče domény (BDC) a vyhledávání zdrojů obsahu, nemusí být praktické. |
| Scénáře obnovení vyhledávání | Vzhledem k tomu, že nasazení podnikového vyhledávání bývají poměrně jedinečná a složitá, obnovení vyhledávání z databází vyžaduje větší investici. Ve spolupráci s konzultantem nebo partnerem můžete identifikovat a implementovat scénáře obnovení vyhledávání, které může vaše organizace vyžadovat. |
Pokyny uvedené v tomto článku předpokládají, že místní farma je už navržená a nasazená.
Podrobná architektura
V ideálním případě je konfigurace farmy obnovení v Azure stejná jako místní produkční farma, včetně následujících:
Stejná reprezentace rolí serveru
Stejná konfigurace vlastních nastavení
Stejná konfigurace součástí vyhledávání
Prostředí v Azure může být menší verze produkční farmy. Pokud plánujete po převzetí služeb při selhání škálovat farmu pro obnovení na více instancí, je důležité, aby byly na začátku reprezentovány všechny typy rolí serveru.
Některé konfigurace nemusí být praktické pro replikaci v prostředí převzetí služeb při selhání. Nezapomeňte otestovat postupy převzetí služeb při selhání a prostředí, abyste zajistili, že farma převzetí služeb při selhání poskytuje očekávanou úroveň služeb.
Toto řešení nepředepisuje konkrétní topologii pro farmu služby SharePoint. Toto řešení se zaměřuje na použití Azure pro farmu převzetí služeb při selhání a implementaci přesouvání protokolů a dfsr mezi těmito dvěma prostředími.
Teplá pohotovostní prostředí
V teplém pohotovostním prostředí jsou všechny virtuální počítače v prostředí Azure spuštěné. Prostředí je připravené na cvičení nebo událost převzetí služeb při selhání.
Následující obrázek znázorňuje řešení zotavení po havárii z místní sharepointové farmy do sharepointové farmy založené na Azure, která je nakonfigurovaná jako teplé pohotovostní prostředí.
Obrázek: Topologie a klíčové prvky produkční farmy a farmy obnovení v pohotovostním režimu
V tomto diagramu:
Vedle sebe jsou znázorněná dvě prostředí: místní sharepointová farma a pohotovostní farma v Azure.
Každé prostředí obsahuje sdílenou složku.
Každá farma zahrnuje čtyři úrovně. Pro zajištění vysoké dostupnosti zahrnuje každá vrstva dva servery nebo virtuální počítače, které jsou nakonfigurované stejně pro určitou roli, jako jsou front-end služby, distribuovaná mezipaměť, back-endové služby a databáze. Na tomto obrázku není důležité popisovat konkrétní komponenty. Obě farmy jsou nakonfigurované stejně.
Čtvrtá vrstva je databázová. Přesouvání protokolů se používá ke kopírování protokolů ze sekundárního databázového serveru v místním prostředí do sdílené složky ve stejném prostředí.
DfsR zkopíruje soubory ze sdílené složky v místním prostředí do sdílené složky v prostředí Azure.
Přesouvání protokolů přehrává protokoly ze sdílené složky v prostředí Azure do primární repliky ve skupině dostupnosti SQL Server AlwaysOn v prostředí pro obnovení.
Studená pohotovostní prostředí
V chladném pohotovostním prostředí je možné vypnout většinu virtuálních počítačů sharepointové farmy. (Doporučujeme občas spouštět virtuální počítače, například každé dva týdny nebo jednou za měsíc, aby se každý virtuální počítač mohl synchronizovat s doménou.) Následující virtuální počítače v prostředí Azure Recovery musí zůstat spuštěné, aby se zajistil nepřetržitý provoz přesouvání protokolů a dfsr:
Sdílená složka
Primární databázový server
Alespoň jeden virtuální počítač se systémem Windows Server Active Directory Domain Services a DNS
Následující obrázek znázorňuje prostředí Azure pro převzetí služeb při selhání, ve kterém běží virtuální počítač sdílené složky a primární virtuální počítač databáze SharePointu. Všechny ostatní virtuální počítače SharePointu se zastaví. Virtuální počítač, na kterém běží Windows Server Active Directory a DNS, se nezobrazuje.
Obrázek: Farma obnovení v pohotovostním režimu bez provozu se spuštěnými virtuálními počítači
Po převzetí služeb při selhání do studeného pohotovostního prostředí se spustí všechny virtuální počítače a musí být nakonfigurovaná metoda pro dosažení vysoké dostupnosti databázových serverů, například SQL Server skupiny dostupnosti AlwaysOn.
Pokud je implementováno více skupin úložiště (databáze jsou rozložené do více než jedné SQL Server skupiny vysoké dostupnosti), musí být spuštěná primární databáze pro každou skupinu úložišť, aby bylo možné přijmout protokoly přidružené k této skupině úložiště.
Dovednosti a zkušenosti
V tomto řešení zotavení po havárii se používá několik technologií. Aby se zajistilo, že tyto technologie vzájemně spolupracují podle očekávání, musí být každá komponenta v místním prostředí a prostředí Azure nainstalovaná a správně nakonfigurovaná. Doporučujeme, aby osoba nebo tým, který toto řešení nastavil, měl silné pracovní znalosti a praktické dovednosti s technologiemi popsanými v následujících článcích:
Služba replikace systému souborů DFS (Distributed File System)
Clustering windows serveru s podporou převzetí služeb při selhání (WSFC) s SQL Server
Nakonec doporučujeme skriptovací dovednosti, které můžete použít k automatizaci úloh spojených s těmito technologiemi. K dokončení všech úloh popsaných v tomto řešení je možné použít dostupná uživatelská rozhraní. Ruční přístup ale může být časově náročný a náchylný k chybám a přináší nekonzistentní výsledky.
Kromě Windows PowerShell existují také knihovny Windows PowerShell pro SQL Server, SharePoint Server a Azure. Nezapomeňte na T-SQL, který může také pomoct zkrátit čas na konfiguraci a údržbu prostředí pro zotavení po havárii.
Plán zotavení po havárii
Tento plán předpokládá, že už máte farmu SharePoint Serveru 2013 nasazenou v produkčním prostředí.
Tabulka: Plán zotavení po havárii
| Fáze | Popis |
|---|---|
| Fáze 1 | Návrh prostředí pro zotavení po havárii |
| Fáze 2 | Vytvořte virtuální síť Azure a připojení VPN. |
| Fáze 3 | Nasaďte Windows Active Directory a Domain Name Services do virtuální sítě Azure. |
| Fáze 4 | Nasaďte farmu obnovení SharePointu v Azure. |
| Fáze 5 | Nastavte dfsr mezi farmami. |
| Fáze 6 | Nastavte odesílání protokolů do farmy obnovení. |
| Fáze 7 | Ověřte řešení převzetí služeb při selhání a obnovení. To zahrnuje následující postupy a technologie: Zastavte odesílání protokolů. Obnovte zálohy. Procházení obsahu. Obnovte služby. Správa záznamů DNS |
Fáze 1: Návrh prostředí pro zotavení po havárii
Pomocí pokynů v tématu Architektury Microsoft Azure pro SharePoint 2013 můžete navrhnout prostředí pro zotavení po havárii, včetně farmy obnovení SharePointu. K zahájení procesu návrhu můžete použít grafiku v řešení zotavení po havárii SharePointu v souboru Azure Visio. Před zahájením jakékoli práce v prostředí Azure doporučujeme navrhnout celé prostředí.
Kromě pokynů uvedených v tématu Architektury Microsoft Azure pro SharePoint 2013 pro návrh virtuální sítě, připojení VPN, Active Directory a farmy SharePointu nezapomeňte do prostředí Azure přidat roli sdílené složky.
Kvůli podpoře přesouvání protokolů v řešení pro zotavení po havárii se virtuální počítač sdílené složky přidá do podsítě, ve které se nacházejí databázové role. Sdílená složka také slouží jako třetí uzel většiny uzlů pro skupinu dostupnosti SQL Server AlwaysOn. Toto je doporučená konfigurace pro standardní farmu Služby SharePoint, která používá skupiny dostupnosti AlwaysOn SQL Server.
Poznámka
Je důležité zkontrolovat předpoklady pro účast databáze ve skupině dostupnosti SQL Server AlwaysOn. Další informace najdete v tématu Požadavky, omezení a doporučení pro skupiny dostupnosti AlwaysOn.
Obrázek: Umístění souborového serveru používaného pro řešení zotavení po havárii
V tomto diagramu se virtuální počítač sdílené složky přidá do stejné podsítě v Azure, která obsahuje role databázového serveru. Nepřidávejte virtuální počítač sdílené složky do skupiny dostupnosti s jinými rolemi serveru, jako jsou role SQL Server.
Pokud se obáváte vysoké dostupnosti protokolů, zvažte použití jiného přístupu pomocí SQL Server zálohování a obnovení se službou Azure Blob Storage Service. Jedná se o novou funkci v Azure, která ukládá protokoly přímo na adresu URL úložiště objektů blob. Toto řešení neobsahuje pokyny k používání této funkce.
Při návrhu farmy pro obnovení mějte na paměti, že úspěšné prostředí pro zotavení po havárii přesně odpovídá produkční farmě, kterou chcete obnovit. Velikost farmy pro obnovení není při návrhu, nasazení a testování farmy pro obnovení nejdůležitější. Škálování farmy se v závislosti na obchodních požadavcích liší v závislosti na jednotlivých organizacích. Farma se škálováním na více instancí může být možné použít pro krátký výpadek nebo dokud požadavky na výkon a kapacitu nevyžadují škálování farmy.
Nakonfigurujte farmu obnovení co nejidenticky jako produkční farmu tak, aby splňovala vaše požadavky smlouvy o úrovni služeb (SLA) a poskytovala funkce, které potřebujete pro podporu vaší firmy. Při návrhu prostředí pro zotavení po havárii se také podívejte na proces správy změn pro vaše produkční prostředí. Doporučujeme, abyste proces správy změn rozšířili na prostředí pro obnovení aktualizací prostředí pro obnovení ve stejném intervalu jako produkční prostředí. V rámci procesu správy změn doporučujeme udržovat podrobný inventář konfigurace farmy, aplikací a uživatelů.
Fáze 2: Vytvoření virtuální sítě Azure a připojení VPN
Připojení místní sítě k virtuální síti Microsoft Azure ukazuje, jak naplánovat a nasadit virtuální síť v Azure a jak vytvořit připojení VPN. Postupujte podle pokynů v tématu a proveďte následující postupy:
Naplánujte privátní adresní prostor IP adres Virtual Network.
Naplánujte změny infrastruktury směrování pro Virtual Network.
Naplánujte pravidla brány firewall pro provoz do a z místního zařízení VPN.
Vytvořte virtuální síť mezi místy v Azure.
Nakonfigurujte směrování mezi místní sítí a Virtual Network.
Fáze 3: Nasazení služby Active Directory a služby Domain Name Services do virtuální sítě Azure
Tato fáze zahrnuje nasazení Windows Server Active Directory i DNS do Virtual Network v hybridním scénáři, jak je popsáno v tématu Architektury Microsoft Azure pro SharePoint 2013 a jak je znázorněno na následujícím obrázku.
Obrázek: Konfigurace domény hybridní služby Active Directory
Na obrázku jsou dva virtuální počítače nasazené ve stejné podsíti. Každý z těchto virtuálních počítačů hostuje dvě role: Active Directory a DNS.
Před nasazením služby Active Directory v Azure si přečtěte pokyny pro nasazení Windows Server Active Directory v Azure Virtual Machines. Tyto pokyny vám pomůžou určit, jestli pro vaše řešení potřebujete jinou architekturu nebo jiné nastavení konfigurace.
Podrobné pokyny k nastavení řadiče domény v Azure najdete v tématu Instalace řadiče repliky Doména služby Active Directory ve virtuálních sítích Azure.
Před touto fází jste nenasazovali virtuální počítače do Virtual Network. Virtuální počítače pro hostování služby Active Directory a DNS pravděpodobně nejsou největšími virtuálními počítači, které pro řešení potřebujete. Před nasazením těchto virtuálních počítačů nejprve vytvořte největší virtuální počítač, který chcete použít v Virtual Network. To pomáhá zajistit, aby vaše řešení v Azure získalo značku, která umožňuje největší velikost, kterou potřebujete. Tento virtuální počítač v tuto chvíli nemusíte konfigurovat. Jednoduše ho vytvořte a odložte stranou. Pokud to neuděláte, můžete při pozdějším pokusu o vytvoření větších virtuálních počítačů narazit na omezení, což byl problém v době psaní tohoto článku.
Fáze 4: Nasazení farmy obnovení SharePointu v Azure
Nasaďte farmu služby SharePoint do Virtual Network podle plánů návrhu. Před nasazením rolí SharePointu v Azure může být užitečné si projít téma Plánování SharePointu 2013 ve službách Azure Infrastructure Services .
Představte si následující postupy, které jsme se naučili při vytváření prostředí testování konceptu:
Vytvořte virtuální počítače pomocí Azure Portal nebo PowerShellu.
Azure a Hyper-V nepodporují dynamickou paměť. Ujistěte se, že je to důležité pro vaše plány výkonu a kapacity.
Restartujte virtuální počítače prostřednictvím rozhraní Azure, ne ze samotného přihlášení k virtuálnímu počítači. Používání rozhraní Azure funguje lépe a je předvídatelnější.
Pokud chcete virtuální počítač vypnout, abyste ušetřili náklady, použijte rozhraní Azure. Pokud vypnete přihlášení k virtuálnímu počítači, poplatky se budou dál účtovat.
Pro virtuální počítače použijte zásady vytváření názvů.
Věnujte pozornost umístění datacentra, ve kterém se virtuální počítače nasazují.
Funkce automatického škálování v Azure se nepodporuje pro role SharePointu.
Nekonfigurujte položky ve farmě, které se budou obnovovat, například kolekce webů.
Fáze 5: Nastavení DFSR mezi farmami
Pokud chcete nastavit replikaci souborů pomocí dfsr, použijte modul snap-in Správa DNS. Před nastavením dfsr se ale přihlaste k místnímu souborovém serveru a souborovém serveru Azure a povolte službu ve Windows.
Na řídicím panelu Správce serveru proveďte následující kroky:
Nakonfigurujte místní server.
Spusťte Průvodce přidáním rolí a funkcí.
Otevřete uzel Souborová služba a služba úložiště .
Vyberte Obory názvů DFS a Replikace DFS.
Kliknutím na Další dokončete kroky průvodce.
Následující tabulka obsahuje odkazy na články s referenčními informacemi o dfsr a blogových příspěvcích.
Tabulka: Referenční články pro DFSR
| Title | Popis |
|---|---|
| Replikace | Téma Na webu TechNet o správě DFS s odkazy pro replikaci |
| Replikace DFS: Průvodce přežitím | Wikiweb s odkazy na informace DFS |
| Replikace DFS: Nejčastější dotazy | Téma na webu TechNet Replikace DFS |
| Blog uživatele Jose Barreto | Blog napsaný hlavním programovým manažerem v týmu souborového serveru v Microsoftu |
| The Storage Team at Microsoft – File Cabinet Blog | Blog o souborových službách a funkcích úložiště ve Windows Serveru |
Fáze 6: Nastavení odesílání protokolů do farmy obnovení
Přesouvání protokolů je důležitou součástí pro nastavení zotavení po havárii v tomto prostředí. Odesílání protokolů můžete použít k automatickému odesílání souborů transakčního protokolu pro databáze z instance primárního databázového serveru do instance sekundárního databázového serveru. Informace o nastavení přesouvání protokolů najdete v tématu Konfigurace přesouvání protokolů v SharePointu 2013.
Důležité
Podpora přesouvání protokolů na SharePoint Serveru je omezená na určité databáze. Další informace najdete v tématu Podporovaná vysoká dostupnost a možnosti zotavení po havárii pro sharepointové databáze (SharePoint 2013).
Fáze 7: Ověření převzetí služeb při selhání a obnovení
Cílem této poslední fáze je ověřit, že řešení zotavení po havárii funguje podle plánu. Uděláte to tak, že vytvoříte událost převzetí služeb při selhání, která vypne produkční farmu a spustí farmu obnovení jako náhradu. Scénář převzetí služeb při selhání můžete spustit ručně nebo pomocí skriptů.
Prvním krokem je zastavit příchozí požadavky uživatelů na služby nebo obsah farmy. Můžete to provést zakázáním položek DNS nebo vypnutím front-endových webových serverů. Jakmile je farma mimo provoz, můžete převzetí služeb při selhání převzít do farmy obnovení.
Zastavit odesílání protokolů
Před obnovením farmy je nutné zastavit odesílání protokolů. Nejprve zastavte doručování protokolů na sekundárním serveru v Azure a pak ho zastavte na místním primárním serveru. Pomocí následujícího skriptu nejprve zastavte doručování protokolů na sekundární server a pak na primární server. Názvy databází ve skriptu se můžou lišit v závislosti na vašem prostředí.
-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.
SET NOCOUNT ON
DECLARE @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)
Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''
Set @SecDB = @PriDB
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Exec ( 'Select ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database + ''''''''
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec ON prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')
Obnovení záloh
Zálohy se musí obnovit v pořadí, ve kterém byly vytvořeny. Než budete moct obnovit konkrétní zálohu transakčního protokolu, musíte nejprve obnovit následující předchozí zálohy bez vrácení nepotvrzených transakcí (to znamená pomocí WITH NORECOVERYpříkazu ):
Úplná záloha databáze a poslední rozdílová záloha – Obnovte tyto zálohy, pokud existují, pořízené před zálohováním konkrétního transakčního protokolu. Před vytvořením poslední úplné nebo rozdílové zálohy databáze používala databáze model úplného obnovení nebo model hromadného obnovení.
Všechny zálohy transakčních protokolů – Obnovte všechny zálohy transakčních protokolů pořízené po úplné nebo rozdílové záloze (pokud ji obnovíte) a před zálohováním konkrétního transakčního protokolu. Zálohy protokolů se musí použít v pořadí, ve kterém byly vytvořeny, bez jakýchkoli mezer v řetězu protokolů.
Pokud chcete obnovit databázi obsahu na sekundárním serveru tak, aby se lokality vykreslily, odeberte před obnovením všechna připojení k databázi. Pokud chcete databázi obnovit, spusťte následující příkaz SQL.
restore database WSS_Content with recovery
Důležité
Pokud používáte T-SQL explicitně, zadejte v každém příkazu RESTORE buď WITH NORECOVERY , nebo WITH RECOVERY , abyste eliminovali nejednoznačnost – to je velmi důležité při psaní skriptů. Po obnovení úplné a rozdílové zálohy je možné transakční protokoly obnovit v SQL Server Management Studio. Vzhledem k tomu, že přesouvání protokolu je už zastavené, je databáze obsahu v pohotovostním režimu, takže musíte změnit stav na úplný přístup.
V SQL Server Management Studio klikněte pravým tlačítkem na databázi WSS_Content,přejděte na Obnovení úloh> a potom klikněte na Transakční protokol (pokud jste neobnovili úplné zálohování, není k dispozici). Další informace najdete v tématuObnovení zálohy transakčních protokolů (SQL Server).
Procházení zdroje obsahu
Pokud chcete vyhledávací službu obnovit, musíte spustit úplné procházení pro každý zdroj obsahu. Všimněte si, že přijdete o některé analytické informace z místní farmy, jako jsou doporučení vyhledávání. Než začnete s úplným procházením, použijte rutinu Windows PowerShell Restore-SPEnterpriseSearchServiceApplication a zadejte databázi správy vyhledávání dodávaná protokolem a replikovanou Search_Service__DB_<GUID>. Tato rutina poskytuje konfiguraci vyhledávání, schéma, spravované vlastnosti, pravidla a zdroje a vytvoří výchozí sadu ostatních součástí.
Pokud chcete spustit úplné procházení, proveďte následující kroky:
V Centrální správě SharePointu 2013 přejděte naAplikace> služby Správa>aplikací služby a klikněte na aplikaci Vyhledávací služby, kterou chcete procházet.
Na stránce Správa vyhledávání klikněte na Zdroje obsahu, přejděte na požadovaný zdroj obsahu, klikněte na šipku a potom klikněte na Spustit úplné procházení.
Obnovení služeb farmy
Následující tabulka ukazuje, jak obnovit služby, které mají databáze dodané protokolem, služby, které mají databáze, ale nedoporučuje se obnovení s využitím přesouvání protokolů, a služby, které nemají databáze.
Důležité
Obnovením místní databáze SharePointu do prostředí Azure se neobnoví žádné služby SharePoint, které jste v Azure ještě nenainstalovali ručně.
Tabulka: Referenční informace k databázi aplikací služby
| Obnovení těchto služeb z databází dodaných protokolem | Tyto služby mají databáze, ale doporučujeme tyto služby spustit bez obnovení jejich databází. | Tyto služby neukládají data v databázích; spuštění těchto služeb po převzetí služeb při selhání |
|---|---|---|
| Služba strojového překladu Služba spravovaných metadat Zabezpečené úložiště přihlašovacích údajů Profil uživatele. (Podporují se pouze databáze Profil a Sociální značky. Synchronizační databáze není podporována.) Služba nastavení předplatného služby Microsoft SharePoint Foundation |
Shromažďování dat o využití a stavu Stavová služba Automatizace wordu |
Excel Services Služby PerformancePoint Převod PowerPointu Grafická služba Visia Řízení práce |
Následující příklad ukazuje, jak obnovit službu spravovaných metadat z databáze.
Používá se existující databáze Managed_Metadata_DB. Tato databáze je dodávána protokolem, ale v sekundární farmě není žádná aktivní aplikace služby, takže je potřeba ji po nasazení aplikace služby připojit.
Nejprve použijte New-SPMetadataServiceApplicationa zadejte DatabaseName přepínač s názvem obnovené databáze.
Dále nakonfigurujte novou aplikaci spravované služby metadat na sekundárním serveru následujícím způsobem:
Název: Spravovaná služba metadat
Databázový server: Název databáze z dodaného transakčního protokolu
Název databáze: Managed_Metadata_DB
Fond aplikací: Aplikace služby SharePoint
Správa záznamů DNS
Musíte ručně vytvořit záznamy DNS, které budou odkazovat na farmu služby SharePoint.
Ve většině případů, kdy máte více front-endových webových serverů, je vhodné využít funkci Vyrovnávání zatížení sítě v Windows Server 2012 nebo nástroj pro vyrovnávání zatížení hardwaru k distribuci požadavků mezi webové front-end servery ve vaší farmě. Vyrovnávání zatížení sítě může také pomoct snížit riziko tím, že žádosti distribuuje na ostatní servery, pokud některý z vašich webových front-end serverů selže.
Při nastavování vyrovnávání zatížení sítě se obvykle clusteru přiřadí jedna IP adresa. Potom ve zprostředkovatele DNS pro vaši síť vytvoříte záznam hostitele DNS, který odkazuje na cluster. (Pro tento projekt jsme do Azure umístili server DNS pro zajištění odolnosti v případě selhání místního datacentra.) Ve Správci DNS ve službě Active Directory můžete například vytvořit záznam DNS s názvem https://sharepoint.contoso.com, který odkazuje na IP adresu vašeho clusteru s vyrovnáváním zatížení.
Pro externí přístup k farmě služby SharePoint můžete na externím serveru DNS vytvořit záznam hostitele se stejnou adresou URL, https://sharepoint.contoso.comkterou používají klienti v intranetu (například ), která odkazuje na externí IP adresu ve vaší bráně firewall. (Osvědčeným postupem v tomto příkladu je nastavit rozdělený DNS tak, aby interní server DNS byl autoritativní pro contoso.com a směruje požadavky přímo do clusteru farmy SharePointu, a ne směrovat požadavky DNS na externí server DNS.) Pak můžete namapovat externí IP adresu na interní IP adresu místního clusteru, aby klienti našli prostředky, které hledají.
Tady můžete narazit na několik různých scénářů zotavení po havárii:
Ukázkový scénář: Místní farma SharePointu není dostupná kvůli selhání hardwaru v místní farmě SharePointu. V takovém případě můžete po dokončení kroků pro převzetí služeb při selhání do farmy Služby Azure SharePoint nakonfigurovat vyrovnávání zatížení sítě na webových front-endových serverech farmy SharePointu pro obnovení stejným způsobem jako u místní farmy. Potom můžete přesměrovat záznam hostitele ve vašem interním poskytovateli DNS tak, aby ukazoval na IP adresu clusteru farmy pro obnovení. Upozorňujeme, že může nějakou dobu trvat, než se záznamy DNS uložené v mezipaměti na klientech aktualizují a nasměrují na farmu pro obnovení.
Ukázkový scénář: Místní datové centrum se zcela ztratí. K tomuto scénáři může dojít kvůli přírodní katastrofě, jako je požár nebo záplava. V takovém případě byste pro podnik pravděpodobně měli sekundární datové centrum hostované v jiné oblasti a také podsíť Azure, která má vlastní adresářové služby a DNS. Stejně jako v předchozím scénáři havárie můžete interní a externí záznamy DNS přesměrovat na farmu Služby Azure SharePoint. Opět si všimněte, že šíření záznamů DNS může nějakou dobu trvat.
Pokud používáte kolekce webů s názvem hostitele, jak se doporučuje v tématu Architektura a nasazení kolekce webů s názvem hostitele (SharePoint 2013), můžete mít několik kolekcí webů hostovaných stejnou webovou aplikací ve farmě služby SharePoint s jedinečnými názvy DNS (například https://sales.contoso.com a https://marketing.contoso.com). V takovém případě můžete vytvořit záznamy DNS pro každou kolekci webů, která odkazuje na IP adresu vašeho clusteru. Jakmile požadavek dosáhne vašich webových front-end serverů SharePointu, zpracují směrování každého požadavku na příslušnou kolekci webů.
Testování konceptu prostředí Microsoftu
Pro toto řešení jsme navrhli a otestovali prostředí pro testování konceptu. Cílem návrhu našeho testovacího prostředí bylo nasadit a obnovit sharepointovou farmu, kterou můžeme najít v prostředí zákazníka. Provedli jsme několik předpokladů, ale věděli jsme, že farma potřebuje zajistit všechny funkce, které jsou součástí balení, bez jakýchkoli přizpůsobení. Topologie byla navržena pro vysokou dostupnost pomocí osvědčených postupů z terénu a produktové skupiny.
Následující tabulka popisuje virtuální počítače Hyper-V, které jsme vytvořili a nakonfigurovali pro místní testovací prostředí.
Tabulka: Virtuální počítače pro místní test
| Název serveru | Role | Konfigurace |
|---|---|---|
| DC1 | Řadič domény se službou Active Directory. | Dva procesory Od 512 MB do 4 GB paměti RAM 1 × 127 GB pevného disku |
| RRAS | Server nakonfigurovaný s rolí Služby směrování a vzdáleného přístupu (RRAS). | Dva procesory 2–8 GB paměti RAM 1 × 127 GB pevného disku |
| FS1 | Souborový server se sdílenými složkami pro zálohování a koncovým bodem pro službu DFSR. | Čtyři procesory 2–12 GB paměti RAM 1 × 127 GB pevného disku 1 × 1TB pevný disk (SAN) 1 × 750 GB pevného disku |
| SP-WFE1, SP-WFE2 | Front-endové webové servery. | Čtyři procesory 16 GB paměti RAM |
| SP-APP1, SP-APP2, SP-APP3 | Aplikační servery. | Čtyři procesory 2–16 GB paměti RAM |
| SP-SQL-HA1, SP-SQL-HA2 | Databázové servery nakonfigurované se skupinami dostupnosti AlwaysOn SQL Server 2012 pro zajištění vysoké dostupnosti. Tato konfigurace používá jako primární a sekundární repliku SP-SQL-HA1 a SP-SQL-HA2. | Čtyři procesory 2–16 GB paměti RAM |
Následující tabulka popisuje konfigurace jednotek pro virtuální počítače Hyper-V, které jsme vytvořili a nakonfigurovali pro front-endové webové a aplikační servery pro místní testovací prostředí.
Tabulka: Požadavky na jednotky virtuálního počítače pro webové a aplikační servery front-endu pro místní test
| Písmeno jednotky | Velikost | Název adresáře | Cesta |
|---|---|---|---|
| C | 80 | Systémová jednotka | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| E | 80 | Jednotka protokolu (40 GB) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| F | 80 | Stránka (36 GB) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA |
Následující tabulka popisuje konfigurace jednotek pro virtuální počítače Hyper-V vytvořené a nakonfigurované tak, aby sloužily jako místní databázové servery. Na stránce Konfigurace databázového stroje přejděte na kartu Datové adresáře a nastavte a potvrďte nastavení uvedená v následující tabulce.
Tabulka: Požadavky na jednotku virtuálního počítače pro databázový server pro místní test
| Písmeno jednotky | Velikost | Název adresáře | Cesta |
|---|---|---|---|
| C | 80 | Kořenový adresář dat | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| E | 500 | Adresář uživatelské databáze | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| F | 500 | Adresář protokolu databáze uživatele | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| G | 500 | Adresář dočasné databáze | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| H | 500 | Adresář protokolů dočasné databáze | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
Nastavení testovacího prostředí
Během různých fází nasazení testovací tým obvykle nejprve pracoval na místní architektuře a pak na odpovídajícím prostředí Azure. To odráží obecné reálné případy, kdy vlastní výrobní farmy již běží. Ještě důležitější je, abyste znali aktuální produkční úlohy, kapacitu a typický výkon. Kromě vytvoření modelu zotavení po havárii, který může splňovat obchodní požadavky, byste měli nastavit velikost serverů farmy obnovení tak, aby poskytovaly minimální úroveň služeb. V chladném nebo teplém pohotovostním prostředí je farma obnovení obvykle menší než produkční farma. Jakmile je farma pro obnovení stabilní a v produkčním prostředí, je možné ji vertikálně navýšit a snížit tak, aby splňovala požadavky úloh.
Testovací prostředí jsme nasadili v následujících třech fázích:
Nastavení hybridní infrastruktury
Zřízení serverů
Nasazení sharepointových farem
Nastavení hybridní infrastruktury
Tato fáze zahrnovala nastavení doménového prostředí pro místní farmu a pro farmu obnovení v Azure. Kromě běžných úloh spojených s konfigurací služby Active Directory implementoval testovací tým řešení směrování a připojení VPN mezi těmito dvěma prostředími.
Zřízení serverů
Kromě serverů farmy bylo nutné zřídit servery pro řadiče domény a nakonfigurovat server pro zpracování RRAS i vpn typu site-to-site. Pro službu DFSR byly zřízeny dva souborové servery a pro testery bylo zřízeno několik klientských počítačů.
Nasazení sharepointových farem
Farmy SharePointu byly nasazeny ve dvou fázích, aby se v případě potřeby zjednodušila stabilizace prostředí a řešení potíží. Během první fáze byla každá farma nasazena na minimální počet serverů pro každou úroveň topologie, aby podporovala požadované funkce.
Vytvořili jsme databázové servery s nainstalovaným SQL Server před vytvořením serverů SharePointu 2013. Protože se jednalo o nové nasazení, vytvořili jsme skupiny dostupnosti před nasazením SharePointu. Na základě osvědčených postupů mcs jsme vytvořili tři skupiny.
Poznámka
Vytvořte zástupné databáze, abyste mohli vytvořit skupiny dostupnosti před instalací SharePointu. Další informace najdete v tématu Konfigurace skupin dostupnosti AlwaysOn SQL Server 2012 pro SharePoint 2013.
Vytvořili jsme farmu a připojili jsme další servery v následujícím pořadí:
Zřiďte SP-SQL-HA1 a SP-SQL-HA2.
Nakonfigurujte AlwaysOn a vytvořte tři skupiny dostupnosti pro farmu.
Zřiďte SP-APP1 pro hostování Centrální správy.
Zřiďte sp-WFE1 a SP-WFE2 pro hostování distribuované mezipaměti.
Při spuštění psconfig.exe na příkazovém řádku jsme použili parametr skipRegisterAsDistributedCachehost. Další informace najdete v tématu Plánování informačních kanálů a služby Distribuované mezipaměti na SharePoint Serveru 2013.
V prostředí pro obnovení jsme opakovali následující kroky:
Zřiďte AZ-SQL-HA1 a AZ-SQL-HA2.
Nakonfigurujte AlwaysOn a vytvořte tři skupiny dostupnosti pro farmu.
Zřiďte AZ-APP1 pro hostování Centrální správy.
Pro hostování distribuované mezipaměti zřiďte az-WFE1 a AZ-WFE2.
Po nakonfigurování distribuované mezipaměti a přidání testovacích uživatelů a testovacího obsahu jsme zahájili druhou fázi nasazení. To vyžadovalo horizontální navýšení kapacity vrstev a konfiguraci serverů farmy tak, aby podporovaly topologii s vysokou dostupností popsanou v architektuře farmy.
Následující tabulka popisuje virtuální počítače, podsítě a skupiny dostupnosti, které jsme pro naši farmu obnovení nastavili.
Tabulka: Infrastruktura farmy obnovení
| Název serveru | Role | Konfigurace | Podsítě | Skupina dostupnosti |
|---|---|---|---|---|
| spDRAD | Řadič domény se službou Active Directory | Dva procesory Od 512 MB do 4 GB paměti RAM 1 × 127 GB pevného disku |
sp-ADservery | |
| AZ-SP-FS | Souborový server se sdílenými složkami pro zálohování a koncovým bodem pro DFSR | Konfigurace A5: Dva procesory 14 GB paměti RAM 1 × 127 GB pevného disku 1 × 135 GB pevného disku 1 × 127 GB pevného disku 1 × 150 GB pevného disku |
sp-databaseservers | DATA_SET |
| AZ-WFE1, AZ -WFE2 | Webové servery front-endu | Konfigurace A5: Dva procesory 14 GB paměti RAM 1 × 127 GB pevného disku |
sp-webservers | WFE_SET |
| AZ -APP1, AZ -APP2, AZ -APP3 | Aplikační servery | Konfigurace A5: Dva procesory 14 GB paměti RAM 1 × 127 GB pevného disku |
sp-applicationservers | APP_SET |
| AZ -SQL-HA1, AZ -SQL-HA2 | Databázové servery a primární a sekundární repliky pro skupiny dostupnosti AlwaysOn | Konfigurace A5: Dva procesory 14 GB paměti RAM |
sp-databaseservers | DATA_SET |
Operations
Jakmile testovací tým stabilizoval prostředí farmy a dokončil funkční testování, spustil následující úlohy operací potřebné ke konfiguraci místního prostředí obnovení:
Konfigurace úplného a rozdílového zálohování
Nakonfigurujte službu DFSR na souborových serverech, které přenášejí transakční protokoly mezi místním prostředím a prostředím Azure.
Nakonfigurujte odesílání protokolů na primárním databázovém serveru.
Podle potřeby stabilizujte, ověřte a odstraňte potíže s přesouváním protokolů. To zahrnovalo identifikaci a dokumentaci veškerého chování, které může způsobovat problémy, jako je latence sítě, která by způsobovala přesouvání protokolů nebo selhání synchronizace souborů DFSR.
Databáze
Naše testy převzetí služeb při selhání zahrnovaly následující databáze:
WSS_Content
ManagedMetadata
Profilová databáze
Synchronizace databáze
Databáze na sociálních sítích
Centrum typů obsahu (databáze vyhrazeného centra syndikací typů obsahu)
Tipy pro řešení potíží
Tato část vysvětluje problémy, se kterými jsme se setkali během testování, a jejich řešení.
Použití nástroje pro správu úložiště termínů způsobilo chybu "Spravované úložiště metadat nebo připojení není momentálně k dispozici".
Ujistěte se, že účet fondu aplikací používaný webovou aplikací má oprávnění Ke čtení do úložiště termínů.
Vlastní sady termínů nejsou v kolekci webů dostupné.
Zkontrolujte, jestli mezi kolekcí webů obsahu a centrem typu obsahu chybí přidružení aplikace služby. Kromě toho se na obrazovce Spravovaná metadata – <název> kolekce webů Vlastnosti připojení ujistěte, že je povolená tato možnost: Tato aplikace služby je výchozím umístěním úložiště pro sady termínů specifické pro sloupec.
Příkaz Get-ADForest Windows PowerShell vygeneruje chybu Výraz Get-ADForest není rozpoznán jako název rutiny, funkce, souboru skriptu nebo funkčního programu.
Při nastavování profilů uživatelů potřebujete název doménové struktury služby Active Directory. V Průvodci přidáním rolí a funkcí se ujistěte, že jste povolili modul služby Active Directory pro Windows PowerShell (v části Nástroje>pro vzdálenou správu serveru Nástroje>pro správu rolí služby AD DS a NÁSTROJE SLUŽBY AD LDS). Kromě toho před použitím rutiny Get-ADForest spusťte následující příkazy, které vám pomůžou zajistit načtení závislostí softwaru.
Import-Module ServerManager
Import-Module ActiveDirectory
Při spuštění relace AlwaysOn_health XEvent na< serveru se> nedaří vytvořit skupinu dostupnosti.
Ujistěte se, že oba uzly vašeho clusteru s podporou převzetí služeb při selhání jsou ve stavu "Up" a ne "Pozastaveno" nebo "Zastaveno".
SQL Server úloha odeslání protokolu selže s chybou odepření přístupu při pokusu o připojení ke sdílené složce
Ujistěte se, že váš agent SQL Server běží pod síťovými přihlašovacími údaji místo výchozích přihlašovacích údajů.
SQL Server úloha odeslání protokolu značí úspěch, ale nezkopírují se žádné soubory.
K tomu dochází, protože výchozí předvolba zálohování pro skupinu dostupnosti je Preferovat sekundární. Ujistěte se, že jste spustili úlohu odeslání protokolu ze sekundárního serveru pro skupinu dostupnosti místo primárního serveru. jinak úloha selže bezobslužně.
Služba spravovaných metadat (nebo jiná služba SharePointu) se po instalaci automaticky nespustí
V závislosti na výkonu a aktuálním zatížení sharepointového serveru může spuštění služeb trvat několik minut. Ručně klikněte na Spustit pro službu a poskytněte dostatek času na spuštění při občasné aktualizaci obrazovky Služby na serveru, abyste mohli sledovat její stav. V případě, že služba zůstane zastavená, povolte protokolování diagnostiky SharePointu, zkuste službu spustit znovu a pak v protokolu zkontrolujte chyby. Další informace najdete v tématu Konfigurace protokolování diagnostiky v SharePointu 2013.
Po změně DNS na prostředí Azure s podporou převzetí služeb při selhání budou klientské prohlížeče dál používat starou IP adresu pro sharepointový web.
Vaše změna DNS nemusí být okamžitě viditelná pro všechny klienty. Na testovacím klientovi proveďte následující příkaz z příkazového řádku se zvýšenými oprávněními a pokuste se znovu o přístup k lokalitě.
Ipconfig /flushdns
Další zdroje informací
Podporovaná vysoká dostupnost a možnosti zotavení po havárii pro sharepointové databáze
Konfigurace skupin dostupnosti AlwaysOn SQL Server 2012 pro SharePoint 2013
Viz taky
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro