Referenzarchitektur: Ressourcenverwaltung mit ServiceNow

Last reviewed 2024-01-30 UTC

In diesem Dokument werden Architekturmuster zum Suchen und Erfassen von Informationen zu Assets in Google Cloud, auf anderen Cloud-Plattformen und lokal mithilfe von ServiceNow Cloud Discovery erläutert. Das Dokument richtet sich an Architekturteams oder Cloud Operations-Teams, die mit der IT Operations-Verwaltung (ITOM), der IT-Infrastrukturbibliothek (ITIL), Google Cloud-Diensten wie Compute Engine, der Google Kubernetes Engine (GKE), dem Cloud Asset Inventory und ServiceNow Cloud Discovery vertraut sind.

Übersicht

Viele große Unternehmen nutzen eine hybride IT-Infrastrukturbereitstellung, die Google Cloud, andere Cloud-Plattformen und lokale Infrastruktur kombiniert. Eine solche Hybridbereitstellung ist normalerweise die erste Iteration in einer Cloud-Migrationsstrategie. Die IT-Abteilungen dieser Unternehmen müssen alle Assets in ihrem technischen System ermitteln und verfolgen, was möglicherweise Millionen von Millionen umfasst. Die IT-Abteilungen müssen ein Konfigurationsverwaltungssystem erstellen, das diese Assets mit den von den Assets bereitgestellten technischen Diensten verknüpft. Dieses System muss die Assets und Dienste auch so überwachen, dass Best Practices für die IT-Betriebsverwaltung (ITOM) und die IT-Dienstverwaltung (ITSM) unterstützt werden.

Für Google Cloud-Kunden nutzt eine gemeinsame Architektur die Cloud-Ressourcenerkennung von ServiceNow, um Informationen zu Assets in Google Cloud, auf anderen Cloud-Plattformen und lokal zu ermitteln und zu erfassen. ServiceNow bietet eine breite Palette von Tools zur Automatisierung von IT-Workflows für die Ressourcenverwaltung bei mehreren Cloud-Anbietern. Mit Tools wie Cloud Operations-Arbeitsbereich können IT-Abteilungen Multi-Cloud-Ressourcen-Dashboards erstellen und komplexe Konfigurationen über eine einheitliche Oberfläche (manchmal auch alsUmfassende Übersicht bezeichnet) verwalten. In diesem Dokument werden eine Reihe von Architekturmustern für dieses Szenario, eine Übersicht über die allgemeinen Komponenten und eine Erläuterung der allgemeinen Designaspekte vorgestellt.

ServiceNow-Komponenten für diese Architektur

Die ServiceNow-Plattformkomponenten in diesen Architekturmustern umfassen Folgendes:

Mit diesen Architekturmustern werden einige gängige Vorgehensweisen zum Importieren von Google Cloud Asset Inventory-Daten in die ServiceNow-Google Cloud Platform-Asset-Inventarsuche definiert.

Architekturmuster für die Google Cloud-Integration

In diesem Dokument werden die folgenden Architekturmuster zur Einbindung von Google Cloud in ServiceNow erläutert:

Diese Beispielarchitekturmuster sind für eine Hybridbereitstellung konzipiert, die einige Infrastrukturen in Google Cloud und andere in der ServiceNow-Cloud enthält. Sie zeigen, wie ServiceNow in Google Cloud zwischen der von Google verwalteten Infrastruktur und der vom Kunden verwalteten Infrastruktur funktioniert. ServiceNow MID-Server fragen die gesamte von Google verwaltete Infrastruktur ab. Dazu werden Google Cloud APIs aufgerufen. Weitere Informationen dazu, welche APIs aufgerufen werden, finden Sie unter Von ITOM-Anwendungen verwendete Google Cloud Platform APIs.

Bei jedem der folgenden Muster arbeiten die Architekturkomponenten im Asset-Erkennungsprozess für Google Cloud Platform zusammen, um die für ServiceNow Discovery-Anwendung und zugehörige Tools erforderlichen Informationen zum Cloud Asset Inventory zu erfassen.

Google Cloud Discovery-Muster

