Planejando um design de grupo de gerenciamento

Visão geral

Um grupo de gerenciamento é identificado por um único banco de dados operacional, um ou mais servidores de gerenciamento e um ou mais agentes e dispositivos monitorados. A conexão de grupos de gerenciamento permite que alertas e outros dados de monitoramento sejam exibidos e editados em um único console. As tarefas também podem ser iniciadas a partir de um grupo de gerenciamento local para serem executadas nos objetos gerenciados de um grupo de gerenciamento conectado.

A implementação mais simples do Operations Manager é um único grupo de gerenciamento. Cada grupo adicional requer pelo menos seu próprio banco de dados operacional e servidor de gerenciamento. Cada grupo também deve ser mantido separadamente com suas próprias definições de configuração, pacotes de gerenciamento e integração com outras soluções de monitoramento e ITSM.

A implementação do grupo de gerenciamento distribuído formará a base de 99% das implantações do Operations Manager. Ele permite a distribuição de recursos e serviços em vários servidores para permitir escalabilidade e redundância para alguns desses recursos. Ele pode incluir todas as funções de servidor do Operations Manager e dá suporte ao monitoramento de dispositivos entre limites de confiança usando o servidor gateway.

O diagrama a seguir apresenta uma possível opção para a topologia de grupo de gerenciamento distribuído.

Observação

Não há comunicação direta entre o console de Operações e os bancos de dados. Toda a comunicação é direcionada para um servidor de gerenciamento específico pela porta TCP 5724 e, em seguida, para os servidores de banco de dados usando OLE DB no TCP 1433 ou uma porta definida pelo usuário especificada pelo administrador do SQL durante a instalação da instância do mecanismo de banco de dados do SQL Server. No entanto, há comunicação direta entre um console do Application Diagnostics (colocado com o console Web) e o SQL Server que hospeda os bancos de dados operacionais e de data warehouse.

Um grupo de gerenciamento implantado em seu ambiente pode se integrar ao OMS (Microsoft Operations Management Suite) e, utilizando o Log Analytics, você pode correlacionar, visualizar e agir ainda mais sobre o desempenho, eventos e alertas. Isso fornece maior visibilidade ao poder realizar pesquisas personalizadas em todo o conjunto de dados para correlacionar dados entre sistemas e aplicativos, hospedados no local ou na nuvem.

A integração com o Operations Manager se estende a outros produtos, como BMC Remedy, IBM, Netcool ou outras soluções de gerenciamento corporativo usadas por sua organização. Para obter mais informações sobre o planejamento da interoperabilidade com essas soluções, consulte Integração com outras soluções de gerenciamento.

Componentes do grupo de gerenciamento

Servidor de gerenciamento

No Operations Manager 2007, o servidor de gerenciamento raiz (RMS) era um tipo especializado de servidor de gerenciamento em um grupo de gerenciamento e foi o primeiro servidor de gerenciamento instalado em um grupo de gerenciamento. O RMS foi o ponto focal para administrar a configuração do grupo de gerenciamento, administrar e se comunicar com os agentes e se comunicar com o banco de dados Operacional e outros bancos de dados no grupo de gerenciamento. O RMS também serviu como destino para o console de Operações e o destino preferencial para os consoles Web. No System Center 2012 R2 – Operations Manager, a função de servidor de gerenciamento raiz foi removida e todos os servidores de gerenciamento agora são pares. Essa configuração continua a existir no System Center 2016 e posterior – Operations Manager.

O RMS não é mais um ponto único de falha, pois todos os servidores de gerenciamento hospedam os serviços anteriormente hospedados apenas pelo RMS. Funções são distribuídas para todos os servidores de gerenciamento. Se um servidor de gerenciamento se tornar indisponível, suas responsabilidades serão automaticamente redistribuídas. Uma função de emulador RMS fornece compatibilidade reversa para pacotes de gerenciamento que têm como direcionamento o RMS. Se você não tiver nenhum pacote de gerenciamento direcionado anteriormente ao RMS, não precisará usar o Emulador do RMS.

