Questo documento illustra i pattern di architettura per la ricerca e la raccolta di informazioni sugli asset in Google Cloud, in altre piattaforme cloud e on-premise utilizzando il rilevamento nel cloud di ServiceNow. Il documento è destinato ai team di architettura o ai team delle operazioni cloud che hanno familiarità con la gestione delle operazioni IT (ITOM), la libreria di infrastruttura IT (ITIL), i servizi Google Cloud come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Asset Inventory e ServiceNow Cloud Discovery.
Panoramica
Molte aziende di grandi dimensioni utilizzano un deployment di infrastruttura IT ibrida che combina Google Cloud, altre piattaforme cloud e l'infrastruttura on-premise. Questo deployment ibrido è in genere l'iterazione iniziale in una strategia di migrazione al cloud. I reparti IT di queste aziende sono tenuti a scoprire e tenere traccia di tutte le risorse nel loro ecosistema tecnico, che possono potenzialmente essere milioni. I reparti IT devono creare un sistema di gestione della configurazione che colleghi questi asset ai servizi tecnici forniti dagli asset. Questo sistema deve inoltre monitorare asset e servizi in modo da supportare le best practice per la gestione delle operazioni IT (ITOM) e la gestione dei servizi IT (ITSM).
Per i clienti di 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 per la gestione delle risorse su più cloud provider. Strumenti come Cloud Operations Workspace consentono ai reparti IT di creare dashboard di risorse multi-cloud e di gestire configurazioni complesse tramite un'interfaccia unificata (a volte chiamata singolo pannello di controllo). Questo documento presenta un insieme di pattern di architettura per questo scenario, una panoramica dei componenti di alto livello e una discussione sulle considerazioni di progettazione generali.
Componenti ServiceNow per questa architettura
I componenti della piattaforma ServiceNow in questi pattern di architettura includono quanto segue:
- Un'istanza ServiceNow contenente un database di gestione della configurazione (CMDB) di elementi di configurazione (CI). Ogni CI rappresenta i componenti dell'ambiente operativo coinvolti nella fornitura dei servizi digitali. Un CI ha più attributi che contengono metadati specifici sul componente e sulle sue relazioni con altri CI.
- Uno o più server ServiceNow Management, Instrumentation e Discovery (MID) in esecuzione nel tuo progetto Google Cloud. I server MID raccolgono i metadati per i CI e li archiviano nel CMDB.
Questi pattern di architettura definiscono alcune pratiche comuni per l'importazione dei dati di Google Cloud Asset Inventory nel rilevamento dell'inventario degli asset della piattaforma Google Cloud di ServiceNow.
Pattern di architettura per l'integrazione di Google Cloud
Questo documento illustra 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 alcune infrastrutture in Google Cloud e alcune nel cloud ServiceNow. Dimostrano come ServiceNow opera in Google Cloud tra infrastruttura gestita da Google e infrastruttura gestita dal cliente. I server MID di ServiceNow eseguono query su tutta l'infrastruttura gestita da Google chiamando le API Cloud di Google. Per ulteriori informazioni su quali API vengono chiamate, consulta la pagina relativa alle API della piattaforma Google Cloud utilizzate dalle applicazioni ITOM.
In ognuno dei seguenti pattern, i componenti dell'architettura collaborano nel processo di rilevamento dell'inventario degli asset di Google Cloud per raccogliere le informazioni di inventario degli asset cloud richieste dall'applicazione ServiceNow Discovery e dagli strumenti correlati.
Pattern di rilevamento di Google Cloud
Il pattern dell'architettura di rilevamento cloud ServiceNow di base utilizza i server ServiceNow MID per chiamare Google Cloud Asset Inventory e altre API Google Cloud al fine di raccogliere dati relativi a risorse quali:
- Istanze VM
- Tag (chiavi/valori)
- Volumi e mappatura dell'archiviazione
- Risorse dei data center, inclusi 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 server MID non hanno bisogno di credenziali perché non accedono alle VM per raccogliere dati. Ciò limita la capacità del processo di rilevamento di raccogliere ulteriori informazioni. Tuttavia, impone meno costi operativi, perché elimina la necessità di gestire e ruotare le credenziali MID Server.
Il seguente diagramma illustra questo pattern di architettura.
La parte relativa a Google Cloud di questo pattern è composta da quanto segue:
- Un progetto Google Cloud (progetto di servizio A nel diagramma), costituito da due bilanciatori del carico Google Cloud, una o più istanze VM, un'istanza GKE e uno o più server ServiceNow MID. Ogni server MID viene eseguito nella propria VM.
- Un secondo progetto Google Cloud (progetto di servizio B nel diagramma), costituito da server MID in esecuzione nelle rispettive VM.
- Un terzo progetto Google Cloud (progetto host C nel diagramma), costituito dall'interconnessione partner.
- Servizi gestiti aggiuntivi, come API Cloud, BigQuery e Cloud Storage.
- Route di rete configurate dai server MID alle API Google Cloud.
La parte ServiceNow è composta dall'istanza ServiceNow, che acquisisce i metadati dai server MID e li archivia nel CMDB.
Pattern di rilevamento basato su IP senza agente di Google Cloud
Questo pattern di architettura aggiunge il rilevamento basato su IP al pattern di base di Cloud Discovery utilizzando un job batch e un account di servizio Google Cloud per accedere alle VM e raccogliere ulteriori dettagli. Questo pattern richiede un carico operativo più impegnativo per gestire il server MID rispetto al pattern di base, perché richiede la gestione e la rotazione delle credenziali del server MID. Tuttavia, espande il processo di rilevamento oltre i dati forniti da Cloud Asset Inventory per includere dati aggiuntivi, come i seguenti:
- Gestione e sicurezza delle credenziali del sistema operativo
- Rilevamento avanzato, come il rilevamento basato su file e il rilevamento delle licenze
- Dettagli sistema operativo
- Processi in esecuzione
- Connessioni TCP
- Software installato
In questo pattern di architettura, uno o più server ServiceNow MID 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 ECC (External Communication Channel) del server MID (non mostrata). Questa architettura è mostrata nel diagramma seguente.
La parte relativa a Google Cloud di questo pattern è composta da quanto segue:
- Progetto di servizio A, composto da due bilanciatori del carico Google Cloud, una o più VM, un'istanza GKE e uno o più server MID di ServiceNow. Ogni server MID viene eseguito nella propria VM.
- Progetto di servizio B, costituito da server MID in esecuzione nelle proprie VM.
- Progetto host C, costituito dall'interconnessione partner.
- Servizi gestiti aggiuntivi, come API Cloud, BigQuery e Cloud Storage.
- Kubernetes Discovery ServiceNow distribuito nell'infrastruttura GKE.
- Route di rete configurate dai server MID alle API Google Cloud.
- Account di servizio che consentono ai server MID di accedere a qualsiasi VM Google Cloud che richiede il rilevamento degli indirizzi IP serverless.
- Route di rete configurate dai server MID a qualsiasi VM Google Cloud che richiede il rilevamento degli indirizzi IP serverless.
La parte ServiceNow è composta dall'istanza ServiceNow, che acquisisce i metadati dai server MID e li archivia nel CMDB.
Rilevamento Google Cloud con pattern raccoglitore client agente
Questo pattern di architettura include quanto segue:
- La scoperta iniziale del cloud.
- Uno o più server MID.
Un altro agente ServiceNow, il raccoglitore client agente, che installi sulle tue VM. Questi agenti si connettono direttamente ai server MID e trasmettono le seguenti informazioni aggiuntive a ServiceNow:
- Rilevamento basato su push quasi in tempo reale
- Misurazione software
- Visualizzazione CI in tempo reale
- Automazione del flusso di lavoro per i server
Il seguente diagramma illustra questo pattern di architettura.
La parte relativa a Google Cloud di questo pattern è composta da quanto segue:
- Progetto di servizio A, composto da due bilanciatori del carico Google Cloud, una o più istanze VM, un'istanza GKE e uno o più server MID di ServiceNow. Ogni server MID viene eseguito nella propria VM.
- Progetto di servizio B, costituito da server MID in esecuzione sulle proprie VM.
- Progetto host C, costituito dall'interconnessione partner.
- Kubernetes Discovery ServiceNow distribuito nell'infrastruttura GKE.
- Servizi gestiti aggiuntivi, come 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 VM Google Cloud in cui sono installati gli agenti ServiceNow Discovery.
La parte ServiceNow è composta da quanto segue:
- L'istanza ServiceNow, che acquisisce i metadati dai server MID e li archivia nel CMDB.
- Agenti di rilevamento ServiceNow installati sulle VM Google Cloud gestite dal cliente.
Flusso di lavoro di rilevamento degli asset cloud
Le seguenti sezioni descrivono il flusso di lavoro per il rilevamento degli asset Google Cloud. Questo flusso di lavoro si applica a tutti e tre i pattern di architettura descritti in questo documento.
Installazione e configurazione dei componenti di ServiceNow
- Abilitare le API Cloud Asset Inventory.
- Installa il raccoglitore client dell'agente sulle tue VM. Per ulteriori informazioni, consulta Installazione del raccoglitore client di agenti.
- Distribuisci le risorse per i computer che ospitano i server MID.
- Configura le regole firewall per consentire le connessioni sulla porta 443 tra l'istanza VM e i computer che ospitano i server MID.
- Configurare la connettività di rete del server MID.
- Installa i server MID.
- Configura i server MID in modo da 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
- 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 e aggiornare CMDB.
- I server MID di ServiceNow interrogano il database Cloud Asset Inventory per informazioni su tutte le risorse nell'ambiente Google Cloud.
- I server MID archiviano le informazioni degli asset cloud in un bucket Cloud Storage.
- Non tutte le informazioni richieste possono essere ricavate dal database di Cloud Asset Inventory. Nel pattern senza agente, le informazioni della VM non includono la versione attuale della patch del sistema operativo. Per questo livello di dettaglio, i server MID eseguono
un
deep rilevamento
tramite le seguenti operazioni:
- I server MID creano un job batch basato sugli indirizzi IP delle VM che richiedono un deep discovery.
- 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.
- Se i raccoglitori client di Agent sono installati, i dati che acquisiscono vengono trasmessi direttamente ai server MID, anziché archiviati nel database Cloud Asset Inventory. Per maggiori informazioni, consulta le sezioni Preparazione del networking e Configurazione server MID.
- Dopo aver raccolto i dati di rilevamento degli asset, i server MID li archiviano nel CMDB come segue:
- I server MID creano CI nel CMDB per rappresentare le funzionalità operative fornite da ogni risorsa.
- I server MID rilevano automaticamente le etichette di Google Cloud e le memorizzano nel CMDB. Queste etichette vengono mappate automaticamente ai CI e sono utili per creare mappe di servizi.
Il processo del flusso di lavoro deve essere ripetuto periodicamente in base alle necessità. A seconda della scalabilità e della configurazione del deployment, puoi scegliere il rilevamento basato sugli eventi o basato sulla pianificazione. Per ulteriori informazioni, consulta la sezione "Gestione del ciclo di vita di CI" nelle linee guida per la progettazione di CMDB.
Note sul layout
Le sezioni seguenti forniscono indicazioni sulla progettazione per l'implementazione di uno qualsiasi dei pattern di architettura descritti in questo documento.
Località dell'istanza ServiceNow
Per la maggior parte dei casi d'uso, consigliamo il deployment dei server MID in Google Cloud. In questo modo le istanze sono vicine agli asset cloud su cui eseguono il deep discovery.
I pattern di architettura in questo documento presuppongono che il CMDB archivi i dati di rilevamento per tutte le risorse cloud e on-premise, non solo per gli asset Google Cloud. CMDB può essere posizionato nel cloud ServiceNow, in Google Cloud o on-premise. La decisione finale su dove posizionare CMDB nel tuo ambiente dipende dai requisiti specifici.
Scelta di utilizzare agenti server MID
Un'altra considerazione di progettazione è se utilizzare agenti server MID e account di servizio. Se il tuo processo di rilevamento deve raccogliere informazioni oltre ai metadati forniti da Cloud Asset Inventory, devi utilizzare un'infrastruttura MID Server con account di servizio o, in alternativa, un server MID con Agent Client Collector. Entrambi gli approcci possono influire sui costi di assistenza operativa, che devi tenere in considerazione nella tua progettazione. L'approccio da usare dipende da quali dati devi acquisire e come li utilizzerai. Il costo operativo dell'acquisizione dei dati potrebbe superare il valore fornito dai dati.
Supporto di più regioni per i server MID
Se la tua azienda richiede il supporto dell'infrastruttura MID Server in più regioni, devi pianificare il deployment di ciascun server MID 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 il rilevamento degli asset Google Cloud, devi considerare il costo del traffico in uscita e di calcolo.
Costo in uscita
I costi per il traffico in uscita vengono addebitati ogni volta che i dati vengono spostati al di fuori di Google Cloud. Per questo motivo, devi analizzare il costo del traffico in uscita per il tuo caso d'uso al fine di determinare l'opzione migliore per individuare i componenti ServiceNow. In genere, i server MID che eseguono il deep discovery comportano costi di traffico in uscita inferiori se sono in esecuzione su 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 valore migliore per la tua azienda.
Ad esempio, dovresti considerare il numero di server MID di cui esegui il deployment nelle istanze di Google Cloud Compute Engine. L'implementazione di più server MID rende più rapido il processo di rilevamento degli asset. Tuttavia, questo aumenta i costi di calcolo, poiché il deployment di ogni server MID viene eseguito nella propria istanza VM. Per ulteriori informazioni sull'implementazione di uno o più server MID, consulta Installare più server MID su un singolo sistema.
Considerazioni sulla supportabilità operativa
È probabile che il tuo deployment includa controlli di sicurezza di rete come firewall, sistemi di protezione dalle intrusioni, sistemi di rilevamento delle intrusioni e infrastruttura di mirroring pacchetto. Se tra Google Cloud e l'ambiente di deployment dei server MID vengono implementati ampi controlli di sicurezza della rete, questi controlli possono creare problemi di supportabilità operativa. 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 eseguirà la query di rilevamento approfondito.
Protezione dei server MID
Consigliamo le seguenti misure di sicurezza per le istanze del server MID:
- Assicurati che i server MID siano isolati per garantire che solo gli amministratori attendibili possano accedervi.
- Assicurati che i server MID siano protetti dall'eliminazione.
- Assicurati che i ruoli IAM vengano applicati per limitare la capacità di apportare modifiche solo alle modifiche approvate tramite processi ITIL o una pipeline CI/CD.
Protezione degli account di servizio
Per la gestione degli account di servizio consigliamo le seguenti misure di sicurezza:
- Se ospiti i tuoi server MID in Google Cloud, l'autenticazione viene gestita automaticamente utilizzando l'account di servizio associato. Se ospiti i tuoi server MID al di fuori di Google Cloud, hai la responsabilità di generare una chiave dell'account di servizio gestita dall'utente per l'autenticazione, quindi di proteggere e controllare questa credenziale permanente. Per saperne di più, consulta le best practice per la gestione delle chiavi degli account di servizio.
- Accertati che i server MID utilizzino un account di servizio provvisto solo dei ruoli e delle autorizzazioni IAM assolutamente necessari per il rilevamento degli asset. Per ulteriori informazioni, consulta le best practice per l'utilizzo degli account di servizio.
Struttura di cartelle e progetti
Cartelle e progetti sono nodi nella gerarchia delle risorse di Google Cloud. Per supportare il rilevamento degli asset, la struttura delle cartelle e del progetto deve riflettere la struttura dell'applicazione e gli ambienti in cui è stato eseguito il deployment dell'applicazione. La strutturazione delle risorse in questo modo consente a ServiceNow di mappare gli asset ai servizi tecnici forniti.
Presta attenzione a tutte le modifiche che apporti alla struttura di cartelle e progetti per supportare il rilevamento ServiceNow. Il ruolo principale della struttura delle cartelle e del progetto è quello di supportare la fatturazione e l'accesso IAM. Pertanto, qualsiasi modifica apportata a ServiceNow deve supportare e allineare la struttura di fatturazione di Google Cloud della tua organizzazione. Per le best practice su come strutturare la tua organizzazione, la gerarchia di cartelle e i progetti Google Cloud, consulta Gerarchia delle risorse e Creazione e gestione delle organizzazioni.
Il seguente diagramma rappresenta un esempio di gerarchia delle risorse di Google Cloud nella sua forma completa. In questo esempio, la struttura delle cartelle definisce l'applicazione e ogni progetto definisce un ambiente.
Etichettatura
Le etichette sono coppie chiave-valore che puoi assegnare alle risorse cloud. (ServiceNow, AWS e Azure fanno riferimento alle etichette come tag.)
ServiceNow utilizza le etichette che assegni alle tue risorse Google Cloud per identificare le risorse e, facoltativamente, mapparle ai servizi. La scelta di uno schema di etichettatura efficace consente a ServiceNow di monitorare l'infrastruttura per ottenere report accurati e conformità ITOM/ITSM.
Ti consigliamo di utilizzare le etichette per tutte le risorse che richiedono un'identificazione univoca che è più specifica di quanto consentito dalla struttura di cartelle e progetto. Ad esempio, potresti voler utilizzare le etichette nei seguenti casi:
- Se l'applicazione prevede requisiti di conformità rigorosi, puoi etichettare tutte le risorse dell'applicazione in modo che l'organizzazione possa identificare facilmente tutta l'infrastruttura che rientra nell'ambito.
- In un ambiente multi-cloud, puoi utilizzare le etichette per identificare il cloud provider e la regione per tutte le risorse.
- Se hai bisogno di una visibilità più granulare rispetto a 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 le etichette agli asset gestiti da Google eseguiti nel tuo VPC. Le etichette assegnate da Google hanno come prefisso goog-. I server MID non
devono tentare di eseguire un'ispezione approfondita su questi asset. Per ulteriori informazioni sulle etichette per le risorse gestite da Google, consulta Mappatura basata su tag ed Etichettare automaticamente le risorse in base alle notifiche in tempo reale di Cloud Asset Inventory.
La seguente tabella elenca le etichette che i servizi Google Cloud assegnano alle risorse gestite da questi servizi.
| Servizio Google Cloud | Etichette o prefisso di etichetta |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Per supportare in modo efficace una gestione delle risorse, il processo di deployment della tua organizzazione deve creare strutture di progetti e cartelle e assegnare etichette delle risorse in modo coerente in tutta l'organizzazione. Le incoerenze nell'infrastruttura e nell'etichettatura possono rendere difficile mantenere una CMDB corretto senza processi manuali che potrebbero essere insostenibili e che presentano sfide di scalabilità a lungo termine.
Il seguente elenco suggerisce le best practice per rendere il processo di deployment coerente e ripetibile:
- Utilizza Infrastructure as Code (IaC) o sistemi di provisioning automatizzato come Terraform, ServiceNow ITOM o Provisioning e governance del cloud con Google Cloud Deployment Manager.
- Predisponi un processo di buona governance per le tue etichette. Per una panoramica della governance dell'etichettatura, consulta Governance dei tag nella documentazione di ServiceNow.
Passaggi successivi
- Per ulteriori best practice per la strutturazione delle risorse per la fatturazione Cloud, consulta la Guida all'organizzazione e alla gestione degli accessi delle risorse di fatturazione Cloud e la Guida alla configurazione di Cloud Insights per Google Cloud.
- Per le best practice su come strutturare le autorizzazioni IAM della tua organizzazione, consulta Best practice per account e organizzazioni di pianificazione e Provisioning e governance di Cloud.
- Per le best practice per la strutturazione dei criteri firewall VPC nella tua organizzazione, consulta Criteri firewall gerarchici.
- Scopri come utilizzare le etichette per supportare il rilevamento basato su tag di ServiceNow.
- Scopri di più sul raccoglitore client di ServiceNow Agent, un meccanismo di push che viene eseguito nel tuo progetto Google Cloud e invia i dati di output all'istanza ServiceNow tramite il server MID, archiviando eventi e metriche nel database pertinente.
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.