Planear uma Conceção de Grupo de Gestão

Importante

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

Descrição Geral

Um grupo de gestão é identificado por uma base de dados operacional individual, um ou mais servidores de gestão, e um ou mais agentes e dispositivos monitorizados. Ligar grupos de gestão permite que os alertas e outros dados de monitorização sejam visualizados e editados a partir de uma única consola. As tarefas podem ser iniciadas a partir de um grupo de gestão local para serem executadas em objetos geridos de um grupo de gestão ligado.

A implementação mais simples do Operations Manager é um grupo de gestão único. Cada grupo adicional necessita, pelo menos, de uma base de dados operacional própria e do servidor de gestão. Cada grupo também deve ser mantido em separado com definições de configuração próprias, pacotes de gestão e integração com outras soluções de monitorização e ITSM.

A instalação do grupo de gestão distribuído formará a base de 99 por cento das implementações do Operations Manager. Permite a distribuição de funcionalidades e serviços em vários servidores para permitir a escalabilidade e redundância de algumas destas funcionalidades. Pode incluir todas as funções de servidor do Operations Manager e suporta a monitorização de dispositivos entre limites de fidedignidade através do servidor de gateway.

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

Nota

Não existe comunicação direta entre a Consola de operações e as bases de dados. Todas as comunicações são direcionadas para um servidor de gestão específico através da porta TCP 5724 e, em seguida, para os servidores de base de dados através de OLE DB em TCP 1433 ou de uma porta definida pelo utilizador e especificada pelo administrador de SQL durante a configuração da instância de motor de base de dados do SQL Server. No entanto, existe comunicação direta entre uma consola do Application Diagnostics (colocalizado com a consola Web) e o SQL Server que aloja as bases de dados operacionais e do armazém de dados.

Um grupo de gestão que implementou no seu ambiente pode ser integrado com o Microsoft Operations Management Suite (OMS) e, ao utilizar o Log Analytics, pode correlacionar, visualizar e agir sobre desempenho, eventos e alertas. Isto proporciona maior visibilidade ao conseguir realizar pesquisas personalizadas em todo o conjunto de dados para correlacionar dados entre sistemas e aplicações, alojados no local ou na cloud.

A integração com o Operations Manager estende-se a outros produtos, como a BMC Remedy, IBM, Netcool ou outras soluções de gestão empresarial utilizadas pela sua organização. Para obter mais informações sobre o planeamento de interoperabilidade com estas soluções, veja o artigo sobre a integração com outras soluções de gestão.

Componentes do grupo de gestão

Servidor de Gestão

No Operations Manager 2007, o servidor de gestão Raiz (RMS) era um tipo especializado de servidor de gestão num grupo de gestão, tendo sido o primeiro servidor de gestão instalado num grupo de gestão. O RMS foi o ponto central da administração da configuração do grupo de gestão, administração e comunicação com agentes, e comunicação com a base de dados Operacional e outras bases de dados do grupo de gestão. O RMS também funcionava como destino para a consola de operações e destino preferencial para as consolas Web. No System Center 2012 R2 – Operations Manager, a função de servidor de gestão raiz foi removida e todos os servidores de gestão passaram a ser elementos. Esta configuração continua a existir no System Center 2016 e posterior – Operations Manager.

O RMS deixou de ser um ponto único de falha, pois todos os servidores de gestão alojam os serviços alojados anteriormente apenas pelo RMS. As funções são distribuídas por todos os servidores de gestão. Se um servidor de gestão ficar indisponível, as suas responsabilidades são redistribuídas automaticamente. Uma função de emulador do RMS fornece compatibilidade com versões anteriores para pacotes de gestão direcionados para o RMS. Se não tiver nenhum pacote de gestão que tenha visado anteriormente o RMS, não terá de utilizar o Emulador RMS.

O grupo de gestão pode conter vários servidores de gestão para fornecer capacidade adicional e disponibilidade contínua. Quando dois ou mais servidores de gestão são adicionados a um grupo de gestão, os servidores de gestão tornam-se automaticamente parte dos três agrupamentos de recursos predefinidos e o trabalho é distribuído por todos os membros do agrupamento. Os membros são adicionados manualmente para os agrupamentos de recursos personalizados definidos . Quando um membro do agrupamento de recursos falha, outros membros no agrupamento de recursos recolhem a carga de trabalho desse membro. Quando é adicionado um novo servidor de gestão, o novo servidor de gestão recolhe automaticamente parte do trabalho dos membros existentes no agrupamento de recursos. Veja Considerações de conceção do conjunto de recursos para saber mais sobre como funcionam e as recomendações que influenciam o seu plano de design.

