Estudo de caso sobre um ambiente de colaboração de intranet empresarial (SharePoint Server 2010)

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo contém orientações sobre planejamento de desempenho e capacidade para uma solução de colaboração de intranet empresarial que possui o Microsoft SharePoint Server 2010 como base. Ele inclui os seguintes tópicos:

• Especificações do ambiente de laboratório, como hardware, topologia de farm e configuração

• Conjunto de dados de farm de teste

• Análises de resultados de testes que devem ajudá-lo a determinar o hardware, a topologia e a configuração que você deve ter para implantar um ambiente semelhante e otimizar esse ambiente de acordo com as características de capacidade e desempenho apropriadas

Neste artigo:

• Introdução a este ambiente

• Glossário

• Visão geral

• Especificações

• Resultados e análises

Introdução a este ambiente

Este documento fornece orientações sobre escalabilidade horizontal e vertical de servidores em uma solução de colaboração de intranet empresarial do SharePoint Server 2010, com base em um ambiente de teste na Microsoft. O planejamento da capacidade informa sobre decisões de compra de hardware e de definição de configurações do sistema para otimizar a solução.

Diferentes cenários possuem requisitos distintos. Portanto, é importante complementar essas orientações com testes adicionais do seu próprio hardware e ambiente. Caso o seu design e sua carga de trabalho planejados sejam semelhantes ao ambiente descrito neste documento, você poderá usá-lo como base para tirar conclusões sobre a escalabilidade vertical e horizontal do seu ambiente.

Este documento inclui:

• Especificações, que incluem hardware, topologia e configuração

• A carga de trabalho, que é a demanda no farm, inclui o número de usuários e as características de uso

• O conjunto de dados, como tamanhos de bancos de dados

• Resultados e análises de testes para incrementar a escalabilidade horizontal de servidores Web

• Resultados e análises de testes para incrementar a escalabilidade vertical de servidores Web

• Resultados e análises de testes para incrementar a escalabilidade horizontal de servidores de bancos de dados

• Comparação entre o Microsoft Office SharePoint Server 2007 e o SharePoint Server 2010 no que diz respeito à taxa de transferência e ao efeito sobre servidores Web e de bancos de dados

O ambiente do SharePoint Server 2010 descrito neste documento é um ambiente de laboratório que reproduz um ambiente de produção em uma grande corporação. O ambiente de produção hospeda sites de equipes muito importantes e portais de publicação de equipes internas para colaboração empresarial, organizações, equipes e projetos. Os funcionários usam esse ambiente de produção para acompanhar projetos, colaborar em documentos e compartilhar informações dentro da organização. O ambiente inclui uma grande quantidade de pequenos sites usados para projetos específicos e pequenas equipes. Para obter detalhes sobre o ambiente de produção, consulte Enterprise intranet collaboration environment technical case study (SharePoint Server 2010).

Antes de ler este documento, você deve entender os principais conceitos subjacentes ao gerenciamento de capacidade no SharePoint Server 2010. A documentação a seguir poderá ajudá-lo a conhecer a abordagem recomendada para o gerenciamento de capacidade, com contexto para ajudar a fazer uso eficaz das informações aqui contidas, além de definir os termos usados em todo o documento.

• Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010

• Gerenciamento de capacidade do SharePoint Server 2010: Limites de software

Também sugerimos as seguintes leituras:

• Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010)

Glossário

Você encontrará alguns termos especializados neste documento. Este documento contém alguns dos principais termos e suas definições.

• RPS: solicitações por segundo. O número de solicitações recebidas por um farm ou servidor em um segundo. Esta é uma medida comum de carga de servidor e farm.

  Observe que as solicitações diferem dos carregamentos de página; cada página contém vários componentes, cada um deles cria uma ou mais solicitações quando a página é carregada. Portanto, um carregamento de página cria várias solicitações. Em geral, as verificações e os eventos de autenticação que usam recursos insignificantes não são contados nas medições RPS.

• Zona Verde: este é o estado em que o servidor pode manter o seguinte conjunto de critérios:

  • A latência no lado do servidor para pelo menos 75% das solicitações é menor que 1 segundo.

  • Todos os servidores têm uma utilização de CPU menor que 50%.

  Observação

  Como este ambiente de laboratório não tinha um rastreamento de pesquisa ativo em execução, o servidor de banco de dados foi mantido em uma taxa de utilização de 40% ou menos de CPU, para reservar 10% para a carga de rastreamento de pesquisa. Isso presume que o Administrador de Recursos do Microsoft SQL Server é usado em produção para limitar a carga de rastreamento de pesquisa a 10% de CPU.

  • A taxa de falha é menor que 0,01%.

• Zona Vermelha (Máx.): este é o estado em que o servidor pode manter o seguinte conjunto de critérios:

  • O recurso de limitação de solicitação HTTP está habilitado, mas nenhum erro 503 (Servidor Ocupado) é retornado.

  • A taxa de falha é menor que 0,1%.

  • A latência no servidor é menor que 3 segundos para pelo menos 75% das solicitações.

  • A utilização de CPU do servidor de banco de dados é menor que 80%, o que permite que 10% sejam reservados para a carga de rastreamento de pesquisa, limitada pelo uso do Administrador de Recursos do SQL Server.

• AxBxC (notação gráfica): este é o número de servidores Web, servidores de aplicativos e servidores de bancos de dados respectivamente em um farm. Por exemplo, 8x1x2 significa que o ambiente contém 8 servidores Web, 1 servidor de aplicativos e 2 servidores de bancos de dados.

• MDF e LDF: arquivos físicos do SQL Server. Para obter mais informações, consulte Arquitetura de arquivos e grupos de arquivos.

Visão geral

Esta seção apresenta uma visão geral de nossa abordagem de dimensionamento, da relação entre este ambiente de laboratório e um ambiente de estudo de caso similar e de nossa metodologia de teste.

Abordagem de dimensionamento

Esta seção descreve a ordem específica que recomendamos para o dimensionamento de servidores em seu ambiente. Trata-se da mesma abordagem que utilizamos no dimensionamento deste ambiente de laboratório. Essa abordagem permitirá que você encontre a melhor configuração para sua carga de trabalho. Ela pode ser descrita da seguinte forma:

• Primeiro, incrementamos a escalabilidade horizontal dos servidores Web. Isso foi feito o máximo possível sob a carga de trabalho testada, até que o servidor de banco de dados se afunilasse e não pudesse mais acomodar nenhuma outra solicitação de servidores Web.

• Segundo, incrementamos a escalabilidade horizontal do servidor de banco de dados movendo metade dos bancos de dados de conteúdo para outro servidor de banco de dados. Neste ponto, os servidores Web não estavam criando carga suficiente nos servidores de bancos de dados. Portanto, sua escalabilidade horizontal foi ajustada adicionalmente.

• Para testar a escalabilidade vertical, tentamos outra opção: a escalabilidade vertical de servidores Web em vez de sua escalabilidade horizontal. Geralmente, é preferível incrementar a escalabilidade horizontal de servidores Web a incrementar sua escalabilidade vertical porque a escalabilidade horizontal fornece melhor redundância e disponibilidade.

Correlacionando o ambiente de laboratório com um ambiente de produção

O ambiente de laboratório delineado neste documento é um modelo em menor escala de um ambiente de produção na Microsoft e, embora haja diferenças significativas entre os dois ambientes, pode ser útil examiná-los lado a lado porque ambos são ambientes de colaboração empresarial em que os padrões observados devem ser similares.

O ambiente de laboratório contém um subconjunto dos dados do ambiente de produção e algumas modificações na carga de trabalho. Isso afeta os resultados do teste no que se refere ao uso de memória do servidor Web, pois o cache de objeto no ambiente de produção recebe uma grande quantidade de dicas sobre sites exclusivos e, portanto, usa mais memória. O ambiente de laboratório também tem menos dados e a maioria deles está armazenada em cache na memória, ao contrário do ambiente de produção, que transporta sete terabytes de dados, para que o servidor de banco de dados no ambiente de produção execute mais leituras de disco do que o servidor de banco de dados no ambiente de laboratório. Similarmente, o hardware usado no ambiente de laboratório é bastante diferente do ambiente de produção que ele modela, pois existe menos demanda desses recursos. O ambiente de laboratório depende de hardware mais facilmente disponível.

Para entender melhor as diferenças entre os ambientes, leia a seção Especificações neste documento e compare-as com as especificações no artigo Enterprise intranet collaboration environment technical case study (SharePoint Server 2010).

Observações sobre metodologia e teste

Este documento fornece resultados de um ambiente de laboratório de teste. Como se tratava de um ambiente de laboratório e não de produção, foi possível controlar certos fatores para mostrar aspectos específicos de desempenho desta carga de trabalho. Além disso, alguns elementos do ambiente de produção, listados aqui, não foram incluídos no ambiente de laboratório para simplificar a sobrecarga de testes. Não é recomendável omitir esses elementos em ambientes de produção.

