Microsoft Azure Architectures for SharePoint 2013

Azure è un ambiente ideale per ospitare una soluzione SharePoint Server 2013. Nella maggior parte dei casi, è consigliabile Microsoft 365, ma una farm di SharePoint Server ospitata in Azure può essere una buona opzione per soluzioni specifiche. Questo articolo descrive come progettare soluzioni SharePoint in modo che siano adatte alla piattaforma Azure. Come esempi vengono usate le due soluzioni specifiche seguenti:

I servizi dell'infrastruttura di Azure sono un'opzione interessante per l'hosting di soluzioni SharePoint. Alcune soluzioni sono più adatte a questa piattaforma rispetto ad altre. La tabella seguente illustra le soluzioni consigliate.

Soluzione Perché questa soluzione è consigliata per Azure
Ambienti di sviluppo e test È facile creare e gestire questi ambienti.
Ripristino di emergenza delle farm di SharePoint locali in Azure Data center secondario ospitato Usare Azure invece di investire in un data center secondario in un'area diversa.
Ambienti di ripristino di emergenza a costi inferiori Gestire e pagare meno risorse rispetto a un ambiente di ripristino di emergenza locale. Il numero di risorse dipende dall'ambiente di ripristino di emergenza scelto: cold standby, warm standby o hot standby.
Piattaforma più elastica In caso di emergenza, aumentare facilmente il numero di istanze della farm di SharePoint di ripristino per soddisfare i requisiti di carico. Ridurre quando la risorsa non è più necessaria.
Vedere Ripristino di emergenza di SharePoint Server 2013 in Microsoft Azure.
Siti con connessione Internet che usano funzionalità e scalabilità non disponibili in Microsoft 365 Concentrarsi sui propri sforzi Concentrarsi sulla costruzione di un ottimo sito piuttosto che sulla costruzione di infrastrutture.
Sfruttare l'elasticità in Azure Ridimensionare la farm per la domanda aggiungendo nuovi server e pagare solo le risorse necessarie. L'allocazione dinamica del computer non è supportata (scalabilità automatica).
Usare Microsoft Entra ID Sfruttare le Microsoft Entra ID per gli account dei clienti.
Aggiungere funzionalità di SharePoint non disponibili in Microsoft 365 Aggiungere report approfonditi e analisi Web.
Vedere Siti Internet in Microsoft Azure con SharePoint Server 2013.
Farm di app per supportare ambienti Microsoft 365 o locali Compilare, testare e ospitare app in Azure per supportare ambienti sia locali che cloud.
Ospitare questo ruolo in Azure invece di acquistare nuovo hardware per gli ambienti locali.

Per le soluzioni intranet e di collaborazione e i carichi di lavoro, prendere in considerazione le opzioni seguenti:

  • Determinare se Microsoft 365 soddisfa i requisiti aziendali o può far parte della soluzione. Microsoft 365 offre un set di funzionalità completo sempre aggiornato.

  • Se Microsoft 365 non soddisfa tutti i requisiti aziendali, prendere in considerazione un'implementazione standard di SharePoint 2013 in locale da Microsoft Consulting Services (MCS). Un'architettura standard può essere una soluzione più veloce, più economica e più semplice da supportare rispetto a una soluzione personalizzata.

  • Se un'implementazione standard non soddisfa i requisiti aziendali, prendere in considerazione una soluzione locale personalizzata.

  • Se l'uso di una piattaforma cloud è importante per i requisiti aziendali, considerare un'implementazione standard o personalizzata di SharePoint 2013 ospitata nei servizi dell'infrastruttura di Azure. Le soluzioni SharePoint sono molto più facili da supportare in Azure rispetto ad altre piattaforme cloud pubbliche Microsoft non native.

Prima di progettare l'ambiente Azure

