Modifica

Eseguire una farm di SharePoint Server 2016 a disponibilità elevata in Azure

Azure ExpressRoute
Azure Managed Disks
Macchine virtuali di Azure
Rete virtuale di Azure
Gateway VPN di Azure

Questa architettura di riferimento mostra procedure comprovate per la distribuzione di una farm di SharePoint Server 2016 a disponibilità elevata in Azure, usando la topologia MinRole e i gruppi di disponibilità di SQL Server Always On. La farm di SharePoint viene distribuita in una rete virtuale protetta senza endpoint o presenza con connessione Internet.

Architettura

Architecture diagram that shows a highly available SharePoint Server 2016 farm in Azure.

Scaricare un file di Visio di questa architettura.

Questa architettura si basa su quella illustrata in [Eseguire macchine virtuali Windows per un'applicazione a più livelli][windows-n-tier]. Distribuisce una farm di SharePoint Server 2016 con disponibilità elevata all'interno di una rete virtuale di Azure. Questa architettura è adatta a un ambiente di test o di produzione, a un'infrastruttura ibrida SharePoint con Microsoft 365 o come base per uno scenario di ripristino di emergenza.

Componenti

  • I gruppi di risorse sono contenitori che contengono risorse di Azure correlate. Un gruppo di risorse viene usato per i server SharePoint e un altro gruppo di risorse viene usato per i componenti dell'infrastruttura indipendenti dalle macchine virtuali, ad esempio la rete virtuale e i servizi di bilanciamento del carico.

  • Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Le macchine virtuali vengono distribuite in una rete virtuale con uno spazio indirizzi Intranet univoco. La rete virtuale è ulteriormente suddivisa in subnet.

  • Le macchine virtuali sono risorse di calcolo su richiesta e scalabili disponibili con Azure. Le macchine virtuali vengono distribuite nella rete virtuale e gli indirizzi IP statici privati vengono assegnati a tutte le macchine virtuali. Gli indirizzi IP statici sono consigliati per le macchine virtuali che eseguono SQL Server e SharePoint Server 2016, per evitare problemi relativi alla memorizzazione nella cache degli indirizzi IP e alle modifiche di indirizzi dopo un riavvio.

  • I set di disponibilità sono raggruppamenti logici di macchine virtuali. Inserire le macchine virtuali per ogni ruolo di SharePoint in set di disponibilità separati ed effettuare il provisioning di almeno due macchine virtuali per ogni ruolo. Questa configurazione rende le macchine virtuali idonee per un contratto di servizio (SLA) superiore.

  • Azure Load Balancer distribuisce il traffico delle richieste di SharePoint dalla rete locale ai server Web front-end della farm di SharePoint. Questa soluzione usa un servizio di bilanciamento del carico interno. In alternativa al traffico HTTP, è possibile usare app Azure gateway di comunicazione.

  • I gruppi di sicurezza di rete filtrano il traffico in una rete virtuale di Azure. Per ogni subnet che contiene macchine virtuali, viene creato un gruppo di sicurezza di rete. Usare i gruppi di sicurezza di rete per limitare il traffico di rete all'interno di una rete virtuale per isolare le subnet.

  • Azure ExpressRoute o una VPN da sito a sito, ad esempio Azure Gateway VPN, fornisce una connessione tra la rete locale e la rete virtuale di Azure. Per altre informazioni, vedere Connettere una rete locale ad Azure.

  • I controller di dominio di Windows Server Active Directory (AD) autenticano gli utenti all'interno di un dominio. I controller di dominio in questa architettura di riferimento vengono eseguiti nella rete virtuale di Azure e hanno una relazione di trust con la foresta di Windows Server AD locale. Le richieste Web client per le risorse della farm di SharePoint vengono autenticate nella rete virtuale anziché inviare tale traffico di autenticazione attraverso la connessione gateway alla rete locale. In DNS, i record Intranet A o CNAME vengono creati in modo che gli utenti della Intranet possano risolvere il nome della farm di SharePoint all'indirizzo IP privato del bilanciamento del carico interno.

    SharePoint Server 2016 supporta anche l'uso di Microsoft Entra Domain Services. Servizi di dominio Microsoft Entra fornisce servizi di dominio gestiti in modo che non sia necessario distribuire e gestire controller di dominio in Azure.

  • I gruppi di disponibilità AlwaysOn di SQL Server offrono una soluzione a disponibilità elevata e ripristino di emergenza. È consigliabile usarli per la disponibilità elevata del database di SQL Server. Per SQL Server vengono usate due macchine virtuali. Uno contiene la replica di database primaria e l'altro contiene la replica secondaria.

  • Una macchina virtuale del nodo di maggioranza consente al cluster di failover di stabilire un quorum. Per altre informazioni, vedere Informazioni sulle configurazioni quorum in un cluster di failover.

  • SharePoint Server offre una piattaforma per l'accesso condiviso. I server SharePoint eseguono i ruoli Web front-end, memorizzazione nella cache, applicazione e ricerca.

  • Un jump box, detto anche bastion host, è una macchina virtuale sicura nella rete usata dagli amministratori per connettersi alle altre macchine virtuali. La jump box include un gruppo di sicurezza di rete che consente il traffico remoto solo dagli indirizzi IP pubblici in un elenco sicuro. Il gruppo di sicurezza di rete deve consentire il traffico desktop remoto (RDP).

Consigli

I requisiti della propria organizzazione potrebbero essere diversi da quelli dell'architettura descritta in questo articolo. Usare queste indicazioni come punto di partenza.

Indicazioni sui gruppi di risorse

È consigliabile separare i gruppi di risorse in base al ruolo del server e disporre di un gruppo di risorse separato per i componenti di infrastruttura che sono risorse globali. In questa architettura le risorse di SharePoint formano un gruppo, mentre le risorse di Microsoft Server SQL e di altre utilità formano un altro gruppo.

Indicazioni sulla rete virtuale e le subnet

Usare una subnet per ogni ruolo di SharePoint, oltre a una subnet per il gateway e una per la jump box.

La subnet per il gateway deve essere denominata GatewaySubnet. Assegnare lo spazio di indirizzi della subnet per il gateway usando l'ultima parte dello spazio di indirizzi della rete virtuale. Per altre informazioni, vedere Connettere una rete locale ad Azure usando un gateway VPN.

Indicazioni per le VM

Questa architettura richiede un minimo di 44 core:

  • Otto server SharePoint in Standard_DS3_v2 (4 core ciascuno) = 32 core
  • Due controller di dominio di Active Directory in Standard_DS1_v2 (1 core ciascuno) = 2 core
  • Due macchine virtuali di SQL Server in Standard_DS3_v2 = 8 core
  • Un nodo di maggioranza in Standard_DS1_v2 = 1 core
  • Un server di gestione in Standard_DS1_v2 = 1 core

Per tutti i ruoli di SharePoint tranne l'indicizzatore di ricerca, è consigliabile usare la dimensione di VM Standard_DS3_v2. La dimensione dell'indicizzatore di ricerca deve essere almeno Standard_DS13_v2. Per altre informazioni, vedere i requisiti hardware e software per SharePoint Server 2016. Per le macchine virtuali di SQL Server, è consigliabile usare almeno 4 core e 8 GB di RAM. Per altre informazioni, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).

