Microsoft Azure-arkitekturer för SharePoint 2013
Azure är en bra miljö för att vara värd för en SharePoint Server 2013-lösning. I de flesta fall rekommenderar vi Microsoft 365, men en SharePoint Server-servergrupp som finns i Azure kan vara ett bra alternativ för specifika lösningar. Den här artikeln beskriver hur du skapar SharePoint-lösningar så att de passar bra på Azure-plattformen. Följande två specifika lösningar används som exempel:
Rekommenderade SharePoint-lösningar för Azure Infrastructure Services
Azure-infrastrukturtjänster är ett övertygande alternativ för att vara värd för SharePoint-lösningar. Vissa lösningar passar bättre för den här plattformen än andra. I följande tabell visas rekommenderade lösningar.
| Lösning | Därför rekommenderas den här lösningen för Azure |
|---|---|
| Utvecklings- och testmiljöer | Det är enkelt att skapa och hantera dessa miljöer. |
| Haveriberedskap för lokala SharePoint-servergrupper till Azure | Värdbaserat sekundärt datacenter Använd Azure i stället för att investera i ett sekundärt datacenter i en annan region. Miljöer med lägre kostnad för haveriberedskap Underhålla och betala för färre resurser än en lokal haveriberedskapsmiljö. Antalet resurser beror på vilken haveriberedskapsmiljö du väljer: kallt vänteläge, varmt vänteläge eller hett vänteläge. Mer elastisk plattform 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. Se Haveriberedskap för SharePoint Server 2013 i Microsoft Azure. |
| Internetuppkopplade webbplatser som använder funktioner och skala som inte är tillgängliga i Microsoft 365 | Fokusera dina ansträngningar Koncentrera dig på att bygga en bra plats i stället för att bygga infrastruktur. Dra nytta av elasticitet i Azure Ange servergruppens storlek för efterfrågan genom att lägga till nya servrar och betala endast för resurser som du behöver. Dynamisk datorallokering stöds inte (automatisk skalning). Använd Microsoft Entra ID Dra nytta av Microsoft Entra ID för kundkonton. Lägg till SharePoint-funktioner som inte är tillgängliga i Microsoft 365 Lägg till djuprapportering och webbanalys. Se Webbplatser i Microsoft Azure med SharePoint Server 2013. |
| Appgrupper för att stödja Microsoft 365 eller lokala miljöer | Skapa, testa och hantera appar i Azure för att stödja både lokala och molnbaserade miljöer. Värd för den här rollen i Azure i stället för att köpa ny maskinvara för lokala miljöer. |
Överväg följande alternativ för lösningar och arbetsbelastningar för intranät och samarbete:
Kontrollera om Microsoft 365 uppfyller dina affärskrav eller kan ingå i lösningen. Microsoft 365 tillhandahåller en omfattande funktionsuppsättning som alltid är uppdaterad.
Om Microsoft 365 inte uppfyller alla dina affärskrav bör du överväga en standardimplementering av SharePoint 2013 lokalt från Microsoft Consulting Services (MCS). En standardarkitektur kan vara en snabbare, billigare och enklare lösning som du kan stödja än en anpassad.
Om en standardimplementering inte uppfyller dina affärskrav bör du överväga en anpassad lokal lösning.
Om det är viktigt att använda en molnplattform för dina affärsbehov bör du överväga en standardimplementering eller anpassad implementering av SharePoint 2013 i Azure-infrastrukturtjänster. SharePoint-lösningar är mycket enklare att stödja i Azure än andra offentliga Microsoft-molnplattformar som inte är inbyggda.
Innan du utformar Azure-miljön
Den här artikeln använder exempel på SharePoint-topologier, men du kan använda dessa designbegrepp med valfri SharePoint-servergruppstopologi. Innan du utformar Azure-miljön bör du använda följande topologi, arkitektur, kapacitet och prestandavägledning för att utforma SharePoint-servergruppen:
Fastställa active directory-domäntypen
Varje SharePoint Server-servergrupp förlitar sig på Active Directory för att tillhandahålla administrativa konton för servergruppskonfiguration. För närvarande finns det två alternativ för SharePoint-lösningar i Azure. Dessa beskrivs i följande tabell.
| Alternativ | Beskrivning |
|---|---|
| Dedikerad domän | Du kan distribuera en dedikerad och isolerad Active Directory-domän till Azure för att stödja din SharePoint-servergrupp. Detta är ett bra val för offentliga webbplatser. |
| Utöka den lokala domänen via en anslutning mellan platser | När du utökar den lokala domänen via en anslutning mellan platser får användarna åtkomst till SharePoint-servergruppen via intranätet som om den fanns lokalt. Du kan dra nytta av din lokal Active Directory och DNS-implementering. En anslutning mellan platser krävs för att skapa en haveriberedskapsmiljö i Azure för redundansväxling till från din lokala servergrupp. |
Den här artikeln innehåller designbegrepp för att utöka den lokala domänen via en anslutning mellan platser. Om din lösning använder en dedikerad domän behöver du ingen anslutning mellan platser.
Utforma det virtuella nätverket
Först behöver du ett virtuellt nätverk i Azure, som innehåller undernät där du ska placera dina virtuella datorer. Det virtuella nätverket behöver ett privat IP-adressutrymme, varav delar du tilldelar till undernäten.
Om du utökar ditt lokala nätverk till Azure via en anslutning mellan platser (krävs för en haveriberedskapsmiljö) måste du välja ett privat adressutrymme som inte redan används någon annanstans i organisationens nätverk, vilket kan inkludera din lokala miljö och andra virtuella Azure-nätverk.
Bild 1: Lokal miljö med ett virtuellt nätverk i Azure:
I det här diagrammet:
Ett virtuellt nätverk i Azure illustreras sida vid sida i den lokala miljön. De två miljöerna är ännu inte anslutna via en anslutning mellan platser, vilket kan vara en PLATS-till-plats-VPN-anslutning eller ExpressRoute.
I det här läget innehåller det virtuella nätverket bara undernäten och inga andra arkitekturelement. Ett undernät är värd för Azure-gatewayen och andra undernät som är värdar för SharePoint-servergruppens nivåer, med ytterligare ett för Active Directory och DNS.
Lägga till anslutningar mellan platser
Nästa distributionssteg är att skapa den lokala anslutningen (om detta gäller för din lösning). För anslutningar mellan platser finns en Azure-gateway i ett separat gatewayundernät, som du måste skapa och tilldela ett adressutrymme.
När du planerar för en anslutning mellan platser definierar och skapar du en Azure-gateway och anslutning till en lokal gatewayenhet.
Bild 2: Använda en Azure-gateway och en lokal gatewayenhet för att tillhandahålla plats-till-plats-anslutning mellan den lokala miljön och Azure:
I det här diagrammet:
Om du lägger till det föregående diagrammet är den lokala miljön ansluten till det virtuella Azure-nätverket via en anslutning mellan platser, som kan vara en VPN-anslutning från plats till plats eller ExpressRoute.
En Azure-gateway finns i ett gatewayundernät.
Den lokala miljön innehåller en gatewayenhet, till exempel en router eller VPN-server.
Mer information om hur du planerar för och skapar ett virtuellt nätverk mellan platser finns i Ansluta ett lokalt nätverk till ett virtuellt Microsoft Azure-nätverk.
Lägg till Active Directory Domain Services (AD DS) och DNS
För haveriberedskap i Azure distribuerar du Windows Server AD och DNS i ett hybridscenario där Windows Server AD distribueras både lokalt och på virtuella Azure-datorer.
Bild 3: Hybrid Active Directory-domänkonfiguration:
Det här diagrammet bygger på föregående diagram genom att lägga till två virtuella datorer i en Windows Server AD och ETT DNS-undernät. Dessa virtuella datorer är replikdomänkontrollanter och DNS-servrar. De är en utökning av den lokala Windows Server AD miljön.
Följande tabell innehåller konfigurationsrekommendationer för dessa virtuella datorer i Azure. Använd dessa som utgångspunkt för att utforma din egen miljö – även för en dedikerad domän där din Azure-miljö inte kommunicerar med din lokala miljö.
| Objekt | Konfiguration |
|---|---|
| Storlek på virtuella datorer i Azure | A1- eller A2-storlek på standardnivån |
| Operativsystem | Windows Server 2012 R2 |
| Active Directory-roll | AD DS-domänkontrollant som utsetts till en global katalogserver. Den här konfigurationen minskar utgående trafik över den lokala anslutningen. I en miljö med flera domäner med höga ändringshastigheter (detta är inte vanligt) konfigurerar du domänkontrollanter lokalt för att inte synkronisera med de globala katalogservrarna i Azure för att minska replikeringstrafiken. |
| DNS-roll | Installera och konfigurera DNS-servertjänsten på domänkontrollanterna. |
| Datadiskar | Placera Active Directory-databasen, loggarna och SYSVOL på ytterligare Azure-datadiskar. Placera inte dessa på operativsystemdisken eller de tillfälliga diskar som tillhandahålls av Azure. |
| IP-adresser | Använd statiska IP-adresser och konfigurera det virtuella nätverket för att tilldela dessa adresser till de virtuella datorerna i det virtuella nätverket när domänkontrollanterna har konfigurerats. |
Viktigt
Innan du distribuerar Active Directory i Azure läser du Riktlinjer för att distribuera Windows Server Active Directory på Azure Virtual Machines. Dessa hjälper dig att avgöra om en annan arkitektur eller olika konfigurationsinställningar behövs för din lösning.
Lägg till SharePoint-servergruppen
Placera de virtuella datorerna i SharePoint-servergruppen på nivåer i lämpliga undernät.
Bild 4: Placering av virtuella SharePoint-datorer:
Det här diagrammet bygger på föregående diagram genom att lägga till Serverrollerna för SharePoint-servergruppen på respektive nivå.
Två virtuella databasdatorer som kör SQL Server skapa databasnivån.
Två virtuella datorer som kör SharePoint Server 2013 för var och en av följande nivåer: klientdelsservrar, distribuerade cacheservrar och serverdelsservrar.
Utforma och finjustera serverroller för tillgänglighetsuppsättningar och feldomäner
En feldomän är en gruppering av maskinvara där rollinstanser körs. Virtuella datorer inom samma feldomän kan uppdateras av Azure-infrastrukturen på samma gång. Eller så kan de misslyckas samtidigt eftersom de delar samma rack. För att undvika risken att ha två virtuella datorer på samma feldomän kan du konfigurera dina virtuella datorer som en tillgänglighetsuppsättning, vilket säkerställer att varje virtuell dator finns i en annan feldomän. Om tre virtuella datorer har konfigurerats som en tillgänglighetsuppsättning garanterar Azure att högst två av de virtuella datorerna finns i samma feldomän.
När du utformar Azure-arkitekturen för en SharePoint-servergrupp konfigurerar du identiska serverroller som en del av en tillgänglighetsuppsättning. Detta säkerställer att dina virtuella datorer är spridda över flera feldomäner.
Bild 5: Använd Azure-tillgänglighetsuppsättningar för att tillhandahålla hög tillgänglighet för SharePoint-servergruppnivåerna:
I det här diagrammet beskrivs konfigurationen av tillgänglighetsuppsättningar i Azure-infrastrukturen. Var och en av följande roller delar en separat tillgänglighetsuppsättning:
Active Directory och DNS
Databas
Serverdel
Distribuera cache
Klientdel
SharePoint-servergruppen kan behöva finjusteras på Azure-plattformen. För att säkerställa hög tillgänglighet för alla komponenter kontrollerar du att alla serverroller har konfigurerats på samma sätt.
Här är ett exempel som visar en standardarkitektur för Webbplatser som uppfyller specifika kapacitets- och prestandamål. Det här exemplet finns i följande arkitekturmodell: Sökarkitekturer för Webbplatser för SharePoint Server 2013.
Bild 6: Planeringsexempel för kapacitets- och prestandamål i en servergrupp med tre nivåer:
I det här diagrammet:
En grupp med tre nivåer representeras: webbservrar, programservrar och databasservrar.
De tre webbservrarna konfigureras identiskt med flera komponenter.
De två databasservrarna konfigureras på samma sätt.
De tre programservrarna har inte konfigurerats på samma sätt. Dessa serverroller kräver finjustering för tillgänglighetsuppsättningar i Azure.
Nu ska vi titta närmare på programservernivån.
Bild 7: Programservernivå före finjustering:
I det här diagrammet:
Tre servrar ingår i programnivån.
Den första servern innehåller fyra komponenter.
Den andra servern innehåller tre komponenter.
Den tredje servern innehåller två komponenter.
Du bestämmer antalet komponenter efter prestanda- och kapacitetsmål för servergruppen. För att anpassa den här arkitekturen för Azure replikerar vi de fyra komponenterna på alla tre servrarna. Detta ökar antalet komponenter utöver vad som är nödvändigt för prestanda och kapacitet. Kompromissen är att den här designen garanterar hög tillgänglighet för alla fyra komponenterna på Azure-plattformen när dessa tre virtuella datorer tilldelas till en tillgänglighetsuppsättning.
Bild 8: Programservernivå efter finjustering:
Det här diagrammet visar alla tre programservrar som har konfigurerats identiskt med samma fyra komponenter.
När vi lägger till tillgänglighetsuppsättningar på sharepoint-servergruppens nivåer är implementeringen klar.
Bild 9: Den slutförda SharePoint-servergruppen i Azure-infrastrukturtjänster:
Det här diagrammet visar SharePoint-servergruppen som implementerats i Azure-infrastrukturtjänster, med tillgänglighetsuppsättningar för att tillhandahålla feldomäner för servrarna på varje nivå.
Se även
Microsoft 365-lösning och arkitekturcenter
Webbplatser i Microsoft Azure med SharePoint Server 2013
SharePoint Server 2013 katastrofåterställning i Microsoft Azure
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