Alta disponibilidade e recuperação de desastre

Importante

Esta versão do Operations Manager chegou ao fim do suporte. Recomendamos que você atualize para o Operations Manager 2022.

System Center – Os recursos e servidores do Operations Manager podem potencialmente falhar, afetando a funcionalidade do Operations Manager. A quantidade de dados e a funcionalidade perdidas durante uma falha são diferentes em cada cenário de falha. Depende da função do recurso com falha e do tempo necessário para recuperar o recurso com falha.

Alta disponibilidade

Demandas de alta disponibilidade são atendidas incorporando redundância ao grupo de gerenciamento dos bancos de dados operacional e de data warehouse do Operations Manager, nos servidores de gerenciamento e gateway e em cargas de trabalho específicas. Essas cargas de trabalho incluem monitoramento de dispositivos de rede, monitoramento de multiplataforma e cargas de trabalho específicas do grupo de gerenciamento que anteriormente eram gerenciadas pelo Servidor de Gerenciamento Raiz.

A configuração com vários servidores e um único grupo de gerenciamento pode usar o Always On do SQL Server para fornecer alta disponibilidade e continuidade do serviço dos bancos de dados do Operations Manager. A tolerância a falhas do servidor de gerenciamento é fornecida com pelo menos dois servidores de gerenciamento e usando pools de recursos para monitorar servidores UNIX, servidores Linux e dispositivos de rede. Servidores do Windows baseados em agente podem ser configurados com um servidor de gerenciamento primário e secundário para redirecionar as comunicações do agente em caso de falha de um servidor de gerenciamento.

O Emulador RMS também pode ser movido para outro servidor de gerenciamento caso o servidor de gerenciamento que hospeda o Emulador RMS fique indisponível.

As conexões do Console de Operações podem se tornar altamente disponíveis por meio da configuração da alta disponibilidade dos Serviços de Acesso a Dados. Isso pode ser feito instalando o NLB (Balanceamento de Carga de Rede) da Microsoft ou usando um balanceador de carga baseado em hardware ou alias DNS. Um ou mais servidores de gerenciamento são adicionados como membros do pool do NLB e, ao abrir o console, você referenciará o nome virtual registrado no DNS dos servidores de gerenciamento com balanceamento de carga.

Observação

Não há suporte para um Load Balancer de rede para o servidor de console Web do Operations Manager.

É possível implantar vários servidores de gateway em um limite de relação de confiança para fornecer caminhos para agentes que residam dentro do limite da relação de confiança. Assim como pode ocorrer o failover de agentes entre um servidor de gerenciamento primário e um ou mais servidores de gerenciamento secundários, o failover deles também pode ocorrer entre servidores de gateway. Além disso, vários servidores de gateway podem ser usados para distribuir a carga de trabalho de gerenciar computadores gerenciados sem agentes e dispositivos de rede gerenciados.

Além de fornecer redundância por meio do failover de gateway de agente, os servidores de gateway podem ser configurados para failover entre servidores de gerenciamento em um grupo de gerenciamento se houver vários servidores de gerenciamento disponíveis.

Embora SQL Server Reporting Services dê suporte a um modelo de implantação de expansão que permite executar várias instâncias de servidor de relatório que compartilham um banco de dados de servidor de relatório único, ele não tem suporte com o Operations Manager. O Operations Manager Reporting instala uma extensão de segurança personalizada como parte da configuração dos componentes front-end, que não podem ser replicados no farm da Web.

Recuperação de desastre

A recuperação de desastres está relacionada a medidas que são adotadas para garantir que as operações sejam retomadas no caso de uma falha catastrófica (por exemplo, a perda de todo o data center que hospeda a infraestrutura principal). É um elemento importante que deve ser considerado em qualquer implantação e as decisões tomadas no planejamento da recuperação de desastre afetam como o Operations Manager poderá continuar dando suporte ao monitoramento proativo e ao relatório do desempenho e da disponibilidade de seus serviços críticos de TI. Esta seção se concentrará na estratégia recomendada para recuperação de desastre e resiliência e em quais etapas devem ser adotadas para garantir que a recuperação seja simples.

