Planejamento de capacidade para o SharePoint Server 2013

APLICA-SE A:2013 2016 2019 Subscription Edition SharePoint no Microsoft 365

Este artigo descreve como planear 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. Existe uma variedade de considerações de gestão de capacidade e utilização que afetam a forma como deve determinar as opções de hardware e configuração mais adequadas.

Antes de ler este artigo, deve ler Capacity management and sizing overview for SharePoint Server 2013 (Descrição geral da gestão de capacidade e dimensionamento do SharePoint Server 2013).

Algumas informações e valores neste artigo baseiam-se nos resultados do teste e noutras informações relacionadas com os Produtos 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 passo requer determinadas informações para uma execução bem-sucedida e tem um conjunto de materiais a entregar que irá utilizar no passo seguinte. Para cada etapa, esses requisitos e produtos estão descritos na tabela.

Etapa 1: modelo

A modelação do seu ambiente baseado no SharePoint Server 2013 começa por analisar as soluções existentes e estimar a procura e os objetivos esperados para a implementação que está a planear configurar. Comece por recolher informações sobre a sua base de utilizadores, requisitos de dados, destinos de latência e débito e documente as funcionalidades do SharePoint Server 2013 que pretende implementar. 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 requer que analise e compreenda as características de procura que a sua solução deverá processar. Compreender a procura requer que consiga descrever as características da carga de trabalho, como o número de utilizadores e as operações utilizadas com mais frequência, bem como as características dos conjuntos de dados, como o tamanho do conteúdo e a distribuição de conteúdos.

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.

• Utilizadores simultâneos – é mais comum medir a simultaneidade das operações executadas no farm de servidores como o número de utilizadores distintos que geram pedidos num 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.

• Pedidos por segundo (RPS) – o RPS é um indicador frequentemente utilizado para descrever a procura no farm de servidores expressa no número de pedidos processados pelo farm por segundo, mas sem diferenciação entre o tipo ou o tamanho dos pedidos. 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, veja Glossário.

• Total de pedidos diários – o total de pedidos diários é um bom indicador da carga global que o sistema terá de processar. É mais comum medir todos os pedidos, exceto pedidos de handshake de autenticação (HTTP status 401) durante 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. Esta medição é o número real de utilizadores exclusivos num período de 24 horas e 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 da Carga de Trabalho – compreender a distribuição dos pedidos com base nas aplicações do cliente que estão a interagir 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 2013. À medida que os utilizadores transitam para versões de cliente mais recentes, como o Office 2013, e começam a utilizar as novas capacidades, espera-se que os novos padrões de carga, RPS e pedidos totais aumentem. Para cada cliente, podemos descrever o número de utilizadores distintos que o utilizam num período de tempo de um dia e o número total de pedidos gerados pelo cliente ou funcionalidade 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, pode ver que a maior parte da carga é gerada pelo crawler de pesquisa e pela navegação típica na Web do utilizador final. Também pode observar que existe uma carga significativa introduzida pela funcionalidade Outlook Social Connector (6,2 por cento dos pedidos).

  

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 utilizadas com mais frequência que o sistema irá servir e compreender a frequência com que serão utilizadas e por quantos utilizadores. Esta compreensão irá ajudá-lo mais tarde quando validar se o farm pode suportar essas 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:

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

• Identificar interações do utilizador. Por exemplo:

  • A página Web navega.
  • Transferências e carregamentos de ficheiros.
  • Vistas e edições da Aplicação Web do Office no browser.
  • Interações de cocriação.
  • O site do SharePoint Workspace é sincronizado.
  • Outlook Social Connections.
  • Sincronização RSS (no Outlook ou noutros visualizadores).
  • Difusões do PowerPoint.
  • Blocos de notas partilhados do OneNote.
  • Livros partilhados do Serviço Excel.
  • Aplicações partilhadas do Access Service

  Para obter mais informações, veja Serviços e funcionalidades. Concentre-se na identificação das interações que podem ser exclusivas da sua implementação. Reconhecer o impacto esperado de tais cargas. Por exemplo, utilização significativa do InfoPath Forms, Cálculos do 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.

• Calcule os seguintes itens:

  • O número total de utilizadores por dia que se espera que utilizem cada capacidade.
  • Derivar os utilizadores simultâneos estimados e os Pedidos de alto nível por segundo.

  Vais fazer algumas suposições. Por exemplo:

  • Apresentar simultaneidade.
  • O fator do RPS por utilizador simultâneo que é diferente entre as capacidades

  Utilize a tabela de carga de trabalho anteriormente nesta secção para as estimativas. É importante concentrarmo-nos nas horas de pico, em vez do débito médio. Planear a atividade de pico permite-lhe dimensionar corretamente a sua solução baseada no SharePoint Server 2013.

Se tiver uma solução existente do Office SharePoint Server 2007, pode extrair os ficheiros de registo do IIS ou procurar outras ferramentas de monitorização da Web para compreender melhor alguns dos comportamentos esperados da solução existente. Caso contrário, consulte as instruções na secção abaixo para obter mais detalhes. Se não estiver a migrar de uma solução existente, deve preencher a tabela com estimativas aproximadas. Nos passos posteriores, terá de validar as suas suposições e otimizar o sistema.

Analisar os logs do IIS do SharePoint Server 2013

Terá de extrair dados dos registos ULS e IIS para detetar as principais métricas sobre uma implementação existente do SharePoint Server 2013. Por exemplo:

• Quantos utilizadores estão ativos.
• Que peso estão a utilizar o sistema.
• Que tipo de pedidos estão a chegar.
• De que tipo de clientes os pedidos têm origem.

Uma das formas mais fáceis de encontrar estes dados é utilizar o Log Parser, uma ferramenta avançada disponível gratuitamente para transferência a partir da Microsoft. O Analisador de Registos pode ler e escrever em vários formatos de texto e binários, incluindo todos os formatos do IIS.

Pode transferir 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.

• Tamanho do conteúdo – compreender o tamanho do conteúdo que espera armazenar no sistema do SharePoint Server 2013 é importante para planear e arquitetar o armazenamento do sistema e também para dimensionar corretamente a solução de Pesquisa que irá pesquisar e indexar este conteúdo. O tamanho do conteúdo é descrito no espaço total em disco. Se estiver a migrar conteúdo de uma implementação existente, poderá achar simples identificar o tamanho total do conteúdo a mover. Durante o planeamento, deve deixar espaço para crescimento ao longo do tempo com base no tempo.

• Número total de documentos – para além do tamanho do corpus de dados, é importante controlar o número total 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 grandes implementações, quanto menos esforço houver num único item, documento ou área de documentos, melhor será o desempenho. Os conteúdos amplamente distribuídos, como múltiplos ficheiros mais pequenos em muitos sites e coleções de sites, são mais fáceis de servir do que uma única biblioteca de documentos grande com ficheiros grandes.

• Tamanho máximo da coleção de sites – é importante identificar qual é a maior unidade de conteúdo que irá armazenar no SharePoint Server 2013; normalmente, é uma necessidade organizacional que o impede de dividir essa unidade de conteúdo. O tamanho médio de todas as coleções de sites e o número total estimado de coleções de sites são outros indicadores que o ajudarão a identificar a sua arquitetura de dados preferida.

• Características de dados das aplicações de serviço – para além de analisar as necessidades de armazenamento do arquivo de conteúdos, deve analisar e estimar os tamanhos de outros arquivos do SharePoint Server 2013, incluindo:

• Tamanho total do índice de pesquisa

• O tamanho total da base de dados de perfil com base no número de utilizadores no arquivo de perfis

• O tamanho total da base de dados social com base no número esperado de etiquetas, 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 devidamente concebida deve conseguir alcançar "quatro noves" (99,99%) de tempo de atividade com capacidade de resposta do servidor de subsegundos.

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

• Disponibilidade do servidor: descrito pela percentagem 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. Os objetivos são geralmente descritos por um número de noves (ou seja, 99%, 99,9%, 99,99%)

• Capacidade de resposta do servidor: o tempo que o farm demora a apresentar pedidos é um bom indicador para controlar o estado de funcionamento do farm. Este indicador tem o nome latência do lado do servidor. O TT é comum utilizar a latência média ou mediana (o percentil 50) dos pedidos diários que estão a ser servidos. Os destinos são geralmente descritos em segundos ou frações de segundos. Se o destino for servir páginas em menos de dois segundos, o objetivo do lado do servidor deve estar em frações de segundo. Este aumento de desempenho permite que a página chegue ao cliente e seja composta no browser. Além disso, os tempos de resposta do servidor mais longos são normalmente uma indicação de um farm em mau estado de funcionamento. O RPS raramente consegue acompanhar se gastar mais de um segundo no servidor para a maioria dos pedidos.

• Spikiness do servidor: outro bom indicador de latência do lado do servidor que vale a pena controlar é o comportamento dos 5% mais lentos de todos os pedidos. Os pedidos mais lentos são normalmente os pedidos que atingem o sistema quando estão sob uma carga mais elevada ou, ainda mais frequentemente, pedidos que são afetados por atividades menos frequentes que ocorrem enquanto os utilizadores interagem com o sistema; um sistema em bom estado de funcionamento também tem os pedidos mais lentos sob controlo. O destino aqui é semelhante à Capacidade de Resposta do Servidor, mas para obter uma resposta de subsegundos na spikiness do servidor, terá de criar o sistema com vários recursos sobressalentes para lidar com os picos de carga.

• Utilização de recursos do sistema: outros indicadores comuns utilizados para controlar o estado de funcionamento do sistema são uma coleção de contadores de sistema que indicam o estado de funcionamento de cada servidor na topologia do farm. Os indicadores utilizados mais frequentemente para controlar são a % de utilização da CPU e a Memória Disponível; no entanto, existem vários contadores que podem ajudar a identificar um sistema que não está em funcionamento; Pode encontrar mais detalhes no Passo 5: Monitorizar e Manter.

Etapa 2: design

Agora que concluiu a recolha de alguns factos ou estimativas sobre a solução que precisa de fornecer, está pronto para começar o próximo passo de criação de uma arquitetura proposta que prevê ser capaz de sustentar a procura 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 utilizar um pequeno conjunto de máquinas virtuais fortes (aumentar verticalmente) ou um conjunto maior de máquinas mais pequenas (aumentar horizontalmente); cada solução tem as 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 planeia definir os diferentes farms e os diferentes serviços em cada farm e, em seguida, escolha as especificações de hardware para cada um dos servidores individuais na sua estrutura. Também pode executar este processo ao identificar as especificações de hardware que deverá implementar (muitas organizações estão limitadas a um determinado padrão da empresa) e, em seguida, definir a 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 utilizam para dimensionar o farm. Destina-se a demonstrar como utilizar esta tabela para os seus próprios dados.

Determine o ponto inicial de sua arquitetura

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

Quando implementa o SharePoint Server 2013, pode escolher entre várias topologias para implementar a sua solução; pode implementar um único servidor ou aumentar horizontalmente muitos servidores para um farm do SharePoint Server 2013 com servidores de bases de dados agrupados ou espelhados e servidores de aplicações discretos para vários serviços. Mais tarde, selecione as configurações de hardware com base nos requisitos de cada uma das funções, com base nas 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, veja Arquiteturas de referência.

Estudos de caso técnicos do SharePoint Server 2010

A documentação de orientação de gestão de capacidade do SharePoint Server 2013 inclui muitos casos técnicos de ambientes de produção existentes que apresentam uma descrição detalhada dos ambientes de produção existentes baseados no SharePoint Server 2013. Os casos práticos específicos do SharePoint Server 2013 serão publicados à medida que estiverem disponíveis; os casos práticos existentes do SharePoint Server 2010 podem servir de referência sobre como estruturar um ambiente baseado no SharePoint Server 2013 para fins específicos.

Pode utilizar estes casos práticos como referência ao conceber a arquitetura das suas soluções do SharePoint Server 2013, especialmente se encontrar a descrição destes diferenciadores de chaves específicos de implementação semelhante às exigências e destinos da solução que está a arquitetar.

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 implementado com máquinas virtuais. Embora não tenha sido encontrada virtualização para adicionar benefícios de desempenho, proporciona benefícios de capacidade de gestão. A virtualização de computadores baseados em SQL Server não é recomendada, mas podem existir algumas vantagens em virtualizar as camadas do servidor Web e do servidor de aplicações. Para obter mais informações, consulte Planeamento da virtualização (/versões anteriores/office/sharepoint-server-2010/ff607968(v=office.14)).

Para obter mais informações sobre os requisitos de hardware, veja 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 verticalmente à medida que adiciona mais núcleos. Quanto mais núcleos o servidor tiver, mais carga ele pode sustentar, desde que o restante se mantenha igual. Em grandes implementações do SharePoint Server 2013, recomendamos que aloque 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 aplicações diferem consoante a função do servidor e os serviços em execução. Algumas funcionalidades do SharePoint Server 2013 exigem maior poder de processamento do que outras. 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 das bases de dados de serviço que um computador baseado em SQL Server está a alojar.

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. Os servidores Web que tiram partido de muitas das funcionalidades de colocação em cache do SharePoint Server 2013 também podem necessitar de 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 implementações do SharePoint Server 2013 de produção, recomendamos que aloque, pelo menos, 8 GB de RAM em cada servidor Web, com 16 GB recomendados para servidores com maior tráfego ou implementações com múltiplos conjuntos aplicacionais configurados para isolamento.

Os requisitos de memória dos servidores de aplicações também diferem; algumas funcionalidades do SharePoint Server 2013 têm requisitos de memória maiores na camada da aplicação do que outras. Na maioria das implementações do SharePoint Server 2013 de produção, recomendamos que aloque, pelo menos, 8 GB de RAM em cada servidor de aplicações; Os servidores de aplicações de 16 GB, 32 GB e 64 GB são comuns quando muitos serviços de aplicação estão ativados no mesmo servidor ou quando os 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 ativados.

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 os seus computadores baseados em SQL Server, veja Planeamento e configuração de capacidade de armazenamento e SQL Server (SharePoint Server).

Escolha da rede

Além do benefício oferecido aos utilizadores, se os clientes tiverem acesso rápido aos dados através da rede, um farm distribuído tem de 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. Existe tráfego significativo num farm na camada do servidor Web, na camada do servidor da aplicação e na camada de servidor da base de dados, e a rede pode facilmente tornar-se um estrangulamento em determinadas condições, como lidar com ficheiros grandes ou cargas elevadas.

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. Por conseguinte, é importante manter menos de 1 milissegundos de latência de rede entre o servidor Web e os computadores baseados em SQL Server que alojam as bases de dados de conteúdos. Os computadores baseados em SQL Server que alojam cada base de dados de aplicação de serviço também devem estar o mais próximo possível do servidor de aplicações que consome. A rede entre os servidores do farm deve ter uma largura de banda mínima de 1 Gbps.

Escolha dos discos e do armazenamento

A gestão de discos não é simplesmente uma função de fornecer espaço suficiente para os seus dados. Tem de avaliar a procura e o crescimento em curso e garantir que a arquitetura de armazenamento não está a abrandar o sistema. Deve sempre certificar-se de que tem, pelo menos, 30% de capacidade adicional em cada disco, acima da estimativa de requisitos de dados mais elevada, para deixar espaço para 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 bases de dados, veja Planeamento e configuração de capacidade de armazenamento e SQL Server (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.

Passo 3: Piloto, Testar e Otimizar

A fase de teste e otimização é um componente importante da gestão eficaz da 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 estiver a atualizar a partir de um ambiente do Office SharePoint Server 2007 e planear fazer alterações arquitetónicas ou estiver a estimar a carga do utilizador das novas funcionalidades do SharePoint Server 2013, teste importante para garantir que o seu novo ambiente baseado no SharePoint Server 2013 irá cumprir os objetivos 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.

Seguem-se os subpassos para a 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. Teste novamente se for necessário.

• Implantar no ambiente de produção.

Testar

Os testes são um fator fundamental para estabelecer a capacidade da conceção do sistema para suportar a carga de trabalho e as características de utilização. Veja Testes de desempenho do SharePoint Server 2013 para obter informações detalhadas sobre como testar a sua implementaçã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 implementar o SharePoint Server 2013 num ambiente de produção, é importante que implemente primeiro um ambiente piloto e teste exaustivamente o farm para garantir que consegue cumprir os objetivos de capacidade e desempenho da carga máxima esperada. Recomendamos que o ambiente piloto seja testado pela primeira vez com carga sintética, especialmente para grandes implementações e, em seguida, sublinhado por um pequeno conjunto de utilizadores em direto e conteúdos em direto. 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 conseguir cumprir os seus objetivos de capacidade e desempenho ao dimensionar o hardware do farm ou efetuar alterações à topologia, poderá ter de considerar rever a sua 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 a última ronda de testes e confirmar que a arquitetura, que selecionou, pode alcançar os objetivos de desempenho e capacidade que estabeleceu no Passo 1: Modelo, pode implementar o seu ambiente baseado no SharePoint Server 2013 para produção.

A estratégia de distribuição apropriada varia dependendo do ambiente e da situação. Embora a implementação do SharePoint Server 2013 esteja geralmente fora do âmbito deste documento, existem determinadas atividades sugeridas que podem sair do exercício de planeamento de capacidade. Aqui estão alguns exemplos:

• Implementar um novo farm do SharePoint Server 2013: O exercício de planeamento de capacidade deve ter orientado e confirmado planos para uma conceção e implementação do SharePoint Server 2016. Neste caso, a implementação será a primeira implementação abrangente do SharePoint Server 2013. Será necessário mover ou reconstruir os servidores e serviços que foram utilizados durante os exercícios de planeamento de capacidade para produção. Este é o cenário mais simples porque não existem quaisquer atualizações ou modificações necessárias para um farm existente.

• Atualizar um farm do Office SharePoint Server 2007 para o SharePoint Server 2013: O exercício de planeamento de capacidade deve ter validado a conceção de um farm que possa satisfazer as exigências existentes e aumentar verticalmente para satisfazer o aumento da procura e utilização de um farm do SharePoint Server 2013. Parte do exercício de planeamento de capacidade deve ter incluído migrações de teste para validar quanto tempo o processo de atualização irá demorar, se qualquer código personalizado tem de ser modificado ou substituído, se quaisquer ferramentas de terceiros têm de ser atualizadas, etc. No final do planeamento de capacidade, deve ter um design validado e compreender quanto tempo demorará a atualizar e um plano para a melhor forma de trabalhar no processo de atualização, por exemplo, uma atualização no local ou a migração de bases de dados de conteúdos para um novo farm. Se estiver a fazer uma atualização no local, durante o planeamento de capacidade, poderá ter descoberto que será necessário hardware adicional ou atualizado e considerações sobre o período de indisponibilidade. Parte da saída do exercício de planeamento deve ser uma lista das alterações de hardware necessárias e um plano detalhado para implementar primeiro as alterações de hardware no farm. Assim que a plataforma de hardware que foi validada durante o planeamento de capacidade estiver implementada, pode avançar com o processo de atualização para o SharePoint Server 2013.

• Melhorar o desempenho de um farm existente do SharePoint Server 2013: O exercício de planeamento de capacidade deve ter ajudado a identificar os estrangulamentos na sua implementação atual, planear formas de reduzir ou eliminar esses estrangulamentos e validar uma implementação melhorada que cumpra os requisitos empresariais dos serviços do SharePoint Server 2013. Existem diferentes formas de resolver problemas de desempenho, desde algo tão fácil como realocar serviços em hardware existente, atualizar hardware existente ou adicionar mais hardware e adicionar mais serviços ao mesmo. As diferentes abordagens devem ser testadas e validadas durante o exercício de planeamento de capacidade e, em seguida, um plano de implementação concebido consoante os 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 Monitorizar e manter o SharePoint Server 2013 para obter uma lista das definições que pode alterar para monitorizar o seu ambiente nas fases iniciais, o que o ajudará a determinar se são necessárias alterações. Lembre-se que aumentar os recursos de monitoramento afetará quanto espaço em disco o banco de dados de uso requer. Assim que o ambiente estiver estável e esta monitorização detalhada já não for necessária, poderá querer reverter as definições abaixo para as predefinições.

Para obter mais informações sobre a monitorização do estado de funcionamento e a resolução de problemas com as ferramentas de monitorização do estado de funcionamento incorporadas na interface de Administração Central do SharePoint Server 2013, consulte:

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

Solucionando problemas

Confira também

Conceitos

Teste de desempenho para SharePoint Server 2013

Monitoramento e manutenção do SharePoint Server 2013

Limites de software para o SharePoint Server 2016

Resultados de teste de capacidade e desempenho e recomendações (SharePoint Server 2013)

Outros recursos

Capacity management and sizing overview for SharePoint Server 2013

Estudos de caso técnicos de desempenho e capacidade (SharePoint Server 2010)