Plano de redundância (Search Server 2008)

Atualizado em: 2008-07-31

Neste artigo:

• Sobre a redundância

• Definir requisitos de redundância de servidor

• Planejar um nível mínimo de redundância de servidor

• Escolher uma topologia de farm de servidores de linha de base

• Planejar redundância de servidor de consulta

• Planejar redundância de servidor de banco de dados

• Avaliar os riscos de falhas de servidor

Este artigo descreve as opções para ajuste de funções de servidor redundantes em um farm do Servidor de Pesquisa da Microsoft 2008. Depois de ler este artigo, você será capaz de determinar e registrar as opções de redundância apropriadas para o ambiente.

Antes de ler este tópico, leia os seguintes tópicos:

• Planejar a implantação do Search Server 2008 ou do Search Server 2008 Express

• Determinar requisitos de hardware e software (Search Server 2008)

• Planejar disponibilidade (Search Server 2008)

Observe que Search Server 2008 e Servidor de Pesquisa 2008 Express normalmente não hospedam conteúdo. Em vez disso, eles são usados principalmente para hospedar serviços de Pesquisa, rastrear conteúdo nos farms do Windows SharePoint Services e do Microsoft Office SharePoint Server ou em outras fontes remotas de conteúdo e responder a consultas. Em alguns ambientes, Search Server 2008 e Servidor de Pesquisa 2008 Express podem ser usados para hospedar conteúdo. Se você planeja usar Search Server 2008 ou Servidor de Pesquisa 2008 Express para hospedar conteúdo, leia os artigos em Planejar o desempenho e a capacidade (Windows SharePoint Services) para assegurar que você está ciente de todos os requisitos da hospedagem de conteúdo e da execução de Search Server 2008 ou Servidor de Pesquisa 2008 Express no mesmo farm.

Sobre a redundância

O termo redundância é quase sempre mal interpretado como sinônimo de disponibilidade. Embora esses conceitos estejam relacionados, não são a mesma coisa. A redundância refere-se ao uso de vários servidores em um ambiente com balanceamento de carga para qualquer finalidade, como melhorar o desempenho do farm, dimensionar para acomodar usuários adicionais e aumentar a disponibilidade.

A disponibilidade é um conceito mais especializado que se refere a um ambiente de vários servidores projetado para aceitar conexões e operar normalmente mesmo que um ou mais servidores no farm não estejam operacionais. Portanto, a disponibilidade implica em redundância e, além disso, implica em um mecanismo de failover e em várias outras possíveis características. No entanto, um sistema redundante pode não ser altamente disponível.

Para obter mais informações sobre disponibilidade, consulte Planejar disponibilidade (Search Server 2008).

Este artigo descreve como implementar servidores redundantes em um farm do Search Server 2008.

Definir requisitos de redundância de servidor

O Search Server 2008 oferece suporte a farms de servidores escalonáveis para capacidade, desempenho e disponibilidade. Geralmente, a capacidade é a primeira consideração na determinação do número de computadores servidores. Após a fatoração no desempenho, a disponibilidade também tem uma função na determinação do número de servidores e no tamanho ou na capacidade dos computadores servidores em um farm de servidores.

No final desta seção, você será capaz de determinar se precisa criar capacidade expansível na topologia de implantação do servidor ao implantar servidores redundantes ou se faz sentido para a organização planejar uma implantação de servidor limitada sem servidores redundantes.

Planejar um nível mínimo de redundância de servidor

Para implantar uma solução redundante, você deve implantar um farm de servidores.

Existem diversas topologias de servidor diferentes, que podem ser usadas como uma linha de base. Cada uma dessas topologias cria um nível de redundância de servidor. Esta seção oferece um resumo desses farms de servidores.

Observação:
Nas descrições a seguir, nos referimos aos servidores nos quais a função de indexação foi instalada como servidores de indexação e aos servidores nos quais a função de consulta foi instalada como servidores de consulta.

Topologias redundantes

Esta seção contém exemplos de topologias redundantes.

Cinco ou mais farms de servidores

A topologia de farm de servidores redundante ideal apresenta um servidor de indexação separado e consiste em cinco ou mais computadores servidores, incluindo pelo menos dois computadores de servidor de banco de dados em uma configuração com cluster e em pelo menos dois computadores de servidor de consulta.

Com essa topologia você pode instalar a função de servidor de indexação no servidor de aplicativos dedicado. Esse design otimiza o desempenho dos computadores de servidor de consulta ao permitir que você descarregue a indexação para a camada intermediária.

Observe que essa topologia mostra uma configuração com cluster do SQL Server que oferece failover manual. Para obter mais informações sobre como configurar um cluster do SQL Server para failover automático, consulte White Paper Cluster de Failover do SQL Server 2005 ou Instalação de um Cluster de Failover do SQL Server 2008 (em inglês), dependendo da versão do SQL Server que você está usando.

Farm de quatro servidores

O menor farm de servidores que cria redundância consiste em quatro servidores:

• Servidores 1 e 2: função de consulta instalada em ambos os computadores.

