Questo documento illustra i pattern di architettura per trovare e raccogliere informazioni sugli asset in Google Cloud, in altre piattaforme cloud e on-premise utilizzando la scoperta cloud di ServiceNow. Il documento è rivolto ai team di architetti o di operazioni cloud che hanno familiarità con la gestione delle operazioni IT (ITOM), la libreria di infrastruttura di Information Technology (ITIL), i servizi Google Cloud come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Asset Inventory e ServiceNow Cloud Discovery.
Panoramica
Molte grandi aziende utilizzano un deployment dell'infrastruttura IT ibrida che combinaGoogle Cloud, altre piattaforme cloud e l'infrastruttura on-premise. Questo tipo di deployment ibrido è in genere l'iterazione iniziale di una strategia di migrazione al cloud. I reparti IT di queste aziende sono tenuti a scoprire e monitorare tutti gli asset del loro ecosistema tecnico, che possono essere potenzialmente milioni. 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 le risorse 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 di Google Cloud , un'architettura comune utilizza la ricerca delle risorse cloud di ServiceNow per trovare e raccogliere informazioni sugli asset in Google Cloud, in altre piattaforme cloud e on-premise. ServiceNow offre una vasta 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 relativi componenti di alto livello e una discussione di considerazioni generali sul design.
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 nel tuo ambiente operativo coinvolti nella fornitura di servizi digitali. Un CI ha più attributi che contengono metadati specifici sul componente e sulle sue relazioni con altri CI.
- Uno o più server MID (Management, Instrumentation and Discovery) di ServiceNow, in esecuzione nel tuo progetto Google Cloud . I server MID raccolgono i metadati per gli elementi di inventario e li archiviano nella CMDB.
Questi pattern di architettura definiscono alcune pratiche comuni per l'importazione dei dati di Cloud Asset Inventory di Google Cloud nella funzionalità di ricerca dell'inventario delle risorse 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 diGoogle 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. Dimostrano come ServiceNow opera in Google Cloud tra l'infrastruttura gestita da Google e l'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 saperne di più sulle API chiamate, consulta API della piattaforma Google Cloud utilizzate dalle applicazioni ITOM.
In ciascuno dei seguenti pattern, i componenti dell'architettura collaborano nel processo di rilevamento dell'inventario delle risorse della piattaforma Google Cloud per raccogliere le informazioni sull'inventario delle risorse cloud richieste dall'applicazione ServiceNow Discovery e dagli strumenti correlati.
Pattern di rilevamentoGoogle Cloud
Il pattern di architettura di rilevamento del cloud di ServiceNow di base utilizza i server MID di ServiceNow per chiamare l'inventario delle risorse di Google Cloud e altre API Google Cloud per raccogliere dati su risorse come:
- Istanze VM
- Tag (chiavi/valori)
- Volumi di archiviazione e mappatura dello spazio di 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 in base alle etichette delle risorse
In questo pattern, i server MID non richiedono credenziali perché non accedono alle VM per raccogliere i dati. Ciò limita la capacità del processo di rilevamento di raccogliere ulteriori informazioni. Tuttavia, comporta un costo operativo inferiore, perché elimina la necessità di gestire e ruotare le credenziali del server MID.
Il seguente diagramma illustra questo pattern di architettura.
La parte di questo pattern relativa a Google Cloud è costituita 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 MID ServiceNow. Ogni MID Server viene eseguito nella propria VM.
- Un secondo progetto Google Cloud (Progetto di servizio B nel diagramma), costituito da MID Server in esecuzione nelle proprie VM.
- Un terzo progetto Google Cloud (progetto host C nel diagramma), costituito dall'interconnessione del partner.
- Servizi gestiti aggiuntivi, come API Cloud, BigQuery e Cloud Storage.
- Route di rete configurati dai server MID alle API Google Cloud.
La parte di ServiceNow è costituita dall'istanza ServiceNow, che acquisisce i metadati dai server MID e li memorizza nella CMDB.
Google Cloud pattern di rilevamento basato su IP senza agente
Questo pattern di architettura aggiunge la ricerca basata su IP al pattern di ricerca cloud di base utilizzando un job batch e un account di servizioGoogle Cloudper accedere alle VM e raccogliere ulteriori dettagli. Questo pattern richiede un maggiore impegno operativo per gestire il server MID rispetto al pattern di base, in quanto richiede di gestire e ruotare le credenziali del server MID. Tuttavia, estende la procedura 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 migliorato, 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ù server MID ServiceNow si trovano in Google Cloud, mentre l'istanza ServiceNow è ospitata nella piattaforma cloud ServiceNow. I server MID sono collegati all'istanza ServiceNow tramite la coda del canale di comunicazione esterno (ECC) del server MID (non mostrata). Questa architettura è mostrata nel seguente diagramma.
La parte di questo pattern relativa a Google Cloud è costituita 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 ServiceNow. Ogni MID Server viene eseguito nella propria VM.
- Progetto di servizio B, composto da MID Server in esecuzione nelle proprie VM.
- Progetto host C, costituito dall'interconnessione del partner.
- Servizi gestiti aggiuntivi, come API Cloud, BigQuery e Cloud Storage.
- ServiceNow Kubernetes Discovery di cui è stato eseguito il deployment sull'infrastruttura GKE.
- Route di rete configurati dai server MID alle API Google Cloud.
- Service account che consentono ai server MID di accedere a qualsiasi VMGoogle Cloud che richiede il rilevamento degli indirizzi IP serverless.
- Percorsi di rete configurati dai server MID a qualsiasi VMGoogle Cloud che richiedono il rilevamento degli indirizzi IP serverless.
La parte di ServiceNow è costituita dall'istanza ServiceNow, che acquisisce i metadati dai server MID e li memorizza nella CMDB.
RilevamentoGoogle Cloud con il pattern Agent Client Collector
Questo pattern di architettura include quanto segue:
- La scoperta iniziale del cloud.
- Uno o più server MID.
Un agente ServiceNow aggiuntivo, Agent Client Collector, da installare sulle VM. Questi agenti si connettono direttamente ai server MID e ritrasmettono a ServiceNow le seguenti informazioni aggiuntive:
- Rilevamento basato su 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.
La parte di questo pattern relativa a Google Cloud è costituita 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 ServiceNow. Ogni MID Server viene eseguito nella propria VM.
- Progetto di servizio B, composto da server MID in esecuzione nelle proprie VM.
- Progetto host C, costituito dall'interconnessione del partner.
- ServiceNow Kubernetes Discovery di cui è stato eseguito il deployment sull'infrastruttura GKE.
- Servizi gestiti aggiuntivi, come API Cloud, BigQuery e Cloud Storage.
- Route di rete configurati dai server MID alle API Google Cloud.
- Percorsi di rete configurati dai server MID alle VMGoogle Cloud su cui sono installati gli agenti di rilevamento ServiceNow.
La parte di ServiceNow è costituita da quanto segue:
- L'istanza ServiceNow, che acquisisce i metadati dai server MID e li archivia nella CMDB.
- Agenti di rilevamento ServiceNow installati su VMGoogle Cloud gestite dal cliente.
Flusso di lavoro di rilevamento asset di Cloud
Le sezioni seguenti descrivono il flusso di lavoro per la scoperta delle risorse di 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 di ServiceNow
- Abilita le API Cloud Asset Inventory.
- Installa Agent Client Collector sulle VM. Per ulteriori informazioni, consulta Installazione del raccoglitore client dell'agente.
- Assegna risorse ai computer che ospitano i server MID.
- Configura le regole del firewall per consentire le connessioni sulla porta 443 tra l'istanza VM e i computer che ospitano i server MID.
- Configura 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 per aggiornare la CMDB.
- I server MID di ServiceNow eseguono query sul database Cloud Asset Inventory per recuperare informazioni su tutti gli asset 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 ottenute dal database di Cloud Asset Inventory. Nel pattern senza agente, le informazioni sulla VM non includono la
versione corrente della patch del sistema operativo. Per questo livello di dettaglio, i server MID eseguono un
rivelamento approfondito
eseguendo i seguenti passaggi:
- I server MID creano un job batch in base agli indirizzi IP delle VM che richiedono una scoperta approfondita.
- Nel job batch, i server MID accedono a ogni VM e eseguono query sul sistema operativo per ottenere la versione delle patch e altre informazioni.
- Se sono installati i collector client dell'agente, i dati acquisiti vengono trasmessi direttamente ai server MID anziché archiviati nel database dell'Cloud Asset Inventory. Per ulteriori informazioni, consulta Preparazione della rete e Configurazione del server MID.
- Dopo aver raccolto i dati di rilevamento delle risorse, i server MID li memorizzano nel CMDB come segue:
- I server MID creano gli elementi di inventario nel CMDB per rappresentare la funzionalità operativa fornita da ogni asset.
- I server MID rilevano automaticamente le etichette da Google Cloud e le memorizzano nella CMDB. Queste etichette vengono mappate automaticamente ai CI e sono utili per creare mappe dei servizi.
Il processo di flusso di lavoro deve essere ripetuto periodicamente, in base alle necessità. A seconda della scala e della configurazione del deployment, puoi scegliere il rilevamento in base agli eventi o in base alla pianificazione. Per saperne di più, consulta la sezione "Gestione del ciclo di vita CI" in CMDB Design Guidance.
Note sul layout
Le sezioni seguenti forniscono indicazioni di progettazione per l'implementazione di uno dei modelli di architettura 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 si trovano vicino agli asset cloud su cui eseguono il rilevamento approfondito.
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 di Google Cloud . La CMDB può trovarsi nel cloud ServiceNow, in Google Cloudo on-premise. La decisione definitiva su dove posizionare la CMDB nel tuo ambiente dipende dai tuoi requisiti specifici.
Decidere di utilizzare gli agenti MID Server
Un'altra considerazione di progettazione riguarda l'utilizzo di agenti MID Server e account servizio. 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, in alternativa, un MID Server con Agent Client Collector. Entrambi gli approcci possono influire sul costo dell'assistenza operativa, che devi considerare nella progettazione. L'approccio da utilizzare dipende dai dati che devi acquisire e da come li utilizzerai. Il costo operativo per acquisire i dati potrebbe superare il valore fornito dai dati.
Supporto multi-regione per i server MID
Se la tua azienda richiede l'assistenza multi-regione dell'infrastruttura MID Server, devi pianificare di eseguire il deployment di ciascun 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 di ServiceNow per la scoperta delle risorse diGoogle Cloud , devi considerare il costo di uscita e il costo di calcolo.
Costo del traffico in uscita
Gli addebiti in uscita vengono addebitati ogni volta che i dati vengono spostati da Google Cloud. Per questo motivo, devi analizzare il costo di uscita per il tuo caso d'uso per determinare l'opzione migliore per posizionare i componenti di ServiceNow. In genere, i server MID che eseguono la scoperta approfondita hanno costi di uscita inferiori se sono in esecuzione suGoogle Cloud rispetto a un altro cloud o on-premise.
Costo calcolo
I componenti di ServiceNow in esecuzione in Google Cloud comportano costi di calcolo che devi analizzare per determinare il valore migliore per la tua azienda.
Ad esempio, devi considerare il numero di server MID di cui esegui il deployment nelle istanze Compute Engine diGoogle Cloud . Il deployment di più MID Server accelera il processo di rilevamento delle risorse. Tuttavia, questa operazione aumenta il costo di calcolo, poiché ogni MID Server viene disegnato nella propria istanza VM. Per ulteriori informazioni su come eseguire il deployment di uno o più MID Server, consulta Installare più MID Server su un unico sistema.
Considerazioni sulla supportabilità operativa
L'implementazione probabilmente include controlli di sicurezza della rete come firewall, sistemi di protezione dalle intrusioni, sistemi di rilevamento delle intrusioni e l'infrastruttura di mirroring dei pacchetti. Se sono in vigore controlli di sicurezza della rete estesi tra Google Cloud e l'ambiente in cui sono eseguiti i deployment dei server MID, questi controlli possono creare problemi di assistenza operativa. Per evitare questi problemi, ti consigliamo di ospitare i server MID in Google Cloudo il più vicino possibile all'infrastruttura Google Cloud su cui eseguirà query una scoperta approfondita.
Protezione dei server MID
Ti consigliamo le seguenti best practice per la sicurezza delle istanze MID Server:
- Assicurati che i server MID siano isolati per garantire che solo gli amministratori attendibili possano connettersi.
- Assicurati che i server MID siano protetti dall'eliminazione.
- Assicurati che i ruoli IAM vengano applicati per limitare la possibilità di apportare modifiche solo a quelle approvate tramite i processi ITIL o tramite una pipeline CI/CD.
Protezione degli account di servizio
Per la gestione degli account di servizio, consigliamo le seguenti best practice per la sicurezza:
- Assicurati che i server MID utilizzino un account di servizio con solo i ruoli e le autorizzazioni IAM assolutamente necessari per il rilevamento delle risorse. Per ulteriori informazioni, consulta Best practice per l'utilizzo degli account di servizio.
- L'autenticazione ServiceNow richiede la copia dei contenuti di una chiave dell'account di servizio nell'interfaccia utente di ServiceNow.
Le chiavi degli account di servizio comportano un rischio per la sicurezza se non vengono gestite correttamente. Sei responsabile della sicurezza della chiave privata e di altre operazioni descritte dalle
best practice per la gestione delle chiavi degli account di servizio.
Se non riesci a creare una chiave del account di servizio, la creazione di chiavi del account di servizio potrebbe essere disabilitata per la tua organizzazione. Per ulteriori informazioni, consulta
Gestione delle risorse dell'organizzazione sicure per impostazione predefinita.
Se hai acquisito la chiave dell'account di servizio da una fonte esterna, devi convalidarla prima dell'utilizzo. Per ulteriori informazioni, vedi Requisiti di sicurezza per le credenziali di origine esterna".
Struttura di cartelle e progetti
Le cartelle e i progetti sono nodi nella gerarchia delle risorse di Google Cloud . Per supportare il rilevamento degli asset, la struttura della cartella e del progetto deve riflettere la struttura dell'applicazione e degli ambienti in cui è dipiattaforma. La strutturazione delle risorse in questo modo consente inoltre a ServiceNow di mappare le risorse ai servizi tecnici forniti.
Tieni presente le eventuali modifiche apportate alla struttura della cartella e del progetto per supportare il rilevamento di ServiceNow. Il ruolo principale della struttura di cartelle e progetti è supportare la fatturazione e l'accesso IAM. Pertanto, eventuali modifiche apportate per supportare ServiceNow devono essere supportate e in linea con la struttura di fatturazione diGoogle Cloud della tua organizzazione. Per le best practice per strutturare la gerarchia di organizzazioni, cartelle e progettiGoogle Cloud , consulta Gerarchia delle risorse e Creazione e gestione delle organizzazioni.
Il seguente diagramma mostra un esempio di gerarchia delle risorse 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 risorse Google Cloud per identificare le risorse e, facoltativamente, mapparle ai servizi. La scelta di un buon schema di etichettatura consente a ServiceNow di monitorare l'infrastruttura per generare report accurati e garantire la conformità ITOM/ITSM.
Ti consigliamo di utilizzare le etichette per le risorse che richiedono un'identificazione unica più specifica di quella consentita dalla struttura della cartella e del progetto. Ad esempio, ti consigliamo di utilizzare le etichette nei seguenti casi:
- Se la tua applicazione prevede 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 multi-cloud, puoi utilizzare le etichette per identificare il fornitore cloud e la regione per tutte le risorse.
- Se hai bisogno di una visibilità più granulare rispetto a quella fornita per impostazione predefinita da Report di fatturazione Google Cloud o Esportazione della fatturazione Cloud in BigQuery, i dati possono essere filtrati per etichette.
Google assegna automaticamente le etichette agli asset gestiti da Google che vengono eseguiti nella VPC. Le etichette assegnate da Google sono precedute da goog-. I tuoi server MID non devono tentare di eseguire un'ispezione approfondita di questi asset. Per ulteriori informazioni sulle etichette per le risorse gestite da Google, consulta Mappatura basata su tag e Etichettare automaticamente le risorse in base alle notifiche in tempo reale di Cloud Asset Inventory.
La tabella seguente elenca le etichette assegnate dai servizi Google Cloud alle risorse gestite da questi servizi.
| ServizioGoogle Cloud | Etichette o prefisso etichetta |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Per supportare efficacemente la gestione delle risorse, il processo di implementazione 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 la gestione di una CMDB corretta senza procedimenti manuali che probabilmente non sono supportabili e che presentano problemi di scalabilità nel lungo termine.
Il seguente elenco suggerisce le best practice per rendere la procedura di implementazione coerente e ripetibile:
- Utilizza Infrastructure as Code (IaC) o sistemi di provisioning automatico come Terraform, ServiceNow ITOM o Cloud provisioning and governance con Google Cloud Deployment Manager.
- Avere un buon processo di governance per le tue etichette. Per una panoramica della governance delle etichette, consulta Governance dei tag nella documentazione di ServiceNow.
Passaggi successivi
- Per altre best practice per strutturare le risorse per la fatturazione Cloud, consulta la guida all'organizzazione e alla gestione dell'accesso alle risorse per la fatturazione Cloud e la guida alla configurazione di Cloud Insights per Google Cloud.
- Per le best practice per la struttura delle autorizzazioni IAM della tua organizzazione, consulta Best practice per la pianificazione di account e organizzazioni e Provisioning e governance di Cloud.
- Per le best practice per strutturare i criteri firewall VPC all'interno della tua organizzazione, consulta Criteri firewall gerarchici.
- Scopri come utilizzare le etichette per supportare la ricerca basata su tag di ServiceNow.
- Scopri di più su ServiceNow Agent Client Collector, un meccanismo push che viene eseguito nel tuo progetto Google Cloud e invia i dati di output all'istanza ServiceNow tramite il server MID, memorizzando eventi e metriche nel database pertinente.
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.