Questa guida illustra il contesto concettuale necessario per eseguire il deployment di un carico di lavoro basato su macchina virtuale (VM) in un cluster air-gap Google Distributed Cloud (GDC) su bare metal utilizzando un runtime VM. Il carico di lavoro in questa guida è una piattaforma ServiceNow di esempio disponibile su hardware on-premise.
Architettura
Gerarchia delle risorse
In GDC, implementi i componenti che compongono ServiceNow in un'organizzazione tenant dedicata per il team delle operazioni, identica a qualsiasi organizzazione cliente. Un'organizzazione è un insieme di cluster, risorse di infrastruttura e carichi di lavoro delle applicazioni che vengono amministrati insieme. Ogni organizzazione in un'istanza GDC utilizza un insieme dedicato di server, garantendo un forte isolamento tra i tenant. Per ulteriori informazioni sull'infrastruttura, consulta Progettare i limiti di accesso.
Inoltre, esegui il deployment e gestisci le risorse ServiceNow insieme in un progetto, che fornisce l'isolamento logico all'interno di un'organizzazione utilizzando criteri software e applicazione. Le risorse di un progetto sono pensate per accoppiare i componenti che devono rimanere insieme per il loro ciclo di vita.
ServiceNow segue un'architettura a tre livelli che si basa su un bilanciatore del carico per indirizzare il traffico tra i server delle applicazioni che si connettono a un server di database che archivia i dati permanenti.
Questa architettura consente scalabilità e manutenibilità, poiché ogni livello può essere sviluppato e gestito in modo indipendente. Fornisce inoltre una chiara separazione delle competenze, il che semplifica il debug e la risoluzione dei problemi. L'incapsulamento di questi livelli all'interno di un progetto GDC consente di eseguire il deployment e gestire i componenti insieme, ad esempio i server delle applicazioni e dei database.
Networking
L'esecuzione di ServiceNow in un ambiente di produzione richiede il deployment di due o più server delle applicazioni per ottenere un'alta disponibilità in caso di errore del nodo. In combinazione con un bilanciatore del carico, questa topologia consente anche di distribuire il carico su più macchine per scalare orizzontalmente l'applicazione. La piattaforma Kubernetes nativa di GDC utilizza Cloud Service Mesh per instradare in modo sicuro il traffico ai server delle applicazioni che compongono ServiceNow.
Cloud Service Mesh è un'implementazione di Google basata sul progetto open source Istio che gestisce, osserva e protegge i servizi. Per ospitare ServiceNow su GDC vengono utilizzate le seguenti funzionalità di Cloud Service Mesh:
- Bilanciamento del carico: Cloud Service Mesh disaccoppia il flusso di traffico dalla scalabilità dell'infrastruttura, offrendo numerose funzionalità per la gestione del traffico, incluso il routing dinamico delle richieste. ServiceNow richiede connessioni client persistenti, pertanto attiviamo le sessioni permanenti utilizzando
DestinationRulesper configurare il comportamento di routing del traffico.
Terminazione TLS: Cloud Service Mesh espone i gateway di ingresso utilizzando i certificati TLS e fornisce l'autenticazione del trasporto all'interno del cluster tramite mTLS (Mutual Transport Layer Security) senza dover modificare il codice dell'applicazione.
Recupero da errori: Cloud Service Mesh fornisce una serie di funzionalità critiche per il recupero da errori, tra cui timeout, interruttori di sicurezza, controlli di integrità attivi e limitazione di nuovi tentativi.
All'interno del cluster Kubernetes, utilizziamo oggetti Service standard come modo astratto per esporre i server di applicazioni e database alla rete. I servizi forniscono un modo pratico per scegliere come target le istanze utilizzando un selettore e forniscono la risoluzione dei nomi all'interno del cluster utilizzando un server DNS compatibile con il cluster.
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
Computing
ServiceNow consiglia di utilizzare macchine bare metal o virtuali per ospitare installazioni on-premise e abbiamo utilizzato la gestione delle macchine virtuali (VM) GDC per eseguire il deployment dei server delle applicazioni e dei database come carichi di lavoro VM. La definizione delle risorse Kubernetes ci ha consentito di specificare sia VirtualMachine sia VirtualMachineDisk per personalizzare le risorse in modo da soddisfare le nostre esigenze per i diversi tipi di server. VirtualMachineExternalAccess ci consente di configurare il trasferimento dei dati in entrata e in uscita per la VM.
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
Per l'immagine del sistema operativo guest, abbiamo creato un'immagine personalizzata basata su Red Hat Enterprise
Linux per soddisfare i nostri requisiti di conformità e sicurezza. La connessione alle istanze VM in esecuzione è possibile tramite SSH utilizzando VirtualMachineAccessRequest, che ci consente di limitare la possibilità di connettersi alle VM tramite il controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes ed evitare la necessità di creare account utente locali nelle immagini personalizzate. La richiesta di accesso definisce anche un durata (TTL)
che consente alle richieste di accesso basate sul tempo di gestire le VM che scadono automaticamente.
Automazione
Come risultato chiave di questo progetto, abbiamo progettato un approccio per installare le istanze di ServiceNow in modo ripetibile, in grado di supportare un'ampia automazione e ridurre la deriva della configurazione tra i deployment.
Helm Packaging
Helm è un gestore di pacchetti per Kubernetes che gestisce il ciclo di vita delle applicazioni, inclusi l'installazione e l'upgrade di tutti i componenti che compongono un'applicazione. Helm fornisce anche un modo per gestire le dipendenze, ad esempio le risorse personalizzate necessarie per l'integrazione con altri sistemi come l'osservabilità e la conformità. La creazione di grafici Helm ci consente di incapsulare queste risorse, semplificando il processo di installazione e gestione di ServiceNow.
Pipeline di rilascio
La personalizzazione delle immagini del server di applicazioni e del database inizia da un'immagine del sistema operativo di base, modificando l'immagine di base in base alle necessità per installare le dipendenze necessarie per ogni immagine del server. Abbiamo selezionato Red Hat Enterprise Linux (RHEL) come immagine del sistema operativo di base per la sua ampia adozione nell'hosting di ServiceNow in installazioni on-premise. Red Hat Enterprise Linux fornisce anche funzionalità di hardening della sicurezza necessarie per soddisfare le guide tecniche di implementazione della sicurezza (STIG) necessarie per fornire un'immagine conforme ai controlli NIST-800-53.
La nostra pipeline di integrazione continua (CI) ha utilizzato il seguente flusso di lavoro per personalizzare le immagini dei server di applicazioni e database:
Quando gli sviluppatori apportano modifiche agli script di personalizzazione o alle dipendenze delle immagini, attiviamo un flusso di lavoro automatizzato nei nostri strumentiCIa per generare un nuovo set di immagini che vengono raggruppate con le release di GDC. Nell'ambito della creazione di immagini, aggiorniamo anche le dipendenze del sistema operativo (yum update) e rendiamo sparsa l'immagine con la compressione per ridurre le dimensioni dell'immagine necessarie per trasferire le immagini agli ambienti dei clienti.
Ciclo di vita dello sviluppo software
Il ciclo di vita dello sviluppo del software (SDLC) è un processo che aiuta le organizzazioni a pianificare, creare, testare ed eseguire il deployment del software. Seguendo un SDLC ben definito, le organizzazioni garantiscono che il software venga sviluppato in modo coerente e ripetibile e identificano potenziali problemi in anticipo. Oltre a creare immagini nella nostra pipeline di integrazione continua (CI), abbiamo anche definito ambienti per sviluppare e preparare le versioni pre-release di ServiceNow per i test e il controllo qualità.
Il deployment di un'istanza separata di ServiceNow per progetto GDC ci ha consentito di testare le modifiche in isolamento, senza influire sulle istanze esistenti nella stessa istanza GDC. Abbiamo utilizzato l'API Resource Manager per creare e eliminare in modo dichiarativo i progetti utilizzando le risorse Kubernetes.
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 combinazione con il packaging dei grafici Helm e la gestione dell'infrastruttura, ad esempio le macchine virtuali come codice, gli sviluppatori possono eseguire rapidamente l'iterazione apportando modifiche e testando nuove funzionalità insieme alle istanze di produzione. L'API dichiarativa consente inoltre ai framework di esecuzione dei test automatizzati di eseguire test di regressione regolari e verificare le funzionalità esistenti.
Operabilità
L'operatività è la facilità con cui un sistema può essere utilizzato e mantenuto. È un aspetto importante da considerare nella progettazione di qualsiasi applicazione software. Un monitoraggio efficace contribuisce all'operatività perché consente di identificare e risolvere i problemi prima che abbiano un impatto significativo sul sistema. Il monitoraggio può essere utilizzato anche per identificare opportunità di miglioramento e stabilire una base di riferimento per gli obiettivi del livello di servizio (SLO).
Monitoraggio
Abbiamo integrato ServiceNow con l'infrastruttura di osservabilità GDC esistente, inclusi logging e metriche. Per le metriche, esponiamo endpoint HTTP da ogni VM che consentono a Prometheus di recuperare i punti dati prodotti dai server delle applicazioni e dei database. Questi endpoint includono metriche di sistema raccolte utilizzando l'esportatore di nodi Prometheus e metriche specifiche dell'applicazione, ad esempio utilizzando un esportatore di database MySQL.
Con gli endpoint esposti in ogni VM, abbiamo configurato il comportamento di polling di Prometheus
utilizzando la risorsa personalizzata MonitoringTarget per definire l'intervallo di scraping e
annotare le metriche.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
name: database-monitor
spec:
podMetricsEndpoints:
path:
value: /metrics
port:
annotation: application.io/dbMetrics
scrapeInterval: 60s
Per la registrazione, abbiamo installato e configurato FluentBit in ogni VM per monitorare i log pertinenti e inviare i dati di log a Loki, dove vengono indicizzati ed eseguiti query tramite Grafana. I log di controllo vengono inoltrati a un endpoint speciale configurato con
conservazione estesa per la conformità. Le applicazioni basate su container possono utilizzare
la risorsa personalizzata LoggingTarget e AuditLoggingTarget per indicare alla
pipeline di logging di raccogliere i log di servizi specifici nel tuo progetto.
In base ai dati disponibili in Prometheus e Loki, abbiamo creato avvisi utilizzando la risorsa personalizzata
MonitoringRule, che ci consente di gestire questa configurazione
come codice nel nostro grafico Helm. L'utilizzo di un'API dichiarativa per definire avvisi e dashboard ci consente anche di archiviare questa configurazione nel nostro repository Git e di seguire gli stessi processi di revisione del codice e integrazione continua su cui facciamo affidamento per qualsiasi altra modifica del codice.
Modalità di errore
I test iniziali hanno rivelato diverse modalità di errore correlate alle risorse che ci hanno aiutato a dare la priorità alle metriche e agli avvisi da aggiungere per primi. Abbiamo iniziato con il monitoraggio dell'utilizzo elevato di memoria e disco, poiché la configurazione errata del database inizialmente ha portato a tabelle buffer che consumavano tutta la memoria disponibile e il logging eccessivo riempiva il disco del volume permanente collegato. Dopo aver modificato le dimensioni del buffer InnoDB e implementato una strategia di rotazione dei log, abbiamo introdotto avvisi che vengono eseguiti se le VM si avvicinano a un utilizzo elevato della memoria o del disco. Abbiamo anche creato un runbook e assegnato un codice di errore in modo che gli operatori possano rivedere rapidamente la documentazione su come diagnosticare e mitigare il problema se l'avviso viene attivato.
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"
Dopo aver verificato la stabilità del sistema, abbiamo spostato l'attenzione sulle modalità di errore dell'applicazione all'interno di ServiceNow. Poiché il debug dei problemi all'interno dell'applicazione spesso richiedeva l'utilizzo di Secure Shell (SSH) in ogni VM del server delle applicazioni per controllare i log di sistema di ServiceNow, abbiamo configurato FluentBit per inoltrare questi log a Loki per creare lo stack di osservabilità GDC ed eseguire query su tutti i log operativi di ServiceNow in Grafana.
Il logging centralizzato ci ha anche consentito di eseguire query sui log di più VM contemporaneamente, consolidando la nostra visualizzazione di ogni componente del sistema. Abbiamo poi incorporato le query di ricerca dei log nei nostri runbook, consentendo agli operatori di abbinare le condizioni di errore con soluzioni e workaround noti.
Backup
I backup sono importanti per l'operatività di un sistema software perché
consentono di ripristinare il sistema in caso di guasto.
GDC offre il backup e il ripristino delle VM tramite
risorse Kubernetes. La creazione di una risorsa personalizzata VirtualMachineBackupRequest
con una risorsa personalizzata VirtualMachineBackupPlanTemplate ci consente di eseguire il backup del
volume permanente collegato a ogni VM nello spazio di archiviazione degli oggetti, dove i backup possono
essere conservati seguendo una policy di conservazione impostata tramite un bucket.
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
Analogamente, il ripristino dello stato di una VM dal backup prevede la creazione di una risorsa personalizzata VirtualMachineRestoreRequest per ripristinare sia i server delle applicazioni sia quelli di database senza modificare il codice o la configurazione di nessuno dei due servizi.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
name: vm-restore-1
spec:
virtualMachineBackup: db-vm-backup
restoreName: restore1
restoredResourceName: db1
Upgrade
Per supportare il ciclo di vita del software di ServiceNow e delle relative dipendenze, abbiamo identificato tre tipi di upgrade software, ognuno gestito in modo leggermente diverso per ridurre al minimo i tempi di inattività e l'interruzione del servizio:
- Aggiornamenti del sistema operativo.
- Upgrade della piattaforma, ad esempio patch e versioni principali.
- Aggiornamenti della configurazione.
Per gli upgrade del sistema operativo, creiamo e rilasciamo continuamente nuove immagini VM per i server di applicazioni e database che vengono distribuite con ogni release di GDC. Queste immagini contengono correzioni per le vulnerabilità della sicurezza e aggiornamenti del sistema operativo Red Hat sottostante. Per implementare le nuove immagini, gli operatori seguono i runbook che descrivono in dettaglio i passaggi necessari per caricare e avviare nuove VM, verificare la configurazione e ritirare le istanze precedenti.
Gli upgrade della piattaforma ServiceNow richiedono l'applicazione di aggiornamenti alle immagini VM esistenti, quindi non possiamo fare affidamento su un'infrastruttura immutabile per eseguire l'applicazione di patch e gli aggiornamenti delle versioni principali. Per gli upgrade della piattaforma, testiamo e verifichiamo la patch o la versione principale della release nei nostri ambienti di sviluppo e gestione temporanea prima di rilasciare un pacchetto di upgrade autonomo insieme alla release GDC. Per applicare patch e upgrade delle versioni principali, gli operatori seguono i runbook per connettersi alle istanze VM esistenti, caricare il pacchetto di upgrade e avviare l'upgrade da ogni VM in esecuzione.
Infine, gli aggiornamenti della configurazione vengono applicati senza tempi di inattività utilizzando le API ServiceNow per i set di aggiornamento e altri dati utente. Sviluppiamo e testiamo gli aggiornamenti della configurazione nei nostri ambienti di sviluppo e staging prima di raggruppare più set di aggiornamenti durante la procedura di rilascio di GDC. Gli operatori seguono quindi i runbook per richiamare uno strumento a riga di comando che abbiamo sviluppato e che chiama le API ServiceNow appropriate per caricare e applicare i set di aggiornamenti.
Integrazioni
Provider di identità
Per offrire ai clienti un percorso senza interruzioni e consentire alle organizzazioni di eseguire l'onboarding dei propri utenti, integriamo ServiceNow con più provider di identità disponibili in GDC. In genere, i clienti aziendali e del settore pubblico dispongono di propri provider di identità ben gestiti, come Active Directory o altri sistemi simili, per concedere e revocare i diritti ai propri dipendenti. A causa dei requisiti di conformità e della facilità di gestione dell'identità e dell'accesso, questi clienti vogliono utilizzare i loro provider di identità esistenti come fonte attendibile per gestire l'accesso dei dipendenti a ServiceNow.
ServiceNow supporta i provider SAML 2.0 e OIDC tramite il modulo multi-identity provider, che abbiamo preattivato nell'immagine VM del server delle applicazioni. Gli operatori dell'infrastruttura (IO) e i clienti si autenticano tramite il provider di identità dell'organizzazione, che crea automaticamente gli utenti e assegna i ruoli all'interno di ServiceNow.
L'uscita verso i server del provider di identità è consentita tramite la risorsa personalizzata ProjectNetworkPolicy, che limita la raggiungibilità dei servizi esterni da un'organizzazione in GDC. Questi criteri
ci consentono di controllare in modo dichiarativo a quali endpoint ServiceNow può accedere sulla
rete.
Importazione degli avvisi
Oltre a consentire agli utenti di accedere per creare manualmente richieste di assistenza, eseguiamo anche
l'integrazione con Prometheus AlertManager per creare incidenti ServiceNow in
risposta agli avvisi di sistema. Questa integrazione consente agli operatori di eseguire il triage e risolvere
i problemi software e hardware all'interno dell'ambiente GDC
collegando i nostri sistemi di osservabilità e ticketing a un punto di accesso
centralizzato.
Per ottenere questa integrazione, abbiamo personalizzato un webhook Kubernetes open source per ricevere avvisi da Prometheus e gestire il ciclo di vita degli incidenti utilizzando l'endpoint APIPI ServiceNow esposto tramite Cloud Service Mesh. Una volta creato un incidente in ServiceNow, gli operatori possono avviare un flusso di lavoro per classificare e assegnare la priorità agli incidenti man mano che si verificano, seguendo i link per visualizzare lo stato in tempo reale dell'avviso attivato in Grafana.
Le chiavi API vengono archiviate utilizzando l'archivio dei secret GDC, supportato dai secret di Kubernetes controllati tramitecontrollo dell'accessoo basato sui ruoli (RBAC). Altre configurazioni, come endpoint API e campi di personalizzazione degli incident, sono gestite tramite l'archiviazione di coppie chiave-valore ConfigMap di Kubernetes.
ServiceNow offre integrazioni del server di posta per consentire ai clienti di ricevere assistenza via email. I flussi di lavoro automatizzati convertono le email in arrivo dei clienti in richieste di assistenza e inviano risposte automatiche ai clienti con i link alle richieste, consentendo al nostro team di assistenza di gestire meglio la posta in arrivo, monitorare e risolvere sistematicamente le richieste via email e fornire un servizio clienti migliore.
Per l'integrazione con i servizi SMTP e POP3 esposti in GDC, utilizziamo i criteri di rete per controllare l'accesso tra i progetti. L'hosting dei componenti email in un progetto separato ci consente di disaccoppiare l'email come servizio che può essere riutilizzato da altre applicazioni.
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
L'esposizione dell'email come servizio Kubernetes fornisce anche Service Discovery e la risoluzione dei nomi di dominio e disaccoppia ulteriormente il backend del server di posta dai client come ServiceNow.
Conformità
Audit logging
I log di controllo contribuiscono alla conformità fornendo un modo per monitorare l'utilizzo del software e fornire un record dell'attività di sistema. I log di controllo registrano i tentativi di accesso da parte di utenti non autorizzati, monitorano l'utilizzo delle API e identificano potenziali rischi per la sicurezza. I log di controllo soddisfano i requisiti di conformità, come quelli imposti da HIPAA (Health Insurance Portability and Accountability Act), PCI DSS (Payment Card Industry Data Security Standard) e SOX (Sarbanes-Oxley Act).
GDC fornisce un sistema per registrare le attività e gli accessi amministrativi all'interno della piattaforma e conservare questi log per un periodo di tempo configurabile. Il deployment della risorsa personalizzata AuditLoggingTarget
configura la pipeline di logging per raccogliere i log di controllo dalla nostra applicazione.
Per ServiceNow, abbiamo configurato le destinazioni di logging di controllo sia per gli eventi di controllo del sistema raccolti dal daemon auditd su Red Hat Enterprise Linux sia per gli eventi specifici dell'applicazione generati dal log di controllo della sicurezza di ServiceNow. Entrambi i tipi di log vengono inviati a un'istanza Loki centralizzata in cui possiamo scrivere query e visualizzare dashboard in Grafana.
Controllo degli accessi
Il controllo dell'accesso è il processo di concessione o negazione dell'accesso alle risorse in base all'identità dell'utente o del processo che richiede l'accesso. In questo modo, i dati vengono protetti da accessi non autorizzati e solo gli utenti autorizzati possono apportare modifiche al sistema. In GDC, ci affidiamo al controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per dichiarare le norme e applicare l'autorizzazione alle risorse di sistema costituite dall'applicazione ServiceNow.
La definizione di un ProjectRole in GDC ci consente di concedere
un accesso granulare alle risorse Kubernetes utilizzando un ruolo di autorizzazione preimpostato.
In combinazione con altri ruoli preesistenti, come il ruolo di amministratore VM (vm-admin),
gli operatori possono eseguire il binding a uno o più ruoli per eseguire il debug dei problemi ed eseguire
la manutenzione di routine.
La definizione di un ProjectRole in GDC ci consente di concedere
un accesso granulare alle risorse Kubernetes utilizzando un ruolo di autorizzazione preimpostato.
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
Gestendo i ruoli e i relativi binding tramite un sistema Infrastructure as Code (IaC) come GitLab e un servizio di sincronizzazione come Config Management, gli operatori possono ottenere l'accesso temporaneo con privilegi elevati a un ruolo tramite una procedura di approvazione. Questi sistemi forniscono anche un accesso limitato nel tempo al sistema, mantenendo un log di controllo delle modifiche apportate.
Runbook
I runbook sono importanti per mantenere un'applicazione software conforme perché forniscono una guida passo passo per completare le attività. Ciò può contribuire a garantire che tutte le attività vengano completate correttamente e in conformità con tutte le leggi e i regolamenti applicabili. I runbook possono anche contribuire a garantire che tutti i membri del team siano consapevoli delle proprie responsabilità e di come portarle a termine. Abbiamo creato runbook per ServiceNow per eseguire attività amministrative come la rotazione delle password, il riavvio dei server e altre procedure operative standard (SOP).
Disaster recovery
Replica dei database
Per soddisfare i requisiti di ripristino di emergenza (RE), eseguiamo il deployment di ServiceNow in una configurazione primaria-secondaria su più istanze GDC. In questa modalità, le richieste a ServiceNow vengono normalmente indirizzate al sito principale, mentre il sito secondario replica continuamente il log binario del database MariaDB. In caso di evento di failover, il sito secondario viene promosso a nuovo sito principale e le richieste vengono quindi indirizzate al nuovo sito principale.
Sfruttiamo le funzionalità di replica di MariaDB per configurare i server di database primario e di replica per istanza GDC in base ai parametri impostati durante il deployment di Helm.
Per attivare la replica per un'istanza esistente in esecuzione da più tempo del periodo di conservazione del log binario, possiamo ripristinare il database di replica utilizzando Mariabackup, che registra anche l'ID transazione globale (GTID) per avviare la replica dal database primario.
In modalità primaria, i server delle applicazioni e il database funzionano come oggi, ma il database principale è configurato per abilitare la replica. Ad esempio:
Abilita il log binario.
Imposta l'ID server.
Crea un account utente di replica.
Crea un backup che includa le informazioni GTID.
In modalità di replica, i server delle applicazioni disattiveranno il servizio web ServiceNow per evitare di connettersi direttamente al database di replica. Il database di replica deve essere configurato per avviare la replica dal database principale, ad esempio:
Imposta l'ID server.
Configura le credenziali dell'utente di replica e i dettagli della connessione primaria, come l'host e la porta.
Ripristina dalla posizione del log binario di ripristino del backup dal GTID.
La replica del database richiede la connettività di rete per consentire alla replica di connettersi al database principale per avviare la replica. Per esporre l'endpoint del database principale per la replica, possiamo utilizzare Cloud Service Mesh per creare un gateway di ingresso Istio che supporti la terminazione TLS nel gateway Istio, in modo simile a come gestiamo il trasferimento dei dati HTTPS per l'applicazione web ServiceNow.
Procedura di failover
In caso di failover, il sito secondario viene promosso a nuovo sito principale e le richieste vengono quindi indirizzate al nuovo sito principale. Inizialmente, questa procedura è manuale, ma può essere automatizzata sempre di più con ulteriori sforzi.
Nel sito principale:
Arresta il servizio ServiceNow sui server delle applicazioni.
Configura il server di database per la modalità di replica.
Avvia il servizio di reverse proxy se viene utilizzato sui server delle applicazioni.
Nel sito secondario:
Interrompi la replica sul server di database.
Interrompi il servizio di reverse proxy se utilizzato sui server delle applicazioni.
Configura il server di database per la modalità primaria.
Avvia il servizio ServiceNow sui server delle applicazioni.
Disporre di una procedura di failover documentata nei nostri runbook contribuisce a garantire che le operazioni non vengano interrotte in caso di emergenza e riduce il tempo necessario per il ripristino in caso di emergenza.