Das grundlegende Cloud Discovery-Architekturmuster von ServiceNow verwendet ServiceNow MID-Server, um Google Cloud Asset Inventory und andere Google Cloud APIs aufzurufen, um Daten zu Ressourcen wie die folgenden zu erfassen:

  • VM-Instanzen
  • Tags (Schlüssel/Wert-Paare)
  • Speicher-Volumes und Speicherzuordnung
  • Rechenzentrumsressourcen, einschließlich Hardwaretypen
  • Cloud-Netzwerke, Subnetze und Gateways
  • Bilder
  • Cloud-Load-Balancer und Verfügbarkeitszonen
  • Cloud-Datenbanken und Datenbankcluster
  • Container (GKE)
  • Dienstzuordnung anhand von Ressourcenlabels

In diesem Muster benötigen die MID-Server keine Anmeldedaten, da sie sich nicht bei den VMs anmelden, um Daten zu erfassen. Dadurch wird die Fähigkeit des Erkennungsprozesses eingeschränkt, zusätzliche Informationen zu erfassen. Allerdings fallen dabei weniger Betriebskosten an, da MID-Serveranmeldedaten nicht verwaltet und rotiert werden müssen.

Diese Architektur wird im folgenden Diagramm veranschaulicht.

Diagramm mit dem Muster der Google Cloud-Erkennungsarchitektur.

Der Google Cloud-Teil dieses Musters besteht aus folgenden Elementen:

  • Ein Google Cloud-Projekt (Dienstprojekt A im Diagramm), das aus zwei Google Cloud-Load-Balancern, einer oder mehreren VM-Instanzen, einer GKE-Instanz und einem oder mehreren ServiceNow-MID-Servern besteht. Jeder MID-Server wird auf einer eigenen VM ausgeführt.
  • Ein zweites Google Cloud-Projekt (Dienstprojekt B im Diagramm), das aus MID-Servern besteht, die in ihren eigenen VMs ausgeführt werden.
  • Ein drittes Google Cloud-Projekt (Hostprojekt C im Diagramm), das aus der Partner Interconnect-Verbindung besteht.
  • Zusätzliche verwaltete Dienste wie Cloud APIs, BigQuery und Cloud Storage
  • Netzwerkrouten, die von den MID-Servern zu den Google Cloud APIs eingerichtet sind.

Der ServiceNow-Teil besteht aus der ServiceNow-Instanz, die die Metadaten von den MID-Servern erfasst und in der CMDB speichert.

IP-basiertes Erkennungsmuster für Google Cloud-Agents

Bei diesem Architekturmuster wird dem grundlegenden Cloud Discovery-Muster mithilfe eines Batchjobs und eines Google Cloud-Dienstkontos die IP-basierte Erkennung hinzugefügt, um sich bei VMs anzumelden und zusätzliche Details zu erfassen. Dieses Muster erfordert mehr operativen Aufwand für die Verwaltung des MID-Servers als das grundlegende Muster, da Sie die MID Server-Anmeldedaten verwalten und rotieren müssen. Dadurch wird jedoch der Erkennungsprozess über die von Cloud Asset Inventory bereitgestellten Daten hinaus erweitert, um zusätzliche Daten hinzuzufügen, z. B.:

  • Verwaltung und Sicherheit von Betriebssystem-Anmeldedaten
  • Erweiterte Erkennung, z. B. dateibasierte Erkennung und Erkennung von Lizenzen
  • Details zum Betriebssystem
  • Laufende Prozesse
  • TCP-Verbindungen
  • Installierte Software

In diesem Architekturmuster befinden sich ein oder mehrere ServiceNow MID-Server in Google Cloud, während die ServiceNow-Instanz auf der ServiceNow-Cloud-Plattform gehostet wird. Die MID-Server sind über die ECC-Warteschlange (External Communication Channel) von MID-Server mit der ServiceNow-Instanz verbunden. Diese Architektur ist im folgenden Diagramm dargestellt:

Diagramm mit dem IP-basierten Discovery-Muster für Google Cloud-Agents ohne Agent.

