Pianificare la disponibilità (SharePoint Server 2010)

Si applica a: SharePoint Foundation 2010, SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono illustrate le decisioni chiave relative alla scelta delle strategie per la disponibilità per un ambiente Microsoft SharePoint Server 2010.

Mentre si valutano attentamente i propri requisiti di disponibilità, tenere presente che più sono elevati il livello di disponibilità e il numero dei sistemi da proteggere, più è probabile che sia complessa e costosa la soluzione per la disponibilità da adottare.

È probabile che non tutte le soluzioni in uso all'interno di un'organizzazione richiedano lo stesso livello di disponibilità. È possibile offrire livelli di disponibilità diversi per siti, servizi o farm diverse.

Contenuto dell'articolo:

• Panoramica della disponibilità

• Scelta di una strategia e di un livello di disponibilità

• Ridondanza e failover tra data center posizionati vicini e configurati come una singola farm (farm "estesa")

Panoramica della disponibilità

Per disponibilità si intende quanto un ambiente SharePoint Server viene percepito come disponibile dagli utenti. Un sistema disponibile è un sistema stabile in cui gli incidenti che influiscono sul servizio si verificano raramente e in cui, in caso di incidenti, vengono prese in tempi brevi misure efficaci.

La disponibilità rientra nella pianificazione della continuità aziendale ed è correlata al backup, al ripristino e al ripristino di emergenza. Per ulteriori informazioni su questi processi correlati, vedere Pianificare il backup e il ripristino in SharePoint Server 2010 e Pianificare il ripristino di emergenza (SharePoint Server 2010).

Una delle misure di disponibilità più comuni è la percentuale di tempo di attività espressa come numero di nove, ovvero la percentuale di tempo durante la quale un determinato sistema è attivo e funzionante. Un sistema con una percentuale di tempo di attività pari a 99,999 ad esempio ha cinque numeri nove di disponibilità.

Nella tabella seguente la percentuale di tempo di attività viene correlata ai periodi equivalenti del calendario.

Se si è in grado di dedurre con cognizione di causa quale sarà il probabile numero totale di ore di inattività all'anno, è possibile utilizzare le formule seguenti per calcolare la percentuale di tempo di attività per un anno, un mese o una settimana:

% tempo di attività/anno = 100 - (8760 - numero di ore di inattività totali all'anno)/8760

% tempo di attività/mese = 100 - ((24 × numero di giorni nel mese) - numero di ore di inattività totali in tale mese di calendario)/(24 × numero di giorni nel mese)

% tempo di attività/settimana = 100 - (168 - numero di ore di inattività totali in tale settimana)/168

Costi della disponibilità

La disponibilità è uno dei requisiti più costosi per un sistema. Maggiori sono il livello di disponibilità e il numero di sistemi da proteggere, maggiore sarà la probabilità che la soluzione per la disponibilità sia più complessa e costosa. Quando si effettua un investimento relativo alla disponibilità, i costi includono:

• Hardware e software aggiuntivi, che possono rendere più complesse le interazioni tra le applicazioni software e le impostazioni.

• Ulteriore complessità operativa.

I costi per ottenere una maggiore disponibilità devono essere valutati in base alle esigenze aziendali. È probabile che non tutte le soluzioni all'interno di un'organizzazione necessitino dello stesso livello di disponibilità. È possibile offrire livelli di disponibilità diversi per siti, servizi o farm diverse.

La disponibilità è un'area chiave nella quale i gruppi IT offrono contratti di servizio che consentono di definire le aspettative insieme ai gruppi di clienti. Molte organizzazioni IT offrono diversi tipi di contratti di servizio, associati a diversi livelli di addebito.

Determinazione dei requisiti di disponibilità

Per valutare la tolleranza dell'organizzazione in merito al tempo di inattività per un sito, un servizio o una farm, rispondere alle domande seguenti:

• Se il sito, il servizio o la farm non risulta disponibile, i dipendenti dell'organizzazione saranno in grado di svolgere i compiti previsti dal loro incarico?

• Se il sito, il servizio o la farm non risulta disponibile, le transazioni aziendali e dei clienti si interromperanno, con una conseguente perdita di opportunità di lavoro e di clienti?

In caso di risposta affermativa a una di queste domande, è consigliabile investire in una soluzione per la disponibilità.

Scelta di una strategia e di un livello di disponibilità

Tra le numerose strategie che è possibile scegliere per aumentare la disponibilità in un ambiente SharePoint Server vi sono le seguenti:

• Migliorare la tolleranza di errore dei componenti hardware server.

• Aumentare la ridondanza dei ruoli del server all'interno di una farm.

Tolleranza di errore dei componenti hardware

Per tolleranza di errore dei componenti hardware si intende la ridondanza dei componenti hardware e dei sistemi dell'infrastruttura, ad esempio di alimentazione a livello server. Durante la pianificazione della tolleranza di errore dei componenti hardware, considerare quanto segue:

• La ridondanza completa di ogni componente all'interno di un server potrebbe non essere possibile o potrebbe non essere fattibile. Utilizzare server aggiuntivi per ulteriore ridondanza.

• Verificare che i server dispongano di più alimentatori collegati a fonti di alimentazione diverse per la massima ridondanza.

In qualsiasi sistema è consigliabile collaborare con i fornitori di hardware per ottenere componenti con tolleranza di errore appropriati per il sistema, inclusi array RAID (Redundant Array of Independent Disks). Per suggerimenti, vedere Gestione di prestazioni e capacità (SharePoint Server 2010) e Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2010).