Consigli per i gruppi di sicurezza di rete

Per abilitare l'isolamento della subnet, è consigliabile avere un gruppo di sicurezza di rete per ogni subnet che contiene macchine virtuali. Se si vuole configurare l'isolamento della subnet, aggiungere regole del gruppo di sicurezza di rete che definiscono il traffico in ingresso o in uscita consentito o negato per ogni subnet. Per altre informazioni, vedere Filtrare il traffico di rete con gruppi di sicurezza di rete.

Non assegnare un gruppo di sicurezza di rete alla subnet del gateway o il gateway smetterà di funzionare.

Indicazioni sull'archiviazione

La configurazione dell'archiviazione delle macchine virtuali nella farm deve corrispondere alle procedure consigliate appropriate usate per le distribuzioni locali. È necessario un disco separato per i log nei server SharePoint. I server SharePoint con i ruoli di indice di ricerca richiedono ulteriore spazio su disco per l'archiviazione dell'indice di ricerca. Per SQL Server la procedura standard consiste nel separare i dati e i log. Aggiungere altri dischi per l'archiviazione del backup di database e usare un disco separato per tempdb.

Per una migliore affidabilità, è consigliabile usare Azure Managed Disks. I dischi gestiti garantiscono che i dischi per le macchine virtuali all'interno di un set di disponibilità siano isolati per evitare singoli punti di guasto.