Der Google Cloud-Teil dieses Musters besteht aus folgenden Elementen:

  • Dienstprojekt A, das aus zwei Google Cloud-Load-Balancern, einer oder mehreren VMs, einer GKE-Instanz und einem oder mehreren ServiceNow-MID-Servern besteht. Jeder MID-Server wird auf einer eigenen VM ausgeführt.
  • Dienstprojekt B, das aus MID-Servern besteht, die in ihren eigenen VMs ausgeführt werden.
  • Hostprojekt C, das aus der Partner Interconnect-Verbindung besteht.
  • Zusätzliche verwaltete Dienste wie Cloud APIs, BigQuery und Cloud Storage
  • ServiceNow Kubernetes Discovery in der GKE-Infrastruktur.
  • Netzwerkrouten, die von den MID-Servern zu den Google Cloud APIs eingerichtet sind.
  • Dienstkonten, mit denen sich MID-Server bei allen Google Cloud-VMs anmelden können, für die eine serverlose IP-Adresserkennung erforderlich ist.
  • Netzwerkrouten, die von den MID-Servern zu den Google Cloud-VMs eingerichtet werden, die eine serverlose IP-Adresserkennung erfordern.

Der ServiceNow-Teil besteht aus der ServiceNow-Instanz, die die Metadaten von den MID-Servern erfasst und in der CMDB speichert.

Google Cloud-Erkennung mit Agent Client Collector-Muster

Dieses Architekturmuster beinhaltet Folgendes:

  • Die erste Cloud Discovery.
  • Einen oder mehrere MID-Server.

  • Einen zusätzlichen ServiceNow-Agent, den Agent Client Collector, den Sie auf Ihren VMs installieren. Diese Agents stellen eine direkte Verbindung zu den MID-Servern her und leiten die folgenden zusätzlichen Informationen an ServiceNow weiter:

    • Echtzeitnahe, Push-basierte Discovery-Erkennung
    • Software-Messung
    • Live-CI-Ansicht
    • Workflow-Automatisierung zu Servern

Diese Architektur wird im folgenden Diagramm veranschaulicht.

Diagramm, das die Google Cloud-Erkennung mit dem Agent Client Collector-Muster zeigt.

Der Google Cloud-Teil dieses Musters besteht aus folgenden Elementen:

  • Dienstprojekt A, das aus zwei Google Cloud-Load-Balancern, einer oder mehreren VM-Instanzen, einer GKE-Instanz und einem oder mehreren ServiceNow-MID-Servern besteht. Jeder MID-Server wird auf einer eigenen VM ausgeführt.
  • Dienstprojekt B, das aus MID-Servern besteht, die in ihren eigenen VMs ausgeführt werden.
  • Hostprojekt C, das aus der Partner Interconnect-Verbindung besteht.
  • ServiceNow Kubernetes Discovery in der GKE-Infrastruktur.
  • Zusätzliche verwaltete Dienste wie Cloud APIs, BigQuery und Cloud Storage
  • Netzwerkrouten, die von den MID-Servern zu den Google Cloud APIs eingerichtet sind.
  • Netzwerkrouten, die von den MID-Servern zu Google Cloud-VMs eingerichtet werden, auf denen ServiceNow Discovery-Agents installiert sind.

Der ServiceNow-Teil besteht aus folgenden Komponenten:

  • Die ServiceNow-Instanz, die die Metadaten von den MID-Servern erfasst und in der CMDB speichert.
  • ServiceNow-Discovery-Agents, die auf vom Kunden verwalteten Google Cloud-VMs installiert sind.

Workflow für die Cloud-Asset-Erkennung

In den folgenden Abschnitten wird der Workflow für die Google Cloud-Asset-Erkennung erörtert. Dieser Workflow gilt für alle drei in diesem Dokument beschriebenen Architekturmuster.

