Planejando um projeto 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 visualizados e editados a partir de 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 oferece suporte ao monitoramento de dispositivos entre limites de confiança usando o servidor gateway.

O diagrama a seguir apresenta uma opção possível para a topologia do 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 de Diagnóstico de Aplicativo (colocalizado com o console Web) e o SQL Server que hospeda os bancos de dados operacionais e de data warehouse.

Um grupo de gerenciamento que você implantou em seu ambiente pode se integrar ao Microsoft Operations Management Suite (OMS) e, utilizando o Log Analytics, você pode correlacionar, visualizar e agir ainda mais sobre desempenho, eventos e alertas. Isso proporciona maior visibilidade, sendo capaz de 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 empresarial usadas pela sua organização. Para obter mais informações sobre como planejar a interoperabilidade com essas soluções, consulte Integração com outras soluções de gerenciamento.

Componentes do grupo de gestão

Servidor de gerenciamento

No Operations Manager 2007, o RMS (servidor de gerenciamento raiz) 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 do grupo de gerenciamento. O RMS também serviu como destino para o console de Operações e como 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. Esta configuração continua a existir no System Center 2016 e posterior - Operations Manager.

O RMS não é mais um único ponto de falha, pois todos os servidores de gerenciamento hospedam os serviços anteriormente hospedados apenas pelo RMS. As funções são distribuídas para todos os servidores de gerenciamento. Se um servidor de gerenciamento ficar indisponível, suas responsabilidades serão automaticamente redistribuídas. Uma função de emulador do RMS proporciona compatibilidade retroativa para pacotes de gerenciamento direcionados ao 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 personalizados definidos, os membros são adicionados manualmente. Quando um membro do pool de recursos falhar, outros membros do pool de recursos pegarão a carga de trabalho desse membro. Quando um novo servidor de gestão é adicionado, o novo servidor de gestão assume automaticamente parte do trabalho dos membros existentes no grupo de recursos. Analise 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 suportar 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 restrições de escalabilidade, alta disponibilidade e recuperação de desastres.

Os servidores de gerenciamento devem ter uma boa conectividade de rede com o banco de dados e o data warehouse do Operations Manager, pois 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 da 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.

Gateway de servidor

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, o processo é criptografado. Quando o agente e o servidor de gerenciamento residem no mesmo domínio do Ative Directory ou em domínios do Ative Directory que estabeleceram relações de confiança, eles usam mecanismos de autenticação Kerberos V5 fornecidos pelo Ative 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 satisfazer o requisito de autenticação mútua segura.

Os servidores 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 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 gateway ou se estiverem em um domínio confiável, eles poderão usar a autenticação Kerberos. Nesse caso, apenas o servidor gateway e os servidores de gerenciamento conectados exigirão certificados. Isso inclui a monitorização de máquinas virtuais a funcionar na infraestrutura como serviço (IaaS) do Microsoft Azure, com o Operations Manager (ou seja, monitorização de nuvem híbrida) que não está associado ao mesmo domínio confiável que as funções que dão suporte ao grupo de gestão do Operations Manager, ou tenha implantado o Operations Manager na IaaS do Azure (uma máquina virtual com o SQL Server a hospedar os bancos de dados operacionais e uma ou mais máquinas virtuais a hospedar a função de servidor de gestão) e está a monitorizar cargas de trabalho locais não confiáveis.

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

A seguir está um exemplo de implantação do Operations Manager hospedada na IaaS do Azure.

Normalmente, os servidores 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 gateway ser usado ou não. O objetivo pretendido 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 gateway pode afetar negativamente a capacidade de recuperação em caso de uma interrupção sustentada que impeça o servidor gateway de se comunicar com o servidor de gerenciamento. Vários servidores gateway são recomendados se forem necessários mais de 2.000 agentes. 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 gateway é preenchida, os dados na fila são descartados de acordo com sua prioridade, o que significa que uma interrupção sustentada do servidor gateway nesse cenário pode resultar em perda de dados.
• Quando houver um grande número de agentes conectados por meio de servidores gateway, considere o uso de um servidor de gerenciamento dedicado para todos os servidores gateway. Ter todos os servidores 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 sustentada. A carga efetiva no servidor de gerenciamento é o número total de agentes que se reportam a ele diretamente ou por meio de servidores gateway.
• Para impedir que o servidor gateway inicie a comunicação com um servidor de gestão, inclusive quando configurado para failover entre vários servidores de gestão 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 em outro ambiente de rede e a comunicação só pode ser iniciada a partir da intranet.

