Architettura di riferimento: gestione delle risorse con ServiceNow

Last reviewed 2025-05-08 UTC

Questo documento descrive i pattern di architettura per trovare e raccogliere informazioni sugli asset in Google Cloud, in altre piattaforme cloud e on-premise utilizzando ServiceNow Cloud Discovery. Il documento è destinato ai team di architettura o alle operazioni cloud che hanno familiarità con la gestione delle operazioni IT (ITOM), con la libreria dell'infrastruttura IT (ITIL), Google Cloud con servizi come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Asset Inventory e con ServiceNow Cloud Discovery.

Panoramica

Molte grandi aziende utilizzano un deployment di infrastruttura IT ibrida che combina Google Cloud, altre piattaforme cloud e infrastruttura on-premise. Un deployment ibrido di questo tipo è in genere l'iterazione iniziale di una strategia di migrazione al cloud. I reparti IT di queste aziende sono tenuti a scoprire e tenere traccia di tutti gli asset nel loro ecosistema tecnico, che possono potenzialmente contare milioni di elementi. I reparti IT devono creare un sistema di gestione della configurazione che colleghi queste risorse ai servizi tecnici che forniscono. Questo sistema deve anche monitorare gli asset e i servizi in modo da supportare le best practice di gestione delle operazioni IT (ITOM) e di gestione dei servizi IT (ITSM).

Per i clienti Google Cloud , un'architettura comune utilizza il rilevamento delle risorse cloud di ServiceNow per trovare e raccogliere informazioni sugli asset in Google Cloud, in altre piattaforme cloud e on-premise. ServiceNow offre un'ampia gamma di strumenti per automatizzare i flussi di lavoro IT di gestione delle risorse su più cloud provider. Strumenti come Cloud Operations Workspace consentono ai reparti IT di creare dashboard delle risorse multicloud e gestire configurazioni complesse tramite un'interfaccia unificata (a volte chiamata single pane of glass). Questo documento presenta un insieme di pattern di architettura per questo scenario, una panoramica dei suoi componenti di alto livello e una discussione sulle considerazioni generali di progettazione.

Componenti ServiceNow per questa architettura

I componenti della piattaforma ServiceNow in questi pattern di architettura includono i seguenti:

Questi pattern di architettura definiscono alcune pratiche comuni per l'importazione dei dati di Cloud Asset Inventory di Google nell'inventario delle risorse di Google Cloud Platform di ServiceNow.

Pattern di architettura per l'integrazione di Google Cloud

Questo documento descrive i seguenti pattern di architettura per l'integrazione di Google Cloud in ServiceNow:

Questi pattern di architettura di esempio sono progettati per un deployment ibrido che include parte dell'infrastruttura in Google Cloud e parte nel cloud ServiceNow. Mostrano come opera ServiceNow Google Cloud tra l'infrastruttura gestita da Google e quella gestita dal cliente. I server MID di ServiceNow eseguono query su tutta l'infrastruttura gestita da Google chiamando le API Cloud di Google. Per saperne di più sulle API chiamate, consulta API Google Cloud utilizzate dalle applicazioni ITOM.

In ciascuno dei seguenti pattern, i componenti dell'architettura collaborano nel processo di rilevamento dell'inventario degli asset di Google Cloud Platform per raccogliere le informazioni sull'inventario degli asset cloud richieste dall'applicazione ServiceNow Discovery e dagli strumenti correlati.

Google Cloud discovery pattern

Il pattern di architettura di base per l'individuazione del cloud ServiceNow utilizza i server MID di ServiceNow per chiamare Google Cloud Asset Inventory e altre API Google Cloud per raccogliere dati sulle risorse, ad esempio:

  • Istanze VM
  • Tag (chiavi/valori)
  • Volumi di archiviazione e mapping dell'archiviazione
  • Risorse del data center, inclusi i tipi di hardware
  • Reti, subnet e gateway cloud
  • Immagini
  • Bilanciatori del carico Cloud e zone di disponibilità
  • Database cloud e cluster di database
  • Container (GKE)
  • Mappatura dei servizi basata sulle etichette delle risorse

