Planejando a tolerância a falhas e a disponibilidade no Project Server 2007

Artigo
03/02/2015

Atualizado: outubro de 2008

Tópico modificado em: 2015-02-27

"Tolerância a falhas" e "disponibilidade" referem-se à capacidade de um ambiente de vários servidores em aceitar conexões e funcionar normalmente, mesmo quando um ou mais dos componentes do farm não estão operacionais. Disponibilidade implica redundância e, além disso, pode incluir um mecanismo de failover e várias outras características possíveis.

Você pode usar as seguintes estratégias para melhorar a tolerância a falhas da implantação do Microsoft Office Project Server 2007:

Clustering
Redundância de hardware
Configurações de RAID
Redundância de função de servidor
Envio de logs
Servidores em espera

Este artigo fornece mais informações sobre cada uma dessas estratégias. Você pode aplicá-las individualmente ou combinadas. Como cada estratégia tem um custo associado, é importante examinar a taxa de custo/benefício de cada uma antes de aplicá-la em sua organização.

Disponibilidade.

É recomendável considerar os requisitos de disponibilidade como parte do design principal da solução do Office Project Server 2007. 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.

O que é disponibilidade?

Disponibilidade é o grau no qual um sistema, como o Office Project Server 2007, é percebido pelos usuários como disponível. Garantir a disponibilidade significa garantir que um sistema seja resistente — ou seja, que incidentes que afetam o serviço ocorram raramente e que uma ação pontual e eficiente seja executada quando eles acontecerem. Estratégias de disponibilidade minimizam a percepção do usuário de inatividade planejada e não planejada.

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 minutos	36 horas	18 dias
99	14 minutos	7 horas	4 dias
99,9	86 segundos	43 minutos	9 horas
99,99	8,6 segundos	4 minutos	53 minutos
99,999	0,8 segundos	26 segundos	5 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 – total de horas de inatividade por ano) / 8760

-
% Tempo de atividade/mês = 100 – ((24 * número de dias no mês) – total de horas de inatividade no mês) /(24 * número de dias no mês)

-
% Tempo de atividade/semana = 100 – (168 – total de horas de inatividade naquela semana) / 168

O que a disponibilidade não é

Disponibilidade não é proteção e recuperação de dados, nem é a recuperação de desastres. Você deve ter uma proteção de dados separada e planos de recuperação de desastres em qualquer sistema altamente disponível.

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.

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

Sobre a redundância

Redundância é uma parte importante da disponibilidade. A redundância inclui o uso de vários servidores em um ambiente com balanceamento de carga para melhorar o desempenho do farm ou dimensionar para acomodar usuários adicionais. A redundância também inclui o uso de componentes de backup idênticos, como fontes de alimentação ou equipamento de rede, para fornecer funcionalidade contínua no caso da falha do componente principal.

Este artigo descreve como implementar servidores redundantes em um farm do Office Project Server 2007.

O Office Project Server 2007 tem suporte para 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 de 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.

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 Office Project Server 2007 ficar indisponível, os funcionários da organização poderão realizar seus trabalhos?
Se o Office Project Server 2007 ficar indisponível, as transações comerciais e com clientes serão interrompidas, levando à perda de negócios e clientes?

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

Embora este artigo analise principalmente a disponibilidade doOffice Project Server 2007, o tempo de atividade do sistema também será afetado pelos outros componentes no sistema. Particularmente, considere o seguinte:

Você deve assegurar que as dependências de infraestrutura, como energia, resfriamento, rede, diretório e SMTP sejam totalmente redundantes.

Escolha um mecanismo de comutação para o sistema, seja DNS ou balanceamento de carga de hardware, que atenda às suas necessidades. As práticas recomendadas para balanceamento de carga de servidores Web podem ser encontradas nos seguintes artigos:

Clustering

O cluster pode proteger seu sistema contra uma falha de aplicativo ou sistema operacional. Você também pode executar várias tarefas em computadores de cluster sem realizá-las offline, incluindo a atualização de um aplicativo ou sistema operacional ou a instalação de um service pack ou atualização.

Os clusters de servidor são criados para manter os aplicativos disponíveis, em vez de proteger os dados. Para proteger contra vírus, corrupção e outras ameaças a dados, você precisa de uma proteção de dados sólida e planos de recuperação. A tecnologia de cluster não protege contra falhas causadas por vírus, corrupção de software ou erro humano.

Clustering de failover do SQL Server

Os clusters de failover são criados para aplicativos com monitoração de estado. Aplicativos com monitoração de estado têm estado na memória de execução demorada ou estados de dados grandes e atualizados com frequência.

Os clusters de failover fornecem alta disponibilidade ao permitir o failover dos recursos. Os clusters de failover também mantêm conexões de cliente com aplicativos e serviços.

