Pianificare architetture virtuali (SharePoint Server 2010)

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2017-01-17

In questo articolo vengono illustrate le considerazioni di base per la pianificazione di architetture virtuali tramite ruoli di server di Microsoft SharePoint Server 2010. Non vengono forniti invece dati o suggerimenti sulla pianificazione di prestazioni o capacità. Vengono fornite inoltre informazioni aggiuntive per la pianificazione di ambienti virtuali e vengono incluse architetture di esempio di farm di dimensioni ridotte, medie ed estese.

Contenuto dell'articolo:

• Confronto tra architetture virtuali e architetture fisiche

• Architetture virtuali di esempio per farm di piccole e medie dimensioni

• Architetture virtuali di esempio per farm di medie e grandi dimensioni

Confronto tra architetture virtuali e architetture fisiche

In un'organizzazione in genere si valuta la possibilità di passare ad architetture virtuali per ridurre il numero di server necessari per ospitare una soluzione, per utilizzare in modo più efficiente l'hardware esistente o per risparmiare spazio ed energia. La possibilità di automatizzare la distribuzione dei server è un'altra motivazione importante per la distribuzione di un ambiente di server virtuali.

Virtualizzazione di server Web e server applicazioni

I ruoli di server Web e server applicazioni sono ottimi candidati per la virtualizzazione. Quando si pianifica un ambiente virtuale, è opportuno applicare informazioni su topologia, prestazioni e capacità per pianificare l'ambiente fisico e quindi utilizzare il numero risultante di server Web e server applicazioni, inclusi specifici ruoli di server applicazioni, come punto di partenza per l'ambiente virtuale.

In un ambiente virtuale tuttavia potrebbero essere necessari più server virtuali per offrire lo stesso livello di servizi e prestazioni nelle ore di punta offerto dai server fisici. I risultati dipenderanno dai servizi specifici e dai modelli di utilizzo di tali servizi.

Dopo questa premessa, considerare che l'utilizzo di un ambiente virtuale garantisce la flessibilità di riallocare le risorse tra le macchine virtuali a seconda dei casi per ottimizzare le prestazioni. È inoltre più semplice aggiungere e rimuovere server virtuali per risolvere problemi di picchi di utilizzo di servizi specifici che si verificano sempre negli stessi periodi dell'anno.

Virtualizzazione di SQL Server

La scelta di virtualizzare o meno Microsoft SQL Server è discutibile e dipende dagli obiettivi globali di una distribuzione. Un ambiente SQL Server virtuale offre in genere prestazioni leggermente più lente rispetto a un ambiente fisico, benché le prestazioni siano migliorate con le nuove versioni. Utilizzando la versione più recente del ruolo Hyper-V (disponibile in Windows Server 2008 R2), i test delle prestazioni di SQL Server indicano che in una macchina virtuale guest viene ottenuta la stessa velocità effettiva di un server fisico con un utilizzo della CPU leggermente più elevato.

È necessario tenere conto di altre considerazioni prima di pianificare la virtualizzazione di SQL Server, ad esempio il numero di CPU core richiesti da SQL Server, il piano di failover e disponibilità e le opzioni per l'ottimizzazione dell'archiviazione. Nonostante tutto, i vantaggi offerti dalla distribuzione di SQL Server in un ambiente virtuale possono superare gli svantaggi in termini di prestazioni.

Le organizzazioni che ospitano farm di SharePoint e pianificano di distribuire e ricreare farm con una certa frequenza, ad esempio le società di hosting, otterranno risultati ottimali aggiungendo SQL Server all'ambiente virtuale. La virtualizzazione di SQL Server può rivelarsi utile inoltre in una soluzione temporanea o transitoria, ad esempio quando si combinano più farm in una farm aziendale e si disattivano componenti hardware. Le organizzazioni che sfruttano al massimo componenti hardware limitati otterranno risultati migliori distribuendo SQL Server in server fisici. Negli esempi riportati in questo articolo sono inclusi ambienti basati su entrambi gli approcci.

Per ulteriori informazioni, vedere Esecuzione di SQL Server 2008 in un ambiente Hyper-V - Procedure consigliate e suggerimenti per le prestazioni (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=134106&clcid=0x410). Questo white paper si basa su una versione precedente di Hyper-V. Una versione più aggiornata del documento è disponibile a partire dalla tarda primavera del 2010.

Virtualizzazione di altri server nell'ambiente

Le soluzioni di Prodotti SharePoint 2010 si basano su altri server dell'ambiente. In questa sezione vengono fornite informazioni aggiuntive generali sul factoring in un'architettura virtuale.

Active Directory

È consigliabile che almeno il controller di dominio radice di un ambiente di servizi directory Active Directory sia ospitato in un server fisico esterno agli ambienti virtuali. Se necessario, è possibile distribuire controller di dominio aggiuntivi come server virtuali.

Per ulteriori informazioni su come distribuire Active Directory in ambienti virtuali, vedere le risorse seguenti:

• Blog di Sander Berkouwer: Active Directory in ambienti Hyper-V, parte 2 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=186927&clcid=0x410)