Se um servidor de gestão não estiver disponível por qualquer motivo, por predefinição, os agentes que dependem dele irão efetuar automaticamente a ativação pós-falha para outro servidor de gestão. Ao selecionar o número e o posicionamento dos servidores de gestão, esta capacidade de ativação pós-falha deve ser considerada se a elevada disponibilidade for um requisito.

Os agentes ligam-se a um servidor de gestão para comunicar com todos os outros componentes do Operations Manager. Algum do trabalho realizado por um servidor de gestão relaciona-se com o processo de obter os dados operacionais enviados pelos agentes e inseri-los numa base de dados operacional e no armazém de dados.

Um servidor de gestão típico irá processar cerca de 3000 agentes. O desempenho real do servidor reais varia de acordo com o volume de dados operacionais recolhidos. No entanto, normalmente os servidores de gestão podem suportar 3000 agentes cada, mesmo com um volume de dados operacionais relativamente elevado.

Não existe limite para o número máximo de servidores de gestão por grupo de gestão. No entanto, é uma melhor prática utilizar o menor número possível de servidores de gestão após abordar a escalabilidade, elevada disponibilidade e restrições de recuperação após desastre.

Os servidores de gestão devem dispor de uma boa conectividade de rede à base de dados e ao armazém de dados do Operations Manager pois enviam frequentemente grandes volumes de dados para estes arquivos. Regra geral, estas ligações de SQL Server consomem mais largura de banda e são mais sensíveis à latência de rede. Por conseguinte, todos os servidores de gestão devem estar na mesma rede local que a base de dados Operacional e a base de dados do Armazém de Dados e nunca devem ser implementados numa rede alargada. A latência entre um servidor de gestão e a instância do SQL Server que aloja bases de dados do Operations Manager deve ser inferior a 10 milissegundos.

Servidor de gateway

O Operations Manager necessita que a autenticação mútua seja efetuada entre agentes e servidores de gestão antes do intercâmbio de informações entre eles. Para proteger o processo de autenticação entre os dois, o processo é encriptado. Quando o agente e o servidor de gestão residem no mesmo domínio do Active Directory ou em domínios do Active Directory que estabeleceram relações de confiança, utilizam os mecanismos de autenticação Kerberos V5 fornecidos pelo Active Directory. Quando os agentes e os servidores de gestão não se encontram dentro do mesmo limite de fidedignidade, devem ser utilizados outros mecanismos para satisfazer o requisito de autenticação mútua segura.

Os servidores de gateway são utilizados quando uma firewall separa os agentes dos servidores de gestão ou quando os agentes estão num domínio não fidedigno separado. O servidor de gateway funciona como um proxy entre os agentes e o servidor de gestão. Sem o servidor de gateway, os agentes ainda podiam efetuar a autenticação de certificados com um servidor de gestão, mas um certificado X.509 teria de ser emitido e instalado em cada agente com a ferramenta MOMCertImport.exe e cada um precisaria de acesso ao servidor de gestão através da firewall. Se os agentes estiverem no mesmo domínio que o servidor de gateway ou num domínio fidedigno, têm de utilizar a autenticação Kerberos. Neste caso, o servidor de gateway e os servidores de gestão ligados necessitarão de certificados. Isto inclui a monitorização de máquinas virtuais em execução na infraestrutura como um serviço (IaaS) do Microsoft Azure, com o Operations Manager (ou seja, a monitorização da cloud híbrida) que não está associada ao mesmo domínio fidedigno que as funções que suportam o grupo de gestão do Operations Manager ou implementou o Operations Manager no IaaS do Azure (uma máquina virtual com SQL Server alojar as bases de dados operacionais e uma ou mais máquinas virtuais que alojam a função de servidor de gestão) e estão a monitorizar cargas de trabalho no local não fidedignos.

A seguir encontra uma implementação do Operations Manager de exemplo a monitorizar os recursos de Azure IaaS.

A seguir encontra um exemplo da implementação do Operations Manager alojada no Azure IaaS.

