En este documento, se analizan los patrones de arquitectura para encontrar y recopilar información sobre los elementos en Google Cloud, en otras plataformas en la nube y de forma local mediante el descubrimiento de servicios en la nube de ServiceNow. El documento está dirigido a equipos de arquitectura o de operaciones en la nube familiarizados con la administración de operaciones de TI (ITOM); la biblioteca de infraestructura de tecnología de la información (ITIL); los servicios de Google Cloud, como Compute Engine, Google Kubernetes Engine (GKE) y Cloud Asset Inventory; y ServiceNow Cloud Discovery.
Descripción general
Muchas empresas grandes usan una implementación de infraestructura de TI híbrida que combina Google Cloud, otras plataformas en la nube y la infraestructura local. Esta implementación híbrida suele ser la iteración inicial en una estrategia de migración a la nube. Los departamentos de TI de estas empresas deben descubrir y realizar un seguimiento de todos los recursos de su ecosistema técnico, lo que podría llegar a ser millones. Los departamentos de TI deben construir un sistema de administración de configuración que vincule estos recursos con los servicios técnicos que proporcionan los activos. Este sistema también debe supervisar los recursos y servicios de una manera que admita las prácticas recomendadas de administración de operaciones de TI (ITOM) y administración de servicios de TI (ITSM).
Para los clientes de Google Cloud, una arquitectura común usa el descubrimiento de recursos en la nube de ServiceNow para encontrar y recopilar información sobre elementos en Google Cloud, en otras plataformas en la nube y de forma local. ServiceNow ofrece una amplia gama de herramientas para automatizar flujos de trabajo de TI de administración de recursos en varios proveedores de servicios en la nube. Herramientas como Cloud Operations Workspace permiten que los departamentos de TI creen paneles de recursos de múltiples nubes y administren configuraciones complejas a través de una interfaz unificada (a veces llamada panel único). En este documento, se presenta un conjunto de patrones de arquitectura para este caso, una descripción general de sus componentes de alto nivel y un análisis de las consideraciones de diseño generales.
Componentes de ServiceNow para esta arquitectura
Los componentes de la plataforma ServiceNow en estos patrones de arquitectura incluyen lo siguiente:
- Una instancia de ServiceNow que contiene una base de datos de administración de configuración (CMDB) de elementos de configuración (CIs). Cada CI representa componentes de tu entorno operativo que están involucrados en la entrega de servicios digitales. Un CI tiene varios atributos que contienen metadatos específicos sobre el componente y sus relaciones a otros CI.
- Uno o más servidores de administración de servicios, instrumentación y descubrimiento (MID) de ServiceNow que se ejecutan en tu proyecto de Google Cloud. Los servidores de MID recopilan los metadatos para los CI y los almacenan en la CMDB.
En estos patrones de arquitectura, se definen algunas prácticas comunes para importar datos de Cloud Asset Inventory de Google al descubrimiento de inventario de recursos de Google Cloud Platform.
Patrones de arquitectura para la integración de Google Cloud
En este documento, se analizan los siguientes patrones de arquitectura para integrar Google Cloud en ServiceNow:
Estos patrones de arquitectura de ejemplo están diseñados para una implementación híbrida que incluye alguna infraestructura en Google Cloud y otras en la nube de ServiceNow. Demuestran cómo funciona ServiceNow en Google Cloud entre la infraestructura administrada por Google y la infraestructura administrada por el cliente. Los servidores MID de ServiceNow consultan toda la infraestructura administrada por Google mediante llamadas a las APIs de Cloud de Google. Para obtener más información sobre a qué API se llama, consulta APIs de Google Cloud Platform usadas por las aplicaciones de TIOM.
En cada uno de los siguientes patrones, los componentes de la arquitectura funcionan juntos en el Proceso de descubrimiento de inventario de los elementos de Google Cloud Platform para recopilar la información del inventario de recursos de la nube que requiere la aplicación ServiceNow Discovery y las herramientas relacionadas.
Patrón de descubrimiento de Google Cloud
El patrón básico de arquitectura de descubrimiento de servicios en la nube de ServiceNow usa los servidores de MID de ServiceNow para llamar a Google Cloud Asset Inventory y otras APIs de Google Cloud a fin de recopilar datos sobre recursos como los siguientes:
- Instancias de VM
- Etiquetas de instancia (claves/valores)
- Volúmenes de almacenamiento y asignación de almacenamiento
- Recursos de centros de datos, incluidos los tipos de hardware
- Redes de subred, subredes y puertas de enlace
- Imágenes
- Balanceadores de cargas de Cloud y zonas de disponibilidad
- Bases de datos en la nube y clústeres de bases de datos
- Contenedores (GKE)
- Asignación de servicios según las etiquetas de recursos
En este patrón, los servidores de MID no necesitan credenciales, ya que no acceden a las VMs para recopilar datos. Esto limita la capacidad del proceso de descubrimiento para recopilar información adicional. Sin embargo, impone un costo operativo menor, ya que elimina la necesidad de administrar y rotar las credenciales del servidor MID.
En el siguiente diagrama, se ilustra esta arquitectura.
La parte de Google Cloud de este patrón consta de los siguientes elementos:
- Un proyecto de Google Cloud (proyecto de servicio A en el diagrama), que consta de dos balanceadores de cargas de Google Cloud, una o más instancias de VM, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor de MID se ejecuta en su propia VM.
- Un segundo proyecto de Google Cloud (proyecto de servicio B en el diagrama), que consiste en servidores MID que se ejecutan en sus propias VMs.
- Un tercer proyecto de Google Cloud (proyecto host C en el diagrama), que consiste en la interconexión de socio.
- Servicios administrados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage
- Rutas de red que se configuran desde los servidores de MID hasta las APIs de Google Cloud.
La parte de ServiceNow consiste en la instancia de ServiceNow, que captura los metadatos de los servidores de MID y los almacena en la CMDB.
Patrón de descubrimiento basado en IP sin agentes de Google Cloud
Este patrón de arquitectura agrega Descubrimiento basado en IP al patrón de descubrimiento básico en la nube mediante un trabajo por lotes y una cuenta de servicio de Google Cloud para acceder a las VMs y recopilar detalles adicionales. Este patrón requiere más una carga operativa para administrar el servidor MID que el patrón básico, ya que requiere que administres y rotes las credenciales del servidor MID. Sin embargo, se expande el proceso de descubrimiento más allá de los datos que proporciona Cloud Asset Inventory para incluir datos adicionales, como los siguientes:
- Seguridad y administración de credenciales del SO
- Descubrimiento mejorado, como el descubrimiento basado en archivos y el descubrimiento de licencias
- Detalles del SO
- Procesos en ejecución
- Conexiones TCP
- Software instalado
En este patrón de arquitectura, uno o más servidores MID de ServiceNow se encuentran en Google Cloud, mientras que la instancia de ServiceNow está alojada en la plataforma en la nube de ServiceNow. Los servidores MID están conectados a la instancia de ServiceNow a través de la cola de canales de comunicación externa de MID del servidor (ECC) (no se muestra). Esta arquitectura se muestra en el siguiente diagrama.
La parte de Google Cloud de este patrón consta de los siguientes elementos:
- Proyecto del servicio A, que consta de dos balanceadores de cargas de Google Cloud, una o más VMs, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor de MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- Proyecto C de host, que consiste en la interconexión de socio.
- Servicios administrados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage
- Service Discovery de Kubernetes implementado en la infraestructura de GKE.
- Rutas de red que se configuran desde los servidores de MID hasta las APIs de Google Cloud.
- Cuentas de servicio que permiten que los servidores MID accedan a cualquier VM de Google Cloud que requiera el descubrimiento de direcciones IP sin servidores.
- Rutas de red configuradas desde los servidores de MID hasta cualquier VM de Google Cloud que requiera la detección de direcciones IP sin servidores.
La parte de ServiceNow consiste en la instancia de ServiceNow, que captura los metadatos de los servidores de MID y los almacena en la CMDB.
Descubrimiento de Google Cloud con patrón de recopilador de clientes con agentes
En este patrón de arquitectura, se incluye lo siguiente:
- El descubrimiento inicial en la nube.
- Uno o más servidores MID.
Un agente adicional de ServiceNow, el recopilador de clientes del agente, que instalas en tus VMs. Estos agentes se conectan directamente a los servidores de MID y comparten la siguiente información adicional a ServiceNow:
- Descubrimiento basado en envíos casi en tiempo real
- Medición de software
- Vista de CI en vivo
- Automatización de flujos de trabajo para servidores
En el siguiente diagrama, se ilustra esta arquitectura.
La parte de Google Cloud de este patrón consta de los siguientes elementos:
- Proyecto del servicio A, que consta de dos balanceadores de cargas de Google Cloud, una o más instancias de VM, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor de MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- Proyecto C de host, que consiste en la interconexión de socio.
- Service Discovery de Kubernetes implementado en la infraestructura de GKE.
- Servicios administrados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage
- Rutas de red que se configuran desde los servidores de MID hasta las APIs de Google Cloud.
- Rutas de red configuradas desde los servidores de MID hasta las VMs de Google Cloud que tienen instalados agentes de descubrimiento de ServiceNow.
La parte de ServiceNow consta de lo siguiente:
- La instancia de ServiceNow, que captura los metadatos de los servidores de MID y los almacena en la CMDB.
- Agentes de descubrimiento de ServiceNow que se instalan en las VMs de Google Cloud administradas por el cliente.
Flujo de trabajo de descubrimiento de recursos de Cloud
En las siguientes secciones, se analiza el flujo de trabajo para el descubrimiento de recursos de Google Cloud. Este flujo de trabajo se aplica a los tres patrones de arquitectura que se describen en este documento.
Instala y configura componentes de ServiceNow
- Habilita las APIs de Cloud Asset Inventory.
- Instala el colector de clientes en tus VMs. Para obtener más información, consulta Instalación del colector de clientes del agente.
- Asigna recursos para computadoras que alojan los servidores de MID.
- Configura las reglas de firewall para permitir conexiones en el puerto 443 entre tu instancia de VM y las computadoras que alojan los servidores de MID.
- Configura la conectividad de red del servidor MID.
- Instala los servidores de MID.
- Configura los servidores MID para llamar a las APIs de Google Cloud relevantes. Asegúrate de que los servidores de MID tengan una ruta de red válida para llamar a las APIs de Google Cloud.
Flujo de trabajo
- Cloud Asset Inventory compila una base de datos de todos los tipos de recursos compatibles en el entorno de Google Cloud. ServiceNow usa Cloud Asset Inventory como fuente para recuperar información adicional a fin de actualizar la CMDB.
- Los servidores de MID de ServiceNow consultan la base de datos de Cloud Asset Inventory para obtener información sobre todos los elementos del entorno de Google Cloud.
- Los servidores de MID almacenan la información de los elementos de la nube en un bucket de Cloud Storage.
- No toda la información requerida se puede obtener de la base de datos de Cloud Asset Inventory. En el patrón sin agentes, la información de VM no incluye la versión actual del parche del SO. Para este nivel de detalle, los servidores MID realizan un descubrimiento profundo mediante la siguiente acción:
- Los servidores MID crean un trabajo por lotes basado en las direcciones IP de las VMs que requieren un descubrimiento profundo.
- En el trabajo por lotes, los servidores de MID acceden a cada VM y consultan el SO para el control de versiones de parches y otra información.
- Si los colectores de clientes del agente están instalados, los datos que capturan se transmiten a los servidores MID directamente, en lugar de almacenarse en la base de datos de Cloud Asset Inventory. Para obtener más información, consulta Preparación de herramientas de redes y Configuración del servidor MID.
- Después de recopilar los datos de descubrimiento de recursos, los servidores de MID los almacenan en la CMDB de la siguiente manera:
- Los servidores MID crean CI en la CMDB para representar la capacidad operativa que proporciona cada recurso.
- Los servidores MID descubren de forma automática las etiquetas de Google Cloud y las almacenan en la CMDB. Estas etiquetas se asignan a las CI de forma automática y son útiles para crear mapas de servicios.
El proceso de flujo de trabajo debe repetirse de forma periódica según sea necesario. Según la escala y la configuración de tu implementación, puedes elegir un descubrimiento basado en eventos o en programas. Para obtener más información, consulta “Administra el ciclo de vida de CI” en la Guía de diseño de CMDB.
Consideraciones del diseño
En las siguientes secciones, se proporciona orientación de diseño para implementar cualquiera de los patrones de arquitectura que se describen en este documento.
Ubicación de la instancia de ServiceNow
Para la mayoría de los casos de uso, recomendamos implementar los servidores de MID en Google Cloud. De esta manera, las instancias están cerca de los recursos de la nube en los que realizan un descubrimiento profundo.
En los patrones de arquitectura de este documento, se supone que tu CMDB almacena datos de descubrimiento para todos tus recursos de nube y todos los recursos locales, no solo los recursos de Google Cloud. La CMDB se puede encontrar en la nube de ServiceNow, en Google Cloud o de forma local. La decisión final sobre dónde ubicar la CMDB en tu entorno depende de tus requisitos específicos.
Decide usar agentes de servidor MID
Otra consideración del diseño es usar agentes y cuentas de servicio del servidor MID. Si tu proceso de descubrimiento necesita recopilar información más allá de los metadatos que proporciona Cloud Asset Inventory, debes usar una infraestructura de servidor MID con cuentas de servicio o, como alternativa, un servidor MID con el Recopilador de clientes del agente. Cualquiera de los dos enfoques puede afectar el costo de asistencia operativa, que debes tener en cuenta en tu diseño. El enfoque que debes usar depende de los datos que necesites capturar y de cómo los usarás. El costo operativo de capturar los datos podría superar el valor que proporcionan.
Compatibilidad multirregional para servidores MID
Si tu empresa requiere compatibilidad multirregional de la infraestructura del servidor MID, debes planificar implementar cada servidor MID en al menos dos zonas de disponibilidad y replicarlo en otra región.
Implicaciones de costo
Cuando eliges dónde implementar los componentes de ServiceNow para el descubrimiento de recursos de Google Cloud, debes tener en cuenta el costo de salida y el costo de procesamiento.
Costo de salida
Se generan cargos de salida cada vez que los datos salen de Google Cloud. Por este motivo, debes analizar el costo de salida del caso de uso para determinar la mejor opción a fin de ubicar los componentes de ServiceNow. Por lo general, los servidores MID que realizan un descubrimiento profundo generan costos de salida más bajos si se ejecutan en Google Cloud que si se ejecutan en otra nube o de forma local.
Costo de procesamiento
Los componentes de ServiceNow que se ejecutan en Google Cloud generan costos de procesamiento que debes analizar a fin de determinar el mejor valor para tu empresa.
Por ejemplo, debes considerar la cantidad de servidores MID que implementas en las instancias de Compute Engine de Google Cloud. La implementación de más servidores MID hace que el proceso de descubrimiento de elementos sea más rápido. Sin embargo, hacerlo aumenta el costo de procesamiento, ya que cada servidor MID se implementa en su propia instancia de VM. Para obtener más información sobre si debes implementar uno o varios servidores MID, consulta Instala varios servidores de MID en un solo sistema.
Consideraciones sobre la compatibilidad operativa
Es probable que tu implementación incluya controles de seguridad de red, como firewalls, sistemas de protección contra intrusiones, sistemas de detección de intrusiones y una infraestructura de duplicación de paquetes. Si hay muchos controles de seguridad de red entre Google Cloud y el entorno en el que se implementan los servidores MID, estos controles pueden crear problemas de compatibilidad operativa. Para evitar estos problemas, te recomendamos que alojes los servidores de MID en Google Cloud o lo más cerca posible de la infraestructura de Google Cloud a la que se consultará un descubrimiento profundo.
Protege los servidores de MID
Recomendamos las siguientes prácticas de seguridad para las instancias de MID Server:
- Asegúrate de que los servidores MID estén aislados para ayudar a garantizar que solo los administradores de confianza puedan conectarse a ellos.
- Asegúrate de que los servidores de MID estén protegidos contra la eliminación.
- Asegúrate de que las funciones de IAM se apliquen para limitar la capacidad de cambios solo a los cambios aprobados mediante procesos de ITIL o una canalización de CI/CD.
Protege las cuentas de servicio
Recomendamos las siguientes prácticas de seguridad para administrar cuentas de servicio:
- Si alojas tus servidores MID en Google Cloud, la autenticación se maneja de forma automática mediante la cuenta de servicio asociada. Si alojas tus servidores MID fuera de Google Cloud, eres responsable de generar una clave de cuenta de servicio administrada por el usuario para la autenticación y, luego, proteger y auditar esta credencial persistente. Si quieres obtener más información, consulta Prácticas recomendadas para administrar claves de cuentas de servicio.
- Asegúrate de que los servidores MID usen una cuenta de servicio que solo tenga los roles y los permisos de IAM que son absolutamente necesarios para el descubrimiento de recursos. Si deseas obtener más información, consulta Prácticas recomendadas para trabajar con cuentas de servicio.
Estructura de carpetas y proyectos
Las carpetas y los proyectos son nodos en la jerarquía de recursos de Google Cloud. Para admitir el descubrimiento de recursos, la estructura de tu carpeta y proyecto debe reflejar la estructura de tu aplicación y de los entornos en los que se implementa la aplicación. La estructuración de tus recursos de esta manera también permite que ServiceNow asigne tus recursos a los servicios técnicos que proporcionan.
Ten en cuenta los cambios que realices en la estructura de la carpeta y el proyecto para admitir el descubrimiento de ServiceNow. El rol principal de la estructura de carpetas y proyectos es admitir la facturación y el acceso a IAM. Por lo tanto, cualquier cambio que realices para admitir ServiceNow debe admitir y alinearse con la estructura de facturación de Google Cloud de tu organización. Si deseas obtener prácticas recomendadas para estructurar la organización, las carpetas y la jerarquía de proyectos de Google Cloud, consulta Jerarquía de recursos y Crea y administra organizaciones.
En el siguiente diagrama, se muestra un ejemplo de la jerarquía de recursos de Google Cloud en su forma completa. En este ejemplo, la estructura de carpetas define la aplicación y cada proyecto define un entorno.
Etiquetado
Las etiquetas son pares clave-valor que puedes asignar a tus recursos en la nube. (ServiceNow, AWS y Azure se refieren a las etiquetas como etiquetas de instancia).
ServiceNow usa las etiquetas que asignas a tus elementos de Google Cloud para identificar tus recursos y, de forma opcional, asignarlos a servicios. Elegir un buen esquema de etiquetado ayuda a ServiceNow a supervisar tu infraestructura para obtener informes precisos y el cumplimiento de ITOM/ITSM.
Te recomendamos que uses etiquetas para cualquier recurso que requiera una identificación única que sea más específica de lo que permite tu estructura de carpeta y proyecto. Por ejemplo, es posible que desees usar etiquetas en los siguientes casos:
- Si hay requisitos de cumplimiento estrictos para tu aplicación, puedes etiquetar todos los recursos de la aplicación a fin de que tu organización pueda identificar con facilidad toda la infraestructura que está dentro del alcance.
- En un entorno de múltiples nubes, puedes usar etiquetas para identificar el proveedor de servicios en la nube y la región de todos los recursos.
- Si necesitas una visibilidad más detallada que la que proporcionan los informes de Facturación de Google Cloud o la exportación de la Facturación de Cloud a BigQuery de forma predeterminada, los datos se pueden filtrar por etiquetas.
Google asigna etiquetas de forma automática a los recursos administrados por Google que se ejecutan en tu VPC. Las etiquetas asignadas por Google tienen el prefijo goog-. Los servidores de MID no deberían intentar realizar una inspección profunda en estos elementos. Para obtener más información sobre las etiquetas de los recursos administrados por Google, consulta Asignación basada en etiquetas de instancia y Etiqueta recursos de forma automática según las notificaciones en tiempo real de Cloud Asset Inventory..
En la siguiente tabla, se enumeran las etiquetas que los servicios de Google Cloud asignan a los recursos que administran esos servicios.
| Servicio de Google Cloud | Etiquetas o prefijo de etiqueta |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Para respaldar la administración de recursos de manera eficaz, el proceso de implementación de la organización debe crear estructuras de carpetas y proyectos, y asignar etiquetas de recursos de manera coherente en toda la organización. Las incoherencias en la infraestructura y el etiquetado pueden dificultar el mantenimiento de una CMDB correcta sin procesos manuales que probablemente no sean compatibles y que presenten desafíos de escalamiento a largo plazo.
En la siguiente lista, se sugieren prácticas recomendadas para hacer que el proceso de implementación sea coherente y repetible:
- Usa la infraestructura como código (IaC) o los sistemas de aprovisionamiento automatizados, como Terraform, ServiceNow ITOM o Aprovisionamiento y administración de Cloud con Google Cloud Deployment Manager.
- Aplica un buen proceso de administración para tus etiquetas. Para obtener una descripción general de la administración del etiquetado, consulta Administración de etiquetas de instancia en la documentación de ServiceNow.
¿Qué sigue?
- Si deseas obtener prácticas recomendadas adicionales a fin de estructurar tus recursos para la Facturación de Cloud, consulta la Guía de administración de accesos y organización de recursos de Facturación de Cloud y la Guía de configuración de estadísticas de Cloud para Google Cloud.
- Si deseas conocer las prácticas recomendadas para estructurar los permisos de IAM de tu organización, consulta Prácticas recomendadas para planificar cuentas y organizaciones y Aprovisionamiento y administración de Cloud.
- Si deseas conocer las prácticas recomendadas para estructurar las políticas de firewall de VPC en toda la organización, consulta Políticas de firewall jerárquicas.
- Aprende a usar etiquetas para admitir el descubrimiento basado en etiquetas de instancia de ServiceNow.
- Obtén más información sobre el Recopilador de clientes del agente de ServiceNow, un mecanismo de envío que se ejecuta en tu proyecto de Google Cloud y que envía datos de salida a la instancia de ServiceNow a través del servidor MID, y almacena eventos y métricas en la base de datos relevante.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.