In diesem Leitfaden wird der konzeptionelle Kontext beschrieben, der erforderlich ist, um eine auf einer virtuellen Maschine (VM) basierende Arbeitslast in einem Air-Gap-Cluster von Google Distributed Cloud (GDC) auf Bare Metal mit einer VM-Laufzeit bereitzustellen. Die Arbeitslast in diesem Leitfaden ist eine Beispiel-ServiceNow-Plattform, die auf lokaler Hardware verfügbar ist.
Architektur
Ressourcenhierarchie
In GDC stellen Sie die Komponenten, aus denen ServiceNow besteht, in einer dedizierten Mandantenorganisation für das Operations-Team bereit, die mit jeder Kundenorganisation identisch ist. Eine Organisation ist eine Sammlung von Clustern, Infrastrukturressourcen und Anwendungsarbeitslasten, die gemeinsam verwaltet werden. Jede Organisation in einer GDC-Instanz verwendet einen dedizierten Satz von Servern, was eine starke Isolation zwischen Mandanten ermöglicht. Weitere Informationen zur Infrastruktur finden Sie unter Zugriffsgrenzen entwerfen.
Außerdem stellen Sie ServiceNow-Ressourcen zusammen in einem Projekt bereit und verwalten sie dort. Dies bietet eine logische Isolation innerhalb einer Organisation durch Software-Richtlinien und die Durchsetzung von Richtlinien. Ressourcen in einem Projekt sind dazu gedacht, Komponenten zu koppeln, die während ihres Lebenszyklus zusammenbleiben müssen.
ServiceNow folgt einer dreistufigen Architektur, die auf einem Load Balancer basiert, um den Traffic über Anwendungsserver zu leiten, die eine Verbindung zu einem Datenbankserver herstellen, auf dem persistente Daten gespeichert werden.
Diese Architektur ermöglicht Skalierbarkeit und Wartungsfreundlichkeit, da jede Ebene unabhängig entwickelt und gewartet werden kann. Außerdem wird eine klare Trennung der Anliegen erreicht, was die Fehlersuche und ‑behebung vereinfacht. Wenn Sie diese Ebenen in einem GDC-Projekt kapseln, können Sie Komponenten wie Ihre Anwendungs- und Datenbankserver gemeinsam bereitstellen und verwalten.
Netzwerk
Für die Ausführung von ServiceNow in einer Produktionsumgebung müssen mindestens zwei Anwendungsserver bereitgestellt werden, um im Falle eines Knotenausfalls eine hohe Verfügbarkeit zu erreichen. In Kombination mit einem Load Balancer ermöglicht diese Topologie auch die Verteilung der Last auf mehrere Maschinen, um die Anwendung horizontal zu skalieren. Die Kubernetes-native Plattform von GDC nutzt Cloud Service Mesh, um Traffic sicher an die Anwendungsserver weiterzuleiten, aus denen ServiceNow besteht.
Cloud Service Mesh ist eine Implementierung von Google, die auf dem Open-Source-Projekt Istio basiert und Dienste verwaltet, beobachtet und schützt. Die folgenden Funktionen von Cloud Service Mesh werden verwendet, um ServiceNow auf GDC zu hosten:
- Lastenausgleich: In Cloud Service Mesh wird der Trafficfluss von der Infrastrukturskalierung entkoppelt. Dadurch werden viele Funktionen zur Trafficverwaltung möglich, darunter dynamisches Anfragerouting. ServiceNow erfordert persistente Clientverbindungen. Daher aktivieren wir Sticky Sessions mit
DestinationRules, um das Traffic-Routingverhalten zu konfigurieren.
TLS-Terminierung: Cloud Service Mesh stellt Ingress-Gateways mit TLS-Zertifikaten bereit und bietet Transportauthentifizierung im Cluster über mTLS (Mutual Transport Layer Security), ohne dass Anwendungscode geändert werden muss.
Wiederherstellung nach Fehlern: Cloud Service Mesh bietet eine Reihe wichtiger Funktionen zur Wiederherstellung nach Fehlern, darunter Zeitüberschreitungen, Unterbrechungen der Netzwerkverbindung, aktive Systemdiagnosen und begrenzte Wiederholungsversuche.
Im Kubernetes-Cluster verwenden wir standardmäßige Service-Objekte, um die Anwendungs- und Datenbankserver auf abstrakte Weise für das Netzwerk verfügbar zu machen. Dienste bieten eine praktische Möglichkeit, Instanzen mithilfe eines Selektors anzusprechen und die Namensauflösung im Cluster mithilfe eines clusterfähigen DNS-Servers zu ermöglichen.
apiVersion: v1
kind: Service
metadata:
name: http-ingress
spec:
selector:
app.kubernetes.io/component: application-server
ports:
- name: http
port: 80
---
apiVersion: v1
kind: Service
metadata:
name: database-ingress
spec:
selector:
app.kubernetes.io/component: database-server
ports:
- name: mysql
port: 3306
Compute
ServiceNow empfiehlt, Bare-Metal- oder virtuelle Maschinen für das Hosting lokaler Installationen zu verwenden. Wir haben die GDC-VM-Verwaltung genutzt, um sowohl die Anwendungs- als auch die Datenbankserver als VM-Arbeitslasten bereitzustellen. Durch das Definieren von Kubernetes-Ressourcen konnten wir sowohl VirtualMachine als auch VirtualMachineDisk angeben, um Ressourcen an unsere Anforderungen für die verschiedenen Arten von Servern anzupassen. Mit VirtualMachineExternalAccess können wir die Datenübertragung in und aus der VM konfigurieren.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
name: vm1-boot-disk
spec:
size: 100G
source:
image:
name: ts-service-now-system-app-server-2023-08-18-203258
namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
labels:
app.kubernetes.io/component: application-server
name: vm1
namespace: support
spec:
compute:
vcpus: 8
memory: 12G
disks:
- boot: true
virtualMachineDiskRef:
name: vm1-boot-disk
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
name: vm1
namespace: support
spec:
enabled: true
ports:
- name: ssh
protocol: TCP
port: 22
Für das Gastbetriebssystem-Image haben wir ein benutzerdefiniertes Image auf Basis von Red Hat Enterprise Linux erstellt, um unsere Anforderungen an Compliance und Sicherheit zu erfüllen. Die Verbindung zu laufenden VM-Instanzen ist über SSH mit VirtualMachineAccessRequest möglich. So können wir die Möglichkeit, eine Verbindung zu VMs herzustellen, über Kubernetes RBAC einschränken und müssen keine lokalen Nutzerkonten in den benutzerdefinierten Images erstellen. In der Zugriffsanfrage wird auch eine Gültigkeitsdauer (Time to Live, TTL) definiert, sodass zeitbasierte Zugriffsanfragen zur Verwaltung der VMs verwendet werden können, die automatisch ablaufen.
Automatisierung
Als wichtiges Ergebnis dieses Projekts haben wir einen Ansatz für die wiederholbare Installation von ServiceNow-Instanzen entwickelt, der eine umfassende Automatisierung ermöglicht und Konfigurationsabweichungen zwischen Bereitstellungen reduziert.
Helm-Paket
Helm ist ein Paketmanager für Kubernetes, der den Lebenszyklus von Anwendungen verwaltet, einschließlich der Installation und des Upgrades aller Komponenten, aus denen eine Anwendung besteht. Helm bietet auch eine Möglichkeit, Abhängigkeiten zu verwalten, z. B. benutzerdefinierte Ressourcen, die für die Integration in andere Systeme wie Observability und Compliance erforderlich sind. Durch das Erstellen von Helm-Charts können wir diese Ressourcen kapseln und so die Installation und Verwaltung von ServiceNow vereinfachen.
Release-Pipeline
Die Anpassung der Anwendungs- und Datenbankserver-Images beginnt mit einem Basis-Betriebssystem-Image. Das Basis-Image wird nach Bedarf geändert, um die für jedes Server-Image erforderlichen Abhängigkeiten zu installieren. Wir haben Red Hat Enterprise Linux (RHEL) als Basis-Betriebssystemimage ausgewählt, da es häufig für das Hosting von ServiceNow in lokalen Installationen verwendet wird. Red Hat Enterprise Linux bietet außerdem die erforderlichen Sicherheitsfunktionen, um die Security Technical Implementation Guides (STIGs) zu erfüllen, die für die Bereitstellung eines konformen Images erforderlich sind, das den NIST-800-53-Kontrollen entspricht.
In unserer CI-Pipeline (Continuous Integration) wurde der folgende Workflow verwendet, um Anwendungs- und Datenbankserver-Images anzupassen:
Wenn Entwickler Änderungen an den Anpassungsskripts oder Bildabhängigkeiten vornehmen, wird in unseren CI-Tools ein automatisierter Workflow ausgelöst, um einen neuen Satz von Bildern zu generieren, die in GDC-Releases enthalten sind. Im Rahmen der Image-Erstellung aktualisieren wir auch die Betriebssystemabhängigkeiten (yum update) und komprimieren das Image, um die für die Übertragung von Images in Kundenumgebungen erforderliche Image-Größe zu reduzieren.
Softwareentwicklungszyklus
Der Software-Entwicklungslebenszyklus (Software Development Life Cycle, SDLC) ist ein Prozess, der Organisationen bei der Planung, Erstellung, dem Testen und der Bereitstellung von Software unterstützt. Durch die Einhaltung eines klar definierten SDLC stellen Unternehmen sicher, dass Software auf konsistente und wiederholbare Weise entwickelt wird, und können potenzielle Probleme frühzeitig erkennen. Neben dem Erstellen von Images in unserer CI-Pipeline (Continuous Integration) haben wir auch Umgebungen für die Entwicklung und das Staging von Vorabversionen von ServiceNow für Tests und Qualitätssicherung definiert.
Durch die Bereitstellung einer separaten ServiceNow-Instanz pro GDC-Projekt konnten wir Änderungen isoliert testen, ohne dass sich dies auf vorhandene Instanzen in derselben GDC-Instanz auswirkte. Wir haben die ResourceManager API verwendet, um Projekte deklarativ mit Kubernetes-Ressourcen zu erstellen und zu löschen.
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
name: service-now-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
name: service-now-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
name: service-now-staging
In Kombination mit der Helm-Chart-Paketierung und der Verwaltung von Infrastruktur wie virtuellen Maschinen als Code können Entwickler schnell Änderungen vornehmen und neue Funktionen neben Produktionsinstanzen testen. Die deklarative API ermöglicht es auch, dass automatisierte Testausführungs-Frameworks regelmäßige Regressionstests durchführen und vorhandene Funktionen überprüfen.
Bedienbarkeit
Die Bedienbarkeit beschreibt, wie einfach ein System bedient und gewartet werden kann. Sie ist ein wichtiger Aspekt beim Design jeder Softwareanwendung. Ein effektives Monitoring trägt zur Betriebsfähigkeit bei, da Probleme erkannt und behoben werden können, bevor sie sich erheblich auf das System auswirken. Mit dem Monitoring lassen sich auch Verbesserungsmöglichkeiten ermitteln und eine Baseline für Service Level Objectives (SLO) festlegen.
Monitoring
Wir haben ServiceNow in die vorhandene GDC-Infrastruktur für die Beobachtbarkeit integriert, einschließlich Logging und Messwerten. Für Messwerte stellen wir HTTP-Endpunkte von jeder VM bereit, damit Prometheus von den Anwendungs- und Datenbankservern erstellte Datenpunkte abrufen kann. Diese Endpunkte enthalten Systemmesswerte, die mit dem Prometheus-Node-Exporter erfasst werden, und anwendungsspezifische Messwerte, z. B. mit einem MySQL-Datenbank-Exporter.
Da in jeder VM Endpunkte verfügbar sind, haben wir das Prometheus-Polling-Verhalten mit der benutzerdefinierten Ressource MonitoringTarget konfiguriert, um das Scraping-Intervall zu definieren und die Messwerte zu annotieren.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
name: database-monitor
spec:
podMetricsEndpoints:
path:
value: /metrics
port:
annotation: application.io/dbMetrics
scrapeInterval: 60s
Für die Protokollierung haben wir FluentBit auf jeder VM installiert und konfiguriert, um relevante Logs zu erfassen und Logdaten an Loki zu senden. Dort werden die Daten indexiert und über Grafana abgefragt. Audit-Logs werden an einen speziellen Endpunkt weitergeleitet, der für die Compliance mit einer verlängerten Aufbewahrungsdauer konfiguriert ist. Containerbasierte Anwendungen können die benutzerdefinierten Ressourcen LoggingTarget und AuditLoggingTarget verwenden, um die Logging-Pipeline anzuweisen, Logs von bestimmten Diensten in Ihrem Projekt zu erfassen.
Anhand der in Prometheus und Loki verfügbaren Daten haben wir Benachrichtigungen mit der benutzerdefinierten Ressource MonitoringRule erstellt. So können wir diese Konfiguration als Code in unserem Helm-Chart verwalten. Durch die Verwendung einer deklarativen API zum Definieren von Benachrichtigungen und Dashboards können wir diese Konfiguration auch in unserem Git-Repository speichern und dieselben Codeüberprüfungs- und Continuous Integration-Prozesse verwenden, die wir für alle anderen Codeänderungen nutzen.
Fehlermodi
Bei den ersten Tests wurden mehrere ressourcenbezogene Fehlermodi erkannt, die uns geholfen haben, zu priorisieren, welche Messwerte und Benachrichtigungen zuerst hinzugefügt werden sollten. Wir haben zuerst die hohe Arbeitsspeicher- und Festplattennutzung überwacht, da eine Fehlkonfiguration der Datenbank anfangs dazu führte, dass Puffertabellen den gesamten verfügbaren Arbeitsspeicher belegten und durch zu viel Logging die angehängte nichtflüchtige Speicherfestplatte gefüllt wurde. Nachdem wir die InnoDB-Puffergröße angepasst und eine Log-Rotation-Strategie implementiert hatten, haben wir Benachrichtigungen eingeführt, die ausgelöst werden, wenn die VMs eine hohe Arbeitsspeicher- oder Festplattennutzung erreichen. Wir haben auch ein Runbook erstellt und einen Fehlercode zugewiesen, damit Bediener bei Auslösung der Benachrichtigung schnell die Dokumentation zur Diagnose und Behebung des Problems aufrufen können.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
name: monitoring-rule
spec:
interval: 60s
limit: 0
alertRules:
- alert: vm1_disk_usage
expr:
(node_filesystem_size_bytes{container_name="compute"} -
node_filesystem_avail_bytes{container_name="compute"}) * 100 /
node_filesystem_size_bytes{container_name="compute"} > 90
labels:
severity: error
code: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
resource: vm1
annotations:
message: "vm1 disk usage above 90% utilization"
Nachdem wir die Systemstabilität überprüft hatten, konzentrierten wir uns auf Anwendungsfehlermodi in ServiceNow. Da wir zum Beheben von Problemen in der Anwendung oft eine SSH-Verbindung zu jeder Anwendungsserver-VM herstellen mussten, um die ServiceNow-Systemlogs zu prüfen, haben wir FluentBit so konfiguriert, dass diese Logs an Loki weitergeleitet werden. So konnten wir den GDC-Observability-Stack nutzen und alle ServiceNow-Betriebslogs in Grafana abfragen.
Das zentrale Logging ermöglichte es uns auch, Logs von mehreren VMs gleichzeitig abzufragen, wodurch wir einen besseren Überblick über die einzelnen Komponenten des Systems erhielten. Anschließend haben wir Logsuchen in unsere Runbooks aufgenommen, damit Bediener Fehlerbedingungen mit bekannten Problemumgehungen und Lösungen abgleichen können.
Sicherungen
Sicherungen sind für die Funktionsfähigkeit eines Softwaresystems wichtig, da das System im Falle eines Fehlers wiederhergestellt werden kann.
GDC bietet VM-Sicherung und ‑Wiederherstellung über Kubernetes-Ressourcen. Durch das Erstellen einer benutzerdefinierten VirtualMachineBackupRequest-Ressource mit einer benutzerdefinierten VirtualMachineBackupPlanTemplate-Ressource können wir das nichtflüchtige Volume, das an jede VM angehängt ist, in einem Objektspeicher sichern. Dort können die Sicherungen gemäß einer Aufbewahrungsrichtlinie aufbewahrt werden, die über einen Bucket festgelegt wird.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
name: vm-backup-plan
spec:
backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
name: "db-vm-backup"
spec:
virtualMachineBackupPlanTemplate: vm-backup-plan
virtualMachine: db1
virtualMachineBackupName: db-vm-backup
Ebenso wird beim Wiederherstellen eines VM-Status aus einem Backup eine benutzerdefinierte Ressource vom Typ VirtualMachineRestoreRequest erstellt, um sowohl Anwendungs- als auch Datenbankserver wiederherzustellen, ohne den Code oder die Konfiguration für einen der beiden Dienste zu ändern.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
name: vm-restore-1
spec:
virtualMachineBackup: db-vm-backup
restoreName: restore1
restoredResourceName: db1
Upgrades
Um den Softwarelebenszyklus von ServiceNow und seinen Abhängigkeiten zu unterstützen, haben wir drei Arten von Software-Upgrades identifiziert, die jeweils etwas anders gehandhabt werden, um Ausfallzeiten und Dienstunterbrechungen zu minimieren:
- Betriebssystem-Upgrades.
- Plattform-Upgrades wie Patch- und Hauptversionen.
- Konfigurationsupdates.
Für Betriebssystem-Upgrades erstellen und veröffentlichen wir kontinuierlich neue VM-Images für Anwendungs- und Datenbankserver, die mit jedem GDC-Release verteilt werden. Diese Images enthalten Korrekturen für Sicherheitslücken und Updates für das zugrunde liegende Red Hat-Betriebssystem. Um die neuen Images bereitzustellen, folgen Bediener Runbooks, in denen die erforderlichen Schritte zum Hochladen und Starten neuer VMs, zum Überprüfen der Konfiguration und zum Außerbetriebnehmen früherer Instanzen beschrieben werden.
Für ServiceNow-Plattform-Upgrades müssen Updates auf die vorhandenen VM-Images angewendet werden. Daher können wir uns nicht auf eine unveränderliche Infrastruktur verlassen, um Patches und Updates für Hauptversionen durchzuführen. Bei Plattform-Upgrades testen und überprüfen wir die Patch- oder Hauptrelease-Version in unseren Entwicklungs- und Staging-Umgebungen, bevor wir zusammen mit dem GDC-Release ein eigenständiges Upgrade-Paket veröffentlichen. Um Patches und Hauptversions-Upgrades anzuwenden, folgen Bediener Runbooks, um eine Verbindung zu den vorhandenen VM-Instanzen herzustellen, das Upgrade-Paket hochzuladen und das Upgrade von jeder ausgeführten VM aus zu starten.
Konfigurationsupdates werden ohne Ausfallzeiten über die ServiceNow-APIs für Aktualisierungssätze und andere Nutzerdaten angewendet. Wir entwickeln und testen Konfigurationsupdates in unseren Entwicklungs- und Stagingumgebungen, bevor wir mehrere Updatesätze während des GDC-Releaseprozesses zusammenfassen. Die Bediener folgen dann Runbooks, um ein von uns entwickeltes Befehlszeilentool aufzurufen, das die entsprechenden ServiceNow-APIs aufruft, um Update-Sets hochzuladen und anzuwenden.
Integrationen
Identitätsanbieter
Um Kunden einen nahtlosen Übergang zu ermöglichen und Organisationen die Möglichkeit zu geben, ihre Nutzer zu registrieren, haben wir ServiceNow in mehrere Identitätsanbieter integriert, die in GDC verfügbar sind. In der Regel haben Enterprise- und öffentliche Kunden eigene gut verwaltete Identitätsanbieter wie Active Directory oder andere Systeme, mit denen sie ihren Mitarbeitern Berechtigungen erteilen und entziehen können. Aus Compliance-Gründen und zur einfachen Verwaltung von Identitäten und Zugriffen möchten diese Kunden ihre vorhandenen Identitätsanbieter als Single Source of Truth verwenden, um den Zugriff ihrer Mitarbeiter auf ServiceNow zu verwalten.
ServiceNow unterstützt sowohl SAML 2.0- als auch OIDC-Anbieter über das Modul für mehrere Identitätsanbieter, das wir in unserem VM-Image für Anwendungsserver vorab aktiviert haben. Sowohl Infrastrukturbetreiber als auch Kunden authentifizieren sich über den Identitätsanbieter ihrer Organisation, wodurch automatisch Nutzer erstellt und Rollen in ServiceNow zugewiesen werden.
Der Zugriff auf Identitätsanbieterserver ist über die benutzerdefinierte Ressource ProjectNetworkPolicy zulässig. Dadurch wird eingeschränkt, ob externe Dienste von einer Organisation in GDC aus erreichbar sind. Mit diesen Richtlinien können wir deklarativ steuern, auf welche Endpunkte ServiceNow im Netzwerk zugreifen kann.
Aufnahme von Benachrichtigungen
Nutzer können sich nicht nur anmelden, um manuell Supportanfragen zu erstellen, sondern wir haben auch eine Integration mit Prometheus AlertManager eingerichtet, um ServiceNow-Vorfälle als Reaktion auf Systembenachrichtigungen zu erstellen. Durch diese Integration können Betreiber Software- und Hardwareprobleme in der GDC-Umgebung beheben, indem sie unsere Observability- und Ticketsysteme über einen zentralen Einstiegspunkt verbinden.
Für diese Integration haben wir einen Open-Source-Kubernetes-Webhook angepasst, um Benachrichtigungen von Prometheus zu empfangen und den Lebenszyklus von Vorfällen über den ServiceNow-API-Endpunkt zu verwalten, der über Cloud Service Mesh verfügbar gemacht wird. Sobald ein Vorfall in ServiceNow erstellt wurde, können Bediener einen Vorfall-Workflow starten, um Vorfälle zu kategorisieren und zu priorisieren, wenn sie auftreten. Sie können Links folgen, um den Live-Status der ausgelösten Benachrichtigung in Grafana aufzurufen.
API-Schlüssel werden im GDC-Geheimnisspeicher gespeichert, der durch Kubernetes-Secrets gesichert wird, die über die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) verwaltet werden. Andere Konfigurationen wie API-Endpunkte und Felder zur Anpassung von Vorfällen werden über den Kubernetes ConfigMap-Schlüssel/Wert-Speicher verwaltet.
ServiceNow bietet Mailserver-Integrationen, damit Kunden E-Mail-basierten Support erhalten können. Automatisierte Workflows wandeln eingehende Kunden-E‑Mails in Supportanfragen um und senden automatische Antworten mit Links zu Anfragen an Kunden. So kann unser Supportteam seinen Posteingang besser verwalten, E‑Mail-Anfragen systematisch verfolgen und beantworten und einen besseren Kundenservice bieten.
Für die Integration in SMTP- und POP3-Dienste, die in GDC verfügbar sind, verwenden wir Netzwerkrichtlinien, um den Zugriff über Projekte hinweg zu steuern. Durch das Hosten von E-Mail-Komponenten in einem separaten Projekt können wir E-Mail als Dienst entkoppeln, der von anderen Anwendungen wiederverwendet werden kann.
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
name: allow-ingress-traffic-from-service-now
spec:
subject:
subjectType: UserWorkload
ingress:
- from:
- projects:
matchNames:
- service-now
Wenn Sie E-Mail als Kubernetes-Dienst verfügbar machen, wird auch die Service-Discovery und die Auflösung von Domainnamen ermöglicht. Außerdem wird das E-Mail-Server-Backend von Clients wie ServiceNow entkoppelt.
Compliance
Audit-Logging
Audit-Logs tragen zur Compliance bei, da sie eine Möglichkeit bieten, die Softwarenutzung zu verfolgen und zu überwachen und Systemaktivitäten aufzuzeichnen. In Audit-Logs werden Zugriffsversuche durch nicht autorisierte Nutzer aufgezeichnet, die API-Nutzung verfolgt und potenzielle Sicherheitsrisiken identifiziert. Prüfprotokolle erfüllen Compliance-Anforderungen, z. B. die des Health Insurance Portability and Accountability Act (HIPAA), des Payment Card Industry Data Security Standard (PCI DSS) und des Sarbanes-Oxley Act (SOX).
GDC bietet ein System zum Aufzeichnen von Administratoraktivitäten und Zugriffen innerhalb der Plattform und zum Aufbewahren dieser Logs für einen konfigurierbaren Zeitraum. Durch die Bereitstellung der benutzerdefinierten Ressource AuditLoggingTarget wird die Logging-Pipeline so konfiguriert, dass Audit-Logs aus unserer Anwendung erfasst werden.
Für ServiceNow haben wir Audit-Logging-Ziele für System-Audit-Ereignisse konfiguriert, die vom auditd-Daemon unter Red Hat Enterprise Linux erfasst werden, sowie für anwendungsspezifische Ereignisse, die vom ServiceNow-Sicherheitsaudit-Log generiert werden. Beide Arten von Logs werden an eine zentrale Loki-Instanz gesendet, in der wir Abfragen schreiben und Dashboards in Grafana ansehen können.
Zugriffssteuerung
Bei der Zugriffssteuerung wird der Zugriff auf Ressourcen basierend auf der Identität des Nutzers oder Prozesses, der den Zugriff anfordert, gewährt oder verweigert. Das trägt zum Schutz der Daten vor unberechtigtem Zugriff bei und sorgt dafür, dass nur autorisierte Nutzer Änderungen am System vornehmen können. In GDC verwenden wir Kubernetes RBAC, um Richtlinien zu deklarieren und die Autorisierung für die Systemressourcen zu erzwingen, die aus der ServiceNow-Anwendung bestehen.
Durch die Definition einer ProjectRole in GDC können wir mithilfe einer voreingestellten Autorisierungsrolle einen detaillierten Zugriff auf Kubernetes-Ressourcen gewähren.
In Kombination mit anderen vorhandenen Rollen wie der Rolle „VM-Administrator“ (vm-admin) können Operatoren an eine oder mehrere Rollen gebunden werden, um Probleme zu beheben und routinemäßige Wartungsarbeiten durchzuführen.
Durch die Definition einer ProjectRole in GDC können wir mithilfe einer voreingestellten Autorisierungsrolle einen detaillierten Zugriff auf Kubernetes-Ressourcen gewähren.
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
name: service-now-admin
labels:
resourcemanager.gdc.goog/rbac-selector: system
spec:
rules:
- apiGroups:
- ""
resources:
- configmaps
- events
- pods/log
- services
verbs:
- get
- list
Wenn Sie Rollen und Rollenbindungen über ein Infrastructure as Code-System (IaC) wie GitLab und einen Synchronisierungsdienst wie Config Management verwalten, können Operatoren über einen Genehmigungsprozess vorübergehend erhöhten Zugriff auf eine Rolle erhalten. Diese Systeme bieten auch zeitlich begrenzten Zugriff auf das System und führen gleichzeitig ein Audit-Log der Systemänderungen.
Runbooks
Runbooks sind wichtig, um eine konforme Softwareanwendung zu betreiben, da sie eine Schritt-für-Schritt-Anleitung für die Ausführung von Aufgaben enthalten. So kann sichergestellt werden, dass alle Aufgaben korrekt und in Übereinstimmung mit allen anwendbaren Gesetzen und Verordnungen erledigt werden. Runbooks können auch dazu beitragen, dass alle Teammitglieder ihre Verantwortlichkeiten kennen und wissen, wie sie diese erfüllen können. Wir haben Runbooks für ServiceNow erstellt, um administrative Aufgaben wie das Rotieren von Passwörtern, das Neustarten von Servern und andere Standardarbeitsanweisungen (Standard Operating Procedures, SOPs) auszuführen.
Notfallwiederherstellung
Datenbankreplikation
Um die Anforderungen an die Notfallwiederherstellung (Disaster Recovery, DR) zu erfüllen, stellen wir ServiceNow in einer primär-sekundären Konfiguration über mehrere GDC-Instanzen hinweg bereit. In diesem Modus werden Anfragen an ServiceNow normalerweise an den primären Standort weitergeleitet, während am sekundären Standort das Binärlog der MariaDB-Datenbank kontinuierlich repliziert wird. Bei einem Failover wird die sekundäre Website zur neuen primären Website hochgestuft und Anfragen werden dann an die neue primäre Website weitergeleitet.
Wir nutzen die Replikationsfunktionen von MariaDB, um sowohl den primären als auch den Replikat-Datenbankserver pro GDC-Instanz basierend auf Parametern zu konfigurieren, die während der Helm-Bereitstellung festgelegt werden.
Wenn Sie die Replikation für eine vorhandene Instanz aktivieren möchten, die länger als der Aufbewahrungszeitraum für das binäre Log ausgeführt wurde, können Sie die Replikatdatenbank mit Mariabackup wiederherstellen. Dabei wird auch die globale Transaktions-ID (GTID) aufgezeichnet, um die Replikation von der primären Datenbank zu starten.
Im primären Modus funktionieren die Anwendungsserver und die Datenbank wie bisher. Die primäre Datenbank ist jedoch für die Replikation konfiguriert. Beispiel:
Aktivieren Sie das binäre Log.
Legen Sie die Server-ID fest.
Erstellen Sie ein Nutzerkonto für die Replikation.
Erstellen Sie eine Sicherung, die GTID-Informationen enthält.
Im Replikamodus deaktivieren die Anwendungsserver den ServiceNow-Webdienst, um eine direkte Verbindung zur Replikatdatenbank zu vermeiden. Die Replikatdatenbank muss so konfiguriert sein, dass die Replikation von der primären Datenbank aus gestartet wird, z. B.:
Legen Sie die Server-ID fest.
Konfigurieren Sie die Anmeldedaten des Replikationsnutzers und die primären Verbindungsdetails wie Host und Port.
Wiederherstellung aus der Sicherung wird mit der binären Logposition aus der GTID fortgesetzt.
Für die Datenbankreplikation ist eine Netzwerkverbindung erforderlich, damit das Replikat eine Verbindung zur primären Datenbank herstellen und die Replikation starten kann. Um den Endpunkt der primären Datenbank für die Replikation verfügbar zu machen, können wir mit Cloud Service Mesh ein Istio-Ingress-Gateway erstellen, das die TLS-Terminierung am Istio-Gateway unterstützt. Das ist ähnlich wie bei der Verarbeitung von HTTPS-Datenübertragungen für die ServiceNow-Webanwendung.
Failover-Prozedur
Im Falle eines Failovers wird der sekundäre Standort zum neuen primären Standort hochgestuft und Anfragen werden dann an den neuen primären Standort weitergeleitet. Dieser Prozess ist anfangs ein manuelles Verfahren, kann aber durch zusätzlichen Aufwand zunehmend automatisiert werden.
Am primären Standort:
Beenden Sie den ServiceNow-Dienst auf Anwendungsservern.
Konfigurieren Sie den Datenbankserver für den Replikatmodus.
Starten Sie den Reverse-Proxy-Dienst, wenn er auf Anwendungsservern verwendet wird.
Am sekundären Standort:
Beenden Sie die Replikation auf dem Datenbankserver.
Beenden Sie den Reverse-Proxy-Dienst, falls er auf Anwendungsservern verwendet wird.
Konfigurieren Sie den Datenbankserver für den primären Modus.
Starten Sie den ServiceNow-Dienst auf Anwendungsservern.
Eine in unseren Runbooks dokumentierte Failover-Prozedur trägt dazu bei, dass der Betrieb im Katastrophenfall nicht unterbrochen wird, und verkürzt die Zeit, die für die Wiederherstellung nach einer Katastrophe erforderlich ist.