Ridondanza all'interno di una farm

SharePoint Server 2010 supporta l'esecuzione dei ruoli del server in computer ridondanti, ovvero la scalabilità orizzontale, all'interno di una farm per incrementare la capacità e offrire la disponibilità di base.

La capacità richiesta determina sia il numero di server che la dimensione dei server in una farm. Dopo avere soddisfatto i requisiti di capacità di base, è possibile aggiungere ulteriori server per aumentare la disponibilità complessiva. Nella figura seguente viene illustrato come è possibile fornire la ridondanza per ogni ruolo del server.

Disponibilità all'interno di una server farm

Nella tabella seguente vengono illustrati i ruoli del server in un ambiente SharePoint Server 2010 e le strategie per la ridondanza che possono essere utilizzate per ogni server di una farm.

Strategie per la disponibilità di database

La disponibilità di database in un ambiente SharePoint Server può essere garantita tramite il clustering di failover di Microsoft SQL Server o il mirroring a disponibilità elevata di SQL Server.

Clustering di failover di SQL Server

Il clustering di failover può garantire il supporto della disponibilità per un'istanza di SQL Server. Un cluster di failover è una combinazione di uno o più nodi o server con almeno due dischi condivisi. Un'istanza del cluster di failover viene visualizzata come un computer singolo, ma dispone di funzionalità in grado di fornire il failover da un nodo all'altro se quello corrente non è più disponibile. SharePoint Server può essere eseguito in qualsiasi combinazione di nodi attivi e passivi di un cluster supportato da SQL Server.

SharePoint Server fa riferimento al cluster in generale, pertanto il failover viene eseguito in modo agevole e automatico dal punto di vista di SharePoint Server.

Per informazioni dettagliate sul clustering di failover, vedere Introduzione al clustering di failover di SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x410) e Configure availability by using SQL Server clustering (SharePoint Server 2010).

Mirroring a disponibilità elevata di SQL Server

Il mirroring del database è una tecnologia di SQL Server in grado di garantire la ridondanza per i singoli database mediante l'invio diretto delle transazioni da un database e un server principali a un database e un server mirror quando il buffer del registro delle transazioni del database principale viene scritto su disco. Questa tecnica consente di mantenere il database mirror quasi del tutto aggiornato rispetto al database principale. SQL Server Enterprise Edition offre funzionalità aggiuntive che migliorano le prestazioni del mirroring del database. Per ulteriori informazioni, vedere Integrazione di SQL Server 2008 R2 e Prodotti SharePoint 2010 (white paper) (SharePoint Server 2010).

