Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
APLICA-SE A
2013 2016 2019 Subscription Edition 
SharePoint no Microsoft 365
Com o tempo, a maioria dos ambientes de pesquisa cresce, tanto em quantidade de conteúdo quanto em número de usuários. Em algum momento, o ambiente de pesquisa supera a capacidade e o desempenho de sua arquitetura de pesquisa. A solução é dimensionar a topologia de sua arquitetura de pesquisa:
Reconstruir sua topologia (este artigo)
Implemente a topologia reconstruída (Gerenciar a topologia de pesquisa no SharePoint Server)
Você está familiarizado com os componentes do sistema de pesquisa no SharePoint Server e como eles 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, mostraremos passo a passo como redesenhar 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 em seu ambiente de pesquisa existente. Você encontra esse número na página Administração de pesquisa no site da Administração Central do SharePoint. Para abrir a página de administração da pesquisa, clique em Gerenciar aplicativos de serviço na Administração Central e clique no nome do aplicativo de serviço Pesquisa.
Estime quanto você espera que o número de itens pesquisáveis cresça nos próximos 12 meses e projete a topologia de pesquisa para esse valor. Por exemplo, se você tiver 8.000.000 de itens indexados e espera que o volume desse conteúdo cresça 50% nos próximos 12 meses. Você deve criar para 12.000.000 de itens pesquisáveis.
Etapa 2: Qual o tamanho da arquitetura de pesquisa devo dimensionar?
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. Há arquiteturas de pesquisa de exemplo que foram testadas pela Microsoft e que recomendamos usar como base para seu próprio farm. Compare sua arquitetura de pesquisa atual com as arquiteturas de pesquisa de exemplo e determine qual exemplo melhor representa sua arquitetura de pesquisa atual. Em seguida, considere para qual arquitetura de pesquisa de exemplo escalar. A amostra de arquitetura de pesquisa escolhida depende de quanto conteúdo precisa ser pesquisável:
| Volume de conteúdo (SharePoint 2016) | Amostra de arquitetura de pesquisa | Volume de conteúdo (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 essas arquiteturas de pesquisa de exemplo usem máquinas virtuais, você pode usar servidores físicos e máquinas virtuais de acordo com a estratégia da solução geral do SharePoint Server de sua arquitetura de pesquisa.
Farm pequeno de pesquisa
Estimamos que essa arquitetura de pesquisa pode rastrear 50 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver até 20 milhões de itens em um farm do SharePoint Server 2016, o farm de pesquisa pequeno provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 50 documentos por segundo, a pesquisa leva 110 horas para rastrear 20 milhões de itens no primeiro rastreamento completo.
Farm médio de pesquisa
Estimamos que essa arquitetura de pesquisa pode rastrear 100 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver entre 20 e 80 milhões de itens em um farm do SharePoint Server 2016, o farm de pesquisa média provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 200 documentos por segundo, a pesquisa leva 280 horas para rastrear 80 milhões de itens no primeiro rastreamento completo.
Farm grande de pesquisa
Estimamos que essa arquitetura de pesquisa pode rastrear 200 documentos por segundo e servir na ordem de 10 consultas por segundo. Se você tiver entre 80 e 200 milhões de itens em um farm do SharePoint Server 2016, o farm de pesquisa grande provavelmente será o farm mais adequado para você. Com uma taxa de rastreamento de 200 documentos por segundo, a pesquisa leva 280 horas para rastrear 200 milhões de itens no primeiro rastreamento completo.
Farm de pesquisa extragrande
A Microsoft testou essa arquitetura de pesquisa e mediu que ela pode rastrear de 300 a 500 documentos por segundo e veicular na ordem de 10 consultas por segundo. Somente o SharePoint Server 2016 dá suporte a essa arquitetura de pesquisa de tamanho. Se você 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 rastreamento de 500 documentos por segundo, a pesquisa leva cerca de 300 horas para rastrear 500 milhões de itens no primeiro rastreamento completo.
A criação de um farm de pesquisa desse tamanho exige que você planeje e ajuste cuidadosamente o farm para obter o desempenho desejado. Você pode achar vantajoso procurar orientação especializada. Também é importante planejar como fazer backup e restaurar um farm de pesquisa desse tamanho e como recuperar o farm se o data center sofrer uma grande interrupção. Recomendamos que você pratique o backup, a restauração e a recuperação.
Etapa 3: De quais requisitos de hardware devo estar ciente?
Agora que você determinou o volume do conteúdo e escolheu uma nova topologia para a qual mover, a próxima etapa é planejar o hardware necessário, conforme descrito nesta seçã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 você mudar da arquitetura de pesquisa de amostra média para a grande, poderá achar mais fácil gerenciar o maior número de servidores ao usar 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 exemplos de arquitetura de pesquisa pequeno, médio, grande ou extra grande 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, você alterar a arquitetura de pesquisa de amostra média para usar servidores físicos, descobrirá que tem dois componentes de processamento de conteúdo no Host E. A solução é remover um dos componentes de processamento de conteúdo. Isso funciona porque o rastreamento, o processamento de conteúdo e o processamento de análises dependem da quantidade de recursos disponíveis, não do número de componentes de processamento de conteúdo.
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
Verifique se cada servidor host tem espaço em disco suficiente para a instalação básica do sistema operacional Windows Server e para os arquivos de 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 operacional do Windows Server e para os arquivos de programa do 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. Isso ocorre porque a quantidade de armazenamento depende de como os usuários 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 | 1.8 GHz 8x núcleos de CPU2,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ária é de 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente do índice só pode conter 10 milhões de itens, e o farm de pesquisa suporta apenas 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 | 1.8 GHz 8x núcleos de CPU2,3 | 1 Gbps |
| O servidor do aplicativo que tem um componente de índice. | A, B, C, D | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x núcleos de CPU2,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ária é de 500 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente do índice só pode conter 10 milhões de itens, e o farm de pesquisa suporta apenas 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 | 1.8 GHz 8x núcleos de CPU2,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 | 1.8 GHz 8x núcleos de CPU2,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ária é de 500 GB de RAM, 16 GB de RAM e quatro núcleos de CPU.
3Com o SharePoint Server 2016, você também pode usar 250 GB de armazenamento, 16 GB de RAM e quatro núcleos de CPU, mas cada componente do índice só pode conter 10 milhões de itens, e o farm de pesquisa suporta apenas o mesmo volume de conteúdo que um farm de pesquisa do SharePoint Server 2013.
Recursos mínimos de hardware 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. Você 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 aplicativos que possui componentes de índice. | A-X | 500 GB | 32 GB | 1,8 GHz 8x núcleos de CPU | 1 Gbps |
| O servidor do aplicativo que tem processamento de consulta e componentes de índice. | Y, Z | 500 GB | 32 GB | 1,8 GHz 8x núcleos de CPU | 1 Gbps |
| Servidores de aplicativos que têm componentes de rastreamento, administração de pesquisa ou processamento de conteúdo | AA-AF | 100 GB | 8 GB | 4 núcleos de CPU de 1,8 GHz | 1 Gbps |
| Servidores de aplicativos que possuem 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 banco de dados que têm bancos 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 arquivos do sistema operacional do Windows Server, os arquivos de programa do SharePoint Server e os logs de diagnóstico em três volumes de armazenamento ou partições separadas com 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
Você pode definir um local personalizado para dados de componente de pesquisa ao instalar o SharePoint Server em um host. Qualquer componente de pesquisa no host que precisar armazenar dados, irá armazená-los nesse local. Para alterar esse local mais tarde, você precisa 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, é uma boa ideia melhorar 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 fiação independente ou um no-break (fonte de alimentação ininterrupta) 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:
