Procedure consigliate per l'eccellenza operativa (SharePoint Foundation 2010)

SharePoint 2010
 

Si applica a: SharePoint Foundation 2010

Ultima modifica dell'argomento: 2016-11-30

Microsoft SharePoint Foundation 2010 viene utilizzato per un'ampia gamma di applicazioni e soluzioni, autonomamente o insieme ad altri sistemi. Per assicurare questa flessibilità, la piattaforma supporta numerose architetture e configurazioni possibili. Alcune parti del sistema sono note, ma sono presenti anche varianti di tali parti. In questo articolo vengono descritte le parincipali procedure di configurazione consigliate che è opportuno tenere in considerazione, quali configurazione di server Web front-end, configurazione di database, manutenzione e applicazione di patch.

Questo articolo fa parte di una serie di articoli relativi alle procedure consigliate per SharePoint Foundation 2010. Contiene una descrizione delle procedure consigliate per ottenere un funzionamento ottimale. Per altri articoli della serie, vedere Procedure consigliate (SharePoint Foundation 2010). Per ulteriori informazioni e risorse sulle procedure consigliate per SharePoint Foundation 2010, vedere il Centro Risorse sulle procedure consigliate (http://go.microsoft.com/fwlink/?linkid=221383&clcid=0x410).

Per ottenere le prestazioni desiderate da un ambiente, utilizzare una quantità elevata di memoria sui server Web e sui server applicazioni.

Anche la velocità della rete è importante per le prestazioni dell'ambiente. Per fare in modo che il traffico sia veloce, eseguire le operazioni seguenti:

  • Utilizzare schede di rete gigabit per tutti i ruoli server.

  • Per i server Web front-end e i server applicazioni, utilizzare due schede di rete negli ambienti di produzione, una per gli utenti e una per le comunicazioni con Microsoft SQL Server.

  • Utilizzare schede di rete private per le comunicazioni tra server per attività quali la gestione e i backup, affinché questo traffico non incida sulle prestazioni complessive della farm.

  • In presenza di un carico elevato, è consigliabile utilizzare reti locali virtuali (VLAN) per ridurre il traffico di rete.

Per ulteriori informazioni, vedere Requisiti hardware e software (SharePoint Foundation 2010) e Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Foundation 2010).

Nessun server Web front-end o server applicazioni dovrà trovarsi a più di un millisecondo (ms) di latenza dal server di database. In pratica, questo significa in generale che tutti i server di una farm devono trovarsi nello stesso data center. Tutti i server di una farm devono essere impostati sullo stesso fuso orario.

La configurazione di server Web e server applicazioni può avere un forte impatto su velocità effettiva e affidabilità. Di seguito sono riportati consigli utili per ottenere risultati ottimali:

  • Separare i componenti di sistema in unità logiche e utilizzare RAID per la ridondanza.

     

    Componenti su unità Livello RAID consigliato

    Unità Windows e file di programma

    RAID 1

    Unità di scambio del sistema operativo e directory Temp

    RAID 1

    File di registro

    RAID 1

    Disco di avvio per la creazione dell'immagine e Windows Desktop Search (facoltativo)

    RAID 1

  • Utilizzare almeno quattro dischi fisici e utilizzare dischi separati per mantenere i file di registro e l'unità di scambio separati dall'unità Windows e dei file di programma.

  • Nella maggior parte degli ambienti di produzione è consigliabile allocare almeno 200 GB di spazio su disco per il sistema operativo e i file temporanei e 150 GB di spazio su disco per i registri.

  • Verificare la capacità del Web e fornire server sufficienti per il numero di utenti e richieste nella farm. Per la disponibilità elevata, allocare un server aggiuntivo in modo da poter estrarre un server da una server farm con bilanciamento del carico di rete e riciclarlo senza incidere sulla disponibilità del servizio.

Per ulteriori informazioni, vedere Pianificare la disponibilità (SharePoint Foundation 2010).

Come per i server Web e i server applicazioni, la configurazione dei server di database incide sulle prestazioni di SharePoint Foundation 2010. Alcuni database devono condividere il percorso con altri database, mentre alcuni altri devono essere separati da altri database.

I database elencati nella tabella seguente devono essere mantenuti separati da altri database.

 