Per poter effettuare il mirroring all'interno di una farm di SharePoint Server, è necessario utilizzare il mirroring a disponibilità elevata, noto anche come modalità di protezione elevata con failover automatico, che prevede tre istanze di server, ovvero un server principale, un server mirror e un server di controllo. Quest'ultimo consente a SQL Server di eseguire automaticamente il failover dal server principale al server mirror. Il failover dal database principale al database mirror solitamente richiede qualche secondo.

Una differenza rispetto alle versioni precedenti è rappresentata dal fatto che SharePoint Server è in grado di riconoscere il mirroring. Dopo avere configurato un'istanza mirror del database di SQL Server, è necessario utilizzare Amministrazione centrale SharePoint oppure i cmdlet di Windows PowerShell per identificare il percorso del server di database (mirror) di failover per un database di configurazione, un database del contenuto o un database dell'applicazione di servizio. Impostando un percorso di database di failover, viene aggiunto un parametro alla stringa di connessione utilizzata da SharePoint Server per connettersi a SQL Server. Nel caso di un evento di timeout di SQL Server, si verifica quanto segue:

1. Il server di controllo configurato per il mirroring di SQL Server scambia automaticamente i ruoli del database primario e del database mirror.

2. SharePoint Server tenta automaticamente di contattare il server specificato come database di failover.

Per informazioni su come configurare il mirroring del database, vedere Configurare la disponibilità tramite il mirroring dei database di SQL Server (SharePoint Server 2010).

Per informazioni generali sul mirroring del database, vedere Mirroring del database (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x410).

Confronto delle strategie per la disponibilità di database per una singola farm - Clustering di failover di SQL Server e mirroring a disponibilità elevata di SQL Server

Nella tabella seguente vengono messi a confronto il clustering di failover e il mirroring sincrono a disponibilità elevata di SQL Server.

Strategie per la ridondanza per le applicazioni di servizio

La strategia per la ridondanza adottata per proteggere le applicazioni di servizio in esecuzione in una farm varia a seconda del percorso in cui l'applicazione di servizio archivia i dati.

Applicazioni di servizio che archiviano i dati all'esterno di un database

Per proteggere le applicazioni di servizio che archiviano i dati all'esterno di un database, installare tali applicazioni in più server applicazioni in modo da garantire la ridondanza all'interno dell'ambiente.

In questa versione di SharePoint Server, quando si installa un'applicazione di servizio in più server applicazioni, i processi timer vengono eseguiti in tutti i server applicazioni che eseguono l'istanza del servizio associata a tale applicazione di servizio oppure nel primo server disponibile. Nel caso si verifichino problemi su un server applicazioni, i processi timer in esecuzione in tale server verranno riavviati in un altro server quando è prevista l'esecuzione del processo timer successivo.

L'installazione di un'applicazione di servizio in più server applicazioni consente di mantenere in esecuzione l'applicazione, ma non garantisce che non si verifichino perdite di dati. Nel caso si verifichino problemi su un server applicazioni, le connessioni attive per tale server andranno perdute e gli utenti perderanno alcuni dati.

Le applicazioni di servizio seguenti archiviano i dati all'esterno di un database:

• Access Services

• Applicazione Excel Services

Applicazioni di servizio che archiviano i dati nei database

Per proteggere le applicazioni di servizio che archiviano i dati nei database, è necessario attenersi alla procedura seguente:

1. Installare il servizio in più server applicazioni per garantire la ridondanza all'interno dell'ambiente.

2. Configurare il clustering o il mirroring di SQL Server per proteggere i dati.

Le applicazioni di servizio seguenti archiviano i dati nei database:

• Applicazione del servizio di ricerca, comprendente i database seguenti:

  • Database di amministrazione della ricerca

  • Database di ricerca per indicizzazione

  • Database delle proprietà

    Nota

    Il mirroring dei database di ricerca è supportato, ma per garantire la ridondanza per la ricerca è necessario eseguire attività aggiuntive. Per informazioni dettagliate, vedere la sezione Search redundancy strategies within a farm.