• Entre as execuções de testes, modificamos somente uma variável de cada vez para facilitar a comparação de resultados.

• Os servidores de bancos de dados usados neste ambiente de laboratório não faziam parte de um cluster porque os testes em questão não exigiam redundância.

• O rastreamento de pesquisa não estava sendo executado durante os testes, embora pudesse estar sendo executado em um ambiente de produção. Para levar isso em conta, reduzimos a utilização de CPU do SQL Server em nossa definição de ‘Zona Verde’ e ‘Máx.’ para acomodar os recursos que um rastreamento de pesquisa teria consumido se estivesse sendo executado ao mesmo tempo que nossos testes. Para saber mais a respeito, leia Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Especificações

Esta seção apresenta informações detalhadas sobre hardware, software, topologia e configuração do ambiente de laboratório.

Hardware

As seções a seguir descrevem o hardware usado neste ambiente de laboratório.

Servidores Web e de aplicativos

Há de um a oito servidores Web no farm, além de um servidor de aplicativos.

Servidores de bancos de dados

Existem de dois a três servidores de bancos de dados, até dois executando a instância do SQL Server padrão que hospeda os bancos de dados de conteúdo. O banco de dados de registro em log não é acompanhado neste documento.

Topologia

O diagrama a seguir mostra a topologia neste ambiente de laboratório:

Configuração

Para permitir máximo desempenho, foram feitas as alterações de configuração a seguir neste ambiente de laboratório.

Carga de trabalho

A combinação transacional do ambiente de laboratório descrito neste documento assemelha-se às características da carga de trabalho de um ambiente de produção na Microsoft. Para obter mais informações sobre o ambiente de produção, consulte Enterprise intranet collaboration environment technical case study (SharePoint Server 2010).

Aqui estão alguns detalhes da combinação de testes de laboratório executados no SharePoint Server 2010 comparados ao ambiente de produção. Embora existam algumas pequenas diferenças nas cargas de trabalho, ambos representam uma combinação transacional típica em um ambiente de colaboração empresarial.

Conjunto de dados

O conjunto de dados do ambiente de laboratório descrito neste documento é um subconjunto do conjunto de dados de um ambiente de produção na Microsoft. Para obter mais informações sobre o ambiente de produção, consulte Enterprise intranet collaboration environment technical case study (SharePoint Server 2010).

Resultados e análises

Os resultados a seguir estão ordenados com base na abordagem de dimensionamento descrita na seção Visão geral deste documento.

Escalabilidade horizontal de servidores Web

Esta seção descreve os resultados do teste obtidos quando incrementamos a escalabilidade horizontal do número de servidores Web neste ambiente de laboratório.

Metodologia de teste

• Adicione servidores Web com as mesmas especificações de hardware, mantendo o restante do farm igual.

• Meça o número de RPS, a latência e a utilização de recursos.

Análise

Em nossos testes, descobrimos o seguinte:

• A escalabilidade vertical do ambiente foi incrementada para quatro servidores Web por servidor de banco de dados. Entretanto, o aumento na taxa de transferência foi não linear, especialmente na adição do quarto servidor Web.

• Após quatro servidores Web, não há mais ganhos na taxa de transferência com a adição de outros servidores Web porque o afunilamento neste ponto é a utilização de CPU do servidor de banco de dados.

• A latência média foi quase constante durante o teste todo, não afetada pelo número de servidores Web e pela taxa de transferência.

Gráficos de resultados

Nos gráficos a seguir, o eixo x mostra a alteração no número de servidores Web no farm, dimensionando de um servidor Web (1x1x1) para cinco servidores Web (5x1x1).

1. Latência e RPS

O gráfico a seguir mostra como a escalabilidade horizontal (adição de servidores Web) afeta a latência e o número de RPS.

2. Utilização do processador

O gráfico a seguir mostra como a escalabilidade horizontal dos servidores Web afeta a utilização do processador nos servidores Web e no servidor de banco de dados.

3. IOPs (Operações de E/S por seção) do SQL Server para arquivos MDF e LDF

Os gráficos a seguir mostram como as IOPs nos bancos de dados de conteúdo são alteradas quando há incremento de escalabilidade horizontal no número de servidores Web. Para medir esses valores, examine os seguintes contadores de desempenho:

• PhysicalDisk: leituras de disco/s

• PhysicalDisk: gravações em disco/s