Anche se questo articolo usa topologie di SharePoint di esempio, è possibile usare questi concetti di progettazione con qualsiasi topologia della farm di SharePoint. Prima di progettare l'ambiente Azure, usare la topologia, l'architettura, la capacità e le indicazioni sulle prestazioni seguenti per progettare la farm di SharePoint:

Determinare il tipo di dominio Active Directory

Ogni farm di SharePoint Server si basa su Active Directory per fornire account amministrativi per la configurazione della farm. Al momento sono disponibili due opzioni per le soluzioni SharePoint in Azure. Sono descritti nella tabella seguente.

Opzione Descrizione
Dominio dedicato È possibile distribuire un dominio Active Directory dedicato e isolato in Azure per supportare la farm di SharePoint. Questa è una buona scelta per i siti Internet pubblici.
Estendere il dominio locale tramite una connessione cross-premise Quando si estende il dominio locale tramite una connessione cross-premise, gli utenti accedono alla farm di SharePoint tramite la intranet come se fosse ospitata in locale. È possibile sfruttare i vantaggi dell'implementazione Active Directory locale e DNS.
È necessaria una connessione cross-premise per la creazione di un ambiente di ripristino di emergenza in Azure a cui eseguire il failover dalla farm locale.

Questo articolo include concetti di progettazione per l'estensione del dominio locale tramite una connessione cross-premise. Se la soluzione usa un dominio dedicato, non è necessaria una connessione cross-premise.

Progettare la rete virtuale

Per prima cosa è necessaria una rete virtuale in Azure, che includa subnet in cui inserire le macchine virtuali. La rete virtuale necessita di uno spazio di indirizzi IP privato, parti delle quali si assegnano alle subnet.

Se si estende la rete locale ad Azure tramite una connessione cross-premise (necessaria per un ambiente di ripristino di emergenza), è necessario scegliere uno spazio indirizzi privato che non è già in uso altrove nella rete dell'organizzazione, che può includere l'ambiente locale e altre reti virtuali di Azure.

Figura 1: Ambiente locale con una rete virtuale in Azure:

Progettazione di reti virtuali di Microsoft Azure per una soluzione SharePoint. Una subnet per il gateway di Azure. Una subnet per le macchine virtuali.

In questo diagramma:

  • Viene illustrata una rete virtuale in Azure affiancata all'ambiente locale. I due ambienti non sono ancora connessi da una connessione cross-premise, che può essere una connessione VPN da sito a sito o ExpressRoute.

  • A questo punto, la rete virtuale include solo le subnet e nessun altro elemento architetturale. Una subnet ospiterà il gateway di Azure e altre subnet ospiteranno i livelli della farm di SharePoint, con un'altra per Active Directory e DNS.

Aggiungere connettività cross-premise

Il passaggio successivo alla distribuzione consiste nel creare la connessione cross-premise (se si applica alla soluzione). Per le connessioni cross-premise, un gateway di Azure si trova in una subnet del gateway separata, che è necessario creare e assegnare uno spazio indirizzi.

Quando si pianifica una connessione cross-premise, si definisce e si crea un gateway di Azure e una connessione a un dispositivo gateway locale.

Figura 2: Uso di un gateway di Azure e di un dispositivo gateway locale per fornire connettività da sito a sito tra l'ambiente locale e Azure:

Ambiente locale connesso a una rete virtuale di Azure tramite una connessione cross-premise, che può essere una connessione VPN da sito a sito o ExpressRoute.

In questo diagramma:

  • Aggiungendo al diagramma precedente, l'ambiente locale è connesso alla rete virtuale di Azure tramite una connessione cross-premise, che può essere una connessione VPN da sito a sito o ExpressRoute.

  • Un gateway di Azure si trova in una subnet del gateway.

  • L'ambiente locale include un dispositivo gateway, ad esempio un router o un server VPN.

Per altre informazioni su come pianificare e creare una rete virtuale cross-premise, vedere Connettere una rete locale a una rete virtuale di Microsoft Azure.

