Planejamento de capacidade para SharePoint Server 2010

Artigo
03/07/2017

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve como planejar a capacidade de um farm do Microsoft SharePoint Server 2010. Com uma boa estimativa e um bom entendimento do planejamento e gerenciamento da capacidade, você pode aplicar seu conhecimento para dimensionar o sistema. Dimensionamento é o termo usado para descrever a seleção e configuração da arquitetura de dados apropriada, topologia lógica e física e hardware para uma plataforma de solução. Há diversas considerações de uso e gerenciamento da capacidade que afetam o modo como você deve determinar as opções mais adequadas de hardware e configuração.

Antes de ler este artigo, leia Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010.

Neste artigo, descrevemos as etapas que devem ser seguidas para garantir um gerenciamento de capacidade eficaz em seu ambiente. Cada etapa exige algumas informações para que sua execução seja bem-sucedida e tem um conjunto de resultados finais que você vai usar na etapa subsequente. Para cada etapa, esses requisitos e resultados finais estão descritos em tabelas.

Neste artigo:

Etapa 1: Modelo
Etapa 2: Design
Etapa 3: Piloto, Teste e Otimização
Etapa 4: Implantação
Etapa 5: Monitoração e Manutenção

Etapa 1: Modelo

A modelagem do seu ambiente baseado no SharePoint Server 2010 começa com a análise das soluções existentes e a estimativa da demanda e das metas esperadas para a implantação que pretende configurar. Comece coletando informações sobre a base de usuários, os requisitos de dados, as metas de latência e produtividade e documente os recursos do SharePoint Server que deseja implantar. Use esta seção para compreender os dados que deve coletar, como coletá-los e usá-los nas etapas seguintes.

Compreender a carga de trabalho e o conjunto de dados esperados

O dimensionamento adequado de uma implementação do SharePoint Server 2010 requer estudo e compreensão das características da demanda esperada pela sua solução. A compreensão da demanda requer a capacidade de descrever tanto as características da carga de trabalho, como número de usuários e operações utilizadas mais frequentemente, quanto as características do conjunto de dados, como dimensionamento e distribuição de conteúdo.

Esta seção pode ajudar a compreender algumas métricas e parâmetros específicos que devem ser coletados e os mecanismos que podem ser usados para a coleta.

Carga de trabalho

A carga de trabalho descreve a demanda à qual o sistema deverá atender, a base de usuários e as características de uso. A tabela a seguir apresenta algumas métricas fundamentais úteis na determinação da carga de trabalho. É possível usar esta tabela para registrar essas métricas à medida que são coletadas.

Características da Carga de Trabalho	Valor
Média do RPS diário
Média do RPS no horário de pico
Número total de usuários exclusivos por dia
Média diária de usuários simultâneos
Usuários simultâneos no horário de pico
Número total de solicitações por dia
Distribuição da carga de trabalho esperada	Número de solicitações por dia
Navegador da Web - Rastreamento de Pesquisa
Navegador da Web - Interação Geral de Colaboração
Navegador da Web - Interação Social
Navegador da Web - Interação Geral
Navegador da Web - Office Web Apps
Clientes do Office
Cliente do OneNote
SharePoint Workspace
Sincronização de RSS do Outlook
Outlook Social Connector
Outras interações (Aplicativos Personalizados/serviços Web)

Usuários simultâneos – É mais comum medir a simultaneidade das operações executadas no farm de servidores como o número de usuários distintos que geram solicitações em determinado intervalo de tempo. As métricas principais são a média diária e os usuários simultâneos na carga de pico.
Solicitações por segundo (RPS) – RPS é um indicador normalmente usado para descrever a demanda do farm de servidores expressada no número de solicitações processadas pelo farm por segundo, mas sem diferenciar entre o tipo ou o tamanho das solicitações. A base de usuários de cada organização gera uma carga no sistema a uma taxa que depende das características de uso exclusivas da organização. Consulte a seção Glossário em Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010 para obter mais informações sobre este termo.
Total de solicitações diárias – Total de solicitações diárias é um bom indicador da carga geral à qual o sistema deve atender. É mais comum medir todas as solicitações, exceto as solicitações de handshake de autenticação (status HTTP 401) em um período de 24 horas.
Total de usuários diários – Total de usuários é outro indicador fundamental da carga geral à qual o sistema deve atender. Essa medida é o número real de usuários exclusivos em um período de 24 horas, e não o número total de funcionários da organização.

Observação

O número total de usuários diários pode indicar o crescimento potencial da carga no farm. Por exemplo, se o número de usuários potenciais for de 100 mil funcionários, 15 mil usuários diários indicam que a carga pode crescer significativamente com o tempo, à medida que cresce a adoção dos usuários.
Distribuição da Carga de Trabalho – Compreender a distribuição das solicitações com base nos aplicativos clientes que interagem com o farm pode ajudar a prever a tendência esperada e as alterações de carga após a migração para o SharePoint Server 2010. Conforme os usuários fazem a transição para as versões mais recentes do cliente, como o Office 2010, e começam a usar os novos recursos, é esperado o crescimento de novos padrões de carga, RPS e solicitações totais. Para cada cliente, podemos descrever o número de usuários distintos que o utilizam em determinado intervalo de tempo do dia e a quantidade de solicitações totais que o cliente ou o recurso gera no servidor.

Por exemplo, o gráfico a seguir mostra um instantâneo de um ambiente interno real da Microsoft que trabalha com uma solução social típica. Neste exemplo, é possível ver que a maior parte da carga é gerada pelo rastreador de pesquisa e pela navegação na Web comum do usuário final. É possível também observar que existe uma carga significativa que foi introduzida pelo novo recurso Outlook Social Connector (6,2% das solicitações).

Distribuição típica da carga diária de solicitações

Estimando sua carga de trabalho de produção

Na estimativa da produtividade necessária que seu farm precisa manter, comece estimando a combinação de transações que será usada no farm. Concentre-se na análise das transações utilizadas mais frequentemente às quais o sistema atenderá, conhecendo a frequência com que elas serão usadas e por quantos usuários. Isso o ajudará a validar no futuro se o farm será capaz de manter essa carga no teste de pré-produção.

O diagrama a seguir descreve a relação entre a carga de trabalho e a carga no sistema:

Capacidade - Diagrama de fluxo de trabalho

Para estimar sua carga de trabalho esperada, colete as seguintes informações:

Identifique as interações do usuário, como navegações comuns de páginas da Web, downloads e carregamentos de arquivos, modos de exibição e edições do Office Web Application no navegador, interações de coautoria, sincronizações de sites do SharePoint Workspace, Conexões Sociais do Outlook, sincronização de RSS (no Outlook ou outros visualizadores), Transmissões do PowerPoint, blocos de anotações compartilhados do OneNote, pastas de trabalho compartilhadas do Serviço do Excel, aplicativos compartilhados do Serviço do Access e outros. Consulte a seção Serviços e recursos do artigo Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010 para obter mais informações. Mantenha o foco na identificação das interações que podem ser exclusivas à sua implantação e reconheça o impacto esperado desse tipo de carga. Alguns exemplos podem ser o uso significativo de Formulários do InfoPath, Cálculos do Serviço do Excel e soluções semelhantes dedicadas.
Identifique as operações de sistema, como rastreamentos incrementais de Pesquisa, backups diários, trabalhos de timer de sincronização de perfis, processamento do Web Analytics, registro dos trabalhos de timer e outros.
Calcule o número total de usuários esperados por dia que utilizarão cada recurso, obtenha os usuários simultâneos esperados e as Solicitações de alto nível por segundo. Há algumas suposições a fazer, como a simultaneidade presente e o fator de RPS por usuários simultâneos que é diferente entre os recursos. Convém usar a tabela de carga de trabalho apresentada anteriormente nesta seção para suas estimativas. É importante focar os horários de pico, em vez da produtividade média. Planejando a atividade de pico, você é capaz de dimensionar adequadamente a sua solução baseada no SharePoint Server 2010.

Caso tenha uma solução do Office SharePoint Server 2007 existente, você poderá extrair os arquivos de log do IIS ou recorrer a outras ferramentas de monitoramento da Web para entender melhor alguns comportamentos esperados da solução existente, ou consulte as instruções na seção a seguir para obter mais detalhes. Se não estiver migrando de uma solução existente, preencha a tabela usando estimativas aproximadas. Nas etapas subsequentes, será preciso validar suas suposições e ajustar o sistema.

Analisando os logs do IIS do SharePoint Server 2010

Para descobrir as métricas principais relacionadas a uma implantação do SharePoint Server 2010 existente, como a quantidade de usuários ativos, como eles utilizam o sistema, que tipo de solicitações estão chegando e de que tipo de cliente elas são originadas, é necessário extrair os dados dos logs ULS e do IIS. Uma das maneiras mais fáceis de adquirir esses dados é usar o Analisador de Logs, uma ferramenta avançada da Microsoft disponível gratuitamente para download. O Analisador de Logs é capaz de ler e gravar em uma variedade de formatos de texto e binários, incluindo todos os formatos do IIS.

Para obter informações detalhadas sobre como analisar o uso do SharePoint Server 2010 por meio do Analisador de Logs, leia o artigo sobre como analisar o uso dos Produtos e Tecnologias do Microsoft SharePoint (https://www.microsoft.com/downloads/en/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en).

É possível baixar o Analisador de Logs 2.2 pelo site https://www.microsoft.com/downloads/en/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displayLang=en.

Conjunto de dados

O conjunto de dados descreve o volume de conteúdo armazenado no sistema e como ele pode ser distribuído no repositório de dados. A tabela a seguir apresenta algumas métricas fundamentais úteis na determinação do conjunto de dados. É possível usar esta tabela para registrar essas métricas à medida que são coletadas.

Objeto	Valor
Tamanho do BD (em GB)
Número de BDs de Conteúdo
Número de conjuntos de sites
Número de aplicativos web
Número de sites
Tamanho do índice de pesquisa (número de itens)
Número de documentos
Número de listas
Tamanho médio dos sites
Tamanho do maior site
Número de perfis de usuário

Tamanho do conteúdo – Saber o tamanho do conteúdo que você espera armazenar no sistema do SharePoint Server 2010 é importante para o planejamento e a arquitetura do armazenamento do sistema, e também para o dimensionamento adequado da solução de Pesquisa que vai rastrear e indexar esse conteúdo. O tamanho do conteúdo está descrito no espaço total em disco. Se estiver migrando conteúdo de uma implantação existente, você pode achar simples identificar o tamanho total que vai mover; enquanto no planejamento, você deve deixar espaço para o crescimento com o passar do tempo, baseado na tendência prevista.
Número total de documentos – Além do tamanho dos dados, é importante acompanhar o número geral de itens. O sistema reage de forma diferente quando 100 GB dos dados são constituídos de 50 arquivos de 2 GB cada ou de 100.000 arquivos de 1 KB cada. Em implantações maiores, quanto menor o estresse em um único item, melhor o desempenho. Um conteúdo amplamente distribuído, como vários arquivos menores entre diversos sites e conjuntos de sites, é mais fácil de ser atendido do que somente uma biblioteca grande de documentos com arquivos muito grandes.
Tamanho máximo do conjunto de sites – É importante identificar qual é a maior unidade de conteúdo que você vai armazenar no SharePoint Server 2010. Geralmente, isso é uma necessidade organizacional que o impede de dividir essa unidade de conteúdo. O tamanho médio de todos os conjuntos de sites e o número total estimado de conjuntos de sites são indicadores adicionais que o ajudam a identificar a arquitetura de dados de sua preferência.
Características de dados dos aplicativos de serviço – Além de analisar as necessidades de armazenamento do repositório de conteúdo, analise e calcule os tamanhos de outros repositórios do SharePoint Server 2010, incluindo:
Tamanho total do índice de Pesquisa
O tamanho total do banco de dados de perfil com base no número de usuários no repositório de perfil
O tamanho total do banco de dados social com base no número esperado de marcas, colegas e atividades
O tamanho do repositório de metadados
O tamanho do banco de dados de uso
O tamanho do banco de dados do Web Analytics

Para obter mais informações sobre como estimar os tamanhos de banco de dados, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Definindo as metas de desempenho e confiabilidade do farm

Um dos resultados finais da Etapa 1: Modelo é o bom entendimento das metas de desempenho e confiabilidade mais adequadas às necessidades da sua organização. Uma solução do SharePoint Server projetada adequadamente deve ser capaz de atingir os "quatro noves" (99,99%) de duração da operação com capacidade de resposta do servidor em milésimos de segundo.

Os indicadores usados para descrever o desempenho e a confiabilidade do farm podem incluir:

Disponibilidade do servidor – Geralmente, descrita pela porcentagem de duração da operação geral do sistema. Convém acompanhar qualquer tempo de inatividade inesperado e comparar a disponibilidade geral com a meta definida para a organização. As metas são normalmente descritas por alguns noves (isto é, 99%, 99,9%, 99,99%).
Capacidade de resposta do servidor – O tempo que leva para o farm atender às solicitações é um bom indicador para acompanhar a integridade do farm. Esse indicador é normalmente chamado de latência do servidor, e é comum usar a latência média ou mediana (50 percentil) das solicitações diárias que são atendidas. As metas são normalmente descritas em milésimos de segundo ou em segundos. Observe que se a sua organização tem uma meta para atender páginas do SharePoint Server 2010 em menos de dois segundos, o objetivo do servidor precisa estar em milésimos de segundo para dar tempo para a página atingir o cliente pela rede e tempo para a renderização no navegador. Em geral, tempos mais longos de resposta do servidor são uma indicação de farm com problemas, já que normalmente resultam em impacto na produtividade, e o RPS raramente conseguirá acompanhar se você gastar mais de um segundo na maioria das solicitações no servidor.
Capacidade de pico do servidor – Outro bom indicador de latência no servidor que vale a pena acompanhar é o comportamento dos 5% das solicitações mais lentas de todas. As solicitações mais lentas em geral são aquelas que chegam ao sistema quando ele está sob uma carga maior ou, mais comumente, são as solicitações impactadas por atividades menos frequentes que ocorrem durante a interação dos usuários com o sistema. Um sistema íntegro é aquele que também tem as solicitações mais lentas sob controle. A meta aqui é semelhante à Capacidade de Resposta do Servidor exceto que, para atingir a resposta em milésimos de segundo na capacidade de pico do servidor, você precisará construir o sistema com muitos recursos sobressalentes para lidar com os picos de carga.
Utilização de recursos do sistema – Outros indicadores comuns usados para acompanhar a integridade do sistema são uma coleção de contadores de sistema que indicam a integridade de cada servidor na topologia do farm. Os indicadores utilizados mais frequentemente são % de utilização da CPU e Memória Disponível; porém, há vários contadores adicionais que podem ajudar a identificar um sistema com problemas. Você encontra mais detalhes na Etapa 5: Manutenção.

Etapa 2: Design

Agora que já concluiu a coleta de alguns fatos ou estimativas sobre a solução que precisa entregar, você está pronto para começar a próxima etapa de criação de uma arquitetura proposta prevista para atender à demanda esperada.

No fim desta etapa, você deverá ter sua topologia física criada e um layout para a topologia lógica, de forma que seja capaz de realizar todas as ordens de compra necessárias.

As especificações de hardware e o número de computadores esquematizados estão totalmente relacionados. Para tratar de uma carga específica, há várias soluções que você pode escolher para implantação. É comum usar um pequeno conjunto de computadores fortes (dimensionamento vertical) ou um conjunto maior de computadores menores (dimensionamento horizontal). Cada solução tem suas vantagens e desvantagens quando se trata de capacidade, redundância, potência, custo, espaço e outras considerações.

É recomendável começar esta etapa determinando a arquitetura e topologia. Defina como pretende esquematizar os diferentes farms e serviços em cada farm e, em seguida, escolha as especificações de hardware para cada servidor individual em seu design. É possível também executar este processo identificando as especificações de hardware esperadas para implantação (muitas organizações estão restritas a determinados padrões da empresa) e, na sequência, definir a arquitetura e topologia.

Use a tabela a seguir para registrar seus parâmetros de design. Os dados incluídos são apenas exemplos e não devem ser utilizados para dimensionar seu farm. Sua intenção é demonstrar como usar esta tabela com seus próprios dados.

Função	Tipo (Padrão ou virtual)	Número de computadores	Processamentos	RAM	IOPS necessário	Tamanho do disco SO+Log	Unidade de dados
Servidores Web	Virtual	4	4 núcleos	8	N/A	400 GB	N/A
Servidor de banco de dados de conteúdo	Padrão	1 cluster	4 núcleos quádruplos 2.33 (GHz)	48	2 mil	400 GB	20 discos de 300 GB A 15 mil RPM
Servidores de aplicativos	Virtual	4	4 núcleos	16	N/A	400 GB	N/A
Servidor Web de Destino de Rastreamento de Pesquisa	Virtual	1	4 núcleos	8	N/A	400 GB	N/A
Servidor de Consulta de Pesquisa	Padrão	2	2 núcleos quádruplos 2.33 (GHz)	32	N/A	400 GB	500 GB
Servidor do Rastreador de Pesquisa	Padrão	2	2 núcleos quádruplos 2.33 (GHz)	16	400	400 GB	N/A
Servidor de banco de dados de Rastreamento de Pesquisa	Padrão	1 cluster	4 núcleos quádruplos 2.33 (GHz)	48	4 mil (ajustado para leitura)	100 GB	16 discos de 150 GB a 15 mil RPM
Banco de dados de Repositório de Propriedades de Pesquisa + Servidor de banco de dados de administração	Padrão	1 cluster	4 núcleos quádruplos 2.33 (GHz)	48	2 mil (ajustado para gravação)	100 GB	16 discos de 150 GB a 15 mil RPM

Determinar a arquitetura de ponto de partida

Esta seção descreve como selecionar uma arquitetura de ponto de partida.

Ao implantar o SharePoint Server 2010, você pode escolher dentre várias topologias para implementar a solução. É possível implantar um servidor único ou dimensionar vários servidores em um farm do SharePoint Server com servidores de banco de dados clusterizados ou espelhados e servidores de aplicativos discretos para diversos serviços. Posteriormente, você selecionará as configurações de hardware baseadas nos requisitos de cada uma das funções, com base nas necessidades de capacidade, disponibilidade e redundância.

Comece analisando as diferentes arquiteturas de referência e descubra a estrutura do seu farm, decida se vai dividir a solução em vários farms ou federar alguns serviços, como pesquisa, em um farm dedicado. Consulte a seção Arquiteturas de referência em Visão geral do gerenciamento da capacidade e dimensionamento do SharePoint Server 2010 para obter mais informações.

Estudos de caso técnicos do SharePoint Server 2010

As diretrizes de gerenciamento de capacidade para o SharePoint Server 2010 incluem um número de estudos de caso técnicos de ambientes de produção existentes que apresentam uma descrição detalhada dos ambientes de produção baseados no SharePoint Server. Outros estudos de caso técnicos serão publicados com o tempo; eles servirão como referência para criar um ambiente baseado no SharePoint Server para fins específicos.

É possível usar estes estudos de caso como referência ao criar a arquitetura das soluções do SharePoint Server, principalmente se achar a descrição desses diferenciadores-chave específicos da implantação parecidos com as demandas e metas da solução que está arquitetando.

Estes documentos descrevem as seguintes informações para cada estudo de caso registrado:

Especificações, como hardware, topologia e configuração do farm;
Carga de trabalho, incluindo a base de usuários e as características de uso;
Conjunto de dados, incluindo tamanhos de conteúdos, características e distribuição do conteúdo;
Integridade e desempenho, incluindo um conjunto de indicadores registrados descrevendo as características de confiabilidade e desempenho do farm.

Para obter mais informações, baixe os documentos relevantes da página de estudos de caso técnicos sobre desempenho e capacidade (https://technet.microsoft.com/pt-br/library/cc261716.aspx).

Selecionar o hardware

A seleção das especificações corretas para os computadores do farm é uma etapa crucial para garantir confiabilidade e desempenho adequados à sua implantação. Um conceito fundamental que você deve ter em mente é o planejamento para a carga de pico e os horários de pico; em outras palavras, quando o farm está operando em condições de carga média, deve haver recursos suficientes disponíveis para atender à maior demanda esperada e ainda atingir as metas de latência e produtividade.

Os recursos básicos de hardware de capacidade e desempenho dos servidores refletem as quatro principais categorias: potência de processamento, desempenho do disco, capacidade da rede e recursos de memória do sistema.

Outra consideração é utilizar computadores virtualizados. Um farm do SharePoint Server pode ser implantado usando computadores virtuais. Embora não se tenha notado nenhum benefício de desempenho com isso, existem alguns benefícios de gerenciamento. A virtualização de computadores baseados no SQL Server em geral não é recomendada, mas podem haver alguns benefícios ao se virtualizar as camadas do servidor Web e do servidor de aplicativos. Para obter mais informações, consulte o artigo sobre planejamento da virtualização (https://technet.microsoft.com/pt-br/library/71c203cd-7534-47b0-9122-657d72ff0080(Office.14).aspx).

Diretrizes de seleção de hardware

Escolhendo processadores

O SharePoint Server 2010 só está disponível para processadores de 64 bits. Em geral, mais processadores lhe permitirão atender a uma demanda maior.

No SharePoint Server 2010, servidores Web individuais serão dimensionados à medida que você adicionar mais núcleos (testamos até 24 núcleos); quanto mais núcleos o servidor tiver, mais carga ele poderá sustentar, em condições normais. Em grandes implantações do SharePoint Server, é recomendado alocar vários servidores Web de 4 núcleos (que podem ser virtualizados) ou menos servidores Web mais fortes (8, 16, 24 núcleos).

Os requisitos de capacidade do processador dos servidores de aplicativos são diferentes dependendo da função do servidor e dos serviços que estão sendo executados. Alguns recursos do SharePoint Server exigem maior potência de processamento que outros. Por exemplo, o Serviço de Pesquisa do SharePoint é altamente dependente da potência de processamento do servidor de aplicativos. Para obter mais informações sobre os requisitos de recursos e serviços do SharePoint Server, consulte Serviços e recursos anteriormente neste documento.

Os requisitos de capacidade do processador para o SQL Server também dependem dos bancos de dados de serviço que está hospedado em um computador baseado no SQL Server. Para obter mais informações sobre o comportamento comum e os requisitos de cada banco de dados, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Escolhendo a memória

Os servidores exigem quantidades variadas de memória, de acordo com a função do servidor. Por exemplo, os servidores que executam os componentes de rastreamento de Pesquisa processarão os dados mais rapidamente se tiverem uma grande quantidade de memória, pois os documentos são lidos na memória para o processamento. Servidores Web que utilizam vários dos recursos de cache do SharePoint Server 2010 também podem exigir mais memória.

Em geral, os requisitos de memória do servidor Web são altamente dependentes do número de pools de aplicativos habilitados no farm e do número de solicitações simultâneas que estão sendo atendidas. Na maioria das implantações de produção do SharePoint Server, é recomendável alocar no mínimo 8 GB de RAM em cada servidor Web, com uma recomendação de 16 GB para servidores com maior tráfego ou implantações com vários pools de aplicativos configurados para isolamento.

Os requisitos de memória dos servidores de aplicativos também são diferentes: alguns recursos do SharePoint Server apresentam maior requisito de memória na camada do aplicativo do que outros. Na maioria das implantações de produção do SharePoint Server, é recomendável alocar no mínimo 8 GB de RAM em cada servidor de aplicativos; servidores de aplicativos de 16 GB, 32 GB e 64 GB são comuns quando muitos serviços de aplicativo estão habilitados no mesmo servidor, ou quando serviços altamente dependentes da memória, como o Serviço de Cálculo do Excel e o Serviço de Pesquisa do SharePoint Server, estão habilitados.

Os requisitos de memória dos servidores de banco de dados são totalmente dependentes dos tamanhos dos bancos de dados. Para obter mais informações sobre como escolher a memória para seus computadores baseados no SQL Server, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Escolhendo redes

Além do benefício oferecido aos usuários quando os clientes têm acesso rápido aos dados pela rede, um farm distribuído deve ter acesso rápido para comunicação entre servidores. Isso é verdade principalmente quando você distribui os serviços por vários servidores ou faz a federação de alguns dos serviços para outros farms. Existe um tráfego significativo no farm pela camada do servidor Web, do servidor de aplicativos e do servidor de banco de dados, e a rede pode facilmente se transformar em um afunilamento sob determinadas condições, como lidar com arquivos muito grandes ou cargas muito elevadas.

Os servidores Web e os servidores de aplicativos devem ser configurados com pelo menos duas placas de interface de rede (NICs): uma NIC para tratar do tráfego do usuário final e outra para tratar da comunicação entre servidores. A latência de rede entre os servidores pode ter um impacto significativo no desempenho, por isso, é importante manter menos de 1 milissegundo de latência de rede entre o servidor Web e os computadores baseados no SQL Server que hospedam os bancos de dados de conteúdo. Os computadores baseados no SQL Server que hospedam cada banco de dados de aplicativo de serviço devem estar o mais próximo possível também do servidor de aplicativos de consumo. A rede entre os servidores do farm deve ter no mínimo 1 Gbps de largura de banda.

Escolhendo discos e armazenamento

O gerenciamento de disco não é simplesmente uma função para fornecer espaço adequado aos seus dados. Avalie a demanda e o crescimento constante e verifique se a arquitetura de armazenamento não está deixando o sistema mais lento. Verifique sempre se você tem no mínimo 30% de capacidade adicional em cada disco, acima da sua maior estimativa de requisitos de dados, para deixar espaço para um crescimento futuro. Além disso, na maioria dos ambientes de produção, a velocidade do disco (IOps) é fundamental para fornecer produtividade suficiente para atender às demandas de armazenamento dos servidores. Você deve estimar a quantidade de tráfego (IOps) que os bancos de dados principais vão precisar na sua implantação e alocar discos suficientes para satisfazer o tráfego.

Para obter mais informações sobre como escolher discos para servidores de banco de dados, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Os servidores Web e de aplicativos também têm requisitos de armazenamento. Na maioria dos ambientes de produção, é recomendável alocar no mínimo 200 GB de espaço em disco para o SO e os arquivos temporários e 150 GB de espaço em disco para os logs.

Etapa 3: Piloto, Teste e Otimização

O estágio de teste e otimização é um componente crítico do gerenciamento de capacidade eficaz. Teste as novas arquiteturas antes de implantá-las na produção e conduza um teste de aceitação em conjunto com as seguintes práticas recomendadas de monitoramento para garantir que as arquiteturas criadas atinjam as metas de desempenho e capacidade. Dessa forma, você identifica e otimiza possíveis afunilamentos antes que eles afetem os usuários em uma implantação dinâmica. Se você está atualizando de um ambiente do Office SharePoint Server 2007 e pretende fazer alterações na arquitetura, ou está estimando a carga do usuário dos novos recursos do SharePoint Server, o teste é importante principalmente para verificar se o seu novo ambiente baseado no SharePoint Server vai atender às metas de desempenho e capacidade.

Após testar o seu ambiente, você pode analisar os resultados do teste para determinar quais alterações são necessárias para atingir as metas de desempenho e capacidade estabelecidas na Etapa 1: Modelo.

Estas são as subetapas recomendadas que você deve seguir para pré-produção:

Crie o ambiente de teste imitando a arquitetura inicial criada na Etapa 2: Design.
Popule o armazenamento com o conjunto de dados ou parte do conjunto de dados que você identificou na Etapa 1: Modelo.
Submeta o sistema a uma carga sintética que represente a carga de trabalho que você identificou na Etapa 1: Modelo.
Execute testes, analise os resultados e otimize a arquitetura.
Implante a arquitetura otimizada em seu data center e distribua um piloto a um grupo menor de usuários.
Analise os resultados do piloto, identifique possíveis afunilamentos e otimize a arquitetura. Refaça o teste, se necessário.
Implante no ambiente de produção.

Teste

O teste é um fator crítico para estabelecer a capacidade do seu design de sistema em oferecer suporte às características de carga de trabalho e uso. Consulte Testes de desempenho para SharePoint Server 2010 para obter informações detalhadas sobre como testar sua implantação do SharePoint Server 2010.

Criar um plano de teste
Criar o ambiente de teste
Criar Testes e Ferramentas

Implantar o ambiente piloto

Antes de implantar o SharePoint Server 2010 em um ambiente de produção, é importante primeiro implantar um ambiente piloto e testar completamente o farm para verificar se ele atende às metas de capacidade e desempenho para sua carga de pico esperada. É recomendável testar primeiro o ambiente piloto com carga sintética, principalmente para grandes implantações, e depois submetê-lo a um pequeno grupo de usuários ativos e conteúdo dinâmico. A vantagem de analisar um ambiente piloto com um pequeno grupo de usuários ativos é a oportunidade de validar algumas suposições feitas sobre as características de uso e o crescimento do conteúdo antes de entrar totalmente em produção.

Otimizar

Se você não conseguir atender às metas de capacidade e desempenho dimensionando o hardware do seu farm ou fazendo alterações na topologia, considere revisar a sua solução. Por exemplo, se os requisitos iniciais eram referentes a um único farm para colaboração (de Pesquisa e Social), convém federar alguns dos serviços, como a pesquisa em um farm de serviços dedicado, ou dividir a carga de trabalho entre mais farms. Uma alternativa é implantar um farm dedicado para colaboração social e outro para colaboração de equipe.

Etapa 4: Implantação

Após executar os últimos testes e confirmar que a arquitetura selecionada é capaz de atingir às metas de desempenho e capacidade estabelecidas na Etapa 1: Modelo, você poderá implantar o ambiente baseado no SharePoint Server 2010 para produção.

A estratégia de distribuição apropriada varia de acordo com o ambiente e a situação. Embora a implantação do SharePoint Server no geral está fora do escopo deste documento, há algumas atividades sugeridas que podem se revelar por meio do exercício de planejamento da capacidade. Veja a seguir alguns exemplos:

Implantando um novo farm do SharePoint Server: o exercício de planejamento da capacidade deve ter planos orientados e verificados para o design e a implantação do SharePoint Server 2010. Neste caso, a distribuição será a primeira implantação ampla do SharePoint Server 2010. Ela exige mover ou reconstruir os servidores e serviços usados durante os exercícios de planejamento da capacidade para produção. Este é o cenário mais direto, pois não existe nenhuma atualização ou modificação necessária para um farm existente.
Atualizando um farm do Office SharePoint Server 2007 para o SharePoint Server 2010: o exercício de planejamento da capacidade deve validar o design de um farm capaz de atender às demandas existentes e de ser dimensionado para satisfazer à crescente demanda e uso de um farm do SharePoint Server 2010. Parte do exercício de planejamento da capacidade deve incluir migrações de teste para validar quanto tempo levará o processo de atualização, se algum código personalizado precisa ser modificado ou substituído, se alguma ferramenta de terceiros precisa de atualização, etc. Na conclusão do planejamento da capacidade, você deverá ter um design validado, saber quanto tempo ele levará para ser atualizado e ter um plano sobre a melhor maneira de se trabalhar com o processo de atualização, por exemplo, uma atualização in-loco ou uma migração de bancos de dados de conteúdo para um novo farm. Se estiver realizando uma atualização in-loco, durante o planejamento da capacidade você deve ter percebido que há a necessidade de hardware adicional ou atualizado, além de considerações em relação ao tempo de inatividade. Parte do resultado do exercício de planejamento deve ser uma lista das alterações de hardware necessárias e um plano detalhado para implantação das alterações de hardware primeiro no farm. Depois que a plataforma de hardware validada durante o planejamento da capacidade estiver no local, você poderá continuar com o processo de atualização para o SharePoint Server 2010.
Melhorando o desempenho de um farm existente do SharePoint Server 2010: o exercício de planejamento da capacidade deve ajudá-lo a identificar os afunilamentos em sua implementação atual, apresentar maneiras de reduzir ou eliminar esses afunilamentos e validar uma implementação aperfeiçoada que atenda aos requisitos de negócios dos serviços do SharePoint Server. Há diversas maneiras de se resolver os problemas de desempenho, desde algo simples como realocar serviços para o hardware existente, atualizar o hardware existente ou adicionar outro hardware até adicionar outros serviços a ele. As diferentes abordagens devem ser testadas e validadas durante o exercício de planejamento da capacidade e, em seguida, um plano de implantação deve ser formulado de acordo com os resultados do teste.

Etapa 5: Monitoração e Manutenção

Para manter o desempenho do sistema, monitore seu servidor para identificar possíveis afunilamentos. Para um monitoramento eficaz, você deve conhecer os indicadores-chave que lhe mostrarão se determinada parte do seu farm requer atenção e como interpretar esses indicadores. Se achar que seu farm está operando fora das metas definidas, você poderá ajustá-lo adicionando ou removendo recursos de hardware, modificando a topologia ou alterando a maneira como os dados são armazenados.

Consulte Monitorando e mantendo o SharePoint Server 2010 para ver uma lista de configurações que você pode modificar para monitorar o ambiente em seus primeiros estágios, o que o ajudará a determinar se alguma alteração será necessária. Lembre-se de que ampliar seus recursos de monitoramento afetará o espaço em disco requerido pelo banco de dados de uso. Depois que o ambiente estiver estável e o monitoramento detalhado não for mais necessário, convém reverter as configurações a seguir aos seus padrões.

Para obter mais informações sobre monitoramento da integridade e solução de problemas por meio das ferramentas de monitoramento da integridade internas da interface da Administração Central do SharePoint Server, leia o seguinte artigo sobre:

Health monitoring (SharePoint Server 2010)

Solução de problemas (https://blogs.msdn.com/b/ecm/archive/2010/06/22/variations-propagate-pages-on-your-terms.aspx)