Arquitetura de referência: gerenciamento de recursos com o ServiceNow

Last reviewed 2024-01-30 UTC

Neste documento, falamos sobre padrões de arquitetura para encontrar e coletar informações sobre recursos no Google Cloud, em outras plataformas de nuvem e no local usando a descoberta de nuvem do ServiceNow. Este documento é destinado a equipes de arquitetura ou operações de nuvem que estejam familiarizadas com o gerenciamento de operações de TI (ITOM, na sigla em inglês). Biblioteca de infraestrutura de tecnologia da informação (ITIL, na sigla em inglês) Serviços do Google Cloud, como o Compute Engine, o Google Kubernetes Engine (GKE) e o Inventário de recursos do Cloud e Cloud Service Discovery.

Visão geral

Muitas empresas grandes usam uma implantação de infraestrutura de TI híbrida que combina o Google Cloud, outras plataformas de nuvem e infraestrutura local. Essa implantação híbrida costuma ser a iteração inicial de uma estratégia de migração para a nuvem. Os departamentos de TI dessas empresas precisam descobrir e acompanhar todos os recursos no ecossistema técnico, que podem totalizar em milhões. Os departamentos de TI precisam criar um sistema de gerenciamento de configuração que vincule esses recursos aos serviços técnicos que eles oferecem. Esse sistema também precisa monitorar os recursos e serviços de maneira compatível com as práticas recomendadas de gerenciamento de operações de TI (ITOM, na sigla em inglês) e de gerenciamento de serviços de TI (ITSM, na sigla em inglês).

