Pianificare la disponibilità (Search Server 2008)

  • Articolo

Aggiornato: 2009-03-11

In questo articolo vengono descritti la disponibilità in generale, i costi e problemi di disponibilità in un ambiente Prodotti e tecnologie SharePoint e infine le strategie e le soluzioni che possono essere utilizzate in tale ambiente. È consigliabile leggere questo documento se la farm in uso esegue Server di ricerca 2008 Microsoft. Se lo si desidera, è possibile scaricare e stampare il modello di disponibilità di Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0x410 (informazioni in lingua inglese)) associato a questo articolo, in cui è disponibile un poster di riepilogo del contenuto.

Che cos'è la disponibilità

La disponibilità corrisponde al livello di disponibilità di un ambiente Prodotti e tecnologie SharePoint percepita dagli utenti. Garantire la disponibilità significa assicurare che un sistema sia stabile, ovvero che incidenti che influiscono sul servizio si verifichino raramente e che in caso di incidenti vengano prese in tempi brevi misure efficaci. Le strategie per la disponibilità consentono di minimizzare la percezione da parte degli utenti di tempo di inattività pianificato e non pianificato.

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

Nella tabella seguente i numeri di nove vengono correlati a 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

14,40 minuti

7 ore

3,65 giorni

99,9

86,40 secondi

43 minuti

8,77 ore

99,99

8,64 secondi

4 minuti

52,60 minuti

99,999

0,86 secondi

26 secondi

5,26 minuti

Se si è in grado di dedurre il numero previsto di possibili ore totali di tempo di inattività, è possibile utilizzare le formule seguenti per calcolare la percentuale di tempo di attività per un anno, un mese o una settimana:

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

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

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

Che cosa non è la disponibilità

La disponibilità non corrisponde né alla protezione e al ripristino dei dati né al ripristino di emergenza, benché tali concetti siano correlati e sia consigliabile prevedere piani di protezione dei dati e di ripristino di emergenza in qualsiasi sistema a disponibilità elevata. La protezione e il ripristino dei dati sono esigenze aziendali generali associate alle esigenze aziendali specifiche seguenti:

  • Mantenimento ed esame di più versioni di un elemento o un sito.

  • Ripristino di elementi o siti eliminati accidentalmente.

  • Archiviazione di dati per motivi legali, normativi o aziendali.

  • Ripristino dei sistemi in caso di errori hardware o software imprevisti.

La disponibilità non corrisponde inoltre alla gestione della continuità aziendale, ovvero alle decisioni, ai processi e agli strumenti aziendali predisposti anticipatamente per la gestione di eventuali crisi. Una crisi può essere un evento locale, regionale o nazionale oppure può essere relativa solo alla propria azienda.

Le strategie di gestione della disponibilità e della protezione dei dati di Prodotti e tecnologie SharePoint possono essere incluse nel piano tecnico per la gestione della continuità aziendale, ma è necessario che tale piano sia molto più completo e che includa gli elementi seguenti:

  • Procedure documentate in modo chiaro.

  • Archiviazione fuori sede di record aziendali chiave.

  • Contatti designati in modo chiaro.

  • Formazione continuativa del personale.

  • Meccanismi di ripristino fuori sede.

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 spesso prevedono operazioni complesse tra componenti software, ad esempio script personalizzati per il failover e il ripristino.

  • Ulteriore complessità operativa.

I costi relativi al raggiungimento della 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 diversi di disponibilità per siti diversi, servizi diversi, ad esempio per ricerca e business intelligence, oppure per farm diverse.

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

Nota

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

Problemi relativi alla disponibilità in Prodotti e tecnologie SharePoint

Una distribuzione di Prodotti e tecnologie SharePoint presenta le difficoltà seguenti per garantire disponibilità:

  • La farm non è disponibile durante l'applicazione di patch o l'aggiornamento della farm.

  • Non è possibile ottenere la ridondanza del server di indicizzazione mediante l'installazione del ruolo indice in più server. Per risolvere la perdita di un server di indicizzazione, sarà necessario reinstallare il server ed eseguire il ripristino da un backup oppure basarsi su risultati leggermente scadenti mentre viene ripetuta la ricerca per indicizzazione del contenuto. In alternativa, per ridurre il tempo necessario per ripristinare la ricerca, è possibile utilizzare una delle tecniche illustrate nella sezione Disponibilità della ricerca dopo il failover.

  • Prodotti e tecnologie SharePoint non è in grado di utilizzare il mirroring di SQL Server. Benché sia consigliabile utilizzare il mirroring di SQL Server come tecnica per la disponibilità, in questo modo viene richiesta automazione aggiuntiva.