Normalmente, os servidores de gateway não são utilizados para gerir a utilização da largura de banda porque o volume geral de dados enviados de agentes para um servidor de gestão é semelhante, quer um servidor de gateway seja utilizado ou não. O objetivo pretendido de um servidor de gateway é reduzir o esforço necessário na gestão de certificados para agentes em domínios não fidedignos e reduzir o número de caminhos de comunicação que têm de ser permitidos através de firewalls.

• Ter mais de 2000 agentes por servidor de gateway pode afetar negativamente a capacidade de recuperação em caso de uma falha sustentada que impeça o servidor de gateway de comunicar com o servidor de gestão. É recomendado o recurso a vários servidores de gateway quando são necessários mais de 2.000 agentes. 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 consegue esvaziar rapidamente a fila após uma falha sustentada entre o servidor de gateway e o servidor de gestão. Além disso, depois de a fila de entrada no servidor de gateway ficar cheia, os dados na fila são removidos com base na prioridade, o que significa que uma indisponibilidade no servidor de gateway neste cenário pode resultar na perda de dados.
• Quando existir um grande número de agentes ligados através de servidores de gateway, considere utilizar um servidor de gestão dedicado para todos os servidores de gateway. Ter todos os servidores de gateway ligados a um único servidor de gestão sem outros agentes ligados pode acelerar o tempo de recuperação em caso de indisponibilidade sustentada. A carga efetiva no servidor de gestão é o número total de agentes que reportam diretamente ou através dos servidores de gateway.
• Para impedir que o servidor de gateway inicie a comunicação com um servidor de gestão, incluindo quando configurado para efetuar a ativação pós-falha entre vários servidores de gestão para elevada disponibilidade, a ferramenta de Aprovação do gateway inclui o argumento da linha de comandos /ManagementServerInitiatesConnection. Isto permite ao Operations Manager cumprir a política de segurança de um cliente quando são implementados sistemas num DMZ ou noutro ambiente de rede, e a comunicação só pode ser iniciada a partir da intranet.

Servidor da consola Web

A consola Web fornece uma interface para o grupo de gestão que está acessível através de um browser. Não tem todas as funcionalidades da Consola de operações e fornece acesso apenas às vistas Monitorização e A Minha Área de Trabalho. A consola Web fornece acesso a todos os dados de monitorização e às tarefas que são ações que podem ser executadas para computadores monitorizados a partir da consola de operações. O acesso aos dados na consola Web tem as mesmas restrições que o acesso ao conteúdo da consola de operações.

Servidor de Relatórios

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

Nota

Instalar o System Center – Operations Manager Reporting Services integra a segurança da instância dos Serviços Relatórios SQL com a segurança baseada em funções do Operations Manager. Não instale outras aplicações do Reporting Services nesta mesma instância do SQL Server.

Os componentes do Servidor de Relatórios do Operations Manager podem ser instalados no mesmo servidor que está a executar o SQL Server 2014 ou 2016 Reporting Services ou num computador diferente. Para obter um desempenho ideal, especialmente num ambiente empresarial com geração de relatórios paralelos e de elevado volume por parte dos utilizadores enquanto os relatórios interativos ou agendados estão a ser processados em simultâneo, tem de aumentar verticalmente para processar utilizadores mais simultâneos e cargas de execução de relatórios maiores. Recomenda-se que o Serviço de Relatórios do Operations Manager não esteja colocalizado no mesmo SQL Server a alojar a base de dados do armazém de dados e instalado num sistema dedicado.

Base de Dados Operacional

A base de dados operacional é uma base de dados do SQL Server que contém todos os dados operacionais, informações de configuração e regras de monitorização para um grupo de gestão. A base de dados do Operations Manager é uma origem única da falha para o grupo de gestão, pelo que pode ficar altamente disponível através da utilização de configurações de cluster suportadas.

Para manter esta base de dados num tamanho consistente, as definições de limpeza do Operations Manager especificam o período de tempo de retenção dos dados. Por predefinição, esta duração é sete (7) dias.

Base de dados do Armazém de Dados de Relatórios

O armazém de dados de Relatórios é uma base de dados do SQL Server que recolhe e armazena dados operacionais para relatórios a logo prazo. Estes dados são escritos diretamente a partir das regras que recolhem dados a reportar e de processos de sincronização de dados na base de dados operacional. A manutenção do armazém de dados, incluindo agregação, limpeza e otimização, é executada automaticamente pelo Operations Manager.

A tabela seguinte realça os tipos de dados predefinidos e o período de retenção após a configuração inicial da base de dados do armazém de dados.