Usare i dischi gestiti Premium per tutte le macchine virtuali di SQL Server e SharePoint. È possibile usare i dischi gestiti Standard per il server con maggioranza dei nodi, i controller di dominio e il server di gestione.

Indicazioni sui server SharePoint

Prima di configurare la farm di SharePoint, accertarsi che sia disponibile un account di servizio di Windows Server Active Directory per ogni servizio. Per questa architettura, è necessario almeno gli account a livello di dominio seguenti per isolare i privilegi per ogni ruolo:

  • Account del servizio SQL Server
  • Account utente per la configurazione
  • Account della server farm
  • Account del servizio di ricerca
  • Account di accesso al contenuto
  • Account per il pool di app Web
  • Account per il pool di app di servizio
  • Account utente con privilegi avanzati per la cache
  • Account lettore con privilegi avanzati per la cache

Per soddisfare il requisito di supporto per la velocità effettiva del disco di almeno 200 MB al secondo, assicurarsi di pianificare l'architettura di ricerca. Vedere Pianificare l'architettura di ricerca a livello aziendale in SharePoint Server 2013. Seguire inoltre le linee guida in Procedure consigliate per la ricerca per indicizzazione in SharePoint Server 2016.

Inoltre è possibile archiviare i dati dei componenti di ricerca in una partizione o in un volume di archiviazione separato con prestazioni elevate. Per ridurre il carico e migliorare la velocità effettiva, configurare gli account utente per la cache di oggetti che sono necessari in questa architettura. Dividere i file del sistema operativo Windows Server, i file di programma di SharePoint Server 2016 e i log di diagnostica in tre partizioni o volumi di archiviazione separati con prestazioni normali.

Per altre informazioni su queste indicazioni, vedere Account amministrativi e di servizio per la distribuzione iniziale in SharePoint Server 2016.

Carichi di lavoro ibridi

Questa architettura di riferimento distribuisce una farm di SharePoint Server 2016 che può essere usata come ambiente ibrido di SharePoint, ovvero estendendo SharePoint Server 2016 a SharePoint Online. Se si dispone di Office Online Server, vedere Supporto di Office Web Apps e Office Online Server in Azure.

Le applicazioni di servizio predefinite in questa soluzione sono progettate per supportare carichi di lavoro ibridi. Tutti i carichi di lavoro ibridi di SharePoint Server 2016 e Microsoft 365 possono essere distribuiti in questa farm senza modifiche all'infrastruttura di SharePoint, con un'eccezione: l'applicazione del servizio di ricerca ibrida cloud non deve essere distribuita nei server che ospitano una topologia di ricerca esistente. È quindi necessario aggiungere una o più macchine virtuali basate sui ruoli di ricerca alla farm per supportare questo scenario ibrido.

Gruppi di disponibilità Always On di SQL Server

Questa architettura usa macchine virtuali di SQL Server perché SharePoint Server 2016 non può usare database SQL di Azure. Per supportare la disponibilità elevata in SQL Server, è consigliabile usare i gruppi di disponibilità Always On, che definiscono un set di database sottoposti contemporaneamente a failover, assicurando disponibilità elevata e possibilità di ripristino. Per altre informazioni, vedere Creare il gruppo di disponibilità e aggiungere i database SharePoint.

È anche consigliabile aggiungere un indirizzo IP del listener al cluster, ovvero l'indirizzo IP privato del servizio di bilanciamento del carico interno per le macchine virtuali di SQL Server.

Per le dimensioni di VM consigliate e per altre raccomandazioni sulle prestazioni per SQL Server in esecuzione in Azure, vedere Procedure consigliate per le prestazioni per SQL Server in Macchine virtuali di Azure. Seguire inoltre le raccomandazioni riportate in Procedure consigliate per SQL Server in una farm di SharePoint Server 2016.