Quando prendere in considerazione la disponibilità

È consigliabile prendere in considerazione i requisiti di disponibilità come parte della progettazione di base della soluzione di SharePoint. È inoltre possibile offrire disponibilità avanzata dopo la distribuzione della soluzione. A livello operativo è consigliabile distribuire e ottimizzare la soluzione di base in una farm e quindi verificare le soluzioni di disponibilità.

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, prendere in esame le considerazioni seguenti per il sito, il servizio o la farm.

  • Valutare se in caso di non disponibilità del sito, del servizio o della farm i dipendenti dell'organizzazione saranno comunque in grado di eseguire le attività previste dal proprio incarico.

  • Valutare se in caso di non disponibilità del sito, del servizio o della farm le transazioni aziendali e dei clienti verranno interrotte, con una conseguente perdita in termini di opportunità e di clienti.

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

Scegliere una strategia per la disponibilità

I numerosi approcci per il miglioramento della disponibilità tra cui è possibile scegliere includono:

  • Tolleranza di errore dei componenti.

  • Ridondanza e failover tra ruoli del server all'interno di una farm.

  • Ridondanza e failover tra server farm.

Requisiti di sistema per la disponibilità

In uno scenario ideale i componenti e i sistemi di failover corrispondono in modo completo ai componenti e ai sistemi primari come piattaforma, hardware e numero di server. È come minimo necessario che l'ambiente di failover sia in grado di gestire il traffico previsto durante un failover. Tenere presente che solo un sottoinsieme di utenti può essere soddisfatto dal sito di failover. I sistemi devono essere identici almeno per quanto riguarda gli elementi seguenti:

  • Versione del sistema operativo e relativi aggiornamenti

  • Versione di SQL Server e relativi aggiornamenti

  • Versione di Prodotti e tecnologie SharePoint e relativi aggiornamenti

Sebbene in questo articolo venga illustrata principalmente la disponibilità di Prodotti e tecnologie SharePoint, il tempo di attività del sistema verrà influenzato anche da altri componenti del sistema. È necessario prendere in considerazione in particolare quanto segue:

Tolleranza di errore dei componenti

In qualsiasi sistema è consigliabile collaborare con i fornitori di hardware per ottenere hardware con tolleranza di errore appropriato per il sistema, incluse le matrici RAID (Redundant Array of Independent Disks). Per suggerimenti, vedere Pianificare le prestazioni e le capacità (Windows SharePoint Services).

Durante la pianificazione della tolleranza di errore dei componenti è necessario prendere in considerazione i fattori seguenti:

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

  • Prendere in considerazione la ridondanza dei componenti per il ruolo del server di indicizzazione, poiché tale ruolo non può essere reso ridondante.

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

Ridondanza e failover tra ruoli del server all'interno di una farm

Prodotti e tecnologie SharePoint supporta l'esecuzione di ruoli del server in computer ridondanti, ovvero la scalabilità orizzontale, all'interno di una farm per incrementare la capacità, migliorare le prestazioni e offrire disponibilità di base. La capacità e le prestazioni determinano sia il numero di server che la dimensione dei server in una farm. Dopo avere soddisfatto i requisiti di base, è possibile aggiungere più server per aumentare la disponibilità complessiva del servizio.

Disponibilità in una farm a server singolo

Disponibilità farm singola

Nella tabella seguente vengono illustrati i server e i ruoli del server in un ambiente Prodotti e tecnologie SharePoint, come indicato nell'elenco nella pagina Servizi nel server del sito Web Amministrazione centrale SharePoint, e le strategie di base per la ridondanza che possono essere utilizzate per ogni server in una farm.

Servizi nel server Strategia di ridondanza di base preferita in una farm