Embora as soluções de HA e DR forneçam proteção contra falha do sistema ou perda do sistema, elas não devem ser confiadas para proteção contra perda ou corrupção de dados acidentais, não intencionais ou mal-intencionadas. Nesses casos, cópias de replicação copiadas ou defasadas podem ter que ser usadas para operações de restauração. Em muitos casos, uma operação de restauração é a forma de recuperação de desastre mais apropriada. Um exemplo disso pode ser um banco de dados de relatórios de baixa prioridade ou dados de análise. Em muitos casos, o custo para habilitar a recuperação de desastres multissite no nível do sistema ou do aplicativo supera muito o valor dos dados. Nos casos em que o valor de curto prazo dos dados é baixo e a necessidade de acessar os dados pode ser adiada sem impactos graves sobre os negócios quando há excesso de falhas ou de recuperação de desastre no site, considere o uso de processos simples de backup e restauração para recuperação de desastre se as economias de custos compensarem.

Compreender o impacto do tempo de inatividade e a tolerância a ele ajudará a tomar as decisões que precisam ser entendidas para criar corretamente a arquitetura do Operations Manager e o nível de complexidade e custo necessários para dar suporte à recuperação de desastres. Além disso, é necessário considerar a extensão da perda de dados de monitoramento que a organização de TI pode tolerar sem causar consequências de negócios. Isso é melhor descrito em dois termos: RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação).

As duas configurações de design mais comuns de recuperação de desastre para o Operations Manager são:

• Criando um grupo de gerenciamento duplicado implantado em seu data center secundário que duplica em escala e configura o grupo de gerenciamento primário.
• implantar servidores adicionais em um data center secundário para dar suporte ao banco de dados Operacional e de Data Warehouse, com servidores de gerenciamento implantados em uma configuração de espera passiva, que não participam do grupo de gerenciamento até que as ações de recuperação precisem ser executadas.

Implantar um grupo de gerenciamento duplicado é uma opção quando não há tolerância para tempo de inatividade; no entanto, é a opção mais complexa. A configuração entre ambos precisa ser consistente para que, quando você corta, não haja diferença no que é monitorado, alertado ou relatado, apresentado e, finalmente, escalonado. A integração com outras plataformas de monitoramento ou plataformas ITSM como o System Center – Service Manager, Remedy ou ServiceNow também precisará existir e possivelmente configurada em um estado ativo/passivo para evitar a duplicação de incidentes, itens de configuração e assim por diante. Os agentes terão hospedagem múltipla entre os dois grupos de gerenciamento, de modo que haverá duplicação de dados.

O diagrama a seguir é um exemplo desse cenário de design.

Se a recuperação imediata não for necessária para sua implantação do Operations Manager e você quiser evitar a complexidade de um grupo de gerenciamento duplicado, você poderá implantar componentes adicionais do grupo de gerenciamento em seu data center secundário para manter a funcionalidade do grupo de gerenciamento. No mínimo, considere implementar um grupo de disponibilidade do AlwaysOn do SQL Server 2014 ou 2016 para fornecer a recuperação dos bancos de dados Operacional e de Data Warehouse entre dois ou mais datacenters, em que uma FCI (instância de cluster de failover) de dois nós está implantada no datacenter principal e um SQL Server autônomo no datacenter secundário como parte de um único WSFC (Windows Server Failover Cluster). A réplica secundária do grupo de disponibilidade do AlwaysOn estaria na instância autônoma não FCI, conforme mostrado no diagrama a seguir.

Neste exemplo, você deverá implantar um ou mais Windows Servers com o mesmo nome do computador e a mesma configuração de hardware e reinstalará a função de servidor de gerenciamento usando o parâmetro /Recover. Veja um exemplo:

Setup.exe /silent /AcceptEndUserLicenseAgreement:1 /recover /InstallPath:<Install Directory> /ManagementGroupName:MGNAME /SqlServerInstance:SQLServerName.domain.com /DatabaseName:OperationsManager /DWSqlServerInstance:SQLServerName.domain.com /DWDatabaseName:OperationsManagerDW /ActionAccountUser:DOMAIN\omaa /ActionAccountPassword:password /DASAccountUser:DOMAIN\omdas /DASAccountPassword:password /DatareaderUser:DOMAIN\omdr /DatareaderPassword:password /DataWriterUser:DOMAIN\omdw /DataWriterPassword:password /EnableErrorReporting:Always /SendCEIPReports:1 /UseMicrosoftUpdate:0

Para saber mais, confira instalação do Operations Manager do prompt de comando.

Durante esse tempo, os agentes enfileirarão os dados coletados (alertas, eventos, desempenho e assim por diante) até que possam retomar a comunicação com um servidor de gerenciamento no grupo de gerenciamento. Essa abordagem evita instalar novas instâncias do SQL Server e restaurar bancos de dados de seu último backup válido conhecido. No entanto, nesse cenário de recuperação, provavelmente haverá um atraso maior no retorno a um estado operável, dado que você precisará implantar as outras funções necessárias para retomar a funcionalidade mínima de monitoramento. Se essa abordagem não for aceitável, você poderá implantar servidores de gerenciamento em seu data center secundário para recuperação no modo de espera. Remova-os como membros dos três pools de recursos principais – Pool de Recursos de Todos os Servidores de Gerenciamento, Notificações e Atribuição de AD. Isso também inclui qualquer pool de recursos personalizado que possa incluir servidores de gerenciamento hospedados no data center primário e precise continuar funcionando como parte do plano de recuperação. Os serviços de Acesso a Dados do System Center, Gerenciamento de Configuração do System Center e o Microsoft Monitoring Agent devem ser interrompidos, definidos como manual ou desabilitado e devem ser iniciados somente em um cenário de recuperação de desastre.

Se um servidor de gerenciamento estiver dando suporte à integração (por meio de um conector hospedado diretamente no servidor de gerenciamento ou de outro produto do System Center, como VMM, Orchestrator ou Service Manager), isso precisará ser planejado com etapas de recuperação manuais ou automáticas, dependendo da configuração de integração e da sequência de etapas de recuperação. Isso garante que qualquer outra dependência do servidor de gerenciamento seja capturada e planejada quando o plano de recuperação de desastre precisar ser implementado.

Se um site ficar offline, o agente efetuará o failover para o servidor de gerenciamento em outro site, presumindo que a configuração de failover do agente permita isso. Configure novamente os agentes do Windows para armazenar em cache somente os servidores de gerenciamento no seu data center principal, que deve gerenciá-los para impedir que tentem efetuar o failover para um servidor de gerenciamento no data center secundário, o que apenas atrasaria a recuperação e a emissão de relatórios. Isso pode ser feito se você implantar manualmente o agente de maneira automatizada com um script (por exemplo, VBScript ou melhor ainda, PowerShell) para pré-configurar durante a instalação ou pós-implantação se você enviar o agente por push do console, novamente usando um método script gerenciado com sua solução de gerenciamento de configuração corporativa.

O Operations Manager pode ser implantado em máquinas virtuais do Azure como uma opção alternativa de recuperação de desastre para manter a continuidade do grupo de gerenciamento. Também será necessário implantar SQL Server em uma máquina virtual no Azure e não em uma configuração híbrida, pois a latência entre um servidor de gerenciamento e o SQL Server que hospeda os bancos de dados do Operations Manager afetará negativamente o desempenho do grupo de gerenciamento.

Considere o escopo de monitoramento, a topologia de rede e a conectividade de rede com o Microsoft Azure (ou seja, VPN site a site ou ExpressRoute), pontos de integração (ou seja, soluções de ITSM, outros produtos do System Center, complementos de terceira parte e assim por diante), acesso ao console, leis ou políticas regulatórias ou relevantes e assim por diante para arquitetar corretamente esse cenário no IaaS do Azure ou em outros provedores de nuvem pública.