O grupo de gerenciamento pode conter vários servidores de gerenciamento para fornecer capacidade adicional e disponibilidade contínua. Quando dois ou mais servidores de gerenciamento são adicionados a um grupo de gerenciamento, os servidores de gerenciamento se tornam automaticamente parte dos três pools de recursos padrão e o trabalho é distribuído entre os membros do pool. Para pools de recursos definidos personalizados, os membros são adicionados manualmente. Quando um membro do pool de recursos falhar, outros membros no pool de recursos assumirão a carga de trabalho desse membro. Quando um novo servidor de gerenciamento é adicionado, o novo servidor de gerenciamento seleciona automaticamente parte do trabalho dos membros existentes no pool de recursos. Examine as considerações de design do pool de recursos para saber mais sobre como elas funcionam e as recomendações que influenciam seu plano de design.

Se um servidor de gerenciamento estiver indisponível por qualquer motivo, por padrão, os agentes que dependem dele farão failover automaticamente para outro servidor de gerenciamento. Ao selecionar o número e o posicionamento dos servidores de gerenciamento, essa capacidade de failover deve ser considerada se a alta disponibilidade for um requisito.

Os agentes se conectam a um servidor de gerenciamento para se comunicar com todos os outros componentes do Operations Manager. Parte do trabalho realizado por um servidor de gerenciamento é o processo de pegar os dados operacionais enviados pelos agentes e inseri-los no banco de dados operacional e no data warehouse.

Um servidor de gerenciamento típico lidará com aproximadamente 3.000 agentes. O desempenho real do servidor varia de acordo com o volume de dados operacionais coletados; No entanto, os servidores de gerenciamento normalmente podem oferecer suporte a 3.000 agentes cada, mesmo com um volume relativamente alto de dados operacionais.

Não há limite para o número máximo de servidores de gerenciamento por grupo de gerenciamento. No entanto, é uma prática recomendada usar o menor número possível de servidores de gerenciamento depois de lidar com as restrições de escalabilidade, alta disponibilidade e recuperação de desastre.

Os servidores de gerenciamento devem ter uma boa conectividade de rede com o banco de dados e o data warehouse do Operations Manager, pois eles frequentemente enviam grandes volumes de dados para esses repositórios. Em geral, essas conexões do SQL Server consomem mais largura de banda e são mais sensíveis à latência de rede. Portanto, todos os servidores de gerenciamento devem estar na mesma rede local que o banco de dados operacional e o banco de dados do Data Warehouse e nunca implantados em uma rede de longa distância. Deve haver menos de 10 milissegundos de latência entre um servidor de gerenciamento e a instância do SQL Server que hospeda os bancos de dados do Operations Manager.

Servidor Gateway

O Operations Manager exige que a autenticação mútua seja executada entre agentes e servidores de gerenciamento antes da troca de informações entre eles. Para proteger o processo de autenticação entre os dois, esse processo é criptografado. Quando o agente e o servidor de gerenciamento residirem no mesmo domínio do Active Directory ou em domínios do Active Directory que tenham estabelecido relações de confiança, eles usarão os mecanismos de autenticação Kerberos V5 fornecidos pelo Active Directory. Quando os agentes e servidores de gerenciamento não estão dentro do mesmo limite de confiança, outros mecanismos devem ser usados para atender ao requisito de autenticação mútua segura.