Conjunto de dados	Tipo de Agregação	Período de retenção (em dias)
Alerta	Não processado	400
Monitorização de Cliente	Não processado	30
Monitorização de Cliente	Diário	400
Evento	Não processado	100
Desempenho	Não processado	10
Desempenho	Hora a hora	400
Desempenho	Diário	400
Estado	Não processado	180
Estado	Hora a hora	400
Estado	Diário	400

Um armazém de dados também pode servir vários grupos de gestão. Isto permite que um único relatório incorpore dados de todos os computadores em toda a organização.

Tal como a base de dados do Operations Manager, a base de dados do armazém de dados pode ser agrupada para elevada disponibilidade. Se não estiver em cluster, deve ser cuidadosamente monitorizado para que quaisquer problemas possam ser resolvidos rapidamente.

Recoletor ACS

O recoletor ACS recebe e processa eventos de reencaminhadores ACS e, em seguida, envia estes dados para a base de dados ACS. Este processamento inclui a desmontagem dos dados para que possam ser distribuídos por várias tabelas na base de dados ACS, minimizando a redundância de dados e aplicando filtros para que não sejam adicionados eventos desnecessários à base de dados ACS.

Base de dados ACS

A base de dados ACS é o repositório central de eventos que são gerados por uma política de auditoria numa implementação de ACS. A base de dados ACS pode estar localizada no mesmo computador do que o recoletor ACS, mas para um melhor desempenho, cada um deve estar instalado num servidor dedicado. Por predefinição, os dados são retidos quatorze (14) dias.

Reencaminhador de ACS

O serviço que é executado em reencaminhadores ACS está incluído no agente do Operations Manager. Por predefinição, este serviço está instalado mas não ativado quando o agente do Operations Manager é instalado. Pode ativar este serviço para vários computadores de agente ao mesmo tempo utilizando a tarefa Ativar a Recolha de Auditorias ou o PowerShell. Depois de ativar este serviço, todos os eventos de segurança são enviados para o recoletor ACS para além do registo de Segurança local.

Considerações de design

Os fatores seguintes deverão ser tidos em consideração quando optar por implementar um grupo de gestão único ou diversos grupos de gestão:

• Aumento da Capacidade. O Operations Manager não tem limites incorporados relativamente ao número de agentes suportados por um grupo de gestão único. Consoante o hardware utilizado e a carga de monitorização (mais pacotes de gestão implementados significa uma carga de monitorização mais elevada) do grupo de gestão, poderá necessitar de vários grupos de gestão para manter um desempenho aceitável.
• Vistas Consolidadas. Quando vários grupos de gestão são utilizados para monitorizar um ambiente, é necessário um mecanismo que forneça uma vista consolidada dos dados de monitorização e alerta dos mesmos. Para tal, implemente um grupo de gestão adicional (que poderá ou não ter responsabilidades de monitorização) que tenha acesso a todos os dados em todos os outros grupos de gestão. Diz-se então que estes grupos de gestão estão ligados. O grupo de gestão utilizado para fornecer uma vista consolidada dos dados é designado por grupo de gestão Local e os que fornecem dados ao mesmo são chamados grupos de gestão Ligados.
• Segurança e Administração. A criação de partições de grupos de gestão por motivos administrativos e de segurança é semelhante, por conceito, à delegação de autoridade administrativa através de Unidades Organizacionais do Active Directory ou domínios a diferentes grupos administrativos. A sua empresa pode incluir vários grupos de TI, cada um com uma área de responsabilidade própria. A área poderá ser uma área geográfica específica ou uma divisão de negócio. Por exemplo, no caso de uma holding, pode ser uma das empresas subsidiárias. Sempre que existir este tipo de delegação total da autoridade administrativa a partir do grupo de TI centralizado, poderá ser útil implementar uma estrutura de grupo de gestão em cada uma das áreas. Podem então ser configurados como grupos de gestão Ligados a um grupo de gestão Local residente no centro de dados centralizado do TI.
• Idiomas Instalados. Todos os servidores com uma função de servidor do Operations Manager instalada têm de ser instalados no mesmo idioma. Ou seja, não pode instalar o servidor de gestão com a versão em inglês do Operations Manager 2012 R2 e, em seguida, implementar a Consola de Operações com a versão japonesa. Se a monitorização tiver de incluir vários idiomas, será necessário um grupo de gestão 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 que é utilizada para monitorizar as suas aplicações de produção e uma implementação de pré-produção que tem uma interação mínima com o ambiente de produção. O grupo de gestão de pré-produção é utilizado para testar e otimizar a funcionalidade do pacote de gestão antes de ser migrado para o ambiente de produção. Além disso, algumas empresas utilizam um ambiente de teste para servidores em que os servidores recém-criados são utilizados durante um período de depuração antes de serem colocados em produção. O grupo de gestão de pré-produção pode ser utilizado para monitorizar o ambiente de teste para garantir o estado de funcionamento dos servidores antes da implementação de produção.
• Funcionalidade ACS Dedicada. Se os seus requisitos incluírem a necessidade de recolher eventos de registo de Segurança de Auditoria do Windows ou eventos de segurança UNIX/Linux, estará a implementar o Serviço de Recolha de Auditorias (ACS). Poderá ser vantajoso implementar um grupo de gestão que suporte a função ACS exclusivamente, caso os requisitos de segurança da sua empresa exijam que a função ACS seja controlada e administrada por um grupo administrativo diferente do que gere o resto do ambiente de produção.
• Funcionalidade de Recuperação Após Desastre. No Operations Manager, todas as interações com a base de dados do Operations Manager são registadas nos registos de transações antes de serem consolidadas na base de dados. Estes registos de transações podem ser enviados para outro servidor com o Microsoft SQL Server e consolidados numa cópia da base de dados do Operations Manager. Esta funcionalidade é uma opção que proporciona redundância da base de dados operacional do Operations Manager entre dois SQL Server existentes no mesmo grupo de gestão. Quando for necessário efetuar uma ativação pós-falha controlada, os servidores de gestão do grupo de gestão necessitam de uma alteração de registo para referenciarem e comunicarem com o SQL Server secundário. Um grupo de gestão de ativação pós-falha pode ser implementado, que corresponde à configuração exata do grupo de gestão primário (pacotes de gestão, substituições, subscrições de notificação, segurança, etc.) e os agentes estão configurados para reportar a ambos os grupos de gestão. Se o grupo de gestão principal na sua totalidade ficar indisponível por qualquer motivo, não haverá tempo de inatividade do ambiente de monitorização. Esta solução garante a continuidade do serviço do grupo de gestão e nenhuma perda de monitorização operacional.

