Redesenhar a topologia de pesquisa empresarial para mais conteúdos e utilizadores no SharePoint
APLICA-SE A:
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
Ao longo do tempo, a maioria dos ambientes de pesquisa aumenta, tanto em quantidade de conteúdo como em número de utilizadores. A dada altura, o ambiente de pesquisa ultrapassa a capacidade e o desempenho da sua arquitetura de pesquisa. A solução é dimensionar a topologia da sua arquitetura de pesquisa:
Reconstruir sua topologia (este artigo)
Implemente a topologia reconstruída (Gerenciar a topologia de pesquisa no SharePoint Server)
Está familiarizado com os componentes do sistema de pesquisa no SharePoint Server e como interagem? Ao ler Visão geral da arquitetura de pesquisa no SharePoint Server e Arquiteturas de pesquisa do SharePoint Server 2016 (ou Arquiteturas de pesquisa do SharePoint Server 2013) antes de começar, você se familiarizará com a arquitetura de pesquisa, os componentes de pesquisa, os bancos de dados de pesquisa e a topologia de pesquisa.
Neste artigo, vamos mostrar-lhe passo a passo como redesenhar a sua topologia de pesquisa.
Após ter seguido essas etapas, você saberá:
Quanto de cada tipo de componente de pesquisa e banco de dados de pesquisa sua topologia precisa.
Em quais servidores de aplicativo e de banco de dados implementar cada componente de pesquisa.
De quais recursos de hardware cada servidor de aplicativo e de banco de dados precisa.
Etapa 1: Quanto conteúdo tenho?
O volume de conteúdo que você possui em seu índice de pesquisa afeta os recursos de que você precisa para hospedar o farm. Verifique quantos itens são pesquisáveis no seu ambiente de pesquisa existente. Encontrará este número na página Administração de pesquisas no site da Administração Central do SharePoint. Para abrir a página de administração de pesquisas, clique em Gerir aplicações de serviço na Administração Central e, em seguida, clique no nome da aplicação do Serviço de pesquisa.
Calcule quanto espera que o número de itens pesquisáveis aumente nos próximos 12 meses e crie a topologia de pesquisa para esse montante. Por exemplo, se tiver 8000 000 itens indexados e esperar que o volume desse conteúdo cresça 50% nos próximos 12 meses. Deve estruturar 12 000 000 itens pesquisáveis.
Passo 2: para que tamanho devo dimensionar a arquitetura de pesquisa?
Nem sempre é fácil avaliar o quanto grande ou pequena deve ser sua arquitetura de pesquisa. O tamanho da arquitetura de pesquisa depende de volume do conteúdo, taxa de rastreamento, taxa de transferência de consulta e nível de alta disponibilidade requerido. Existem arquiteturas de pesquisa de exemplo que foram testadas pela Microsoft que aconselhamos a utilizar como base para o seu próprio farm. Compare a sua arquitetura de pesquisa atual com as arquiteturas de pesquisa de exemplo e determine qual o exemplo que melhor representa a sua arquitetura de pesquisa atual. Em seguida, considere a arquitetura de pesquisa de exemplo para a qual dimensionar. A amostra de arquitetura de pesquisa escolhida depende de quanto conteúdo precisa ser pesquisável:
| Volume de conteúdos (SharePoint 2016) | Amostra de arquitetura de pesquisa | Volume de conteúdos (SharePoint 2013) |
|---|---|---|
| 0 a 20 milhões de itens | Farm pequeno de pesquisa | 0-10 milhões de itens |
| 0 a 80 milhões de itens | Farm médio de pesquisa | 0 a 40 milhões de itens |
| 0 a 200 milhões de itens | Farm grande de pesquisa | 0 a 100 milhões de itens |
| 0 a 500 milhões de itens | Farm de pesquisa extra grande | Sem suporte |
Embora estas arquiteturas de pesquisa de exemplo utilizem máquinas virtuais, pode utilizar servidores físicos e máquinas virtuais de acordo com a estratégia da solução geral do SharePoint Server da sua arquitetura de pesquisa.
Farm pequeno de pesquisa
Estimámos que esta arquitetura de pesquisa pode pesquisar 50 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver até 20 milhões de itens num farm do SharePoint Server 2016, o pequeno farm de pesquisa será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 50 documentos por segundo, a pesquisa demora 110 horas a pesquisar 20 milhões de itens na primeira pesquisa completa.
Farm médio de pesquisa
Estimamos que esta arquitetura de pesquisa pode pesquisar 100 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver entre 20 e 80 milhões de itens num farm do SharePoint Server 2016, o farm de pesquisa média será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 200 documentos por segundo, a pesquisa demora 280 horas a pesquisar 80 milhões de itens na primeira pesquisa completa.
Farm grande de pesquisa
Estimamos que esta arquitetura de pesquisa pode pesquisar 200 documentos por segundo e servir na ordem de 10 consultas por segundo. Se tiver entre 80 e 200 milhões de itens num farm do SharePoint Server 2016, o farm de pesquisa grande será provavelmente o farm mais adequado para si. Com uma taxa de pesquisa de 200 documentos por segundo, a pesquisa demora 280 horas a pesquisar 200 milhões de itens na primeira pesquisa completa.
Farm de pesquisa extra-grande
A Microsoft testou esta arquitetura de pesquisa e mediu que pode pesquisar 300 a 500 documentos por segundo e servir na ordem de 10 consultas por segundo. Apenas o SharePoint Server 2016 suporta esta arquitetura de pesquisa de tamanho. Se tiver até 500 milhões de itens, um farm semelhante ao farm de pesquisa extra grande é um bom ponto de partida. Com uma taxa de pesquisa de 500 documentos por segundo, a pesquisa demora cerca de 300 horas a pesquisar 500 milhões de itens na primeira pesquisa completa.
Criar um farm de pesquisa deste tamanho requer que planeie e ajuste cuidadosamente o farm para obter o desempenho pretendido. Poderá considerar vantajoso procurar orientações especializadas. Também é importante planear como criar cópias de segurança e restaurar um farm de pesquisa deste tamanho e como recuperar o farm se o seu datacenter tiver uma falha grave. Recomendamos que pratique a cópia de segurança, o restauro e a recuperação.
Etapa 3: De quais requisitos de hardware devo estar ciente?
Agora que determinou o volume dos seus conteúdos e escolheu uma nova topologia para onde avançar, o próximo passo é planear o hardware de que irá precisar, conforme descrito nesta secção:
Escolher executar os servidores fisicamente ou virtualmente
Quando você planejou originalmente a arquitetura de pesquisa, decidiu usar servidores físicos ou máquinas virtuais, ou uma mistura deles. Considere se essa decisão ainda é válida. Por exemplo, se passar do meio para a arquitetura de pesquisa de exemplo grande, poderá ser mais fácil gerir o aumento do número de servidores quando utiliza máquinas virtuais. Note também que embora um ambiente virtual seja mais fácil de gerenciar, o nível de seu desempenho pode, algumas vezes, ser um pouco inferior que de um ambiente físico. Um servidor físico pode hospedar mais componentes de pesquisa no mesmo servidor que um servidor virtual. Você encontrará uma orientação útil em Overview of farm virtualization and architectures for SharePoint 2013.
Os pequenos, médios, grandes ou grandes exemplos de arquitetura de pesquisa são executados em máquinas virtuais, mas também podem ser executados em servidores físicos. Nos exemplos de arquitetura de farm, simplesmente mova os componentes de pesquisa das máquinas virtuais para o servidor host e remova as máquinas virtuais. Cada servidor físico pode hospedar até quatro componentes de índice, mas apenas um de cada tipo dos outros componentes de pesquisa. Se, por exemplo, alterar a arquitetura de pesquisa de exemplo médio para utilizar servidores físicos, verá que tem dois componentes de processamento de conteúdos no Anfitrião E. A solução é retirar um dos componentes de processamento de conteúdos. Isto funciona porque a pesquisa, o processamento de conteúdos e o processamento de análise dependem da quantidade de recursos disponíveis e não do número de componentes de processamento de conteúdos.
Escolher recursos de hardware para os servidores de host
Cada componente de pesquisa e banco de dados de pesquisa requer uma quantidade mínima de recursos de hardware do servidor de host para ser bem executado. Porém, quanto mais recursos de hardware você tiver, melhor será o desempenho da arquitetura de pesquisa. Portanto, é uma boa ideia ter mais do que a quantidade mínima de recursos de hardware. Os recursos que cada componente de pesquisa requer depende da carga de trabalho, em grande parte determinada pela taxa de rastreamento, taxa de consulta e número de itens indexados.
Por exemplo, ao hospedar máquinas virtuais no Windows Server 2008 R2 Service Pack 1 (SP1), você não pode usar mais de quatro núcleos da CPU por máquina virtual. Com o Windows Server 2012 ou mais recente, você usa oito ou mais núcleos da CPU por máquina virtual. Então, pode expandir com mais núcleos da CPU para cada máquina virtual, ao invés de aumentar com mais máquinas virtuais. Configure os servidores ou as máquinas virtuais que hospedam os mesmos componentes de pesquisa com os mesmos recursos de hardware. Usaremos o componente de índice como um exemplo. Quando você hospeda partições do índice nas máquinas virtuais, a máquina virtual com o desempenho mais fraco determina o desempenho da arquitetura de pesquisa geral.
Recursos de armazenamento gerais
Certifique-se de que cada servidor anfitrião tem espaço em disco suficiente para a instalação base do sistema operativo Windows Server e para os ficheiros do programa do SharePoint Server. O servidor de host também precisa de espaço livre no disco rígido para fazer diagnósticos, como log, depuração e criação de despejos da memória para as operações diárias e para o arquivo de página. Normalmente, 80 GB de espaço em disco são suficientes para o sistema operativo Windows Server e para os ficheiros do programa sharePoint Server.
Adicione armazenamento para o espaço de log do SQL para cada servidor do banco de dados. Se você não definir o servidor do banco de dados para fazer backup dos bancos de dados com frequência, o espaço de log do SQL usará muito armazenamento. Para mais informações sobre como planejar os bancos de dados SQL, consulte Configuração e planejamento da capacidade de armazenamento do SQL Server (SharePoint Server).
O armazenamento mínimo que o banco de dados de relatórios da análise requer pode variar. Isto deve-se ao facto de a quantidade de armazenamento depender da forma como os utilizadores interagem com o SharePoint Server. Quando os usuários interagem com frequência, em geral há mais eventos a armazenar. Verifique a quantidade de armazenamento que sua arquitetura de pesquisa atual usa para o banco de dados de análise e atribua pelo menos essa quantidade para sua topologia reconstruída.
Recursos mínimos de hardware para o farm pequeno de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| O servidor do aplicativo que tem rastreamento, administração da pesquisa, análise e componentes de processamento do conteúdo. | A, B | 200 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem todos os bancos de dados de pesquisa. | C, D | 100 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários é 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos mínimos de hardware para o farm médio de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| O servidor do aplicativo que tem componentes de processamento da análise e do conteúdo. | E, F | 300 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do aplicativo que tem rastreamento, administração da pesquisa e componentes de processamento do conteúdo. | E, F | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem todos os bancos de dados de pesquisa. | G, H | 400 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários é 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos mínimos de hardware para o farm grande de pesquisa
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | A, B, C, D, E, G, H | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D, E, F, G, H, I, J | 500 GB2,3 | 32 GB2,3 | Núcleos de CPU de 1,8 GHz 8x2,3 | 1 Gbps |
| Os servidores do aplicativo que têm componentes de processamento da análise e do conteúdo | K, L, M, N | 300 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Os servidores do aplicativo que têm rastreamento e componentes de administração da pesquisa | K, L | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| O servidor do banco de dados que tem bancos de dados de pesquisa | O, P, Q, R | 500 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
2Com o SharePoint Server 2013, a quantidade mínima de recursos necessários são 500 GB de RAM, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, também pode utilizar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas, em seguida, cada componente de índice só pode conter 10 milhões de itens e o farm de pesquisa só suporta o mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos de hardware mínimos para o farm de pesquisa extra grande
Esta tabela mostra a quantidade mínima de recursos de hardware que cada servidor de aplicativos e de bancos de dados precisa. Só pode criar este farm de exemplo com o SharePoint Server 2016.
| Servidor | No host | Armazenamento | RAM | Processador1 | Largura de banda da rede |
|---|---|---|---|---|---|
| Servidor de aplicações com componentes de índice. | A-X | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz 8x | 1 Gbps |
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | Y, Z | 500 GB | 32 GB | Núcleos de CPU de 1,8 GHz 8x | 1 Gbps |
| Servidores de aplicações com componentes de processamento de pesquisa, de pesquisa ou de pesquisa | AA-AF | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de aplicações com componentes de processamento de análise | AG, AH | 800 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de bases de dados com bases de dados de pesquisa | IA-AL | 500 GB | 16 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
1O número de núcleos da CPU é especificado aqui, mas não o número de threads da CPU.
Planejar o desempenho do armazenamento
A velocidade do armazenamento afeta o desempenho da pesquisa. Verifique se o armazenamento de que você dispõe é rápido o bastante para lidar com o tráfego dos componentes e bancos de dados de pesquisa. A velocidade do disco é medida em operações de E/S por segundo (IOPS).
O modo como você decide distribuir os dados a partir dos componentes de pesquisa e do sistema operacional em seu armazenamento afeta o desempenho da pesquisa. É uma boa ideia:
Divida os ficheiros do sistema operativo Windows Server, os ficheiros do programa do SharePoint Server e os registos de diagnóstico em três volumes ou partições de armazenamento separados com o desempenho normal.
Armazenar os dados do componente de pesquisa em um volume de armazenamento separado ou partição. Para os componentes do índice, esse armazenamento também deve ter um alto desempenho.
Observação
Pode definir uma localização personalizada para dados de componentes de pesquisa ao instalar o SharePoint Server num anfitrião. Qualquer componente de pesquisa no host que precisar armazenar dados, irá armazená-los nesse local. Para alterar esta localização mais tarde, tem de reinstalar o SharePoint Server.
Escolher o tipo de armazenamento
Para obter uma visão geral de arquiteturas de armazenamento e tipos de discos, confira Armazenamento e planejamento e configuração da capacidade do SQL Server (SharePoint Server 2013). Os servidores que hospedam os componentes de índice, processamento de análises e administração de pesquisa, ou bancos de dados de pesquisa, requerem armazenamento que possa manter baixa latência, mantendo, ao mesmo tempo, operações de E/S (IOPS) suficientes. As tabelas seguintes mostram quantas IOPS são requeridas por cada um desses componentes e bancos de dados de pesquisa.
Se você implantar um armazenamento compartilhado como SAN/NAS, a carga de pico do disco de um componente de pesquisa geralmente coincidirá com a carga de pico do disco de outro componente de pesquisa. Para obter o número da pesquisa IOPS requerido no armazenamento compartilhado, é preciso adicionar o requisito de IOPS de cada um desses componentes.
Pesquisar os requisitos de IOPS do componente
| Nome do componente | Detalhes do componente | Requisitos de IOPS | Uso do volume/partição de armazenamento separado |
|---|---|---|---|
| Componente do índice | Usa o armazenamento ao mesclar o índice, ao lidar e responder a consultas. | 300 IOPS para 64 KB de leituras aleatórias. 100 IOPS para 256 KB de gravações aleatórias. 200 MB/s para leituras sequenciais. 200 MB/s para gravações sequenciais. |
Sim |
| Componente de análise | Analisa os dados localmente, no processamento em massa. | Não | Sim |
| Componente de rastreamento | Armazena o conteúdo baixado localmente, antes de enviar para um componente de processamento do conteúdo. O armazenamento é limitado pela largura de banda da rede. | Não | Sim |
Pesquisar requisitos de IOPS do banco de dados
| Nome do banco de dados | Requisitos de IOPS | Carga típica no subsistema de E/S. |
|---|---|---|
| Banco de dados de rastreamento | IOPS médio a alto | 10 IOPS por taxa de rastreamento de 1 documento por segundo (DPS). |
| Banco de dados de links | IOPS médio | 10 IOPS por 1 milhão de itens no índice da pesquisa. |
| Banco de dados de Administração de Pesquisa | IOPS baixo | Não aplicável. |
| Banco de Dados de Relatório de Análise | IOPS médio | Não aplicável. |
Escolher como sua arquitetura de pesquisa oferece suporte à alta disponibilidade
Se você não estiver familiarizado com as estratégias de alta disponibilidade, eis um artigo para começar: Crie uma arquitetura e uma estratégia de alta disponibilidade para o SharePoint Server. Quando você hospeda componentes e bancos de dados de pesquisa redundantes em domínios com falha separados, uma interrupção em uma parte do farm não deixa inativo o serviço inteiro. Mas, o desempenho da pesquisa diminuirá porque os componentes da pesquisa não poderão mais compartilhar a carga. Para reduzir a possibilidade de perder um único servidor, recomendamos que melhore a redundância local. Para cada servidor de host na arquitetura de pesquisa:
Use um armazenamento RAID em cada servidor.
Instale diversas conexões de rede redundantes em cada servidor.
Instale várias fontes de alimentação redundantes com fios independentes ou uma fonte de alimentação ininterrupta (UPS) para cada servidor.
Todas as arquiteturas de pesquisa de amostra hospedam componentes de pesquisa redundantes em servidores independentes. Nas arquiteturas de pesquisa de amostra, o host mais à direita em cada par de hosts é redundante. Eis uma arquitetura de pesquisa grande com os hosts redundantes descritos:
