Compartilhar via

Planejar a disponibilidade (SharePoint Server 2010)

  • Artigo

 

Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve as principais decisões a serem tomadas ao escolher as estratégias de disponibilidade para um ambiente do Microsoft SharePoint Server 2010.

Quando estiver revisando cuidadosamente seus requisitos de disponibilidade, esteja ciente de que quanto maior o nível de disponibilidade e quanto mais sistemas você protege, mais complexa e onerosa provavelmente será a sua solução de disponibilidade.

Nem todas as soluções em uma organização devem exigir o mesmo nível de disponibilidade. Você pode oferecer diferentes níveis de disponibilidade para sites diferentes, serviços diferentes ou farms diferentes.

Neste artigo:

  • Visão geral de disponibilidade

  • Escolhendo uma estratégia e um nível de disponibilidade

  • A redundância e o failover entre data centers em locais próximos são configurados como um único farm (farm "alongado")

Visão geral de disponibilidade

A disponibilidade é um grau pelo qual um ambiente do SharePoint Server é percebido por usuários como disponível. Um sistema disponível é um sistema flexível — ou seja, incidentes que afetem o serviço ocorrem com pouca frequência e ações oportunas e eficientes são tomadas quando eles ocorrem.

A disponibilidade faz parte do gerenciamento de continuidade de negócios (BCM) e está relacionada a backup e recuperação e recuperação de desastre. Para obter mais informações sobre esses processos relacionados, consulte Plano de backup e recuperação no SharePoint Server 2010 e Planejar a recuperação de desastre (SharePoint Server 2010).

Observação

Ao calcular a disponibilidade, a maioria das organizações especificamente isenta ou adiciona horas para atividades de manutenção planejada.

Uma das medidas mais comuns de disponibilidade é o percentual de duração da operação, expresso como número de noves — ou seja, o percentual de tempo em que um determinado sistema está ativo e em funcionamento. Por exemplo, diz-se que um sistema com percentual de duração da operação de 99,999 tem cinco noves de disponibilidade.

A tabela a seguir correlaciona o percentual de duração da operação com equivalentes de hora de calendário.

Percentual de duração da operação aceitável Tempo de inatividade por dia Tempo de inatividade por mês Tempo de inatividade por ano

95

72 minutos

36 horas

18,26 dias

99 (dois noves)

14,40 minutos

7 horas

3,65 dias

99,9 (três noves)

86,40 segundos

43 minutos

8,77 horas

99,99 (quatro noves)

8,64 segundos

4 minutos

52,60 minutos

99,999 (cinco noves)

0,86 segundo

26 segundos

5,26 minutos

Se você puder fazer uma boa estimativa sobre o número total de horas de tempo de inatividade provável por ano, poderá usar as fórmulas a seguir para calcular o percentual de duração da operação para um ano, um mês ou uma semana:

% duração da operação/ano = 100 - (8760 - número total de horas de tempo de inatividade por ano)/8760

% duração da operação/mês = 100 - ((24 × número de dias do mês) - número total de horas de tempo de inatividade nesse mês do calendário)/(24 × número de dias do mês)

% duração da operação/semana = 100 - (168 - número total de horas de tempo de inatividade nessa semana)/168

Custos de disponibilidade

Quanto maior o nível de disponibilidade e quanto mais sistemas você protege, mais complexa e onerosa provavelmente será a sua solução de disponibilidade. Quando você investe em disponibilidade, os custos incluem o seguinte:

  • Hardware e software adicionais, o que poderá aumentar a complexidade de interações entre aplicativos de software e configurações.

  • Complexidade operacional adicional.

Os custos de aumentar a disponibilidade devem ser avaliados em conjunto com as necessidades da sua empresa — nem todas as soluções em uma organização devem exigir o mesmo nível de disponibilidade. Você pode oferecer diferentes níveis de disponibilidade para sites diferentes, serviços diferentes ou farms diferentes.

A disponibilidade é uma área fundamental em que grupos de TI (tecnologia da informação) oferecem contratos de nível de serviço para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários contratos de nível de serviço, que são associados a diferentes níveis de estorno.

Determinando requisitos de disponibilidade

Para medir a tolerância da sua organização em relação ao tempo de inatividade de um site, serviço ou farm, responda às seguintes perguntas:

  • Se o site, serviço ou farm ficar indisponível, os funcionários não conseguirão executar as responsabilidades de trabalho esperadas?

  • Se o site, serviço ou farm ficar indisponível, as transações empresariais e de clientes serão paradas, levando a perdas de negócios e de clientes?

Se você respondeu sim para uma dessas perguntas, deverá investir em uma solução de disponibilidade.

Escolhendo uma estratégia e um nível de disponibilidade

Você pode optar entre várias abordagens para aumentar a disponibilidade no ambiente do SharePoint Server, incluindo o seguinte:

  • Aprimorar a tolerância a falhas de componentes de hardware de servidor.

  • Aumentar a redundância de funções de servidor em um farm.

Tolerância a falhas de componente de hardware

A tolerância a falhas de componente de hardware é a redundância de componentes de hardware e sistemas de infraestrutura, como fontes de alimentação, no nível do servidor. Quando estiver planejando a tolerância a falhas de componentes de hardware, considere o seguinte:

  • A redundância completa de todos os componentes de um servidor pode ser impossível ou impraticável. Use outros servidores para obter redundância adicional.

  • Garanta que os servidores tenham várias fontes de alimentação conectadas a fontes de energia diferentes para obter a redundância máxima.

Em qualquer sistema, recomendamos que você trabalhe com fornecedores de hardware para obter hardware tolerante a falhas apropriado ao sistema, incluindo matrizes RAID (redundant array of independent disks). Para obter recomendações, consulte Gerenciamento de desempenho e capacidade (SharePoint Server 2010) e Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010).

Redundância em um farm

O SharePoint Server 2010 oferece suporte à execução de funções de servidor em computadores redundantes (ou seja, dimensionamento) em um farm para aumentar a capacidade e oferecer disponibilidade básica.

A capacidade necessária determina o número de servidores e o tamanho dos servidores em um farm. Depois de atingir os seus requisitos de capacidade base, talvez seja necessário adicionar mais servidores para aumentar a disponibilidade geral. A ilustração a seguir mostra como você pode oferecer redundância para cada função de servidor.

Disponibilidade em um farm de servidores

Disponibilidade de farm único

A tabela a seguir descreve as funções de servidor em um ambiente do SharePoint Server 2010 e as estratégias de redundância que podem ser usadas para cada uma delas em um farm.

Função de servidor Estratégia de redundância preferencial em um farm

Servidor Web front-end

Implante vários servidores Web front-end em um farm e use o NLB (Balanceamento de Carga de Rede).

Servidor de aplicativos

Implante vários servidores de aplicativos em um farm.

Servidor de banco de dados

Implante servidores de banco de dados usando cluster ou espelhamento de banco de dados de alta disponibilidade.

Estratégias de disponibilidade de banco de dados

Você pode usar o cluster de failover do Microsoft SQL Server ou o espelhamento de banco de dados de alta disponibilidade do SQL Server para oferecer suporte à disponibilidade de bancos de dados em um ambiente do SharePoint Server.

Cluster de failover do SQL Server

O cluster de failover pode oferecer suporte a disponibilidade para uma instância do SQL Server. Um cluster de failover é uma combinação de um ou mais nós ou servidores e dois ou mais discos compartilhados. Uma instância de cluster de failover aparece como um único computador, mas tem funcionalidade que oferece failover de um nó para outro caso o nó atual fique indisponível. O SharePoint Server pode ser executado em qualquer combinação de nós ativos e passivos em um cluster com suporte do SQL Server.

O SharePoint Server faz referências ao cluster como um todo; dessa forma, o failover é automático e direto da perspectiva do SharePoint Server.

Para obter informações detalhadas sobre cluster de failover, consulte Introdução ao cluster de failover do SQL Server 2008 (https://go.microsoft.com/fwlink/?linkid=102837&clcid=0x416) e Configure availability by using SQL Server clustering (SharePoint Server 2010).

Espelhamento de alta disponibilidade do SQL Server

O espelhamento de banco de dados é uma tecnologia do SQL Server que pode oferecer redundância para cada banco de dados. No espelhamento de banco de dados, as transações são enviadas diretamente de um banco de dados e de um servidor principal para um banco de dados espelho quando o buffer de log de transações do banco de dados principal é gravado no disco. Essa técnica é capaz de manter o banco de dados espelho praticamente atualizado com o banco de dados principal. O SQL Server Enterprise Edition dispõe de uma funcionalidade adicional que melhora o desempenho de espelhamento do banco de dados. Para obter mais informações, consulte SQL Server 2008 R2 e Produtos do SharePoint 2010: melhores juntos (white paper) (SharePoint Server 2010).

Para espelhamento em um farm do SharePoint Server, você deverá usar o espelhamento de alta disponibilidade, também conhecido como modo de alta segurança com failover automático. O espelhamento de banco de dados de alta disponibilidade envolve três instâncias de servidor:uma principal, um espelho e uma testemunha. O servidor testemunha permite que o SQL Server faça o failover automático do servidor principal para o servidor espelho. O failover do banco de dados principal para o banco de dados de espelho normalmente leva alguns segundos.

Uma alteração de versões anteriores é que o SharePoint Server reconhece espelhamentos. Depois de configurar uma instância de espelho de banco de dados do SQL Server, você utiliza a Administração Central do SharePoint ou cmdlets do Windows PowerShell para identificar a localização do servidor de banco de dados (espelho) de failover para um banco de dados de configuração, um banco de dados de conteúdo ou um banco de dados de aplicativo de serviço. A definição da localização do banco de dados de failover adiciona um parâmetro à cadeia de conexão que o SharePoint Server usa para se conectar ao SQL Server. No caso de um evento de expiração de tempo limite do SQL Server, ocorrerá o seguinte:

  1. O servidor testemunha configurado para espelhamento do SQL Server automaticamente alterna as funções dos bancos de dados primário e espelho.

  2. O SharePoint Server tenta automaticamente contatar o servidor especificado como o banco de dados de failover.

Para obter informações sobre como configurar o espelhamento de banco de dados, consulte Configurar a disponibilidade usando o espelhamento de banco de dados do SQL Server (SharePoint Server 2010).

Para obter informações gerais sobre o espelhamento de banco de dados, consulte Espelhamento de banco de dados (https://go.microsoft.com/fwlink/?linkid=180597&clcid=0x416).

Observação

Não é possível espelhar bancos de dados configurados para usar o provedor remoto de repositório de BLOB de FILESTREAM do SQL Server.

Comparação de estratégias de disponibilidade de banco de dados para um único farm: cluster de failover do SQL Server versus espelhamento de alta disponibilidade do SQL Server

A tabela a seguir compara o cluster de failover ao espelhamento de alta disponibilidade do SQL Server síncrono.

Cluster de failover do SQL Server Espelhamento de alta disponibilidade do SQL Server

Tempo para failover

O membro de cluster assume a falha imediatamente.

O espelho assume a falha imediatamente.

Consistência transacional?

Sim

Sim

Simultaneidade transacional?

Sim

Sim

Tempo para recuperação

Tempo menor para recuperação (milissegundos)

Tempo ligeiramente menor para recuperação (milissegundos)

Etapas exigidas para failover?

A falha é automaticamente detectada pelos nós do banco de dados; o SharePoint Server 2010 faz referência ao cluster para que o failover seja direto e automático.

A falha é automaticamente detectada pelo banco de dados; o SharePoint Server 2010 reconhecerá o local do espelho se tiver sido configurado corretamente, portanto, o failover será automático.

Proteção contra falha de armazenamento?

Não protege contra falha de armazenamento, pois o armazenamento é compartilhado entre os nós do cluster.

Protege contra falha de armazenamento porque os dois servidores de banco de dados, principal e espelho, gravam nos discos locais.

Tipos de armazenamento com suporte

Armazenamento compartilhado (mais caro).

É possível usar o DAS (direct-attached storage), que é mais econômico.

Requisitos de local

Os membros do cluster devem estar na mesma sub-rede.

Os servidores principal, espelho e testemunha devem estar na mesma LAN (viagem de ida e volta com latência de até 1 milissegundo).

Modelo de recuperação

É recomendável o modelo de recuperação completa do SQL Server. Você pode usar o modelo de recuperação simples do SQL Server, porém, se o cluster for perdido, o único ponto de recuperação disponível será o último backup completo. Para obter mais informações, consulte Planejamento e configuração de armazenamento e capacidade do SQL Server (SharePoint Server 2010) e Plan for SQL Server, storage and BLOB configuration (SharePoint Foundation 2010).

Exige o modelo de recuperação completa do SQL Server.

Sobrecarga de desempenho

Alguma redução de desempenho pode ocorrer durante um failover.

O espelhamento de alta disponibilidade introduz latência transacional porque é síncrono. Ele também exige memória adicional e sobrecarga de processador.

Carga operacional

Configurada e mantida no nível de servidor.

A carga operacional é maior do que o clustering. Deve ser configurada e mantida em todos os bancos de dados. A reconfiguração após o failover é manual.

Estratégias de redundância de aplicativo de serviço

A estratégia de redundância a ser seguida para proteger os aplicativos de serviço executados em um farm varia conforme o local onde o aplicativo de serviço armazena os dados.

Aplicativos de serviço que armazenam dados fora de um banco de dados

Para proteger os aplicativos de serviço que armazenam dados fora de um banco de dados, instale-os em vários servidores de aplicativos para oferecer redundância ao ambiente.

Nesta versão do SharePoint Server, quando você instalar um aplicativo de serviço em vários servidores de aplicativos, os trabalhos de timer serão executados em todos os servidores de aplicativos que estiverem executando a instância do serviço associada a esse aplicativo de serviço ou no primeiro servidor disponível. Se houver falhas em um servidor de aplicativos, os trabalhos de timer executados nesse servidor serão reiniciados em outro servidor quando o próximo trabalho de timer estiver programado para ser executado.

A instalação de um aplicativo de serviço em vários servidores de aplicativos mantém o aplicativo de serviço funcionando, mas não garante que os dados não serão perdidos. Se houver falha em um servidor de aplicativos, as conexões ativas desse servidor serão perdidas e os usuários perderão alguns dados.

Os seguintes aplicativos de serviço armazenam dados fora de um banco de dados:

  • Serviços do Access

  • Aplicativo de Serviços do Excel

Aplicativos de serviço que armazenam dados em bancos de dados

Para ajudar a proteger os aplicativos de serviço que armazenam dados em bancos de dados, execute as seguintes etapas:

  1. Instale o serviço em vários servidores de aplicativos para fornecer redundância no ambiente.

  2. Configure o cluster ou o espelhamento do SQL Server para proteger os dados.

Estes aplicativos de serviço armazenam dados em bancos de dados:

  • Aplicativo de serviço de pesquisa, incluindo os seguintes bancos de dados:

    • Administração de Pesquisa

    • Rastreamento

    • Propriedade

      Observação

      Há suporte para o espelhamento dos bancos de dados de Pesquisa, mas oferecer redundância para a Pesquisa exige trabalho adicional. Para obter detalhes, consulte Estratégias de redundância de pesquisa em um farm.

  • Serviço de Perfil de Usuário, incluindo os seguintes bancos de dados:

    • Perfis

    • Social

    • Sincronização

      Observação

      Não há suporte para o espelhamento do banco de dados de Sincronização.

  • Aplicativo Serviço de Conectividade de Dados Corporativos

  • Aplicativo de serviço de Registro de Aplicativo

    Não é recomendável fazer o espelhamento do banco de dados de Registro de Aplicativo porque ele é usado apenas durante a atualização de informações do Catálogo de Dados Corporativos do Microsoft Office SharePoint Server 2007 para o SharePoint Server 2010.

  • Aplicativo de Serviço de Conjunto de Dados de Uso e Integridade

    Observação

    Não é recomendável fazer o espelhamento do banco de dados de registro em log do aplicativo de serviço de Conjunto de Dados de Uso e Integridade.

  • Aplicativo de serviço de Metadados Gerenciados

  • Aplicativo de serviço de Repositório Seguro

  • Aplicativo de serviço de Controle de Sessão

  • Aplicativo de serviço do Web Analytics, incluindo os seguintes bancos de dados:

    • Relatórios

    • Preparo

      Observação

      Não há suporte para o espelhamento do banco de dados de Preparo.

  • Aplicativo de serviço dos Word Automation Services

  • Serviço de Configurações de Inscrição do Microsoft SharePoint Foundation

  • Serviços do PerformancePoint

Estratégias de redundância de pesquisa em um farm

Somente Servidor

O aplicativo de serviço de Pesquisa é um caso especial de redundância em um farm. A ilustração a seguir mostra como a redundância e o failover podem ser configurados para um aplicativo de serviço de Pesquisa médio dedicado que rastreia aproximadamente 40 milhões de itens. Para obter mais informações sobre a arquitetura do aplicativo de serviço de Pesquisa, consulte "Arquiteturas de pesquisa do Microsoft SharePoint Server 2010" no artigo Diagramas técnicos (SharePoint Server 2010).

Aplicativo de serviço de Pesquisa Redundante

Arquitetura de pesquisa altamente disponível

  • Servidor de consulta. Um servidor de consulta hospeda os componentes e as partições de índice de uma consulta.

    • Os componentes de consulta retornam os resultados da pesquisa. Cada componente de consulta faz parte de uma partição de índice, que é associada a um banco de dados de propriedade específico que contém metadados associados a determinado conjunto de conteúdo rastreado. Você pode fazer com que uma partição de índice fique redundante adicionando componentes de consulta "espelhados" à ela e colocando-os em servidores de farm diferentes.

      Observação

      O uso do termo componentes de consulta espelhados refere-se a cópias de arquivo idênticas, e não ao espelhamento de bancos de dados do SQL Server.

    • As partições de índice são grupos de componentes de consulta, cada um com um subconjunto do índice de texto completo que retorna os resultados da pesquisa. Cada partição de índice é associada a um banco de dados de propriedade específico que contém metadados associados a determinado conjunto de conteúdo rastreado. Você pode escolher quais servidores de um farm lidarão com as consultas criando um componente de consulta nesse servidor. Se quiser equilibrar a carga de manipulação de consultas em vários servidores do farm, adicione componentes de consulta a uma partição de índice e associe-os aos servidores que deseja usar para lidar com as consultas. Para obter mais informações, consulte Add or remove a query component. Você pode fazer com que uma partição de índice fique redundante adicionando componentes de consulta espelhados à ela e colocando-os em servidores de consulta diferentes.

  • Servidor de rastreamento. Um servidor de rastreamento hospeda componentes de rastreamento e um componente de administração de pesquisa.

    • Os componentes de rastreamento processam rastreamentos de fontes de conteúdo, propagam arquivos de índice resultantes aos componentes de consulta e adicionam informações sobre o local e o agendamento de rastreamento de fontes de conteúdo aos bancos de dados de rastreamento associados. Eles também são associados a um único aplicativo de serviço de Pesquisa. Você pode distribuir a carga de rastreamento adicionando componentes de rastreamento a diferentes servidores de rastreamento. Você pode ter quantos componentes de rastreamento os recursos permitirem em um servidor de rastreamento especificado. Se você tiver muitos locais de conteúdo, poderá adicionar componentes de rastreamento e bancos de dados de rastreamento e dedicá-los ao conteúdo específico. Cada componente de rastreamento em determinado servidor de rastreamento deve estar associado a um banco de dados de rastreamento separado. Para obter redundância, é recomendável que você tenha no mínimo dois componentes de rastreamento. Cada um deles deve ser definido para rastrear os dois bancos de dados de rastreamento. Se um banco de dados ultrapassar 25 milhões de itens, é recomendável adicionar um novo banco de dados de rastreamento e componente de rastreamento.

    • O componente de administração de pesquisa monitora as ações de entrada do usuário e atualiza o banco de dados de administração de pesquisa. Apenas um componente de administração de pesquisa é permitido por aplicativo de serviço de Pesquisa. O componente de administração de pesquisa pode ser executado em qualquer servidor, preferencialmente em um servidor de rastreamento ou de consulta.

  • Servidores de banco de dados. Os servidores de banco de dados hospedam bancos de dados de rastreamento, de propriedade, de administração de pesquisa e outros bancos de dados do SharePoint Server 2010.

    • Banco de dados de rastreamento

      Os bancos de dados de rastreamento contêm dados relacionados ao local das fontes de conteúdo, agendamentos de rastreamento e outras informações específicas às operações de rastreamento de determinado aplicativo de serviço de Pesquisa. Você pode distribuir a carga do banco de dados adicionando bancos de dados de rastreamento a diferentes computadores que estiverem executando o SQL Server. Os bancos de dados de rastreamento são associados a componentes de rastreamento e podem ser dedicados a hosts específicos por meio da criação de regras de distribuição de host. Para obter mais informações sobre os componentes de rastreamento, consulte Add or remove a crawl component (SharePoint Server 2010). Para obter mais informações sobre as regras de distribuição de host, consulte Add or remove a host distribution rule. Os bancos de dados de rastreamento serão redundantes se forem espelhados ou implantados em um cluster de failover do SQL Server.

    • Banco de dados de propriedade

      Os bancos de dados de propriedade contêm metadados associados ao conteúdo rastreado. Você pode distribuir a carga das consultas do banco de dados adicionando bancos de dados de propriedade a diferentes computadores que estejam executando o SQL Server. Os bancos de dados de propriedade são associados a partições de índice e retornam todos os metadados associados ao conteúdo nos resultados da consulta.

      Os bancos de dados de propriedade serão redundantes se forem espelhados ou implantados em um cluster de failover do SQL Server.

    • Banco de dados de administração de pesquisa

      Há apenas um banco de dados de Administração de Pesquisa por instância do aplicativo de serviço de Pesquisa em um farm.

      O banco de dados de Administração de Pesquisa será redundante apenas se for espelhado ou implantado em um cluster de failover do SQL Server.

Para obter mais informações sobre a redundância de pesquisa, consulte Manage search topology (SharePoint Server 2010).

A redundância e o failover entre data centers em locais próximos são configurados como um único farm (farm "alongado")

Algumas empresas têm data centers localizados próximos entre si, com conexões de largura de banda alta, e, dessa forma, eles podem ser configurados como um único farm. Isso é chamado de farm "alongado". Para que um farm alongado funcione, a latência deve ser menor do que 1 milissegundo entre o SQL Server e os servidores Web front-end em uma única direção e a largura de banda deve ser de pelo menos 1 gigabit por segundo.

Nesse cenário, você pode fornecer tolerância a falhas. Siga as diretrizes padrão para criar redundância de bancos de dados e aplicativos de serviço.

A ilustração a seguir mostra um farm alongado.

Farm alongado

Farm "estendido"