ServiceNow-Komponenten installieren und konfigurieren

  1. Aktivieren Sie die Cloud Asset Inventory APIs.
  2. Installieren Sie den Agent Client Collector auf Ihren VMs. Weitere Informationen finden Sie unter Agent Client Collector-Installation.
  3. Weisen Sie Ressourcen für Computer zu, die die MID-Server hosten.
  4. Konfigurieren Sie Firewallregeln, um Verbindungen an Port 443 zwischen Ihrer VM-Instanz und den Computern zuzulassen, auf denen die MID-Server gehostet werden.
  5. Konfigurieren Sie die MID Server-Netzwerkverbindung.
  6. Installieren Sie die MID-Server.
  7. Konfigurieren Sie die MID-Server so, dass sie die relevanten Google Cloud APIs aufrufen. Achten Sie darauf, dass die MID-Server eine gültige Netzwerkroute für den Aufruf von Google Cloud APIs haben.

Workflow

  1. Cloud Asset Inventory kompiliert eine Datenbank mit allen unterstützten Asset-Typen in der Google Cloud-Umgebung. ServiceNow verwendet Cloud Asset Inventory als Quelle, um zusätzliche Informationen zum Aktualisieren der CMDB abzurufen.
  2. Die ServiceNow MID-Server fragen die Cloud Asset Inventory-Datenbank nach Informationen zu allen Assets in der Google Cloud-Umgebung ab.
  3. Die MID-Server speichern die Cloud-Asset-Informationen in einem Cloud Storage-Bucket.
  4. Nicht alle erforderlichen Informationen können aus der Cloud Asset Inventory-Datenbank abgerufen werden. Im Muster ohne Agent enthalten die VM-Informationen nicht die aktuelle Version des Betriebssystem-Patches. Für diese Detailebene führen die MID-Server eine Deep Discovery durch. Dazu werden sie so ausgeführt:
    1. Die MID-Server erstellen einen Batchjob anhand der IP-Adressen der VMs, die eine Deep Discovery erfordern.
    2. Bei dem Batchjob melden sich die MID-Server bei jeder VM an und fragen das Betriebssystem nach der Patchversionsverwaltung und anderen Informationen ab.
  5. Wenn Agent Client Collector installiert sind, werden die erfassten Daten direkt an die MID-Server übertragen und nicht in der Cloud Asset Inventory-Datenbank gespeichert. Weitere Informationen finden Sie unter Netzwerkvorbereitung und MID-Serverkonfiguration.
  6. Nachdem die Asset-Erkennungsdaten erfasst wurden, werden sie von den MID-Servern in der CMDB gespeichert:
    1. Die MID-Server erstellen CIs in der CMDB, um die operative Fähigkeit des jeweiligen Assets darzustellen.
    2. Die MID-Server erkennen automatisch Labels aus Google Cloud und speichern sie in der CMDB. Diese Labels werden den CIs automatisch zugeordnet und sind zum Erstellen von Dienstzuordnungen nützlich.

Der Workflowprozess sollte regelmäßig nach Bedarf wiederholt werden. Je nach Umfang und Konfiguration der Bereitstellung können Sie eine ereignisbasierte oder zeitplanbasierte Erkennung auswählen. Weitere Informationen finden Sie unter "CI-Lebenszyklus verwalten" in der Anleitung zum CMDB-Design.

Überlegungen zum Design

Die folgenden Abschnitte enthalten Designanleitungen für die Implementierung der in diesem Dokument beschriebenen Architekturmuster.

Standort der ServiceNow-Instanz

Für die meisten Anwendungsfälle empfehlen wir die Bereitstellung der MID-Server in Google Cloud. Auf diese Weise befinden sich die Instanzen in der Nähe der Cloud-Assets, für die sie eine Deep Discovery durchführen.

Bei den Architekturmustern in diesem Dokument wird davon ausgegangen, dass Ihre CMDB für alle Cloud-Ressourcen und für alle lokalen Ressourcen Discovery-Daten speichert, nicht nur für Ihre Google Cloud-Assets. Die CMDB kann sich in der ServiceNow-Cloud, in Google Cloud oder lokal befinden. Ob Sie die CMDB in Ihrer Umgebung finden, hängt von Ihren speziellen Anforderungen ab.

MID Server-Agents verwenden

Ein weiterer Designaspekt ist die Verwendung von MID-Server-Agents und -Dienstkonten. Wenn Ihr Erkennungsprozess Informationen über die Metadaten hinaus erfassen muss, die Cloud Asset Inventory bietet, müssen Sie eine MID Server-Infrastruktur mit Dienstkonten oder alternativ einen MID-Server mitAgent-Client-Collector verwenden. Beide Ansätze können sich auf Ihre Betriebskosten auswirken, die Sie bei der Entwicklung berücksichtigen müssen. Welche Vorgehensweise Sie verwenden sollten, hängt davon ab, welche Daten Sie erfassen müssen und wie Sie die Daten verwenden. Die Betriebskosten für die Erfassung der Daten können den Wert der Daten überwiegen.

Multiregionale Unterstützung von MID-Servern

Wenn Ihr Unternehmen multiregionale Unterstützung der MID-Serverinfrastruktur benötigt, sollten Sie jeden MID-Server in mindestens zwei Verfügbarkeitszonen bereitstellen und in eine andere Region replizieren.

Auswirkungen auf die Kosten

Wenn Sie auswählen, wo die ServiceNow-Komponenten für die Google Cloud-Asset-Erkennung bereitgestellt werden sollen, müssen Sie die Kosten für ausgehenden Traffic und die Computing-Kosten berücksichtigen.

Kosten für ausgehenden Traffic

Gebühren für ausgehenden Traffic fallen an, wenn Daten aus Google Cloud verschoben werden. Aus diesem Grund sollten Sie die Kosten für ausgehenden Traffic für Ihren Anwendungsfall analysieren, um die beste Option für die Suche nach Ihren ServiceNow-Komponenten zu ermitteln. Für MID-Server, die eine umfassende Erkennung durchführen, fallen in der Regel niedrigere Kosten für ausgehenden Traffic an, wenn sie in Google Cloud ausgeführt werden als bei einer anderen Cloud oder lokalen Umgebungen.

Compute-Kosten

Für ServiceNow-Komponenten, die in Google Cloud ausgeführt werden, fallen Computing-Kosten an, die Sie analysieren sollten, um den besten Wert für Ihr Unternehmen zu erzielen.

Berücksichtigen Sie beispielsweise die Anzahl der MID-Server, die Sie in Google Cloud Compute Engine-Instanzen bereitstellen. Durch die Bereitstellung weiterer MID-Server wird der Asset-Erkennungsprozess schneller. Dies erhöht jedoch die Rechenkosten, da jeder MID-Server in einer eigenen VM-Instanz bereitgestellt wird. Weitere Informationen zum Bereitstellen eines oder mehrerer MID-Server finden Sie unter Mehrere MID-Server auf einem einzelnen System installieren.

Überlegungen zur operativen Unterstützung

Ihre Bereitstellung enthält wahrscheinlich Netzwerksicherheitskontrollen wie Firewalls, Systeme zum Schutz vor Angriffen, Angriffserkennungssysteme und die Paketspiegelungsinfrastruktur. Wenn zwischen der Google Cloud und der Umgebung, in der die MID-Server bereitgestellt werden, umfangreiche Sicherheitskontrollen vorhanden sind, können diese Kontrollen Probleme mit der operativen Unterstützung verursachen. Zur Vermeidung dieser Probleme empfehlen wir, die MID-Server in Google Cloud zu hosten oder möglichst nahe an der Google Cloud-Infrastruktur, die von einer Deep Discovery abgefragt wird.

MID-Server sichern

Wir empfehlen die folgenden Sicherheitsmaßnahmen für Ihre MID Server-Instanzen:

Dienstkonten sichern

Wir empfehlen die folgenden Sicherheitsmaßnahmen für die Verwaltung von Dienstkonten:

Ordner- und Projektstruktur

Ordner und Projekte sind Knoten in der Google Cloud-Ressourcenhierarchie. Um die Asset-Erkennung zu unterstützen, sollten Ihre Ordner- und Projektstruktur die Struktur Ihrer Anwendung und der Umgebungen widerspiegeln, in denen die Anwendung bereitgestellt wird. Wenn Sie Ihre Ressourcen auf diese Weise strukturieren, kann ServiceNow Ihre Assets den von ihnen bereitgestellten technischen Diensten zuordnen.

