En este documento, se analizan los patrones de arquitectura para encontrar y recopilar información sobre los recursos en Google Cloud, en otras plataformas en la nube y en las instalaciones locales con el descubrimiento de servicios en la nube de ServiceNow. El documento está dirigido a los equipos de arquitectura o de operaciones en la nube que conocen la administración de operaciones de TI (ITOM), la biblioteca de infraestructura de tecnología de la información (ITIL), Google Cloud servicios 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 combinaGoogle Cloud, otras plataformas en la nube y la infraestructura local. Por lo general, este tipo de implementación híbrida es la primera iteración en una estrategia de migración a la nube. Los departamentos de TI de estas empresas deben descubrir y hacer un seguimiento de todos los recursos de su ecosistema técnico, que pueden llegar a ser millones. Los departamentos de TI deben crear un sistema de administración de la configuración que vincule estos activos con los servicios técnicos que proporcionan. Este sistema también debe supervisar los recursos y servicios de una manera que respalde 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 los recursos en Google Cloud, en otras plataformas de nube y en las instalaciones. ServiceNow ofrece una amplia variedad de herramientas para automatizar los flujos de trabajo de TI de administración de recursos en múltiples 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 de ServiceNow en estos patrones de arquitectura incluyen los siguientes:
- Una instancia de ServiceNow que contiene una base de datos de administración de configuración (CMDB) de elementos de configuración (CI). Cada IC representa los componentes de tu entorno operativo que participan 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, 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 de ServiceNow.
Patrones de arquitectura para la integración de Google Cloud
En este documento, se analizan los siguientes patrones de arquitectura para integrarGoogle Cloud en ServiceNow:
Estos patrones de arquitectura de ejemplo están diseñados para una implementación híbrida que incluye parte de la infraestructura en Google Cloud y parte en la nube de ServiceNow. Demuestran cómo opera ServiceNow 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 llamando a las APIs de Cloud de Google. Para obtener más información sobre a qué APIs se llama, consulta APIs de Google Cloud Platform usadas por las aplicaciones de ITOM.
En cada uno de los siguientes patrones, los componentes de la arquitectura funcionan juntos en el proceso de descubrimiento de inventario de recursos 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 descubrimientoGoogle 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 del centro de datos, incluidos los tipos de hardware
- Redes, subredes y puertas de enlace de Cloud
- Imágenes
- Balanceadores de cargas de Cloud y zonas de disponibilidad
- Bases de datos y clústeres de bases de datos en la nube
- Contenedores (GKE)
- Asignación de servicios basada en 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 Google Cloud de este patrón consta de lo siguiente:
- Un Google Cloud proyecto (proyecto de servicio A en el diagrama), que consta de dos Google Cloud balanceadores de cargas, una o más instancias de VM, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor MID se ejecuta en su propia VM.
- Un segundo proyecto Google Cloud (proyecto de servicio B en el diagrama), que consiste en servidores MID que se ejecutan en sus propias VMs.
- Un tercer proyecto Google Cloud (proyecto host C en el diagrama), que consta de la interconexión del 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 consta de la instancia de ServiceNow, que captura los metadatos de los servidores de MID y los almacena en la CMDB.
Google Cloud Patrón de detección sin agente basado en IP
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 deGoogle Cloudpara acceder a las VMs y recopilar detalles adicionales. Este patrón requiere una mayor 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:
- Administración y seguridad 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 enGoogle Cloud, mientras que la instancia de ServiceNow se aloja en la plataforma de nube de ServiceNow. Los servidores MID se conectan a la instancia de ServiceNow a través de la cola del canal de comunicación externo (ECC) del servidor MID (no se muestra). Esta arquitectura se muestra en el siguiente diagrama.
La parte Google Cloud de este patrón consta de lo siguiente:
- Proyecto de servicio A, que consta de dos Google Cloud balanceadores de cargas, una o más VMs, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- El proyecto host C, que consta de la interconexión de socio.
- Servicios administrados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage
- Descubrimiento de Kubernetes de ServiceNow 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 cualquierGoogle Cloud VM que requiera el descubrimiento de direcciones IP sin servidor
- Rutas de red configuradas desde los servidores de MID hasta cualquier VM deGoogle Cloud que requiera el descubrimiento de direcciones IP sin servidores.
La parte de ServiceNow consta de la instancia de ServiceNow, que captura los metadatos de los servidores de MID y los almacena en la CMDB.
Google Cloud descubrimiento con el patrón Agent Client Collector
Este patrón de arquitectura incluye lo siguiente:
- Es el descubrimiento inicial de la nube.
- Uno o más servidores de 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 MID y retransmiten la siguiente información adicional a ServiceNow:
- Descubrimiento basado en la transmisión casi en tiempo real
- Medición de software
- Vista de CI en vivo
- Automatización de flujos de trabajo en servidores
En el siguiente diagrama, se ilustra esta arquitectura.
La parte Google Cloud de este patrón consta de lo siguiente:
- Proyecto de servicio A, que consta de dos Google Cloud balanceadores de cargas, una o más instancias de VM, una instancia de GKE y uno o más servidores MID de ServiceNow. Cada servidor MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- El proyecto host C, que consta de la interconexión de socio.
- Descubrimiento de Kubernetes de ServiceNow 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 deGoogle 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 MID y los almacena en la CMDB
- Agentes de descubrimiento de ServiceNow que se instalan en las VMs deGoogle Cloud administradas por el cliente.
Flujo de trabajo de detección de recursos de Cloud
En las siguientes secciones, se analiza el flujo de trabajo para el descubrimiento de activos. Google Cloud Este flujo de trabajo se aplica a los tres patrones de arquitectura que se describen en este documento.
Instala y configura los 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 recopilador de clientes del agente.
- Asigna recursos para las computadoras que alojan los servidores MID.
- Configura reglas de firewall para permitir conexiones en el puerto 443 entre tu instancia de VM y las computadoras que alojan los servidores 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 MID de ServiceNow consultan la base de datos de Cloud Asset Inventory para obtener información sobre todos los recursos del entorno de Google Cloud .
- Los servidores MID almacenan la información de los activos de Cloud 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 agente, la información de la VM no incluye la versión actual del parche del SO. Para este nivel de detalle, los servidores MID realizan un descubrimiento profundo de la siguiente manera:
- 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 obtener información sobre el control de versiones de los parches y otros datos.
- 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 redes y Configuración del servidor MID.
- Después de recopilar los datos de detección de activos, los servidores MID los almacenan en la CMDB de la siguiente manera:
- Los servidores de MID crean elementos de configuración en la CMDB para representar la capacidad operativa que proporciona cada activo.
- Los servidores de MID descubren automáticamente las etiquetas deGoogle Cloud y las almacenan en la CMDB. Estas etiquetas se asignan automáticamente a las IC y son útiles para crear mapas de servicios.
El proceso del flujo de trabajo debe repetirse periódicamente según sea necesario. Según la escala y la configuración de tu implementación, puedes elegir el descubrimiento basado en eventos o en la programación. Para obtener más información, consulta "Administración del ciclo de vida de la CI" en Orientación para el diseño de la CMDB.
Consideraciones del diseño
En las siguientes secciones, se proporciona orientación sobre el 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 MID enGoogle Cloud. De esa manera, las instancias están cerca de los recursos de la nube en los que realizan el descubrimiento detallado.
Los patrones de arquitectura de este documento suponen que tu CMDB almacena datos de detección para todos tus recursos de nube y todos los recursos locales, no solo tus activos de Google Cloud . La CMDB puede ubicarse en la nube de ServiceNow, en Google Cloudo de forma local. La decisión final sobre dónde ubicar la CMDB en tu entorno depende de tus requisitos específicos.
Decidir usar agentes de MID Server
Otra consideración de diseño es si se deben usar cuentas de servicio y agentes 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, lo que debes tener en cuenta en tu diseño. El enfoque que debes usar depende de los datos que necesitas capturar y de cómo los usarás. El costo operativo de la captura de datos podría superar el valor que proporcionan los datos.
Compatibilidad multirregión para servidores MID
Si tu empresa requiere compatibilidad con varias regiones de la infraestructura del servidor MID, debes planificar la implementación de cada servidor MID en al menos dos zonas de disponibilidad y replicarlo en otra región.
Implicaciones de costos
Cuando elijas dónde implementar los componentes de ServiceNow para laGoogle Cloud detección de recursos, 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 para tu caso de uso y determinar la mejor opción para ubicar tus componentes de ServiceNow. Por lo general, los servidores MID que realizan un descubrimiento detallado generan costos de salida más bajos si se ejecutan enGoogle 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 para determinar el mejor valor para tu empresa.
Por ejemplo, debes tener en cuenta la cantidad de servidores MID que implementas en las instancias deGoogle Cloud Compute Engine. Implementar más servidores MID acelera el proceso de descubrimiento de activos. Sin embargo, esto 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 Cómo instalar varios servidores MID en un solo sistema.
Consideraciones sobre la capacidad de asistencia 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 existen controles de seguridad de red extensos entre Google Cloud y el entorno en el que se implementan los servidores MID, estos controles pueden generar problemas de asistencia operativa. Para evitar estos problemas, te recomendamos que alojes los servidores MID en Google Cloudo lo más cerca posible de la infraestructura de Google Cloud contra la que se realizará una consulta de detección profunda.
Protege los servidores de MID
Recomendamos las siguientes prácticas de seguridad para tus instancias del MID Server:
- Asegúrate de que los servidores MID estén aislados para garantizar que solo los administradores de confianza puedan conectarse a ellos.
- Asegúrate de que los servidores 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:
- 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.
- La autenticación de ServiceNow requiere que se copie el contenido de una clave de cuenta de servicio en la interfaz de usuario de ServiceNow.
Las claves de cuenta de servicio son un riesgo de seguridad si no se administran de forma adecuada. Eres responsable de la seguridad de la clave privada y de otras operaciones que se describen en
Prácticas recomendadas para administrar claves de cuentas de servicio.
Si no se te permite crear una clave de cuenta de servicio, es posible que la creación de claves de cuentas de servicio esté inhabilitada para tu organización. Para obtener más información, consulta Administra los recursos de la organización con seguridad de forma predeterminada.
Si adquiriste la clave de la cuenta de servicio de una fuente externa, debes validarla antes de usarla. Para obtener más información, consulta Requisitos de seguridad para las credenciales de fuentes externas.
Estructura de carpetas y proyectos
Las carpetas y los proyectos son nodos en la jerarquía de recursos 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. Estructurar tus recursos de esta manera también permite que ServiceNow asigne tus activos a los servicios técnicos que proporcionan.
Ten en cuenta los cambios que realices en la estructura de carpetas y proyectos para admitir el descubrimiento de ServiceNow. La función principal de la estructura de carpetas y proyectos es admitir el acceso a la facturación y a IAM. Por lo tanto, cualquier cambio que realices para admitir ServiceNow debe admitir y alinearse con laGoogle Cloud estructura de facturación de tu organización. Si deseas conocer las prácticas recomendadas para estructurar la jerarquía de tuGoogle Cloud organización, carpetas y proyectos, consulta Jerarquía de recursos y Crea y administra organizaciones.
En el siguiente diagrama, se muestra un ejemplo de jerarquía de recursos 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 de Cloud. (ServiceNow, AWS y Azure se refieren a las etiquetas como etiquetas de instancia).
ServiceNow usa las etiquetas que asignas a tus activos de Google Cloud paraidentificarlos y, de manera opcional, asignarlos a servicios. Elegir un buen esquema de etiquetado ayuda a ServiceNow a supervisar tu infraestructura para obtener informes precisos y cumplir con ITOM/ITSM.
Te recomendamos que uses etiquetas para cualquier recurso que requiera una identificación única más específica de lo que permiten la estructura de tu carpeta y proyecto. Por ejemplo, puedes usar etiquetas en los siguientes casos:
- Si tu aplicación tiene requisitos de cumplimiento estrictos, puedes etiquetar todos los recursos de la aplicación para que tu organización pueda identificar fácilmente 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 automáticamente etiquetas a los recursos administrados por Google que se ejecutan en tu VPC. Las etiquetas asignadas por Google tienen el prefijo goog-. Tus servidores MID no deben intentar realizar una inspección profunda de estos recursos. Para obtener más información sobre las etiquetas de los recursos administrados por Google, consulta Asignación basada en etiquetas 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.
| Servicio deGoogle Cloud | Etiquetas o prefijo de etiqueta |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
goog-gce-
|
| Dataproc |
goog-dataproc-
|
| Vertex AI Workbench |
goog-caip-notebook and goog-caip-notebook-volume
|
Para respaldar la administración de recursos de manera eficaz, el proceso de implementación de tu organización debe crear estructuras de proyectos y carpetas, y asignar etiquetas de activos 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 que tu 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.
- Tener 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?
- Obtén más información sobre el conector de integración para ServiceNow.
- Si deseas conocer otras prácticas recomendadas para estructurar tus recursos para la Facturación de Cloud, consulta la Guía de administración de acceso y organización de recursos de Facturación de Cloud y la Guía de configuración de Cloud Insights 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 tus políticas de firewall de VPC en toda tu 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 pertinente.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.