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 è destinato a di architettura o team delle operazioni cloud che hanno familiarità con l'IT gestione delle operazioni (ITOM); Libreria di infrastrutture tecnologiche dell’informazione (ITIL); ai 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 combina Google Cloud, altre piattaforme cloud e l'infrastruttura on-premise. Tale un deployment ibrido è in genere l'iterazione iniziale di una migrazione al cloud strategia. I reparti IT di queste aziende devono scoprire e mantenere monitorare tutte le risorse nel proprio ecosistema tecnico, in modo da poter in 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 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 per la gestione delle risorse su più cloud provider. Strumenti come Area di lavoro della suite operativa di Google Cloud consente ai reparti IT di creare dashboard di risorse multi-cloud e di gestire complessi tramite un'interfaccia unificata (talvolta chiamata un singolo riquadro vetro). Questo documento presenta un insieme di pattern di architettura dello scenario, una panoramica dei suoi componenti di alto livello e una discussione sulle considerazioni sulla progettazione.
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 necessari per la distribuzione di soluzioni digitali i servizi di machine learning. Un CI ha più attributi che contengono metadati specifici su del componente e dei suoi relazioni con altri CI.
- Uno o più Server ServiceNow Management, Instrumentation, and Discovery (MID), 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 di dati Cloud Asset Inventory i dati nel cluster di ServiceNow Rilevamento dell'inventario degli asset della piattaforma Google Cloud.
Modelli 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 modelli 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 opera ServiceNow in Google Cloud tra Infrastruttura gestita da Google e 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 rilevamento di Google 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 basata su etichette delle risorse
Con questo pattern, i server MID non hanno bisogno di credenziali perché non registrano nelle VM per raccogliere i dati. Ciò limita la capacità del processo di rilevamento di raccogliere ulteriori informazioni. Ma impone meno costi operativi, elimina la necessità di gestire e ruotare le credenziali del server MID.
Il seguente diagramma illustra questo modello di architettura.
La parte di Google Cloud di questo pattern è costituita da quanto segue:
- Un progetto Google Cloud (progetto di servizio A nel diagramma), che è composto da due bilanciatori del carico Google Cloud, una o più VM di istanze gestite, un'istanza GKE e uno o più ServiceNow Server MID. Ogni server MID viene eseguito nella propria VM.
- Un secondo progetto Google Cloud (progetto di servizio B nel diagramma), ovvero 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 alla piattaforma Google di Google Cloud.
La parte di ServiceNow è composta dall'istanza di ServiceNow, che acquisisce il dai server MID e li archivia nel CMDB.
Pattern di rilevamento basato su IP senza agenti di Google Cloud
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 servizio Google Cloud per 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, 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 migliorato, ad esempio rilevamento basato su file e l'individuazione 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 connessi 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 Google Cloud di questo pattern è 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 server MID viene eseguito nella propria VM.
- Progetto di servizio B, composto da MID Server in esecuzione nelle proprie VM.
- Progetto C host, composto da Partner Interconnect.
- Altri servizi gestiti, come le 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.
- Account di servizio che consentono ai server MID di accedere a qualsiasi VM di Google Cloud che richiedono il rilevamento di indirizzi IP serverless.
- Route di rete configurati dai server MID a qualsiasi VM Google Cloud che richiede il rilevamento dell'indirizzo IP serverless.
La parte di ServiceNow è costituita dall'istanza ServiceNow, che acquisisce i metadati dai server MID e li memorizza nella CMDB.
Rilevamento di 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 agente ServiceNow aggiuntivo, Agent Client Collector, vengono installate sulle tue VM. Questi agenti si connettono direttamente ai server MID inoltra le seguenti informazioni aggiuntive a ServiceNow:
- Rilevamento basato sulle notifiche quasi in tempo reale
- Misurazione del software
- Visualizzazione CI in tempo reale
- Automazione del flusso di lavoro verso i server
Il seguente diagramma illustra questo pattern di architettura.
La parte Google Cloud di questo pattern è costituita da quanto segue:
- Progetto di servizio A, composto da due carichi di lavoro Google Cloud di fatturazione, una o più istanze VM, un'istanza GKE e uno o più server MID ServiceNow. Ogni server MID viene eseguito nella propria VM.
- Progetto di servizio B, composto da server MID in esecuzione nelle rispettive VM.
- Progetto C host, composto da Partner Interconnect.
- Deployment di ServiceNow Kubernetes Discovery in GKE dell'infrastruttura.
- Altri servizi gestiti, come le API Cloud, BigQuery e Cloud Storage.
- Route di rete configurati dai server MID alle API Google Cloud.
- route di rete configurate dai server MID VM Google Cloud in cui sono installati gli agenti ServiceNow Discovery.
La parte ServiceNow è costituita da quanto segue:
- L'istanza ServiceNow, che acquisisce i metadati dal file MID lo archivia nel CMDB.
- Agenti di rilevamento ServiceNow installati in ambienti gestiti dal cliente delle VM di Google Cloud.
Flusso di lavoro di rilevamento degli asset cloud
Le sezioni seguenti illustrano il flusso di lavoro per l'asset Google Cloud scoperta. 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 il raccoglitore client agente sulle tue VM. Per ulteriori informazioni, vedi Installazione del raccoglitore client agente.
- Alloca risorse per i 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 Google di Google Cloud.
Flusso di lavoro
- Cloud Asset Inventory compila un database di 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 una query sul database Cloud Asset Inventory per informazioni su tutti gli asset nell'ambiente Google Cloud.
- I server MID archiviano le informazioni sugli asset cloud in un nel bucket Cloud Storage.
- Non tutte le informazioni richieste possono essere ottenute da Cloud Asset Inventory
per configurare un database. Nel pattern senza agente, le informazioni sulla VM non includono
dell'attuale versione patch del sistema operativo. Per questo livello di dettaglio, i server MID eseguono
a
una scoperta approfondita
nel seguente modo:
- I server MID creano un job batch basato sugli indirizzi IP dei le VM che richiedono un rilevamento approfondito.
- 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 sono installati i collector client dell'agente, i dati acquisiti vengono trasmessi direttamente ai server MID anziché archiviati nel database dell'inventario delle risorse Cloud. Per ulteriori informazioni, consulta Preparazione della rete e Configurazione del server MID.
- Dopo aver raccolto i dati di rilevamento degli asset, i server MID li archiviano in
il CMDB nel modo seguente:
- I server MID creano CI nel CMDB per rappresentare capacità operativa fornita da ogni risorsa.
- I server MID rilevano automaticamente le etichette da Google Cloud e le archiviano 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 "Gestione del ciclo di vita di CI" nel Indicazioni per la progettazione del database CMDB.
Note sul layout
Le seguenti sezioni forniscono indicazioni di progettazione per l'implementazione di uno qualsiasi dei di architettura esistenti descritti in questo documento.
Percorso dell'istanza ServiceNow
Per la maggior parte dei casi d'uso, consigliamo di implementare i server MID in Google Cloud. In questo modo, le istanze si trovano vicino agli asset cloud su cui eseguono la scoperta approfondita.
I pattern di architettura in questo documento presuppongono che la CMDB archivi i dati di rilevamento per tutte le risorse cloud e per tutte le risorse on-premise, non solo per gli asset Google Cloud. Il CMDB può essere posizionato ServiceNow, in Google Cloud o on-premise. La decisione definitiva sulla posizione del database CMDB nel tuo ambiente dipende i tuoi requisiti.
Scelta 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 multiregionale per i server MID
Se la tua azienda richiede il supporto multiregionale dell'infrastruttura MID Server, dovresti pianificare il deployment di ogni server MID in almeno due zone di disponibilità di replicarlo in un'altra regione.
Implicazioni sui costi
Quando scegli dove eseguire il deployment dei componenti di ServiceNow per la scoperta delle risorse Google Cloud, devi prendere in considerazione i costi di uscita e di calcolo.
Costo in uscita
Costi per il traffico in uscita vengono addebitati quando i dati si spostano fuori da 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 trovare i componenti ServiceNow. In genere, i server MID che eseguono la scoperta approfondita hanno costi di uscita inferiori se vengono eseguiti su Google 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, considera il numero di server MID di cui esegui il deployment di Google Cloud Compute Engine. Il deployment di più server MID consente di accelerare il processo di rilevamento delle risorse. Tuttavia, questa operazione aumenta il costo dell'elaborazione, perché 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
Il deployment probabilmente include controlli di sicurezza di rete come firewall, sistemi di protezione dalle intrusioni, sistemi di rilevamento delle intrusioni e mirroring pacchetto dell'infrastruttura. Se sono in atto controlli di sicurezza di rete estesi tra Google Cloud e l'ambiente in cui si trovano i server MID implementati, 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à una query una scoperta approfondita.
Protezione dei server MID
Ti consigliamo le seguenti pratiche di sicurezza per le istanze MID Server:
- Assicurati che i server MID siano isolati per fare in modo che solo gli amministratori attendibili possano connettersi con loro.
- Assicurati che i server MID siano protetti dall'eliminazione.
- Assicurati che i ruoli IAM vengano applicati per limitare la possibilità di modifiche solo alle modifiche approvate tramite i processi ITIL o tramite un pipeline CI/CD.
Protezione degli account di servizio
Consigliamo le seguenti best practice per la sicurezza per la gestione degli account di servizio:
- Assicurati che i server MID utilizzino un account di servizio che abbia solo Ruoli e autorizzazioni IAM assolutamente necessari per l'asset scoperta. Per ulteriori informazioni, consulta Best practice per l'utilizzo degli account di servizio.
- Autenticazione ServiceNow richiede la copia dei contenuti della chiave di un account di servizio in ServiceNow a riga di comando. Se non vengono gestite correttamente, le chiavi degli account di servizio comportano un rischio per la sicurezza. Sei responsabile della chiave privata e per le altre operazioni descritte Best practice per la gestione delle chiavi degli account di servizio. Se non riesci a creare una chiave del service account, la creazione di chiavi del service account potrebbe essere disabilitata per la tua organizzazione. Per ulteriori informazioni, vedi Gestione delle risorse dell'organizzazione sicure per impostazione predefinita.
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. Strutturando le risorse in questo modo, puoi anche ServiceNow per mappare le tue risorse ai servizi tecnici che forniscono.
Fai attenzione a qualsiasi modifica apportata alla struttura di cartelle e progetti supportare il rilevamento di ServiceNow. Il ruolo principale della struttura di cartelle e progetti è supportare la fatturazione e l'accesso IAM. Pertanto, tutte le modifiche apportate ServiceNow dovrebbe supportare e allinearsi alle Struttura di fatturazione di Google Cloud. Per conoscere le best practice per strutturare Gerarchia di organizzazioni, cartelle e progetti di Google 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 agli asset Google Cloud identificare gli asset e, facoltativamente, mapparli ai servizi. La scelta di un buon schema di etichettatura aiuta ServiceNow a monitorare l'infrastruttura report accurati e 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, potresti voler 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.
- 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 di Report di fatturazione Google Cloud o Esportazione della fatturazione Cloud in BigQuery, i dati possono essere filtrate per etichette.
Google assegna automaticamente le etichette agli asset gestiti da Google che vengono pubblicati in
in un 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 maggiori informazioni
informazioni sulle etichette per le risorse gestite da Google, consulta
Mappatura basata su tag
e
Etichetta 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.
| Servizio Google Cloud | Etichette o prefisso etichetta |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Per supportare in modo efficace la gestione delle risorse, il deployment della tua organizzazione il processo deve creare strutture di progetti e cartelle e assegnare le etichette delle risorse in modo coerente in tutta l'organizzazione. Incoerenze nell'infrastruttura e l'etichettatura può rendere difficile mantenere un CMDB corretto senza processi che probabilmente non saranno supportati e che presenteranno scalabilità sfide a lungo termine.
Il seguente elenco suggerisce le best practice per rendere la procedura di implementazione coerente e ripetibile:
- Utilizzare Infrastructure as Code (IaC) o sistemi di provisioning automatizzato come come Terraform ITOM di ServiceNow, o Provisioning e governance nel cloud con Google Cloud Deployment Manager.
- Avere un buon processo di governance per le tue etichette. Per una panoramica sulla governance dell'etichettatura, 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 strutturare le autorizzazioni IAM della tua organizzazione, vedi Best practice per la pianificazione di account e organizzazioni e Provisioning e governance nel cloud.
- Per le best practice per strutturare i tuoi criteri firewall VPC la 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, esplora il Centro architetture cloud.