Pianificare l'ambiente per la disponibilità (Office SharePoint Server)

  • Articolo

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 Microsoft Office SharePoint Server 2007. Se lo si desidera, è possibile scaricare e stampare il modello di disponibilità di Office SharePoint Server 2007 (informazioni in lingua inglese) (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 di questo articolo.

Panoramica della 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 ai periodi equivalenti del calendario.

Percentuale accettabile di tempo di attività 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 in modo informato il numero previsto di possibile 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 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 di dati sono esigenze aziendale 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 inavvertitamente.

  • 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 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.

  • Memorizzazione fuori sede dei 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 coinvolgono operazioni complesse tra il software, ad esempio gli script personalizzati per il failover e 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 diversi siti, diversi servizi, ad esempio per ricerca e business intelligence, oppure per diverse farm.

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 i problemi seguenti per l'offerta di 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 nelle sezioni Disponibilità della ricerca all'interno di una farm e Disponibilità della ricerca tra farm.

  • Prodotti e tecnologie SharePoint non è in grado di utilizzare il mirroring del database di Microsoft SQL Server 2005. Benché sia consigliabile utilizzare il mirroring di SQL Server come tecnica per la disponibilità per SharePoint, ciò comporta un'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 la 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, rispondere alle domande seguenti per il sito, il servizio o la farm.

  • Se il sito, il servizio o la farm non risulta disponibile, i dipendenti dell'organizzazione saranno in grado di eseguire le responsabilità previste dal proprio incarico?

  • Se il sito, il servizio o la farm non risulta disponibile, le transazioni aziendali e dei clienti verranno interrotte, comportando una perdita di opportunità e di clienti?

In caso di risposta affermativa a una di queste domande, è 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 e database 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, dalla piattaforma, all'hardware e al numero di server. È come minimo necessario che l'ambiente di failover sia in grado di gestire il traffico previsto durante un failover. È necessario 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 e tutti gli aggiornamenti del sistema operativo

  • Versione e tutti gli aggiornamenti di SQL Server

  • Versione e tutti gli aggiornamenti di Prodotti e tecnologie SharePoint

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:

Disponibilità all'interno di una farm

Per supportare la disponibilità all'interno di una farm, eseguire la pianificazione in modo da disporre di componenti a tolleranza di errore, ruoli del server ridondanti e supporto della disponibilità di database mediante clustering, mirroring del database o entrambe le tecnologie.

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, inclusi array RAID (Redundant Array of Independent Disks). Per suggerimenti, vedere Pianificare le prestazioni e la capacità (Office SharePoint Server).

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 potrebbe non essere fattibile. Utilizzare server aggiuntivi per la 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 più alimentatori collegati a origini di alimentazione diverse per 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 aver soddisfatto i requisiti di base, è possibile aggiungere più server per aumentare la disponibilità complessiva del servizio.

Ridondanza in una farm a server singolo

Disponibilità farm singola

Nella tabella seguente vengono illustrati i servizi 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

Server Web

Distribuire su 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 all'interno di una farm.

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).

Strategie per la disponibilità di database per una singola farm

La disponibilità di database all'interno di una farm può essere garantita tramite il clustering o il mirroring a disponibilità elevata, ovvero il mirroring sincrono, di SQL Server.

Clustering Il clustering di failover garantisce il supporto della disponibilità per un'intera 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.

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

Mirroring sincrono del database Il mirroring del database garantisce il supporto della disponibilità mediante l'invio diretto di transazioni da un database e un server principali a un database e un server mirror ogni volta che il buffer del registro delle transazioni del database principale viene scritto su disco. È consigliabile utilizzare il mirroring del database a disponibilità elevata, o 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.

Ogni tecnologia presenta vantaggi e svantaggi. Il clustering è più semplice da implementare, ma può essere più costoso. Il mirroring di SQL Server non è supportato per i database di Microsoft Office Project Server 2007.

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 memorizzazione, poiché la memorizzazione è 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.

Necessita di archiviazione condivisa più costosa.

Può utilizzare l'archiviazione diretta, meno costosa.

Stessa subnet.

Fino a 1 millisecondi (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 overhead 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.

Per ulteriori informazioni sull'utilizzo del clustering, vedere Configurare la disponibilità in una sola farm mediante il clustering di SQL Server.

Per ulteriori informazioni sull'utilizzo del mirroring sincrono, vedere Configurare la disponibilità in una sola farm tramite mirroring del database di SQL Server e Utilizzo del mirroring del database (Office SharePoint Server) (white paper).

Ridondanza e failover tra data center posizionati 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 offrire la ridondanza per i database di SharePoint 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 applicazione 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 è molto importante, utilizzare una farm di provider di servizi condivisi di failover. Per ulteriori informazioni, vedere Disponibilità della ricerca all'interno di una farm.

Project Server è un altro punto di errore singolo in questo scenario. Pianificare il backup e il ripristino dei database di Project Server.

Farm "estesa"

Farm "estesa"

Disponibilità della ricerca all'interno di una farm

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

Se l'azienda non necessita di attualità e disponibilità immediata della ricerca dopo il failover, è possibile eseguire il backup e ripristinare il provider di servizi condivisi di ricerca nel sito di failover.

Se l'azienda necessita di attualità e disponibilità rapida della ricerca, è possibile utilizzare uno dei metodi seguenti:

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

    Nota

    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).

  • 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.

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 tempestivamente 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 dell'esecuzione 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 che si tratti di 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 rende obbligatorio alcuna 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:

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:

  • È necessario mantenere nella farm di failover un database di configurazione separato e 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.

  • È possibile eseguire correttamente il mirroring asincrono solo dei database del contenuto o eseguire il log shipping di tali database alla 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, inclusi i database di Microsoft Office Project 2007, nella farm di failover.

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

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

Nota

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

Farm primarie e di failover prima del failover

Farm primarie e di failover prima del failover

Nella tabella seguente vengono elencati i servizi 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.

Nota

Non può essere utilizzato per i database dei provider di servizi condivisi che contengono informazioni per la ricerca, né per i database di Project Server.

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.

Disponibilità della ricerca tra farm

La ricerca richiede la sincronizzazione completa tra il database di ricerca, il database del provider di servizi condivisi e l'indice. A causa di tale requisito, non è possibile replicare la ricerca tra farm utilizzando un meccanismo di replica asincrona, ovvero mirroring asincrono del database, log shipping o replica SAN asincrona.

Nota

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

Per garantire la ricerca in una farm di failover, è necessario utilizzare uno dei metodi seguenti:

  • Ripristinare un backup del provider di servizi condivisi per la ricerca nella farm di failover.

  • Utilizzare una farm padre centralizzata che ospiti la ricerca e altri provider di servizi condivisi. Il servizio di ricerca nella farm centrale esegue la ricerca per indicizzazione nel contenuto di tutte le altre farm.

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 diversi siti, diversi servizi, ad esempio per ricerca e business intelligence, oppure per diverse farm.

Riconoscimenti

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

  • Bill Baer, Servizi Microsoft Online, Hosted SharePoint, architetto di tecnologia

  • James Petrosky, Servizi Microsoft Consulting, consulente senior

  • Steve Peschka, Servizi Microsoft Consulting, architetto senior IW

  • Dan Winter, Servizio Supporto Tecnico Clienti Microsoft, ingegnere escalation

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

  • Mike Watson, architetto di tecnologia

  • Todd Carter, Microsoft Premier Field Engineering, ingegnere principale di Premier Field

  • Mike Plumley, Microsoft Office Project Server, scrittore

  • 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

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

Vedere anche

Concetti

Configurare un'elevata disponibilità (Office SharePoint Server)