Nome del database Dimensioni Ottimizzazione lettura/scrittura Posizione condivisa

TempDB

Medio

Deve trovarsi su un disco fisico separato da tutti gli altri database.

Archiviazione sicura

Piccolo

Ospitato su un'istanza di database separata. Accesso limitato a un amministratore.

Utilizzo

Molto grande

Ottimizzazione per la scrittura

Deve trovarsi su un disco fisico separato.

NotaNote
Il database di utilizzo può essere su un server separato e non necessita di prestazioni elevate come altri database. La velocità del database di utilizzo non influisce sulle prestazioni del sito.

I database nella tabella seguente devono essere memorizzati nello stesso percorso di altri database.

 

Nome del database Dimensioni Posizione condivisa

Configurazione

Contenuto Amministrazione centrale

Piccolo

Devono trovarsi nella stessa posizione

ReportServer di SQL Server

ReportServerTempDB

Piccolo

Variabile

Devono trovarsi sullo stesso server di database

Per ulteriori informazioni sulle dimensioni di database e il mix di lettura/scrittura per specifici database, vedere il modello di database che supportano i Prodotti SharePoint 2010(http://go.microsoft.com/fwlink/?linkid=187970&clcid=0x410).

Un server database integro è in grado di contenere database e file di registro e contemporaneamente rispondere alle richieste. Attenersi ai consigli contenuti nell'elenco seguente per garantire prestazioni ottimali dei database.

  • Espandere preventivamente tutti i database e i registri, se possibile. Tenere sotto controllo le dimensioni per non rischiare di esaurire lo spazio disponibile.

  • Non sovraccaricare i server di database con troppi database o dati. Attenersi alle linee guida seguenti:

    • Se si utilizza il mirroring di SQL Server, non archiviare più di 50 database su una sola istanza fisica di SQL Server.

    • Limitare i database del contenuto a 200 GB.

  • Deframmentare e ricostruire gli indici ogni giorno, se il tempo di inattività necessario per la ricostruzione è accettabile.

  • Monitorare il server database per verificare che risponda correttamente e non sia sovraccarico. I contatori delle prestazioni chiave da monitorare includono:

    • Coda di attesa in rete: 0 o 1 per buone prestazioni

    • Lunghezza media della coda del disco (latenza): inferiore a 5 ms

    • Memoria utilizzata: inferiore al 70%

    • Spazio libero su disco: superiore al 25%

    • Percentuale riscontri cache buffer: 90% o superiore

Per ulteriori informazioni, vedere le risorse seguenti:

È importante mantenere i server aggiornati applicando gli hotfix, gli aggiornamenti e i Service Pack più recenti. Questi aggiornamenti possono contenere miglioramenti importanti del prodotto. Eseguire comunque un test approfondito degli aggiornamenti negli ambienti di pre-produzione prima di applicarli negli ambienti di produzione. Seguire la procedura consigliata per la distribuzione degli aggiornamenti, che include quanto segue:

  • Attivare Windows Update per scaricare automaticamente gli aggiornamenti, ma non installarli in modo automatico.

  • Pianificare l'installazione degli aggiornamenti in orari con carichi di lavoro ridotti.

  • Per garantire disponibilità elevata, durante l'aggiornamento portare i server fuori servizio uno alla volta.

Verificare che vengano applicate patch per il BIOS (computer server, controller e dischi), per il sistema operativo Windows, per Microsoft SharePoint Foundation 2010 e SQL Server.

Per ulteriori informazioni, vedere il Centro Risorse sugli aggiornamenti per i prodotti SharePoint 2010 (http://go.microsoft.com/fwlink/?linkid=209614&clcid=0x410).

Utilizzare gli account appropriati per le applicazioni e i servizi Web. È consigliabile che tutti gli account siano account di dominio e che non venga utilizzato Servizio di rete. Per risultati ottimali, utilizzare account separati per quanto segue:

  • Applicazioni Web: utilizzare account diversi in base ai requisiti di sicurezza.

  • Account per la ricerca: utilizzare un account per la farm.

SharePoint Foundation 2010 utilizza molti altri account, ad esempio gli account dei servizi di SQL Server, l'identità del pool di applicazioni di Amministrazione centrale, gli account del servizio Timer di SharePoint Foundation, l'account di accesso al contenuto predefinito, l'account Single Sign-on e l'account per l'importazione dei profili. Seguire le procedure consigliate per mantenere aggiornate le password e verificare che i servizi funzionino.

Per ulteriori informazioni, vedere Change passwords used for administration accounts (SharePoint Foundation 2010).

In linea generale, per i backup è preferibile utilizzare un disco locale, anziché un'unità di rete, e quindi copiare i dati in seguito. Se possibile, utilizzare la compressione per i backup, prestando attenzione a non sovraccaricare SQL Server. Ad esempio, LiteSpeed per SQL Server esegue la compressione durante il backup e questo può compromettere le prestazioni di SQL Server.

Per i database di grandi dimensioni, eseguire backup incrementali, ad esempio quelli disponibili con System Center Data Protection Manager (DPM) 2010. Non eseguire backup completi come meccanismo primario, in quanto le dimensioni sarebbero troppo elevate per garantire un ripristino rapido.

Per ulteriori informazioni, vedere Backup and recovery best practices (SharePoint Foundation 2010).

Non limitarsi a eseguire il backup dei dati, ma includere anche i file di registro. Per un ripristino completo dell'ambiente è necessario eseguire il backup anche dei registri dei dati di utilizzo, dei registri di IIS, dei registri delle transazioni e dei registri della posta elettronica SMTP. Per i registri delle transazioni, eseguire il backup e il troncamento del file di registro ogni cinque minuti. Non ridurre mai le dimensioni del registro delle transazioni in quanto si potrebbero verificare problemi di prestazioni durante il nuovo aumento di dimensioni del registro.

Per ulteriori informazioni, vedere Back up or archive logs (SharePoint Foundation 2010) e Arresto della crescita imprevista del registro delle transazioni di un database SQL Server (http://go.microsoft.com/fwlink/?linkid=111458&clcid=0x410).

Verificare periodicamente i backup e controllarne la coerenza. Non dare per scontato che il backup funzionerà al momento del bisogno, ma garantire che questo succederà. Eseguire operazioni di ripristino per convalidare il contenuto del backup e accertarsi di poter ripristinare l'intero ambiente. Nel caso di ambienti distribuiti in più aree geografiche, prepararsi per un ripristino di emergenza configurando una farm remota. È quindi possibile ripristinare l'ambiente utilizzando il comando di collegamento di database per caricare una copia del database nella farm remota e reindirizzare gli utenti. Analogamente, è possibile configurare un ambiente di standby in cui venga eseguita la stessa versione del software dell'ambiente di produzione, in modo da poter ripristinare i database e recuperare i documenti rapidamente. Mantenere dimensioni ridotte dei database per velocizzare il ripristino.

Per ulteriori informazioni, vedere Procedural best practices.

Se si utilizza DPM 2010 per il backup e il ripristino, pianificare il backup e il ripristino delle applicazioni di servizio separatamente. DPM 2010 non consente di eseguire il backup del servizio di ricerca o di altre applicazioni di servizio.

Per ulteriori informazioni, vedere Scegliere gli elementi da proteggere e ripristinare nell'ambiente e il white paper sulla protezione di SharePoint con DPM 2010 (http://go.microsoft.com/fwlink/?linkid=218153&clcid=0x410).

Il team addetto alla pubblicazione di contenuto per SharePoint Foundation 2010 ringrazia le persone seguenti che hanno contribuito all'articolo:

  • Aaron Saikovski, Microsoft Consulting Services

  • Ali Mazaheri, Microsoft Consulting Services

  • Bryan Porter, Microsoft Consulting Services

  • Chris Holder, Microsoft SharePoint Customer Engineering

  • Dan Winter, Microsoft SharePoint Customer Engineering

  • Eric Charran, Microsoft Consulting Services

  • Gus Apostol, Microsoft SQL Server Customer Programs

  • John S. Moh, Microsoft Consulting Services

  • Luca Bandinelli, Microsoft SharePoint Customer Engineering

  • Rahim Dossa, Microsoft Consulting Services

  • Steve Peschka, Microsoft Consulting Services

  • Steve Walker, Microsoft SharePoint Customer Engineering

  • Tajeshwar Singh, Microsoft Consulting Services

Mostra: