En esta guía se explica el contexto conceptual necesario para desplegar una carga de trabajo basada en máquinas virtuales en un clúster aislado de Google Distributed Cloud (GDC) en Bare Metal mediante un tiempo de ejecución de máquina virtual. La carga de trabajo de esta guía es una plataforma de ServiceNow de ejemplo que está disponible en hardware local.
Arquitectura
Jerarquía de recursos
En GDC, implementas los componentes que forman ServiceNow en una organización de arrendatario dedicada al equipo de Operaciones, idéntica a cualquier organización de cliente. Una organización es un conjunto de clústeres, recursos de infraestructura y cargas de trabajo de aplicaciones que se administran conjuntamente. Cada organización de una instancia de GDC usa un conjunto de servidores específico, lo que proporciona un aislamiento sólido entre los inquilinos. Para obtener más información sobre la infraestructura, consulta Diseñar límites de acceso.
Además, puedes implementar y gestionar recursos de ServiceNow en un proyecto, lo que proporciona aislamiento lógico en una organización mediante políticas de software y su aplicación. Los recursos de un proyecto están diseñados para acoplar componentes que deben permanecer juntos durante su ciclo de vida.
ServiceNow sigue una arquitectura de tres niveles que se basa en un balanceador de carga para dirigir el tráfico entre los servidores de aplicaciones que se conectan a un servidor de base de datos que almacena datos persistentes.
Esta arquitectura permite la escalabilidad y el mantenimiento, ya que cada nivel se puede desarrollar y mantener de forma independiente. También proporciona una separación clara de las responsabilidades, lo que simplifica la depuración y la solución de problemas. Al encapsular estos niveles en un proyecto de GDC, puedes implementar y gestionar componentes de forma conjunta, como los servidores de aplicaciones y de bases de datos.
Redes
Para ejecutar ServiceNow en un entorno de producción, es necesario implementar dos o más servidores de aplicaciones para conseguir una alta disponibilidad en caso de que falle un nodo. Combinada con un balanceador de carga, esta topología también permite distribuir la carga entre varias máquinas para escalar horizontalmente la aplicación. La plataforma nativa de Kubernetes de GDC utiliza Cloud Service Mesh para enrutar de forma segura el tráfico a los servidores de aplicaciones que componen ServiceNow.
Cloud Service Mesh es una implementación de Google basada en el proyecto de código abierto Istio que gestiona, observa y protege los servicios. Para alojar ServiceNow en GDC, se utilizan las siguientes funciones de Cloud Service Mesh:
- Equilibrio de carga: Cloud Service Mesh separa el flujo del tráfico del escalado de la infraestructura, lo que abre las puertas a muchas funciones de gestión del tráfico, como el enrutamiento dinámico de solicitudes. ServiceNow requiere conexiones de cliente persistentes, por lo que habilitamos las sesiones fijas mediante
DestinationRulespara configurar el comportamiento del enrutamiento del tráfico.
Terminación de TLS: Cloud Service Mesh expone las pasarelas de entrada mediante certificados TLS y proporciona autenticación de transporte en el clúster a través de mTLS (Seguridad en la capa de transporte mutua) sin tener que cambiar el código de la aplicación.
Recuperación tras fallos: Cloud Service Mesh incluye varias funciones de recuperación tras fallos críticos, como tiempos de espera, disyuntores, comprobaciones activas del estado y reintentos vinculados.
En el clúster de Kubernetes, usamos objetos Service estándar como una forma abstracta de exponer los servidores de aplicaciones y bases de datos a la red. Los servicios proporcionan una forma cómoda de orientar las instancias mediante un selector y ofrecen resolución de nombres en el clúster mediante un servidor DNS compatible con el clúster.
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
Computación
ServiceNow recomienda usar máquinas físicas o virtuales para alojar instalaciones locales. Nosotros hemos utilizado la gestión de máquinas virtuales de GDC para implementar los servidores de aplicaciones y de bases de datos como cargas de trabajo de máquinas virtuales. Definir recursos de Kubernetes nos permitió especificar tanto el VirtualMachine como el VirtualMachineDisk para adaptar los recursos a nuestras necesidades de los diferentes tipos de servidores. VirtualMachineExternalAccess nos permite configurar la transferencia de datos hacia y desde 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
Para la imagen del SO invitado, creamos una imagen personalizada basada en Red Hat Enterprise Linux para cumplir nuestros requisitos de cumplimiento y seguridad. Es posible conectarse a instancias de VMs en ejecución a través de SSH mediante VirtualMachineAccessRequest, lo que nos permite limitar la capacidad de conectarnos a VMs a través del control de acceso basado en roles (RBAC) de Kubernetes y evitar la necesidad de crear cuentas de usuario locales en las imágenes personalizadas. La solicitud de acceso también define un tiempo de vida (TTL) que permite gestionar las solicitudes de acceso basadas en el tiempo de las máquinas virtuales que caducan automáticamente.
Automatización
Como resultado clave de este proyecto, hemos diseñado un método para instalar instancias de ServiceNow de forma repetible que pueda admitir una automatización exhaustiva y reducir las diferencias de configuración entre los despliegues.
Helm Packaging
Helm es un gestor de paquetes para Kubernetes que gestiona el ciclo de vida de las aplicaciones, incluida la instalación y la actualización de todos los componentes que forman una aplicación. Helm también ofrece una forma de gestionar las dependencias, como los recursos personalizados necesarios para integrarse con otros sistemas, como la observabilidad y el cumplimiento. La creación de gráficos de Helm nos permite encapsular estos recursos, lo que simplifica el proceso de instalación y gestión de ServiceNow.
Proceso de lanzamiento
Para personalizar las imágenes del servidor de aplicaciones y del servidor de bases de datos, se parte de una imagen del sistema operativo base y se modifica según sea necesario para instalar las dependencias necesarias para cada imagen del servidor. Hemos seleccionado Red Hat Enterprise Linux (RHEL) como imagen del SO base por su amplia adopción en las instalaciones on-premise de ServiceNow. Red Hat Enterprise Linux también ofrece funciones de refuerzo de la seguridad necesarias para cumplir las guías técnicas de implementación de seguridad (STIGs) que se necesitan para ofrecer una imagen conforme a los controles de NIST 800-53.
Nuestro flujo de integración continua (CI) usaba el siguiente flujo de trabajo para personalizar las imágenes de los servidores de aplicaciones y de bases de datos:
Cuando los desarrolladores hacen cambios en las secuencias de comandos de personalización o en las dependencias de imágenes, activamos un flujo de trabajo automatizado en nuestras herramientas de integración continua para generar un nuevo conjunto de imágenes que se incluyen en los lanzamientos de GDC. Como parte de la creación de imágenes, también actualizamos las dependencias del SO (yum update) y esparcimos la imagen con compresión para reducir el tamaño de la imagen necesario para transferir imágenes a los entornos de los clientes.
Ciclo de vida del desarrollo de software
El ciclo de vida de desarrollo de software (SDLC) es un proceso que ayuda a las organizaciones a planificar, crear, probar y desplegar software. Si siguen un SDLC bien definido, las organizaciones se aseguran de que el software se desarrolle de forma coherente y repetible, y de identificar posibles problemas en las primeras fases. Además de crear imágenes en nuestro flujo de integración continua (CI), también definimos entornos para desarrollar y organizar versiones previas al lanzamiento de ServiceNow con el fin de realizar pruebas y asegurar la calidad.
Implementar una instancia independiente de ServiceNow por proyecto de GDC nos permitió probar los cambios de forma aislada, sin que afectaran a las instancias existentes en la misma instancia de GDC. Hemos usado la API ResourceManager para crear y eliminar proyectos de forma declarativa mediante recursos de 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
Si se combina con el empaquetado de gráficos de Helm y la gestión de la infraestructura, como las máquinas virtuales, como código, los desarrolladores pueden iterar rápidamente haciendo cambios y probando nuevas funciones junto con las instancias de producción. La API declarativa también permite que los frameworks de ejecución de pruebas automatizadas realicen pruebas de regresión periódicas y verifiquen las funciones existentes.
Operatividad
La operatividad es la facilidad con la que se puede utilizar y mantener un sistema. Es un aspecto importante a tener en cuenta al diseñar cualquier aplicación de software. La monitorización eficaz contribuye a la operatividad porque permite identificar y abordar los problemas antes de que tengan un impacto significativo en el sistema. La monitorización también se puede usar para identificar oportunidades de mejora y establecer una base para los objetivos de nivel de servicio.
Supervisión
Hemos integrado ServiceNow con la infraestructura de observabilidad de GDC, incluidos los registros y las métricas. En el caso de las métricas, exponemos endpoints HTTP de cada VM que permiten a Prometheus extraer puntos de datos generados por los servidores de aplicaciones y de bases de datos. Estos endpoints incluyen métricas del sistema recogidas con el exportador de nodos de Prometheus y métricas específicas de la aplicación, por ejemplo, con un exportador de bases de datos MySQL.
Con los endpoints expuestos en cada VM, hemos configurado el comportamiento de sondeo de Prometheus mediante el recurso personalizado MonitoringTarget para definir el intervalo de raspado y anotar las métricas.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
name: database-monitor
spec:
podMetricsEndpoints:
path:
value: /metrics
port:
annotation: application.io/dbMetrics
scrapeInterval: 60s
Para el registro, instalamos y configuramos FluentBit en cada máquina virtual para monitorizar los registros relevantes y enviar los datos de registro a Loki, donde los datos se indexan y se consultan a través de Grafana. Los registros de auditoría se reenvían a un endpoint especial configurado con una conservación ampliada para cumplir los requisitos. Las aplicaciones basadas en contenedores pueden usar los recursos personalizados LoggingTarget y AuditLoggingTarget para indicar a la canalización de registro que recoja registros de servicios específicos de tu proyecto.
A partir de los datos disponibles en Prometheus y Loki, creamos alertas mediante el recurso personalizado MonitoringRule, que nos permite gestionar esta configuración como código en nuestro gráfico de Helm. Usar una API declarativa para definir alertas y paneles de control también nos permite almacenar esta configuración en nuestro repositorio de Git y seguir los mismos procesos de revisión de código e integración continua que usamos para cualquier otro cambio de código.
Modos de fallo
Las primeras pruebas revelaron varios modos de fallo relacionados con los recursos, lo que nos ayudó a priorizar las métricas y las alertas que debíamos añadir primero. Empezamos monitorizando el uso elevado de memoria y disco, ya que la configuración incorrecta de la base de datos provocó que las tablas de búfer consumieran toda la memoria disponible y que el registro excesivo llenara el disco de volumen persistente adjunto. Después de ajustar el tamaño del búfer de InnoDB e implementar una estrategia de rotación de registros, introdujimos alertas que se activan si las VMs se acercan a un uso elevado de memoria o disco. También hemos creado un runbook y asignado un código de error para que los operadores puedan consultar rápidamente la documentación sobre cómo diagnosticar y mitigar el problema si se activa la alerta.
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"
Después de verificar la estabilidad del sistema, nos centramos en los modos de fallo de la aplicación en ServiceNow. Como para depurar los problemas de la aplicación a menudo teníamos que usar Secure Shell (SSH) en cada VM del servidor de aplicaciones para consultar los registros del sistema de ServiceNow, configuramos FluentBit para que reenviara estos registros a Loki. De esta forma, pudimos aprovechar la pila de observabilidad de GDC y consultar todos los registros operativos de ServiceNow en Grafana.
El registro centralizado también nos permitió consultar los registros de varias VMs al mismo tiempo, lo que consolidó nuestra visión de cada componente del sistema. Después, incorporamos consultas de búsqueda de registros a nuestros runbooks, lo que permitió a los operadores asociar condiciones de error con soluciones y alternativas conocidas.
Copias de seguridad
Las copias de seguridad son importantes para el funcionamiento de un sistema de software porque permiten restaurar el sistema en caso de fallo.
GDC ofrece la creación de copias de seguridad y la restauración de VMs mediante recursos de Kubernetes. Si creamos un recurso personalizado VirtualMachineBackupRequest con un recurso personalizado VirtualMachineBackupPlanTemplate, podemos hacer una copia de seguridad del volumen persistente conectado a cada VM en el almacenamiento de objetos, donde las copias de seguridad se pueden conservar siguiendo una política de conservación definida a través de un segmento.
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
Del mismo modo, restaurar el estado de una VM a partir de una copia de seguridad implica crear un recurso personalizado VirtualMachineRestoreRequest para restaurar tanto los servidores de aplicaciones como los de bases de datos sin modificar el código ni la configuración de ninguno de los servicios.
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
name: vm-restore-1
spec:
virtualMachineBackup: db-vm-backup
restoreName: restore1
restoredResourceName: db1
Actualizaciones
Para admitir el ciclo de vida del software de ServiceNow y sus dependencias, hemos identificado tres tipos de actualizaciones de software, cada una de las cuales se gestiona de forma ligeramente diferente para minimizar el tiempo de inactividad y las interrupciones del servicio:
- Actualizaciones del SO.
- Actualizaciones de la plataforma, como parches y versiones principales.
- Actualizaciones de configuración.
En el caso de las actualizaciones del SO, creamos y lanzamos continuamente nuevas imágenes de VM para servidores de aplicaciones y de bases de datos, que se distribuyen con cada lanzamiento de GDC. Estas imágenes contienen correcciones de vulnerabilidades de seguridad y actualizaciones del sistema operativo Red Hat subyacente. Para desplegar las nuevas imágenes, los operadores siguen manuales de procedimientos que detallan los pasos necesarios para subir e iniciar nuevas VMs, verificar la configuración y retirar las instancias anteriores.
Las actualizaciones de la plataforma ServiceNow requieren que se apliquen actualizaciones a las imágenes de VM existentes, por lo que no podemos usar una infraestructura inmutable para aplicar parches y actualizaciones de versiones principales. En el caso de las actualizaciones de la plataforma, probamos y verificamos la versión del parche o de la versión principal en nuestros entornos de desarrollo y de pruebas antes de lanzar un paquete de actualización independiente junto con la versión de GDC. Para aplicar parches y actualizaciones de versiones principales, los operadores siguen los runbooks para conectarse a las instancias de VM, subir el paquete de actualización e iniciar la actualización desde cada VM en ejecución.
Por último, las actualizaciones de configuración se aplican sin tiempo de inactividad mediante las APIs de ServiceNow para conjuntos de actualizaciones y otros datos de usuario. Desarrollamos y probamos las actualizaciones de configuración en nuestros entornos de desarrollo y de staging antes de empaquetar varios conjuntos de actualizaciones durante el proceso de lanzamiento de GDC. A continuación, los operadores siguen los runbooks para invocar una herramienta de línea de comandos que hemos desarrollado y que llama a las APIs de ServiceNow correspondientes para subir y aplicar conjuntos de actualizaciones.
Integraciones
Proveedores de identidades
Para ofrecer a los clientes una experiencia fluida y permitir que las organizaciones incorporen a sus usuarios, integramos ServiceNow con varios proveedores de identidades disponibles en GDC. Normalmente, los clientes de empresas y del sector público tienen sus propios proveedores de identidades bien gestionados, como Active Directory u otros sistemas similares, para conceder y revocar derechos a sus empleados. Debido a los requisitos de cumplimiento y a la facilidad de la gestión de identidades y accesos, estos clientes quieren usar sus proveedores de identidades como fuente de información veraz para gestionar el acceso de sus empleados a ServiceNow.
ServiceNow admite proveedores de SAML 2.0 y OIDC a través de su módulo de proveedor de identidades múltiples, que hemos prehabilitado en nuestra imagen de VM del servidor de aplicaciones. Tanto los operadores de infraestructura como los clientes se autentican a través de su proveedor de identidades de la organización, que crea automáticamente usuarios y asigna roles en ServiceNow.
El acceso saliente a los servidores del proveedor de identidades se permite a través del recurso personalizado ProjectNetworkPolicy, que limita si se puede acceder a los servicios externos desde una organización de GDC. Estas políticas nos permiten controlar de forma declarativa a qué endpoints puede acceder ServiceNow en la red.
Ingestión de alertas
Además de permitir que los usuarios inicien sesión para crear casos de asistencia manualmente, también nos integramos con Prometheus AlertManager para crear incidentes de ServiceNow en respuesta a las alertas del sistema. Esta integración permite a los operadores clasificar y resolver problemas de software y hardware en el entorno de GDC conectando nuestros sistemas de observabilidad y de asistencia con un punto de entrada centralizado.
Para lograr esta integración, personalizamos un webhook de Kubernetes de código abierto para recibir alertas de Prometheus y gestionar el ciclo de vida de los incidentes mediante el endpoint de la API de ServiceNow expuesto a través de Cloud Service Mesh. Una vez que se crea un incidente en ServiceNow, los operadores pueden iniciar un flujo de trabajo de incidentes para categorizar y priorizar los incidentes a medida que se producen, siguiendo los enlaces para ver el estado en tiempo real de la alerta activada en Grafana.
Las claves de API se almacenan en el almacén de secretos de GDC, que se basa en secretos de Kubernetes controlados mediante el control de acceso basado en roles (RBAC). Otras configuraciones, como los endpoints de la API y los campos de personalización de incidentes, se gestionan mediante el almacenamiento de valores clave de ConfigMap de Kubernetes.
Correo electrónico
ServiceNow ofrece integraciones de servidores de correo para que los clientes puedan recibir asistencia por correo electrónico. Los flujos de trabajo automatizados convierten los correos de los clientes en casos de asistencia y envían respuestas automáticas a los clientes con enlaces a los casos, lo que permite que nuestro equipo de Asistencia gestione mejor su bandeja de entrada, haga un seguimiento sistemático de las solicitudes por correo y las resuelva, y proporcione un mejor servicio de atención al cliente.
Para integrarnos con los servicios SMTP y POP3 expuestos en GDC, usamos políticas de red para controlar el acceso entre proyectos. Alojar componentes de correo en un proyecto independiente nos permite desacoplar el correo como servicio que pueden reutilizar otras aplicaciones.
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
Al exponer el correo como un servicio de Kubernetes, también se proporciona el descubrimiento de servicios y la resolución de nombres de dominio, y se desacopla aún más el backend del servidor de correo de los clientes, como ServiceNow.
Cumplimiento
Registros de auditoría
Los registros de auditoría contribuyen a la postura de cumplimiento, ya que proporcionan una forma de monitorizar el uso del software y de hacer un seguimiento del mismo, así como de registrar la actividad del sistema. Los registros de auditoría registran los intentos de acceso de usuarios no autorizados, monitorizan el uso de las APIs e identifican posibles riesgos de seguridad. Los registros de auditoría cumplen los requisitos de cumplimiento normativo, como los que imponen la ley de transferencia y responsabilidad de los seguros médicos de EE. UU. (HIPAA), el estándar de seguridad de datos del sector de las tarjetas de pago (PCI DSS) y la ley Sarbanes-Oxley (SOX).
GDC proporciona un sistema para registrar las actividades y los accesos administrativos en la plataforma, así como para conservar estos registros durante un periodo configurable. Al desplegar el recurso personalizado AuditLoggingTarget, se configura la canalización de registro para recoger los registros de auditoría de nuestra aplicación.
En ServiceNow, hemos configurado destinos de registro de auditoría tanto para los eventos de auditoría del sistema recogidos del daemon auditd en Red Hat Enterprise Linux como para los eventos específicos de la aplicación generados por el registro de auditoría de seguridad de ServiceNow. Ambos tipos de registros se envían a una instancia de Loki centralizada en la que podemos escribir consultas y ver paneles de control en Grafana.
Control de acceso
El control de acceso es el proceso de conceder o denegar el acceso a los recursos en función de la identidad del usuario o del proceso que solicita el acceso. De esta forma, se protegen los datos frente a accesos no autorizados y se asegura que solo los usuarios autorizados puedan hacer cambios en el sistema. En GDC, usamos el control de acceso basado en roles (RBAC) de Kubernetes para declarar políticas y aplicar la autorización a los recursos del sistema que componen la aplicación ServiceNow.
Definir un ProjectRole en GDC nos permite conceder acceso detallado a los recursos de Kubernetes mediante un rol de autorización predefinido.
Si se combina con otros roles predefinidos, como el de administrador de VMs (vm-admin), los operadores pueden enlazarse a uno o varios roles para depurar problemas y realizar tareas de mantenimiento rutinarias.
Definir un ProjectRole en GDC nos permite conceder acceso detallado a los recursos de Kubernetes mediante un rol de autorización predefinido.
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
Al gestionar los roles y las vinculaciones de roles a través de un sistema de infraestructura como código (IaC), como GitLab, y un servicio de sincronización, como Config Management, los operadores pueden obtener acceso elevado temporal a un rol mediante un proceso de aprobación. Estos sistemas también proporcionan acceso al sistema durante un tiempo limitado y, al mismo tiempo, mantienen un registro de auditoría de los cambios del sistema.
Runbooks
Los runbooks son importantes para mantener una aplicación de software conforme, ya que proporcionan una guía paso a paso para completar las tareas. Esto puede ayudar a asegurar que todas las tareas se completen correctamente y de conformidad con todas las leyes y normativas aplicables. Los runbooks también pueden ayudar a asegurarse de que todos los miembros del equipo conozcan sus responsabilidades y cómo llevarlas a cabo. Hemos creado runbooks para ServiceNow con el fin de llevar a cabo tareas administrativas, como rotar contraseñas, reiniciar servidores y otros procedimientos operativos estándar.
Recuperación tras fallos
Replicación de bases de datos
Para cumplir los requisitos de recuperación tras desastres, implementamos ServiceNow en una configuración principal-secundaria en varias instancias de GDC. En este modo, las solicitudes a ServiceNow se dirigen normalmente al sitio principal, mientras que el sitio secundario replica continuamente el registro binario de la base de datos MariaDB. En caso de que se produzca una conmutación por error, el sitio secundario se convierte en el nuevo sitio principal y las solicitudes se dirigen a este.
Aprovechamos las funciones de replicación de MariaDB para configurar los servidores de bases de datos principal y de réplica por instancia de GDC en función de los parámetros definidos durante la implementación de Helm.
Para habilitar la replicación en una instancia que se haya ejecutado durante más tiempo que el periodo de conservación del registro binario, podemos restaurar la base de datos de réplica con Mariabackup, que también registra el identificador de transacción global (GTID) para iniciar la replicación desde la base de datos principal.
En el modo principal, los servidores de aplicaciones y la base de datos funcionan igual que ahora, pero la base de datos principal está configurada para habilitar la replicación. Por ejemplo:
Habilita el registro binario.
Defina el ID de servidor.
Crea una cuenta de usuario de replicación.
Crea una copia de seguridad que incluya información de GTID.
En el modo de réplica, los servidores de aplicaciones inhabilitarán el servicio web de ServiceNow para evitar que se conecten directamente a la base de datos de réplica. La base de datos de réplica debe configurarse para iniciar la replicación desde la base de datos principal. Por ejemplo:
Defina el ID de servidor.
Configura las credenciales del usuario de replicación y los detalles de la conexión principal, como el host y el puerto.
Restaurar a partir de una copia de seguridad y reanudar la posición del registro binario a partir del GTID.
La replicación de bases de datos requiere conectividad de red para que la réplica se conecte a la base de datos principal y empiece la replicación. Para exponer el endpoint de la base de datos principal para la replicación, podemos usar Cloud Service Mesh para crear una puerta de enlace de entrada de Istio que admita la terminación de TLS en la puerta de enlace de Istio, de forma similar a como gestionamos la transferencia de datos HTTPS en la aplicación web de ServiceNow.
Procedimiento de conmutación por error
En caso de conmutación por error, el sitio secundario se convierte en el nuevo sitio principal y las solicitudes se dirigen al nuevo sitio principal. Este proceso es inicialmente un procedimiento manual, pero se puede automatizar cada vez más con esfuerzos adicionales.
En el sitio principal:
Detén el servicio de ServiceNow en los servidores de aplicaciones.
Configura el servidor de bases de datos en modo de réplica.
Inicia el servicio de proxy inverso si se usa en servidores de aplicaciones.
En el sitio secundario:
Detén la replicación en el servidor de bases de datos.
Detén el servicio de proxy inverso si se usa en servidores de aplicaciones.
Configura el servidor de bases de datos en modo principal.
Inicia el servicio de ServiceNow en los servidores de aplicaciones.
Tener un procedimiento de conmutación por error documentado en nuestros manuales de operaciones ayuda a asegurar que las operaciones no se interrumpan en caso de desastre y reduce el tiempo necesario para recuperarse de un desastre.