Considerações de design do pool de recursos

Importante

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

Um pool de recursos é um agrupamento lógico de servidores de gerenciamento e/ou servidores de gateway que distribuem o trabalho entre si e assumem o trabalho de um membro que falhou. Em outras palavras, eles fornecem alta disponibilidade e escalabilidade para os fluxos de trabalho. Ao criar um grupo de gerenciamento, é necessário considerar alguns fatores ao monitorar dispositivos de rede, sistemas UNIX/Linux e outras cargas de trabalho que foram projetadas para tirar proveito de um pool de recursos.

Visão geral

Pools de recursos asseguram a continuidade do monitoramento, fornecendo vários membros, que são servidores de gerenciamento e/ou servidores de gateway que podem assumir fluxos de trabalho de monitoramento caso um dos membros do pool fique indisponível. Você pode criar pools de recursos para fins específicos. Por exemplo, você pode criar um pool de recursos de servidores de gerenciamento em seu data center principal para monitorar dispositivos de rede.

Pools de recursos aplicam uma lógica semelhante ao "conjunto de nós principais” do clustering, em que (< número de nós como membros do pool > /2) + 1. No mínimo, deve haver três membros no pool para manter o quorum, que deve ser superior a 50% dos membros votantes do quorum em um pool para manter a disponibilidade do pool. Se você tiver apenas dois membros do pool e um não estiver disponível, você perdeu quorum.

Para cada pool de recursos criado no console de Operações, o banco de dados do Operations Manager, que é chamado de observador padrão, sempre recebe um voto, mesmo que você tenha um número par de membros no pool para permitir que o quorum seja alcançado. Isso também se aplica aos três pools de recursos criados por padrão quando você cria o grupo de gerenciamento pela primeira vez, que é discutido posteriormente neste artigo. Para todos os pools de recursos criados usando o cmdlet do PowerShell NewSCOM-ResourcePool, ele é definido como desabilitado por padrão. Incluir o banco de dados do Operations Manager como o observador padrão reduz a complexidade do seu grupo de gerenciamento apenas solicitando que você implante dois servidores de gerenciamento no mínimo para manter a alta disponibilidade de seus pools de recursos.

Outra função de suporte a um pool de recursos são os observadores. Esse é um servidor de gerenciamento ou um servidor de Gateway que não participa do carregamento de fluxos de trabalho para o pool; no entanto, eles participam de decisões de quorum. Isso nunca é usado em circunstâncias normais e não deve ser considerado.

Há dois tipos de associação:

• Automático
• Manual

Quando você cria um pool de recursos, sua associação é definida como manual e não pode ser reconfigurada como automática. Quando um grupo de gerenciamento do System Center – Operations Manager é criado, são criados três pools de recursos por padrão com associação automática. A tabela a seguir descreve esses três pools de recursos.

Nome do pool de recursos	Descrição
Todo pool de recursos de servidores de gerenciamento	Executa fluxos de trabalho de cálculo de grupo, disponibilidade, pacote cumulativo de atualizações de integridade de monitor distribuído e limpeza de banco de dados.
Pool de recursos de notificações	Os fluxos de trabalho de Serviço de Assinatura de Alerta são direcionados para esse pool de recursos para dar suporte a notificações de alerta.
Pool de recursos de atribuição do AD	Os fluxos de trabalho de Integração do AD são direcionados para esse pool de recursos para dar suporte à atribuição automática de agentes a servidores de gerenciamento.

Como a associação do Pool de Recursos de Todos os Servidores de Gerenciamento é automática, qualquer servidor de gerenciamento comissionado se torna automaticamente um membro do pool de recursos. Em determinadas considerações sobre arquiteturas e design, como aqueles que incorporam operações de contingência geograficamente dispersas, a atribuição automática ao Pool de Recursos de Todos os Servidores de Gerenciamento pode não ser desejada. Nessas situações, é possível alterar a atribuição de associação de automática para manual. Sendo assim, os servidores de gerenciamento devem ser adicionados ao Pool de Recursos de Todos os Servidores de Gerenciamento por meio da atribuição manual.

Observação

A associação do Pool de Todos os Recursos dos Servidores de Gerenciamento é somente leitura. Para alterar sua associação de automática para manual, consulte Modificando a Associação do Pool.

Com a introdução de pools de recursos, é recomendável que todos os membros estejam conectados por uma rede de baixa latência (menos de 10 ms). Os pools de recursos não devem ser implantados em vários data centers ou em um ambiente de nuvem híbrida, como o Microsoft Azure.

Exemplos de disponibilidade do Pool de recursos

Os exemplos a seguir demonstram o conceito de disponibilidade do pool de recursos com base nas seguintes configurações, apenas com servidores de gerenciamento ou servidores de Gateway.

Servidor de gerenciamento único

• O observador padrão é habilitado por padrão e não oferece nenhum benefício, pois há somente dois membros e o quorum não é atingido.
• Não há alta disponibilidade porque o servidor de gerenciamento é um ponto único de falha.

Dois servidores de gerenciamento

• O observador padrão é habilitado por padrão.
• Há alta disponibilidade para o pool porque há três membros votantes : dois servidores de gerenciamento e o observador padrão.
• Ao desabilitar o observador padrão, você perderá a alta disponibilidade do pool.

Três servidores de gerenciamento

• O observador padrão é habilitado por padrão.
• Há alta disponibilidade para o pool, pois há quatro membros votantes : três servidores de gerenciamento e o observador padrão.
• Por padrão, você pode ter apenas um servidor de gerenciamento indisponível para manter o quorum. Se dois servidores de gerenciamento não estiverem disponíveis, você terá exatamente 50% dos membros votantes e o pool de recursos não funcionará mais para gerenciar as cargas de trabalho de monitoramento.
• O observador padrão não aumenta o número de servidores de gerenciamento que podem estar inativos, portanto, ele não aumenta a disponibilidade do pool.
• Você pode considerar a remoção do observador padrão nesse cenário.