Os servidores de gateway são usados quando um firewall separa os agentes dos servidores de gerenciamento ou quando os agentes estão em um domínio não confiável separado. O servidor gateway atua como um proxy entre os agentes e o servidor de gerenciamento. Sem o servidor de gateway, os agentes ainda poderiam executar a autenticação de certificado com um servidor de gerenciamento, mas um certificado X.509 precisaria ser emitido e instalado em cada agente usando a ferramenta MOMCertImport.exe, e cada um exigiria acesso ao servidor de gerenciamento por meio do firewall. Se os agentes estiverem no mesmo domínio que o servidor de gateway ou se estiverem em um domínio confiável, eles poderão usar a autenticação Kerberos. Nesse caso, somente o servidor de gateway e os servidores de gerenciamento conectados exigirão certificados. Isso inclui o monitoramento de máquinas virtuais em execução na IaaS (infraestrutura como serviço) do Microsoft Azure, com o Operations Manager (ou seja, monitoramento de nuvem híbrida) que não está ingressado no mesmo realm confiável que as funções que dão suporte ao grupo de gerenciamento do Operations Manager ou que você implantou o Operations Manager na IaaS do Azure (uma máquina virtual com o SQL Server que hospeda os bancos de dados operacionais e uma ou mais máquinas virtuais que hospedam a função de servidor de gerenciamento) e está monitorando não confiável cargas de trabalho locais.

Veja a seguir um exemplo de implantação do Operations Manager monitorando recursos de IaaS do Azure.

Veja a seguir um exemplo de implantação do Operations Manager hospedada na IaaS do Azure.

Normalmente, os servidores de gateway não são usados para gerenciar a utilização da largura de banda porque o volume geral de dados enviados de agentes para um servidor de gerenciamento é semelhante, independentemente de um servidor de gateway ser usado ou não. A finalidade pretendida de um servidor gateway é reduzir o esforço necessário no gerenciamento de certificados para agentes em domínios não confiáveis e reduzir o número de caminhos de comunicação que devem ser permitidos por meio de firewalls.

• Ter mais de 2.000 agentes por servidor de gateway pode afetar negativamente a capacidade de recuperação em caso de uma interrupção sustentada que impeça o servidor de gateway de se comunicar com o servidor de gerenciamento. Vários servidores de gateway são recomendados se mais de 2.000 agentes forem necessários. A alternativa, se o tempo de recuperação do servidor gateway for uma preocupação, é testar o sistema para garantir que o servidor gateway seja capaz de esvaziar rapidamente sua fila após uma interrupção sustentada entre o servidor gateway e o servidor de gerenciamento. Além disso, depois que a fila de entrada no servidor de gateway é preenchida, os dados na fila são descartados de acordo com sua prioridade, o que significa que uma interrupção sustentada do servidor de gateway nesse cenário pode resultar em perda de dados.
• Quando houver um grande número de agentes conectados por meio de servidores de gateway, considere usar um servidor de gerenciamento dedicado para todos os servidores de gateway. Ter todos os servidores de gateway conectados a um único servidor de gerenciamento sem outros agentes conectados a ele pode acelerar o tempo de recuperação em caso de interrupção prolongada. A carga efetiva no servidor de gerenciamento é o número total de agentes que se reportam a ele diretamente ou por meio de servidores de gateway.
• Para impedir que o servidor gateway inicie a comunicação com um servidor de gerenciamento, inclusive quando configurado para fazer failover entre vários servidores de gerenciamento para alta disponibilidade, a ferramenta de aprovação do gateway inclui o argumento de linha de comando /ManagementServerInitiatesConnection. Isso permite que o Operations Manager esteja em conformidade com a política de segurança de um cliente quando os sistemas são implantados em uma DMZ ou outro ambiente de rede e a comunicação só pode ser iniciada na intranet.

Servidor do console Web

O console Web fornece uma interface para o grupo de gerenciamento que pode ser acessada por meio de um navegador da Web. Ele não tem a funcionalidade completa do console de Operações e fornece acesso apenas aos modos de exibição Monitoramento e Meu Espaço de Trabalho. O console Web fornece acesso a todos os dados e tarefas de monitoramento que são ações que podem ser executadas em computadores monitorados a partir do console de Operações. O acesso aos dados no console Web tem as mesmas restrições que o acesso ao conteúdo no console de Operações.