Aggiungere Active Directory Domain Services (AD DS) e DNS

Per il ripristino di emergenza in Azure, si distribuiscono Windows Server AD e DNS in uno scenario ibrido in cui Windows Server AD viene distribuito sia in locale che in macchine virtuali di Azure.

Figura 3: Configurazione ibrida del dominio di Active Directory:

Le due macchine virtuali distribuite nella rete virtuale di Azure e nella subnet della farm di SharePoint sono controller di dominio di replica e server DNS.

Questo diagramma si basa sui diagrammi precedenti aggiungendo due macchine virtuali a una subnet Windows Server AD e DNS. Queste macchine virtuali sono controller di dominio di replica e server DNS. Si tratta di un'estensione dell'ambiente Windows Server AD locale.

La tabella seguente fornisce consigli di configurazione per queste macchine virtuali in Azure. Usare questi elementi come punto di partenza per la progettazione del proprio ambiente, anche per un dominio dedicato in cui l'ambiente Azure non comunica con l'ambiente locale.

Elemento Configurazione
Dimensioni della macchina virtuale in Azure Dimensioni A1 o A2 nel livello Standard
Sistema operativo Windows Server 2012 R2
Ruolo di Active Directory Controller di dominio Active Directory Domain Services designato come server di catalogo globale. Questa configurazione riduce il traffico in uscita attraverso la connessione cross-premise.
In un ambiente multidominio con elevate velocità di modifica (non comune), configurare i controller di dominio in locale per non eseguire la sincronizzazione con i server di catalogo globale in Azure per ridurre il traffico di replica.
Ruolo DNS Installare e configurare il servizio Server DNS nei controller di dominio.
Dischi dati Posizionare il database, i log e SYSVOL di Active Directory su dischi dati di Azure aggiuntivi. Non inserirli nel disco del sistema operativo o nei dischi temporanei forniti da Azure.
Indirizzi IP Usare gli indirizzi IP statici e configurare la rete virtuale per assegnare questi indirizzi alle macchine virtuali nella rete virtuale dopo la configurazione dei controller di dominio.

Importante

Prima di distribuire Active Directory in Azure, leggere Linee guida per la distribuzione di Windows Server Active Directory in Azure Macchine virtuali. Queste informazioni consentono di determinare se sono necessarie un'architettura diversa o impostazioni di configurazione diverse per la soluzione.

Aggiungere la farm di SharePoint

Inserire le macchine virtuali della farm di SharePoint in livelli nelle subnet appropriate.

Figura 4: Posizionamento delle macchine virtuali di SharePoint:

Server di database e ruoli del server SharePoint aggiunti alla rete virtuale di Azure all'interno della subnet della farm di SharePoint.

Questo diagramma si basa sui diagrammi precedenti aggiungendo i ruoli del server farm di SharePoint nei rispettivi livelli.

  • Due macchine virtuali di database in esecuzione SQL Server creare il livello di database.

  • Due macchine virtuali che eseguono SharePoint Server 2013 per ognuno dei livelli seguenti: server front-end, server cache distribuita e server back-end.

Progettare e ottimizzare i ruoli del server per i set di disponibilità e i domini di errore

Un dominio di errore è un raggruppamento di hardware in cui vengono eseguite le istanze del ruolo. Le macchine virtuali all'interno dello stesso dominio di errore possono essere aggiornate contemporaneamente dall'infrastruttura di Azure. In alternativa, possono non riuscire contemporaneamente perché condividono lo stesso rack. Per evitare il rischio di avere due macchine virtuali nello stesso dominio di errore, è possibile configurare le macchine virtuali come set di disponibilità, garantendo che ogni macchina virtuale si trova in un dominio di errore diverso. Se tre macchine virtuali sono configurate come set di disponibilità, Azure garantisce che non più di due macchine virtuali si trovino nello stesso dominio di errore.

