Considerações sobre o design do pool de recursos

Um pool de recursos é um agrupamento lógico de servidores de gerenciamento e/ou servidores de gateway usados para distribuir o trabalho entre si e assumir o trabalho de um membro com falha. Em outras palavras, eles fornecem alta disponibilidade e escalabilidade para fluxos de trabalho. Ao projetar um grupo de gerenciamento, considerações devem ser feitas para o monitoramento de dispositivos de rede, sistemas Linux/UNIX e outras cargas de trabalho projetadas para aproveitar um pool de recursos.

Visão geral

Os pools de recursos garantem 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 se um dos membros do pool ficar 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 primário 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 é conhecido como 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 atingido. 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, o que é discutido posteriormente neste artigo. Para todos os pools de recursos criados usando o cmdlet NewSCOM-ResourcePool do PowerShell, 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, exigindo apenas que você implante dois servidores de gerenciamento no mínimo para manter a alta disponibilidade de seus pools de recursos.

Outra função que dá suporte a um pool de recursos são os observadores. Este é 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 das decisões do quórum. Isso nunca é usado em circunstâncias normais e, portanto, não deve ser considerado.

Existem 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, três pools de recursos são criados 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
Pool de recursos de todos os servidores de gerenciamento	Executa fluxos de trabalho para cálculo de grupo, disponibilidade, acúmulo de integridade do monitor distribuído e limpeza do banco de dados.
Pool de recursos de notificações	Os fluxos de trabalho do Serviço de Assinatura de Alerta são direcionados a 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 a esse pool de recursos para dar suporte à atribuição automática de agentes aos 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 membro desse pool de recursos. Em determinadas arquiteturas e considerações de design, como aquelas 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. Dessa forma, os servidores de gerenciamento devem ser adicionados ao pool de recursos de todos os servidores de gerenciamento por meio de 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 ao 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 configurações a seguir, somente com servidores de gerenciamento ou somente com servidores de Gateway.

Servidor de gerenciamento único

• O observador padrão é habilitado por padrão e não oferece nenhum benefício, pois há apenas dois membros e o quorum não é atingido.
• Não há alta disponibilidade porque o servidor de gerenciamento é um único ponto 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.
• Se você desabilitar o observador padrão, 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ê só pode ter 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, não aumenta a disponibilidade do pool.
• Você pode considerar a remoção do observador padrão neste 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 nesse cenário fornece um valor significativo, pois aumenta o número de servidores de gerenciamento que podem estar inativos. Sem o observador padrão, você teria apenas quatro membros do quórum, o que permite que apenas um membro fique 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ê só pode ter dois servidores de gerenciamento indisponíveis para manter o quorum. Se três servidores de gerenciamento não estiverem disponíveis, isso será 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, não aumenta a disponibilidade do pool.
• Você pode considerar a remoção do observador padrão neste cenário.

Depois de alcançar três ou mais servidores de gerenciamento em um pool de recursos, em que você tem um número ímpar de membros no pool, considere remover o observador padrão como membro. Se você atingir cinco servidores de gerenciamento, há a possibilidade de o banco de dados operacional ter uma carga significativa, o que pode gerar latência suficiente para afetar os cálculos do pool de recursos.

Com a maneira como o observador padrão desempenha uma função, 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 Gateway é um único ponto de falha.
• O observador padrão não deve ser usado aqui porque os servidores Gateway não têm um serviço SDK local e, portanto, não podem consultar o banco de dados operacional.

Dois servidores 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 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 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 Gateway indisponível para manter o quorum. Se dois servidores de gateway estiverem inativos, isso será 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 não deve ser usado aqui porque os servidores 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 seguintes fluxos de trabalho são hospedados por pools de recursos no Operations Manager:

• Gerenciamento de dispositivos de rede
• Gerenciamento de agentes UNIX/Linux
• Monitorando URLs de aplicativos Web

Observação

Os agentes do Windows não se reportam 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 uma carga pesada nos servidores de gerenciamento quando você inclui o monitoramento de portas de rede, especialmente se você selecionar a maioria das portas ativas disponíveis no dispositivo. Portanto, para melhor desempenho, recomendamos o uso de servidores de gerenciamento dedicados em pools de recursos dedicados para monitoramento de rede. Além disso, os servidores de gerenciamento que são membros desse pool devem ser removidos dos pools Todos os Servidores de Gerenciamento, Notificações e Atribuição do AD.

O monitoramento do Linux/UNIX 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 no pool de recursos deve ter todos os certificados raiz usados para assinar os certificados implantados nos agentes nos 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 falhou.

Próximas etapas

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