In questo pattern, i MID Server non richiedono credenziali, perché non accedono alle VM per raccogliere dati. Ciò limita la capacità del processo di rilevamento di raccogliere ulteriori informazioni. ma impone costi operativi inferiori, perché elimina la necessità di gestire e ruotare le credenziali del MID Server.

Il seguente diagramma illustra questo pattern di architettura.

Diagramma che mostra il pattern dell'architettura di rilevamento Google Cloud .

La parte Google Cloud di questo pattern è costituita da quanto segue:

  • Un Google Cloud progetto (il progetto di servizio A nel diagramma), che consiste in due Google Cloud bilanciatori del carico, una o più istanze VM, un'istanza GKE e uno o più server MID ServiceNow. Ogni MID Server viene eseguito nella propria VM.
  • Un secondo progetto Google Cloud (Service Project B nel diagramma), che consiste in MID Server in esecuzione nelle proprie VM.
  • Un terzo progetto Google Cloud (progetto host C nel diagramma), che consiste nell'interconnessione partner.
  • Servizi gestiti aggiuntivi, come le API Cloud, BigQuery e Cloud Storage.
  • Route di rete configurate dai server MID alle API Google Cloud.

La parte ServiceNow è costituita dall'istanza ServiceNow, che acquisisce i metadati dai MID Server e li archivia nel CMDB.

Google Cloud Pattern di rilevamento senza agenti basato sull'IP

Questo pattern di architettura aggiunge il rilevamento basato su IP al pattern di rilevamento cloud di base utilizzando un job batch e un Google Cloud service account per accedere alle VM e raccogliere ulteriori dettagli. Questo pattern richiede un carico operativo maggiore per gestire il MID Server rispetto al pattern di base, perché richiede di gestire e ruotare le credenziali del MID Server. Tuttavia, espande il processo di rilevamento oltre i dati forniti da Cloud Asset Inventory per includere dati aggiuntivi, ad esempio:

  • Gestione e sicurezza delle credenziali del sistema operativo
  • Rilevamento avanzato, ad esempio rilevamento basato su file e rilevamento delle licenze
  • Dettagli del sistema operativo:
  • Processi in esecuzione
  • Connessioni TCP
  • Software installato

In questo pattern di architettura, uno o più ServiceNow MID Server si trovano in Google Cloud, mentre l'istanza ServiceNow è ospitata nella piattaforma cloud ServiceNow. I server MID sono connessi all'istanza ServiceNow tramite la coda del canale di comunicazione esterno (ECC) del server MID (non mostrata). Questa architettura è illustrata nel seguente diagramma.

Diagramma che mostra il pattern di rilevamento senza agente basato su IP Google Cloud .

La parte Google Cloud di questo pattern è costituita da quanto segue:

  • Il progetto di servizio A, che consiste in due bilanciatori del carico, una o più VM, un'istanza GKE e uno o più server MID ServiceNow. Google Cloud Ogni MID Server viene eseguito nella propria VM.
  • Il progetto di servizio B, che è costituito da MID Server eseguiti nelle proprie VM.
  • Progetto host C, che consiste nell'interconnessione partner.
  • Servizi gestiti aggiuntivi, come le API Cloud, BigQuery e Cloud Storage.
  • ServiceNow Kubernetes Discovery di cui è stato eseguito il deployment nell'infrastruttura GKE.
  • Route di rete configurate dai server MID alle API Google Cloud.
  • Service account che consentono ai MID Server di accedere a qualsiasi VMGoogle Cloud che richiede il rilevamento dell'indirizzo IP serverless.
  • Route di rete configurate dai server MID a qualsiasi VMGoogle Cloud che richiede il rilevamento dell'indirizzo IP serverless.

La parte ServiceNow è costituita dall'istanza ServiceNow, che acquisisce i metadati dai MID Server e li archivia nel CMDB.

Google Cloud discovery con pattern Agent Client Collector

Questo pattern di architettura include quanto segue:

  • La scoperta iniziale del cloud.
  • Uno o più MID Server.

  • Un agente ServiceNow aggiuntivo, Agent Client Collector, che devi installare sulle tue VM. Questi agenti si connettono direttamente ai server MID e trasmettono a ServiceNow le seguenti informazioni aggiuntive:

    • Rilevamento basato sul push quasi in tempo reale
    • Misurazione del software
    • Visualizzazione CI in tempo reale
    • Automazione del flusso di lavoro sui server

Il seguente diagramma illustra questo pattern di architettura.

Diagramma che mostra l'individuazione di Google Cloud con il pattern Agent Client Collector.

La parte Google Cloud di questo pattern è costituita da quanto segue:

  • Progetto di servizio A, costituito da due Google Cloud bilanciatori del carico, una o più istanze VM, un'istanza GKE e uno o più server MID ServiceNow. Ogni MID Server viene eseguito nella propria VM.
  • Il progetto di servizio B, che consiste in MID Server in esecuzione nelle proprie VM.
  • Progetto host C, che consiste nell'interconnessione partner.
  • ServiceNow Kubernetes Discovery di cui è stato eseguito il deployment nell'infrastruttura GKE.
  • Servizi gestiti aggiuntivi, come le API Cloud, BigQuery e Cloud Storage.
  • Route di rete configurate dai server MID alle API Google Cloud.
  • Route di rete configurate dai server MID alle VMGoogle Cloud su cui sono installati gli agenti ServiceNow Discovery.

La parte di ServiceNow è costituita da:

  • L'istanza ServiceNow, che acquisisce i metadati dai server MID e li archivia nel CMDB.
  • Agenti di rilevamento ServiceNow installati su VMGoogle Cloud gestite dal cliente.

Flusso di lavoro di rilevamento degli asset cloud

Le sezioni seguenti descrivono il flusso di lavoro per l'individuazione degli asset. Google Cloud Questo flusso di lavoro si applica a tutti e tre i pattern di architettura descritti in questo documento.

Installare e configurare i componenti ServiceNow

  1. Abilita le API Cloud Asset Inventory.
  2. Installa Agent Client Collector sulle tue VM. Per saperne di più, vedi Installazione di Agent Client Collector.
  3. Allocare risorse per i computer che ospitano i server MID.
  4. Configura le regole firewall per consentire le connessioni sulla porta 443 tra l'istanza VM e i computer che ospitano i MID Server.
  5. Configura la connettività di rete del MID Server.
  6. Installa i server MID.
  7. Configura i server MID per chiamare le API Google Cloud pertinenti. Assicurati che i server MID abbiano una route di rete valida per chiamare le API Google Cloud.

Flusso di lavoro

  1. Cloud Asset Inventory compila un database di tutti i tipi di asset supportati nell'ambiente Google Cloud . ServiceNow utilizza Cloud Asset Inventory come origine per recuperare informazioni aggiuntive per aggiornare il CMDB.
  2. I server MID ServiceNow eseguono query sul database Cloud Asset Inventory per ottenere informazioni su tutti gli asset nell'ambiente Google Cloud .
  3. I server MID archiviano le informazioni sugli asset cloud in un bucket Cloud Storage.
  4. Non tutte le informazioni richieste possono essere ottenute dal database Cloud Asset Inventory. Nel pattern senza agent, le informazioni sulla VM non includono la versione attuale della patch del sistema operativo. Per questo livello di dettaglio, i MID Server eseguono un rilevamento approfondito nel seguente modo:
    1. I server MID creano un job batch in base agli indirizzi IP delle VM che richiedono un'analisi approfondita.
    2. Nel job batch, i server MID accedono a ogni VM ed eseguono query sul sistema operativo per il controllo delle versioni delle patch e altre informazioni.
  5. Se sono installati Agent Client Collector, i dati acquisiti vengono trasmessi direttamente ai MID Server, anziché archiviati nel database Cloud Asset Inventory. Per saperne di più, consulta Preparazione della rete e Configurazione del server MID.
  6. Dopo aver raccolto i dati di rilevamento degli asset, i server MID li memorizzano nella CMDB nel seguente modo:
    1. I server MID creano CI nella CMDB per rappresentare la capacità operativa fornita da ogni asset.
    2. I server MID rilevano automaticamente le etichette da Google Cloud e le archiviano nel CMDB. Queste etichette vengono mappate automaticamente alle IC e sono utili per creare mappe dei servizi.