Servidor de relatório

Relatórios para System Center – Operations Manager é instalado no SQL Server Reporting Services (que é compatível com a versão do Operations Manager que você está usando) e a única configuração válida do Reporting Services com suporte dos Relatórios do Operations Manager é o modo nativo.

Observação

Instalando o System Center – Operations Manager Reporting Services integra a segurança da instância do SQL Reporting Services com a segurança baseada em função do Operations Manager. Não instale nenhum outro aplicativo do Reporting Services nessa mesma instância do SQL Server.

Os componentes do Servidor de Relatório do Operations Manager podem ser instalados no mesmo servidor que está executando o SQL Server 2014 ou 2016 Reporting Services ou em um computador diferente. Para obter o desempenho ideal, especialmente em um ambiente corporativo com geração paralela de relatórios de alto volume pelos usuários enquanto relatórios interativos ou programados são processados simultaneamente, você precisa escalar verticalmente para lidar com mais usuários simultâneos e cargas de execução de relatórios maiores. É recomendável que o serviço de Relatórios do Operations Manager não esteja colocalizado no mesmo SQL Server que hospeda o banco de dados do data warehouse e seja instalado em um sistema dedicado.

Banco de dados operacional

O banco de dados operacional é um banco de dados do SQL Server que contém todos os dados operacionais, informações de configuração e regras de monitoramento de um grupo de gerenciamento. O banco de dados do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, ele pode ser altamente disponibilizado usando configurações de clustering com suporte.

Para manter esse banco de dados em um tamanho consistente, as configurações de limpeza no Operations Manager especificam o período de tempo em que os dados podem ser retidos nele. Por padrão, essa duração é de sete (7) dias.

Banco de dados do Data Warehouse de relatórios

O data warehouse de relatórios é um banco de dados do SQL Server que coleta e armazena dados operacionais para relatórios de longo prazo. Esses dados são gravados diretamente de regras que coletam dados para relatar e de processos de sincronização de dados no banco de dados operacional. A manutenção do data warehouse, incluindo agregação, limpeza e otimização, é executada automaticamente pelo Operations Manager.

A tabela a seguir destaca os tipos de dados padrão e o período de retenção após a configuração inicial do banco de dados do data warehouse.

Conjunto de dados	Tipo de agregação	Período de Retenção (em dias)
Alerta	Bruta	400
Monitoramento de clientes	Bruta	30
Monitoramento de clientes	Diariamente	400
Eventos	Bruta	100
Desempenho	Bruta	10
Desempenho	A cada hora	400
Desempenho	Diariamente	400
Estado	Bruta	180
Estado	A cada hora	400
Estado	Diariamente	400

Um data warehouse pode atender a vários grupos de gerenciamento. Isso permite que um único relatório incorpore dados de todos os computadores da organização.

Assim como o banco de dados do Operations Manager, o banco de dados do data warehouse pode ser clusterizado para alta disponibilidade. Se não estiver agrupado, ele deve ser cuidadosamente monitorado para que quaisquer problemas possam ser resolvidos rapidamente.

Coletor ACS

O coletor ACS recebe os eventos dos encaminhadores ACS e os processa; em seguida, ele envia os dados para o banco de dados do ACS. Esse processamento inclui a desmontagem dos dados para que eles possam ser distribuídos em várias tabelas no banco de dados do ACS, minimizando a redundância de dados e aplicando filtros para que eventos desnecessários não sejam adicionados ao banco de dados do ACS.

Banco de dados ACS

O banco de dados do ACS é o repositório central de eventos gerados por uma diretiva de auditoria em uma implantação do ACS. O banco de dados do ACS pode ser instalado no mesmo computador do coletor ACS, mas, para melhor desempenho, cada um deve ser instalado em um servidor dedicado. Por padrão, os dados são retidos por quatorze (14) dias.