Achten Sie auf Änderungen, die Sie an der Ordner- und Projektstruktur vornehmen, um die ServiceNow-Erkennung zu unterstützen. Die Hauptrolle der Ordner- und Projektstruktur besteht darin, die Abrechnung und den IAM-Zugriff zu unterstützen. Daher sollten alle Änderungen, die Sie an ServiceNow vornehmen, die Google Cloud-Abrechnungsstruktur unterstützen und an diese anpassen. Best Practices zum Strukturieren Ihrer Google Cloud-Organisation, Ihrer Ordner- und Projekthierarchie finden Sie unter Ressourcenhierarchie und Organisationen erstellen und verwalten.

Im folgenden Diagramm ist ein Beispiel für die vollständige Google Cloud-Ressourcenhierarchie dargestellt. In diesem Beispiel wird die Anwendung durch die Ordnerstruktur definiert. Jedes Projekt definiert eine Umgebung.

Diagramm, das ein Beispiel für eine Google Cloud-Ressourcenhierarchie zeigt.

Labeling

Labels sind Schlüssel/Wert-Paare, die Sie Ihren Cloud-Ressourcen zuweisen können. (ServiceNow, AWS und Azure bezeichnen Labels als Tags.)

ServiceNow verwendet die Labels, die Sie Ihren Google Cloud-Assets zuweisen, um Ihre Assets zu identifizieren und optional Diensten zuzuordnen. Wenn Sie ein gutes Labeling-Schema auswählen, kann ServiceNow Ihre Infrastruktur auf genaue Berichte und ITOM/ITSM-Compliance überwachen.

Wir empfehlen, Labels für alle Ressourcen zu verwenden, die eine eindeutige Identifizierung erfordern, die spezifischer als Ihre Ordner- und Projektstruktur ist. Beispielsweise können Sie in folgenden Fällen Labels verwenden:

  • Wenn strenge Compliance-Anforderungen für Ihre Anwendung gelten, können Sie alle Anwendungsressourcen mit einem Label versehen, damit Ihre Organisation alle relevanten Infrastrukturen leicht identifizieren kann.
  • In einer Multi-Cloud-Umgebung können Sie Labels verwenden, um den Cloud-Anbieter und die Region für alle Ressourcen zu identifizieren.
  • Wenn Sie eine detailliertere Sichtbarkeit benötigen als die standardmäßig von Google Cloud Billing-Berichten oder Cloud Billing-Export nach BigQuery bereitgestellten Informationen, können die Daten nach Labels gefiltert werden.

Google weist Google-verwalteten Assets, die in Ihrer VPC ausgeführt werden, automatisch Labels zu. Von Google zugewiesene Labels haben das Präfix goog-. Ihre MID-Server sollten nicht versuchen, eine detaillierte Prüfung dieser Assets durchzuführen. Weitere Informationen zu Labels für von Google verwaltete Ressourcen finden Sie unter Tag-basierte Zuordnung und Ressourcen anhand von Cloud Asset Inventory-Echtzeitbenachrichtigungen automatisch mit Labels versehen.

In der folgenden Tabelle sind die Labels aufgeführt, die Google Cloud-Dienste Ressourcen zuweisen, die von diesen Diensten verwaltet werden.

Google Cloud-Dienst Labels oder Labelpräfix
Google Kubernetes Engine goog-gke-
Compute Engine

goog-gce-

Dataproc

goog-dataproc-

Vertex AI Workbench

goog-caip-notebook and goog-caip-notebook-volume

Für eine effektive Ressourcenverwaltung muss der Bereitstellungsprozess Ihrer Organisation Projekt- und Ordnerstrukturen erstellen und Asset-Labels in der gesamten Organisation konsistent zuweisen. Inkonsistenzen bei Infrastruktur und Labeling können es schwierig machen, eine korrekte CMDB ohne manuelle Prozesse zu verwalten, die wahrscheinlich nicht unterstützt werden und langfristig Herausforderungen bei der Skalierung darstellen.

In der folgenden Liste werden Best Practices empfohlen, um den Bereitstellungsprozess konsistent und wiederholbar zu gestalten:

Nächste Schritte