La procedura del flusso di lavoro deve essere ripetuta periodicamente in base alle necessità. A seconda della scala e della configurazione della tua implementazione, puoi scegliere il rilevamento basato sugli eventi o sulla pianificazione. Per maggiori informazioni, consulta la sezione "Managing the CI lifecycle" (Gestione del ciclo di vita delle CI) nella Guida alla progettazione di CMDB.

Considerazioni sulla progettazione

Le sezioni seguenti forniscono indicazioni di progettazione per l'implementazione di uno qualsiasi dei pattern architetturali descritti in questo documento.

Posizione dell'istanza ServiceNow

Per la maggior parte dei casi d'uso, consigliamo di eseguire il deployment dei server MID in Google Cloud. In questo modo, le istanze sono vicine agli asset cloud su cui eseguono l'analisi approfondita.

I pattern di architettura in questo documento presuppongono che la CMDB memorizzi i dati di rilevamento per tutte le risorse cloud e per tutte le risorse on-premise, non solo per gli asset Google Cloud . La CMDB può trovarsi nel cloud ServiceNow, in Google Cloudo on-premise. La decisione finale su dove posizionare il CMDB nel tuo ambiente dipende dai tuoi requisiti specifici.

Decidere di utilizzare gli agenti MID Server

Un'altra considerazione di progettazione è se utilizzare agenti e account di servizio MID Server. Se la procedura di rilevamento deve raccogliere informazioni oltre ai metadati forniti da Cloud Asset Inventory, devi utilizzare un'infrastruttura MID Server con account di servizio oppure un MID Server con Agent Client Collector. Entrambi gli approcci possono influire sul costo dell'assistenza operativa, che devi prendere in considerazione nella progettazione. L'approccio da utilizzare dipende dai dati che devi acquisire e da come li utilizzerai. Il costo operativo dell'acquisizione dei dati potrebbe superare il valore che forniscono.

Supporto multiregionale per i server MID

Se la tua azienda richiede il supporto multiregionale dell'infrastruttura MID Server, devi pianificare il deployment di ogni MID Server in almeno due zone di disponibilità e replicarlo in un'altra regione.

Implicazioni sui costi

Quando scegli dove eseguire il deployment dei componenti ServiceNow per l'individuazione degli assetGoogle Cloud , devi considerare il costo di uscita e il costo di calcolo.

Costo del traffico in uscita

I costi di uscita vengono addebitati ogni volta che i dati escono da Google Cloud. Per questo motivo, devi analizzare il costo di uscita per il tuo caso d'uso per determinare l'opzione migliore per individuare i componenti ServiceNow. In genere, i server MID che eseguono l'individuazione approfondita comportano costi di uscita inferiori se vengono eseguiti in Google Cloud rispetto a quando vengono eseguiti su un altro cloud o on-premise.

Costo calcolo

I componenti ServiceNow eseguiti in Google Cloud comportano costi di calcolo che devi analizzare per determinare il miglior valore per la tua azienda.

Ad esempio, devi considerare il numero di MID Server di cui esegui il deployment nelle istanze diGoogle Cloud Compute Engine. Il deployment di più MID Server velocizza la procedura di rilevamento degli asset. Tuttavia, in questo modo aumentano i costi di calcolo, perché ogni MID Server viene implementato nella propria istanza VM. Per ulteriori informazioni sull'opportunità di eseguire il deployment di uno o più MID Server, vedi Installare più MID Server su un singolo sistema.

Considerazioni sull'assistenza operativa

Il tuo deployment include probabilmente controlli di sicurezza della rete come firewall, sistemi di protezione dalle intrusioni, sistemi di rilevamento delle intrusioni e infrastruttura di mirroring dei pacchetti. Se sono in vigore controlli di sicurezza di rete estesi tra Google Cloud e l'ambiente in cui sono implementati i server MID, questi controlli possono creare problemi di supporto operativo. Per evitare questi problemi, ti consigliamo di ospitare i server MID in Google Cloud o il più vicino possibile all'infrastruttura Google Cloud su cui verrà eseguita una query di rilevamento approfondito.

Protezione dei server MID

