Share via


Konfigurera haveriberedskap för ett SharePoint-program med flera nivåer för haveriberedskap med Azure Site Recovery

Den här artikeln beskriver i detalj hur du skyddar ett SharePoint-program med hjälp av Azure Site Recovery.

Översikt

Microsoft SharePoint är ett kraftfullt program som kan hjälpa en grupp eller avdelning att organisera, samarbeta och dela information. SharePoint kan tillhandahålla intranätportaler, dokument- och filhantering, samarbete, sociala nätverk, extranät, webbplatser, företagssökning och Business Intelligence. Den har också funktioner för systemintegrering, processintegrering och arbetsflödesautomatisering. Vanligtvis betraktar organisationer det som ett nivå 1-program som är känsligt för stilleståndstid och dataförlust.

I dag tillhandahåller Microsoft SharePoint inga färdiga funktioner för haveriberedskap. Oavsett typ och omfattning av en katastrof innebär återställningen att du använder ett väntelägesdatacenter som du kan återställa servergruppen till. Standby-datacenter krävs för scenarier där lokala redundanta system och säkerhetskopior inte kan återställas från avbrottet i det primära datacentret.

En bra haveriberedskapslösning bör tillåta modellering av återställningsplaner runt komplexa programarkitekturer som SharePoint. Den bör också ha möjlighet att lägga till anpassade steg för att hantera programmappningar mellan olika nivåer och därmed tillhandahålla en redundansväxling med ett enda klick med en lägre RTO i händelse av en katastrof.

Den här artikeln beskriver i detalj hur du skyddar ett SharePoint-program med hjälp av Azure Site Recovery. Den här artikeln beskriver metodtips för replikering av ett SharePoint-program med tre nivåer till Azure, hur du kan göra ett programåterställningstest och hur du kan redundansväxlar programmet till Azure.

Du kan titta på videon nedan om hur du återställer ett flernivåprogram till Azure.

Förutsättningar

Kontrollera att du förstår följande innan du börjar:

  1. Replikera en virtuell dator till Azure
  2. Så här utformar du ett återställningsnätverk
  3. Göra ett redundanstest till Azure
  4. Redundansväxling till Azure
  5. Så här replikerar du en domänkontrollant
  6. Så här replikerar du SQL Server

SharePoint-arkitektur

SharePoint kan distribueras på en eller flera servrar med hjälp av nivåindelade topologier och serverroller för att implementera en servergruppsdesign som uppfyller specifika mål. En typisk stor SharePoint-servergrupp med hög efterfrågan som stöder ett stort antal samtidiga användare och ett stort antal innehållsobjekt använder tjänstgruppering som en del av sin skalbarhetsstrategi. Den här metoden omfattar att köra tjänster på dedikerade servrar, gruppera dessa tjänster tillsammans och sedan skala ut servrarna som en grupp. Följande topologi illustrerar tjänst- och servergruppering för en SharePoint-servergrupp på tre nivåer. Mer information om olika SharePoint-topologier finns i SharePoint-dokumentationen och produktradsarkitekturer. Mer information om SharePoint 2013-distribution finns i det här dokumentet.

Distributionsmönster 1

Site Recovery-stöd

Site Recovery är programagnostisk och bör fungera med alla versioner av SharePoint som körs på en dator som stöds. För att skapa den här artikeln användes virtuella VMware-datorer med Windows Server 2012 R2 Enterprise. SharePoint 2013 Enterprise Edition och SQL Server 2014 Enterprise Edition användes.

Källa och mål

Scenario Till en sekundär plats Till Azure
Hyper-V Ja Ja
VMware Ja Ja
Fysisk server Ja Ja
Azure Ej tillämpligt Ja

Saker att tänka på

Om du använder ett delat diskbaserat kluster som någon nivå i ditt program kan du inte använda Site Recovery replikering för att replikera dessa virtuella datorer. Du kan använda inbyggd replikering som tillhandahålls av programmet och sedan använda en återställningsplan för att redundansväxlar alla nivåer.

Replikera virtuella datorer

Följ den här vägledningen för att börja replikera den virtuella datorn till Azure.

  • När replikeringen är klar kontrollerar du att du går till varje virtuell dator på varje nivå och väljer samma tillgänglighetsuppsättning i "Egenskaper för inställningar för replikerade objekt >> – > Beräkning och nätverk". Om din webbnivå till exempel har 3 virtuella datorer kontrollerar du att alla tre virtuella datorer är konfigurerade för att ingå i samma tillgänglighetsuppsättning i Azure.

    Set-Availability-Set

  • Vägledning om hur du skyddar Active Directory och DNS finns i dokumentet Skydda Active Directory och DNS .

  • Information om hur du skyddar databasnivån som körs på SQL Server finns i dokumentet Skydda SQL Server.

