Planejamento de capacidade para o SharePoint Server 2013

Artigo
03/08/2023

APLICA-SE A: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint no Microsoft 365

Este artigo descreve como planejar a capacidade de um farm do SharePoint Server 2013. Quando você entende o planejamento e o gerenciamento da capacidade, pode aplicar esse conhecimento ao redimensionamento do sistema. Redimensionamento é o termo usado para descrever a seleção e a configuração da arquitetura de dados apropriada, da topologia lógica e física e do hardware para uma plataforma de solução. Há um intervalo de considerações de gerenciamento de capacidade e uso que afetam como você deve determinar as opções de hardware e configuração mais apropriadas.

Antes de ler este artigo, você deve ler a visão geral de gerenciamento de capacidade e dimensionamento do SharePoint Server 2013.

Importante

Algumas informações e valores neste artigo são baseados em resultados de teste e outras informações relacionadas aos Produtos do SharePoint 2010 e podem não representar os valores finais do SharePoint Server 2013.

Neste artigo descrevemos as etapas que devem ser tomadas para realizar efetivamente o gerenciamento da capacidade em seu ambiente. Cada etapa requer determinadas informações para execução bem-sucedida e tem um conjunto de entregas que você usará na etapa subsequente. Para cada etapa, esses requisitos e produtos estão descritos na tabela.

Etapa 1: modelo

Modelar seu ambiente baseado no SharePoint Server 2013 começa com a análise de suas soluções existentes e a estimativa da demanda e dos destinos esperados para a implantação que você está planejando configurar. Você começa coletando informações sobre sua base de usuários, requisitos de dados, latência e destinos de taxa de transferência e documente os recursos do SharePoint Server 2013 que deseja implantar. Use esta seção para compreender quais dados devem ser coletados, como coletá-los e como eles podem ser usados nas etapas subsequentes.

Compreenda a carga de trabalho e o conjunto de dados esperados

O dimensionamento adequado de uma implementação do SharePoint Server 2013 exige que você estude e entenda as características de demanda que sua solução deve lidar. Entender a demanda requer que você possa descrever as características da carga de trabalho, como o número de usuários e as operações mais usadas, e características do conjunto de dados, como tamanho do conteúdo e distribuição de conteúdo.

Esta seção pode ajudá-lo a compreender algumas métricas e parâmetros específicos que devem ser coletados e seus mecanismos de coleta.

Workload

A carga de trabalho descreve a demanda que o sistema precisará sustentar, a base de usuários e as características de uso. A tabela a seguir fornece algumas das principais métricas que são úteis para determinar sua carga de trabalho. Você pode usar esta tabela para registrar essas métricas ao coletá-las.

Características da carga de trabalho	Valor
RPS médias diárias
RPS médias no horário de pico
Quantidade total de usuários únicos por dia
Média diária de usuários simultâneos
Pico de usuários simultâneos no horário de pico
Quantidade total de solicitações por dia
Distribuição esperada da carga de trabalho
Não. de solicitações por dia
Navegador da Web: rastreador de pesquisa
Navegador da Web: interação de colaboração geral
Navegador da Web: interação social
Navegador da Web: interação geral
Navegador da Web: Office Web Apps
Clientes do Office
Cliente do OneNote
Espaço de trabalho do SharePoint
Sincronização de RSS do Outlook
Conector Social do Outlook
Outras interações (aplicativos/serviços Web personalizados)

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 um determinado período de tempo. As principais métricas são a média diária e os usuários simultâneos no horário de pico.
Solicitações por segundo (RPS) – RPS é um indicador comumente usado usado para descrever a demanda no farm de servidor expressa no número de solicitações processadas pelo farm por segundo, mas sem diferenciação 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 exclusivas de uso da organização. Para obter mais informações, consulte Glossário.
Total de solicitações diárias – O total de solicitações diárias é um bom indicador da carga geral que o sistema precisará lidar. É mais comum medir todas as solicitações, exceto solicitações de aperto de mão de autenticação (status HTTP 401) em um período de 24 horas.
Total de usuários diários: o total de usuários é outro indicador importante da carga geral com que o sistema terá que lidar. Essa medida é o número real de usuários exclusivos em um período de 24 horas, não o número total de funcionários na organização.

Observação

A quantidade total diária de usuários pode indicar o crescimento potencial da carga no farm. Por exemplo, se a quantidade de usuários possíveis é de 100.000 funcionários, 15.000 usuários diários indica que a carga pode crescer significativamente com o tempo, conforme a aceitação dos usuários aumenta.
Distribuição de carga de trabalho – entender a distribuição das solicitações com base nos aplicativos do cliente que estão interagindo com o farm pode ajudar a prever a tendência esperada e carregar as alterações depois de migrar para o SharePoint Server 2013. À medida que os usuários fazem a transição para versões mais recentes do cliente, como o Office 2013, e começam a usar os novos recursos, novos padrões de carga, RPS e solicitações totais devem crescer. Para cada cliente, podemos descrever o número de usuários distintos usando-o em um período de tempo de um dia e o número de solicitações totais que o cliente ou recurso gera no servidor.

Por exemplo, o gráfico abaixo mostra um instantâneo de um ambiente interno da Microsoft em funcionamento, servindo a uma solução social comum. Neste exemplo, você pode ver que a maior parte da carga é gerada pelo rastreador de pesquisa e pela navegação típica do usuário final na Web. Você também pode observar que há uma carga significativa introduzida pelo recurso do Outlook Social Connector (6,2% das solicitações).

Estimar a carga de trabalho de sua produção

Ao fazer a estimativa da taxa de transferência requerida que seu farm precisa poder manter, comece com a estimativa da mistura de transações que serão usadas no seu farm. Concentre-se em analisar as transações mais usadas que o sistema atenderá e entender com que frequência elas serão usadas e por quantos usuários. Esse entendimento ajudará você mais tarde quando você validar se o farm pode sustentar tais cargas em testes de pré-produção.

O diagrama a seguir descreve o relacionamento entre a carga de trabalho e a carga sobre o 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. Por exemplo:
- A página da Web navega.
- Downloads e uploads de arquivos.
- Exibições e edições do Aplicativo Web do Office no navegador.
- Interações de coautoria.
- Sincronizações de site do Workspace do SharePoint.
- Conexões Sociais do Outlook.
- Sincronização do RSS (no Outlook ou em outros visualizadores).
- Transmissões do PowerPoint.
- Blocos de anotações compartilhados do OneNote.
- Pastas de trabalho compartilhadas do Serviço excel.
- Acessar aplicativos compartilhados do Serviço
Para obter mais informações, consulte Serviços e recursos. Concentre-se na identificação das interações que podem ser exclusivas para sua implantação. Reconheça o impacto esperado dessas cargas. Por exemplo, uso significativo de InfoPath Forms, Cálculos de Serviço do Excel e soluções dedicadas semelhantes.
Identifique as operações do sistema, como rastreamentos de Pesquisa aumentando, backups diários, tarefas programadas de sincronização de perfil, processamento de análise da Web, tarefas programadas de conexão e outros.
Estimar os seguintes itens:
- O número total de usuários por dia que devem utilizar cada recurso.
- Derivar os usuários simultâneos estimados e solicitações de alto nível por segundo.
Você fará algumas suposições. Por exemplo:
- Apresentar simultaneidade.
- O fator de RPS por usuário simultâneo que é diferente entre os recursos
Use a tabela de carga de trabalho anterior nesta seção para suas estimativas. É importante se concentrar nos horários de pico, em vez da taxa de transferência média. O planejamento da atividade de pico permite dimensionar corretamente sua solução baseada no SharePoint Server 2013.

Se você tiver uma solução existente do Office SharePoint Server 2007, poderá minerar os arquivos de log do IIS ou procurar outras ferramentas de monitoramento da Web para entender melhor alguns dos comportamentos esperados da solução existente. Caso contrário, confira as instruções na seção abaixo para obter mais detalhes. Se você não estiver migrando de uma solução existente, deverá preencher a tabela usando estimativas aproximadas. Em etapas posteriores, você precisará validar suas suposições e ajustar o sistema.

Analisar os logs do IIS do SharePoint Server 2013

Você precisará extrair dados dos logs uls e IIS para descobrir as principais métricas sobre uma implantação existente do SharePoint Server 2013. Por exemplo:

Quantos usuários estão ativos.
O quanto eles estão usando o sistema.
Que tipo de solicitações estão chegando.
De que tipo de clientes as solicitações se originam.

Uma das maneiras mais fáceis de encontrar esses dados é usar o Log Parser, uma ferramenta poderosa disponível gratuitamente para download da Microsoft. O Log Parser pode ler e gravar em muitos formatos binários e de texto, incluindo todos os formatos IIS.

Você pode baixar o Log Parser 2.2 em https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07.

Dataset

O conjunto de dados descreve o volume de conteúdo armazenado no sistema e como isso pode ser distribuído no repositório de dados. A tabela a seguir fornece algumas das principais métricas que ajudam a determinar seu conjunto de dados. Você pode usar essa tabela para registrar essas métricas ao coletá-las.

Objeto	Valor
Tamanho do BD (em GB)
Quantidade de BD de conteúdo
Quantidade de conjuntos de site
Quantidade de aplicativos Web
Quantidade de sites
Tamanho do índice de pesquisa (quantidade de itens)
Quantidade de documentos
Quantidade de listas
Tamanho médio dos sites
Tamanho do maior site
Quantidade de perfis de usuários

Tamanho do conteúdo – entender o tamanho do conteúdo que você espera armazenar no sistema do SharePoint Server 2013 é importante para planejar e arquitetar o armazenamento do sistema e também para dimensionar corretamente a solução search que rastreará e indexará esse conteúdo. O tamanho do conteúdo é descrito no espaço total do disco. Se você estiver migrando conteúdo de uma implantação existente, talvez seja simples identificar o tamanho total do conteúdo a ser movido. Durante o planejamento, você deve deixar espaço para crescimento com base no tempo.
Número total de documentos – além do tamanho do data corpus, é importante acompanhar o número geral de itens. O sistema reage de forma diferente se houver 100 GB de dados compostos por 50 arquivos de 2 GB ou 100.000 arquivos de 1 KB. Em implantações grandes, quanto menos estresse houver em um único item, documento ou área de documentos, melhor desempenho será. Conteúdo amplamente distribuído, como vários arquivos menores em muitos sites e coleção de sites, é mais fácil de servir e, em seguida, uma biblioteca de documentos grande com arquivos grandes.
Tamanho máximo da coleção de sites – é importante identificar qual é a maior unidade de conteúdo que você armazenará no SharePoint Server 2013; geralmente é uma necessidade organizacional que impede a divisão dessa unidade de conteúdo. O tamanho médio de todos os conjuntos de sites e a quantidade total estimada de conjuntos de sites são indicadores adicionais que o ajudarão a identificar sua arquitetura de dados preferida.
Características de dados de aplicativos de serviço – Além de analisar as necessidades de armazenamento para o repositório de conteúdo, você deve analisar e estimar os tamanhos de outros repositórios do SharePoint Server 2013, 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 da base de dados do Web Analytics

Definir o desempenho do farm e os alvos de confiabilidade

Um dos produtos da Etapa 1: modelo é uma boa compreensão de alvos de desempenho e confiabilidade que melhor se adéquam às necessidades de sua empresa. Uma solução do SharePoint Server 2013 projetada corretamente deve ser capaz de alcançar "quatro noves" (99,99%) de tempo de atividade com capacidade de resposta do servidor sub-segundo.

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

Disponibilidade do servidor: geralmente descrito pelo percentual de tempo de atividade geral do sistema. Você deve rastrear qualquer tempo de inatividade inesperado e comparar a disponibilidade geral ao alvo da organização definido. As metas são comumente descritas por um número de noves (ou seja, 99%, 99,9%, 99,99%)
Capacidade de resposta do servidor: o tempo que o farm leva para atender às solicitações é um bom indicador para controlar a integridade do farm. Esse indicador é chamado de latência do lado do servidor. Tt é comum usar a latência média ou mediana (o percentil 50) das solicitações diárias que estão sendo atendidas. Os destinos são normalmente descritos em segundos ou frações de segundos. Se o destino for servir páginas em menos de dois segundos, a meta do lado do servidor deverá estar em frações de segundo. Esse desempenho aumentado permite tempo para a página alcançar o cliente e renderizar no navegador. Além disso, tempos de resposta mais longos do servidor geralmente são uma indicação de um farm não íntegro. O RPS raramente pode acompanhar se você gastar mais de um segundo no servidor para a maioria das solicitações.
Spikiness do servidor: outro bom indicador de latência do lado do servidor que vale a pena acompanhar é o comportamento dos 5% mais lentos de todas as solicitações. As solicitações mais lentas geralmente são as solicitações que atingem o sistema quando ele está sob maior carga ou até mais comumente, solicitações que são afetadas por atividades menos frequentes que ocorrem enquanto os usuários interagem com o sistema; um sistema saudável é aquele que tem as solicitações mais lentas sob controle também. O destino aqui é semelhante à Responsividade do Servidor, mas para obter uma resposta de sub-segundo no spikiness do servidor, você precisará criar o sistema com vários recursos sobressalentes para lidar com os picos de carga.
Utilização de recursos do sistema: outros indicadores comuns usados para controlar a integridade do sistema são uma coleção de contadores do sistema que indicam a integridade de cada servidor na topologia do farm. Os indicadores mais usados a serem rastreados são a utilização de % CPU e Memória Disponível; no entanto, há vários contadores que podem ajudar a identificar um sistema não saudável; mais detalhes podem ser encontrados na Etapa 5: Monitorar e Manter.

Etapa 2: design

Agora que você terminou de coletar alguns fatos ou estimativas sobre a solução que precisa entregar, está pronto para iniciar a próxima etapa de criação de uma arquitetura proposta que você prevê que será capaz de sustentar a demanda esperada.

Ao final desta etapa você deve ter um projeto para sua topologia física e um layout para sua topologia lógica, e assim poderá adquirir quaisquer partes necessárias.

As especificações de hardware e a quantidade de máquinas em seu layout estão estreitamente vinculadas, para lidar com uma carga específica há várias soluções que podem ser implantadas. É comum usar um pequeno conjunto de máquinas fortes (escalar) ou um conjunto maior de computadores menores (dimensionar); cada solução tem suas vantagens e desvantagens quando se trata de capacidade, redundância, energia, custo, espaço e outras considerações.

Recomendamos que você comece esta etapa determinando sua arquitetura e topologia. Defina como você planeja fazer o layout de diferentes farms e de diferentes serviços em cada farm, depois escolha as especificações de hardware para cada um dos servidores individuais em seu projeto. Você também pode executar esse processo identificando as especificações de hardware que você deve implantar (muitas organizações estão restritas a um determinado padrão da empresa) e, em seguida, definir sua arquitetura e topologia.

Use a tabela a seguir para registrar os parâmetros do projeto. Os dados incluídos são dados de exemplo e não são usados para dimensionar seu farm. Ele pretende demonstrar como usar essa tabela para seus próprios dados.

Role	Tipo (padrão ou virtual)	Quantidade de máquinas	Procs	RAM	Necessidades de IOPS	Tamanho do disco (SO + registro)	Unidade de dados
Servidores da Web	Virtual	4	4 núcleos	8	N/D	400 GB	N/D
Servidor do banco de dados de conteúdo	Padrão	1 cluster	4 quad-core 2,33 (GHz)	48	2k	400 GB	20 discos de 300 GB a 15.000 RPM
Servidores de aplicativos	Virtual	4	4 núcleos	16	N/D	400 GB	N/D
Servidor da Web para alvo de rastreamento de pesquisa	Virtual	1	4 núcleos	8	N/D	400 GB	N/D
Servidor de consulta de pesquisa	Padrão	2	2 quad-core 2,33 (GHz)	32	N/D	400 GB	500 GB
Servidor do rastreamento de pesquisa	Padrão	2	2 quad-core 2,33 (GHz)	16	400	400 GB	N/D
Servidor do banco de dados de rastreamento de pesquisa	Padrão	1 cluster	4 quad-core 2,33 (GHz)	48	4.000 (ajustado para leitura)	100 GB	16 discos de 150 GB @ 15K RPM
Servidor do banco de dados de armazenamento das propriedades de pesquisa + do banco de dados de administração	Padrão	1 cluster	4 quad-core 2,33 (GHz)	48	2.000 (ajustado para gravação)	100 GB	16 discos de 150 GB @ 15K RPM

Determine o ponto inicial de sua arquitetura

Esta seção descreve como selecionar o ponto inicial de sua arquitetura.

Ao implantar o SharePoint Server 2013, você pode escolher entre um intervalo de topologias para implementar sua solução; você pode implantar um único servidor ou escalar muitos servidores em um farm do SharePoint Server 2013 com servidores de banco de dados clusterizados ou espelhados e servidores de aplicativo discretos para vários serviços. Posteriormente, você seleciona as configurações de hardware com base nos requisitos de cada uma das funções, com base em suas necessidades de capacidade, disponibilidade e redundância.

Comece revisando as diferentes arquiteturas de referência e determine a estrutura do seu farm, decida se você deve dividir sua solução entre vários farms, ou serviços de farm federados, como pesquisa, em um farm dedicado. Para obter mais informações, consulte Arquiteturas de referência.

Estudos de caso técnicos do SharePoint Server 2010

As diretrizes de gerenciamento de capacidade do SharePoint Server 2013 incluem muitos estudos de caso técnicos de ambientes de produção existentes que apresentam uma descrição detalhada dos ambientes de produção existentes do SharePoint Server 2013. Estudos de caso técnicos específicos do SharePoint Server 2013 serão publicados à medida que estiverem disponíveis; os estudos de caso existentes do SharePoint Server 2010 podem servir de referência sobre como projetar um ambiente baseado no SharePoint Server 2013 para fins específicos.

Você pode usar esses estudos de caso como referência ao projetar a arquitetura de suas soluções do SharePoint Server 2013 especialmente se encontrar a descrição desses diferenciadores de chave específicos de implantação semelhantes às demandas e aos destinos da solução que você está arquitetando.

Esses documentos descrevem as seguintes informações para cada estudo de caso documentado:

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

Para obter mais informações, baixe os documentos relevantes na página Performance and capacity technical case studies (SharePoint Server 2010).

Selecione seu hardware

Selecionar as especificações certas para as máquinas do seu farm é uma etapa crucial para garantir a confiabilidade e o desempenho adequados para sua implantação. Um conceito chave é lembrar-se de que você deve planejar para cargas de pico e horários de pico; em outras palavras, quando o farm está sob condições de carga médias, deve haver recursos suficientes disponíveis para lidar com a demanda mais alta esperada, e ainda atingir os limites de latência e taxa de transferência.

O desempenho e a capacidade de núcleo dos recursos de hardware dos servidores refletem quatro categorias principais: potência de processamento, desempenho do disco, capacidade da rede e recursos de memória de um sistema.

Outra coisa a considerar é o uso de máquinas virtualizadas. Um farm do SharePoint Server 2013 pode ser implantado usando máquinas virtuais. Apesar de a virtualização não adicionar nenhum benefício de desempenho, ela fornece benefícios no gerenciamento. A virtualização de computadores baseados em SQL Server não é recomendada, mas pode haver certos benefícios para virtualizar as camadas do servidor Web e do servidor de aplicativo. Para obter mais informações, confira Planejamento de virtualização (/versões anteriores/office/sharepoint-server-2010/ff607968(v=office.14)).

Para obter mais informações sobre os requisitos de hardware, consulte Requisitos de hardware e software para o SharePoint Server 2016.

Orientações sobre a seleção de hardware

Escolha de processadores

O SharePoint Server 2013 está disponível apenas para processadores de 64 bits. Em geral, a maior quantidade de processadores lhe permitirá manter uma demanda maior.

No SharePoint Server 2013, os servidores Web individuais aumentarão à medida que você adicionar mais núcleos. Quanto mais núcleos o servidor tiver, mais carga ele pode sustentar, desde que o restante se mantenha igual. Em implantações grandes do SharePoint Server 2013, recomendamos 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 aplicativo diferem dependendo da função do servidor e dos serviços em execução. Alguns recursos do SharePoint Server 2013 exigem maior poder de processamento do que outros. Por exemplo, o Serviço de pesquisa do SharePoint depende muito da potência de processamento do servidor de aplicativos.

Os requisitos de capacidade do processador para SQL Server também dependem dos bancos de dados de serviço que um computador baseado em SQL Server está hospedando.

Escolha da memória

Seus servidores requererão várias quantidades de memória, dependendo das funções do servidor. Por exemplo, os servidores que executam componentes de rastreamento de pesquisa processarão os dados mais rapidamente se tiverem mais memória, porque os documentos são lidos pela memória para o processamento. Servidores Web que aproveitam muitos dos recursos de cache do SharePoint Server 2013 também podem exigir mais memória.

Em geral, os requisitos de memória de um servidor da Web dependem bastante da quantidade de pools de aplicativos que está habilitada no farm e da quantidade de solicitações simultâneas que estão sendo mantidas. Na maioria das implantações do SharePoint Server 2013 de produção, recomendamos alocar pelo menos 8 GB de RAM em cada servidor Web, com 16 GB recomendados 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 aplicativo também diferem; alguns recursos do SharePoint Server 2013 têm requisitos de memória maiores na camada de aplicativo do que outros. Na maioria das implantações do SharePoint Server 2013 de produção, recomendamos alocar pelo menos 8 GB de RAM em cada servidor de aplicativo; Servidores de aplicativo 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 2013, estão habilitados.

Os requisitos de memória dos servidores de bancos de dados dependem muito do tamanho do banco de dados. Para obter mais informações sobre como escolher a memória para seus computadores baseados em SQL Server, consulte Armazenamento e SQL Server planejamento e configuração de capacidade (SharePoint Server).

Escolha da rede

Além do benefício oferecido aos usuários, se os clientes tiverem acesso rápido a dados por meio da rede, um farm distribuído deverá ter acesso rápido para comunicação entre servidores. Isso é especialmente verdade se você distribuir os serviços entre vários servidores ou alguns serviços federados em outros farms. Há tráfego significativo em um farm na camada do servidor Web, na camada do servidor de aplicativo e na camada do servidor de banco de dados e a rede pode facilmente se tornar um gargalo em determinadas condições, como lidar com arquivos grandes ou cargas altas.

Os servidores da Web e de aplicativos devem ser configurados para usar ao menos duas placas de interface de rede (NICs): uma NIC para lidar com o tráfego de usuários finais e a outra para lidar com a comunicação entre servidores. A latência da rede entre servidores pode ter um efeito significativo no desempenho. Portanto, é importante manter menos de 1 milissegundos de latência de rede entre o servidor Web e os computadores baseados em SQL Server que hospedam os bancos de dados de conteúdo. Os computadores baseados em SQL Server que hospedam cada banco de dados de aplicativo de serviço devem estar o mais próximo possível do servidor de aplicativo consumidor também. A rede entre os servidores do farm deve ter uma largura de banda mínima de 1 Gbps.

Escolha dos discos e do armazenamento

O gerenciamento de disco não é simplesmente uma função de fornecer espaço suficiente para seus dados. Você deve avaliar a demanda e o crescimento em andamento e verificar se a arquitetura de armazenamento não está desacelerando o sistema. Você sempre deve ter certeza de que tem pelo menos 30% de capacidade adicional em cada disco, acima da estimativa mais alta dos requisitos de dados, para deixar espaço para o crescimento futuro. Além disso, na maioria dos ambientes de produção, a velocidade do disco (IOps) é crucial para oferecer taxas de transferência suficientes para satisfazer as demandas de armazenamento do servidor. Você deve estimar a quantidade de tráfego (IOps) requerida pelos maiores bancos de dados de sua implantação e alocar discos suficientes para satisfazer esse tráfego.

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

Os servidores da Web e de aplicativos também têm requisitos de armazenamento. Na maioria dos ambientes de produção, recomendamos alocar ao menos 200 GB de espaço em disco para o sistema operacional e pastas temporárias e 150 GB de espaço em disco para registros.

Etapa 3: Piloto, Teste e Otimização

O estágio de teste e otimização é um componente importante do gerenciamento efetivo de capacidade. Você deve testar as novas arquiteturas antes de implementá-las na produção e deve realizar testes de aceitação com outras práticas recomendadas de monitoramento para garantir que as arquiteturas projetadas atingem as metas de desempenho e capacidade. Isso possibilita identificar e otimizar possíveis gargalos antes de poderem afetar os usuários em uma implantação. Se você estiver atualizando de um ambiente do Office SharePoint Server 2007 e planeja fazer alterações arquitetônicas ou estimando a carga do usuário dos novos recursos do SharePoint Server 2013, teste importante para garantir que seu novo ambiente baseado no SharePoint Server 2013 atenda às metas de desempenho e capacidade.

Após ter testado o ambiente, pode analisar os resultados do teste para determinar que alterações devem ser feitas para atingir as metas de desempenho e capacidade estabelecidas na Etapa 1: modelo.

A seguir estão as sub etapas para pré-produção:

Criar um ambiente de teste que imite a arquitetura inicial projetada na Etapa 2: design.
Preencher o armazenamento com o conjunto de dados ou parte do conjunto de dados identificada na Etapa 1: modelo.
Sobrecarregar o sistema com uma carga sintética que representa a carga de trabalho identificada na Etapa 1: modelo.
Executar testes, analisar resultados e otimizar a arquitetura.
Implantar a arquitetura otimizada no data center e fazer a distribuição de um piloto com um conjunto menor de usuários.
Analisar os resultados do piloto, identificar possíveis gargalos e otimizar a arquitetura. Verifique novamente se for necessário.
Implantar no ambiente de produção.

Testar

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

Criação de um plano de testes
Criação de um ambiente de teste
Criação de testes e ferramentas

Implantação do ambiente piloto

Antes de implantar o SharePoint Server 2013 em um ambiente de produção, é importante primeiro implantar um ambiente piloto e testar completamente o farm para garantir que ele possa cumprir as metas de capacidade e desempenho para a carga máxima esperada. Recomendamos que o ambiente piloto seja testado primeiro com carga sintética especialmente para implantações grandes e, em seguida, estressado por um pequeno conjunto de usuários vivos e conteúdo ao vivo. O benefício de analisar um ambiente piloto usando um pequeno conjunto de usuários ativos é a oportunidade de validar algumas suposições que você tenha feito sobre as características de uso e o crescimento do conteúdo antes de entrar em produção.

Otimização

Se não for possível atender às metas de capacidade e desempenho escalonando o hardware do farm ou alterando a topologia, considere uma revisão da solução. Por exemplo, se os requisitos iniciais eram de um farm para colaboração, pesquisa e aplicativos sociais, considere realizar a federação de alguns serviços, como a pesquisa, em um farm dedicado, ou divida a carga de trabalho entre vários farms. Uma alternativa é implantar um farm dedicado para aplicativos sociais e outro para a colaboração da equipe.

Etapa 4: implantação

Depois de executar sua última rodada de testes e confirmar que a arquitetura selecionada pode alcançar as metas de desempenho e capacidade estabelecidas na Etapa 1: Modelo, você pode implantar seu ambiente baseado no SharePoint Server 2013 em produção.

A estratégia de distribuição apropriada varia dependendo do ambiente e da situação. Embora a implantação do SharePoint Server 2013 geralmente esteja fora do escopo deste documento, há certas atividades sugeridas que podem sair do exercício de planejamento de capacidade. Aqui estão alguns exemplos:

Implantando um novo farm do SharePoint Server 2013: O exercício de planejamento de capacidade deve ter planos guiados e confirmados para um design e implantação do SharePoint Server 2016. Nesse caso, a distribuição será a primeira implantação ampla do SharePoint Server 2013. Isso exigirá mover ou recompilar os servidores e serviços que foram usados durante os exercícios de planejamento de capacidade em produção. Este é o cenário mais direto porque não há atualizações ou modificações necessárias para um farm existente.
Atualizando um farm do Office SharePoint Server 2007 para o SharePoint Server 2013: O exercício de planejamento de capacidade deve ter validado o design de um farm que pode atender às demandas existentes e escalar para atender ao aumento da demanda e ao uso de um farm do SharePoint Server 2013. Parte do exercício de planejamento de capacidade deve ter incluído migrações de teste para validar quanto tempo o processo de atualização levará, se qualquer código personalizado deve ser modificado ou substituído, se quaisquer ferramentas de terceiros precisam ser atualizadas e assim por diante. Ao concluir o planejamento de capacidade, você deve ter um design validado e uma compreensão de quanto tempo levará para atualizar e um plano para a melhor maneira de trabalhar no processo de atualização - por exemplo, uma atualização in-loco ou migrar bancos de dados de conteúdo para um novo farm. Se você estiver fazendo uma atualização in loco, durante o planejamento de capacidade, talvez tenha descoberto que hardware adicional ou atualizado será necessário e considerações sobre o tempo de inatividade. Parte da saída do exercício de planejamento deve ser uma lista das alterações de hardware necessárias e um plano detalhado para implantar as alterações de hardware no farm primeiro. Depois que a plataforma de hardware que foi validada durante o planejamento de capacidade estiver em vigor, você poderá avançar com o processo de atualização para o SharePoint Server 2013.
Melhorando o desempenho de um farm do SharePoint Server 2013 existente: O exercício de planejamento de capacidade deve ter ajudado você a identificar os gargalos em sua implementação atual, planejar maneiras de reduzir ou eliminar esses gargalos e validar uma implementação aprimorada que atenda aos seus requisitos de negócios para os serviços do SharePoint Server 2013. Há diferentes maneiras pelas quais problemas de desempenho poderiam ter sido resolvidos, de algo tão fácil quanto realocar serviços em hardware existente, atualizar hardware existente ou adicionar mais hardware e adicionar mais serviços a ele. As diferentes abordagens devem ser testadas e validadas durante o exercício de planejamento de capacidade e, em seguida, um plano de implantação projetado dependendo dos resultados desse teste.

Etapa 5: monitoração e manutenção

Para manter o desempenho do sistema, é preciso monitorar o servidor para identificar possíveis gargalos. Antes de poder monitorar com eficácia, você deve entender os principais indicadores que informarão se houver uma parte específica do farm que requer atenção, e como saber interpretar esses indicadores. Se achar que o farm está operando fora das metas definidas, pode ajustá-lo adicionando ou removendo recursos de hardware, alterando a topologia ou alterando o armazenamento dos dados.

Consulte Monitoramento e manutenção do SharePoint Server 2013 para obter uma lista das configurações que você pode alterar para monitorar seu ambiente em seus estágios iniciais, o que ajudará você a determinar se alguma alteração é necessária. Lembre-se que aumentar os recursos de monitoramento afetará quanto espaço em disco o banco de dados de uso requer. Depois que o ambiente estiver estável e esse monitoramento detalhado não for mais necessário, talvez você queira reverter as configurações abaixo para suas configurações padrão.

Para obter mais informações sobre monitoramento de integridade e solução de problemas usando as ferramentas de monitoramento de integridade integradas à interface do Administração Central do SharePoint Server 2013, consulte:

Monitoramento e geração de relatórios no SharePoint Server 2016

Solucionando problemas