Dela via

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

  • Artikel

I den här artikeln beskrivs 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 även funktioner för systemintegrering, processintegrering och arbetsflödesautomatisering. Vanligtvis betraktar organisationer det som ett nivå 1-program som är känsligt för driftstopp och dataförlust.

I dag tillhandahåller Microsoft SharePoint inte några färdiga funktioner för haveriberedskap. Oavsett typ och omfattning av en katastrof innebär återställning 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 driftstoppet i det primära datacentret.

En bra lösning för haveriberedskap bör tillåta modellering av återställningsplaner kring 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.

I den här artikeln beskrivs i detalj hur du skyddar ett SharePoint-program med Hjälp av Azure Site Recovery. Den här artikeln beskriver metodtipsen för att replikera ett SharePoint-program med tre nivåer till Azure, hur du kan utföra ett haveriberedskapstest och hur du kan redundansväxla programmet 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. Utforma 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 innebär 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-dokumentation och produktlinjearkitekturer. Mer information om Distribution av SharePoint 2013 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. I 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 Saknas 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 intern replikering som tillhandahålls av programmet och sedan använda en återställningsplan för att redundansväxla 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 webbnivån till exempel har tre 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 Skydda Active Directory och DNS-dokument .

  • Vägledning 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 internetuppkopplade webbplatser skapar du en Traffic Manager-profil av typen Prioritet i Azure-prenumerationen. Och konfigurera sedan din DNS- och Traffic Manager-profil på följande sätt.

Var Source Mål
Offentligt DNS Offentlig DNS för SharePoint-webbplatser

Ex: 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. Kontrollera att prioriteten är högre än den lokala slutpunkten.

Värd för 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 redundansväxling. 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 följande inställningar:

  • Routningsmetod – "Prioritet"
  • DNS-tid att leva (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 program med flera nivåer, och därmed upprätthålla programkonsekvens. Följ de angivna stegen 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 vara en del av "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. När du använder ett publicerat skript ska du följa riktlinjerna i skriptet.

Distribuera till Azure

  1. Lägg till ett föråtgärdsskript till 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 riktlinjerna 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 rededitlade virtuella datorerna på webbnivån (grupp 2). Använd skriptet ASR-AddSingleLoadBalancer som publicerats i exempelskripten. Se till att du följer riktlinjerna 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äxlingen. Följ stegen som beskrivs i avsnittet "Vägledning för nätverk" 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 adresser lägger du till ett manuellt steg för att uppdatera DNS-posten så att den pekar på den nya virtuella datorns IP-adress för lastbalanseraren på den nya webbnivån.

  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 dessa steg 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 Den centrala administrationen, "Säkerhetskopiering och återställning" och väljer Återställ. Återställningen frågar efter 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 dessa steg för att börja med ett nytt tjänsten Search program:

    • Den här metoden förutsätter att en säkerhetskopia av sökadministrationsdatabasen ä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. Till exempel är det bara möjligt att ange platsen för indexenheten 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ökkonfigurationen, schemat, hanterade egenskaper, regler och källor och skapar en standarduppsättning av 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öra 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. Välj återställningsplanen som skapats för SharePoint-programmet.
  3. Välj Testa redundans.
  4. Välj återställningspunkt och virtuellt Azure-nätverk för att starta redundanstestprocessen.
  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 failover considerations for AD and DNS document (Testa 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äxlingen.

Nästa steg

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