Riprogettare la topologia di ricerca aziendale per altri contenuti e utenti in SharePoint
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Nel corso del tempo la maggior parte degli ambienti di ricerca aumenta, sia in quantità di contenuto che in numero di utenti. A un certo punto l'ambiente di ricerca ha superato la capacità e le prestazioni dell'architettura di ricerca. La soluzione consiste nel ridimensionare la topologia dell'architettura di ricerca:
Riprogettare la topologia (questo articolo)
Implementare la topologia riprogettata (Gestire la topologia di ricerca in SharePoint Server)
Si ha familiarità con i componenti del sistema di ricerca in SharePoint Server e con come interagiscono? Leggendo Panoramica dell'architettura di ricerca in SharePoint Server e architetture di ricerca per SharePoint Server 2016 (o Architetture di ricerca per SharePoint Server 2013) prima di iniziare, si acquisirà familiarità con l'architettura di ricerca, i componenti di ricerca, i database di ricerca e la topologia di ricerca.
Questo articolo illustra in modo dettagliato come riprogettare la topologia di ricerca.
Passaggio 1: determinare la quantità di contenuto disponibile
Passaggio 2: determinare le dimensioni a cui scalare l'architettura di ricerca
Dopo aver effettuato questi passaggi, si avranno le seguenti informazioni:
Il numero di ciascun tipo di componente e database di ricerca richiesto dalla topologia.
In quali server applicazioni e server di database distribuire ogni componente di ricerca.
Quali risorse hardware sono richieste da ogni server applicazioni e server di database.
Passaggio 1: determinare la quantità di contenuto disponibile
Il volume di contenuto incluso nell'indice di ricerca influisce sulle risorse necessarie per ospitare la farm. Verificare quanti elementi sono ricercabili nell'ambiente di ricerca esistente. Questo numero è disponibile nella pagina Amministrazione ricerca nel sito Web Amministrazione centrale SharePoint. Per aprire la pagina di amministrazione della ricerca, fare clic su Gestisci applicazioni di servizio in Amministrazione centrale e quindi sul nome dell'applicazione del servizio di ricerca.
Stimare quanto si prevede che il numero di elementi ricercabili aumenterà nei prossimi 12 mesi e progettare la topologia di ricerca per tale importo. Ad esempio, se si dispone di 8.000.000 elementi indicizzati e si prevede che il volume di tale contenuto aumenterà del 50% nei prossimi 12 mesi. È consigliabile progettare 12.000.000 elementi ricercabili.
Passaggio 2: determinare le dimensioni a cui scalare l'architettura di ricerca
Pianificare le dimensioni di un'architettura di ricerca è un'operazione tutt'altro che semplice. Dipende infatti dal volume del contenuto, dalla frequenza di ricerca per indicizzazione, dalla velocità effettiva delle query e dal livello di disponibilità richiesto. Esistono architetture di ricerca di esempio testate da Microsoft che è consigliabile usare come base per la farm. Confrontare l'architettura di ricerca corrente con le architetture di ricerca di esempio e determinare quale esempio rappresenta meglio l'architettura di ricerca corrente. Valutare quindi l'architettura di ricerca di esempio in cui eseguire la scalabilità. La scelta dell'architettura di ricerca di esempio dipende dalla quantità di contenuto da rendere disponibile per la ricerca:
| Volume di contenuto (SharePoint 2016) | Architettura di ricerca di esempio | Volume di contenuto (SharePoint 2013) |
|---|---|---|
| 0-20 milioni di elementi | Farm di ricerca di piccole dimensioni | 0-10 milioni di elementi |
| 0-80 milioni di elementi | Farm di ricerca di medie dimensioni | 0-40 milioni di elementi |
| 0-200 milioni di elementi | Farm di ricerca di grandi dimensioni | 0-100 milioni di elementi |
| 0-500 milioni di elementi | Farm di ricerca di dimensioni molto grandi | Non supportato |
Anche se queste architetture di ricerca di esempio usano macchine virtuali, è possibile usare sia server fisici che macchine virtuali in base alla strategia della soluzione complessiva di SharePoint Server dell'architettura di ricerca.
Farm di ricerca di piccole dimensioni
È stato calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 50 documenti al secondo e di gestire 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti fino a 20 milioni di elementi, la farm di ricerca di piccole dimensioni sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 50 documenti al secondo, la prima ricerca per indicizzazione completa su 20 milioni di elementi richiede circa 110 ore.
Farm di ricerca di medie dimensioni
È stato calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 100 documenti al secondo e di gestire 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti da 20 a 80 milioni di elementi, la farm di ricerca media sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 200 documenti al secondo, la prima ricerca per indicizzazione completa su 80 milioni di elementi richiede circa 280 ore.
Farm di ricerca di grandi dimensioni
Abbiamo calcolato che questa architettura di ricerca è in grado di eseguire la ricerca per indicizzazione di 200 documenti al secondo nell'ordine di 10 query al secondo. Se in una farm di SharePoint Server 2016 sono presenti tra 80 e 200 milioni di elementi, la farm di ricerca di grandi dimensioni sarà probabilmente la farm più adatta. Con una frequenza di ricerca per indicizzazione di 200 documenti al secondo, la prima ricerca per indicizzazione completa su 200 milioni di elementi richiede circa 280 ore.
Farm di ricerca di dimensioni molto grandi
Microsoft ha testato questa architettura di ricerca e calcolato che è in grado di eseguire la ricerca per indicizzazione di un numero di documenti da 300 a 500 al secondo e di gestire 10 query al secondo. Solo SharePoint Server 2016 supporta questa architettura di ricerca di dimensioni. Se si dispone fino a 500 milioni di elementi, una farm simile a una farm di ricerca extra large è un buon punto di partenza. Con una frequenza di ricerca per indicizzazione di 500 documenti al secondo, la prima ricerca per indicizzazione completa su 500 milioni di elementi richiede circa 300 ore.
Per creare una farm di ricerca di questa dimensione è necessario pianificare attentamente e ricercare manualmente la farm per ottenere le prestazioni desiderate. Può risultare vantaggioso per richiedere assistenza. È anche importante pianificare come eseguire il backup e ripristinare una farm di ricerca di queste dimensioni e come ripristinare la farm se il data center presenta un'interruzione importante. Si consiglia di praticare operazioni di backup, ripristino e recupero.
Passaggio 3: Requisiti hardware da conoscere
Dopo aver determinato il volume del contenuto e aver scelto una nuova topologia in cui passare, il passaggio successivo consiste nel pianificare l'hardware necessario, come descritto in questa sezione:
Scegliere se usare server fisici o virtuali
Quando l'architettura di ricerca è stata pianificata inizialmente, si è deciso di usare server fisici o macchine virtuali oppure una combinazione di entrambi. Considerare se tale decisione è ancora valida. Ad esempio, se si passa dall'architettura di ricerca di esempio di medie dimensioni a quella di grandi dimensioni, può risultare più semplice gestire il numero maggiore di server avvalendosi di macchine virtuali. Tenere inoltre presente che, se un ambiente virtuale è più facile da gestire, offre un livello di prestazioni leggermente inferiore a quello di un ambiente fisico. Un server fisico può ospitare più componenti di ricerca nello stesso server rispetto a un server virtuale. In Overview of farm virtualization and architectures for SharePoint 2013 sono disponibili informazioni utili.
Gli esempi di architettura di ricerca di piccole, medie, grandi o grandi dimensioni vengono eseguiti nelle macchine virtuali, ma possono essere eseguiti anche nei server fisici. Nelle architetture di farm di esempio, è sufficiente spostare i componenti di ricerca dalle macchine virtuali al server host e rimuovere le macchine virtuali. Ogni server fisico può ospitare un massimo di quattro componenti di indicizzazione, ma solo uno di ogni altro tipo di componente di ricerca. Se ad esempio si modifica l'architettura di ricerca di esempio media per usare i server fisici, si noterà che sono presenti due componenti di elaborazione del contenuto nell'host E. La soluzione consiste nell'eliminare uno dei componenti di elaborazione del contenuto. Ciò funziona perché la ricerca per indicizzazione, l'elaborazione del contenuto e l'elaborazione dell'analisi dipendono dalla quantità di risorse disponibili, non dal numero di componenti di elaborazione del contenuto.
Scegliere le risorse hardware per i server host
Ogni componente e database di ricerca richiede una quantità minima di risorse hardware del server host per funzionare correttamente. Tuttavia, maggiore è il numero di risorse hardware presenti, migliori saranno le prestazioni dell'architettura di ricerca. È consigliabile pertanto implementare risorse hardware superiori alla quantità minima richiesta. Le risorse richieste da ogni componente di ricerca dipendono dal carico di lavoro, a sua volta determinato principalmente dalla frequenza della ricerca per indicizzazione, dalla frequenza delle query e dal numero di elementi indicizzati.
Se ad esempio si ospitano macchine virtuali in Windows Server 2008 R2 Service Pack 1 (SP1), non è possibile usare più di quattro core di CPU per macchina virtuale. Con Windows Server 2012 o versioni successive, si usano otto o più core di CPU per macchina virtuale. È quindi possibile implementare la scalabilità orizzontale con più core di CPU per ogni macchina virtuale anziché implementare la scalabilità verticale con più macchine virtuali. Configurare i server o le macchine virtuali che ospitano gli stessi componenti di ricerca con le stesse risorse hardware. Usare il componente di indicizzazione come esempio. Se si ospitano partizioni di indice in macchine virtuali, la macchina virtuale con le prestazioni inferiori determina le prestazioni dell'intera architettura di ricerca.
Risorse di archiviazione generali
Assicurarsi che ogni server host disponga di spazio su disco sufficiente per l'installazione di base del sistema operativo Windows Server e per i file di programma di SharePoint Server. Il server host necessita anche di spazio su disco disponibile per le operazioni di diagnostica quali la registrazione, il debug e la creazione di dump della memoria, per le operazioni quotidiane e per il file di paging. In genere, 80 GB di spazio su disco sono sufficienti per il sistema operativo Windows Server e per i file di programma di SharePoint Server.
Aggiungere spazio di archiviazione per i log SQL per ogni server di database. Se non si imposta il server di database in modo da eseguire spesso il backup dei database, i log SQL usano una quantità elevata di spazio di archiviazione. Per altre informazioni su come pianificare i database SQL, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server).
L'archiviazione minima richiesta dal database di report di analisi può variare. Ciò è dovuto al fatto che la quantità di spazio di archiviazione dipende dal modo in cui gli utenti interagiscono con SharePoint Server. Quando gli utenti interagiscono frequentemente, in genere sono presenti più eventi da archiviare. Controllare la quantità di spazio di archiviazione usata dall'architettura di ricerca corrente per il database di analisi e assegnare almeno questa quantità per la topologia riprogettata.
Requisiti hardware minimi per la farm di ricerca di piccole dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Spazio di archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche, analisi ed elaborazione del contenuto. | A, B | 200 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con tutti i database di ricerca. | C, D | 100 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di medie dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Spazio di archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con un componente di indicizzazione. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con componenti di analisi e di elaborazione del contenuto | E, F | 300 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche ed elaborazione del contenuto. | E, F | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con tutti i database di ricerca. | G, H | 400 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di grandi dimensioni
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database.
| Server | Nell'host | Spazio di archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | A, B, C, D, E, G, H | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Server applicazioni con un componente di indicizzazione. | A, B, C, D, E, F, G, H, I, J | 500 GB2,3 | 32 GB2,3 | 1,8 GHz 8 core CPU2,3 | 1 Gbps |
| Più server applicazioni con componenti di analisi e di elaborazione del contenuto. | K, L, M, N | 300 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Più server applicazioni con componenti di ricerca per indicizzazione e amministrazione delle ricerche. | K, L | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con database di ricerca. | O, P, Q, R | 500 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
numero araboCon SharePoint Server 2013 la quantità minima di risorse necessarie è di 500 GB di RAM, 16 GB di RAM e quattro core CPU.
3Con SharePoint Server 2016 è anche possibile usare 250 GB di spazio di archiviazione, 16 GB di RAM e quattro core CPU, ma ogni componente di indice può contenere solo 10 milioni di elementi e la farm di ricerca supporta solo lo stesso volume di contenuto di una farm di ricerca di SharePoint Server 2013.
Requisiti hardware minimi per la farm di ricerca di dimensioni molto grandi
Questa tabella indica la quantità minima di risorse hardware necessaria per ogni server applicazioni o server di database. È possibile compilare questa farm di esempio solo con SharePoint Server 2016.
| Server | Nell'host | Spazio di archiviazione | RAM | Processore1 | Larghezza di banda di rete |
|---|---|---|---|---|---|
| Server applicazioni con componenti di indicizzazione. | A-X | 500 GB | 32 GB | 8 core di CPU a 1,8 GHz | 1 Gb/s |
| Server applicazioni con componenti di elaborazione delle query e di indicizzazione. | Y, Z | 500 GB | 32 GB | 8 core di CPU a 1,8 GHz | 1 Gb/s |
| Server applicazioni con componenti di ricerca per indicizzazione, amministrazione delle ricerche o elaborazione del contenuto | AA-AF | 100 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server applicazioni con componenti di analisi e di elaborazione | AG, AH | 800 GB | 8 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
| Server di database con database di ricerca | AI-AL | 500 GB | 16 GB | 4 core di CPU a 1,8 GHz | 1 Gbps |
1Il numero specificato fa riferimento ai core, non ai thread della CPU.
Pianificazione delle prestazioni di archiviazione
La velocità di archiviazione incide sulle prestazioni di ricerca. Assicurarsi che la velocità di archiviazione sia sufficiente per gestire il traffico dei componenti e database di ricerca. La velocità del disco è misurata in operazioni di input/output al secondo.
Il modo in cui si decide di distribuire i dati dai componenti di ricerca e dal sistema operativo nell'archiviazione influisce sulle prestazioni di ricerca. È consigliabile:
Suddividere i file del sistema operativo Windows Server, i file di programma di SharePoint Server e i log di diagnostica in tre volumi di archiviazione o partizioni separati con prestazioni normali.
Archiviare i dati dei componenti di ricerca in un volume di archiviazione o partizione di memoria separata. Per i componenti di indicizzazione, questo spazio di archiviazione deve avere inoltre prestazioni elevate.
Nota
È possibile impostare un percorso personalizzato per i dati dei componenti di ricerca quando si installa SharePoint Server in un host. Tutti i componenti di ricerca presenti nell'host che devono archiviare dati usano questo percorso. Per modificare questo percorso in un secondo momento, è necessario reinstallare SharePoint Server.
Scelta del tipo di risorse di archiviazione
Per una panoramica delle architetture di archiviazione e sui tipi di dischi, vedere Pianificazione e configurazione dell'archiviazione e della capacità di SQL Server (SharePoint Server 2013). I server che ospitano i componenti di indicizzazione, analisi, elaborazione e amministrazione delle ricerche o i database di ricerca richiedono supporti di archiviazione in grado di mantenere una latenza bassa, assicurando comunque un numero sufficiente di operazioni di input/output al secondo. Nelle tabelle seguenti è indicato il numero di operazioni di input/output al secondo richiesto da ognuno di questi componenti e database di ricerca.
Se si distribuisce un sistema di archiviazione condiviso come SAN/NAS, il carico massimo del disco di un componente di ricerca coincide generalmente con quello di un altro componente di ricerca. Per ottenere il numero di operazioni di input/output al secondo richiesto dalla ricerca dal sistema di archiviazione condivisa, è necessario sommare il requisito di operazioni di input/output al secondo di ognuno di questi componenti.
Requisiti di input/output al secondo per i componenti di ricerca
| Nome componente | Dettagli componente | Requisiti di input/output al secondo | Uso di volume di archiviazione//partizione di memoria separata |
|---|---|---|---|
| Componente di indicizzazione | Usa l'archiviazione durante l'unione dell'indice e durante la gestione e la risposta alle query. | 300 operazioni di input/output al secondo per letture casuali a 64 KB. 100 operazioni di input/output al secondo per scritture casuali a 256 KB. 200 MB/s per letture sequenziali. 200 MB/s per scritture sequenziali. |
Sì |
| Componente di analisi | Analizza i dati in locale, con elaborazione bulk. | No | Sì |
| Componente di ricerca per indicizzazione | Archivia localmente il contenuto scaricato, prima di inviarlo a un componente di elaborazione del contenuto. L'archiviazione è limitata dalla larghezza di banda della rete. | No | Sì |
Requisiti di input/output al secondo per i database di ricerca
| Nome database | Requisiti di input/output al secondo | Carico tipico sul sottosistema I/O. |
|---|---|---|
| Database di ricerca per indicizzazione | Numero medio-alto di operazioni di input/output al secondo | 10 operazioni di input/output al secondo per una frequenza di ricerca per indicizzazione di un documento al secondo. |
| Database dei collegamenti | Numero medio di operazioni di input/output al secondo | 10 operazioni di input/output al secondo per un milione di elementi nell'indice di ricerca. |
| Database di amministrazione della ricerca | Numero ridotto di operazioni di input/output al secondo | Non applicabile. |
| Database di report di analisi | Numero medio di operazioni di input/output al secondo | Non applicabile. |
Scelta della modalità di supporto della disponibilità elevata per l'architettura di ricerca
Se non si ha familiarità con le strategie di disponibilità elevata, ecco un articolo introduttivo: Creare un'architettura e una strategia a disponibilità elevata per SharePoint Server. Se si ospitano componenti e database di ricerca ridondanti in domini di errore separati, un'interruzione del servizio in una parte della farm non comporta l'interruzione dell'intero servizio. Si verificherà tuttavia una riduzione delle prestazioni di ricerca, perché i componenti di ricerca non possono condividere ulteriormente il carico. Per ridurre la possibilità di perdere un singolo server, è consigliabile migliorare la ridondanza locale. Per ogni server host nell'architettura di ricerca:
Usare l'archiviazione RAID in ogni server.
Installare più connessioni di rete ridondanti in ogni server.
Installare più alimentatori ridondanti con cablaggio indipendente o un gruppo di continuità per ogni server.
Tutte le architetture di ricerca di esempio ospitano componenti di ricerca ridondanti in server indipendenti. Nelle architetture di ricerca di esempio l'host più a destra in ogni coppia di host è ridondante. Questa è l'architettura di ricerca di grandi dimensioni con gli host ridondanti evidenziati.