Neste ambiente de laboratório, determinamos que nossos dados em IOPs não eram representativos de um ambiente de produção porque nosso conjunto de dados era tão pequeno que poderíamos armazenar ainda uma boa parte dele em cache do que seria possível no ambiente de produção que estamos modelando. Calculamos leituras projetadas multiplicando o valor dos dados que tínhamos do laboratório de gravações/segundo pela taxa de leituras para gravações em nosso ambiente de produção. Os resultados nesta seção são médias. Mas existem também picos que ocorrem durante determinadas operações que devem ser levados em conta. Para saber mais sobre como estimar IOPs necessárias, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Máximo:

Zona Verde:

Exemplo de como ler esses gráficos:

Uma organização com uma carga de trabalho similar àquela descrita neste documento, que espera que haja 300 RPS em sua zona verde, poderia usar uma topologia de 3x1x1 e aproximadamente 600 leituras/s de Disco Físico no arquivo MDF.

Escalabilidade horizontal em servidores de bancos de dados

Esta seção descreve os resultados do teste obtidos quando incrementamos a escalabilidade horizontal do número de servidores de bancos de dados neste ambiente de laboratório.

Metodologia de teste

• Tenha dois bancos de dados de conteúdo em um único servidor de banco de dados e depois divida-os em dois servidores para dobrar efetivamente os núcleos do processador e a memória disponível para os servidores de bancos de dados no ambiente.

• Mantenha constante a capacidade total de IOPs, mesmo ao adicionar um servidor de banco de dados. Isso significa que o número de leituras/s e de gravações/s que o disco poderia executar para cada banco de dados de conteúdo não foi alterado, apesar da divisão do conteúdo em dois servidores de bancos de dados em vez de um.

Análise

• O primeiro afunilamento no ambiente 4x1x2 foi a utilização de CPU do servidor de banco de dados. Ficou perto de uma escala linear quando adicionamos mais poder de processador e memória.

• O dimensionamento para quatro servidores Web e 2 servidores de bancos de dados não proporcionou RPS adicional porque a utilização de CPU nos servidores Web chegou perto de 100%.

• Quando incrementamos a escalabilidade horizontal dos servidores de bancos de dados (adicionando um servidor de banco de dados) e adicionamos quatro servidores Web, o desempenho foi dimensionado quase linearmente. O afunilamento nesse ponto passou da utilização de CPU do servidor de banco de dados para as IOPs de disco de bancos de dados de conteúdo.

• Nenhum teste adicional foi realizado neste ambiente de laboratório para a escalabilidade horizontal ultrapassar 8x1x2. Entretanto, esperamos que uma capacidade adicional de IOPs aumente a taxa de transferência.

• Foi observada uma correlação entre as IOPs usadas e o número de RPS atingido pelos testes

Gráficos de resultados

Nos gráficos a seguir, o eixo x quase sempre mostra quatro servidores Web com 1 servidor de aplicativos e 1 servidor de banco de dados (4x1x1) dimensionado para oito servidores Web com dois servidores de bancos de dados (8x1x2). Alguns também mostram 1x1x1 ou 4x1x2.

1. Latência e RPS

O gráfico a seguir mostra como a escalabilidade horizontal em servidores Web e em servidores de bancos de dados afeta a latência e o número de RPS.

2. Utilização do processador

Os gráficos a seguir mostram como a escalabilidade horizontal afeta a utilização do processador.

3. Utilização de memória na escalabilidade horizontal

Durante todos os nossos testes, observamos que quanto maior o número de conjuntos de sites em um ambiente, mais memória é consumida. Por exemplo, nos testes aqui em que 181 conjuntos de sites foram acessados, o principal processo w3wp usou até 1,8 GB de RAM. Para ver mais exemplos, consulte Performance and capacity technical case studies (SharePoint Server 2010). Conteúdo adicional sobre requisitos de memória para números maiores de conjuntos de sites está em desenvolvimento. Confira posteriormente o conteúdo novo e atualizado.

4. IOPs do SQL Server para arquivos MDF e LDF

Os gráficos a seguir mostram como as IOPs são alteradas quando há incremento de escalabilidade horizontal no número de servidores Web e de servidores de bancos de dados.

RPS máximo

RPS de Zona Verde

Escalabilidade vertical de servidores Web

Esta seção descreve os resultados do teste obtidos quando incrementamos a escalabilidade vertical de servidores Web neste ambiente de laboratório.

Metodologia de teste

• Adicione mais processadores de servidores Web, mas mantenha o restante do farm igual.