È consigliabile che il server del nodo di maggioranza risieda in un computer separato dai partner di replica. Il server consente al server partner di replica secondaria in una sessione in modalità a protezione elevata di stabilire se avviare un failover automatico. A differenza dei due partner, il server con maggioranza dei nodi non serve il database ma supporta il failover automatico.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Scalabilità

Per aumentare le prestazioni dei server esistenti, modificare le dimensioni della macchina virtuale.

Con la funzionalità MinRoles in SharePoint Server 2016, è possibile aumentare il numero di istanze per i server in base al ruolo del server e rimuovere i server da un ruolo. Quando si aggiungono server a un ruolo, è possibile specificare uno dei ruoli singoli o uno dei ruoli combinati. Tuttavia, se si aggiungono server al ruolo di ricerca, è necessario anche riconfigurare la topologia di ricerca tramite PowerShell. È anche possibile convertire i ruoli usando MinRoles. Per altre informazioni, vedere Gestione di una server farm MinRole in SharePoint Server 2016.

SharePoint Server 2016 non supporta l'uso di set di scalabilità di macchine virtuali per la scalabilità automatica.

Disponibilità

Questa architettura di riferimento supporta la disponibilità elevata all'interno di un'area di Azure perché ogni ruolo ha almeno due macchine virtuali distribuite in un set di disponibilità.

Per evitare un errore a livello di area, creare una farm separata per il ripristino di emergenza in un'area diversa di Azure. Gli obiettivi del tempo di ripristino (RTO) e gli obiettivi del punto di ripristino (RPO) determineranno i requisiti della configurazione. Per informazioni dettagliate, vedere Scegliere una strategia di ripristino di emergenza per SharePoint 2016. L'area secondaria deve essere un'area abbinata all'area primaria. Nel caso di un'interruzione su vasta scala, viene definita la priorità di ripristino di un'area per ogni coppia. Per altre informazioni, vedere Continuità aziendale e ripristino di emergenza nelle aree geografiche abbinate di Azure.

Gestione

Per usare e gestire i server, le server farm e i siti, seguire le procedure consigliate per le operazioni SharePoint. Per altre informazioni, vedere Operazioni per SharePoint Server 2016.

Le attività da prendere in considerazione per la gestione di SQL Server in un ambiente SharePoint possono differire da quelle considerate in genere per un'applicazione di database. Una procedura consigliata consiste nel backup settimanale completo di tutti i database SQL con backup incrementali ogni notte. Eseguire un backup dei log delle transazioni ogni 15 minuti. Un'altra procedura consiste nell'implementare le attività di manutenzione di SQL Server nei database disabilitando al contempo quelle SharePoint predefinite. Per altre informazioni, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

Gli account del servizio a livello di dominio usati per eseguire SharePoint Server 2016 richiedono controller di dominio di Windows Server AD o Microsoft Entra Domain Services per processi di aggiunta a dominio e autenticazione. Per estendere l'infrastruttura di identità di Windows Server Active Directory già in uso in Intranet, però, questa particolare architettura usa due macchine virtuali come controller di dominio di replica di Windows Server Active Directory di una foresta Windows Server Active Directory locale esistente.

Inoltre è sempre consigliabile pianificare la protezione avanzata della sicurezza. Altri indicazioni includono:

  • Aggiungere regole ai gruppi di sicurezza di rete per isolare subnet e ruoli.
  • Non assegnare indirizzi IP pubblici alle macchine virtuali.
  • Per il rilevamento delle intrusioni e l'analisi dei payload, considerare l'uso di un dispositivo di rete virtuale davanti ai server Web front-end anziché un servizio di bilanciamento del carico interno di Azure.
  • In alternativa, usare i criteri IPsec per la crittografia del traffico di testo non crittografato tra server. Se si esegue anche l'isolamento della subnet, aggiornare le regole del gruppo di sicurezza di rete per consentire il traffico IPsec.
  • Installare gli agenti anti-malware per le macchine virtuali.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