Para clientes do Google Cloud, uma arquitetura comum usa a descoberta de recursos da nuvem do ServiceNow para encontrar e coletar informações sobre recursos no Google Cloud, em outras plataformas de nuvem e no local. O ServiceNow oferece uma ampla variedade de ferramentas para automatizar fluxos de trabalho de TI de gerenciamento de recursos em vários provedores de nuvem. Ferramentas como o Espaço de trabalho de Operações do Cloud permitem que os departamentos de TI criem painéis de recursos multicloud e gerenciem configurações complexas por meio de uma interface unificada (às vezes chamada depainel único. Neste documento, apresentamos um conjunto de padrões de arquitetura para esse cenário, uma visão geral dos componentes de alto nível e uma discussão sobre considerações gerais de design.

Componentes do ServiceNow para essa arquitetura

Os componentes da plataforma ServiceNow nesses padrões de arquitetura incluem:

Esses padrões de arquitetura definem algumas práticas comuns para importar dados do Inventário de recursos do Cloud para a descoberta de inventário de recursos do Google Cloud Platform do ServiceNow.

Padrões de arquitetura para integração do Google Cloud

Neste documento, falamos sobre os seguintes padrões de arquitetura para integrar o Google Cloud ao ServiceNow:

Esses exemplos de padrões de arquitetura são projetados para uma implantação híbrida que inclui alguma infraestrutura no Google Cloud e algumas na nuvem ServiceNow. Eles demonstram como o ServiceNow opera no Google Cloud entre a infraestrutura gerenciada pelo Google e a gerenciada pelo cliente. Os servidores MID do ServiceNow consultam toda a infraestrutura gerenciada pelo Google chamando as APIs do Cloud. Para mais informações sobre quais APIs são chamadas, consulte APIs do Google Cloud Platform usadas por aplicativos ITOM.

Em cada um dos padrões a seguir, os componentes de arquitetura funcionam juntos nos Processo de descoberta de inventário de recursos do Google Cloud Platform para coletar as informações de inventário de recursos em nuvem exigidas pelo aplicativo ServiceNow e ferramentas relacionadas.

Padrão de descoberta do Google Cloud

O padrão da arquitetura de descoberta de nuvem do ServiceNow usa os servidores MID do ServiceNow para chamar o Inventário de recursos do Google Cloud e outras APIs do Google Cloud a fim de coletar dados sobre recursos como estes:

  • Instâncias de VM
  • Tags (chaves/valores)
  • Volumes de armazenamento e mapeamento de armazenamento
  • Recursos de data center, incluindo tipos de hardware
  • Redes de nuvem, sub-redes e gateways
  • Imagens
  • Balanceadores de carga e zonas de disponibilidade do Cloud
  • Bancos de dados e clusters de nuvem
  • Contêineres (GKE)
  • Mapeamento de serviço com base em rótulos de recursos

Nesse padrão, os servidores do MID não precisam de credenciais porque não fazem login nas VMs para coletar dados. Isso limita a capacidade do processo de descoberta de coletar mais informações. Mas isso impõe menos custo operacional, porque elimina a necessidade de gerenciar e alternar as credenciais do servidor MID.

O diagrama a seguir ilustra esse padrão de arquitetura.

Diagrama que mostra o padrão de arquitetura de descoberta do Google Cloud.

A parte do Google Cloud desse padrão consiste no seguinte:

  • Um projeto do Google Cloud (Projeto de serviço A no diagrama), que consiste em dois balanceadores de carga do Google Cloud, uma ou mais instâncias de VM, uma instância do GKE e um ou mais servidores MID do ServiceNow. Cada servidor MID é executado na própria VM.
  • Um segundo projeto do Google Cloud (Projeto de serviço B no diagrama), que consiste em servidores MID em execução nas próprias VMs.
  • Um terceiro projeto do Google Cloud (Projeto host C no diagrama), que consiste na interconexão por parceiro.
  • Serviços gerenciados adicionais, como APIs do Cloud, BigQuery e Cloud Storage.
  • Rotas de rede configuradas dos servidores do MID para as APIs do Google Cloud.

A parte ServiceNow consiste na instância ServiceNow, que captura os metadados dos servidores MID e os armazena no CMDB.

Padrão de descoberta com base em IP sem agente do Google Cloud

Esse padrão de arquitetura adiciona a descoberta baseada em IP ao padrão básico de nuvem usando um job em lote e uma conta de serviço do Google Cloud para fazer login nas VMs e coletar mais detalhes. Esse padrão requer uma carga operacional maior para gerenciar o servidor MID do que com o padrão básico, porque exige que você gerencie e alterne as credenciais do servidor MID. No entanto, ele expande o processo de descoberta além dos dados fornecidos pelo Inventário de recursos do Cloud para incluir outros dados, como os seguintes:

  • Gerenciamento e segurança de credenciais do SO
  • Descoberta aprimorada, como descoberta baseada em arquivos e descoberta de licenças
  • detalhes do SO
  • Processos em execução
  • Conexões TCP
  • Software instalado

Nesse padrão de arquitetura, um ou mais servidores MID do ServiceNow estão localizados no Google Cloud, enquanto a instância do ServiceNow está hospedada na plataforma de nuvem do ServiceNow. Os servidores MID estão conectados à instância ServiceNow pela fila de canais de comunicação externa (ECC, na sigla em inglês) do servidor MID (não mostrados). Veja essa arquitetura no diagrama a seguir.

Diagrama que mostra o padrão de descoberta baseado em IP sem agente do Google Cloud.

A parte do Google Cloud desse padrão consiste no seguinte:

  • Projeto de serviço A, que consiste em dois balanceadores de carga do Google Cloud, uma ou mais VMs, uma instância do GKE e um ou mais servidores MID do ServiceNow. Cada servidor MID é executado na própria VM.
  • Projeto de serviço B, que consiste em servidores MID que são executados nas próprias VMs.
  • Projeto host C, que consiste na interconexão por parceiro.
  • Serviços gerenciados adicionais, como APIs do Cloud, BigQuery e Cloud Storage.
  • ServiceNow Kubernetes Discovery implantado na infraestrutura do GKE.
  • Rotas de rede configuradas dos servidores do MID para as APIs do Google Cloud.
  • Contas de serviço que permitem que os servidores MID façam login em qualquer VM do Google Cloud que exija a descoberta de endereços IP sem servidor.
  • Rotas de rede configuradas a partir de servidores MID para qualquer VM do Google Cloud que exigem descoberta de endereços IP sem servidor.

A parte ServiceNow consiste na instância ServiceNow, que captura os metadados dos servidores MID e os armazena no CMDB.

Descoberta do Google Cloud com o padrão do coletor do cliente do agente

Esse padrão de arquitetura inclui o seguinte:

  • A descoberta da nuvem inicial.
  • Um ou mais servidores MID.
  • Outro agente do ServiceNow, o coletor de cliente do agente, que você instala nas VMs. Esses agentes se conectam diretamente aos servidores MID e transmitem as seguintes informações extras ao ServiceNow:

    • Descoberta quase em tempo real com base em push
    • Medição de software
    • Visualização de CI em tempo real
    • Automação do fluxo de trabalho para servidores

O diagrama a seguir ilustra esse padrão de arquitetura.

Diagrama que mostra a descoberta do Google Cloud com o padrão do coletor do cliente do agente.

A parte do Google Cloud desse padrão consiste no seguinte:

  • Projeto de serviço A, que consiste em dois balanceadores de carga do Google Cloud, uma ou mais instâncias de VM, uma instância do GKE e um ou mais servidores MID do ServiceNow. Cada servidor MID é executado na própria VM.
  • Projeto de serviço B, que consiste em servidores MID em execução nas próprias VMs.
  • Projeto host C, que consiste na interconexão por parceiro.
  • ServiceNow Kubernetes Discovery implantado na infraestrutura do GKE.
  • Serviços gerenciados adicionais, como APIs do Cloud, BigQuery e Cloud Storage.
  • Rotas de rede configuradas dos servidores do MID para as APIs do Google Cloud.
  • Rotas de rede configuradas dos servidores do MID para as VMs do Google Cloud que têm os agentes de descoberta do ServiceNow instalados.

A parte ServiceNow consiste no seguinte:

  • A instância ServiceNow, que captura os metadados dos servidores MID e os armazena no CMDB.
  • Agentes de descoberta ServiceNow que são instalados em VMs do Google Cloud gerenciadas pelo cliente.

Fluxo de trabalho de descoberta de recursos do Cloud

As seções a seguir discutem o fluxo de trabalho para a descoberta de recursos do Google Cloud. Esse fluxo de trabalho se aplica aos três padrões de arquitetura descritos neste documento.

Instalar e configurar os componentes do ServiceNow

  1. Ativar as APIs do Inventário de recursos do Cloud.
  2. Instale o coletor de clientes do agente nas VMs. Para mais informações, consulte Instalação do coletor do cliente do agente.
  3. Aloque recursos para computadores que hospedam os servidores MID
  4. Configure regras de firewall para permitir conexões na porta 443 entre a instância de VM e os computadores que hospedam os servidores MID.
  5. Configure a conectividade de rede do servidor MID.
  6. Instale os servidores de MID.
  7. Configure os servidores de MID para chamar as APIs relevantes do Google Cloud. Verifique se os servidores de MID têm uma rota de rede válida para chamar APIs do Google Cloud.

Fluxo de trabalho

  1. O Inventário de recursos do Cloud compila um banco de dados de todos os tipos de recursos compatíveis no ambiente do Google Cloud. O ServiceNow usa o Inventário de recursos do Cloud como a origem para recuperar mais informações e atualizar o CMDB.
  2. Os servidores de MID do ServiceNow consultam o banco de dados do Cloud Asset Inventory para informações sobre todos os recursos no ambiente do Google Cloud.
  3. Os servidores MID armazenam as informações dos recursos da nuvem em um bucket do Cloud Storage.
  4. Nem todas as informações necessárias podem ser extraídas do banco de dados do Inventário de recursos do Cloud. No padrão sem agente, as informações da VM não incluem a versão atual do patch do SO. Para esse nível de detalhe, os servidores MID realizam uma descoberta profunda fazendo o seguinte:
    1. Os servidores MID criam um job em lote com base nos endereços IP das VMs que exigem uma descoberta profunda.
    2. No job em lote, os servidores MID fazem login em cada VM e consultam o SO para o controle de versões de patch e outras informações.
  5. Se os Coletores de clientes do agente estiverem instalados, os dados capturados vão ser transmitidos para os servidores MID diretamente em vez de armazenados no banco de dados do Inventário de recursos do Cloud. Para saber mais, consulte Preparação da rede e Configuração do servidor MID.
  6. Depois de coletar os dados de descoberta de recursos, os servidores de MID os armazenam no CMDB da seguinte maneira:
    1. Os servidores MID criam CIs no CMDB para representar a capacidade operacional fornecida por cada recurso.
    2. Os servidores MID descobrem automaticamente os rótulos do Google Cloud e os armazenam no CMDB. Esses rótulos são mapeados automaticamente para as CIs e são úteis para criar mapas de serviços.

O processo do fluxo de trabalho precisa ser repetido periodicamente, conforme necessário. Dependendo da escala e da configuração da implantação, é possível escolher a descoberta com base em eventos ou em programações. Para mais informações, consulte "Como gerenciar o ciclo de vida de CI" em Orientação de design do CMDB.

Considerações sobre o design

Nas seções a seguir, fornecemos orientações de design para implementar qualquer um dos padrões de arquitetura descritos neste documento.

Local da instância ServiceNow

Na maioria dos casos de uso, recomendamos a implantação de servidores MID no Google Cloud. Assim, as instâncias estão próximas dos recursos da nuvem em que são executadas.

Os padrões de arquitetura neste documento pressupõem que o CMDB armazena dados de descoberta para todos os seus recursos de nuvem e para todos os recursos locais, não apenas os recursos do Google Cloud. O CMDB pode estar localizado na nuvem do ServiceNow, no Google Cloud ou no local. A decisão final sobre onde localizar o CMDB no seu ambiente depende dos seus requisitos específicos.

Decidir usar agentes do servidor MID

Outra consideração de design é se os agentes do servidor MID e as contas de serviço serão usados. Se o processo de descoberta precisar coletar informações além dos metadados fornecidos pelo Inventário de recursos do Cloud, use uma infraestrutura de servidor MID com contas de serviço ou, como alternativa, um servidor MID comColetor de clientes do agente. Qualquer uma dessas abordagens pode afetar o custo de suporte operacional, que você precisa considerar no seu design. A abordagem a ser usada depende de quais dados você precisa capturar e de como eles serão usados. O custo operacional da captura de dados pode superar o valor fornecido por eles.

Suporte multirregional a servidores MID

Se a sua empresa requer suporte multirregional à infraestrutura do servidor MID, planeje a implantação de cada servidor MID em pelo menos duas zonas de disponibilidade e replicando-as em outra região.

Implicações no custo

Ao escolher onde implantar os componentes do ServiceNow na descoberta de recursos do Google Cloud, você precisa considerar o custo de saída e o custo de computação.

Custo de saída

As cobranças de saída são geradas sempre que os dados saem do Google Cloud. Por isso, analise o custo de saída do seu caso de uso para determinar a melhor opção para localizar os componentes do ServiceNow. Normalmente, os servidores de MID que executam uma descoberta profunda geram custos de saída menores se estiverem em execução no Google Cloud do que em outra nuvem ou no local.

Custo do Compute

Os componentes do ServiceNow que são executados no Google Cloud geram custos de computação que você precisa analisar para determinar o melhor valor para sua empresa.

Por exemplo, considere o número de servidores MID que você implanta nas instâncias do Google Cloud Compute Engine. A implantação de mais servidores MID torna o processo de descoberta de recursos mais rápido. No entanto, isso aumenta o custo de computação, porque cada servidor MID é implantado na própria instância de VM. Para saber mais sobre se é necessário implantar um ou vários servidores de MID, consulte Instalar vários servidores de MID em um único sistema.

Considerações sobre suporte operacional

Sua implantação provavelmente inclui controles de segurança de rede, como firewalls, sistemas de proteção contra intrusões, sistemas de detecção de intrusões e infraestrutura de espelhamento de pacotes. Se houver amplos controles de segurança de rede em vigor entre o Google Cloud e o ambiente em que os servidores MID estão implantados, esses controles poderão criar problemas de suporte operacional. Para evitar esses problemas, recomendamos que você hospede os servidores de MID no Google Cloud ou o mais próximo possível da infraestrutura do Google Cloud que será consultada por uma análise detalhada.

Como proteger servidores MID

Recomendamos as seguintes práticas de segurança para suas instâncias do servidor MID:

Como proteger contas de serviço

Recomendamos as seguintes práticas de segurança para gerenciar contas de serviço:

Estrutura de pastas e projetos

Pastas e projetos são nós na hierarquia de recursos do Google Cloud. Para oferecer suporte à descoberta de recursos, a estrutura de pastas e projetos precisa refletir a estrutura do aplicativo e dos ambientes em que ele está implantado. Estruturar seus recursos dessa maneira também possibilita que o ServiceNow mapeie seus recursos para os serviços técnicos que eles fornecem.

Esteja atento a qualquer mudança feita na pasta e na estrutura do projeto para oferecer suporte à descoberta do ServiceNow. O papel principal da estrutura de pastas e projetos é oferecer suporte ao faturamento e ao acesso do IAM. Portanto, todas as alterações feitas para oferecer suporte ao ServiceNow precisam ser compatíveis e se alinhar à estrutura de faturamento do Google Cloud da sua organização. Veja as práticas recomendadas para estruturar a organização, a pasta e a hierarquia de projetos do Google Cloud em Hierarquia de recursos e Como criar e gerenciar organizações.

O diagrama a seguir representa um exemplo da hierarquia de recursos do Google Cloud na forma completa. Neste exemplo, a estrutura de pastas define o aplicativo, e cada projeto define um ambiente.

Diagrama que mostra um exemplo de hierarquia de recursos
do Google Cloud.

Rotulação

Rótulos são pares de chave-valor que podem ser atribuídos aos recursos da nuvem. (ServiceNow, AWS e Azure se referem a rótulos como tags.)

O ServiceNow usa os rótulos atribuídos aos recursos do Google Cloud para identificar seus recursos e, opcionalmente, mapeá-los para serviços. Escolher um bom esquema de rotulagem ajuda o ServiceNow a monitorar a infraestrutura para gerar relatórios precisos e conformidade com ITOM/ITSM.

Recomendamos que você use rótulos para todos os recursos que exigem identificação exclusiva que é mais específica do que a estrutura de pasta e projeto permite. Por exemplo, você pode querer usar rótulos nos seguintes casos:

  • Se houver requisitos rigorosos de conformidade para o aplicativo, é possível rotular todos os recursos dele para que a organização possa identificar facilmente toda a infraestrutura que está no escopo.
  • Em um ambiente de várias nuvens, é possível usar rótulos para identificar o provedor de nuvem e a região de todos os recursos.
  • Se você precisar de uma visibilidade mais detalhada do que a fornecida por padrão nos relatórios do Google Cloud Billing ou na exportação do Cloud Billing para o BigQuery, os dados podem ser filtrados por rótulos.

O Google atribui automaticamente rótulos a recursos gerenciados pelo Google que são executados na sua VPC. Os rótulos atribuídos pelo Google são prefixados com goog-. Os servidores MID não podem tentar realizar uma inspeção profunda nesses recursos. Para mais informações sobre rótulos para recursos gerenciados pelo Google, consulte Mapeamento com base em tags e Aplicar marcadores automaticamente com base nas notificações em tempo real do Inventário de recursos do Cloud

A tabela a seguir lista os rótulos que os serviços do Google Cloud atribuem aos recursos que eles gerenciam.

Serviço do Google Cloud Rótulos ou prefixo de rótulo
Google Kubernetes Engine goog-gke-
Compute Engine

goog-gce-

Dataproc

goog-dataproc-

Vertex AI Workbench

goog-caip-notebook and goog-caip-notebook-volume

Para oferecer suporte ao gerenciamento de recursos de maneira eficaz, o processo de implantação da organização precisa criar estruturas de projetos e pastas e atribuir rótulos de recursos de modo consistente em toda a organização. Inconsistências na infraestrutura e na rotulagem podem dificultar a manutenção de um CMDB correto sem processos manuais que provavelmente não serão compatíveis e apresentarem desafios de escalonamento a longo prazo.

Veja na lista a seguir as práticas recomendadas para tornar o processo de implantação consistente e repetível:

A seguir