SharePoint Server 2013 katastrofåterställning i Microsoft Azure
Med Azure kan du skapa en haveriberedskapsmiljö för din lokala SharePoint-servergrupp. Den här artikeln beskriver hur du utformar och implementerar den här lösningen.
Titta på översiktsvideon för haveriberedskap för SharePoint Server 2013
När en katastrof drabbar din lokala SharePoint-miljö är din högsta prioritet att snabbt få igång systemet igen. Haveriberedskap med SharePoint blir snabbare och enklare när du har en säkerhetskopieringsmiljö som redan körs i Microsoft Azure. Den här videon beskriver huvudbegreppen för en varm SharePoint-redundansmiljö och kompletterar den fullständiga information som finns i den här artikeln.
Använd den här artikeln med följande lösningsmodell: SharePoint Disaster Recovery i Microsoft Azure.
Använda Azure Infrastructure Services för haveriberedskap
Många organisationer har ingen haveriberedskapsmiljö för SharePoint, vilket kan vara dyrt att bygga och underhålla lokalt. Azure Infrastructure Services erbjuder övertygande alternativ för haveriberedskapsmiljöer som är mer flexibla och billigare än de lokala alternativen.
Fördelarna med att använda Azure Infrastructure Services är:
Färre kostsamma resurser Underhålla och betala för färre resurser än lokala haveriberedskapsmiljöer. Antalet resurser beror på vilken haveriberedskapsmiljö du väljer: kallt vänteläge, varmt vänteläge eller hett vänteläge.
Bättre flexibilitet för resurser I händelse av en katastrof skalar du enkelt ut din SharePoint-servergrupp för återställning för att uppfylla belastningskraven. Skala in när du inte längre behöver resurserna.
Lägre åtagande för datacenter Använd Azure Infrastructure Services i stället för att investera i ett sekundärt datacenter i en annan region.
Det finns mindre komplexa alternativ för organisationer som precis har kommit igång med haveriberedskap och avancerade alternativ för organisationer med höga motståndskraftskrav. Definitionerna för kalla, varma och varma väntelägesmiljöer skiljer sig lite åt när miljön finns på en molnplattform. I följande tabell beskrivs dessa miljöer för att skapa en SharePoint-återställningsservergrupp i Azure.
Tabell: Återställningsmiljöer
| Typ av återställningsmiljö | Beskrivning |
|---|---|
| Hot | En fullständigt storleksanpassad servergrupp etableras, uppdateras och körs i vänteläge. |
| Varma | Servergruppen skapas och virtuella datorer körs och uppdateras. Återställning omfattar att koppla innehållsdatabaser, etablera tjänstprogram och crawla innehåll. Servergruppen kan vara en mindre version av produktionsgruppen och sedan skalas ut för att betjäna den fullständiga användarbasen. |
| Kallt | Servergruppen är helt byggd, men de virtuella datorerna stoppas. Underhåll av miljön omfattar att starta de virtuella datorerna då och då, korrigera, uppdatera och verifiera miljön. Starta den fullständiga miljön i händelse av en katastrof. |
Det är viktigt att utvärdera organisationens mål för återställningstid (RTOs) och mål för återställningspunkter (RPO). Dessa krav avgör vilken miljö som är den lämpligaste investeringen för din organisation.
Vägledningen i den här artikeln beskriver hur du implementerar en varm standby-miljö. Du kan också anpassa den till en kall väntelägesmiljö, även om du behöver följa ytterligare procedurer för att stödja den här typen av miljö. Den här artikeln beskriver inte hur du implementerar en hot standby-miljö.
Mer information om haveriberedskapslösningar finns i Begrepp för hög tillgänglighet och haveriberedskap i SharePoint 2013 och Välj en strategi för haveriberedskap för SharePoint 2013.
Lösningsbeskrivning
Lösningen för haveriberedskap i varmt vänteläge kräver följande miljö:
En lokal SharePoint-produktionsgrupp
En SharePoint-servergrupp för återställning i Azure
En PLATS-till-plats-VPN-anslutning mellan de två miljöerna
Följande bild illustrerar dessa tre element.
Bild: Element i en lösning för varmt vänteläge i Azure
SQL Server loggöverföring med DFSR (Distributed File System Replication) används för att kopiera databassäkerhetskopior och transaktionsloggar till återställningsgruppen i Azure:
DFSR överför loggar från produktionsmiljön till återställningsmiljön. I ett WAN-scenario är DFSR effektivare än att skicka loggarna direkt till den sekundära servern i Azure.
Loggarna spelas upp på nytt till SQL Server i återställningsmiljön i Azure.
Du bifogar inte logglevererade SharePoint-innehållsdatabaser i återställningsmiljön förrän en återställningsövning har utförts.
Utför följande steg för att återställa servergruppen:
Stoppa loggöverföringen.
Sluta acceptera trafik till den primära servergruppen.
Spela upp de slutliga transaktionsloggarna igen.
Koppla innehållsdatabaserna till servergruppen.
Återställa tjänstprogram från databaserna för replikerade tjänster.
Uppdatera DNS-poster (Domain Name System) så att de pekar på återställningsservergruppen.
Starta en fullständig crawlning.
Vi rekommenderar att du repeterar dessa steg regelbundet och dokumenterar dem för att säkerställa att din liveåterställning körs smidigt. Det kan ta lite tid att ansluta innehållsdatabaser och återställa tjänstprogram, vilket vanligtvis innebär manuell konfiguration.
När en återställning har utförts tillhandahåller den här lösningen de objekt som anges i följande tabell.
Tabell: Mål för lösningsåterställning
| Objekt | Beskrivning |
|---|---|
| Webbplatser och innehåll | Webbplatser och innehåll är tillgängliga i återställningsmiljön. |
| En ny sökinstans | I den här varma väntelägeslösningen återställs inte sökningen från sökdatabaser. Sökkomponenterna i återställningsservergruppen konfigureras på samma sätt som möjligt för produktionsgruppen. När webbplatserna och innehållet har återställts startas en fullständig crawlning för att återskapa sökindexet. Du behöver inte vänta tills crawlningen har slutförts för att göra webbplatserna och innehållet tillgängligt. |
| Tjänster | Tjänster som lagrar data i databaser återställs från de logglevererade databaserna. Tjänster som inte lagrar data i databaser startas helt enkelt. Alla tjänster med databaser behöver inte återställas. Följande tjänster behöver inte återställas från databaser och kan helt enkelt startas efter redundansväxling: Insamling av användnings- och hälsodata Tillståndstjänst Word-automatisering Andra tjänster som inte använder en databas |
Du kan arbeta med Microsoft Consulting Services (MCS) eller en partner för att hantera mer komplexa återställningsmål. Dessa sammanfattas i följande tabell.
Tabell: Andra objekt som kan hanteras av MCS eller en partner
| Objekt | Beskrivning |
|---|---|
| Synkronisera anpassade servergruppslösningar | Helst är konfigurationen av återställningsservergruppen identisk med produktionsgruppen. Du kan arbeta med en konsult eller partner för att utvärdera om anpassade servergruppslösningar replikeras och om processen är på plats för att hålla de två miljöerna synkroniserade. |
| Anslutningar till lokala datakällor | Det kanske inte är praktiskt att replikera anslutningar till serverdelsdatasystem, till exempel BDC-anslutningar (backup domain controller) och sökinnehållskällor. |
| Sökåterställningsscenarier | Eftersom företagssökningsdistributioner tenderar att vara ganska unika och komplexa kräver återställning av sökning från databaser en större investering. Du kan arbeta med en konsult eller partner för att identifiera och implementera sökåterställningsscenarier som din organisation kan kräva. |
Vägledningen i den här artikeln förutsätter att den lokala servergruppen redan har utformats och distribuerats.
Detaljerad arkitektur
Vi rekommenderar att konfigurationen av återställningsservergruppen i Azure är identisk med den lokala produktionsgruppen, inklusive följande:
Samma representation av serverroller
Samma konfiguration av anpassningar
Samma konfiguration av sökkomponenter
Miljön i Azure kan vara en mindre version av produktionsgruppen. Om du planerar att skala ut återställningsservergruppen efter redundansväxlingen är det viktigt att varje typ av serverroll först representeras.
Vissa konfigurationer kanske inte är praktiska att replikera i redundansmiljön. Se till att testa redundansprocedurerna och miljön för att säkerställa att redundansgruppen tillhandahåller den förväntade servicenivån.
Den här lösningen föreskriver inte en specifik topologi för en SharePoint-servergrupp. Fokus för den här lösningen är att använda Azure för redundansklustergruppen och implementera loggöverföring och DFSR mellan de två miljöerna.
Varma väntelägesmiljöer
I en varm väntelägesmiljö körs alla virtuella datorer i Azure-miljön. Miljön är redo för en redundansövning eller händelse.
Följande bild illustrerar en haveriberedskapslösning från en lokal SharePoint-servergrupp till en Azure-baserad SharePoint-servergrupp som är konfigurerad som en varm väntelägesmiljö.
Bild: Topologi och viktiga element i en produktionsgrupp och en varm återställningsservergrupp i vänteläge
I det här diagrammet:
Två miljöer illustreras sida vid sida: den lokala SharePoint-servergruppen och den varma vänteservergruppen i Azure.
Varje miljö innehåller en filresurs.
Varje servergrupp innehåller fyra nivåer. För att uppnå hög tillgänglighet omfattar varje nivå två servrar eller virtuella datorer som har konfigurerats identiskt för en specifik roll, till exempel klientdelstjänster, distribuerad cache, serverdelstjänster och databaser. Det är inte viktigt i den här bilden att framhäva specifika komponenter. De två servergrupperna konfigureras på samma sätt.
Den fjärde nivån är databasnivån. Loggöverföring används för att kopiera loggar från den sekundära databasservern i den lokala miljön till filresursen i samma miljö.
DFSR kopierar filer från filresursen i den lokala miljön till filresursen i Azure-miljön.
Loggöverföringen spelar upp loggarna från filresursen i Azure-miljön till den primära repliken i tillgänglighetsgruppen SQL Server AlwaysOn i återställningsmiljön.
Miljöer med kallt vänteläge
I en kall väntelägesmiljö kan de flesta virtuella Datorer i SharePoint-servergruppen stängas av. (Vi rekommenderar att du ibland startar de virtuella datorerna, till exempel varannan vecka eller en gång i månaden, så att varje virtuell dator kan synkronisera med domänen.) Följande virtuella datorer i Azure-återställningsmiljön måste fortsätta att köras för att säkerställa kontinuerliga åtgärder för loggöverföring och DFSR:
Filresursen
Den primära databasservern
Minst en virtuell dator som kör Windows Server Active Directory Domain Services och DNS
Följande bild visar en Azure-redundansmiljö där den virtuella filresursdatorn och den primära virtuella SharePoint-databasen körs. Alla andra virtuella SharePoint-datorer stoppas. Den virtuella dator som kör Windows Server Active Directory och DNS visas inte.
Bild: Återställningsservergrupp i kallt vänteläge med virtuella datorer som körs
Efter redundansväxling till en kall väntelägesmiljö startas alla virtuella datorer och metoden för att uppnå hög tillgänglighet för databasservrarna måste konfigureras, till exempel SQL Server AlwaysOn-tillgänglighetsgrupper.
Om flera lagringsgrupper implementeras (databaser är spridda över fler än en SQL Server uppsättning med hög tillgänglighet) måste den primära databasen för varje lagringsgrupp köras för att acceptera loggarna som är associerade med dess lagringsgrupp.
Färdigheter och erfarenhet
Flera tekniker används i den här haveriberedskapslösningen. För att säkerställa att dessa tekniker interagerar som förväntat måste varje komponent i den lokala miljön och Azure-miljön installeras och konfigureras korrekt. Vi rekommenderar att den person eller det team som konfigurerar den här lösningen har starka kunskaper om och praktiska kunskaper om de tekniker som beskrivs i följande artiklar:
Slutligen rekommenderar vi skriptfärdigheter som du kan använda för att automatisera uppgifter som är associerade med dessa tekniker. Du kan använda de tillgängliga användargränssnitten för att utföra alla uppgifter som beskrivs i den här lösningen. En manuell metod kan dock vara tidskrävande och felbenägen och ger inkonsekventa resultat.
Förutom Windows PowerShell finns det även Windows PowerShell bibliotek för SQL Server, SharePoint Server och Azure. Glöm inte T-SQL, vilket också kan bidra till att minska tiden för att konfigurera och underhålla din haveriberedskapsmiljö.
Översikt över haveriberedskap
Den här översikten förutsätter att du redan har en SharePoint Server 2013-servergrupp distribuerad i produktion.
Tabell: Översikt över haveriberedskap
| Fas | Beskrivning |
|---|---|
| Fas 1 | Utforma haveriberedskapsmiljön. |
| Fas 2 | Skapa det virtuella Azure-nätverket och VPN-anslutningen. |
| Fas 3 | Distribuera Windows Active Directory och Domain Name Services till det virtuella Azure-nätverket. |
| Fas 4 | Distribuera SharePoint-återställningsgruppen i Azure. |
| Fas 5 | Konfigurera DFSR mellan servergrupperna. |
| Fas 6 | Konfigurera loggöverföring till återställningsservergruppen. |
| Fas 7 | Verifiera lösningar för redundans och återställning. Detta omfattar följande procedurer och tekniker: Stoppa loggöverföringen. Återställ säkerhetskopiorna. Crawlningsinnehåll. Återställa tjänster. Hantera DNS-poster. |
Fas 1: Utforma haveriberedskapsmiljön
Använd vägledningen i Microsoft Azure Architectures för SharePoint 2013 för att utforma haveriberedskapsmiljön, inklusive SharePoint-återställningsservergruppen. Du kan använda grafiken i SharePoint-haveriberedskapslösningen i Azure Visio-filen för att starta designprocessen. Vi rekommenderar att du utformar hela miljön innan du påbörjar något arbete i Azure-miljön.
Förutom vägledningen i Microsoft Azure Architectures för SharePoint 2013 för att utforma det virtuella nätverket, VPN-anslutningen, Active Directory och SharePoint-servergruppen måste du lägga till en filresursroll i Azure-miljön.
För att stödja loggöverföring i en haveriberedskapslösning läggs en virtuell filresursdator till i undernätet där databasrollerna finns. Filresursen fungerar också som den tredje noden i en nodmajoritet för tillgänglighetsgruppen SQL Server AlwaysOn. Det här är den rekommenderade konfigurationen för en SharePoint-standardgrupp som använder SQL Server AlwaysOn-tillgänglighetsgrupper.
Obs!
Det är viktigt att granska förutsättningarna för att en databas ska kunna delta i en SQL Server AlwaysOn-tillgänglighetsgrupp. Mer information finns i Krav, begränsningar och rekommendationer för AlwaysOn-tillgänglighetsgrupper.
Bild: Placering av en filserver som används för en haveriberedskapslösning
I det här diagrammet läggs en virtuell filresursdator till i samma undernät i Azure som innehåller databasserverrollerna. Lägg inte till den virtuella filresursdatorn i en tillgänglighetsuppsättning med andra serverroller, till exempel SQL Server roller.
Om du är orolig för den höga tillgängligheten för loggarna bör du överväga att använda en annan metod med hjälp av SQL Server säkerhetskopiering och återställning med Azure Blob Storage Service. Det här är en ny funktion i Azure som sparar loggar direkt till en bloblagrings-URL. Den här lösningen innehåller inte vägledning om hur du använder den här funktionen.
När du utformar återställningsservergruppen bör du tänka på att en lyckad haveriberedskapsmiljö korrekt återspeglar den produktionsgrupp som du vill återställa. Storleken på återställningsservergruppen är inte det viktigaste i återställningsservergruppens design, distribution och testning. Servergruppsskalan varierar från organisation till organisation baserat på affärskrav. Det kan vara möjligt att använda en nedskalad servergrupp för ett kort avbrott eller tills prestanda- och kapacitetskrav kräver att du skalar servergruppen.
Konfigurera återställningsservergruppen så identiskt som möjligt till produktionsgruppen så att den uppfyller kraven på serviceavtal (SLA) och tillhandahåller de funktioner som du behöver för att stödja din verksamhet. När du utformar haveriberedskapsmiljön bör du även titta på ändringshanteringsprocessen för produktionsmiljön. Vi rekommenderar att du utökar ändringshanteringsprocessen till återställningsmiljön genom att uppdatera återställningsmiljön med samma intervall som produktionsmiljön. Som en del av ändringshanteringsprocessen rekommenderar vi att du upprätthåller en detaljerad inventering av servergruppens konfiguration, program och användare.
Fas 2: Skapa det virtuella Azure-nätverket och VPN-anslutningen
Anslut ett lokalt nätverk till ett virtuellt Microsoft Azure-nätverk som visar hur du planerar och distribuerar det virtuella nätverket i Azure och hur du skapar VPN-anslutningen. Följ anvisningarna i avsnittet för att slutföra följande procedurer:
Planera det privata IP-adressutrymmet för Virtual Network.
Planera ändringar i routningsinfrastrukturen för Virtual Network.
Planera brandväggsregler för trafik till och från den lokala VPN-enheten.
Skapa det virtuella nätverket mellan platser i Azure.
Konfigurera routning mellan ditt lokala nätverk och Virtual Network.
Fas 3: Distribuera Active Directory och Domain Name Services till det virtuella Azure-nätverket
Den här fasen omfattar distribution av både Windows Server Active Directory och DNS till Virtual Network i ett hybridscenario enligt beskrivningen i Microsoft Azure Architectures for SharePoint 2013 och som visas i följande bild.
Bild: Hybrid Active Directory-domänkonfiguration
I bilden distribueras två virtuella datorer till samma undernät. De här virtuella datorerna är båda värdar för två roller: Active Directory och DNS.
Innan du distribuerar Active Directory i Azure läser du Riktlinjer för att distribuera Windows Server Active Directory på Azure Virtual Machines. De här riktlinjerna hjälper dig att avgöra om du behöver en annan arkitektur eller olika konfigurationsinställningar för din lösning.
Detaljerad information om hur du konfigurerar en domänkontrollant i Azure finns i Installera en replik Active Directory-domän Controller i virtuella Azure-nätverk.
Innan den här fasen distribuerade du inte virtuella datorer till Virtual Network. De virtuella datorerna som är värdar för Active Directory och DNS är förmodligen inte de största virtuella datorerna som du behöver för lösningen. Innan du distribuerar de här virtuella datorerna skapar du först den största virtuella datorn som du planerar att använda i din Virtual Network. Detta säkerställer att din lösning hamnar på en tagg i Azure som tillåter den största storlek du behöver. Du behöver inte konfigurera den här virtuella datorn just nu. Skapa den bara och lägg den åt sidan. Om du inte gör det kan du stöta på en begränsning när du försöker skapa större virtuella datorer senare, vilket var ett problem när den här artikeln skrevs.
Fas 4: Distribuera SharePoint-återställningsservergruppen i Azure
Distribuera SharePoint-servergruppen i din Virtual Network enligt dina designplaner. Det kan vara bra att granska Planering för SharePoint 2013 i Azure Infrastructure Services innan du distribuerar SharePoint-roller i Azure.
Tänk på följande metoder som vi har lärt oss genom att skapa vår konceptbevismiljö:
Skapa virtuella datorer med hjälp av Azure Portal eller PowerShell.
Azure och Hyper-V stöder inte dynamiskt minne. Se till att detta beaktas i dina prestanda- och kapacitetsplaner.
Starta om virtuella datorer via Azure-gränssnittet, inte från själva inloggningen för den virtuella datorn. Att använda Azure-gränssnittet fungerar bättre och är mer förutsägbart.
Om du vill stänga av en virtuell dator för att spara kostnader använder du Azure-gränssnittet. Om du stänger av från inloggningen för den virtuella datorn fortsätter avgifterna att ackumuleras.
Använd en namngivningskonvention för de virtuella datorerna.
Var uppmärksam på vilken datacenterplats de virtuella datorerna distribueras på.
Funktionen för automatisk skalning i Azure stöds inte för SharePoint-roller.
Konfigurera inte objekt i servergruppen som ska återställas, till exempel webbplatssamlingar.
Fas 5: Konfigurera DFSR mellan servergrupperna
Om du vill konfigurera filreplikering med hjälp av DFSR använder du snapin-modulen DNS-hantering. Innan DFSR-installationen loggar du dock in på din lokala filserver och Azure-filserver och aktiverar tjänsten i Windows.
Från Serverhanteraren instrumentpanelen utför du följande steg:
Konfigurera den lokala servern.
Starta Guiden Lägg till roller och funktioner.
Öppna noden Fil- och lagringstjänster .
Välj DFS-namnområden och DFS-replikering.
Slutför guiden genom att klicka på Nästa .
Följande tabell innehåller länkar till DFSR-referensartiklar och blogginlägg.
Tabell: Referensartiklar för DFSR
| Rubrik | Beskrivning |
|---|---|
| Replikering | DFS Management TechNet-ämne med länkar för replikering |
| DFS Replication: Överlevnadsguide | Wiki med länkar till DFS-information |
| DFS Replication: Vanliga frågor och svar | TechNet-ämne för DFS Replication |
| Jose Barreto blogg | Blogg skriven av en huvudprogramhanterare i filserverteamet på Microsoft |
| Lagringsteamet på Microsoft – Arkivkabinettblogg | Blogg om filtjänster och lagringsfunktioner i Windows Server |
Fas 6: Konfigurera loggöverföring till återställningsservergruppen
Loggöverföring är den viktiga komponenten för att konfigurera haveriberedskap i den här miljön. Du kan använda loggöverföring för att automatiskt skicka transaktionsloggfiler för databaser från en primär databasserverinstans till en sekundär databasserverinstans. Information om hur du konfigurerar loggöverföring finns i Konfigurera loggöverföring i SharePoint 2013.
Viktigt
Stöd för loggöverföring i SharePoint Server är begränsat till vissa databaser. Mer information finns i Alternativ för hög tillgänglighet och haveriberedskap för SharePoint-databaser (SharePoint 2013).
Fas 7: Validera redundans och återställning
Målet med den här slutfasen är att verifiera att haveriberedskapslösningen fungerar som planerat. Det gör du genom att skapa en redundanshändelse som stänger av produktionsgruppen och startar återställningsservergruppen som en ersättning. Du kan starta ett redundansscenario manuellt eller med hjälp av skript.
Det första steget är att stoppa inkommande användarbegäranden för servergruppstjänster eller innehåll. Du kan göra detta genom att inaktivera DNS-poster eller genom att stänga av klientwebbservrarna. När servergruppen är "nere" kan du redundansväxla till återställningsservergruppen.
Stoppa loggöverföring
Du måste stoppa loggöverföringen innan du återställer servergruppen. Stoppa loggöverföringen på den sekundära servern i Azure först och stoppa den sedan lokalt på den primära servern. Använd följande skript för att stoppa loggöverföringen på den sekundära servern först och sedan på den primära servern. Databasnamnen i skriptet kan vara olika beroende på din miljö.
-- 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 + ' )')
Återställa säkerhetskopiorna
Säkerhetskopior måste återställas i den ordning de skapades. Innan du kan återställa en viss säkerhetskopia av transaktionsloggen måste du först återställa följande tidigare säkerhetskopior utan att återställa ogenomförda transaktioner (dvs. med hjälp WITH NORECOVERYav ):
Den fullständiga databassäkerhetskopian och den senaste differentiella säkerhetskopian – Återställ dessa säkerhetskopior, om sådana finns, som görs före den specifika säkerhetskopieringen av transaktionsloggen. Innan den senaste fullständiga eller differentiella databassäkerhetskopian skapades använde databasen den fullständiga återställningsmodellen eller en massloggad återställningsmodell.
Alla säkerhetskopior av transaktionsloggar – Återställ alla säkerhetskopior av transaktionsloggar som görs efter den fullständiga säkerhetskopian av databasen eller den differentiella säkerhetskopian (om du återställer en) och före den specifika säkerhetskopieringen av transaktionsloggen. Loggsäkerhetskopior måste tillämpas i sekvensen där de skapades, utan några luckor i loggkedjan.
Om du vill återställa innehållsdatabasen på den sekundära servern så att platserna renderas tar du bort alla databasanslutningar före återställningen. Kör följande SQL-instruktion för att återställa databasen.
restore database WSS_Content with recovery
Viktigt
När du använder T-SQL explicit anger du antingen WITH NORECOVERY eller WITH RECOVERY i varje RESTORE-instruktion för att eliminera tvetydighet – detta är mycket viktigt när du skriver skript. När de fullständiga och differentiella säkerhetskopiorna har återställts kan transaktionsloggarna återställas i SQL Server Management Studio. Eftersom loggöverföringen redan har stoppats är innehållsdatabasen i vänteläge, så du måste ändra tillståndet till fullständig åtkomst.
I SQL Server Management Studio högerklickar du på WSS_Content-databasen, pekar påÅterställning av uppgifter> och klickar sedan på Transaktionslogg (om du inte har återställt den fullständiga säkerhetskopian är detta inte tillgängligt). Mer information finns iÅterställa en säkerhetskopia av transaktionsloggen (SQL Server).
Crawla innehållskällan
Du måste starta en fullständig crawlning för varje innehållskälla för att återställa söktjänsten. Observera att du förlorar viss analysinformation från den lokala servergruppen, till exempel sökrekommendationer. Innan du startar de fullständiga crawlningarna använder du cmdleten Windows PowerShell Restore-SPEnterpriseSearchServiceApplication och anger den logglevererade och replikerade sökadministrationsdatabasen Search_Service__DB_<GUID>. Den här cmdleten ger sökkonfiguration, schema, hanterade egenskaper, regler och källor och skapar en standarduppsättning med de andra komponenterna.
Utför följande steg för att starta en fullständig crawlning:
I Central administration i SharePoint 2013 går du tillProgramhanteringstjänstprogram>>Hantera tjänstprogram och klickar sedan på söktjänstprogrammet som du vill crawla.
På sidan Sökadministration klickar du på Innehållskällor, pekar på den innehållskälla som du vill använda, klickar på pilen och klickar sedan på Starta fullständig crawlning.
Återställa servergruppstjänster
Följande tabell visar hur du återställer tjänster som har logglevererade databaser, de tjänster som har databaser men som inte rekommenderas att återställas med loggöverföring och de tjänster som inte har databaser.
Viktigt
Återställning av en lokal SharePoint-databas till Azure-miljön återställer inte några SharePoint-tjänster som du inte redan har installerat i Azure manuellt.
Tabell: Databasreferens för tjänstprogram
| Återställa dessa tjänster från logglevererade databaser | Dessa tjänster har databaser, men vi rekommenderar att du startar dessa tjänster utan att återställa deras databaser | Dessa tjänster lagrar inte data i databaser. starta dessa tjänster efter redundansväxling |
|---|---|---|
| Maskinöversättningstjänst Hanterad metadatatjänst Säker lagringstjänst Användarprofil. (Endast profilerings- och sociala taggningsdatabaser stöds. Synkroniseringsdatabasen stöds inte.) Tjänst för prenumerationsinställningar för Microsoft SharePoint Foundation |
Insamling av användnings- och hälsodata Tillståndstjänst Word-automatisering |
Excel Services PerformancePoint-tjänster PowerPoint-konvertering Visio-grafiktjänst Arbetshantering |
I följande exempel visas hur du återställer tjänsten Hanterade metadata från en databas.
Detta använder den befintliga Managed_Metadata_DB-databasen. Den här databasen är en logg som levereras, men det finns inget aktivt tjänstprogram i den sekundära servergruppen, så den måste anslutas när tjänstprogrammet är på plats.
Använd först New-SPMetadataServiceApplicationoch ange växeln DatabaseName med namnet på den återställde databasen.
Konfigurera sedan det nya tjänstprogrammet för hanterade metadata på den sekundära servern enligt följande:
Namn: Managed Metadata Service
Databasserver: Databasnamnet från den levererade transaktionsloggen
Databasnamn: Managed_Metadata_DB
Programpool: SharePoint-tjänstprogram
Hantera DNS-poster
Du måste skapa DNS-poster manuellt för att peka på SharePoint-servergruppen.
I de flesta fall där du har flera klientwebbservrar är det klokt att dra nytta av funktionen Utjämning av nätverksbelastning i Windows Server 2012 eller en maskinvarubaserad lastbalanserare för att distribuera begäranden mellan webbklientdelsservrarna i servergruppen. Belastningsutjämning i nätverket kan också minska risken genom att distribuera begäranden till de andra servrarna om en av dina webbklientservrar misslyckas.
När du konfigurerar belastningsutjämning för nätverk tilldelas klustret vanligtvis en enda IP-adress. Sedan skapar du en DNS-värdpost i DNS-providern för nätverket som pekar på klustret. (För det här projektet placerar vi en DNS-server i Azure för återhämtning vid ett lokalt datacenterfel.) Du kan till exempel skapa en DNS-post i DNS Manager i Active Directory, till exempel med namnet https://sharepoint.contoso.com, som pekar på IP-adressen för ditt belastningsbalanserade kluster.
För extern åtkomst till SharePoint-servergruppen kan du skapa en värdpost på en extern DNS-server med samma URL som klienter använder på intranätet (till exempel https://sharepoint.contoso.com) som pekar på en extern IP-adress i brandväggen. (Ett bra exempel är att konfigurera delad DNS så att den interna DNS-servern är auktoritativ för och dirigerar begäranden direkt till SharePoint-servergruppsklustret i stället för contoso.com att dirigera DNS-begäranden till din externa DNS-server.) Du kan sedan mappa den externa IP-adressen till den interna IP-adressen för ditt lokala kluster så att klienterna hittar de resurser de letar efter.
Härifrån kan du stöta på ett par olika haveriberedskapsscenarier:
Exempelscenario: Den lokala SharePoint-servergruppen är inte tillgänglig på grund av maskinvarufel i den lokala SharePoint-servergruppen. När du i det här fallet har slutfört stegen för redundansväxling till Azure SharePoint-servergruppen kan du konfigurera belastningsutjämning för nätverk på SharePoint-servergruppens webbklientdelsservrar, på samma sätt som du gjorde med den lokala servergruppen. Du kan sedan omdirigera värdposten i din interna DNS-provider så att den pekar på återställningsgruppens kluster-IP-adress. Observera att det kan ta lite tid innan cachelagrade DNS-poster på klienter uppdateras och pekar på återställningsservergruppen.
Exempelscenario: Det lokala datacentret går helt förlorat. Det här scenariot kan inträffa på grund av en naturkatastrof, till exempel en brand eller översvämning. I det här fallet för ett företag skulle du förmodligen ha ett sekundärt datacenter i en annan region samt ditt Azure-undernät som har egna katalogtjänster och DNS. Precis som i föregående katastrofscenario kan du omdirigera dina interna och externa DNS-poster så att de pekar på Azure SharePoint-servergruppen. Observera återigen att dns-postspridning kan ta lite tid.
Om du använder värdnamnswebbplatssamlingar, som rekommenderas i Arkitektur och distribution av värdnamn för webbplatssamling (SharePoint 2013) kan du ha flera webbplatssamlingar som hanteras av samma webbprogram i SharePoint-servergruppen, med unika DNS-namn (till exempel https://sales.contoso.com och https://marketing.contoso.com). I det här fallet kan du skapa DNS-poster för varje webbplatssamling som pekar på klustrets IP-adress. När en begäran når sharepoint-webbklientdelsservrarna hanterar de routning av varje begäran till lämplig webbplatssamling.
Microsoft proof-of-concept-miljö
Vi har utformat och testat en proof-of-concept-miljö för den här lösningen. Designmålet för vår testmiljö var att distribuera och återställa en SharePoint-servergrupp som vi kan hitta i en kundmiljö. Vi gjorde flera antaganden, men vi visste att servergruppen behövde tillhandahålla alla färdiga funktioner utan några anpassningar. Topologin utformades för hög tillgänglighet med hjälp av metodtips från fältet och produktgruppen.
I följande tabell beskrivs de virtuella Hyper-V-datorer som vi skapade och konfigurerade för den lokala testmiljön.
Tabell: Virtuella datorer för lokalt test
| Servernamn | Roll | Konfiguration |
|---|---|---|
| DC1 | Domänkontrollant med Active Directory. | Två processorer Från 512 MB till 4 GB RAM-minne 1 x 127 GB hårddisk |
| RRAS | Server konfigurerad med RRAS-rollen (Routing and Remote Access Service). | Två processorer 2–8 GB RAM-minne 1 x 127 GB hårddisk |
| FS1 | Filserver med resurser för säkerhetskopior och en slutpunkt för DFSR. | Fyra processorer 2–12 GB RAM-minne 1 x 127 GB hårddisk 1 x 1 TB hårddisk (SAN) 1 x 750 GB hårddisk |
| SP-WFE1, SP-WFE2 | Klientwebbservrar. | Fyra processorer 16 GB RAM-minne |
| SP-APP1, SP-APP2, SP-APP3 | Programservrar. | Fyra processorer 2–16 GB RAM-minne |
| SP-SQL-HA1, SP-SQL-HA2 | Databasservrar, konfigurerade med SQL Server 2012 AlwaysOn-tillgänglighetsgrupper för att ge hög tillgänglighet. Den här konfigurationen använder SP-SQL-HA1 och SP-SQL-HA2 som primära och sekundära repliker. | Fyra processorer 2–16 GB RAM-minne |
I följande tabell beskrivs enhetskonfigurationer för de virtuella Hyper-V-datorer som vi skapade och konfigurerade för klientdelens webb- och programservrar för den lokala testmiljön.
Tabell: Krav på virtuella datorer för klientwebb- och programservrarna för det lokala testet
| Enhetsbeteckning | Storlek | Katalognamn | Sökväg |
|---|---|---|---|
| C | 80 | Systemenhet | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| E | 80 | Loggenhet (40 GB) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| F | 80 | Sida (36 GB) | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA |
I följande tabell beskrivs enhetskonfigurationer för de virtuella Hyper-V-datorer som skapats och konfigurerats för att fungera som lokala databasservrar. På sidan Konfiguration av databasmotor öppnar du fliken Datakataloger för att ange och bekräfta inställningarna som visas i följande tabell.
Tabell: Krav på virtuell datorenhet för databasservern för det lokala testet
| Enhetsbeteckning | Storlek | Katalognamn | Sökväg |
|---|---|---|---|
| C | 80 | Datarotkatalog | <DriveLetter>:\Program Files\Microsoft SQL Server\ |
| E | 500 | Katalog för användardatabas | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| F | 500 | Loggkatalog för användardatabas | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| G | 500 | Temp DB-katalog | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
| H | 500 | Temp DB-loggkatalog | <DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA |
Konfigurera testmiljön
Under de olika distributionsfaserna arbetade testteamet vanligtvis med den lokala arkitekturen först och sedan i motsvarande Azure-miljö. Detta återspeglar de allmänna verkliga fall där interna produktionsgårdar redan körs. Vad som är ännu viktigare är att du bör känna till den aktuella produktionsarbetsbelastningen, kapaciteten och typiska prestanda. Förutom att skapa en haveriberedskapsmodell som kan uppfylla affärskraven bör du ändra storleken på återställningsservergruppens servrar för att leverera en lägsta servicenivå. I en kall eller varm väntelägesmiljö är en återställningsservergrupp vanligtvis mindre än en produktionsgrupp. När återställningsservergruppen är stabil och i produktion kan servergruppen skalas upp och ut för att uppfylla arbetsbelastningskraven.
Vi distribuerade testmiljön i följande tre faser:
Konfigurera hybridinfrastrukturen
Etablera servrarna
Distribuera SharePoint-servergrupper
Konfigurera hybridinfrastrukturen
Den här fasen omfattade konfiguration av en domänmiljö för den lokala servergruppen och för återställningsservergruppen i Azure. Förutom de normala uppgifter som är associerade med att konfigurera Active Directory implementerade testteamet en routningslösning och en VPN-anslutning mellan de två miljöerna.
Etablera servrarna
Förutom servergruppsservrarna var det nödvändigt att etablera servrar för domänkontrollanterna och konfigurera en server för att hantera RRAS samt plats-till-plats-VPN. Två filservrar etablerades för DFSR-tjänsten och flera klientdatorer etablerades för testare.
Distribuera SharePoint-servergrupper
SharePoint-servergrupper distribuerades i två steg för att förenkla miljöstabilisering och felsökning om det behövs. Under den första fasen distribuerades varje servergrupp på det minsta antalet servrar för varje nivå av topologin för att stödja de nödvändiga funktionerna.
Vi skapade databasservrarna med SQL Server installerade innan vi skapade SharePoint 2013-servrarna. Eftersom det här var en ny distribution skapade vi tillgänglighetsgrupperna innan vi distribuerade SharePoint. Vi har skapat tre grupper baserat på riktlinjer för MCS-metodtips.
Obs!
Skapa platshållardatabaser så att du kan skapa tillgänglighetsgrupper före SharePoint-installationen. Mer information finns i Konfigurera SQL Server 2012 AlwaysOn-tillgänglighetsgrupper för SharePoint 2013
Vi skapade servergruppen och anslöt ytterligare servrar i följande ordning:
Etablera SP-SQL-HA1 och SP-SQL-HA2.
Konfigurera AlwaysOn och skapa de tre tillgänglighetsgrupperna för servergruppen.
Etablera SP-APP1 som värd för central administration.
Etablera SP-WFE1 och SP-WFE2 som värd för den distribuerade cachen.
Vi använde parametern skipRegisterAsDistributedCachehost när vi körde psconfig.exe på kommandoraden. Mer information finns i Planera för feeds och tjänsten Distribuerad cache i SharePoint Server 2013.
Vi upprepade följande steg i återställningsmiljön:
Etablera AZ-SQL-HA1 och AZ-SQL-HA2.
Konfigurera AlwaysOn och skapa de tre tillgänglighetsgrupperna för servergruppen.
Etablera AZ-APP1 som värd för central administration.
Etablera AZ-WFE1 och AZ-WFE2 som värd för den distribuerade cachen.
När vi har konfigurerat den distribuerade cachen och lagt till testanvändare och testinnehåll började vi steg två i distributionen. Detta krävde utskalning av nivåerna och konfiguration av servergruppsservrarna för att stödja topologin med hög tillgänglighet som beskrivs i servergruppsarkitekturen.
I följande tabell beskrivs de virtuella datorer, undernät och tillgänglighetsuppsättningar som vi har konfigurerat för vår återställningsservergrupp.
Tabell: Infrastruktur för återställningsservergrupp
| Servernamn | Roll | Konfiguration | Undernät | Tillgänglighetsuppsättning |
|---|---|---|---|---|
| spDRAD | Domänkontrollant med Active Directory | Två processorer Från 512 MB till 4 GB RAM-minne 1 x 127 GB hårddisk |
sp-ADservers | |
| AZ-SP-FS | Filserver med resurser för säkerhetskopior och en slutpunkt för DFSR | A5-konfiguration: Två processorer 14 GB RAM-minne 1 x 127 GB hårddisk 1 x 135 GB hårddisk 1 x 127 GB hårddisk 1 x 150 GB hårddisk |
sp-databaseservers | DATA_SET |
| AZ-WFE1, AZ -WFE2 | FrontEnd-webbservrar | A5-konfiguration: Två processorer 14 GB RAM-minne 1 x 127 GB hårddisk |
sp-webservers | WFE_SET |
| AZ -APP1, AZ -APP2, AZ -APP3 | Programservrar | A5-konfiguration: Två processorer 14 GB RAM-minne 1 x 127 GB hårddisk |
sp-applicationservers | APP_SET |
| AZ -SQL-HA1, AZ -SQL-HA2 | Databasservrar och primära och sekundära repliker för AlwaysOn-tillgänglighetsgrupper | A5-konfiguration: Två processorer 14 GB RAM-minne |
sp-databaseservers | DATA_SET |
Drift
När testteamet stabiliserat servergruppsmiljöerna och slutfört funktionstestningen startade de följande åtgärder som krävdes för att konfigurera den lokala återställningsmiljön:
Konfigurera fullständiga och differentiella säkerhetskopior.
Konfigurera DFSR på de filservrar som överför transaktionsloggar mellan den lokala miljön och Azure-miljön.
Konfigurera loggöverföring på den primära databasservern.
Stabilisera, validera och felsök loggöverföring efter behov. Detta inkluderade att identifiera och dokumentera alla beteenden som kan orsaka problem, till exempel nätverksfördröjning, vilket skulle orsaka loggöverföring eller DFSR-filsynkroniseringsfel.
Databaser
Våra redundanstester omfattade följande databaser:
WSS_Content
ManagedMetadata
Profildatabas
Synkronisera DATABAS
Social DB
Innehållstypshubben (en databas för en dedikerad innehållstyp syndikeringshubb)
Felsökningstips
I avsnittet beskrivs de problem vi stötte på under testningen och deras lösningar.
När du använde verktyget För hantering av termlagringsplats uppstod felet "Det hanterade metadatalagret eller anslutningen är inte tillgänglig för närvarande".
Kontrollera att det programpoolskonto som används av webbprogrammet har behörigheten Läsåtkomst till termlagring.
Anpassade termuppsättningar är inte tillgängliga i webbplatssamlingen
Sök efter en tjänstprogramassociation som saknas mellan innehållswebbplatssamlingen och din innehållstyphubb. Under skärmen Hanterade metadata – <webbplatssamlingens namn> Anslutningsegenskaper kontrollerar du dessutom att det här alternativet är aktiverat: Det här tjänstprogrammet är standardlagringsplatsen för kolumnspecifika termuppsättningar.
Kommandot Get-ADForest Windows PowerShell genererar felet "Termen "Get-ADForest" identifieras inte som namnet på en cmdlet, funktion, skriptfil eller ett fungerande program.
När du konfigurerar användarprofiler behöver du Active Directory-skogsnamnet. I guiden Lägg till roller och funktioner kontrollerar du att du har aktiverat Active Directory-modulen för Windows PowerShell (under avsnittet Rolladministrationsverktyg>för fjärrserveradministrationsverktyg>AD DS och AD LDS-verktyg). Kör dessutom följande kommandon innan du använder Get-ADForest för att se till att dina programvaruberoenden läses in.
Import-Module ServerManager
Import-Module ActiveDirectory
Det går inte att skapa tillgänglighetsgruppen när XEvent-sessionen "AlwaysOn_health" startas på servernamnet<>
Kontrollera att båda noderna i redundansklustret finns i statusen "Upp" och inte "Pausad" eller "Stoppad".
SQL Server loggöverföringsjobb misslyckas med felmeddelande om nekad åtkomst vid försök att ansluta till filresursen
Kontrollera att din SQL Server Agent körs under nätverksautentiseringsuppgifter i stället för standardautentiseringsuppgifterna.
SQL Server loggöverföringsjobb indikerar att det lyckades, men inga filer kopieras
Detta beror på att standardinställningen för säkerhetskopiering för en tillgänglighetsgrupp är Prioritera sekundär. Se till att du kör loggleveransjobbet från den sekundära servern för tillgänglighetsgruppen i stället för den primära. Annars misslyckas jobbet tyst.
Tjänsten Hanterade metadata (eller annan SharePoint-tjänst) startar inte automatiskt efter installationen
Det kan ta flera minuter att starta tjänsterna, beroende på prestanda och aktuell belastning på SharePoint Server. Klicka manuellt på Start för tjänsten och ge tillräckligt med tid för start samtidigt som du ibland uppdaterar skärmen Tjänster på servern för att övervaka dess status. Om tjänsten förblir stoppad aktiverar du SharePoint-diagnostikloggning, försöker starta tjänsten igen och kontrollerar sedan loggen efter fel. Mer information finns i Konfigurera diagnostikloggning i SharePoint 2013
När du har ändrat DNS till Azure-redundansmiljön fortsätter klientwebbläsare att använda den gamla IP-adressen för SharePoint-webbplatsen
DNS-ändringen kanske inte visas för alla klienter omedelbart. På en testklient utför du följande kommando från en upphöjd kommandotolk och försöker komma åt platsen igen.
Ipconfig /flushdns
Ytterligare resurser
Alternativ för hög tillgänglighet och haveriberedskap för SharePoint-databaser som stöds
Konfigurera SQL Server 2012 AlwaysOn-tillgänglighetsgrupper för SharePoint 2013
Se även
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för