Ti consigliamo le seguenti pratiche di sicurezza per le tue istanze MID Server:

Proteggere i service account

Ti consigliamo le seguenti pratiche di sicurezza per la gestione dei service account:

Struttura di cartelle e progetti

Cartelle e progetti sono nodi della Google Cloud gerarchia delle risorse. Per supportare l'individuazione degli asset, la struttura di cartelle e progetti deve riflettere la struttura dell'applicazione e degli ambienti in cui viene eseguito il deployment. La strutturazione delle risorse in questo modo consente inoltre a ServiceNow di mappare le tue risorse ai servizi tecnici che fornisce.

Presta attenzione alle modifiche apportate alla struttura di cartelle e progetti per supportare l'individuazione di ServiceNow. Il ruolo principale della struttura di cartelle e progetti è supportare la fatturazione e l'accesso IAM. Pertanto, qualsiasi modifica apportata per supportare ServiceNow deve supportare e allinearsi alla struttura di fatturazioneGoogle Cloud della tua organizzazione. Per le best practice per strutturare la gerarchia di organizzazione, cartelle e progetti, consulta Gerarchia delle risorse e Creazione e gestione delle organizzazioni.Google Cloud

Il seguente diagramma rappresenta un esempio di gerarchia di risorse Google Cloud nella sua forma completa. In questo esempio, la struttura delle cartelle definisce l'applicazione e ogni progetto definisce un ambiente.

Diagramma che mostra un esempio di gerarchia delle risorse Google Cloud .

Etichettatura

Le etichette sono coppie chiave-valore che puoi assegnare alle tue risorse cloud. (ServiceNow, AWS e Azure si riferiscono alle etichette come tag.)

ServiceNow utilizza le etichette che assegni alle tue risorse per identificarle e, facoltativamente, mapparle ai servizi. Google Cloud La scelta di un buon schema di etichettatura consente a ServiceNow di monitorare la tua infrastruttura per report accurati e conformità ITOM/ITSM.

Ti consigliamo di utilizzare le etichette per tutte le risorse che richiedono un'identificazione univoca più specifica di quella consentita dalla struttura di cartelle e progetti. Ad esempio, potresti voler utilizzare le etichette nei seguenti casi:

  • Se la tua applicazione è soggetta a requisiti di conformità rigorosi, puoi etichettare tutte le risorse dell'applicazione in modo che la tua organizzazione possa identificare facilmente tutta l'infrastruttura inclusa nell'ambito.
  • In un ambiente multicloud, puoi utilizzare le etichette per identificare il provider cloud e la regione per tutte le risorse.
  • Se hai bisogno di una visibilità più granulare di quella fornita per impostazione predefinita dai report di fatturazione Google Cloud o dall'esportazione della fatturazione Cloud in BigQuery, i dati possono essere filtrati per etichette.

Google assegna automaticamente etichette agli asset gestiti da Google eseguiti nel tuo VPC. Le etichette assegnate da Google hanno il prefisso goog-. I tuoi server MID non devono tentare di eseguire un'ispezione approfondita di questi asset. Per saperne di più sulle etichette per le risorse gestite da Google, consulta Mapping basato su tag e Etichettare automaticamente le risorse in base alle notifiche in tempo reale di Cloud Asset Inventory.

La tabella seguente elenca le etichette che i servizi Google Cloud assegnano alle risorse che gestiscono.

ServizioGoogle Cloud Etichette o prefisso etichetta
Google Kubernetes Engine goog-gke-
Compute Engine goog-gce-
Dataproc goog-dataproc-
Vertex AI Workbench goog-caip-notebook and goog-caip-notebook-volume

Per supportare la gestione delle risorse in modo efficace, il processo di deployment della tua organizzazione deve creare strutture di progetti e cartelle e assegnare etichette degli asset in modo coerente in tutta l'organizzazione. Le incoerenze nell'infrastruttura e nell'etichettatura possono rendere difficile la manutenzione di una CMDB corretta senza processi manuali che probabilmente non sono supportati e che presentano sfide di scalabilità a lungo termine.

Il seguente elenco suggerisce le best practice per rendere il processo di implementazione coerente e ripetibile:

Passaggi successivi