Nätverkskonfiguration

Nätverksegenskaper

  • För virtuella datorer på app- och webbnivå konfigurerar du nätverksinställningar i Azure Portal så att de virtuella datorerna ansluts till rätt DR-nätverk efter redundansväxlingen.

    Välj Nätverk

  • Om du använder en statisk IP-adress anger du den IP-adress som du vill att den virtuella datorn ska ta i fältet Mål-IP

    Ange statisk IP-adress

DNS och trafikroutning

För webbplatser som är riktade mot Internet skapar du en Traffic Manager-profil av typen Prioritet i Azure-prenumerationen. Konfigurera sedan din DNS- och Traffic Manager-profil på följande sätt.

Var Källa Mål
Offentligt DNS Offentlig DNS för SharePoint-webbplatser

Exempel: sharepoint.contoso.com
Traffic Manager

contososharepoint.trafficmanager.net
Lokal DNS sharepointonprem.contoso.com Offentlig IP-adress i den lokala servergruppen

I Traffic Manager-profilen skapar du de primära slutpunkterna och återställningsslutpunkterna. Använd den externa slutpunkten för lokal slutpunkt och offentlig IP-adress för Azure-slutpunkten. Se till att prioriteten är högre än den lokala slutpunkten.

Värdhantera en testsida på en specifik port (till exempel 800) på SharePoint-webbnivån för att Traffic Manager automatiskt ska kunna identifiera tillgänglighet efter redundans. Det här är en lösning om du inte kan aktivera anonym autentisering på någon av dina SharePoint-webbplatser.

Konfigurera Traffic Manager-profilen med inställningarna nedan.

  • Routningsmetod – "Prioritet"
  • DNS time to live (TTL) – "30 sekunder"
  • Inställningar för slutpunktsövervakare – Om du kan aktivera anonym autentisering kan du ge en specifik webbplatsslutpunkt. Eller så kan du använda en testsida på en specifik port (till exempel 800).

Skapa en återställningsplan

En återställningsplan gör det möjligt att sekvensera redundansväxlingen för olika nivåer i ett flernivåprogram, och därmed upprätthålla programkonsekvensen. Följ stegen nedan när du skapar en återställningsplan för ett webbprogram med flera nivåer. Läs mer om att skapa en återställningsplan.

Lägga till virtuella datorer i redundansgrupper

  1. Skapa en återställningsplan genom att lägga till virtuella datorer på app- och webbnivå.

  2. Klicka på Anpassa för att gruppera de virtuella datorerna. Som standard ingår alla virtuella datorer i Grupp 1.

    Anpassa RP

  3. Skapa en annan grupp (grupp 2) och flytta de virtuella datorerna på webbnivån till den nya gruppen. Dina virtuella datorer på appnivå ska ingå i Grupp 1 och virtuella datorer på webbnivå ska ingå i Grupp 2. Detta är för att säkerställa att de virtuella datorerna på appnivå startar först följt av virtuella datorer på webbnivå.

Lägga till skript i återställningsplanen

Du kan distribuera de vanligaste Azure Site Recovery-skripten till ditt Automation-konto genom att klicka på knappen Distribuera till Azure nedan. När du använder ett publicerat skript kontrollerar du att du följer vägledningen i skriptet.