• Servidores 3 e 4: servidor de banco de dados com cluster ou espelhado.

Para o uso de um farm de quatro servidores, escolha cuidadosamente onde implantar a função de servidor de indexação. A função de consulta não pode ser implantada no servidor de indexação e em outro servidor no farm para a obtenção de redundância. Isso ocorre porque, quando a função de indexação é instalada no mesmo computador servidor que a função de consulta, a função de indexação deixa de propagar índices de conteúdo para outros servidores de consulta. Consequentemente, se a função de servidor de indexação for instalada em um dos servidores Web, você não poderá mais hospedar a função de consulta em ambos os servidores Web. É possível instalar a função de indexação no servidor de banco de dados, obtendo assim redundância da função de consulta nos servidores Web. No entanto, o desempenho do servidor de banco de dados será afetado, particularmente quando o conteúdo estiver sendo rastreado.

Farm de três servidores

Há uma alternativa para obter redundância ao implantar menos servidores. Com um farm de três servidores, você deve decidir qual das funções de servidor deve se tornar redundante: a função de servidor Web ou a de servidor de banco de dados.

Adicionando um terceiro servidor à camada de servidor Web, você obtém redundância da função de servidor Web. As funções de consulta e indexação podem ser instaladas no mesmo servidor Web (consulte a opção A nesta seção) ou em servidores Web diferentes (consulte a Opção B abaixo).

Nessa topologia, a função de consulta não pode ser implantada em ambos os servidores Web para a obtenção de redundância. Isso ocorre porque, se a função de servidor de consulta estiver instalada no mesmo servidor que o servidor de indexação, este não propagará o índice para outros servidores de consulta. No entanto, é possível instalar a função de indexação no servidor de banco de dados. Isso permite que você implante a função de consulta em ambos os servidores Web. Entretanto, o desempenho do servidor de banco de dados será afetado.

Embora a disponibilidade seja limitada, dedicar dois servidores à função de servidor Web aprimora o desempenho geral de um farm pequeno. Use essa topologia quando o desempenho for mais importante do que a redundância de dados.

Topologias não redundantes

As topologias não redundantes podem conter mais de um servidor, mas não são redundantes porque há apenas um servidor em cada função de servidor. Por exemplo, um farm que contém um servidor de consulta, um servidor de indexação e um servidor de banco de dados não é redundante.

Se não precisar criar capacidade e desempenho adicionais na implantação do servidor, o ponto inicial da topologia do servidor é um ou dois servidores. Para fins de uso limitado, você pode implantar um único servidor Search Server 2008 ou implantar Servidor de Pesquisa da Microsoft 2008 Express, que é limitado por design a um único servidor de aplicativos.

Os diagramas a seguir mostram exemplos de topologias não redundantes.

Escolher uma topologia de farm de servidores de linha de base

Cada uma das topologias de farm de servidores descrita anteriormente neste artigo representa um ponto de partida de linha de base para a elaboração da implantação. O ponto de partida mais adequado à organização depende das funções do servidor para as quais a redundância é necessária.

O restante deste artigo descreve as opções de redundância para cada uma das funções de servidor. Quando tiver terminado o artigo, você será capaz de determinar a topologia de linha de base que poderá oferecer a redundância necessária à organização. Essa será a topologia usada como linha de base quando você planejar capacidade e desempenho.

Planejar redundância de servidor de consulta

Use esta seção para:

• Determinar se a organização requer redundância integrada à camada da Web.

• Planejar que tecnologia de balanceamento de carga de servidor de consulta deverá ser implementada.

A função de servidor de consulta pode ser implantada em vários servidores. O código implantado em cada servidor é idêntico e os servidores de consulta não armazenam dados. Em outras palavras, cada instância das funções de servidor permanece idêntica. Se um dos computadores servidores falhar, nenhum dado salvo será perdido. Os servidores Web executam automaticamente o balanceamento da carga das solicitações para essas funções de servidor entre os computadores servidores disponíveis.

A função de consulta pode ser implantada em qualquer número de servidores Web. No entanto, há uma limitação. Se o servidor de consulta for implantado para o mesmo servidor que hospeda a função de indexação, a função de consulta não deverá ser implantada em nenhum outro computador servidor. Isso se deve ao fato de que a função de indexação reconhece que a função de consulta está localizada no mesmo servidor. Portanto, ela não tenta propagar o índice.

A função de servidor de aplicativos de indexação não pode ser redundante no Search Server 2008. No Search Server 2008, a função de indexação está associada a um Provedor de Serviços Compartilhados (SSP). A função de indexação cria um índice por SSP. Você não pode implantar vários servidores de indexação para melhorar a capacidade. O servidor de indexação é associado a um único SSP e, no Search Server 2008, é possível possuir apenas um SSP.

A próxima etapa é planejar que tecnologia de balanceamento de carga será implementada. O Search Server 2008 oferece suporte a dois métodos de balanceamento de carga:

• Software, como os serviços de Balanceamento de Carga de Rede (NLB) no sistema operacional Windows Server 2003. O NLB é executado nos servidores de consulta e usa TCP/IP para rotear solicitações. Como o NLB e outras soluções de software de balanceamento de carga são executadas em servidores de consulta, eles usam os recursos do sistema de servidor de consulta. Isso reduz os recursos que podem ser usados para atender consultas. No entanto, o efeito nos recursos do sistema não é bom e uma solução de software pode lidar com até 32 servidores de consulta.

• Hardware, como um roteador ou switch box. O hardware de balanceamento de carga usa a rede para direcionar o tráfego de consultas entre os servidores de consulta. O hardware de balanceamento de carga é mais caro de configurar do que o software.No entanto, ele não afeta o uso de recursos em servidores de consulta. O Search Server 2008 pode ser usado com qualquer hardware de balanceamento de carga.

Embora não recomendado, existe um terceiro método de balanceamento de carga, o balanceamento de carga round-robin com DNS. Ele pode usar recursos significativos nos servidores de consulta, é mais lento do que o software ou o hardware de balanceamento de carga. Não recomendamos que utilizá-lo com o Search Server 2008. Além disso, o balanceamento de carga round-robin DNS não leva a carga da sessão em consideração ao rotear um usuário para um servidor, o que pode levar à sobrecarga do servidor.

O artigo Como Configurar Parâmetros de Balanceamento de Carga de Rede no Windows Server 2003 (https://go.microsoft.com/fwlink/?linkid=124067&clcid=0x416) oferece instruções para a configuração do NLB. Se você decidir implementar uma tecnologia diferente para o balanceamento de carga, leve isso em consideração no processo de planejamento e de implantação.

Planejar redundância de servidor de banco de dados

Use esta seção para ajudá-lo a determinar se a redundância da função de servidor de banco de dados é necessária para a solução. Os próximos tópicos de planejamento o ajudarão a decidir qual tecnologia de redundância de banco de dados é a mais apropriada para o ambiente. Para obter mais informações, consulte Planejar e projetar o armazenamento e o gerenciamento do banco de dados.

A função de servidor de banco de dados afeta a disponibilidade da sua solução mais do que qualquer outra função. Se um servidor de consulta ou um servidor de indexação falhar, essas funções poderão ser rapidamente restauradas ou reimplantadas. No entanto, se um servidor de banco de dados falhar, a sua solução dependerá da restauração do servidor de banco de dados. Potencialmente, isso pode incluir a recriação do servidor de banco de dados e a restauração de dados da mídia de backup. Nesse caso, você poderá perder qualquer dado novo ou alterado após o último trabalho de backup, dependendo de como o SQL Server 2005 foi configurado. Adicionalmente, a solução estará totalmente indisponível pelo tempo que levar a restauração da função de servidor de banco de dados.

Avaliar os riscos de falhas de servidor

Esta seção oferece um resumo das consequências esperadas de uma falha de um único servidor de consulta ou servidor de indexação. Em outras palavras, se você implantar a função de servidor de consulta em apenas um servidor e esse servidor falhar, quais serão as potenciais consequências? A compreensão das consequências possíveis o ajudará a priorizar a alocação dos servidores do farm. A tabela a seguir relaciona as funções de servidor de aplicativos e descreve as consequências do tempo de inatividade de cada uma delas.

Função de servidor	Consequências do tempo de inatividade
Consulta	Os usuários não poderão emitir consultas de texto completo. Os usuários ainda podem navegar em sites e acessar conteúdo exposto por meio de sites. Se o aplicativo depender da capacidade dos usuários ou clientes de localizar conteúdo por meio de pesquisa, planeje a implantação da função de servidor de consulta em vários servidores. Em um farm de cinco servidores, isso pode ser feito facilmente com a implantação da função de consulta nos dois computadores servidores Web.
Índice	Os servidores de consulta continuam a usar os índices de conteúdo existentes até que o serviço de indexação seja restaurado e índices novos ou atualizados sejam gerados. Consequentemente, os resultados da pesquisa não incluem conteúdo novo ou alterado enquanto a função de indexação não está disponível.
Banco de dados	O farm não estará acessível para os usuários. As tentativas de visualizar páginas no farm gerarão mensagens de erro. Se o aplicativo depende da capacidade de usuários ou clientes de localizar conteúdo por meio de pesquisa, planeje a implantação de uma configuração de servidor de banco de dados de cluster.

A recomendação geral de redundância é planejar a instalação de um servidor de consulta para pelo menos dois computadores servidores se o requisito de disponibilidade da função de servidor de consulta for 99% ou superior.

Se a sua organização puder tolerar a perda temporária dessa funcionalidade pelo tempo necessário para que a equipe de TI implante uma função de servidor de aplicativos em um servidor diferente ou restaure o serviço no servidor existente, você pode considerar a implantação da função em um único servidor de aplicativos.

Consulte também

Planejar disponibilidade (Search Server 2008)

Outros recursos

Planejar e projetar o armazenamento e o gerenciamento do banco de dados
Como Configurar Parâmetros de Balanceamento de Carga de Rede no Windows Server 2003
White Paper Cluster de Failover do SQL Server 2005
Instalação de um Cluster de Failover do SQL Server 2008