Em clusters de failover, os nós compartilham o acesso a dados. Os nós podem ser ativos ou passivos e a configuração de cada nó depende do modo operacional (ativo ou passivo) e de como você configura o failover do cluster. Um servidor designado para manipular o failover deve ser ajustado para manipular a carga de trabalho do nó que apresenta falha e de sua própria carga de trabalho.

Em implantações do Office Project Server 2007, você pode usar failover de cluster com o SQL Server.

Clusters de balanceamento de carga

Os clusters de balanceamento de carga são grupos de computadores idênticos, normalmente clonados que são usados para aumentar a disponibilidade de servidores da Web, servidores Microsoft Internet Security and Acceleration (ISA) (para servidores proxy e firewall) e outros aplicativos que recebem o tráfego TCP e UDP. Como os nós de cluster são geralmente clones idênticos uns dos outros e, portanto, podem operar independentemente, todos os nós de um cluster ficam ativos.

O Office Project Server 2007 aceita dois métodos de balanceamento de carga:

Software, como os serviços de Balanceamento de Carga de Rede (NLB) no sistema operacional Microsoft Windows Server 2003. O NLB é executado nos servidores Web front-end e usa TCP/IP para rotear solicitações. Como o NLB (e outras soluções de balanceamento de carga de software) é executado nos servidores Web front-end, ele utiliza os recursos do sistema Web front-end e, consequentemente, reduz os recursos que podem ser usados para atender às páginas da Web. No entanto, o impacto em recursos do sistema não é grande, e uma solução de software pode lidar com até 32 servidores Web front-end.
Hardware, como um roteador ou switch box. O hardware de balanceamento de carga usa a rede para direcionar o tráfego do site entre os servidores Web front-end. O hardware de balanceamento de carga é mais caro de configurar do que o software, mas não afeta os recursos do servidor Web front-end. O Office Project Server 2007 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 Web front-end, é mais lento do que o software ou o hardware de balanceamento de carga e não é recomendado para o Office Project Server 2007. Além disso, o balanceamento de carga round-robin com DNS não leva em consideração a carga de sessão ao rotear um usuário para um servidor, o que pode levar à sobrecarga de um servidor.

Redundância de hardware

Você pode fornecer algumas tolerância a falhas para a implantação do Office Project Server 2007 implantando configurações de hardware adicionais que duplicam a configuração de hardware da sua organização. Dessa forma, se um caminho de dados de entrada/saída (E/S), ou os componentes físicos de um servidor (como computador, rede e componentes de rede de área de armazenamento) falharem, o sistema não será afetado. O hardware que você usa para minimizar os pontos únicos de falha varia de acordo com os componentes que você deseja tornar redundante. Os fornecedores de hardware geralmente incluem hardware duplicado como parte de sua solução de armazenamento.

Configurações de RAID

Usando uma matriz redundante de discos independentes (RAID), você pode aumentar a tolerância de falhas da implantação do Office Project Server 2007. A RAID armazena dados idênticos em vários discos para redundância, melhor desempenho e maior tempo médio entre falhas (MTBF). Em uma configuração RAID, parte da capacidade de armazenamento físico contém informações redundantes sobre dados armazenados em discos rígidos. As informações redundantes são informações de paridade (no caso de um volume RAID-5), ou uma cópia completa e separada dos dados (no caso de um volume espelhado). As informações redundantes permitem a regeneração de dados se um dos discos ou o caminho de acesso falhar ou se um setor no disco não puder ser lido.

Para garantir que os computadores que executam o Office Project Server 2007 continuem a funcionar corretamente no caso de uma falha de disco único, você pode usar o espelhamento de disco RAID ou a distribuição de disco com paridade nos discos rígidos de de sua implantação do Office Project Server 2007. O espelhamento de disco e a distribuição de disco com paridade criam dados redundantes para os dados de seus discos rígidos.

Os bancos de dados do Office Project Server 2007 têm muita atividade de E/S. Por esse motivo, recomendamos o uso da RAID 10 para melhor desempenho e redundância de unidades que contêm os bancos de dados do Office Project Server 2007.

O uso de configurações de RAID não impede arquivos danificados ou outros erros de arquivo. Por esse motivo, não use configurações RAID como um substituto à manutenção de backups atualizados de dados importantes nos servidores.

Como os arquivos de log de transações e os arquivos de banco de dados são cruciais para a operação de computadores que executam o Office Project Server 2007, você pode manter os arquivos de log de transações e os arquivos de banco de dados em discos físicos separados. Você também pode usar o espelhamento de disco da RAID ou a distribuição de disco com paridade para evitar que a perda de um único disco rígido físico cause uma falha no banco de dados do Office Project Server 2007.