Distribuera till Azure

  1. Lägg till ett föråtgärdsskript i Grupp 1 i sql-tillgänglighetsgruppen för redundansväxling. Använd skriptet "ASR-SQL-FailoverAG" som publicerats i exempelskripten. Se till att du följer vägledningen i skriptet och gör de nödvändiga ändringarna i skriptet på rätt sätt.

    Add-AG-Script-Step-1

    Add-AG-Script-Step-2

  2. Lägg till ett poståtgärdsskript för att koppla en lastbalanserare på de redvässlade virtuella datorerna på webbnivån (grupp 2). Använd ASR-AddSingleLoadBalancer-skriptet som publicerats i exempelskripten. Se till att du följer vägledningen i skriptet och gör de nödvändiga ändringarna i skriptet på rätt sätt.

    Add-LB-Script-Step-1

    Add-LB-Script-Step-2

  3. Lägg till ett manuellt steg för att uppdatera DNS-posterna så att de pekar på den nya servergruppen i Azure.

    • För internetuppkopplade webbplatser krävs inga DNS-uppdateringar efter redundansväxling. Följ stegen som beskrivs i avsnittet "Nätverksvägledning" för att konfigurera Traffic Manager. Om Traffic Manager-profilen har konfigurerats enligt beskrivningen i föregående avsnitt lägger du till ett skript för att öppna dummyporten (800 i exemplet) på den virtuella Azure-datorn.

    • För interna webbplatser lägger du till ett manuellt steg för att uppdatera DNS-posten så att den pekar på den nya virtuella webbnivådatorns lastbalanserares IP-adress.

  4. Lägg till ett manuellt steg för att återställa sökprogrammet från en säkerhetskopia eller starta en ny söktjänst.

  5. Följ stegen nedan för att återställa tjänsten Search program från en säkerhetskopia.

    • Den här metoden förutsätter att en säkerhetskopia av söktjänstprogrammet utfördes före den katastrofala händelsen och att säkerhetskopian är tillgänglig på DR-platsen.
    • Detta kan enkelt uppnås genom att schemalägga säkerhetskopieringen (till exempel en gång dagligen) och använda en kopieringsprocedur för att placera säkerhetskopian på dr-platsen. Kopieringsprocedurer kan omfatta skriptprogram som AzCopy (Azure Copy) eller konfiguration av DFSR (Distributed File Services Replication).
    • Nu när SharePoint-servergruppen körs navigerar du i Central administration, Säkerhetskopiering och återställning och väljer Återställ. Återställningen frågar den angivna säkerhetskopieringsplatsen (du kan behöva uppdatera värdet). Välj den säkerhetskopiering av söktjänstprogrammet som du vill återställa.
    • Sökningen återställs. Tänk på att återställningen förväntar sig att hitta samma topologi (samma antal servrar) och samma hårddiskbeteckningar som tilldelats dessa servrar. Mer information finns i dokumentet "Återställ tjänsten Search program i SharePoint 2013".
  6. Följ stegen nedan för att börja med ett nytt tjänsten Search program.

    • Den här metoden förutsätter att en säkerhetskopia av databasen "Sökadministration" är tillgänglig på DR-platsen.
    • Eftersom de andra söktjänstprogramdatabaserna inte replikeras måste de återskapas. Det gör du genom att gå till Central administration och ta bort söktjänstprogrammet. Ta bort indexfilerna på alla servrar som är värdar för sökindexet.
    • Återskapa söktjänstprogrammet och återskapa databaserna. Vi rekommenderar att du har ett förberett skript som återskapar det här tjänstprogrammet eftersom det inte går att utföra alla åtgärder via användargränssnittet. Du kan till exempel bara ange indexenhetens plats och konfigurera söktopologin med hjälp av SharePoint PowerShell-cmdletar. Använd Windows PowerShell-cmdleten Restore-SPEnterpriseSearchServiceApplication och ange den logglevererade och replikerade sökadministrationsdatabasen Search_Service__DB. Den här cmdleten ger sökkonfiguration, schema, hanterade egenskaper, regler och källor och skapar en standarduppsättning med de andra komponenterna.
    • När söktjänstprogrammet har återskapats måste du starta en fullständig crawlning för varje innehållskälla för att återställa söktjänsten. Du förlorar viss analysinformation från den lokala servergruppen, till exempel sökrekommendationer.
  7. När alla steg har slutförts sparar du återställningsplanen och den slutliga återställningsplanen ser ut så här.

    Sparad RP

Gör ett redundanstest

Följ den här vägledningen för att utföra ett redundanstest.

  1. Gå till Azure Portal och välj ditt Recovery Service-valv.
  2. Klicka på återställningsplanen som skapats för SharePoint-programmet.
  3. Klicka på "Testa redundans".
  4. Välj återställningspunkt och virtuellt Azure-nätverk för att starta redundanstestningsprocessen.
  5. När den sekundära miljön är igång kan du utföra dina valideringar.
  6. När valideringarna är klara kan du klicka på Rensa redundanstest i återställningsplanen och redundanstestmiljön rensas.

Vägledning om hur du utför redundanstest för AD och DNS finns i test av redundansöverväganden för AD- och DNS-dokument .

Vägledning om hur du utför redundanstest för SQL Always ON-tillgänglighetsgrupper finns i Utföra program-DR med Azure Site Recovery och göra dokumentet Testa redundans.

Redundansväxling

Följ den här vägledningen för att utföra en redundansväxling.

  1. Gå till Azure Portal och välj ditt Recovery Services-valv.
  2. Klicka på återställningsplanen som skapats för SharePoint-programmet.
  3. Klicka på "Redundans".
  4. Välj återställningspunkt för att starta redundansväxlingsprocessen.

Nästa steg

Du kan lära dig mer om att replikera andra program med hjälp av Site Recovery.