Estime os requisitos de desempenho e capacidade para ambientes de colaboração divisional (SharePoint Server 2013)
APLICA-SE A:2013 2016 2019 Subscription Edition SharePoint no Microsoft 365
Este artigo descreve orientações sobre o desempenho e o planeamento de capacidade para uma solução de colaboração de divisão baseada no SharePoint Server 2013. As informações seguintes estão incluídas neste artigo:
Testar especificações do ambiente de laboratório, como hardware, topologia de farm e configuração
A carga de trabalho e o conjunto de dados do farm de teste que geraram a carga de teste
Resultados e análise de teste que demonstram e explicam as tendências nas demandas de taxa de transferência, latência e hardware nas cargas em pontos específicos da escala.
Use as informações nesse artigo para compreender as características do cenário sob as cargas normais e de pico, e como as tendências de desempenho mudam quando os servidores de farm são expandidos. Este artigo também poderá ajudar a estimar um ponto de partida apropriado para sua arquitetura planejada, e os fatores que devem ser considerados ao desenvolver um plano para manter níveis de desempenho aceitáveis sob carga de pico.
Introdução
Este artigo descreve como aumentar horizontalmente os servidores numa solução de colaboração de divisão do SharePoint Server 2013. Uma solução de colaboração de divisão é uma implementação do SharePoint Server 2013 que tem menos computadores envolvidos nas atividades de colaboração do que uma solução de colaboração empresarial. Este artigo pressupõe que uma divisão seja uma organização dentro de uma empresa que tenha de 1.000 a 10,000 funcionários.
Cenários distintos terão requisitos diferentes. Portanto, complemente esta orientação com testes adicionais em seu próprio hardware e ambiente. Se o design e a carga de trabalho planejados se parecem com o ambiente descrito neste artigo, você pode usar este artigo para descrever conclusões sobre que desempenho esperar ao dimensionar seu ambiente.
Importante
Resultados de testes neste artigo foram produzidos em um laboratório de este que utilizou uma carga de trabalho, conjunto de dados e arquitetura para simular um ambiente de produção sob condições altamente controladas. Embora tenham projetado atentamente esses resultados, as características de desempenho de um laboratório de teste nunca são as mesmas do comportamento de um ambiente de produção. Estes resultados de testes não representam o desempenho e a capacidade característicos de um farm de produção. Em vez disso, eles demonstram tendências observadas nas demandas de taxa de transferência, latência e hardware. Use a análise dos dados observados para ajudá-lo a planejar a capacidade e a gerenciar seu próprio farm.
À medida que ler este artigo, você aprenderá o seguinte:
Especificações, que incluem hardware, topologia e configuração
A carga de trabalho, que inclui uma análise da demanda sobre o farm, o número de usuários e características de uso
O conjunto de dados, como tamanhos de bancos de dados e tipos de conteúdo
Resultados de testes e análises para dimensionar servidores Web
Antes de ler este artigo, leia os seguintes artigos para se certificar de que compreende os principais conceitos subjacentes à gestão de capacidade em Limites de software e limites do SharePoint 2013SharePoint Server 2013.
Glossário
A lista seguinte contém definições para os principais termos encontrados neste artigo.
RPS: Pedidos por segundo. RPS é o número de solicitações que um farm ou servidor recebe em um segundo. É uma medição comum da carga do servidor e do farm.
Observação
As solicitações são diferentes dos carregamentos de página. Uma página contém vários componentes, cada um dos quais cria uma ou mais solicitações quando um navegador carrega a página. Um único um carregamento de página cria várias solicitações. Normalmente, as verificações e eventos de autenticação que usam recursos menos importantes não são contabilizadas nas medições do RPS.
Zona Verde: A Zona Verde representa um conjunto definido de características de carga em condições de funcionamento normais, até às cargas de pico diárias esperadas. Um farm que opera nesta faixa deve estar apto a manter tempos de resposta e latência que estejam dentro de parâmetros aceitáveis.
Este é o estado no qual o servidor pode manter os seguintes conjuntos de critérios:
A latência do lado do servidor para, pelo menos, 75% das solicitações é menor do que 1 segundo.
Todos os servidores de farm mantêm uma média de utilização de CPU inferior a aproximadamente 60%.
Observação
Nosso ambiente de laboratório não executou um rastreamento de pesquisa ativo. Assim, o servidor de banco de dados foi mantido a aproximadamente 50% de utilização da CPU, ou menos, a fim de reservar 10% para carregamento do rastreamento de pesquisa. Isto pressupõe que o SQL Server Resource Governor é utilizado na produção para limitar a carga de pesquisa a 10% da CPU.
A taxa de falha é inferior a 0,01%.
Zona Vermelha (Máx.): A Zona Vermelha representa um conjunto definido de características de carga em condições de funcionamento de pico. Na Zona Vermelha, o farm apresenta uma demanda de recursos transitórios muito alta, e só pode ser sustentado por períodos limitados, até a ocorrência de falhas e outros problemas de desempenho e confiabilidade.
Este é o estado no qual o servidor pode manter os seguintes conjuntos de critérios por uma duração limitada
O recurso de limitação de solicitações HTTP é ativado, mas nenhum erro 503 (servidor ocupado) é retornado,
A taxa de falhas é inferior a 0. 1%.
A latência do lado do servidor é inferior a 3 segundos para, pelo menos, 75% das solicitações.
Todos os servidores de farm (excluindo servidores de bancos de dados) mantêm uma média de utilização de CPU inferior a aproximadamente 90%.
A utilização média de CPU pelo servidor de banco de dados é inferior a aproximadamente 50%, o que leva em conta a grande sobrecarga a ser reservada para o carregamento do rastreamento de pesquisa.
AxBxC (Notação de gráfico): O número de servidores Web, servidores de aplicações e servidores de bases de dados, respetivamente, num farm. Por exemplo, 10x1x1 significa que o ambiente tem 10 servidores Web, 1 servidor de aplicativos e 1 servidor de banco de dados.
MDF e LDF: Ficheiros físicos do SQL Server. Para obter mais informações, veja Arquitetura de Ficheiros e Grupos de Ficheiros.
Visão Geral
Esta seção fornece uma visão geral de nossa abordagem de dimensionamento e metodologia de teste.
Abordagem de dimensionamento
Esta secção descreve a abordagem que tomámos para dimensionar o nosso ambiente de laboratório. Essa abordagem permitirá que você encontre a melhor configuração para sua carga de trabalho:
Nós expandimos os servidores Web até que quatro servidores Web estivessem em uso. Cada servidor executa o serviço de cache distribuído.
Adicionamos um servidor dedicado que executa o serviço de cache distribuído.
Desabilitamos o serviço de cache distribuído nos servidores Web.
Expandimos os servidores Web adicionais ao máximo para o escopo do teste.
Metodologia e notas de teste
Como este artigo contém resultados de um ambiente de laboratório de teste, nós pudemos controlar determinados fatores para mostrar aspectos específicos dessa carga de trabalho. Alem disso, determinados elementos do ambiente de produção, que estão na lista a seguir, foram deixados de lado de nosso ambiente de laboratório para simplificar a sobrecarga do teste.
Observação
Recomendamos que você inclua esses elementos nos ambientes de produção.
Entre as execuções de teste, nós modificamos somente uma variável de cada vez para facilitar a comparação de resultados entre as execuções de teste.
Os servidores de banco de dados não são parte do cluster porque a redundância não era necessária aos objetivos desses testes.
O rastreamento de pesquisa não estava em execução durante os testes. É claro que ele poderia estar em execução em um ambiente de produção. Para ter isto em conta, reduzimos a utilização da CPU do SQL Server nas nossas definições de "Zona Verde" e "Zona Vermelha" para acomodar os recursos que uma pesquisa de pesquisa normalmente consumiria durante os testes.
Especificações
Esta seção oferece detalhes sobre o hardware, software, topologia e configuração de nosso ambiente de laboratório de teste.
Hardware
As seções a seguir descrevem o hardware usado em nosso ambiente de laboratório de teste.
Importante
Utilizámos anfitriões Hyper-V para virtualizar todos os servidores Web e servidores de aplicações no nosso laboratório de teste. Servidores de bancos de dados não foram virtualizados. O hardware do host físico e o hardware da máquina virtual estão descritos separadamente abaixo.
Hosts Hyper-V
Utilizámos seis anfitriões Hyper-V configurados de forma idêntica para os nossos testes. Cada host executa uma ou duas máquinas virtuais
Hardware do Host | Valor |
---|---|
Processadores |
2 processadores quad-core de 2,49 GHz |
RAM |
32 GB |
Sistema Operacional |
Windows Server 2008 R2 SP1 |
Número de adaptadores de rede |
2 |
Velocidade do adaptador de rede |
1 Gigabit |
Servidores Web virtuais e servidores de aplicativos
Nosso farm de teste usa oito servidores Web virtuais. Também usamos um servidor virtual dedicado que executa o serviço de Cache Distribuído.
Observação
Ambientes de produção geralmente implantam servidores dedicados que executam o serviço de Cache Distribuído em uma configuração altamente disponível. Em nosso ambiente de laboratório de teste usamos um único servidor dedicado, pois a alta disponibilidade não é um fator importante.
Hardware de máquina virtual | WFE1-8 e DC1 |
---|---|
Processadores |
4 processadores virtuais |
RAM |
12 GB |
Sistema operacional |
Windows Server 2008 R2 SP1 |
Tamanho da unidade do SharePoint |
100 GB |
Número de adaptadores de rede |
2 |
Velocidade do adaptador de rede |
10 Gigabits (tráfego entre hosts limitado à velocidade do adaptador de rede) |
Autenticação |
Windows NTLM |
Tipo de balanceador de carga |
IP grande F5 |
Serviços executados localmente |
WFE 1-8: Serviços Federados Básicos. Isto inclui o seguinte: Serviço de Temporizador do SharePoint, Serviço de Rastreio, Word Automation Services, Serviços do Excel e Serviço de Código em Sandbox do Microsoft SharePoint Foundation. DC1: Cache Distribuído Service. |
Servidores de banco de dados
Nos nossos testes, utilizamos um servidor de base de dados físico e executámos a instância predefinida do SQL Server que armazena as bases de dados do SharePoint. Não rastreamos o banco de dados de registro neste artigo.
Observação
Se você ativar o relatório de uso, recomendamos que armazene o banco de dados de registro em log em um LUN (número de unidade lógica) separado. Talvez as implementações grandes e algumas implementações médias necessitem de um servidor de banco de dados de registro em log dedicado para acomodar a demanda no processador gerada por um alto volume de log de eventos.
No nosso ambiente de laboratório, restringimos o registo e armazenámos a base de dados de registo numa instância separada do SQL Server.
Servidor de Base de Dados – Instância Predefinida | SQL Server |
---|---|
Processadores |
4 processadores Quad-core de 2,4 GHz processadores |
RAM |
32 GB |
Sistema operacional |
Windows Server 2008 R2 SP1 |
Armazenamento e geometria |
Direct Attached Storage (DAS) 1 x volume do sistema (RAID0, 1 eixo, 300 GB) 2 x volumes de dados de conteúdo (RAID0, 4 eixos, 450 GB cada) 2 x volumes de dados de conteúdo (RAID0, 2 eixos, 450 GB cada) 1 x volume de dados temp (RAID0, 2 eixos, 300 GB cada) 1 x volume de log temp (RAID0, 2 eixos, 300 GB cada) |
Número de adaptadores de rede |
1 |
Velocidade do adaptador de rede |
1 Gigabit |
Autenticação |
Windows NTLM |
Versão do software |
SQL Server 2008 R2 |
Topologia
O diagrama a seguir mostra a topologia neste ambiente de laboratório.
Configuração
A tabela seguinte mostra as alterações de configuração significativas que foram feitas no servidor de banco de dados em nosso ambiente de laboratório. Essas alterações de configuração permitem o desempenho de teste ideal e relações claras entre parâmetros de teste e resultados. Tenha em atenção que a definição MAXDOP é necessária para o SharePoint Server 2013. As demais alterações de configuração só se aplicam a nosso ambiente de laboratório de teste e pode não afetar seu ambiente de produção.
Configuração | Valor | Observações |
---|---|---|
Conjunto de sites |
179 (total no ambiente) |
Os conjuntos de sites em nosso ambiente de teste usam configurações padrões e autenticação de solicitações do Windows. |
Cache BLOB |
Habilitado |
O padrão é Desativado. Se você ativar o cache BLOB, melhorará a eficiência do servidor por meio da redução de chamadas ao servidor de banco de dados para recursos de página estáticos que possam ser frequentemente solicitados. |
Grau máximo de paralelismo (MAXDOP) |
1 |
Este parâmetro é definido na instância ou instâncias do SQL Server que contêm bases de dados de conteúdos do SharePoint Server 2013. O valor predefinido é 0, o que permite ao SQL Server determinar o grau máximo de paralelismo. O SharePoint Server 2013 requer que MAXDOP seja definido como 1 para instâncias do SQL Server que contenham bases de dados do SharePoint Server 2013. Para obter mais informações sobre como configurar a definição MAXDOP para o SQL Server 2008 R2, veja o grau máximo de paralelismo Opção. Para obter informações sobre como configurar a definição MAXDOP para o SQL Server 2012, veja Configurar o grau máximo de paralelismo Opção de Configuração do Servidor. |
Workload
Esta secção explica os testes de laboratório que executámos no SharePoint Server 2013. Os detalhes destes testes são típicos de um ambiente de colaboração divisional.
Dataset
O conjunto de dados para nosso o ambiente de laboratório de teste representa um ambiente de colaboração divisional típico. Este conjunto de dados contém vários conjuntos de sites, sites, listas, bibliotecas, tipos e tamanhos de arquivos.
Características do conjunto de dados | Valor |
---|---|
Tamanho do banco de dados (combinado) |
174 GB |
Tamanho de MDF |
154 GB |
Tamanho de LDF |
20 GB |
Tamanho de BLOB |
152 GB |
Número de bancos de dados de conteúdo |
2 |
Número de conjuntos de sites |
179 |
Número de aplicativos da Web |
1 |
Número de sites |
1,471 |
Resultados e análise
Os resultados a seguir são ordenados com base na abordagem em escala descrita na seção Visão geral.
Expansão do servidor Web
As seções seguintes descrevem os resultados de testes obtidos ao expandir o número de servidores Web em nosso ambiente de laboratório de teste.
Metodologia de teste
Adicione servidores Web que utilizam as mesmas especificações de hardware e execute o teste novamente sem alterações no farm ou nos parâmetros de teste.
Meça o RPS, latência e utilização de recursos de cada servidor no farm de teste.
Análise
Em nossos testes encontramos o seguinte:
O ambiente expandido para dez servidores Web por servidor de banco de dados. O aumento da taxa de transferência foi bastante linear.
Mesmo até a expansão máxima testada de dez servidores, a adição de mais servidores de banco de dados não aumenta a taxa de transferência. O afunilamento foi confinado em geral aos recursos de servidor Web.
A latência média na zona verde foi quase constante durante todo o teste. O número de servidores Web e a taxa de transferência não afetaram a latência da zona verde. Os dados de latência da zona vermelha mostram uma linha de tendência esperada. A latência é muito alta em um único servidor Web. Uma curva entre 2 e 10 servidores Web permanece confortavelmente dentro dos critérios da zona vermelha.
Observação
Talvez a latência seja levemente afetada quando o serviço de cache distribuído é movido de um servidor Web do farm para um servidor que é dedicado ao cache distribuído. Isso pode ocorrer porque o tráfego do cache distribuído, que era anteriormente interno a cada servidor Web, começa a passar na rede. Teste o desempenho de expansão em seu próprio ambiente para determinar se esta troca é significativa. Observe que a latência em nosso ambiente de teste aumentou levemente quando o serviço de cache distribuído migrou para um servidor dedicado. A latência diminuiu com cada servidor Web adicionado, pois a latência nominal adicionada foi deslocada pelo processamento reduzido e pela carga de memória nos servidores Web. > Para obter mais informações sobre o planeamento da capacidade da Cache Distribuída, veja Planear feeds e o serviço cache distribuída no SharePoint Server.
Devido a melhorias nas características de utilização da base de dados e da colocação em cache no SharePoint Server 2013, a carga média na camada do servidor da base de dados é baixa. Descobrimos que durante nossos testes não foi necessário expandir os servidores de banco de dados.
O desempenho vence quando você adiciona servidores Web virtuais que dependem em parte dos recursos de hardware do host e da utilização de recursos de outros computadores virtuais executados no mesmo host. Servidores virtuais requerem planejamento adicional e estratégias de gerenciamento específicas para virtualização.
Para obter mais informações sobre o desempenho e o planeamento de capacidade do Hyper-V, veja Requisitos de virtualização do Hyper-V para o SharePoint 2013 e Utilizar configurações de melhores práticas para as máquinas virtuais do SharePoint 2013 e o ambiente Hyper-V.
Observação
As conclusões nesta secção são específicas do hardware que compõe o ambiente. O ambiente pode ter alcançado o mesmo débito se o ambiente utilizasse servidores anfitriões Hyper-V mais, mas menos potentes, ou menos, mas servidores anfitriões Hyper-V mais potentes. Um aumento dos recursos de hardware no servidor de bases de dados não afetaria muito os resultados.
Resultados e gráficos
Nos gráficos a seguir, o eixo x mostra a alteração no número de servidores Web no farm. A escala começa com um servidor Web virtual e um servidor de banco de dados físico (1x1). O máximo é de oito servidores Web virtuais, um servidor de cache distribuído virtual dedicado (adicionado a quatro servidores Web) e um servidor de banco de dados físico (8x1x1).
Observação
Os gráficos nesta seção representam os valores médios para cada ponto de dados durante todo o teste. Todos os gráficos incluem a linha de base do RPS para as zonas Verde e Vermelho para mostrar a relação entre o RPS e fatores, como a latência, a utilização de recursos do servidor e a utilização do disco do SQL Server.
1. RPS
O gráfico a seguir mostra como a expansão afeta a linha de base do RPS.
2. Latência
O gráfico a seguir mostra como a expansão afeta a latência. Observe que a latência da zona verde permanece quase plana, mas a latência da zona vermelha apresenta aumentos que estão dentro dos limites aceitáveis
3. Utilização do processador do servidor Web e de memória
O gráfico a seguir mostra como a expansão afeta a utilização média do processador e da memória nos servidores Web. Observe que a utilização do processador e a utilização de memória na zona verde permanecem relativamente constante conforme o RPS aumenta.
A tendência de utilização do processador na Zona Vermelha está inativa. Esta tendência descendente reflete o facto de a procura média do processador do servidor Web com carga máxima diminuir gradualmente à medida que o número de servidores aumenta.
4. SQL operações de E/S do Servidor por segundo (IOPs) e utilização do processador
Os gráficos a seguir mostram como os valores de IOPs médio do disco (total e leituras/gravações) e de utilização do processador mudam à medida que o número de servidores Web é expandido. Os contadores de desempenho a seguir foram usados para medir os valores de IOPs:
PhysicalDisk: leituras de disco/s
PhysicalDisk: gravações de disco/s
Os valores de cada contador em toda a duração do teste estão na média e são adicionados para produzir o total de IOPs.
Observação
Uma vez que os dados da utilização da memória do SQL Server não se encontram disponíveis no momento dos nossos testes, estes dados não estão incluídos neste gráfico.
Importante
Esses resultados de teste de IOPs não são representativos de um ambiente de produção porque nosso conjunto de dados era muito menor em relação ao de um farm de produção. Assim, era possível que um percentual maior de dados fosse colocado em cache nos servidores Web do que seria possível em um ambiente de produção. Como colocamos um percentual maior dos dados em cache no servidor Web, os resultados de IOPs nesta seção são médias calculadas baseadas nos dados de teste disponíveis. Esperamos que nossos resultados de IOPs sejam, no geral, mais baixos do que as IOPs em ambiente de produção. Um teste completo de seu próprio farm em um ambiente piloto pode produzir resultados diferentes.
Observe que, nos gráficos desta seção, a utilização de IOPs e do processador do servidor de banco de dados mostra uma queda em seis servidores Web de front-end, enquanto o RPS continua a aumentar. Essa variação também é refletida na utilização do processador do servidor Web, conforme mostrado no gráfico anterior..
Isso mostra que a escala no farm alcançou um ponto em que a pressão máxima nos recursos do servidor farm foi alcançada usando a carga e o conjunto de dados da linha de base. Uma utilização média dos recursos do servidor é necessária para suportar a carga do farm.
A partir dessa tendência, é possível concluir o seguinte:
Se a carga de teste fosse aumentada no sexto ponto da escala do servidor Web, seria alcançado um RPS maior e, ao mesmo tempo, seria mantida uma curva plana na utilização de recursos do servidor.
Se o número de servidores Web fosse expandido ainda mais enquanto era mantida a mesma carga de teste, o RPS continuaria a aumentar ao mesmo tempo em que a pressão nos recursos do servidor teriam continuado em tendência descendente.
IOPs Totais do SQL Server
O gráfico a seguir mostra como a expansão afeta o total de IOPs.
IOPs do SQL Server divididos em operações de leitura e escrita
O gráfico a seguir mostra como a expansão afeta as IOPs, decompostas em leituras por segundo e gravações por segundo.
Utilização do processador DO SQL Server
O gráfico seguinte mostra como o aumento horizontal afeta a utilização do processador do SQL Server.
Confira também
Conceitos
Planejamento de desempenho no SharePoint Server 2013
Resultados de teste de capacidade e desempenho e recomendações (SharePoint Server 2013)