SQL Server

Clustering o mirroring sincrono. Il clustering è più semplice da implementare, ma può essere più costoso.

Per ulteriori informazioni sull'utilizzo del mirroring sincrono, vedere Utilizzo del mirroring del database (Office SharePoint Server) (white paper).

Server Web

Eseguire la distribuzione in più server e bilanciare il carico utilizzando il bilanciamento del carico software o hardware.

Server Web per server farm di medie dimensioni (applicazione Web e servizi di query di ricerca)

Eseguire la distribuzione in più server.

Indicizzazione ricerca

Non può essere distribuita su più server ed essere ridondante. È necessario utilizzare una strategia per la disponibilità diversa. Per ulteriori informazioni, vedere Disponibilità della ricerca dopo il failover.

Calcolo Excel

Eseguire la distribuzione in più server.

Applicazione Project

Eseguire la distribuzione in più server.

Per ulteriori informazioni, vedere Pianificare la ridondanza (Office SharePoint Server).

Confronto tra 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 confrontati 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

Il mirroring viene eseguito immediatamente in caso di errore.

Il mirroring viene eseguito immediatamente in caso di errore.

Coerenza delle transazioni.

Coerenza delle transazioni.

Concorrenza delle transazioni.

Concorrenza delle transazioni.

Tempo di ripristino più breve (da pochi secondi ad alcuni minuti).

Tempo di ripristino leggermente superiore (da pochi secondi ad alcuni minuti).

L'errore viene rilevato automaticamente dai nodi di database. Prodotti e tecnologie SharePoint fa riferimento al cluster, quindi il failover dal punto di vista di Prodotti e tecnologie SharePoint è facile e automatico.

Per ottenere il failover di Prodotti e tecnologie SharePoint sono necessari script.

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

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

Richiede l'archiviazione condivisa, più costosa.

Può utilizzare l'archiviazione diretta, meno costosa.

Stessa subnet.

Fino a 1 millisecondo (ms) di latenza tra i server SQL Server e i server Web.

Può 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.

Necessita del modello di recupero con registrazione completa di SQL Server.

Nessun sovraccarico delle prestazioni.

Introduce la latenza transazionale e aggiunge l'overhead della memoria e del processore.

Carico operativo minimo.

Carico operativo aggiuntivo, inclusi gli script e la configurazione di alias di SQL Server.

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

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

  • In questo scenario è possibile garantire la ridondanza per i database utilizzando il mirroring sincrono. In una farm estesa è possibile eseguire il mirroring del database di configurazione e dei database del contenuto. Per un case study sull'utilizzo di una farm estesa da parte di un'azienda, vedere Case study di disponibilità elevata per SharePoint tramite il mirroring del database (white paper).

  • Rivolgersi al fornitore SAN per determinare se è possibile utilizzare la replica SAN o un altro meccanismo supportato per offrire la disponibilità fra data center, ad esempio SQL Server in esecuzione su cluster di server distribuiti geograficamente. Verificare che la soluzione di replica SAN offra un livello sufficiente di concorrenza e coerenza transazionale.

In una farm estesa è possibile offrire la tolleranza di errore per server applicazioni che eseguono provider di servizi condivisi se si dispone di:

  • Più server di query

  • Più server che eseguono Servizi di calcolo Excel

Il server di indicizzazione è un punto di errore singolo in questo scenario. È possibile eseguire il backup e ripristinare la ricerca oppure, se la disponibilità della ricerca al momento del ripristino è essenziale, utilizzare una farm di provider di servizi condivisi di failover. Per ulteriori informazioni, vedere Disponibilità della ricerca dopo il failover.

Farm "estesa"

Farm "estesa"

Ridondanza e failover tra data center con più farm

È possibile impostare una farm di failover per garantire la disponibilità in un data center separato dalla farm primaria. Un ambiente con una farm di failover separata ha le caratteristiche seguenti:

  • Nella farm di failover è necessario disporre di un database di configurazione separato e di un database del contenuto di Amministrazione centrale.

    Nota

    Se è stato configurato il mapping di accesso alternativo per la farm primaria, è particolarmente importante configurarlo in modo identico nella farm di failover.

  • Tutte le personalizzazioni devono essere distribuite in entrambe le farm.

  • Le patch devono essere applicate individualmente a entrambe le farm.

  • Solo i database del contenuto possono essere sottoposti correttamente a mirroring asincrono o a log shipping nella farm di failover.

  • È necessario che i database di cui è stato eseguito il mirroring o il log shipping siano impostati per l'utilizzo del modello di recupero con registrazione completa.

  • È possibile eseguire il backup e il ripristino dei database dei provider di servizi condivisi nella farm di failover.

Rivolgersi al fornitore SAN per determinare se è possibile utilizzare la replica SAN o un altro meccanismo supportato per garantire la disponibilità tra data center.

Questa topologia può essere ripetuta tra molti data center, se si configura il log shipping di SQL Server in uno o più data center aggiuntivi.

Nota

Il mirroring di SQL Server può essere utilizzato solo con un server mirror, ma è possibile eseguire il log shipping in più server secondari.

Farm primarie e di failover prima del failover

Farm primarie e di failover prima del failover

Nella tabella seguente vengono descritti i server e i ruoli del server in un ambiente Prodotti e tecnologie SharePoint e le strategie di ridondanza di base utilizzabili per ogni ruolo tra server farm.

Server o ruolo del server Strategia di ridondanza di base preferita tra farm

SQL Server

Mirroring asincrono di database di SQL Server, log shipping di SQL Server o un altro meccanismo di replica asincrona.

NotaNota:
Non utilizzabile per i database provider di servizi condivisi che ospitano informazioni di ricerca.

Server Web front-end

Eseguire la distribuzione in entrambe le farm, incluse le personalizzazioni.

Server Web per server farm di medie dimensioni (applicazione Web e servizi di query di ricerca)

Eseguire la distribuzione in entrambe le farm.

Indicizzazione ricerca

Eseguire la distribuzione in entrambe le farm. Ripristinare il backup dalla farm originale per passare alla farm di failover.

Calcolo Excel

Eseguire la distribuzione in entrambe le farm. Se il provider di servizi condivisi non ospita la ricerca, è possibile utilizzare il mirroring asincrono del database, il log shipping di SQL Server o un altro meccanismo di replica asincrona per spostare i dati in una farm di failover.

Se il provider di servizi condivisi ospita anche la ricerca, è necessario ripristinare il backup dalla farm originale per consentire lo spostamento.

Applicazione Project

Eseguire la distribuzione in entrambe le farm. Ripristinare il backup dalla farm originale per passare alla farm di failover.

Replica asincrona e ricerca

La ricerca necessita di sincronizzazione completa tra il database di ricerca, il database del provider di servizi condivisi e l'indice. A causa di tale requisiti, non è possibile replicare la ricerca tra farm utilizzando un meccanismo di replica asincrona (mirroring asincrono del database, log shipping o replica SAN asincrona). Per offrire la ricerca in una farm di failover, è necessario ripristinare il provider di servizi condivisi di ricerca.

Nota

Se si esegue un provider di servizi condivisi senza ricerca o Project, è possibile utilizzare un meccanismo di replica asincrona per spostare i dati.

Disponibilità della ricerca dopo il failover

Il ruolo di server di indicizzazione non può essere ridondante in una farm. Le esigenze dell'azienda in merito alla disponibilità della ricerca dopo il failover possono determinare l'architettura logica della soluzione.

  • Se nell'azienda non è necessario poter eseguire ricerche simultanee immediate e in qualsiasi momento dopo il failover, è possibile eseguire il backup e ripristinare il provider di servizi condivisi di ricerca nel sito di failover.

  • Se nell'azienda è necessario poter eseguire ricerche simultanee rapidamente e in qualsiasi momento, è possibile utilizzare una delle soluzioni seguenti:

  • Architettura con singola farm e due provider di servizi condivisi identici.

  • Una farm padre centralizzata che ospita la ricerca e altri provider di servizi condivisi. Il servizio di ricerca nella farm centrale esegue la ricerca per indicizzazione del contenuto in tutte le altre farm. Questa architettura può essere utilizzata per supportare una o più farm.

ImportanteImportante:

Se nell'azienda è necessario poter eseguire ricerche simultanee rapidamente e in qualsiasi momento e si utilizzano i profili, i profili nei provider di servizi condivisi di failover non vengono sincronizzati con quelli nei provider di servizi condivisi primari e rimarranno nello stato in cui si trovavano dopo l'importazione iniziale. Per mantenere sincronizzati i profili in tutti i provider di servizi condivisi, è necessario utilizzare il motore di replica dei profili utente incluso nel Toolkit di amministrazione della versione a 32 bit di SharePoint (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x410) (informazioni in lingua inglese) o nel Toolkit di amministrazione della versione a 64 bit di SharePoint (informazioni in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x410) (informazioni in lingua inglese) . Per ulteriori informazioni, vedere Motore di replica dei profili utente (Office SharePoint Server).

Singola farm con due provider di servizi condivisi

L'architettura seguente consente la protezione dall'errore di un server di indicizzazione. In questa topologia entrambi i provider di servizi condivisi eseguono la ricerca per indicizzazione dello stesso contenuto utilizzando le stesse regole. Il provider di servizi condivisi di failover non è collegato al sito Web primario, a meno che non si verifichi un failover.

Singola farm con due provider di servizi condivisi

Farm con due provider di servizi condivisi

Questa topologia presenta le limitazioni seguenti:

La possibilità di eseguire la ricerca per indicizzazione di set di dati di grandi dimensioni viene influenzata da diversi fattori, incluse la latenza e la larghezza di banda tra server di indicizzazione e server Web.

In un ambiente con larghezza di banda limitata, questa topologia può ridurre le prestazioni in modo significativo. La ripetizione della ricerca per indicizzazione comporta un carico aggiuntivo sugli archivi di contenuto in cui viene eseguita la ricerca e ciò può influire sulle prestazioni dell'archivio. È possibile che anche la capacità della ricerca di mantenere aggiornato l'indice venga influenzata negativamente.

Farm di provider di servizi condivisi centralizzate

Nell'architettura seguente l'utilizzo di una farm padre di provider di servizi condivisi consente di proteggere da errori in un server di indicizzazione. Sebbene possa sembrare una soluzione gravosa a livello di hardware, le farm di provider di servizi condivisi separate possono condividere hardware, ad esempio un server database con clustering o mirroring, purché i server di indicizzazione risiedano in server separati. Per ulteriori informazioni sulla pianificazione e la configurazione di farm di provider di servizi condivisi, vedere Pianificare l'architettura del provider di servizi condivisi.

Questa topologia presenta i vantaggi seguenti:

  • La gestione dei provider di servizi condivisi è centralizzata.

  • L'errore di una farm non richiede una nuova ricerca per indicizzazione.

Farm di provider di servizi condivisi centralizzate

Farm di failover di provider di servizi condivisi

Questa topologia presenta le limitazioni seguenti:

Esaminare attentamente i requisiti di disponibilità. 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.

I costi relativi al raggiungimento della 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 diversi di disponibilità per siti diversi, servizi diversi, ad esempio per ricerca e business intelligence, oppure per farm diverse.

Ringraziamenti

Il team responsabile della pubblicazione di contenuto relativo a Microsoft Office SharePoint Server ringrazia i revisori tecnici seguenti per avere collaborato a questo documento:

  • Bill Baer, Microsoft Online Services, Hosted SharePoint, technology architect

  • James Petrosky, Microsoft Consulting Services, consulente senior

  • Steve Peschka, Microsoft Consulting Services, architetto senior IW

  • Dan Winter, Servizio Supporto Tecnico Clienti Microsoft, responsabile dell'escalation

  • Sean Livingston, Prodotti e tecnologie Microsoft SharePoint, responsabile programma

  • Mike Watson, technology architect

  • Todd Carter, Microsoft Premier Field Engineering, Premier Field Engineer principale

  • Mike Plumley, Microsoft Office Project Server, autore

  • Christophe Fiessinger, Microsoft Office Project, responsabile tecnico senior del prodotto

  • Sid Shah, Microsoft Search, responsabile programma

  • Luca Bandinelli, Prodotti e tecnologie Microsoft SharePoint, responsabile programma