Encaminhador ACS

O serviço que é executado nos encaminhadores ACS está incluído no agente do Operations Manager. Por padrão, este serviço é instalado durante a instalação do agente do Operations Manager, mas não é habilitado. Você pode habilitar esse serviço para vários computadores agentes ao mesmo tempo usando a tarefa Habilitar Coleta de Auditoria ou usando o PowerShell. Após habilitar o serviço, todos os eventos de segurança serão enviados ao coletor ACS além de serem armazenados no log de Segurança local.

Considerações sobre o design

Os seguintes fatores devem ser levados em consideração ao decidir implementar um único ou vários grupos de gerenciamento:

• Aumento da capacidade. O Operations Manager não tem limites internos em relação ao número de agentes que um único grupo de gerenciamento pode dar suporte. Dependendo do hardware que você usa e da carga de monitoramento (mais pacotes de gerenciamento implantados significam uma carga de monitoramento mais alta) no grupo de gerenciamento, talvez você precise de vários grupos de gerenciamento para manter um desempenho aceitável.
• Exibições consolidadas. Quando vários grupos de gerenciamento são usados para monitorar um ambiente, é necessário um mecanismo para fornecer uma exibição consolidada dos dados de monitoramento e alerta deles. Isso pode ser feito implantando um grupo de gerenciamento adicional (que pode ou não ter responsabilidades de monitoramento) que tenha acesso a todos os dados em todos os outros grupos de gerenciamento. Esses grupos de gerenciamento são então considerados conectados. O grupo de gerenciamento usado para fornecer uma exibição consolidada dos dados é chamado de grupo de gerenciamento local, e os outros que fornecem dados a ele são chamados de grupos de gerenciamento conectados.
• Segurança e Administrativo. O particionamento de grupos de gerenciamento por motivos administrativos e de segurança é semelhante em conceito à delegação de autoridade administrativa sobre unidades organizacionais ou domínios do Active Directory para diferentes grupos administrativos. Sua empresa pode incluir vários grupos de TI, cada um com sua própria área de responsabilidade. A área pode ser uma área geográfica específica ou divisão de negócios. Por exemplo, no caso de uma holding, pode ser uma das empresas subsidiárias. Quando existe esse tipo de delegação total de autoridade administrativa do grupo de TI centralizado, pode ser útil implementar uma estrutura de grupo de gerenciamento em cada uma das áreas. Em seguida, eles podem ser configurados como grupos de gerenciamento conectados a um grupo de gerenciamento local que reside no data center de TI centralizado.
• Idiomas instalados. Todos os servidores com uma função de servidor do Operations Manager instalada neles devem ser instalados no mesmo idioma. Ou seja, você não pode instalar o servidor de gerenciamento usando a versão em inglês do Operations Manager 2012 R2 e, em seguida, implantar o Console de Operações usando a versão em japonês. Se o monitoramento precisar abranger vários idiomas, um grupo de gerenciamento adicional será necessário para cada idioma dos operadores.
• Funcionalidade de produção e pré-produção. No Operations Manager, é uma prática recomendada ter uma implementação de produção usada para monitorar seus aplicativos de produção e uma implementação de pré-produção que tenha interação mínima com o ambiente de produção. O grupo de gerenciamento de pré-produção é usado para testar e ajustar a funcionalidade do pacote de gerenciamento antes de ser migrado para o ambiente de produção. Além disso, algumas empresas empregam um ambiente de teste para servidores em que os servidores recém-criados são colocados por um período de burn-in antes de serem colocados em produção. O grupo de gerenciamento de pré-produção pode ser usado para monitorar o ambiente de preparo para garantir a integridade dos servidores antes da distribuição da produção.
• Funcionalidade ACS dedicada. Se seus requisitos incluírem a necessidade de coletar eventos de log de Segurança de Auditoria do Windows ou eventos de segurança UNIX/Linux, você implementará o ACS (Serviço de Coleta de Auditoria). Pode ser benéfico implementar um grupo de gerenciamento que ofereça suporte à função ACS exclusivamente se os requisitos de segurança da sua empresa exigirem que a função ACS seja controlada e administrada por um grupo administrativo diferente daquele que gerencia o restante do ambiente de produção.
• Funcionalidade de recuperação de desastres. No Operations Manager, todas as interações com o banco de dados do Operations Manager são registradas em logs de transações antes de serem confirmadas no banco de dados. Esses logs de transações podem ser enviados para outro servidor que executa o Microsoft SQL Server e confirmados em uma cópia do banco de dados do Operations Manager. Esse recurso é uma opção para fornecer redundância do banco de dados operacional do Operations Manager entre dois SQL Servers no mesmo grupo de gerenciamento. Quando um failover controlado precisa ser executado, os servidores de gerenciamento no grupo de gerenciamento exigem uma alteração no Registro para fazer referência e se comunicar com o SQL Server secundário. Um grupo de gerenciamento de failover pode ser implantado, o que corresponde à configuração exata do grupo de gerenciamento primário (pacotes de gerenciamento, substituições, assinaturas de notificação, segurança etc.) e os agentes são configurados para relatar a ambos os grupos de gerenciamento. Se o grupo de gerenciamento primário em sua totalidade ficar indisponível por qualquer motivo, não haverá tempo de inatividade do ambiente de monitoramento. Esta solução garante a continuidade do serviço do grupo de gerenciamento e perda zero de monitoramento operacional.