Quatro servidores de gerenciamento

• O observador padrão é habilitado por padrão.
• Há alta disponibilidade para o pool, pois há cinco membros votantes : quatro servidores de gerenciamento e o observador padrão.
• Por padrão, você pode ter apenas dois servidores de gerenciamento indisponíveis para manter o quorum. Se três servidores de gerenciamento estiverem inativos, você terá menos de 50% dos membros votantes e o pool de recursos não funcionará mais para gerenciar as cargas de trabalho de monitoramento.
• O observador padrão proporciona um valor significativo neste cenário, porque ele aumenta o número de servidores de gerenciamento que podem estar inativos. Sem o observador padrão, você teria apenas quatro membros do quorum, permitindo que apenas um membro estivesse indisponível.

Cinco servidores de gerenciamento

• O observador padrão é habilitado por padrão.
• Há alta disponibilidade para o pool, pois há seis membros votantes : cinco servidores de gerenciamento e o observador padrão.
• Por padrão, você pode ter apenas dois servidores de gerenciamento indisponíveis para manter o quorum. Se três servidores de gerenciamento estiverem indisponíveis, você terá exatamente 50% dos membros votantes e o pool de recursos não poderá ser usado para gerenciar as cargas de trabalho de monitoramento.
• O observador padrão não aumenta o número de servidores de gerenciamento que podem estar inativos, portanto, ele não aumenta a disponibilidade do pool.
• Você pode considerar a remoção do observador padrão nesse cenário.

Depois de chegar a três ou mais servidores de gerenciamento em um pool de recursos, em que você tem um número ímpar de membros no pool, você pode considerar a remoção do observador padrão como membro. Se você atingir cinco servidores de gerenciamento, haverá o potencial para que o banco de dados operacional experimente carga significativa, o que pode gerar latência suficiente para afetar os cálculos do pool de recursos.

Com a forma como o observador padrão desempenha um papel, cada servidor de gerenciamento no pool consulta seu próprio serviço SDK local, o que permite consultar uma tabela no banco de dados operacional para o observador padrão. Se o banco de dados ou o serviço SDK estiver sob uma carga, haverá uma latência que, de outra forma, não existiria.

Servidor de Gateway único

• O observador padrão é habilitado por padrão.
• Não há alta disponibilidade porque o servidor de Gateway é um ponto único de falha.
• O observador padrão não deve ser usado aqui porque os servidores de Gateway não têm um serviço SDK local e, portanto, não podem consultar o banco de dados operacional.

Dois servidores de Gateway

• O observador padrão é habilitado por padrão.
• Não há alta disponibilidade porque há apenas dois membros do pool e o observador padrão não é um participante porque os servidores de Gateway não se comunicam diretamente com o banco de dados operacional. Três servidores de Gateway são necessários para manter o quorum do pool.

Três servidores de Gateway

• O observador padrão é habilitado por padrão.
• Há alta disponibilidade para o pool porque há três membros votantes – três servidores de Gateway.
• Por padrão, você só pode ter um servidor de Gateway indisponível para manter o quorum. Se três servidores de Gateway estiverem indisponíveis, você terá menos de 50% dos membros votantes e o pool de recursos não poderá ser usado para gerenciar as cargas de trabalho de monitoramento.
• O observador padrão não deve ser usado aqui porque os servidores de Gateway não têm um serviço SDK local e, portanto, não podem consultar o banco de dados operacional.

Cenários de monitoramento que dão suporte a pools de recursos

Os fluxos de trabalho a seguir são hospedados por pools de recursos no Operations Manager:

• Gerenciamento de dispositivos de rede
• Gerenciamento de agentes UNIX/Linux
• Gerenciamento de URLs de aplicativo Web

Observação

Agentes do Windows não são subordinados a pools de recursos.

O monitoramento de rede no Operations Manager requer seu próprio pool de recursos separado e dedicado. Isso ocorre porque os fluxos de trabalho de monitoramento de rede são executados em servidores de gerenciamento (no módulo SNMP), e não em agentes. Isso coloca um fardo pesado sobre os servidores de gerenciamento depois que você inclui o monitoramento de portas de rede, especialmente se você selecionar a maioria das portas ativas disponíveis no dispositivo. Portanto, para obter um melhor desempenho, recomendamos usar servidores de gerenciamento dedicados em pools de recursos dedicados para o monitoramento da rede. Além disso, os servidores de gerenciamento que são membros desse pool devem ser removidos dos pools de Todos os Servidores de Gerenciamento, Notificações e Atribuição do AD.

O monitoramento de UNIX/Linux no Operations Manager pode ser atribuído a um pool de recursos dedicado, se necessário, para habilitar o monitoramento de alta disponibilidade e o gerenciamento de agentes, mas não é necessário. O Operations Manager usa certificados para autenticar o acesso aos computadores que está gerenciando. Quando o Assistente de Descoberta implanta um agente, ele recupera o certificado do agente, assina o certificado, implanta o certificado de volta no agente e, depois, reinicia o agente. Para dar suporte à alta disponibilidade, cada servidor de gerenciamento do pool de recursos deve ter todos os certificados raiz usados para assinar os certificados implantados nos agentes dos computadores UNIX e Linux. Caso contrário, se um servidor de gerenciamento ficar indisponível, os outros servidores de gerenciamento não poderão confiar nos certificados assinados pelo servidor que falharam.

Próximas etapas

Para saber mais sobre como criar e gerenciar pools de recursos, consulte Como gerenciar pools de recursos.