Ce guide fournit le contexte conceptuel nécessaire pour déployer une charge de travail basée sur une machine virtuelle (VM) dans un cluster Google Distributed Cloud (GDC) isolé sur Bare Metal à l'aide d'un environnement d'exécution de VM. La charge de travail de ce guide est un exemple de plate-forme ServiceNow disponible sur du matériel sur site.
Architecture
Hiérarchie des ressources
Dans GDC, vous déployez les composants qui constituent ServiceNow dans une organisation locataire dédiée à l'équipe des opérations, identique à n'importe quelle organisation cliente. Une organisation est un ensemble de clusters, de ressources d'infrastructure et de charges de travail d'application qui sont administrés ensemble. Chaque organisation d'une instance GDC utilise un ensemble de serveurs dédiés, ce qui permet une forte isolation entre les locataires. Pour en savoir plus sur l'infrastructure, consultez Concevoir des limites d'accès.
De plus, vous déployez et gérez les ressources ServiceNow ensemble dans un projet, ce qui assure une isolation logique au sein d'une organisation à l'aide de règles et de mesures d'application logicielles. Les ressources d'un projet sont destinées à coupler les composants qui doivent rester ensemble pendant leur cycle de vie.
ServiceNow suit une architecture à trois niveaux qui s'appuie sur un équilibreur de charge pour diriger le trafic vers les serveurs d'applications qui se connectent à un serveur de base de données stockant les données persistantes.
Cette architecture permet l'évolutivité et la facilité de maintenance, car chaque niveau peut être développé et géré de manière indépendante. Il permet également de séparer clairement les préoccupations, ce qui simplifie le débogage et le dépannage. En encapsulant ces niveaux dans un projet GDC, vous pouvez déployer et gérer les composants ensemble, par exemple vos serveurs d'application et de base de données.
Mise en réseau
Pour exécuter ServiceNow dans un environnement de production, vous devez déployer au moins deux serveurs d'application afin d'assurer une haute disponibilité en cas de défaillance d'un nœud. Combinée à un équilibreur de charge, cette topologie permet également de répartir la charge sur plusieurs machines pour mettre à l'échelle l'application de manière horizontale. La plate-forme Kubernetes native de GDC utilise Cloud Service Mesh pour acheminer le trafic de manière sécurisée vers les serveurs d'application qui composent ServiceNow.
Cloud Service Mesh est une implémentation Google basée sur le projet Open Source Istio, qui permet de gérer, d'observer et de sécuriser les services. Les fonctionnalités suivantes de Cloud Service Mesh sont utilisées pour héberger ServiceNow sur GDC :
- Équilibrage de charge : Cloud Service Mesh dissocie le flux de trafic du scaling de l'infrastructure, et offre de nombreuses fonctionnalités de gestion du trafic, y compris le routage dynamique des requêtes. ServiceNow nécessite des connexions client persistantes. Nous activons donc les sessions persistantes à l'aide de
DestinationRulespour configurer le comportement de routage du trafic.
Arrêt TLS : Cloud Service Mesh expose les passerelles d'entrée à l'aide de certificats TLS et fournit une authentification du transport au sein du cluster via mTLS (Mutual Transport Layer Security) sans avoir à modifier le code de l'application.
Reprise après échec : Cloud Service Mesh offre un certain nombre de fonctionnalités majeures de reprise après échec, y compris des délais avant expiration, des disjoncteurs, des vérifications d'état actives et des tentatives limitées.
Dans le cluster Kubernetes, nous utilisons des objets Service standards comme moyen abstrait d'exposer les serveurs d'application et de base de données au réseau. Les services permettent de cibler facilement les instances à l'aide d'un sélecteur et de fournir une résolution de nom dans le cluster à l'aide d'un serveur DNS compatible avec le 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
Calcul
ServiceNow recommande d'utiliser des machines virtuelles ou bare metal pour héberger les installations sur site. Nous avons utilisé la gestion des machines virtuelles (VM) GDC pour déployer les serveurs d'application et de base de données en tant que charges de travail de VM. La définition des ressources Kubernetes nous a permis de spécifier à la fois VirtualMachine et VirtualMachineDisk pour adapter les ressources à nos besoins pour les différents types de serveurs. VirtualMachineExternalAccess nous permet de configurer le transfert de données vers et depuis 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
Pour l'image de l'OS invité, nous avons créé une image personnalisée basée sur Red Hat Enterprise Linux afin de répondre à nos exigences de conformité et de sécurité. Il est possible de se connecter à des instances de VM en cours d'exécution via SSH à l'aide de VirtualMachineAccessRequest, ce qui nous permet de limiter la possibilité de se connecter à des VM via le contrôle d'accès basé sur les rôles Kubernetes et d'éviter d'avoir à créer des comptes utilisateur locaux dans les images personnalisées. La demande d'accès définit également une valeur TTL (Time To Live) qui permet de gérer les VM dont les demandes d'accès temporaires expirent automatiquement.
Automatisation
Pour ce projet, nous avons conçu une approche permettant d'installer des instances de ServiceNow de manière reproductible, ce qui permet une automatisation étendue et réduit la dérive de configuration entre les déploiements.
Emballage Helm
Helm est un gestionnaire de packages pour Kubernetes qui gère le cycle de vie des applications, y compris l'installation et la mise à niveau de tous les composants qui constituent une application. Helm permet également de gérer les dépendances, telles que les ressources personnalisées requises pour l'intégration à d'autres systèmes comme l'observabilité et la conformité. La création de graphiques Helm nous permet d'encapsuler ces ressources, ce qui simplifie le processus d'installation et de gestion de ServiceNow.
Pipeline de versions
La personnalisation des images de serveur d'application et de base de données commence par une image de système d'exploitation de base. Vous devez modifier cette image de base selon vos besoins pour installer les dépendances nécessaires à chaque image de serveur. Nous avons sélectionné Red Hat Enterprise Linux (RHEL) comme image d'OS de base en raison de son adoption généralisée pour l'hébergement de ServiceNow dans des installations sur site. Red Hat Enterprise Linux fournit également des fonctionnalités de renforcement de la sécurité nécessaires pour répondre aux guides d'implémentation technique de sécurité (STIG) requis pour fournir une image conforme aux contrôles NIST-800-53.
Notre pipeline d'intégration continue (CI) utilisait le workflow suivant pour personnaliser les images de serveur d'application et de base de données :
Lorsque les développeurs apportent des modifications aux scripts de personnalisation ou aux dépendances d'image, nous déclenchons un workflow automatisé dans notre outil CI pour générer un nouvel ensemble d'images qui sont regroupées avec les versions GDC. Lors de la création d'images, nous actualisons également les dépendances de l'OS (yum update) et nous rendons l'image clairsemée avec compression pour réduire la taille de l'image nécessaire au transfert d'images vers les environnements client.
Cycle de vie du développement logiciel
Le cycle de développement logiciel (SDLC, software development lifecycle) est un processus qui aide les organisations à planifier, créer, tester et déployer des logiciels. En suivant un cycle de vie du développement logiciel bien défini, les entreprises s'assurent que les logiciels sont développés de manière cohérente et reproductible, et identifient les problèmes potentiels dès le début. En plus de créer des images dans notre pipeline d'intégration continue (CI), nous avons également défini des environnements pour développer et mettre en scène des versions préliminaires de ServiceNow à des fins de test et d'assurance qualité.
Le déploiement d'une instance ServiceNow distincte par projet GDC nous a permis de tester les modifications de manière isolée, sans affecter les instances existantes sur la même instance GDC. Nous avons utilisé l'API Resource Manager pour créer et supprimer des projets de manière déclarative à l'aide de ressources 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
Combiné au packaging de chart Helm et à la gestion de l'infrastructure, comme les machines virtuelles en tant que code, les développeurs peuvent rapidement itérer, apporter des modifications et tester de nouvelles fonctionnalités en parallèle des instances de production. L'API déclarative permet également aux frameworks d'exécution de tests automatisés d'effectuer des tests de régression réguliers et de vérifier les fonctionnalités existantes.
Fonctionnement
L'opérabilité désigne la facilité avec laquelle un système peut être utilisé et entretenu. Il s'agit d'un aspect important à prendre en compte lors de la conception de toute application logicielle. Une surveillance efficace contribue à l'opérabilité, car elle permet d'identifier et de résoudre les problèmes avant qu'ils n'aient un impact significatif sur le système. La surveillance peut également être utilisée pour identifier les axes d'amélioration et établir une référence pour les objectifs de niveau de service (SLO).
Surveillance
Nous avons intégré ServiceNow à l'infrastructure d'observabilité GDC existante, y compris la journalisation et les métriques. Pour les métriques, nous exposons des points de terminaison HTTP à partir de chaque VM, ce qui permet à Prometheus de récupérer les points de données produits par les serveurs d'application et de base de données. Ces points de terminaison incluent les métriques système collectées à l'aide de l'exportateur de nœuds Prometheus et les métriques spécifiques à l'application, par exemple à l'aide d'un exportateur de base de données MySQL.
Avec les points de terminaison exposés dans chaque VM, nous avons configuré le comportement d'interrogation de Prometheus à l'aide de la ressource personnalisée MonitoringTarget pour définir l'intervalle d'extraction et annoter les métriques.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
name: database-monitor
spec:
podMetricsEndpoints:
path:
value: /metrics
port:
annotation: application.io/dbMetrics
scrapeInterval: 60s
Pour la journalisation, nous avons installé et configuré FluentBit dans chaque VM afin de suivre les journaux pertinents et d'envoyer les données de journaux à Loki, où les données sont indexées et interrogées via Grafana. Les journaux d'audit sont transférés vers un point de terminaison spécial configuré avec une durée de conservation étendue pour la conformité. Les applications basées sur des conteneurs peuvent utiliser les ressources personnalisées LoggingTarget et AuditLoggingTarget pour indiquer au pipeline de journalisation de collecter les journaux de services spécifiques dans votre projet.
Sur la base des données disponibles dans Prometheus et Loki, nous avons créé des alertes à l'aide de la ressource personnalisée MonitoringRule, qui nous permet de gérer cette configuration en tant que code dans notre graphique Helm. L'utilisation d'une API déclarative pour définir des alertes et des tableaux de bord nous permet également de stocker cette configuration dans notre dépôt Git et de suivre les mêmes processus de vérification du code et d'intégration continue que ceux sur lesquels nous nous appuyons pour toute autre modification du code.
Modes de défaillance
Les premiers tests ont révélé plusieurs modes de défaillance liés aux ressources, ce qui nous a aidés à déterminer les métriques et les alertes à ajouter en premier. Nous avons commencé par surveiller l'utilisation élevée de la mémoire et du disque, car une mauvaise configuration de la base de données avait initialement entraîné la consommation de toute la mémoire disponible par les tables de tampon et le remplissage du disque du volume persistant associé par une journalisation excessive. Après avoir ajusté la taille de la mémoire tampon InnoDB et mis en place une stratégie de rotation des journaux, nous avons introduit des alertes qui s'exécutent si les VM approchent d'une utilisation élevée de la mémoire ou du disque. Nous avons également rédigé un runbook et attribué un code d'erreur afin que les opérateurs puissent rapidement consulter la documentation sur la façon de diagnostiquer et d'atténuer le problème si l'alerte se déclenche.
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"
Après avoir vérifié la stabilité du système, nous nous sommes concentrés sur les modes de défaillance des applications dans ServiceNow. Étant donné que le débogage des problèmes dans l'application nous obligeait souvent à utiliser Secure Shell (SSH) dans chaque VM de serveur d'application pour vérifier les journaux système ServiceNow, nous avons configuré FluentBit pour transférer ces journaux vers Loki afin de nous appuyer sur la pile d'observabilité GDC et d'interroger tous les journaux opérationnels ServiceNow dans Grafana.
La journalisation centralisée nous a également permis d'interroger les journaux de plusieurs VM en même temps, ce qui a consolidé notre vue de chaque composant du système. Nous avons ensuite intégré des requêtes de recherche de journaux dans nos runbooks, ce qui a permis aux opérateurs d'associer les conditions d'erreur à des solutions de contournement et des solutions connues.
Sauvegardes
Les sauvegardes sont importantes pour le fonctionnement d'un système logiciel, car elles permettent de restaurer le système en cas de défaillance.
GDC propose la sauvegarde et la restauration de VM via des ressources Kubernetes. La création d'une ressource personnalisée VirtualMachineBackupRequest avec une ressource personnalisée VirtualMachineBackupPlanTemplate nous permet de sauvegarder le volume persistant associé à chaque VM dans un stockage d'objets, où les sauvegardes peuvent être conservées conformément à une règle de conservation définie par le biais d'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
De même, la restauration de l'état d'une VM à partir d'une sauvegarde implique la création d'une ressource personnalisée VirtualMachineRestoreRequest pour restaurer les serveurs d'application et de base de données sans modifier le code ni la configuration de l'un ou l'autre service.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
name: vm-restore-1
spec:
virtualMachineBackup: db-vm-backup
restoreName: restore1
restoredResourceName: db1
Mises à niveau
Pour prendre en charge le cycle de vie logiciel de ServiceNow et de ses dépendances, nous avons identifié trois types de mises à niveau logicielles, chacune étant traitée légèrement différemment pour minimiser les temps d'arrêt et les interruptions de service :
- Mises à niveau de l'OS.
- Mises à niveau de la plate-forme, telles que les versions correctives et majeures.
- Mises à jour de la configuration.
Pour les mises à niveau de l'OS, nous créons et publions en continu de nouvelles images de VM pour les serveurs d'application et de base de données, qui sont distribuées avec chaque version de GDC. Ces images contiennent des correctifs pour les failles de sécurité et des mises à jour du système d'exploitation Red Hat sous-jacent. Pour déployer les nouvelles images, les opérateurs suivent des runbooks qui détaillent les étapes requises pour importer et lancer de nouvelles VM, vérifier la configuration et mettre hors service les instances précédentes.
Les mises à niveau de la plate-forme ServiceNow nécessitent l'application de mises à jour aux images de VM existantes. Nous ne pouvons donc pas nous appuyer sur une infrastructure immuable pour effectuer les mises à jour des correctifs et des versions majeures. Pour les mises à niveau de plate-forme, nous testons et vérifions la version du correctif ou de la version majeure dans nos environnements de développement et de préproduction avant de publier un package de mise à niveau autonome avec la version GDC. Pour appliquer des correctifs et des mises à niveau de version majeure, les opérateurs suivent des runbooks pour se connecter aux instances de VM existantes, importer le package de mise à niveau et lancer la mise à niveau à partir de chaque VM en cours d'exécution.
Enfin, les mises à jour de configuration sont appliquées sans temps d'arrêt à l'aide des API ServiceNow pour les ensembles de mises à jour et autres données utilisateur. Nous développons et testons les mises à jour de configuration dans nos environnements de développement et de préproduction avant de regrouper plusieurs ensembles de mises à jour lors du processus de publication de GDC. Les opérateurs suivent ensuite des runbooks pour appeler un outil de ligne de commande que nous avons développé et qui appelle les API ServiceNow appropriées pour importer et appliquer les ensembles de mises à jour.
Intégrations
Fournisseurs d'identité
Pour offrir aux clients un parcours fluide et permettre aux organisations d'intégrer leurs utilisateurs, nous intégrons ServiceNow à plusieurs fournisseurs d'identité disponibles dans GDC. En règle générale, les clients des secteurs public et privé disposent de leurs propres fournisseurs d'identité bien gérés, tels qu'Active Directory ou d'autres systèmes de ce type, pour accorder et révoquer les droits d'accès de leurs employés. En raison des exigences de conformité et de la facilité de gestion des identités et des accès, ces clients souhaitent utiliser leurs fournisseurs d'identité existants comme source de vérité pour gérer l'accès de leurs employés à ServiceNow.
ServiceNow est compatible avec les fournisseurs SAML 2.0 et OIDC grâce à son module multi-fournisseur d'identité, que nous avons préactivé dans notre image de VM de serveur d'application. Les opérateurs d'infrastructure (OI) et les clients s'authentifient via le fournisseur d'identité de leur organisation, qui crée automatiquement des utilisateurs et attribue des rôles dans ServiceNow.
La sortie vers les serveurs du fournisseur d'identité est autorisée via la ressource personnalisée ProjectNetworkPolicy, qui limite l'accessibilité des services externes depuis une organisation dans GDC. Ces règles nous permettent de contrôler de manière déclarative les points de terminaison auxquels ServiceNow peut accéder sur le réseau.
Ingestion des alertes
En plus de permettre aux utilisateurs de se connecter pour créer manuellement des demandes d'assistance, nous nous intégrons également à Prometheus AlertManager pour créer des incidents ServiceNow en réponse aux alertes système. Cette intégration permet aux opérateurs de trier et de résoudre les problèmes logiciels et matériels dans l'environnement GDC en connectant nos systèmes d'observabilité et de gestion des demandes à un point d'entrée centralisé.
Pour réaliser cette intégration, nous avons personnalisé un webhook Kubernetes Open Source afin de recevoir les alertes de Prometheus et de gérer le cycle de vie des incidents à l'aide du point de terminaison de l'API ServiceNow exposé via Cloud Service Mesh. Une fois un incident créé dans ServiceNow, les opérateurs peuvent lancer un workflow d'incident pour catégoriser et hiérarchiser les incidents à mesure qu'ils se produisent, en suivant les liens pour afficher l'état en direct de l'alerte déclenchée dans Grafana.
Les clés API sont stockées à l'aide du secret store GDC, qui s'appuie sur des secrets Kubernetes contrôlés par le contrôle des accès basé sur les rôles (RBAC). D'autres configurations, telles que les points de terminaison d'API et les champs de personnalisation des incidents, sont gérées via le stockage de paires clé-valeur Kubernetes ConfigMap.
ServiceNow propose des intégrations de serveur de messagerie pour permettre aux clients de recevoir une assistance par e-mail. Les workflows automatisés convertissent les e-mails entrants des clients en demandes d'assistance et envoient des réponses automatiques aux clients avec des liens vers les demandes. Notre équipe d'assistance peut ainsi mieux gérer sa boîte de réception, suivre et résoudre systématiquement les demandes par e-mail, et fournir un meilleur service client.
Pour l'intégration aux services SMTP et POP3 exposés dans GDC, nous utilisons des règles réseau pour contrôler l'accès aux projets. L'hébergement des composants de messagerie dans un projet distinct nous permet de dissocier la messagerie en tant que service réutilisable par d'autres applications.
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'exposition de l'e-mail en tant que service Kubernetes fournit également la détection de services et la résolution de noms de domaine, et découple davantage le backend du serveur de messagerie des clients tels que ServiceNow.
Conformité
Audit Logging
Les journaux d'audit contribuent à la conformité en permettant de suivre et de surveiller l'utilisation des logiciels, et en fournissant un enregistrement de l'activité du système. Les journaux d'audit enregistrent les tentatives d'accès des utilisateurs non autorisés, suivent l'utilisation des API et identifient les risques de sécurité potentiels. Les journaux d'audit répondent aux exigences de conformité, telles que celles imposées par la loi HIPAA (Health Insurance Portability and Accountability Act), la norme PCI DSS (Payment Card Industry Data Security Standard) et la loi SOX (Sarbanes-Oxley Act).
GDC fournit un système permettant d'enregistrer les activités d'administration et les accès au sein de la plate-forme, et de conserver ces journaux pendant une période configurable. Le déploiement de la ressource personnalisée AuditLoggingTarget configure le pipeline de journalisation pour collecter les journaux d'audit de notre application.
Pour ServiceNow, nous avons configuré des cibles de journalisation d'audit pour les événements d'audit système collectés à partir du daemon auditd sur Red Hat Enterprise Linux et pour les événements spécifiques à l'application générés par le journal d'audit de sécurité ServiceNow. Les deux types de journaux sont envoyés à une instance Loki centralisée où nous pouvons écrire des requêtes et afficher des tableaux de bord dans Grafana.
Contrôle des accès
Le contrôle des accès est le processus qui consiste à accorder ou refuser l'accès à des ressources en fonction de l'identité de l'utilisateur ou du processus qui demande l'accès. Cela permet de protéger les données contre les accès non autorisés et de s'assurer que seuls les utilisateurs autorisés peuvent apporter des modifications au système. Dans GDC, nous nous appuyons sur Kubernetes RBAC pour déclarer des règles et appliquer des autorisations aux ressources système qui composent l'application ServiceNow.
Définir un ProjectRole dans GDC nous permet d'accorder un accès précis aux ressources Kubernetes à l'aide d'un rôle d'autorisation prédéfini.
Combinés à d'autres rôles préexistants, tels que le rôle d'administrateur de VM (vm-admin), les opérateurs peuvent s'associer à un ou plusieurs rôles pour déboguer les problèmes et effectuer la maintenance de routine.
Définir un ProjectRole dans GDC nous permet d'accorder un accès précis aux ressources Kubernetes à l'aide d'un rôle d'autorisation prédéfini.
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
En gérant les rôles et les liaisons de rôle via un système Infrastructure as Code (IaC) tel que GitLab et un service de synchronisation tel que Config Management, les opérateurs peuvent obtenir un accès temporaire étendu à un rôle via un processus d'approbation. Ces systèmes fournissent également un accès limité dans le temps au système tout en conservant un journal d'audit des modifications apportées au système.
Runbooks
Les runbooks sont importants pour maintenir la conformité d'une application logicielle, car ils fournissent un guide étape par étape pour effectuer les tâches. Cela peut contribuer à garantir que toutes les tâches sont effectuées correctement et conformément à toutes les lois et réglementations applicables. Les runbooks peuvent également aider à s'assurer que tous les membres de l'équipe connaissent leurs responsabilités et savent comment les remplir. Nous avons créé des runbooks pour ServiceNow afin d'effectuer des tâches administratives telles que la rotation des mots de passe, le redémarrage des serveurs et d'autres procédures opérationnelles standards.
Reprise après sinistre
Réplication de base de données
Pour répondre aux exigences de reprise après sinistre, nous déployons ServiceNow dans une configuration primaire-secondaire sur plusieurs instances GDC. Dans ce mode, les requêtes adressées à ServiceNow sont normalement acheminées vers le site principal, tandis que le site secondaire réplique en continu le journal binaire de la base de données MariaDB. En cas de basculement, le site secondaire est promu au rang de nouveau site principal, et les requêtes sont alors acheminées vers le nouveau site principal.
Nous nous appuyons sur les capacités de réplication de MariaDB pour configurer les serveurs de base de données principal et répliqué par instance GDC en fonction des paramètres définis lors du déploiement Helm.
Pour activer la réplication pour une instance existante qui s'exécute depuis plus longtemps que la période de conservation du journal binaire, nous pouvons restaurer la base de données répliquée à l'aide de Mariabackup, qui enregistre également l'identifiant de transaction global (GTID) pour commencer la réplication à partir de la base de données principale.
En mode principal, les serveurs d'applications et la base de données fonctionnent comme aujourd'hui, mais la base de données principale est configurée pour permettre la réplication. Exemple :
Activez le journal binaire.
Définissez l'ID du serveur.
Créez un compte utilisateur de réplication.
Créez une sauvegarde incluant les informations GTID.
En mode réplique, les serveurs d'applications désactivent le service Web ServiceNow pour éviter de se connecter directement à la base de données répliquée. La base de données répliquée doit être configurée pour démarrer la réplication à partir de la base de données principale. Par exemple :
Définissez l'ID du serveur.
Configurez les identifiants de l'utilisateur de la réplication et les détails de la connexion principale, tels que l'hôte et le port.
Restaurez à partir de la sauvegarde et reprenez la position du journal binaire à partir du GTID.
La réplication de base de données nécessite une connectivité réseau pour que la base de données répliquée se connecte à la base de données principale et lance la réplication. Pour exposer le point de terminaison de la base de données principale pour la réplication, nous pouvons utiliser Cloud Service Mesh pour créer une passerelle d'entrée Istio compatible avec l'arrêt TLS au niveau de la passerelle Istio, de la même manière que nous gérons le transfert de données HTTPS pour l'application Web ServiceNow.
Procédure de basculement
En cas de basculement, le site secondaire est promu au rang de nouveau site principal, et les requêtes sont alors acheminées vers le nouveau site principal. Ce processus est initialement une procédure manuelle, mais il peut être de plus en plus automatisé grâce à des efforts supplémentaires.
Sur le site principal :
Arrêtez le service ServiceNow sur les serveurs d'application.
Configurez le serveur de base de données pour le mode répliqué.
Démarrez le service de proxy inverse s'il est utilisé sur les serveurs d'applications.
Sur le site secondaire :
Arrêtez la réplication sur le serveur de base de données.
Arrêtez le service de proxy inverse s'il est utilisé sur les serveurs d'application.
Configurez le serveur de base de données pour le mode principal.
Démarrez le service ServiceNow sur les serveurs d'application.
La mise en place d'une procédure de reprise après sinistre documentée dans nos runbooks permet de s'assurer que les opérations ne sont pas interrompues en cas de sinistre et de réduire le temps nécessaire à la reprise après sinistre.