• Servizio profili utente, comprendente i database seguenti:

  • Database dei profili

  • Database di social networking

  • Database di sincronizzazione

    Nota

    Il mirroring del database di sincronizzazione non è supportato.

• Applicazione del servizio di integrazione applicativa dei dati

• Applicazione del servizio Registro applicazioni

  Non è consigliabile applicare il mirroring al database del servizio Registro applicazioni, poiché viene utilizzato esclusivamente durante l'aggiornamento delle informazioni del Catalogo dati business di Microsoft Office SharePoint Server 2007 a SharePoint Server 2010.

• Applicazione del servizio per la raccolta dati di utilizzo e integrità

  Nota

  Non è consigliabile applicare il mirroring per il database di registrazione di tale applicazione.

• Applicazione del servizio metadati gestiti

• Applicazione del servizio di archiviazione sicura

• Applicazione del servizio informazioni sullo stato

• Applicazione di servizio Web Analytics, comprendente i database seguenti:

  • Database di report

  • Database dell'area di gestione temporanea

    Nota

    Il mirroring del database dell'area di gestione temporanea non è supportato.

• Applicazione del servizio Word Automation Services

• Servizio delle impostazioni di sottoscrizione di Microsoft SharePoint Foundation

• PerformancePoint Services

Strategie per la ridondanza della ricerca all'interno di una farm

Solo server

L'applicazione del servizio di ricerca rappresenta un caso speciale dal punto di vista della ridondanza all'interno di una farm. Nella figura seguente viene illustrato come è possibile configurare la ridondanza e il failover per un'applicazione del servizio di ricerca dedicata media che esegue la ricerca per indicizzazione per circa 40 milioni di elementi. Per ulteriori informazioni sull'architettura di tale applicazione, vedere "Architetture di ricerca per Microsoft SharePoint Server 2010" nell'articolo Diagrammi tecnici (SharePoint Server 2010).

Applicazione del servizio di ricerca ridondante

• Server di query. In tale server vengono ospitati i componenti di query e le partizioni di indice.

  • I componenti di query restituiscono i risultati di ricerca. Ognuno di questi componenti fa parte di una partizione di indice, la quale è associata a un database delle proprietà specifico contenente i metadati associati a un set specifico di contenuti sottoposti a ricerca per indicizzazione. È possibile rendere ridondante una partizione di indice aggiungendo componenti di query "mirror" a una partizione di indice e collocandoli in server diversi della farm.

    Nota

    Con il termine componenti di query mirror si indicano copie di file identiche e non il mirroring del database di SQL Server.

  • Le partizioni di indice sono gruppi di componenti di query, ognuno dei quali contiene un sottoinsieme dell'indice full-text e restituisce risultati di ricerca. Ogni partizione di indice è associata a un database delle proprietà specifico contenente i metadati associati a un set specifico di contenuti sottoposti a ricerca per indicizzazione. È possibile decidere quali server di una farm gestiranno le query creando un componente di query in tale server. Se si desidera bilanciare il carico di gestione delle query tra più server della farm, aggiungere componenti di query a una partizione di indice e associarli ai server da utilizzare per gestire le query. Per ulteriori informazioni, vedere Add or remove a query component. È possibile rendere ridondante una partizione di indice aggiungendo componenti di query mirror a una partizione di indice e collocandoli in server di query diversi.

