Compartilhar via

Planejar disponibilidade (Search Server 2008)

  • Artigo

Atualizado em: 2009-03-11

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

O que é 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, que ocorram poucos incidentes que afetem esse serviço e uma ação efetiva e oportuna seja tomada quando 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 tempo de natividade que provavelmente terá, use as seguintes fórmulas para calcular a porcentagem de tempo de atividade por 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/ano = 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 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:

  • Capacidade de manter e revisar mais de uma versão de um item ou site.

  • Recuperação de itens ou sites excluídos acidentalmente.

  • Arquivamento de dados por motivos legais, normativos ou comerciais.

  • Restauração de 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 um evento local, regional ou nacional ou pode estar relacionada apenas à sua empresa.

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 local de registros de negócios.

  • Contatos claramente designados.

  • Treinamento contínuo de equipe.

  • Mecanismos de recuperação fora do local.

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, maior a probabilidade de uma solução de disponibilidade ser mais complexa e cara. Quando você investe em disponibilidade, os custos incluem:

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

  • Complexidade operacional complexa.

Os custos de obtenção de disponibilidade devem ser avaliados com base nas necessidades do negócio — nem todas as soluções em uma organização exigem 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.

ObservaçãoObservação:

Ao calcular a disponibilidade, a maioria das organizações especificamente isenta 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 na seção Disponibilidade da Pesquisa após failover para reduzir o tempo necessário para recuperar a pesquisa.

  • O aplicativo Produtos e Tecnologias do SharePoint não detecta o espelhamento do SQL Server. Embora seja recomendável considerar o uso de espelhamento do SQL Server como uma técnica de disponibilidade, a realização desse procedimento exige automação adicional.

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 de suas funções?

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

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

Escolher uma estratégia de disponibilidade

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

  • Tolerância a falha de componentes.

  • Redundância e failover entre funções de servidor 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 somente 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 e atualizações do SQL Server

  • 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:

Tolerância de falha 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 (Windows SharePoint Services).

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 oferecem suporte à execução de funções de servidor em computadores redundantes 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 atender aos requisitos básicos, talvez você queira adicionar mais servidores para aumentar a disponibilidade geral do serviço.

Disponibilidade em um farm de servidor único

Disponibilidade de farm único

A tabela a seguir descreve os servidores e as funções 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 servidor em um farm.

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

SQL Server

Clustering ou espelhamento síncrono. O clustering é mais fácil de implementar, mas pode ser mais caro.

Para obter mais informações sobre como usar o espelhamento síncrono, consulte o Usando espelhamento de banco de dados (Office SharePoint Server) (white paper) .

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 da Pesquisa após failover.

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).

Comparação das estratégias de disponibilidade de banco de dados para um único farm: clustering de failover do SQL Server vs. espelhamento de alta disponibilidade do SQL Server

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

Clustering 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, em uma perspectiva de produtos e tecnologias do SharePoint, é contínuo e automático.

Exige 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.

Exige 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, em caso de perda do cluster, seja o último backup completo.

Exige 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.

Redundância e failover entre centros de dados próximos e 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 possam ser configurados como um único farm. Isso 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, é possível 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 para o qual haja 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 que executem SSPs, estabelecendo:

  • Vários servidores de consulta

  • Vários servidores executando o 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 e restaurá-la ou, se a atualidade da pesquisa na recuperação for essencial, usar um farm de SSPs de failover. Para obter mais informações, consulte Disponibilidade da Pesquisa após failover.

Farm “estendido”

Farm "estendido"

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.

    ObservaçãoObservação:

    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 backup dos bancos de dados de SSP e restaurá-los no farm de failover.

Consulte o fornecedor de SAN para determinar se você pode usar a replicação de SAN em outro mecanismo para o qual haja 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.

ObservaçãoObservação:

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

Fams principal e de failover antes do failover

Farms primário e de failover antes do failover

A tabela a seguir descreve os servidores 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 um 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 de SSP que hospedem informações de pesquisa.

Servidores Web 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.

Índice 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.

Replicação e pesquisa assíncrona

A pesquisa exige sincronização completa entre o banco de dados de Pesquisa, o banco de dados do 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). Para fornecer pesquisa em um farm de failover, você deve recuperar o SSP de Pesquisa.

ObservaçãoObservação:

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

Disponibilidade da pesquisa após o failover

A função de servidor de indexação não pode ser redundante em um farm. As necessidades da empresa referentes ao grau de atualidade da pesquisa após o failover poderão 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 itens:

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

  • 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.

ImportanteImportante:

Se a empresa exigir simultaneidade de pesquisa e disponibilidade rápidas, e você estiver usando perfis, os perfis nos SSPs de failover não serão sincronizados com os perfis nos SSPs principais — eles ficarão no estado em que se encontravam quando foram importados inicialmente. Para manter esse perfis em todos os SSPs sincronizados, você deve usar o Mecanismo de Replicação de Perfil de Usuário, incluído no SharePoint Administration Toolkit de 32 bits (em inglês) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0x416) (em inglês) ou no SharePoint Administration Toolkit de 64 bits (em inglês) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0x416) (em inglês). Para obter mais informações, consulte User Profile Replication Engine (Office SharePoint Server).

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 pai de SSP 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 agrupado 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 exige um novo rastreamento.

Farms de SSP centralizados

Farms de failover de SSP

Esta topologia tem as seguintes limitações:

Resumo

Examine cuidadosamente os requisitos disponibilidade. Quanto maior o nível de disponibilidade e quanto maior o número de sistemas protegidos, maior a probabilidade de uma solução de disponibilidade ser mais complexa e cara.

Os custos de obtenção de disponibilidade devem ser avaliados com base nas necessidades do negócio. Nem todas as soluções em uma organização exigem 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.

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, Hosted SharePoint, Arquiteto de tecnologia

  • James Petrosky, Microsoft Consulting Services, Consultor sênior

  • Steve Peschka, Microsoft Consulting Services, Arquiteto de IW sênior

  • Dan Winter, Microsoft Customer Support Services, Engenheiro de escalação

  • Sean Livingston, Microsoft SharePoint Products and Technologies, Gerente de programação

  • Mike Watson, Arquiteto de tecnologia

  • Todd Carter, Microsoft Premier Field Engineering, Engenheiro-chefe de campo

  • Mike Plumley, Microsoft Office Project Server, Autor

  • Christophe Fiessinger, Microsoft Office Project, Gerente de produtos técnicos sênior

  • Sid Shah, Microsoft Search, Gerente de programação

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