Alta disponibilidade e recuperação de desastres

System Center – Os servidores e recursos do Operations Manager podem falhar, afetando a funcionalidade do Operations Manager. A quantidade de dados e funcionalidades perdidas durante uma falha é diferente 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 gestão para os bancos de dados operacionais e de data warehouse do Operations Manager, os servidores de gateway e de gestão, e cargas de trabalho específicas. Essas cargas de trabalho incluem monitoramento de dispositivos de rede, monitoramento entre plataformas e cargas de trabalho específicas do grupo de gerenciamento que foram gerenciadas anteriormente pelo Servidor de Gerenciamento Raiz.

A configuração de vários servidores e grupo de gerenciamento único pode 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 usando 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 disponíveis configurando a alta disponibilidade para os Serviços de Acesso a Dados. Isso pode ser feito instalando o Microsoft Network Load Balancing (NLB) 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 de NLB e, ao abrir o console, você faz referência ao nome virtual registrado no DNS dos servidores de gerenciamento com balanceamento de carga.

Vários servidores gateway podem ser implantados através de um limite de confiança para fornecer caminhos redundantes para agentes que estão através desse limite de confiança. Assim como os agentes podem fazer failover entre um servidor de gerenciamento primário e um ou mais servidores de gerenciamento secundários, eles também podem fazer failover entre servidores gateway. Além disso, vários servidores gateway podem ser usados para distribuir a carga de trabalho do gerenciamento de computadores gerenciados sem agente e dispositivos de rede gerenciados.

Além de fornecer redundância através do recurso de alternância do gateway de agente, é possível configurar os servidores gateway para alternar entre servidores de gestão num grupo de gestão, caso estejam disponíveis múltiplos servidores de gestão.

Embora o SQL Server Reporting Services ofereça suporte a um modelo de implantação em 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. 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 na web farm.

Recuperação de desastres

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 nas medidas que devem ser tomadas para garantir uma recuperação suave.

Embora as soluções 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 acidental, não intencional ou maliciosa de dados. Nesses casos, talvez seja necessário fazer backup de cópias de replicação copiadas ou com atraso para operações de restauração. Em muitos casos, uma operação de restauração é a forma mais apropriada de DR. Um exemplo disso poderia 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 em vários locais 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 uma falha ou DR do local for excessiva, considere o uso de processos simples de backup e restauração para DR se a economia de custos o 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ário 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 (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, 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:

• Criação de 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.

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 as duas partes precisa ser consistente para que, quando se fizer a transição, não haja diferença no que é monitorizado, alertado, 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, ser 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 em seu data center secundário para manter a funcionalidade do seu 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 do Data Warehouse entre dois ou mais datacenters, onde 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 para o Grupo de Disponibilidade Always On estaria na instância autônoma não FCI, conforme mostrado no diagrama a seguir.

Neste exemplo, seria necessário implantar um ou mais servidores Windows com a mesma configuração de hardware e nome do computador e reinstalar a função de servidor de gerenciamento usando o parâmetro /Recover. Aqui está 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 a partir do prompt de comando.

Durante este período, 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 gestão no grupo de gestão. Essa abordagem evita a instalação de novas instâncias do SQL Server e a restauração de bancos de dados do seu último backup válido. No entanto, nesse cenário de recuperação, provavelmente haverá um atraso maior no retorno a um estado operável, já 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 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 principal e precisam continuar a funcionar como parte do plano de recuperação. Os serviços System Center Data Access, System Center Configuration Management e Microsoft Monitoring Agent devem ser interrompidos e definidos como manuais ou desabilitados e iniciados apenas em um cenário de recuperação de desastres.

Se um servidor de gerenciamento estiver oferecendo 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 das 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 desastres 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 tentem fazer failover para um servidor de gerenciamento no data center secundário, o que só 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 pós-implantação se você enviar o agente do console, novamente usando um método de 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 desastres para manter a continuidade do grupo de gerenciamento. Também será necessário implantar 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 Rota Expressa), 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.