• Server di ricerca per indicizzazione. In tale server vengono ospitati i componenti di ricerca per indicizzazione e un componente di amministrazione della ricerca.

  • I componenti di ricerca per indicizzazione elaborano le ricerche per indicizzazione eseguite nelle origini di contenuto, propagano i file di indice risultanti ai componenti di query e aggiungono informazioni relative al percorso e alla pianificazione della ricerca per indicizzazione per le origini di contenuto ai database di ricerca per indicizzazione associati. I componenti di ricerca per indicizzazione sono associati a una singola applicazione del servizio di ricerca. È possibile distribuire il carico di ricerca per indicizzazione aggiungendo tali componenti a server di ricerca per indicizzazione diversi. In un determinato server di questo tipo è possibile disporre di tanti componenti di ricerca per indicizzazione quanti sono consentiti dalle risorse. Se vi sono numerosi percorsi di contenuto, sarà possibile aggiungere componenti e database di ricerca per indicizzazione e dedicarli a contenuto specifico. È consigliabile associare ogni componente di ricerca di indicizzazione disponibile in un determinato server di ricerca per indicizzazione a un database di ricerca per indicizzazione distinto. Ai fini della ridondanza, è opportuno disporre di almeno due componenti di ricerca per indicizzazione. Ogni componente deve essere impostato in modo da eseguire la ricerca per indicizzazione in entrambi i database di ricerca per indicizzazione. Se un database supera i 25 milioni di elementi, è consigliabile aggiungere un nuovo database e un nuovo componente di ricerca per indicizzazione.

  • Il componente di amministrazione della ricerca monitorizza le azioni utente in ingresso e aggiorna il database di amministrazione della ricerca. Per ogni applicazione del servizio di ricerca è consentito un solo componente di amministrazione della ricerca. Tale componente può essere eseguito in qualsiasi server, preferibilmente un server di ricerca per indicizzazione o un server di query.

• Server di database. In tali server vengono ospitati i database di ricerca per indicizzazione, i database delle proprietà, il database di amministrazione della ricerca e altri database di SharePoint Server 2010.

  • Database di ricerca per indicizzazione

    Nei database di ricerca per indicizzazione sono contenuti i dati relativi al percorso delle origini di contenuto, alle pianificazioni della ricerca per indicizzazione e altre informazioni specifiche delle operazioni di ricerca per indicizzazione per una determinata applicazione del servizio di ricerca. È possibile distribuire il carico dei database aggiungendo database di ricerca per indicizzazione a computer diversi in cui sia in esecuzione SQL Server. I database di ricerca per indicizzazione sono associati ai componenti di ricerca per indicizzazione e possono essere dedicati a host specifici mediante la creazione di regole di distribuzione host. Per ulteriori informazioni sui componenti di ricerca per indicizzazione, vedere Add or remove a crawl component (SharePoint Server 2010). Per ulteriori informazioni sulle regole di distribuzione host, vedere Add or remove a host distribution rule. I database di ricerca per indicizzazione sono ridondanti se vi viene applicato il mirroring o se vengono distribuiti in un cluster di failover di SQL Server.

  • Database delle proprietà

    Nei database delle proprietà sono contenuti i metadati associati al contenuto sottoposto a ricerca per indicizzazione. È possibile distribuire il carico di query dei database aggiungendo database delle proprietà a computer diversi in cui sia in esecuzione SQL Server. I database delle proprietà sono associati alle partizioni di indice e restituiscono gli eventuali metadati associati al contenuto nei risultati delle query.

    I database delle proprietà sono ridondanti se vi viene applicato il mirroring o se vengono distribuiti in un cluster di failover di SQL Server.

  • Database di amministrazione della ricerca

    Vi è un solo database di amministrazione della ricerca per ogni istanza dell'applicazione del servizio di ricerca disponibile in una farm.

    Il database di amministrazione della ricerca è ridondante solo se vi viene applicato il mirroring o se viene distribuito in un cluster di failover di SQL Server.

Per ulteriori informazioni sulla ridondanza della ricerca, vedere Manage search topology (SharePoint Server 2010).

Ridondanza e failover tra data center posizionati vicini e configurati come una singola farm (farm "estesa")

Alcune aziende dispongono di data center posizionati vicini con connessioni con larghezza di banda elevata che possono essere quindi configurati come una singola farm. Tale farm viene definita farm "estesa". Per il corretto funzionamento di una farm estesa, sono necessarie una latenza inferiore a 1 millisecondo tra SQL Server e i server Web front-end in una direzione e una larghezza di banda pari almeno a 1 gigabit al secondo.

In questo scenario è possibile assicurare la tolleranza di errore seguendo le indicazioni standard per rendere ridondanti i database e le applicazioni di servizio.

Nella figura seguente viene illustrata una farm estesa.

Farm estesa