Pianificare la disponibilità (SharePoint Foundation 2010)

  • Articolo

 

Si applica a: SharePoint Foundation 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono illustrate le decisioni chiave relative alla scelta delle strategie di disponibilità per un ambiente Microsoft SharePoint Foundation 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 di 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 Foundation 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 gestione 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 (SharePoint Foundation 2010) e Pianificare il ripristino di emergenza (SharePoint Foundation 2010).

Nota

Durante il calcolo della disponibilità, la maggior parte delle organizzazioni esclude o aggiunge in modo specifico ore per le attività di manutenzione pianificate.

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.

Percentuale di tempo di attività accettabile Tempo di inattività al giorno Tempo di inattività al mese Tempo di inattività all'anno

95

72,00 minuti

36 ore

18,26 giorni

99 (due nove)

14,40 minuti

7 ore

3,65 giorni

99,9 (tre nove)

86,40 secondi

43 minuti

8,77 ore

99,99 (quattro nove)

8,64 secondi

4 minuti

52,60 minuti

99,999 (cinque nove)

0,86 secondi

26 secondi

5,26 minuti

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 in tale mese) - numero di ore di inattività totali nel 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:

  • Componenti hardware e software aggiuntivi, che spesso comportano una maggiore complessità delle interazioni tra le applicazioni software e le impostazioni.

  • Maggiore 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 Foundation 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).

Ridondanza all'interno di una farm

SharePoint Foundation 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

Disponibilità farm singola

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

Ruolo del server Strategia per la ridondanza preferita in una farm

Server Web front-end

Distribuire più server Web front-end all'interno di una farm e utilizzare Bilanciamento carico di rete.

Server applicazioni

Distribuire più server applicazioni all'interno di una farm.

Server di database

Distribuire i server di database mediante il clustering o il mirroring del database a disponibilità elevata.

Strategie per la disponibilità di database

La disponibilità di database in un ambiente SharePoint Foundation 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 garantisce 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 Foundation può essere eseguito in qualsiasi combinazione di nodi attivi e passivi di un cluster supportato da SQL Server.

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

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 Foundation 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 poter effettuare il mirroring all'interno di una farm di SharePoint Foundation, è 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 Foundation è 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 Foundation 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 Foundation tenta automaticamente di contattare il server specificato come database di failover.

Per informazioni su come configurare il mirroring del database, vedere Configure availability by using SQL Server database mirroring (SharePoint Foundation 2010).

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

Nota

Per i database configurati per utilizzare il provider di Archiviazione BLOB remoti FILESTREAM di SQL Server non è possibile applicare il mirroring.

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.

Clustering di failover di SQL Server Mirroring a disponibilità elevata di SQL Server

Tempo necessario per il failover

Il membro del cluster subentra immediatamente in caso di errore.

L'elemento mirror subentra immediatamente in caso di errore.

Coerenza delle transazioni?

Sì

Sì

Concorrenza delle transazioni?

Sì

Sì

Tempo necessario per il ripristino

Tempo di ripristino più breve (millisecondi).

Tempo di ripristino leggermente superiore (millisecondi).

Operazioni necessarie per il failover?

L'errore viene rilevato automaticamente dai nodi di database. SharePoint Foundation 2010 fa riferimento al cluster, quindi il failover è facile e automatico.

L'errore viene rilevato automaticamente dal database. SharePoint Foundation 2010 riconosce il percorso mirror, se configurato correttamente, in modo che il failover sia automatico.

Protezione da errori di archiviazione?

Non protegge da errori di archiviazione, poiché quest'ultima è condivisa tra i nodi del cluster.

Protegge da errori di archiviazione, poiché sia il server di database principale che il server di database mirror scrivono su dischi locali.

Tipi di archiviazione supportati

Richiede l'archiviazione condivisa, più costosa.

Può utilizzare l'archiviazione DAS (Direct-Attached Storage), meno costosa.

Requisiti per il percorso

I membri del cluster devono trovarsi nella stessa subnet.

Il server principale, il server mirror e il server di controllo devono trovarsi nella stessa rete LAN (round trip con latenza fino a 1 millisecondo).

Modello di recupero

È consigliato il modello di recupero con registrazione completa di SQL Server. È possibile utilizzare il modello di recupero con registrazione minima di SQL Server, sebbene l'unico punto di ripristino disponibile in caso di perdita del cluster sarà l'ultimo backup completo.

Richiede il modello di recupero con registrazione completa di SQL Server.

Overhead delle prestazioni

Durante un failover può verificarsi un calo delle prestazioni.

Il mirroring a disponibilità elevata introduce la latenza transazionale perché è sincrono. Richiede inoltre ulteriore overhead della memoria e del processore.

Carico operativo

Impostato e gestito a livello di server.

Il carico operativo è superiore rispetto al clustering. Deve essere impostato e gestito per tutti i database. La riconfigurazione dopo il failover è manuale.

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 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 integrazione applicativa dei dati

  • Applicazione del servizio Registro applicazioni

    Non è consigliabile applicare il mirroring per il database del servizio Registro applicazioni perché viene utilizzato esclusivamente durante l'aggiornamento delle informazioni del Catalogo dati business di Windows SharePoint Services 3,0 a SharePoint Foundation 2010.

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

    Nota

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

  • Servizio impostazioni di sottoscrizione di Microsoft SharePoint Foundation

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

Farm "estesa"