Antes de implementar o System Center Operations Manager num ambiente de produção, planeie a estrutura do seu grupo de gestão. Durante a fase de planeamento, compreenda os componentes do serviço de TI (ou seja, ao nível da infraestrutura e da aplicação) e o número de sistemas e dispositivos que os suportam, como irá integrar e suportar os seus processos de gestão de incidentes e problemas e como irá visualizar os dados para diferentes escalões de suporte de escalamento de incidentes, engenharia, consumidores de serviços e gestão.

Grupos de gestão ligados

Muitas empresas com servidores em várias localizações geográficas necessitam de uma monitorização central desses servidores. A configuração do grupo de gestão Ligado, ilustrada na imagem abaixo, é um conjunto de processos de fluxo de trabalho que foram concebidos para criar uma infraestrutura de gestão de sistemas hierárquica.

Esta configuração pode ser utilizada para disponibilizar a monitorização centralizada. Foi concebido para suportar a visualização de alertas e dados de monitorização e para iniciar tarefas num objeto gerido de um grupo de gestão ligado.

Ao ligar grupos de gestão do Operations Manager, a funcionalidade de monitorização centralizada pode ser mantida ao mesmo tempo que permite:

• A monitorização de um número de objetos geridos superior ao permitido por um grupo de gestão único.
• O isolamento da atividade de monitorização de acordo com unidades de negócio lógicas, tais como "Marketing" ou localizações físicas como Roma.

Quando liga grupos de gestão, não está a implementar novos servidores; em vez disso, está a permitir que o grupo de gestão local tenha acesso aos alertas e informações de deteção que se encontra num grupo de gestão ligado. Desta forma, pode visualizar e interagir com todos os alertas e outros dados de monitorização de vários grupos de gestão numa única Consola de operações. Além disso, pode executar tarefas nos computadores monitorizados dos grupos de gestão ligados. Para saber como ligar grupos de gestão, veja Ligar Grupos de Gestão no Operations Manager.

Idiomas instalados

Os grupos de gestão do Operations Manager suportam apenas um idioma instalado. Se o ambiente de TI global que é necessário monitorizar tiver mais do que um idioma instalado, será necessário um grupo de gestão separado por idioma.