Planejando um projeto do grupo de gerenciamento

Importante

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

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. Conectar grupos de gerenciamento permite que alertas e outros dados de monitoramento sejam exibidos e editados em um único console. Tarefas também podem ser iniciadas de um grupo de gerenciamento local para serem executadas nos objetos gerenciados de um grupo de gerenciamento conectado.

A implementação do Operations Manager mais simples é um grupo de gerenciamento único. Cada grupo adicional requer, pelo menos, o próprio servidor de banco de dados e gerenciamento operacional. 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.

Diagrama de um servidor único mg de exemplo.

A implementação do grupo de gerenciamento distribuído formará a base de 99% de implantações do Operations Manager. Permite a distribuição de recursos e serviços entre diversos servidores para permitir a 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 de gateway.

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

Diagrama de um mg distribuído de OM de exemplo.

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 na TCP 1433 ou em 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 de Diagnóstico de Aplicativo (colocado com o console Web) e o SQL Server hospedando os bancos de dados operacionais e de data warehouse.

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

Ilustração da integração do OM com o Microsoft OMS.

A integração ao 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 de interoperabilidade com essas soluções, confira a 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) foi 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 era o ponto focal para administrar a configuração do grupo de gerenciamento, administrar e se comunicar com agentes e se comunicar com o banco de dados operacional e outros bancos de dados no grupo de gerenciamento. O RMS também atuou como o destino para o console de Operações e o destino preferencial de 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 correspondentes. Essa configuração continua existindo no System Center 2016 e posterior – Operations Manager.

O RMS não é mais o único ponto de falha, já que todos os servidores de gerenciamento hospedam os serviços hospedados anteriormente 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 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 automaticamente se tornam parte dos três pools de recursos padrão e o trabalho é disseminado 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 pega 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 eles funcionam e as recomendações que influenciam seu plano de design.

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

Os agentes se conectar a um servidor de gerenciamento para se comunicar com todos os outros componentes do Operations Manager. Parte do trabalho executado 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 do servidor real varia de acordo com o volume de dados operacionais coletados; No entanto, servidores de gerenciamento, normalmente, podem dar suporte a 3.000 agentes cada, mesmo com um volume relativamente grande 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 restrições de escalabilidade, alta disponibilidade e recuperação de desastre.

Os servidores de gerenciamento devem ter uma boa conectividade de rede com o data warehouse e banco de dados do Operations Manager porque eles frequentemente enviam grandes volumes de dados para esses armazenamentos. 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 do banco de dados operacional e do banco de dados do Data Warehouse e nunca implantado 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 requer 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 os 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 de gateway atua como um proxy entre os agentes e o servidor de gerenciamento. Sem o servidor de gateway, os agentes ainda podem realizar a autenticação de certificado com um servidor de gerenciamento. No entanto, um certificado X.509 precisa ser emitido e instalado em cada agente por meio da ferramenta MOMCertImport.exe. Cada um desses agentes exige 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, apenas 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á associado ao 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 no IaaS do Azure (uma máquina virtual com SQL Server hospedando os bancos de dados operacionais e uma ou mais máquinas virtuais que hospedam a função de servidor de gerenciamento) e estão monitorando cargas de trabalho locais não confiáveis.

O item a seguir apresenta um exemplo de implantação do Operations Manager monitorando recursos de IaaS do Azure.
Ilustração do OpsMgr Monitoring Azure Resources.

A seguir, está um exemplo de implantação do Operations Manager hospedada na IaaS do Azure.
Ilustração do OpsMgr hospedado em 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 se um servidor de gateway é usado ou não. A finalidade pretendida de um servidor de 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 impede que o servidor de gateway se comunique com o servidor de gerenciamento. Vários servidores de gateway serão recomendados se mais de 2.000 agentes forem necessários. A alternativa, se o tempo de recuperação do servidor de gateway for uma preocupação, é testar o sistema para garantir que o servidor de gateway seja capaz de esvaziar rapidamente sua fila após uma interrupção sustentada entre o servidor de 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 prolongada do servidor de gateway nesse cenário pode resultar em perda de dados.
  • Quando há 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. Fazer com que todos os servidores de gateway se conectem a um único servidor de gerenciamento sem outros agentes conectados a ele pode acelerar o tempo de recuperação em caso de interrupção sustentada. O carregamento efetivo no servidor de gerenciamento é o número total de agentes subordinados a ele diretamente ou por meio de servidores de gateway.
  • Para impedir que o servidor de gateway inicie a comunicação com um servidor de gerenciamento, incluindo 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 do cliente quando os sistemas são implantados em um DMZ ou outro ambiente de rede e a comunicação só poderá ser iniciada da intranet.

Servidor do console Web

O console Web fornece uma interface para o grupo de gerenciamento que seja acessível 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 Workspace. O console Web fornece acesso a todos os dados de monitoramento e tarefas que são ações que podem ser executadas em computadores monitorados no console de Operações. O acesso a dados no console Web tem as mesmas restrições que o acesso ao conteúdo no console de Operações.