Antes de implantar o System Center Operations Manager em um ambiente de produção, planeje o design do seu grupo de gerenciamento. Durante a fase de planejamento, entender os componentes de serviço de TI (ou seja, infraestrutura e nível de aplicativo) e o número de sistemas e dispositivos que os suportam, como ele integrará e dará suporte aos seus processos de gerenciamento de incidentes e problemas e como você visualizará os dados para diferentes camadas de suporte de escalonamento de incidentes, engenharia, consumidores de serviço e gerenciamento.

Grupos de gerenciamento conectados

Muitas empresas com servidores em várias localizações geográficas exigem monitoramento central desses servidores. A configuração do grupo de gerenciamento conectado, ilustrada na imagem abaixo, é um conjunto de processos de fluxo de trabalho projetados para criar uma infraestrutura de gerenciamento de sistemas hierárquicos.

Essa configuração pode ser usada para obter monitoramento centralizado. Ele foi projetado para dar suporte à exibição de alertas e dados de monitoramento e para iniciar tarefas em um objeto gerenciado de um grupo de gerenciamento conectado.

Ao conectar grupos de gerenciamento do Operations Manager, a funcionalidade de monitoramento centralizado pode ser mantida e, ao mesmo tempo, habilitar:

• Monitoramento de um número maior de objetos de gerenciamento do que é possível com um único grupo de gerenciamento.
• Isolamento da atividade de monitoramento de acordo com unidades de negócios lógicas, como "Marketing", ou locais físicos, como Roma.

Ao conectar grupos de gerenciamento, você não está implantando nenhum servidor novo; pelo contrário, está permitindo que o grupo de gerenciamento local tenha acesso aos alertas e às informações de descoberta que estão em um grupo de gerenciamento conectado. Dessa forma, você pode exibir e interagir com todos os alertas e outros dados de monitoramento de vários grupos de gerenciamento em um único console de Operações. Além disso, você pode executar tarefas em computadores monitorados dos grupos de gerenciamento conectados. Para saber como conectar grupos de gerenciamento, consulte Conectando grupos de gerenciamento no Operations Manager.

Idiomas instalados

Os grupos de gerenciamento do Operations Manager dão suporte a apenas um idioma instalado. Se o ambiente de TI geral que você precisa monitorar tiver mais de um idioma instalado, será necessário um grupo de gerenciamento separado por idioma.