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 Espaço de trabalho de operações do Cloud permite que os departamentos de TI criem painéis de recursos de várias nuvens 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:
- Uma instância do ServiceNow que contém um banco de dados de gerenciamento de configuração (CMDB, na sigla em inglês) de itens de configuração (CIs). Cada CI representa componentes no seu ambiente operacional envolvidos na entrega de serviços digitais. Uma CI tem vários atributos que contêm metadados específicos sobre o componente e os relacionamentos com outras CIs.
- um ou mais servidores ServiceManager, Instrumentation e Discovery (MID, na sigla em inglês) em execução no projeto do Google Cloud. Os servidores MID coletam os metadados de CIs e os armazenam no CMDB.
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 (em inglês) 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.
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.
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.
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
- Ativar as APIs do Inventário de recursos do Cloud.
- Instale o coletor de clientes do agente nas VMs. Para mais informações, consulte Instalação do coletor do cliente do agente.
- Aloque recursos para computadores que hospedam os servidores MID
- 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.
- Configure a conectividade de rede do servidor MID.
- Instale os servidores de MID.
- 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
- 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.
- 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.
- Os servidores MID armazenam as informações dos recursos da nuvem em um bucket do Cloud Storage.
- 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:
- Os servidores MID criam um job em lote com base nos endereços IP das VMs que exigem uma descoberta profunda.
- 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.
- 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.
- Depois de coletar os dados de descoberta de recursos, os servidores de MID os armazenam no CMDB da seguinte maneira:
- Os servidores MID criam CIs no CMDB para representar a capacidade operacional fornecida por cada recurso.
- 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:
- Verifique se os servidores de MID estão isolados para garantir que apenas os administradores confiáveis possam se conectar a eles.
- Verifique se os servidores MID estão protegidos contra exclusão.
- Verifique se os papéis do IAM foram aplicados para limitar a capacidade de realizar mudanças apenas às mudanças aprovadas por processos ITIL ou pipeline de CI/CD.
Como proteger contas de serviço
Recomendamos as seguintes práticas de segurança para gerenciar contas de serviço:
- Se você estiver hospedando seus servidores MID no Google Cloud, a autenticação será processada automaticamente usando a conta de serviço associada. Se você hospeda seus servidores MID fora do Google Cloud, você é responsável por gerar uma chave de conta de serviço gerenciada pelo usuário para autenticar, proteger e auditar essa credencial persistente. Para mais informações, consulte Práticas recomendadas para gerenciar chaves de conta de serviço.
- Verifique se os servidores de MID usam uma conta de serviço com apenas os papéis e as permissões do IAM que são absolutamente necessários para a descoberta de recursos. Para mais informações, consulte Práticas recomendadas para trabalhar com 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. (em inglês).
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.
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 |
|
| Dataproc |
|
| Vertex AI Workbench |
|
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:
- Use infraestrutura como código (IaC) ou sistemas de provisionamento automatizados, como Terraform, ServiceNow ITOM ou Provisionamento e governança do Cloud com o Google Cloud Deployment Manager.
- Tenha um bom processo de governança para seus marcadores. Para ter uma visão geral da governança de rótulos, consulte Governança de tags na documentação do ServiceNow.
A seguir
- Para mais práticas recomendadas de estruturação de recursos do Cloud Billing, consulte o Guia para organização e gerenciamento de acesso do Cloud Billing Resource e o Guia de configuração do Cloud Insights para Google Cloud
- Para conferir as práticas recomendadas de estruturação de permissões do IAM da sua organização, consulte Práticas recomendadas para planejar contas e organizações e Provisionamento e governança do Cloud.
- Veja as práticas recomendadas para estruturar as políticas de firewall da VPC em toda a organização em Políticas hierárquicas de firewall.
- Saiba como usar rótulos para oferecer compatibilidade com a descoberta baseada em tags do ServiceNow.
- Saiba mais sobre o Coletor de cliente do agente do ServiceNow, um mecanismo push que é executado no projeto do Google Cloud e envia dados de saída para a instância do ServiceNow pelo servidor MID, armazenar eventos e métricas no banco de dados relevante.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.