Análise

• A escala é linear até oito núcleos de processador.

• Os testes mostram que o ambiente pode aproveitar as vantagens de uma caixa de vinte e quatro núcleos, embora exista alguma degradação à medida que os vinte e quatro núcleos se aproximam.

Gráficos de resultados

No gráfico a seguir, o eixo x é o número de processadores e a quantidade de RAM no servidor Web. O gráfico a seguir mostra como a escalabilidade vertical (adição de processadores) afeta o número de RPS no servidor Web.

Comparando o SharePoint Server 2010 e o Office SharePoint Server 2007

Esta seção especifica informações sobre como o teste de capacidade desta carga de trabalho variou entre o SharePoint Server 2010 e o Microsoft Office SharePoint Server 2007.

Carga de trabalho

Para comparar o SharePoint Server 2010 com o Office SharePoint Server 2007, foi usada uma combinação de testes diferente daquela delineada na seção Especificações, pois algumas operações do SharePoint Server 2010 não estavam disponíveis no Office SharePoint Server 2007. A combinação de testes do Office SharePoint Server 2007 foi inspirada pelo mesmo ambiente de produção que os testes do SharePoint Server 2010 seguem. Entretanto, isso foi registrado antes da atualização para o SharePoint Server 2010 nesse ambiente.

O gráfico a seguir mostra a combinação de testes dos ambientes de laboratório e produção do Office SharePoint Server 2007.

Metodologia de teste

• Os testes realizados nesta comparação criaram um ambiente do Office SharePoint Server 2007, testaram esse ambiente com a carga de trabalho delineada anteriormente nesta seção e depois atualizaram os bancos de dados de conteúdo do SharePoint Server 2010 sem alterar os clientes que usam o ambiente, nem fazer atualização visual. Esse ambiente atualizado foi então testado novamente de acordo com os resultados do SharePoint Server 2010 com a mesma combinação de testes que inclui somente operações do Office SharePoint Server 2007.

• O conjunto de dados não foi modificado após a atualização dos bancos de dados de conteúdo de testes do SharePoint Server 2010.

• A combinação de testes do Office SharePoint Server 2007 exclui novas operações específicas do SharePoint Server 2010 e assemelha-se à solução de colaboração de intranet empresarial no mesmo ambiente de produção do Office SharePoint Server 2007, como descrito na seção Carga de trabalho.

Análise

• Quando o mesmo número de servidores Web são forçados até sua taxa de transferência máxima no SharePoint Server 2010 e no Office SharePoint Server 2007, o SharePoint Server 2010 atinge uma taxa de transferência 20% menor comparada à do Office SharePoint Server 2007.

• Quando a escalabilidade horizontal dos servidores Web foi incrementada para maximizar o uso do servidor de banco de dados, o SharePoint Server 2010 pôde atingir uma taxa de transferência 25% melhor comparada ao Office SharePoint Server 2007. Isso reflete as melhorias feitas no SharePoint Server 2010 para sustentar implantações maiores.

• Quando a escalabilidade horizontal dos servidores Web foi incrementada para maximizar o uso de servidores de bancos de dados, o SharePoint Server 2010 foi associado à utilização de CPU do SQL Server, enquanto o Office SharePoint Server 2007 foi associado ao Bloqueio na camada de banco de dados. Isso significa que, se o poder de processamento disponível for aumentado para os servidores de bancos de dados, o SharePoint Server 2010 poderá atingir melhor taxa de transferência do que seria possível com o mesmo hardware usando o Office SharePoint Server 2007. Isso é causado pelos mecanismos de bloqueio no banco de dados no Office SharePoint Server 2007, que não são afetados pelo hardware aperfeiçoado, de forma que não foi possível forçar a utilização de CPU do servidor de banco de dados para mais de 80%.

• Como resultado das descobertas delineadas nesta seção, no Office SharePoint Server 2007, a taxa de transferência máxima possível foi atingida em uma topologia de 5x0x1, enquanto no SharePoint Server 2010, a taxa de transferência máxima possível com a mesma carga de trabalho foi atingida em uma topologia de 7x0x1, com um aumento de 25% no total de RPS.

Gráficos de resultados

O gráfico a seguir mostra a taxa de transferência sem a escalabilidade horizontal de servidores Web.

O gráfico a seguir mostra a taxa de transferência quando os servidores Web estavam na escalabilidade horizontal máxima.

See Also

Other Resources

Centro de recursos: Gerenciamento de capacidade do SharePoint 2010