Quando si progetta l'architettura di Azure per una farm di SharePoint, configurare ruoli server identici per far parte di un set di disponibilità. Ciò garantisce che le macchine virtuali siano distribuite tra più domini di errore.

Figura 5: Usare i set di disponibilità di Azure per fornire disponibilità elevata per i livelli della farm di SharePoint:

Configurazione dei set di disponibilità nell'infrastruttura di Azure per una soluzione SharePoint 2013.

Questo diagramma illustra la configurazione dei set di disponibilità all'interno dell'infrastruttura di Azure. Ognuno dei ruoli seguenti condivide un set di disponibilità separato:

  • Active Directory e DNS

  • Database

  • Back-end

  • Distribuire la cache

  • Front-end

Potrebbe essere necessario ottimizzare la farm di SharePoint nella piattaforma Azure. Per garantire la disponibilità elevata di tutti i componenti, assicurarsi che i ruoli del server siano tutti configurati in modo identico.

Di seguito è riportato un esempio che mostra un'architettura di siti Internet standard che soddisfa obiettivi specifici di capacità e prestazioni. Questo esempio è illustrato nel modello di architettura seguente: Internet Sites Search Architectures for SharePoint Server 2013.

Figura 6: Esempio di pianificazione per gli obiettivi di capacità e prestazioni in una farm a tre livelli:

Architettura dei siti Internet di SharePoint 2013 standard con allocazioni di componenti che soddisfano obiettivi di capacità e prestazioni specifici.

In questo diagramma:

  • È rappresentata una farm a tre livelli: server Web, server applicazioni e server di database.

  • I tre server Web sono configurati in modo identico con più componenti.

  • I due server di database sono configurati in modo identico.

  • I tre server applicazioni non sono configurati in modo identico. Questi ruoli del server richiedono un'ottimizzazione per i set di disponibilità in Azure.

Verrà ora esaminato più da vicino il livello del server applicazioni.

Figura 7: Livello server applicazioni prima dell'ottimizzazione:

Esempio di livello server applicazioni di SharePoint Server 2013 prima dell'ottimizzazione per i set di disponibilità di Microsoft Azure.

In questo diagramma:

  • Tre server sono inclusi nel livello applicazione.

  • Il primo server include quattro componenti.

  • Il secondo server include tre componenti.

  • Il terzo server include due componenti.

Si determina il numero di componenti in base agli obiettivi di prestazioni e capacità per la farm. Per adattare questa architettura per Azure, verranno replicati i quattro componenti in tutti e tre i server. Questo aumenta il numero di componenti oltre a quanto necessario per le prestazioni e la capacità. Il compromesso è che questa progettazione garantisce la disponibilità elevata di tutti e quattro i componenti nella piattaforma Azure quando queste tre macchine virtuali vengono assegnate a un set di disponibilità.

Figura 8: Livello server applicazioni dopo l'ottimizzazione:

Esempio di livello server applicazioni di SharePoint Server 2013 dopo l'ottimizzazione per i set di disponibilità di Microsoft Azure.

Questo diagramma mostra tutti e tre i server applicazioni configurati in modo identico con gli stessi quattro componenti.

Quando si aggiungono set di disponibilità ai livelli della farm di SharePoint, l'implementazione è completa.

Figura 9: Farm di SharePoint completata nei servizi dell'infrastruttura di Azure:

Farm di Esempio di SharePoint 2013 nei servizi di infrastruttura di Azure con rete virtuale, connettività cross-premise, subnet, macchine virtuali e set di disponibilità.

Questo diagramma mostra la farm di SharePoint implementata nei servizi dell'infrastruttura di Azure, con set di disponibilità per fornire domini di errore per i server in ogni livello.

Vedere anche

Centro soluzioni e architetture di Microsoft 365

Siti Internet in Microsoft Azure che utilizzano SharePoint Server 2013

Ripristino di emergenza di SharePoint Server 2013 in Microsoft Azure