Elevada Disponibilidade e Recuperação após Desastre

Importante

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

System Center – os servidores e funcionalidades do Operations Manager podem potencialmente falhar, afetando a funcionalidade do Operations Manager. A quantidade de dados e funcionalidade perdidas durante uma falha é diferente em cada cenário de falha. Depende da função da funcionalidade com falhas e do tempo que demora a recuperar a funcionalidade com falhas.

Elevada disponibilidade

As necessidades de elevada disponibilidade são resolvidas ao criar redundância para o grupo de gestão de bases de dados operacionais e de armazém de dados do Operations Manager, servidores de gateway e de gestão, e cargas de trabalho específicas. Estas cargas de trabalho incluem monitorização de dispositivos de rede, monitorização entre plataformas e cargas de trabalho específicas do grupo de gestão que eram anteriormente geridas pelo Servidor de Gestão de Raiz.

A configuração de vários servidores, de um único grupo de gestão, pode utilizar o SQL Server AlwaysOn para fornecer elevada disponibilidade e continuidade de serviço das bases de dados do Operations Manager. A tolerância a falhas do servidor de gestão é fornecida por ter, pelo menos, dois servidores de gestão e ao utilizar os agrupamentos de recursos para monitorizar servidores UNIX, servidores Linux e dispositivos de rede. Os servidores Windows baseados em agentes podem ser configurados com um servidor de gestão primário e secundário para redirecionar comunicações de agentes caso um servidor de gestão falhe.

O Emulador RMS também pode ser movido para outro servidor de gestão, caso o servidor de gestão que aloja o Emulador RMS fique indisponível.

As ligações da consola de operações podem ser disponibilizadas de forma elevada ao configurar a elevada disponibilidade para os Serviços de Acesso a Dados. Isto pode ser feito ao instalar o Balanceamento de Carga de Rede da Microsoft (NLB) ou ao utilizar um balanceador de carga baseado em hardware ou alias DNS. Um ou mais servidores de gestão são adicionados como membros do conjunto de NLB e, ao abrir a consola, faz referência ao nome virtual registado no DNS, dos servidores de gestão com balanceamento de carga.

Nota

Uma Balanceador de Carga de Rede não é suportada para o servidor de consola Web do Operations Manager.

Podem ser implementados vários servidores de gateway através de um limite de confiança para fornecer caminhos redundantes para agentes que se situam nesse limite de confiança. Tal como os agentes se podem situar entre um servidor de gestão primário e um ou mais servidores de gestão secundários, eles podem também situar-se entre servidores de gateway. Além disso, podem ser utilizados vários servidores de gateway para distribuir a carga de trabalho de gestão de computadores geridos sem agente e dispositivos de rede geridos.

Para além de proporcionarem redundância através de ativação pós-falha do agente-gateway, os servidores de gateway podem ser configurados para se situarem entre servidores de gestão num grupo de gestão, se estiverem disponíveis vários servidores de gestão.

Embora SQL Server Reporting Services suporte um modelo de implementação de escalamento horizontal que lhe permite executar várias instâncias do servidor de relatórios que partilham uma única base de dados do servidor de relatórios, não é suportado com o Operations Manager. O Operations Manager Reporting instala uma extensão de segurança personalizada como parte da configuração dos componentes de front-end, que não podem ser replicados no farm Web.

Recuperação após desastre

A recuperação após desastre está relacionada com as medidas tomadas para garantir que as operações podem ser retomadas se uma falha catastrófica (por exemplo, perda de todo o datacenter que aloja a infraestrutura primária). É um elemento importante que tem de ser considerado em qualquer implementação e as decisões tomadas no planeamento da recuperação após desastre afetam a forma como o Operations Manager poderá continuar a suportar a monitorização proativa e a comunicação do desempenho e disponibilidade dos seus serviços de TI críticos. Esta secção irá centrar-se na estratégia recomendada de recuperação após desastre e resiliência, e nas medidas que deverão ser tomadas para assegurar uma recuperação sem problemas.

Embora as soluções HA e DR forneçam proteção contra falhas do sistema ou perda de sistema, não devem ser confiadas para proteção contra danos ou perdas de dados acidentais, não intencionais ou maliciosas. Nestes casos, as cópias de segurança copiadas ou atrasadas podem ter de ser utilizadas para operações de restauro. Em muitos casos, uma operação de restauro é a forma mais adequada de DR. Um exemplo poderia ser uma base de dados de relatórios ou dados de análise de baixa prioridade. Em muitos casos, o custo para ativar a DR de múltiplos sites a nível do sistema ou aplicação ultrapassa bastante o valor dos dados. Nos casos em que o valor a curto prazo dos dados é baixo e a necessidade de aceder aos dados pode ser adiada sem um impacto comercial grave se uma falha ou dr.dr do site for excessivo, considere utilizar processos de cópia de segurança e restauro simples para DR se a poupança de custos o justificar.

Compreender o impacto e a tolerância do período de indisponibilidade ajudará a tomar as decisões com pleno entendimento de modo a planear adequadamente a arquitetura do Operations Manager, o nível de complexidade e os custos necessários para suportar a recuperação após desastre. Além disso, considere a extensão da monitorização da perda de dados que a organização de TI pode tolerar sem causar consequências comerciais. Isto é descrito melhor em dois termos: objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO).

As duas configurações de conceção da recuperação após desastre mais comuns para o Operations Manager são:

• Criar um grupo de gestão duplicado implementado no seu datacenter secundário que duplica em escala e configuração o grupo de gestão principal.
• Implementar servidores adicionais num datacenter secundário para suportar a base de dados Operacional e do Armazém de Dados, com servidores de gestão implementados numa configuração de reserva progressiva, sem participar no grupo de gestão até que as ações de recuperação tenham de ser efetuadas.

Implementar um grupo de gestão duplicado é uma opção quando não existe tolerância para o período de inatividade; no entanto, é a opção mais complexa. A configuração entre ambos tem de ser consistente para que, quando corta, não haja diferença no que é monitorizado, alertado ou comunicado, apresentado e, por fim, escalado. A integração com outras plataformas de monitorização ou plataformas ITSM, como o System Center - Service Manager, Remedy ou ServiceNow também terá de existir e possivelmente configurada num estado ativo/passivo para evitar a duplicação de incidentes, itens de configuração, entre outros. Os agentes serão multihomed entre os dois grupos de gestão, pelo que haverá duplicação de dados.

O diagrama seguinte é um exemplo deste cenário de conceção.

Se a recuperação imediata não for necessária para a implementação do Operations Manager e quiser evitar a complexidade de um grupo de gestão duplicado, pode, em alternativa, implementar componentes adicionais do grupo de gestão no seu datacenter secundário para manter a funcionalidade do seu grupo de gestão. No mínimo, considere a implementação de um Grupo de Disponibilidade Always On do SQL Server 2014 ou 2016 para fornecer a recuperação das bases de dados Operacionais e do Armazém de Dados entre dois ou mais datacenters, onde é implementada uma instância de cluster de ativação pós-falha (FCI) de dois nós no datacenter primário e um SQL Server autónomo no datacenter secundário, como parte de um único Cluster de Ativação Pós-falha do Windows Server (WSFC). A réplica secundária do Grupo de Disponibilidade Always On estaria na instância autónoma não-FCI, conforme mostrado no diagrama seguinte.

Neste exemplo, seria necessário implementar um ou mais Windows Servers com a mesma configuração de hardware e o nome do computador e reinstalar a função de servidor de gestão com o parâmetro /Recuperar . 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, veja Instalar o Operations Manager a partir da linha de comandos.

Durante este período, os agentes colocarão em fila os dados recolhidos (alertas, eventos, desempenho, etc.) até poderem retomar a comunicação com um servidor de gestão no grupo de gestão. Esta abordagem evita a instalação de novas instâncias do SQL Server e o restauro de bases de dados a partir da última cópia de segurança em boas condições. No entanto, neste cenário de recuperação, é provável que haja um atraso maior no regresso a um estado operável, dado que terá de implementar as outras funções necessárias para retomar a funcionalidade mínima de monitorização. Se esta abordagem não for aceitável, pode implementar servidores de gestão no seu datacenter secundário para a recuperação no modo de espera. Remova-os como membros dos três conjuntos de recursos principais – Conjunto de Recursos de Todos os Servidores de Gestão, Notificações e Atribuição do AD. Isto também inclui qualquer conjunto de recursos personalizado, que pode incluir servidores de gestão alojados no datacenter primário e precisam de continuar a funcionar como parte do plano de recuperação. Os serviços de Acesso a Dados do System Center, Gestão da Configuração do System Center e Microsoft Monitoring Agent devem ser parados e definidos para manual ou desativados, e apenas devem ser iniciados num cenário de recuperação após desastre.

Se um servidor de gestão suportar a integração (através de um conector alojado diretamente no servidor de gestão ou a partir de outro produto do System Center, como o VMM, o Orchestrator ou Service Manager), terá de ser planeado com passos de recuperação manuais ou automáticos, consoante a configuração de integração e a sequência de passos de recuperação. Isto garante que qualquer outra dependência no servidor de gestão é capturada e planeada para quando o plano de recuperação após desastre tem de ser implementado.

Se um site ficar offline, o agente irá falhar no servidor de gestão de outro site, partindo do princípio que a configuração da ativação pós-falha do agente o permite. Reconfigure os agentes do Windows para colocar em cache apenas servidores de gestão no seu datacenter primário que devem geri-los para impedir que tentem efetuar a ativação pós-falha para um servidor de gestão no datacenter secundário, o que apenas atrasaria a recuperação e os relatórios. Isto pode ser conseguido se implementar manualmente o agente de forma automatizada com um script (por exemplo, VBScript ou melhor ainda, PowerShell) para pré-configurar durante a instalação ou após a implementação se emitir o agente a partir da consola, utilizando novamente um método scripted gerido com a sua solução de gestão de configuração empresarial.

O Operations Manager pode ser implementado em máquinas virtuais do Azure, em alternativa à opção de recuperação após desastre para manter a continuidade do grupo de gestão. Também será necessário implementar SQL Server numa máquina virtual no Azure e não numa configuração híbrida, uma vez que a latência entre um servidor de gestão e o SQL Server que aloja as bases de dados do Operations Manager afetará negativamente o desempenho do grupo de gestão.

Considere o âmbito de monitorização, a topologia de rede e a conectividade de rede ao Microsoft Azure (ou seja, VPN site a site ou ExpressRoute), pontos de integração (ou seja, soluções ITSM, outros produtos do System Center, suplementos de terceira parte, etc.), acesso à consola, leis ou políticas relevantes ou regulamentares, etc., e assim sucessivamente para arquitetar corretamente este cenário no Azure IaaS ou noutros fornecedores de cloud pública.