Este documento aborda os padrões de arquitetura para encontrar e recolher informações sobre recursos no Google Cloud, noutras plataformas na nuvem e no local através da deteção na nuvem do ServiceNow. Este documento destina-se a equipas de arquitetura ou equipas de operações na nuvem familiarizadas com a gestão de operações de TI (ITOM); a biblioteca de infraestrutura de tecnologias de informação (ITIL); Google Cloud serviços como o Compute Engine, o Google Kubernetes Engine (GKE) e o Cloud Asset Inventory; e o ServiceNow Cloud Discovery.
Vista geral
Muitas grandes empresas usam uma implementação de infraestrutura de TI híbrida que combina o Google Cloud Platform, outras plataformas na nuvem e infraestrutura no local.Google CloudNormalmente, uma implementação híbrida deste tipo é a iteração inicial numa estratégia de migração para a nuvem. Os departamentos de TI destas empresas têm de descobrir e monitorizar todos os recursos no respetivo ecossistema técnico, que podem potencialmente ser milhões. Os departamentos de TI têm de criar um sistema de gestão de configuração que associe estes recursos aos serviços técnicos que os recursos fornecem. Este sistema também tem de monitorizar os recursos e os serviços de uma forma que suporte as práticas recomendadas de gestão de operações de TI (ITOM) e gestão de serviços de TI (ITSM).
Para os Google Cloud clientes, uma arquitetura comum usa o ServiceNow cloud resource discovery para encontrar e recolher informações sobre recursos no Google Cloud, noutras plataformas na nuvem e no local. O ServiceNow oferece uma vasta gama de ferramentas para automatizar fluxos de trabalho de TI de gestão de recursos em vários fornecedores de nuvem. As ferramentas como o Cloud Operations Workspace permitem que os departamentos de TI criem painéis de controlo de recursos multicloud e façam a gestão de configurações complexas através de uma interface unificada (por vezes, denominada painel único). Este documento apresenta um conjunto de padrões de arquitetura para este cenário, uma vista geral dos respetivos componentes de alto nível e uma discussão das considerações gerais de design.
Componentes do ServiceNow para esta arquitetura
Os componentes da plataforma ServiceNow nestes padrões de arquitetura incluem o seguinte:
- Uma instância do ServiceNow que contém uma base de dados de gestão de configuração (CMDB) de itens de configuração (CIs). Cada CI representa componentes no seu ambiente operacional envolvidos na prestação de serviços digitais. Um IC tem vários atributos que contêm metadados específicos sobre o componente e as respetivas relações com outros ICs.
- Um ou mais servidores de gestão, instrumentação e deteção (MID) do ServiceNow, executados no seu Google Cloud projeto. Os servidores MID recolhem os metadados para os ICs e armazenam-nos na CMDB.
Estes padrões de arquitetura definem algumas práticas comuns para importar dados do Cloud Asset Inventory da Google para a deteção do inventário de recursos da Google Cloud Platform do ServiceNow.
Padrões de arquitetura para Google Cloud integração
Este documento aborda os seguintes padrões de arquitetura para integrar o Google Cloud no ServiceNow:
Estes padrões de arquitetura de exemplo foram concebidos para uma implementação híbrida que inclui alguma infraestrutura no local e alguma na nuvem do ServiceNow. Google Cloud Demonstram como o ServiceNow opera Google Cloud entre a infraestrutura gerida pela Google e a infraestrutura gerida pelo cliente. Os servidores MID do ServiceNow consultam toda a infraestrutura gerida pela Google chamando as APIs Google Cloud. Para mais informações sobre as APIs que são chamadas, consulte o artigo APIs da Google Cloud Platform usadas por aplicações ITOM.
Em cada um dos seguintes padrões, os componentes da arquitetura funcionam em conjunto no processo de deteção do inventário de recursos da Google Cloud Platform para recolher as informações do inventário de recursos da nuvem necessárias pela aplicação ServiceNow Discovery e pelas ferramentas relacionadas.
Google Cloud padrão de descoberta
O padrão de arquitetura de deteção na nuvem do ServiceNow básico usa servidores MID do ServiceNow para chamar o inventário de recursos do Google Cloud e outras APIs do Google Cloud para recolher dados sobre recursos, como os seguintes:
- Instâncias de VMs
- Etiquetas (chaves/valores)
- Volumes de armazenamento e mapeamento de armazenamento
- Recursos do centro de dados, incluindo tipos de hardware
- Redes na nuvem, sub-redes e gateways
- Imagens
- Balanceadores de carga na nuvem e zonas de disponibilidade
- Bases de dados e clusters de bases de dados na nuvem
- Contentores (GKE)
- Mapeamento de serviços com base em etiquetas de recursos
Neste padrão, os servidores MID não precisam de credenciais, porque não iniciam sessão nas VMs para recolher dados. Isto limita a capacidade do processo de descoberta de recolher informações adicionais. No entanto, impõe um custo operacional inferior, porque remove a necessidade de gerir e alternar as credenciais do servidor MID.
O diagrama seguinte ilustra este padrão de arquitetura.
A parte Google Cloud deste padrão é composta pelo seguinte:
- Um Google Cloud projeto (projeto de serviço A no diagrama), que consiste em dois Google Cloud equilibradores de carga, 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 sua própria MV.
- Um segundo Google Cloud projeto (projeto de serviço B no diagrama), que consiste em servidores MID em execução nas respetivas VMs.
- Um terceiro Google Cloud projeto (projeto anfitrião C no diagrama), que consiste na interligação de parceiros.
- Serviços geridos adicionais, como as APIs Google Cloud, o BigQuery e o Cloud Storage.
- Rotas de rede configuradas a partir dos servidores MID para as APIs Google Cloud.
A parte do ServiceNow consiste na instância do ServiceNow, que captura os metadados dos servidores MID e armazena-os na CMDB.
Google Cloud Padrão de descoberta sem agente baseado no IP
Este padrão de arquitetura adiciona a deteção baseada em IP ao padrão de deteção na nuvem básico através da utilização de um trabalho em lote e de umaGoogle Cloud conta de serviço para iniciar sessão em VMs e recolher detalhes adicionais. Este padrão requer um encargo operacional maior para gerir o servidor MID do que o padrão básico, porque requer que faça a gestão e a rotação das credenciais do servidor MID. No entanto, expande o processo de deteção para além dos dados fornecidos pelo Cloud Asset Inventory para incluir dados adicionais, como os seguintes:
- Segurança e gestão de credenciais do SO
- Descoberta melhorada, como a descoberta baseada em ficheiros e a descoberta de licenças
- Detalhes do SO
- Processos em execução
- Ligações TCP
- Software instalado
Neste padrão de arquitetura, um ou mais servidores MID do ServiceNow estão localizados emGoogle Cloud, enquanto a instância do ServiceNow está alojada na plataforma na nuvem do ServiceNow. Os servidores MID estão ligados à instância do ServiceNow através da fila do canal de comunicação externo (ECC) do servidor MID (não apresentado). Esta arquitetura é apresentada no diagrama seguinte.
A parte Google Cloud deste padrão é composta pelo seguinte:
- Projeto de serviço A, que consiste em dois balanceadores de carga, uma ou mais VMs, uma instância do GKE e um ou mais servidores MID do ServiceNow. Google Cloud Cada servidor MID é executado na sua própria MV.
- O projeto de serviço B, que consiste em servidores MID que são executados nas suas próprias VMs.
- O projeto anfitrião C, que consiste na interconexão de parceiros.
- Serviços geridos adicionais, como as APIs Google Cloud, o BigQuery e o Cloud Storage.
- ServiceNow Kubernetes Discovery implementado na infraestrutura do GKE.
- Rotas de rede configuradas a partir dos servidores MID para as APIs Google Cloud.
- Contas de serviço que permitem que os servidores MID iniciem sessão em quaisquer Google Cloud MV que exijam a deteção de endereços IP sem servidor.
- Rotas de rede configuradas a partir dos servidores MID para quaisquer Google Cloud VMs que exijam a deteção de endereços IP sem servidor.
A parte do ServiceNow consiste na instância do ServiceNow, que captura os metadados dos servidores MID e armazena-os na CMDB.
Google Cloud descoberta com o padrão do coletor de clientes do agente
Este padrão de arquitetura inclui o seguinte:
- A descoberta inicial da nuvem.
- Um ou mais servidores MID.
Um agente do ServiceNow adicional, o Agent Client Collector, que instala nas suas VMs. Estes agentes estabelecem ligação diretamente aos servidores MID e retransmitem as seguintes informações adicionais ao ServiceNow:
- Descoberta baseada em push praticamente em tempo real
- Medição de software
- Visualização de CI em direto
- Automatização do fluxo de trabalho para servidores
O diagrama seguinte ilustra este padrão de arquitetura.
A parte Google Cloud deste padrão é composta pelo seguinte:
- O projeto de serviço A, que consiste em dois balanceadores de carga, uma ou mais instâncias de VM, uma instância do GKE e um ou mais servidores MID do ServiceNow. Google Cloud Cada servidor MID é executado na sua própria MV.
- O projeto de serviço B, que consiste em servidores MID em execução nas suas próprias VMs.
- O projeto anfitrião C, que consiste na interconexão de parceiros.
- ServiceNow Kubernetes Discovery implementado na infraestrutura do GKE.
- Serviços geridos adicionais, como as APIs Google Cloud, o BigQuery e o Cloud Storage.
- Rotas de rede configuradas a partir dos servidores MID para as APIs Google Cloud.
- Rotas de rede configuradas a partir dos servidores MID para VMsGoogle Cloud com agentes do ServiceNow Discovery instalados.
A parte do ServiceNow consiste no seguinte:
- A instância do ServiceNow, que capta os metadados dos servidores MID e armazena-os na CMDB.
- Agentes de deteção do ServiceNow instalados em VMs geridas pelo cliente.Google Cloud
Fluxo de trabalho de descoberta de recursos do Cloud
As secções seguintes abordam o fluxo de trabalho para a descoberta de Google Cloud recursos. Este fluxo de trabalho aplica-se a todos os três padrões de arquitetura descritos neste documento.
Instale e configure os componentes do ServiceNow
- Ative as APIs Cloud Asset Inventory.
- Instale o Agent Client Collector nas suas VMs. Para mais informações, consulte o artigo Instalação do Agent Client Collector.
- Atribua recursos para computadores que alojam os servidores MID.
- Configure regras de firewall para permitir ligações na porta 443 entre a sua instância de VM e os computadores que alojam os servidores MID.
- Configure a conetividade de rede do servidor MID.
- Instale os servidores MID.
- Configure os servidores MID para chamar as APIs Google Cloud relevantes. Certifique-se de que os servidores MID têm uma rota de rede válida para chamar as APIs Google Cloud.
Fluxo de trabalho
- O Cloud Asset Inventory compila uma base de dados de todos os tipos de recursos suportados no Google Cloud ambiente. O ServiceNow usa o Cloud Asset Inventory como a origem para obter informações adicionais para atualizar a CMDB.
- Os servidores MID do ServiceNow consultam a base de dados do Cloud Asset Inventory para obter informações sobre todos os recursos no ambiente Google Cloud .
- Os servidores MID armazenam as informações dos recursos na nuvem num contentor do Cloud Storage.
- Não é possível obter todas as informações necessárias a partir da base de dados do Cloud Asset Inventory. No padrão sem agente, as informações da VM não incluem a versão de patch do SO atual. Para este nível de detalhe, os servidores MID realizam uma
deteção detalhada
fazendo o seguinte:
- Os servidores MID criam uma tarefa em lote com base nos endereços IP das VMs que requerem uma deteção detalhada.
- Na tarefa em lote, os servidores MID iniciam sessão em cada VM e consultam o SO para obter informações sobre a versão do patch e outras informações.
- Se os coletores de clientes de agentes estiverem instalados, os dados que capturam são transmitidos diretamente para os servidores MID, em vez de serem armazenados na base de dados do Cloud Asset Inventory. Para mais informações, consulte os artigos Preparação de rede e Configuração do servidor MID.
- Após a recolha dos dados de deteção de recursos, os servidores MID armazenam-nos na CMDB da seguinte forma:
- Os servidores MID criam CIs na CMDB para representar a capacidade operacional fornecida por cada recurso.
- Os servidores MID descobrem automaticamente etiquetas de Google Cloud e armazenam-nas na CMDB. Estas etiquetas são mapeadas automaticamente para as CIs e são úteis para criar mapas de serviços.
O processo de fluxo de trabalho deve ser repetido periodicamente, conforme necessário. Consoante a escala e a configuração da sua implementação, pode optar pela descoberta baseada em eventos ou baseada em agendamento. Para mais informações, consulte "Gerir o ciclo de vida da CI" no artigo Orientações de design da CMDB.
Considerações de design
As secções seguintes fornecem orientações de design para implementar qualquer um dos padrões de arquitetura descritos neste documento.
Localização da instância do ServiceNow
Para a maioria dos exemplos de utilização, recomendamos a implementação dos servidores MID em Google Cloud. Desta forma, as instâncias estão perto dos recursos na nuvem nos quais realizam a deteção detalhada.
Os padrões de arquitetura neste documento pressupõem que a sua CMDB armazena dados de deteção para todos os seus recursos na nuvem e para todos os recursos no local, e não apenas os seus ativos do Google Cloud . A CMDB pode estar localizada na nuvem do ServiceNow, no Google Cloudou nas instalações. A decisão final sobre onde localizar a CMDB no seu ambiente depende dos seus requisitos específicos.
Decidir usar agentes do MID Server
Outra consideração de design é se deve usar agentes do servidor MID e contas de serviço. Se o seu processo de deteção precisar de recolher informações além dos metadados que o Cloud Asset Inventory fornece, tem de usar uma infraestrutura de servidor MID com contas de serviço ou, em alternativa, um servidor MID com o Agent Client Collector. Qualquer uma das abordagens pode afetar o custo de apoio técnico operacional, que tem de ter em consideração no seu design. A abordagem que deve usar depende dos dados que precisa de captar e da forma como vai usar os dados. O custo operacional da captura dos dados pode ser superior ao valor que os dados oferecem.
Suporte multirregional para servidores MID
Se a sua empresa precisar de suporte multirregional da infraestrutura do servidor MID, deve planear implementar cada servidor MID em, pelo menos, duas zonas de disponibilidade e replicá-lo noutra região.
Implicações de custos
Quando escolhe onde implementar os componentes do ServiceNow para a Google Cloud deteção de recursos, tem de considerar o custo de saída e o custo de computação.
Custo de saída
As taxas de saída são incorridas sempre que os dados saem do Google Cloud. Por este motivo, deve analisar o custo de saída para o seu exemplo de utilização para determinar a melhor opção para localizar os seus componentes do ServiceNow. Normalmente, os servidores MID que realizam a descoberta detalhada incorrem em custos de saída mais baixos se estiverem a ser executados no Google Cloud do que se forem executados noutra nuvem ou no local.Google Cloud
Custo de computação
Os componentes do ServiceNow que são executados em Google Cloud incorrem em custos de computação que deve analisar para determinar o melhor valor para a sua empresa.
Por exemplo, deve considerar o número de servidores MID que implementa em instâncias do Compute Engine.Google Cloud A implementação de mais servidores MID acelera o processo de descoberta de recursos. No entanto, fazê-lo aumenta o custo de computação, uma vez que cada servidor MID é implementado na sua própria instância de VM. Para mais informações sobre se deve implementar um ou vários servidores MID, consulte o artigo Instale vários servidores MID num único sistema.
Considerações de capacidade de apoio técnico operacional
A sua implementação inclui provavelmente controlos de segurança de rede, como firewalls, sistemas de proteção contra intrusões, sistemas de deteção de intrusões e infraestrutura de replicação de pacotes. Se existirem controlos de segurança de rede extensos entre o Google Cloud e o ambiente onde os servidores MID estão implementados, estes controlos podem criar problemas de capacidade de suporte operacional. Para evitar estes problemas, recomendamos que aloje os servidores MID na Google Cloudou o mais próximo possível da infraestrutura Google Cloud que uma descoberta detalhada vai consultar.
Proteger servidores MID
Recomendamos as seguintes práticas de segurança para as suas instâncias do MID Server:
- Certifique-se de que os servidores MID estão isolados para ajudar a garantir que apenas os administradores fidedignos podem estabelecer ligação aos mesmos.
- Certifique-se de que os servidores MID estão protegidos contra eliminação.
- Certifique-se de que as funções do IAM são aplicadas para limitar a capacidade de alterações apenas às alterações aprovadas através de processos ITIL ou de um pipeline de CI/CD.
Proteger contas de serviço
Recomendamos as seguintes práticas de segurança para gerir contas de serviço:
- Certifique-se de que os servidores MID usam uma conta de serviço que tenha apenas as funções e as autorizações do IAM absolutamente necessárias para a deteção de recursos. Para mais informações, consulte o artigo Práticas recomendadas para trabalhar com contas de serviço.
- A autenticação do ServiceNow
requer a cópia do conteúdo de uma chave de conta de serviço para a interface do utilizador do ServiceNow.
As chaves das contas de serviço representam um risco de segurança se não forem geridas corretamente. É responsável pela segurança da chave privada e por outras operações descritas nas
Práticas recomendadas de gestão de chaves de contas de serviço.
Se não conseguir criar uma chave de conta de serviço, a criação de chaves de contas de serviço pode estar desativada para a sua organização. Para mais informações, consulte o artigo
Gerir recursos da organização seguros por predefinição.
Se adquiriu a chave da conta de serviço a partir de uma fonte externa, tem de a validar antes de a usar. Para mais informações, consulte o artigo Requisitos de segurança para credenciais de origem externa".
Estrutura de pastas e projetos
As pastas e os projetos são nós na Google Cloud hierarquia de recursos. Para suportar a deteção de recursos, a estrutura de pastas e projetos deve refletir a estrutura da sua aplicação e dos ambientes onde a aplicação está implementada. A estruturação dos seus recursos desta forma também permite que o ServiceNow mapeie os seus ativos para os serviços técnicos que fornece.
Tenha em atenção as alterações que fizer à estrutura de pastas e projetos para suportar a deteção do ServiceNow. A função principal da estrutura de pastas e projetos é suportar a faturação e o acesso à IAM. Por conseguinte, quaisquer alterações que fizer para suportar o ServiceNow devem suportar e estar alinhadas com aGoogle Cloud estrutura de faturação da sua organização. Para ver as práticas recomendadas para estruturar a hierarquia de Google Cloud organizações, pastas e projetos, consulte Hierarquia de recursos e Criar e gerir organizações.
O diagrama seguinte representa um exemplo de hierarquia Google Cloud de recursos na sua forma completa. Neste exemplo, a estrutura de pastas define a aplicação e cada projeto define um ambiente.
Etiquetagem
Etiquetas são pares de chave-valor que pode atribuir aos seus recursos na nuvem. (O ServiceNow, o AWS e o Azure referem-se às etiquetas como etiquetas.)
O ServiceNow usa as etiquetas que atribui aos seus Google Cloud recursos para identificar os seus recursos e, opcionalmente, mapeá-los para serviços. A escolha de um bom esquema de etiquetagem ajuda o ServiceNow a monitorizar a sua infraestrutura para gerar relatórios precisos e garantir a conformidade com ITOM/ITSM.
Recomendamos que use etiquetas para todos os recursos que exijam uma identificação única mais específica do que a permitida pela estrutura de pastas e projetos. Por exemplo, pode querer usar etiquetas nos seguintes casos:
- Se existirem requisitos de conformidade rigorosos para a sua aplicação, pode etiquetar todos os recursos da aplicação para que a sua organização possa identificar facilmente toda a infraestrutura no âmbito.
- Num ambiente multicloud, pode usar etiquetas para identificar o fornecedor de nuvem e a região de todos os recursos.
- Se precisar de uma visibilidade mais detalhada do que a fornecida por predefinição pelos relatórios de faturação do Google Cloud ou exportação da faturação do Cloud para o BigQuery, os dados podem ser filtrados por etiquetas.
A Google atribui automaticamente etiquetas aos recursos geridos pela Google que são executados na sua VPC. As etiquetas atribuídas pela Google têm o prefixo goog-. Os seus servidores MID não devem tentar realizar uma inspeção detalhada nestes recursos. Para mais
informações sobre etiquetas para recursos geridos pela Google, consulte
Mapeamento baseado em etiquetas
e
Etiquete recursos automaticamente com base nas notificações em tempo real do Cloud Asset Inventory.
A tabela seguinte lista as etiquetas que os serviços atribuem aos recursos que esses serviços gerem. Google Cloud
| Google Cloud serviço | Etiquetas ou prefixo de etiquetas |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
goog-gce-
|
| Dataproc |
goog-dataproc-
|
| Vertex AI Workbench |
goog-caip-notebook and goog-caip-notebook-volume
|
Para apoiar a gestão de recursos de forma eficaz, o processo de implementação da sua organização tem de criar estruturas de projetos e pastas, e atribuir etiquetas de recursos de forma consistente em toda a organização. As inconsistências na infraestrutura e na etiquetagem podem dificultar a manutenção de uma CMDB correta sem processos manuais que provavelmente não são suportados e que apresentam desafios de escalabilidade a longo prazo.
A lista seguinte sugere práticas recomendadas para tornar o processo de implementação consistente e repetível:
- Use infraestrutura como código (IaC) ou sistemas de aprovisionamento automatizados, como o Terraform, o ServiceNow ITOM ou o aprovisionamento e a governação na nuvem com o Google Cloud Deployment Manager.
- Ter um bom processo de governação em vigor para as suas etiquetas. Para uma vista geral da gestão de etiquetagem, consulte Gestão de etiquetas na documentação do ServiceNow.
O que se segue?
- Saiba mais sobre o conetor de integração para o ServiceNow.
- Para ver práticas recomendadas adicionais para estruturar os seus recursos para o Cloud Billing, consulte o guia de organização de recursos e gestão de acesso do Cloud Billing e o guia de configuração do Cloud Insights para o Google Cloud.
- Para ver as práticas recomendadas para estruturar as autorizações da IAM da sua organização, consulte Práticas recomendadas para planear contas e organizações e Aprovisionamento e gestão na nuvem.
- Para ver as práticas recomendadas para estruturar as políticas de firewall de VPC na sua organização, consulte o artigo Políticas de firewall hierárquicas.
- Saiba como usar etiquetas para suportar a descoberta baseada em etiquetas do ServiceNow.
- Saiba mais sobre o ServiceNow Agent Client Collector, um mecanismo de envio que é executado no seu Google Cloud projeto e envia dados de saída para a instância do ServiceNow através do MID Server, armazenando eventos e métricas na base de dados relevante.
- Para ver mais arquiteturas de referência, diagramas e práticas recomendadas, explore o Centro de arquitetura na nuvem.