Se seu ambiente contiver uma SAN (rede de área de armazenamento), você talvez já tenha a redundância de disco necessária para a sua implantação. Em um ambiente SAN, recomendamos não colocar a implantação Office Project Server 2007 e seus componentes associados no mesmo eixo de disco de outros aplicativos com intensa atividade de E/S, pois isso pode prejudicar o desempenho. Os dados do Office Project Server 2007 são otimizados para leituras sequenciais, tornando-o ideal para um ambiente SAN.

Redundância de função de servidor

A topologia de servidor de linha de base a ser escolhida depende dos requisitos de redundância das funções de servidor de aplicativos. Esta seção descreve as funções de servidor de aplicativos em relação a suas opções de redundância.

Funções que podem ser redundantes

Essas funções de servidor de aplicativos podem ser implantadas em vários servidores. O código implantado em cada servidor é idêntico, e as funções de servidor de aplicativos 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 equilibram automaticamente a carga das solicitações para essas funções de servidor entre os computadores servidores de aplicativos disponíveis.

O Serviço de Aplicativo do Project do Office Project Server 2007 pode ser implantado de forma redundante. Isso permite maior taxa de transferência para solicitações de dados do PWA e pode aumentar a capacidade da implantação. No entanto, o Serviço de Aplicativo do Project em vários servidores de implantação não aumenta a disponibilidade de farm. Se um dos servidores falhar, o farm não detectará automaticamente a falha e continuará a enviar solicitações ao servidor do Serviço de Aplicativo do Project com falha até que ele seja removido do farm manualmente.

Funções que não podem ser redundantes

Algumas funções de servidor de aplicativo que você pode ativar no Office Project Server 2007 não podem ser redundantes, como a pesquisa do Windows SharePoint Services 3,0. Essa função de servidor de aplicativo pode ser implantada em vários servidores; no entanto, os vários servidores não são redundantes. Essa função de servidor está configurada para rastrear o conteúdo e gerar índices de conteúdo. Se você implantar essa função para vários servidores, cada servidor rastreará um conteúdo diferente.

Redundância de servidor de 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 Web ou um servidor de aplicativos 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 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.

Em qualquer sistema, é recomendável trabalhar com fornecedores de hardware para adquirir hardware tolerante a falhas apropriado para o sistema, incluindo matrizes RAID.

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.
Verifique se os servidores têm vários suprimentos de energia conectados a fontes de alimentação diferentes para redundância máxima.

Envio de logs

Com o Microsoft SQL Server, você pode usar o envio de logs para alimentar os logs de transação de um banco de dados para outro continuamente. Fazer o backup contínuo dos logs de transação de um banco de dados de origem e, em seguida, copiar e restaurar os logs para um banco de dados de destino mantém o banco de dados de destino sincronizado com o banco de dados de origem. O envio de logs fornece um método automatizado de manutenção de um servidor em espera.

Servidores em espera

Um servidor em espera é um segundo servidor que pode ser colocado on-line se um servidor de produção principal falhar. Os mesmo componentes de software instalados no servidor primário estão instalados no servidor em espera. O uso de um servidor em espera permite que os usuários continuem trabalhando com dados do Office Project Server 2007 se o servidor principal ficar indisponível.

Um servidor em espera também pode ser usado quando um servidor primário estiver indisponível devido à manutenção agendada. Por exemplo, se for necessário colocar o servidor primário off-line para uma atualização de hardware ou software, você pode usar o servidor em espera até que o servidor primário seja colocado online.

O fator mais importante a ser considerado no uso de servidores em espera é que o hardware, as atualizações de software e as atualizações de firmware de um servidor em espera devem ser idênticas às do servidor principal o qual o servidor em espera foi criado para substituir.

Se o servidor espera for um servidor de banco de dados, ele deve conter uma cópia dos bancos de dados no servidor primário. Se o servidor principal ficar off-line e o servidor em espera for colocado online, quando o servidor primário ficar disponível novamente, as alterações nas cópias do banco de dados localizadas no servidor em espera devem ser copiadas de volta para o servidor primário. Caso contrário, essas alterações serão perdidas. Quando os usuários começarem a usar o servidor primário novamente, os bancos de dados do servidor primário devem ser sofrer backup e ser copiados para o servidor em espera.

O envio de logs é usado com maior eficácia para garantir que o servidor em espera permaneça sincronizado com o servidor primário. Se o servidor principal falhar, ou mesmo se apenas um único banco de dados falhar, os bancos de dados do servidor em espera poderão ser disponibilizados para processos do usuário. Os processos de usuário que puderem acessar o servidor primário devem usar o servidor de espera em vez disso.

Se você tiver servidores Web front-end separados na implantação, pode instalar o Serviço de Aplicativo do Project nos servidores Web front-end e deixá-los desativados. Em seguida, no caso de falha em um dos servidores do Office Project Server 2007, você pode ativar o Serviço de Aplicativo do Project no Web front-end para colocar on-line facilmente um servidor em espera.

Compartilhar via