Servidor de console Web

O console da 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órios

Reporting for System Center – Operations Manager é instalado no SQL Server Reporting Services (que é suportado pela versão do Operations Manager que está a utilizar) e a única configuração válida do Reporting Services suportada pelos Relatórios do Operations Manager é o modo nativo.

Observação

A instalação do System Center – Operations Manager Reporting Services integra a segurança da instância do SQL Server Reporting Services à segurança baseada em funções 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 melhor desempenho, especialmente em um ambiente corporativo com geração paralela de relatórios de alto volume pelos usuários enquanto relatórios interativos ou agendados são processados simultaneamente, você precisa aumentar a escala para lidar com mais usuários simultâneos e cargas maiores de execução de relatórios. É recomendável que o serviço de Relatório do Operations Manager não esteja colocalizado no mesmo SQL Server que hospeda o armazém de dados, devendo ser instalado num sistema dedicado.

Base 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 ser altamente disponível usando configurações de clustering suportadas.

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

Banco de dados do Reporting Data Warehouse

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 relatório e de processos de sincronização de dados no banco de dados operacional. A manutenção do data warehouse, incluindo agregação, preparação 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 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	Cru	400
Monitorização de Clientes	Cru	30
Monitorização de Clientes	Diariamente	400
Eventos	Cru	100
Desempenho	Cru	10
Desempenho	Por hora	400
Desempenho	Diariamente	400
Estado	Cru	180
Estado	Por hora	400
Estado	Diariamente	400

Um armazém de dados pode servir vários grupos de gestão. Isso permite que um único relatório incorpore dados de todos os computadores da 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 agrupado, deve ser cuidadosamente monitorizado para que quaisquer problemas possam ser resolvidos rapidamente.

Coletor ACS

O coletor ACS recebe e processa eventos de encaminhadores ACS e, em seguida, envia esses dados para o banco de dados ACS. Esse processamento inclui a desmontagem dos dados para que eles possam ser espalhados por 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.

Base de dados ACS

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

Transitário ACS

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

Considerações de design

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

• 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 suportar. Dependendo do hardware usado e da carga de monitoramento (mais pacotes de gerenciamento implantados significa uma carga de monitoramento maior) no grupo de gerenciamento, você pode precisar de vários grupos de gerenciamento para manter um desempenho aceitável.
• Vistas consolidadas. Quando vários grupos de gerenciamento são usados para monitorar um ambiente, um mecanismo é necessário para fornecer uma visã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. Diz-se então que estes grupos de gestão estão ligados. 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 Administração. 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 Ative Directory a 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 filiais. Nos casos em que exista este tipo de delegação total da autoridade administrativa do grupo informático centralizado, poderá ser útil implementar uma estrutura de grupo de gestão 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, não é possível 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 a monitorização tiver de abranger várias línguas, será necessário um grupo de gestão adicional para cada língua 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 testes para servidores onde os servidores recém-construídos são colocados por um período de teste 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 implantação da produção.
• Funcionalidade ACS dedicada. Se os seus requisitos incluírem a necessidade de recolher eventos de log de segurança de auditoria do Windows ou eventos de segurança do UNIX/Linux, irá implementar o Serviço de Coleta de Auditoria (ACS). Pode ser benéfico implementar um grupo de gerenciamento que suporte exclusivamente a função ACS 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 lá. 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 do Registro para fazer referência e se comunicar 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. Esta solução garante a continuidade do serviço do grupo de gestão e zero perda de monitorização 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, compreenda 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ços e gerenciamento.

Grupo de gestão ligado

Muitas empresas com servidores em vários locais geográficos 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 hierárquica de gerenciamento de sistemas.

Essa configuração pode ser usada para obter monitoramento centralizado. Ele foi projetado para dar suporte à visualizaçã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 monitorização de acordo com unidades de negócio lógicas, tais como "Marketing", ou locais físicos, como Roma.

Quando você conecta grupos de gerenciamento, 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 visualizar 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 nos 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 oferecem suporte a apenas um idioma instalado. Se o ambiente geral de TI que você precisa monitorar tiver mais de um idioma instalado, será necessário um grupo de gerenciamento separado por idioma.