Usare il calcolatore dei prezzi di Azure per stimare i costi. Ecco alcuni fattori per ottimizzare il costo per questa architettura.

Active Directory Domain Services

Valutare se scegliere Active Directory Domain Services come servizio condiviso utilizzato da più carichi di lavoro per ridurre i costi. Per altre informazioni, vedere prezzi di Dominio di Active Directory Services.

Gateway VPN

Il modello di fatturazione è basato sulla quantità di tempo durante il quale il gateway viene sottoposto a provisioning e risulta disponibile. Vedere Gateway VPN prezzi.

Tutto il traffico in ingresso è gratuito. Tutto il traffico in uscita viene fatturato. I costi della larghezza di banda Internet vengono applicati al traffico in uscita della VPN.

Rete virtuale

Rete virtuale è gratuito. Per ogni sottoscrizione è possibile creare fino a 50 reti virtuali in tutte le aree. Tutto il traffico che ha origine entro i limiti di una rete virtuale è gratuito. Quindi, la comunicazione tra due macchine virtuali nella stessa rete virtuale è gratuita.

Questa architettura si basa sull'architettura distribuita in [Eseguire macchine virtuali Windows per un'applicazione a più livelli][windows-n-tier].

Per altre informazioni, vedere la sezione sui costi in Microsoft Azure Well-Architected Framework.

DevOps

Valutare se usare gruppi di risorse separati per gli ambienti di produzione, sviluppo e test. L'uso di gruppi di risorse separati semplifica la gestione delle distribuzioni, l'eliminazione delle distribuzioni di test e l'assegnazione dei diritti di accesso. In generale, includere le risorse con un ciclo di vita identico nello stesso gruppo. Per gli ambienti di sviluppo e test è opportuno usare un livello Developer. Per ridurre al minimo i costi durante la pre-produzione, distribuire una replica dell'ambiente di produzione, eseguire i test e quindi arrestare il sistema.

Usare i modelli di Azure Resource Manager o i modelli di Azure Bicep per definire l'infrastruttura. In entrambi i casi, si segue la procedura di infrastruttura come codice (IaC) per la distribuzione delle risorse. Per automatizzare la distribuzione dell'infrastruttura, è possibile usare Azure DevOps Services o altre soluzioni CI/CD. Anche il processo di distribuzione è idempotente, ovvero ripetibile per produrre gli stessi risultati. Azure Pipelines fa parte di Azure DevOps Services ed esegue compilazioni, test e distribuzioni automatizzati.

Strutturare i modelli di distribuzione seguendo i criteri del carico di lavoro, identificare singole unità di lavoro e includerli nel proprio modello. In questo scenario, almeno sette carichi di lavoro vengono identificati e isolati nei propri modelli: la rete virtuale di Azure e il gateway VPN, il jump box di gestione, i controller di dominio AD e le macchine virtuali di SQL Server, il cluster di failover e il gruppo di disponibilità e le vm rimanenti, il nodo primario di SharePoint, la cache di SharePoint e le regole del gruppo di sicurezza di rete. L'isolamento dei carichi di lavoro semplifica l'associazione delle risorse specifiche di un carico di lavoro a un team, così che il team possa gestirne in modo indipendente tutti gli aspetti. Questo isolamento consente a DevOps di eseguire l'integrazione continua e il recapito continuo (CI/CD). Questa configurazione consente anche la gestione temporanea dei carichi di lavoro, ovvero la distribuzione in varie fasi e l'esecuzione delle convalide in ogni fase prima di passare a quella successiva. In questo modo, è possibile eseguire il push degli aggiornamenti negli ambienti di produzione in modo altamente controllato e ridurre al minimo i problemi di distribuzione imprevisti.

Prendere in considerazione l'uso di Monitoraggio di Azure per analizzare e ottimizzare le prestazioni dell'infrastruttura, monitorare e diagnosticare i problemi di rete senza accedere alle macchine virtuali.

Per altre informazioni, vedere la sezione DevOps in Azure Well-Architected Framework.

Passaggi successivi

Per altre informazioni sulle singole parti dell'architettura della soluzione, vedere gli argomenti seguenti: