Planejar-se para a disponibilidade (Office SharePoint Server)

  • Artigo

Atualizado em: 2009-04-23

Este artigo descreve a disponibilidade em geral, os custos e os desafios de disponibilidade em um ambiente de Produtos e Tecnologias do SharePoint, além das estratégias e soluções que você pode usar no ambiente. Leia este documento se o farm estiver executando o Microsoft Office SharePoint Server 2007. Convém baixar e imprimir o modelo de Disponibilidade do Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369\&clcid=0x416) que acompanha este artigo. Ele fornece um resumo em tamanho de pôster do conteúdo deste artigo.

Visão geral de disponibilidade

Disponibilidade é o grau até o qual um ambiente de Produtos e Tecnologias do SharePoint é percebido pelos usuários como disponível. Assegurar a disponibilidade significa assegurar que um sistema seja flexível — ou seja, ocorrem poucos incidentes que afetam esse serviço e uma ação efetiva e oportuna é tomada quando eles acontecem. As estratégias de disponibilidade minimizam a percepção do usuário do tempo de inatividade planejado ou não.

Uma das medidas mais comuns de disponibilidade é a porcentagem de tempo de atividade expressa como número de noves — ou seja, a porcentagem de tempo que um determinado sistema está ativo e trabalhando. Por exemplo, considera-se que um sistema com uma porcentagem de tempo de atividade 99.999 tenha cinco noves de disponibilidade.

A tabela a seguir correlaciona o número de noves aos equivalentes de tempo no calendário.

Porcentagem de tempo de atividade aceitável Tempo de inatividade por dia Tempo de inatividade por mês Tempo de inatividade por ano

95

72,00 minutos

36 horas

18,26 dias

99

14,40 minutos

7 horas

3,65 dias

99,9

86,40 segundos

43 minutos

8,77 horas

99,99

8,64 segundos

4 minutos

52,60 minutos

99,999

0,86 segundos

26 segundos

5,26 minutos

Se você puder fazer uma estimativa do número total de horas de tempo de inatividade que provavelmente terá, use as seguintes fórmulas para calcular a porcentagem de tempo de atividade por um ano, mês ou semana:

% Tempo de atividade/ano = 100 - (8760 - número do total de horas de inatividade por ano)/8760

% Tempo de atividade/mês = 100 - ((24 * número de dias no mês) - número do total de horas de inatividade naquele mês do calendário)/(24 * número de dias no mês)

% Tempo de atividade/semana = 100 - (168 - número do total de horas de inatividade naquela semana)/168

O que a disponibilidade não é

A disponibilidade não é a proteção e a recuperação de dados, nem sua recuperação de desastre, embora esses conceitos estejam relacionados e você deva ter planos de proteção de dados e recuperação de desastre em qualquer sistema altamente disponível. Proteger e recuperar dados é a necessidade comercial geral subjacente às seguintes necessidades comerciais específicas:

  • Manter e poder examinar mais de uma versão de um item ou site.

  • Recuperar itens ou sites excluídos acidentalmente.

  • Arquivar dados para fins legais, regulatórios ou comerciais.

  • Restaurar sistemas em caso de falha inesperada de hardware ou software.

Além disso, a disponibilidade não é BCM (business continuation management). O BCM consiste em decisões de negócios, processos e ferramentas que você usa com antecedência para administrar crises. Uma crise pode ser num evento local, regional ou nacional ou pode estar relacionada apenas ao negócio.

As estratégias de disponibilidade e gerenciamento de proteção de dados de Produtos e Tecnologias do SharePoint podem fazer parte do seu plano de BCM técnico, mas o plano de BCM geral deve ser muito mais abrangente, incluindo os seguintes elementos:

  • Procedimentos claramente documentados.

  • Armazenamento fora do site de registros de negócio.

  • Contatos claramente designados.

  • Treinamento contínuo de equipe.

  • Mecanismos de recuperação fora do site.

Custos da disponibilidade

A disponibilidade é um dos requisitos mais caros de um sistema. Quanto maior o nível de disponibilidade e quanto maior o número de sistemas protegidos, mais complexa e cara provavelmente uma solução de disponibilidade será. Quando você investe em disponibilidade, os custos incluem:

  • Hardware e software adicional, com frequência envolvendo operações complexas entre software, como personalizados para failover e recuperação.

  • Complexidade operacional complexa.

Os custos de obtenção de disponibilidade devem ser avaliados com base nas suas necessidades comerciais — nem todas as soluções em uma organização requerem o mesmo nível de disponibilidade. Você pode oferecer níveis diferentes de disponibilidade para sites diferentes, serviços diferentes — por exemplo, inteligência de pesquisa e negócios ou farms diferentes.

A disponibilidade é uma área-chave na qual grupos de tecnologia da informação (TI) oferecem contratos de nível de serviço (SLAs) para definir as expectativas com grupos de clientes. Muitas organizações de TI oferecem vários SLAs associados a níveis de cobrança diferentes.

Dica

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

Desafios para a disponibilidade em Produtos e Tecnologias do SharePoint

Uma implantação de Produtos e Tecnologias do SharePoint propõe os seguintes desafios para fornecer disponibilidade:

  • Durante a aplicação de patches ou a atualização do farm, o farm fica indisponível.

  • A redundância de servidor de indexação não pode ser obtida com a instalação da função de índice em vários servidores. Para superar a perda de um servidor de indexação, será necessário reinstalar o servidor e restaurar de um backup, ou então depender de resultados ligeiramente obsoletos, enquanto a pesquisa rastreia o conteúdo novamente. Se desejar, use uma das técnicas descritas nas seções Disponibilidade de pesquisa em um farm e Disponibilidade de pesquisa entre farms para reduzir o tempo necessário para recuperar a pesquisa.

  • Os Produtos e Tecnologias do SharePoint não reconhecem o espelhamento de banco de dados do Microsoft SQL Server 2005. Embora seja recomendável considerar o uso do espelhamento do SQL Server como uma técnica de disponibilidade do SharePoint, isso requer informações adicionais.

Quando considerar a disponibilidade

É recomendável considerar os requisitos de disponibilidade como parte do design principal da solução do SharePoint. Também é possível fornecer disponibilidade aperfeiçoada após a implantação da solução. Operacionalmente, é recomendável implantar e ajustar a solução principal com um farm e testar as soluções de disponibilidade.

Determinando os requisitos de disponibilidade

Para medir a tolerância de tempo de inatividade da organização para um site, serviço ou farm, responda às perguntas a seguir sobre o site, serviço ou farm.

  • Se o site, serviço ou farm ficar indisponível, os funcionários da organização não poderão executar as responsabilidades esperadas em seus trabalhos?

  • Se o site, serviço ou farm ficar indisponível, as transações de negócios e clientes serão interrompidas, provocando a perda de negócios e clientes?

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

Escolher uma estratégia de disponibilidade

Você pode escolher entre muitos outros métodos para aperfeiçoar a disponibilidade, incluindo:

  • Tolerância a falha de componentes.

  • Redundância e failover entre funções de servidor e bancos de dados em um farm.

  • Redundância e failover entre farms de servidores.

Requisitos de sistema para a disponibilidade

Em um cenário ideal, os componentes e sistemas de failover correspondem ao sistema e aos componentes principais de todas as maneiras: plataforma, hardware, número de servidores. No mínimo, o ambiente de failover deve ser capaz de lidar com o tráfego esperado durante um failover. Tenha em mente que apenas um subconjunto de usuários pode ser atendido pelo site de failover. Os sistemas devem corresponder pelo menos no seguinte:

  • Versão e atualizações do sistema operacional

  • Versões do SQL Server e todas as atualizações

  • Versões e atualizações de Produtos e Tecnologias do SharePoint

Embora este artigo analise principalmente a disponibilidade de Produtos e Tecnologias do SharePoint, o tempo de atividade do sistema também será afetado pelos outros componentes no sistema. Particularmente, considere o seguinte:

Disponibilidade em um farm

Para dar suporte à disponibilidade em um farm, planeje ter componentes tolerantes à falha, funções de servidor redundantes e suporte para disponibilidade de banco de dados, seja por meio de clustering, espelhamento de banco de dados ou os dois.

Tolerância a falhas de componente

Em qualquer sistema, é recomendável trabalhar com fornecedores de hardware para adquirir hardware tolerante a falhas apropriado para o sistema, incluindo matrizes RAID. Para obter as recomendações, consulte Planejar o desempenho e a capacidade (Office SharePoint Server).

Ao planejar a tolerância a falhas de componente, considere o seguinte:

  • A redundância completa de cada componente em um servidor talvez não seja possível ou pode ser impraticável. Use mais servidores para redundância adicional.

  • Considere a redundância de componente para a função de servidor de indexação, porque essa função não pode ser redundante.

  • Verifique se os servidores têm vários suprimentos de energia conectados a fontes de alimentação diferentes para redundância máxima.

Redundância e failover entre funções de servidor em um farm

Os Produtos e Tecnologias do SharePoint suportam a execução de funções de servidor em computadores redundantes (ou seja, adição de mais servidores) em um farm para aumentar a capacidade e melhorar o desempenho e fornecer disponibilidade básica. A capacidade e o desempenho determinam o número de servidores e o tamanho dos servidores em um farm. Depois que você atender aos requisitos básicos, é possível adicionar servidores para aumentar a disponibilidade geral do serviço.

Redundância em um farm de servidor único

Disponibilidade de farm único

A tabela a seguir descreve as funções e os serviços de servidor em um ambiente de Produtos e Tecnologias do SharePoint, conforme listado na página Serviços no Servidor no site Administração Central do SharePoint e as estratégias de redundância básicas que podem ser usadas para cada em um farm.

Serviços no servidor Estratégia de redundância básica preferencial dentro de um farm

Servidores Web

Implante em vários servidores e faça o balanceamento de carga usando balanceamento de carga de software ou hardware.

Servidor Web para farms de servidores médios (aplicativo Web e serviços de consulta de pesquisa)

Implante em vários servidores.

Indexação de pesquisa

Não é possível implantar em vários servidores e ser redundante. Você deve usar uma estratégia de disponibilidade diferente. Para obter mais informações, consulte Disponibilidade de pesquisa em um farm.

Cálculo do Excel

Implante em vários servidores.

Aplicativo do Project

Implante em vários servidores.

Para obter mais informações, consulte Planejar-se para redundância (Office SharePoint Server).

Estratégias de disponibilidade de banco de dados para um único farm

A disponibilidade do banco de dados em um farm pode ser fornecida usando clusters do SQL Server ou espelhamento de alta disponibilidade do SQL Server (chamado também de espelhamento síncrono).

Clustering O cluster de failover fornece suporte de disponibilidade para toda uma instância do SQL Server. Um cluster de failover é uma combinação de um ou mais nós ou servidores, com dois ou mais discos compartilhados. Uma instância de cluster de failover aparece como um único computador, mas tem funcionalidade que fornecerá failover de um nó para outro se o nó atual se tornar indisponível.

O Office SharePoint Server 2007 referencia o cluster como um todo, portanto, o failover é automático e contínuo da perspectiva dos Produtos e Tecnologias do SharePoint.

Espelhamento síncrono de banco de dados O espelhamento de banco de dados fornece suporte de disponibilidade enviando as transações diretamente de um banco de dados e servidor principais para um banco de dados e servidor espelhados sempre que o buffer do log da transação do banco de dados principal for gravado em um disco. Recomendamos que você use espelhamento de banco de dados de alta disponibilidade, também denominado 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 entidade de segurança, um espelho e uma testemunha. O servidor testemunha permite failover automático do SQL Server do servidor principal para o servidor espelhado. O failover do banco de dados principal para o banco de dados espelhado normalmente leva vários segundos.

Cada tecnologia tem vantagens e desvantagens. O clustering é mais fácil de implementar, mas pode ser mais caro. Não há suporte para o espelhamento do SQL Server em bancos de dados do Microsoft Office Project Server 2007.

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

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

O espelho assume imediatamente após a falha.

O espelho assume imediatamente após a falha.

Transacionalmente consistente.

Transacionalmente consistente.

Transacionalmente concorrente.

Transacionalmente concorrente.

Menor tempo para recuperação (segundos a minutos).

Tempo para recuperação ligeiramente maior (segundos a minutos).

A falha é detectada automaticamente pelos nós do banco de dados; os Produtos e Tecnologias do SharePoint referenciam o cluster, assim, o failover de uma perspectiva de Produtos e Tecnologias do SharePoint é contínuo e automático.

Requer script para obter failover de Produtos e Tecnologias do SharePoint.

Não protege contra o armazenamento com falha, porque o armazenamento é compartilhado entre os nós no cluster.

Protege contra o armazenamento com falha porque os servidores de banco de dados principal e espelho gravam em discos locais.

Requer armazenamento compartilhado mais caro.

Pode usar DAS mais econômico.

Mesma sub-rede.

Até 1 milissegundo (ms) em latência entre o SQL Server e os servidores Web.

Pode usar o modelo de recuperação simples do SQL Server, embora o único ponto de recuperação disponível se o cluster for perdido seja o último backup completo.

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

Nenhuma sobrecarga de desempenho.

Introduz a latência transacional. Adiciona sobrecarga de memória e processador.

Carga operacional mínima.

Carga operacional adicional, incluindo criação de script e configuração de alias do SQL Server.

Para obter mais informações sobre como usar clustering, consulte Configurar disponibilidade em um único farm usando clustering do SQL Server.

Para obter mais informações sobre como usar espelhamento síncrono, consulte Configurar disponibilidade em um único farm usando espelhamento de banco de dados do SQL Server e Usando espelhamento de banco de dados (Office SharePoint Server) (white paper).

Redundância e failover entre centros de dados próximos configurados como um único farm (farm “estendido”)

Algumas empresas têm centros de dados próximos com conexões de alta largura de banda, de modo que podem ser configurados como um único farm. Ele se chama farm “estendido”. Para que um farm estendido funcione, deve haver uma latência de menos de 1 milissegundo entre o SQL Server e os servidores Web em uma direção, e uma largura de banda de pelo menos 1 gigabit por segundo.

  • Neste cenário, você pode fornecer redundância para bancos de dados do SharePoint usando espelhamento síncrono. Em um farm estendido, você pode espelhar o banco de dados de configuração e os bancos de dados de conteúdo. Para obter um estudo de caso sobre o modo como uma empresa usou um farm estendido, consulte Estudo de caso de alta disponibilidade para SharePoint usando espelhamento de banco de dados (white paper).

  • Consulte o fornecedor de SAN para determinar se você pode usar a replicação de SAN em outro mecanismo com suporte para fornecer disponibilidade entre os centros de dados, como o SQL Server em execução em clusters de servidor geograficamente dispersos. Verifique se a solução de replicação de SAN oferece um nível suficiente de simultaneidade e consistência transacional.

Em um farm estendido, você pode fornecer tolerância a falhas para servidores de aplicativos executando SSPs estabelecendo:

  • Vários servidores de consulta

  • Vários servidores que estão sendo executados Serviços de Cálculo do Excel

O servidor de indexação é um único ponto de falha nesse cenário. Você pode fazer backup da pesquisa ou restaurá-la ou, se a atualidade da pesquisa na recuperação for importante, use um farm SSP de failover. Para obter mais informações, consulte Pesquisar disponibilidade em um farm.

O Project Server é outro ponto de falha único neste cenário. Planeje fazer backup e restaurar seus bancos de dados do Project Server.

Farm “estendido”

Farm "estendido"

Pesquisar disponibilidade em um farm

A função de servidor de indexação não pode ser redundante em um farm. As necessidades comerciais da empresa referentes ao grau de atualidade da pesquisa após o failover ajudarão a determinar a arquitetura lógica da solução.

Se a empresa não exigir atualidade de pesquisa e disponibilidade imediatas após o failover, você poderá fazer backup do SSP da Pesquisa e restaurá-lo no site de failover.

Se a empresa exigir atualidade de pesquisa e disponibilidade rápidas, use um destes métodos:

  • Uma arquitetura de farm único com dois SSPs idênticos.

    Dica

    Se a empresa exigir rápida simultaneidade e disponibilidade de pesquisa e você estiver usando perfis, os perfis dos SSPs de failover não serão sincronizados nos perfis dos SSPs principais. Eles estarão no mesmo estado em que foram importados pela primeira vez. Para manter os perfis de todos os SSPs sincronizados, é necessário usar o Mecanismo de Replicação de Perfil do Usuário que está incluído no Kit de Ferramentas da Administração do SharePoint de 32 bits (em inglês) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x416) ou no Kit de Ferramentas da Administração do SharePoint de 64 bits (em inglês) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x416). Para obter mais informações, consulte User Profile Replication Engine (Office SharePoint Server).

  • Um farm pai centralizado que hospede a pesquisa e outros SSPs. O serviço de pesquisa no farm central rastreia conteúdo em todos os outros farms. Essa arquitetura pode ser usada para dar suporte a um ou mais farms.

Farm único com dois SSPs

A arquitetura a seguir protege contra a falha de um servidor de indexação. Nesta topologia, os dois SSPs rastreiam o mesmo conteúdo, usando as mesmas regras. O SSP de failover não é associado ao site principal, a menos que ocorra um failover.

Farm único com dos SSPs

Farm com dois SSPs

Esta topologia tem as seguintes limitações:

A capacidade de rastrear conjuntos de dados grandes de modo oportuno é afetada por vários fatores, incluindo a latência e a largura de banda entre os servidores de indexação e os servidores Web.

Em um ambiente com largura de banda limitada, essa topologia pode reduzir significativamente o desempenho. Rastrear o conteúdo duas vezes coloca mais carga nos repositórios de conteúdo sendo rastreados, o que pode afetar o desempenho do repositório. A capacidade de pesquisa para manter o índice atualizado também pode ser afetada de modo negativo.

Farms de SSP centralizados

Na arquitetura a seguir, o uso de um farm de SSP pai protege contra a falha de um servidor de indexação. Embora isso possa parecer uma solução intensiva de hardware, farms de SSP separados podem compartilhar alguns itens de hardware, como um servidor de banco de dados em cluster ou espelhado, desde que os servidores de indexação residam em servidores separados. Para obter mais informações sobre como planejar e configurar farms de SSP, consulte Planejar arquitetura de SSP.

Esta topologia tem os seguintes benefícios:

  • O gerenciamento de SSP é centralizado.

  • A falha de um farm não requer um novo rastreamento.

Farms de SSP centralizados

Farms de failover de SSP

Esta topologia tem as seguintes limitações:

Redundância e failover entre centros de dados com vários farms

Você pode configurar um farm de failover para fornecer disponibilidade em um centro de dados separado do farm principal. Um ambiente com um farm de failover separado tem as seguintes características:

  • Um banco de dados de configuração separado e um banco de dados de conteúdo da Administração Central devem ser mantidos no farm de failover.

    Dica

    Se você tiver configurado mapeamento de acesso alternativo ao farm principal, será especialmente importante configurá-lo de modo idêntico no farm de failover.

  • Todas as personalizações devem ser implantadas nos dois farms.

  • Os patches devem ser aplicados aos dois farms, separadamente.

  • Somente bancos de dados de conteúdo podem ser espelhados de modo assíncrono com êxito ou ter o log enviado ao farm de failover.

  • Bancos de dados espelhados ou com log enviado devem ser configurados para usar o modelo de recuperação completa.

  • É possível fazer o backup e restaurar bancos de dados, incluindo bancos de dados do Office Project 2007 e SSP.

Consulte o fornecedor de SAN para determinar se você pode usar replicação de SAN em outro mecanismo com suporte para fornecer disponibilidade entre centros de dados.

Essa topologia poderá ser repetida entre muitos centros de dados, se você configurar o envio de log do SQL Server para um ou mais centros de dados adicionais.

Dica

O espelhamento do SQL Server somente poderá ser usado com um servidor de espelho, mas você pode enviar o log a vários servidores secundários.

Farms principal e de failover antes do failover

Farms primário e de failover antes do failover

A tabela a seguir lista os serviços e as funções de servidor em um ambiente de Produtos e Tecnologias do SharePoint e as estratégias de redundância básicas que podem ser usadas para cada entre os farms de servidores.

Servidor ou função de servidor Estratégia de redundância básica preferencial entre farms

SQL Server

Espelhamento de banco de dados assíncrono do SQL Server, envio de log do SQL Server ou outro mecanismo de replicação assíncrona.

ObservaçãoObservação:
Não pode ser usado para bancos de dados SSP que hospedam informações de pesquisa, nem para bancos de dados do Project Server.

Servidores Web de front-end

Implante nos dois farms, incluindo as personalizações.

Servidor Web para farms de servidores médios (aplicativo Web e serviços de consulta de pesquisa)

Implante nos dois farms.

Indexação de pesquisa

Implante nos dois farms. Recupere o backup do farm original para mover para o farm de failover.

Cálculo do Excel

Implante nos dois farms. Se o SSP não hospedar a pesquisa, use o espelhamento de banco de dados assíncrono, o envio de log do SQL Server ou outro mecanismo de replicação assíncrona para mover dados para o farm de failover.

Se o SSP também hospedar a pesquisa, será necessário recuperar o backup do farm original para mover.

Aplicativo do Project

Implante nos dois farms. Recupere o backup do farm original para mover para o farm de failover.

Disponibilidade de pesquisa entre farms

A pesquisa requer sincronização completa entre o banco de dados de pesquisa, o banco de dados SSP e o índice. Devido a esse requisito, não é possível replicar a pesquisa entre farms usando um mecanismo de replicação assíncrona (espelhamento de banco de dados assíncrono, envio de log e replicação de SAN assíncrona).

Dica

Se você estiver executando um SSP sem pesquisa ou sem o Project, use um mecanismo de replicação assíncrona para mover dados.

Para fornecer pesquisa em um farm de failover, você deve usar um dos seguintes métodos:

  • Recuperar um backup do SSP de pesquisa para o farm de failover.

  • Use um farm pai centralizado que hospeda SSPs de pesquisa e outros SSPs. O serviço de pesquisa no farm central rastreia o conteúdo em todos os outros farms.

Resumo

Examine atentamente seus requisitos de disponibilidade. Quanto maior o nível de disponibilidade e quanto maior o número de sistemas protegidos, mais complexa e cara provavelmente uma solução de disponibilidade será.

Os custos de obtenção de disponibilidade devem ser avaliados com base nas necessidades comerciais. Nem todas as soluções em uma organização requerem o mesmo nível de disponibilidade. Você pode oferecer níveis diferentes de disponibilidade para sites diferentes, serviços diferentes (por exemplo, pesquisa e inteligência comercial) ou farms diferentes.

Agradecimentos

A equipe de Publicação de Conteúdo do Microsoft Office SharePoint Server agradece aos seguintes revisores técnicos deste documento:

  • Bill Baer, Microsoft Online Services, SharePoint hospedado, arquiteto de tecnologia

  • James Petrosky, Serviços de Consultoria Microsoft, consultor sênior

  • Steve Peschka, Serviços de Consultoria Microsoft, arquiteto sênior IW

  • Dan Winter, Serviços de Atendimento ao Cliente Microsoft, engenheiro de escalonamento

  • Sean Livingston, Produtos e Tecnologias do Microsoft SharePoint, gerente de programa

  • Mike Watson, arquiteto de tecnologia

  • Todd Carter, engenheiro de campo do Microsoft Premier e do Principal Premier

  • Mike Plumley, Microsoft Office Project Server, Redator

  • Christophe Fiessinger, Microsoft Office Project, gerente de produto técnico sênior

  • Sid Shah, Microsoft Search, gerente de programa

  • Luca Bandinelli, Microsoft SharePoint Products and Technologies, Gerente de programação

Baixar esse manual

Este tópico inclui o seguinte manual que pode ser baixado para leitura e impressão mais fácil:

Consulte também

Conceitos

Configurar a alta disponibilidade (Office SharePoint Server)