• Considerazioni sulla pianificazione dei controller di dominio virtualizzati (https://go.microsoft.com/fwlink/?linkid=186928&clcid=0x410)

Prodotti gateway

Tra i prodotti gateway sono inclusi:

• Microsoft Forefront Unified Access Gateway (UAG)

• Microsoft Forefront Threat Management Gateway (TMG)

Per una maggiore disponibilità, è consigliabile posizionare questi prodotti all'esterno dell'ambiente virtuale di Prodotti SharePoint 2010. Per ulteriori informazioni su come configurare ambienti virtuali per questi prodotti gateway, vedere la documentazione dei prodotti.

Testing affiancato

Se si teme che la distribuzione dei ruoli di server di Prodotti SharePoint 2010 in un ambiente virtuale possa produrre effetti negativi sulle prestazioni, prendere in considerazione l'eventualità di testare i ruoli specifici che di prevede di distribuire. È possibile utilizzare i risultati per decidere quanti server virtuali distribuire per un ruolo specifico o addirittura se distribuire un ruolo specifico nell'ambiente virtuale. Se ad esempio nella farm verrà eseguita la ricerca per indicizzazione di una quantità elevata di contenuto, i risultati dei test possono indurre a distribuire il ruolo di ricerca per indicizzazione in un server fisico dedicato.

Un modo per testare un ambiente virtuale consiste nel distribuire un ruolo specifico sia virtualmente che fisicamente e nel confrontare i dati benchmark per rete, memoria, disco e CPU. Nella figura seguente viene fornito un esempio di come testare specifici ruoli di server utilizzando un numero limitato di server.

In questa figura vengono distribuiti ruoli specifici nell'ambiente virtuale. Viene configurato un server fisico di testing per verificare un ruolo per volta in modo da poter raccogliere dati benchmark affiancati. Tenere conto delle differenze tra gli ambienti fisici e virtuali che influiscono sui risultati del test, ad esempio specifiche hardware diverse.

Se si dispone di una farm esistente, è possibile aggiungere un host virtuale e integrare macchine virtuali con ruoli equivalenti per osservare gli effetti prodotti da ogni ruolo sulle prestazioni virtuali. È inoltre possibile osservare il modo in cui combinazioni diverse di ruoli influiscono sulle prestazioni globali della farm. Nell'esempio seguente viene illustrato questo concetto.

Architetture virtuali di esempio per farm di piccole e medie dimensioni

Come punto di partenza per sostituire una farm fisica con una farm virtuale utilizzare da due a quattro server host fisici. Per ogni host, il numero di server che possono essere distribuiti dipende dalla memoria disponibile, dalla CPU, dal disco e dalle risorse di rete.

Nelle due figure seguenti vengono illustrate distribuzioni di esempio in cui i ruoli di server Web e server applicazioni vengono distribuiti in un ambiente virtuale.

In questo esempio è necessario tenere conto di quanto segue:

• Le risorse minime per CPU e RAM rappresentano i punti di partenza per la farm. Poiché sono riservati solo due core per ogni immagine virtuale, questo esempio si applica solo ad ambienti modello di prova o ad ambienti di distribuzione in cui le prestazioni non rappresentano un problema. Riservare risorse disponibili sufficienti da riallocare in base al monitoraggio delle prestazioni.

• SQL Server viene distribuito nei server fisici, anziché nei server virtuali.

• I server Web e i server applicazioni sono ridondanti nei due server host.

• Vengono distribuiti tre server Web nell'ambiente virtuale per garantire una disponibilità elevata.

• I controller di dominio Active Directory vengono distribuiti nei server fisici.

Per ambienti di testing e di produzione pilota, quattro core è il punto di partenza minimo consigliato per le macchine virtuali. Nell'ambiente virtuale seguente vengono utilizzate meno macchine virtuali per raggiungere questo obiettivo.

Questo esempio rappresenta un ambiente di partenza. Potrebbe essere necessario aggiungere risorse, a seconda del modello di utilizzo della farm.

Architetture virtuali di esempio per farm di medie e grandi dimensioni

Utilizzando server host di dimensioni maggiori, è possibile allocare più risorse per le immagini virtuali. Nella figura seguente viene illustrata un'implementazione di esempio in cui vengono utilizzate quantità maggiori di CPU e RAM.

Se i vantaggi della virtualizzazione di SQL Server superano gli effetti negativi prodotti sulle prestazioni, è possibile distribuire come guest anche SQL Server, come illustrato nella figura seguente.

In questo esempio è necessario tenere conto di quanto segue:

• In ogni host viene distribuita una sola istanza di SQL Server. In ambienti virtuali di piccole e medie dimensioni è consigliabile non distribuire più di un guest SQL Server per host.

• Entrambi i server host includono più memoria per soddisfare il numero di server virtuali, incluso SQL Server.

Se uno specifico ruolo di server utilizza un numero talmente elevato di risorse da influire negativamente sulle prestazioni globali dell'ambiente virtuale, valutare la possibilità di dedicare un server fisico a tale ruolo. A seconda dei modelli di utilizzo di un'organizzazione, tali ruoli possono includere server di ricerca per indicizzazione, il server che importa i profili, l'applicazione Excel Services o altri servizi utilizzati frequentemente. Nella figura seguente viene illustrato un esempio.

In questo esempio:

• SQL Server viene distribuito in server fisici. Rimuovere SQL Server dall'ambiente virtuale prima i rimuovere i ruoli di server applicazioni.

• Il ruolo di ricerca per indicizzazione viene distribuito in un server fisico. In alcuni ambienti è possibile che venga distribuito un ruolo diverso in un server fisico, a seconda dell'utilizzo.