Servidor de relatórios

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

Observação

Instalar 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ções do Operations Manager. Não instale nenhum outro Reporting Services aplicativos nesta mesma instância do SQL Server.

Os componentes de servidor de relatórios 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 um desempenho ideal, especialmente em um ambiente empresarial com geração de relatórios paralelos de alto volume por usuários enquanto relatórios interativos ou agendados estão sendo processados simultaneamente, você precisa escalar verticalmente para lidar com mais usuários simultâneos e cargas de execução de relatório maiores. É recomendável que o serviço de Relatórios do Operations Manager não esteja colocalizado no mesmo SQL Server hospedando o banco de dados do data warehouse e 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 para um grupo de gerenciamento. O banco de dados do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, pode se tornar altamente disponível 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 que os dados podem ser mantidos nele. Por padrão, esta 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 das regras que coletam dados de relatório e de processos de sincronização de dados no banco de dados operacional. A manutenção do data warehouse, incluindo a agregação, limpeza e otimização, é realizada 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 instalação inicial do banco de dados do data warehouse.

Dataset Tipo de agregação Período de retenção (em dias)
Alerta Raw 400
Monitoramento de Clientes Raw 30
Monitoramento de Clientes Diariamente 400
Eventos Raw 100
Desempenho Raw 10
Desempenho A cada hora 400
Desempenho Diariamente 400
Estado Raw 180
Estado A cada hora 400
Estado Diariamente 400

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

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 clusterizado, ele deverá ser monitorado cuidadosamente 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 possam ser distribuídos em várias tabelas dentro do banco de dados ACS, minimizando a redundância de dados e aplicando filtros para que eventos desnecessários não sejam adicionados ao banco de dados 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 catorze (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 em vários computadores do agente 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 ou vários grupos de gerenciamento:

  • Maior capacidade. O Operations Manager não tem limites internos em relação ao número de agentes que podem ter suporte de um único grupo de gerenciamento. Dependendo do hardware que você usa e a carga de monitoramento (mais pacotes de gerenciamento implantados significa uma carga maior de monitoramento) no grupo de gerenciamento, vários grupos de gerenciamento podem ser necessários para manter o desempenho aceitável.
  • Exibições consolidadas. Quando vários grupos de gerenciamento são usados para monitorar um ambiente, um mecanismo é necessário para fornecer uma exibição consolidada dos dados de monitoramento e de alerta deles. Isso pode ser feito com a implantação de um grupo de gerenciamento adicional (que pode ou não ter qualquer responsabilidade de monitoramento) que tem acesso a todos os dados em todos os outros grupos de gerenciamento. Esses grupos de gerenciamento em seguida devem ser conectados. O grupo de gerenciamento que é 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 à delegação de autoridade administrativa em 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 empresa controladora, ela pode ser uma das empresas subsidiárias. Quando esse tipo de delegação completa de autoridade administrativa do grupo de TI centralizado existe, pode ser útil implementar uma estrutura de grupo de gerenciamento em cada uma das áreas. Então, elas podem ser configuradas como grupos de gerenciamento Conectados para 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 japonesa. Se o monitoramento precisar abranger vários idiomas, será necessário um grupo de gerenciamento adicional 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 implantam um ambiente de preparo para servidores em que os servidores recém-criados são colocados por um período de gravação 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 de produção.
  • Funcionalidade do ACS dedicado. 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 SERVIÇO de Coleta de Auditoria (ACS). Isso pode ser útil ao implementar um grupo de gerenciamento que dá suporte à função de 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 nos logs de transações antes de serem confirmadas no banco de dados. Esses logs de transação 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 é necessário realizar um failover controlado, os servidores de gerenciamento no grupo de gerenciamento exigem uma alteração no Registro para referência e comunicação com o SQL Server secundário. Um grupo de gerenciamento de failover pode ser implantado, 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. Essa 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 grupo de gerenciamento. Durante a fase de planejamento, entender os componentes do serviço de TI (ou seja, infraestrutura e nível de aplicativo) e o número de sistemas e dispositivos que dão suporte a eles, como ele integrará e dará suporte aos 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ários locais geográficos precisam de monitoramento central desses servidores. A configuração do grupo de gerenciamento Conectado, ilustrada na imagem abaixo, é um conjunto de processos de fluxo de trabalho que são projetados para criar uma infraestrutura de gerenciamento de sistemas hierárquicos.

Diagrama do exemplo do grupo de gerenciamento conectado.

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.

Pela conexão dos grupos de gerenciamento do Operations Manager, a funcionalidade de monitoramento centralizado poderá ser mantida, permitindo ao mesmo tempo:

  • O monitoramento de um número maior de objetos gerenciados do que o que era 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 localizações físicas, como Roma.

Ao conectar grupos de gerenciamento, você não está implantando novos servidores; em vez disso, você está permitindo que o grupo de gerenciamento local tenha acesso aos alertas e 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.