Alta disponibilidade e recuperação de desastre

Os servidores e recursos do System Center – Operations Manager podem 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

As necessidades de alta disponibilidade são atendidas criando redundância no grupo de gerenciamento para os bancos de dados operacionais e de data warehouse do Operations Manager, o gateway e os servidores de gerenciamento e cargas de trabalho específicas. Essas cargas de trabalho incluem monitoramento de dispositivo de rede, monitoramento entre plataformas e cargas de trabalho específicas do grupo de gerenciamento que eram gerenciadas anteriormente pelo Servidor de Gerenciamento Raiz.

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

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 ser altamente disponibilizadas configurando a alta disponibilidade para os 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 NLB e, ao abrir o console, você faz referência ao nome virtual registrado no DNS dos servidores de gerenciamento com balanceamento de carga.

Observação

Não há suporte para um Balanceador de Carga 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 o SQL Server Reporting Services dê suporte a um modelo de implantação de expansão que permite executar várias instâncias do servidor de relatório que compartilham um único banco de dados do servidor de relatório, ele não tem suporte com o Operations Manager. Os Relatórios do Operations Manager instalam uma extensão de segurança personalizada como parte da configuração dos componentes de front-end, que não podem ser replicados no web farm.

Recuperação de desastre

A recuperação de desastres está relacionada às medidas tomadas para garantir que as operações possam ser retomadas em caso de falha catastrófica (por exemplo, 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 desastres afetam como o Operations Manager poderá continuar dando suporte ao monitoramento proativo e à emissão de relatórios sobre o desempenho e a disponibilidade de seus serviços críticos de TI. Esta seção se concentrará na estratégia recomendada de recuperação de desastres e resiliência e quais medidas devem ser tomadas para garantir uma recuperação suave.

Embora as soluções de HA e DR forneçam proteção contra falha ou perda do sistema, elas não devem ser usadas para proteção contra perda ou corrupção de dados acidental, não intencional ou mal-intencionada. Nesses casos, o backup de cópias de replicação copiadas ou com retardamento pode ter que ser usado para operações de restauração. Em muitos casos, uma operação de restauração é a forma mais apropriada de DR. 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 DR multissite no nível do sistema ou do aplicativo supera em 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 atrasada sem impacto grave nos negócios se houver uma falha ou DR do site excessiva, considere o uso de processos simples de backup e restauração para DR se a economia de custos justificar.

Compreender o impacto e a tolerância ao tempo de inatividade ajudará a orientar as decisões que precisam ser compreendidas para projetar adequadamente 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, considere a extensão do monitoramento da perda de dados que a organização de TI pode tolerar sem causar consequências para os negócios. Isso é melhor descrito em dois termos: RTO (objetivo de tempo de recuperação) e RPO (RPO, objetivo de ponto de recuperação).

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

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

A implantação de 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ê cortar, não haja diferença no que é monitorado, alertado ou relatado, apresentado e, finalmente, escalado. A integração com outras plataformas de monitoramento ou plataformas ITSM, como 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 serão multihomed entre os dois grupos de gerenciamento, portanto, 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 a implantação do Operations Manager e você quiser evitar a complexidade de um grupo de gerenciamento duplicado, poderá implantar componentes adicionais do grupo de gerenciamento no data center secundário para manter a funcionalidade do grupo de gerenciamento. No mínimo, considere implementar um Grupo de Disponibilidade Always On do SQL Server 2014 ou 2016 para fornecer recuperação dos bancos de dados Operacional e Data Warehouse entre dois ou mais datacenters, em que uma FCI (instância de cluster de failover) de dois nós é implantada no data center primário e um SQL Server autônomo no datacenter secundário como parte de um único WSFC (Cluster de Failover do Windows Server). A réplica secundária do Grupo de Disponibilidade Always On estaria na instância autônoma não FCI, conforme mostrado no diagrama a seguir.

Neste exemplo, você precisaria implantar um ou mais Windows Servers com a mesma configuração de hardware e nome de computador 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 obter mais informações, consulte instalando o Operations Manager no 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 a instalação de novas instâncias do SQL Server e a restauração de bancos de dados do ú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, pois 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 em espera. Remova-os como membros dos três pools de recursos primários - Pool de Recursos de Todos os Servidores de Gerenciamento, Notificações e Atribuição do AD. Isso também inclui qualquer pool de recursos personalizado, que pode incluir servidores de gerenciamento hospedados no data center primário e precisa continuar a funcionar 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 Microsoft Monitoring Agent devem ser interrompidos e definidos como manuais ou desabilitados e 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 manual ou automática, 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 para quando o plano de recuperação de desastre precisar ser implementado.

Se um site ficar offline, o agente fará failover para o servidor de gerenciamento em outro site, supondo que a configuração de failover do agente permita isso. Reconfigure os agentes do Windows para armazenar em cache apenas os servidores de gerenciamento em seu data center primário que devem gerenciá-los para evitar que eles tentem fazer failover para um servidor de gerenciamento no data center secundário, o que apenas atrasaria a recuperação e a geraçã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 após a implantação se você enviar o agente por push do console, novamente usando um método com 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. Será necessário implantar também o 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 ITSM, outros produtos do System Center, complementos de terceiros e assim por diante), acesso ao console, leis ou políticas regulatórias ou relevantes e assim por diante para arquitetar adequadamente esse cenário no Azure IaaS ou em outros provedores de nuvem pública.