En este documento se describen patrones de arquitectura para encontrar y recopilar información sobre los recursos de Google Cloud, otras plataformas en la nube y entornos on‐premise mediante el descubrimiento de nubes de ServiceNow. Este documento está dirigido a equipos de arquitectura o de operaciones en la nube que estén familiarizados con la gestión de operaciones de TI (ITOM), la biblioteca de infraestructura de tecnologías de la información (ITIL), Google Cloud servicios como Compute Engine, Google Kubernetes Engine (GKE) e Inventario de Recursos de Cloud, y ServiceNow Cloud Discovery.
Información general
Muchas grandes empresas utilizan una implementación de infraestructura de TI híbrida que combinaGoogle Cloud, otras plataformas en la nube e infraestructura on-premise. Este tipo de despliegue híbrido suele ser la primera iteración de 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 ascender a millones. Los departamentos de TI deben crear un sistema de gestión de la configuración que vincule estos recursos con los servicios técnicos que proporcionan. Este sistema también debe monitorizar los recursos y servicios de forma que se ajusten a las prácticas recomendadas de gestión de operaciones de TI (ITOM) y gestión de servicios de TI (ITSM).
En el caso de los clientes de Google Cloud , una arquitectura habitual usa el descubrimiento de recursos en la nube de ServiceNow para buscar y recoger información sobre los recursos de Google Cloud, otras plataformas en la nube y entornos locales. ServiceNow ofrece una amplia gama de herramientas para automatizar los flujos de trabajo de TI de gestión de recursos en varios proveedores de servicios en la nube. Herramientas como Cloud Operations Workspace permiten a los departamentos de TI crear paneles de recursos multicloud y gestionar configuraciones complejas a través de una interfaz unificada (a veces denominada panel único). En este documento se presenta un conjunto de patrones de arquitectura para este escenario, 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 de estos patrones de arquitectura incluyen los siguientes:
- Una instancia de ServiceNow que contiene una base de datos de gestión de configuración (CMDB) de elementos de configuración (CIs). Cada CI representa los componentes de tu entorno operativo que participan en la prestación de servicios digitales. Un CI tiene varios atributos que contienen metadatos específicos sobre el componente y sus relaciones con otros CIs.
- Uno o varios servidores MID (Management, Instrumentation and Discovery) de ServiceNow que se ejecutan en tu Google Cloud proyecto. Los servidores MID recogen los metadatos de los IAs y los almacenan en la CMDB.
Estos patrones de arquitectura definen algunas prácticas habituales para importar datos de Cloud Asset Inventory de Google a Google Cloud Platform asset inventory discovery de ServiceNow.
Patrones de arquitectura para la integración de Google Cloud
En este documento se describen 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. Muestran cómo funciona ServiceNow Google Cloud entre la infraestructura gestionada por Google y la infraestructura gestionada por el cliente. Los servidores MID de ServiceNow consultan toda la infraestructura gestionada por Google llamando a las APIs de Google Cloud. Para obtener más información sobre las APIs a las que se llama, consulta APIs de Google Cloud Platform usadas por aplicaciones de ITOM.
En cada uno de los siguientes patrones, los componentes de la arquitectura trabajan conjuntamente en el proceso de detección del inventario de recursos de Google Cloud Platform para recoger la información del inventario de recursos en la nube que necesitan la aplicación Discovery de ServiceNow y las herramientas relacionadas.
Google Cloud patrón de descubrimiento
El patrón de arquitectura de descubrimiento en la nube de ServiceNow básico usa servidores MID de ServiceNow para llamar a Google Cloud Asset Inventory y a otras APIs de Google Cloud con el fin de recoger datos sobre recursos como los siguientes:
- Instancias de VM
- Etiquetas (claves/valores)
- Volúmenes de almacenamiento y asignación de almacenamiento
- Recursos del centro de datos, incluidos los tipos de hardware
- Redes, subredes y pasarelas de Cloud
- Imágenes
- Balanceadores de carga 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 MID no necesitan credenciales porque no inician sesión en las máquinas virtuales para recoger datos. Esto limita la capacidad del proceso de descubrimiento para recopilar información adicional. Sin embargo, impone menos costes operativos, ya que elimina la necesidad de gestionar y rotar las credenciales del MID Server.
En el siguiente diagrama se ilustra este patrón de 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 carga, una o varias instancias de VM, una instancia de GKE y uno o varios servidores MID de ServiceNow. Cada MID Server se ejecuta en su propia máquina virtual.
- Un segundo proyecto (proyecto de servicio B en el diagrama), Google Cloud que consta de servidores MID que se ejecutan en sus propias máquinas virtuales.
- Un tercer proyecto Google Cloud (Proyecto del host C en el diagrama), que consta de la interconexión del partner.
- Servicios gestionados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage.
- Rutas de red configuradas desde los servidores MID a las APIs de Google Cloud.
La parte de ServiceNow consta de la instancia de ServiceNow, que captura los metadatos de los MID Servers y los almacena en la CMDB.
Google Cloud Patrón de descubrimiento basado en IP sin agente
Este patrón de arquitectura añade la detección basada en IP al patrón de detección en la nube básico mediante un trabajo por lotes y unaGoogle Cloud cuenta de servicio para iniciar sesión en las máquinas virtuales y obtener más detalles. Este patrón requiere una mayor carga operativa para gestionar el MID Server que el patrón básico, ya que requiere que gestiones y rotes las credenciales del MID Server. Sin embargo, amplía el proceso de detección más allá de los datos proporcionados por Inventario de recursos de Cloud para incluir datos adicionales, como los siguientes:
- Gestión y seguridad de las credenciales del SO
- Búsqueda mejorada, como la búsqueda basada en archivos y la búsqueda de licencias
- Detalles del SO
- Procesos en ejecución
- Conexiones TCP
- Software instalado
En este patrón de arquitectura, uno o varios servidores MID de ServiceNow se encuentran enGoogle Cloud, mientras que la instancia de ServiceNow se aloja 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 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:
- El proyecto de servicio A, que consta de dos balanceadores de carga, una o varias VMs, una instancia de GKE y uno o varios servidores MID de ServiceNow. Google Cloud Cada MID Server se ejecuta en su propia máquina virtual.
- Proyecto de servicio B, que consta de servidores MID que se ejecutan en sus propias VMs.
- Proyecto de host C, que consta de la interconexión de partner.
- Servicios gestionados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage.
- ServiceNow Kubernetes Discovery se ha desplegado en la infraestructura de GKE.
- Rutas de red configuradas desde los servidores MID a las APIs de Google Cloud.
- Cuentas de servicio que permiten que los servidores MID inicien sesión en cualquier máquina virtual que requiera la detección de direcciones IP sin servidor.Google Cloud
- Rutas de red configuradas desde los servidores MID a cualquier VM que requiera la detección de direcciones IP sin servidor.Google Cloud
La parte de ServiceNow consta de la instancia de ServiceNow, que captura los metadatos de los MID Servers y los almacena en la CMDB.
Google Cloud descubrimiento con el patrón de recopilador de clientes de agentes
Este patrón de arquitectura incluye lo siguiente:
- El descubrimiento inicial de la nube.
- Uno o varios servidores MID.
Un agente adicional de ServiceNow, el Agent Client Collector, que debes instalar en tus máquinas virtuales. Estos agentes se conectan directamente a los servidores MID y reenvían la siguiente información adicional a ServiceNow:
- Descubrimiento casi en tiempo real basado en push
- Medición de software
- Vista de CI en directo
- Automatización de flujos de trabajo en servidores
En el siguiente diagrama se ilustra este patrón de arquitectura.
La parte Google Cloud de este patrón consta de lo siguiente:
- El proyecto de servicio A, que consta de dos balanceadores de carga, una o varias instancias de VM, una instancia de GKE y uno o varios servidores MID de ServiceNow. Google Cloud Cada MID Server se ejecuta en su propia máquina virtual.
- Proyecto de servicio B, que consta de servidores MID que se ejecutan en sus propias máquinas virtuales.
- Proyecto de host C, que consta de la interconexión de partner.
- ServiceNow Kubernetes Discovery se ha desplegado en la infraestructura de GKE.
- Servicios gestionados adicionales, como las APIs de Cloud, BigQuery y Cloud Storage.
- Rutas de red configuradas desde los servidores MID a las APIs de Google Cloud.
- Rutas de red configuradas desde los servidores MID a las Google Cloud máquinas virtuales que tienen instalados agentes de ServiceNow Discovery.
La parte de ServiceNow consta de lo siguiente:
- La instancia de ServiceNow, que captura los metadatos de los MID Servers y los almacena en la CMDB.
- Agentes de descubrimiento de ServiceNow instalados en máquinas virtuales gestionadas por el cliente.Google Cloud
Flujo de trabajo de descubrimiento de recursos de Cloud
En las siguientes secciones se describe el flujo de trabajo para Google Cloud descubrir recursos. Este flujo de trabajo se aplica a los tres patrones de arquitectura descritos en este documento.
Instalar y configurar componentes de ServiceNow
- Habilita las APIs de Cloud Asset Inventory.
- Instala Agent Client Collector en tus máquinas virtuales. Para obtener más información, consulta el artículo Instalación de Agent Client Collector.
- Asigna recursos a los ordenadores que alojan los servidores MID.
- Configura reglas de cortafuegos para permitir las conexiones en el puerto 443 entre tu instancia de VM y los ordenadores que alojan los servidores MID.
- Configurar la conectividad de red del MID Server.
- Instala los servidores MID.
- Configura los servidores MID para llamar a las APIs de Google Cloud pertinentes. Asegúrate de que los servidores MID tengan una ruta de red válida para llamar a las APIs de Google Cloud.
Flujo de trabajo
- Inventario de recursos de Cloud compila una base de datos de todos los tipos de recursos admitidos del Google Cloud entorno. ServiceNow usa Inventario de Recursos de Cloud como fuente para obtener información adicional con la que 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 Google Cloud .
- Los servidores MID almacenan la información de los recursos de la nube en un segmento de Cloud Storage.
- No se puede obtener toda la información necesaria de la base de datos del Inventario de Recursos de Cloud. 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 haciendo lo siguiente:
- Los servidores MID crean una tarea por lotes basada en las direcciones IP de las VMs que requieren un descubrimiento profundo.
- En el trabajo por lotes, los servidores MID inician sesión en cada VM y consultan el sistema operativo para obtener información sobre la versión del parche y otros datos.
- Si se instalan los colectores de clientes del agente, los datos que recogen se transmiten directamente a los servidores MID, en lugar de almacenarse en la base de datos de Cloud Asset Inventory. Para obtener más información, consulta los artículos Preparación de la red y Configuración del MID Server.
- Después de recoger los datos de detección de recursos, los MID Servers los almacenan en la CMDB de la siguiente manera:
- Los servidores MID crean CIs en la CMDB para representar la capacidad operativa proporcionada por cada recurso.
- Los servidores MID descubren automáticamente las etiquetas deGoogle Cloud y las almacenan en la CMDB. Estas etiquetas se asignan automáticamente a los IEs y son útiles para crear mapas de servicios.
El proceso del flujo de trabajo debe repetirse periódicamente según sea necesario. En función de la escala y la configuración de tu implementación, puedes elegir el descubrimiento basado en eventos o en una programación. Para obtener más información, consulta "Gestionar el ciclo de vida de los elementos de configuración" en la guía de diseño de CMDB.
Factores del diseño
En las siguientes secciones se ofrecen directrices de diseño para implementar cualquiera de los patrones de arquitectura que se describen en este documento.
Ubicación de la instancia de ServiceNow
En la mayoría de los casos prácticos, recomendamos implementar los servidores MID enGoogle Cloud. De esta forma, las instancias están cerca de los recursos en la nube en los que realizan la detección profunda.
Los patrones de arquitectura de este documento presuponen que tu CMDB almacena datos de detección de todos tus recursos en la nube y de todos los recursos locales, no solo de tus Google Cloud recursos. La CMDB puede estar ubicada 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 si se van a usar agentes de MID Server
Otro aspecto de diseño que debes tener en cuenta es si quieres usar agentes de MID Server y cuentas de servicio. Si tu proceso de detección necesita recopilar información más allá de los metadatos que proporciona Cloud Asset Inventory, debes usar una infraestructura de MID Server con cuentas de servicio o, como alternativa, un MID Server con Agent Client Collector. Cualquiera de los dos enfoques puede afectar al coste de asistencia operativa, que debes tener en cuenta en tu diseño. El enfoque que debes usar depende de los datos que necesites recoger y de cómo los vayas a usar. El coste operativo de recoger los datos puede ser superior al valor que proporcionan.
Compatibilidad multirregional con servidores MID
Si tu empresa requiere compatibilidad con varias regiones de la infraestructura del MID Server, debes planificar la implementación de cada MID Server en al menos dos zonas de disponibilidad y replicarlo en otra región.
Implicaciones económicas
Cuando elija dónde implementar los componentes de ServiceNow para la detección de recursos, debe tener en cuenta el coste de salida y el coste de computación.Google Cloud
Coste de salida
Los cargos de salida se aplican cada vez que los datos salen de Google Cloud. Por este motivo, debes analizar el coste de salida de tu caso de uso para determinar la mejor opción para ubicar tus componentes de ServiceNow. Por lo general, los MID Servers que realizan un descubrimiento profundo incurren en costes de salida más bajos si se ejecutan enGoogle Cloud que si se ejecutan en otra nube o en un entorno local.
Coste de computación
Los componentes de ServiceNow que se ejecutan en Google Cloud generan costes de computación que debes analizar para determinar el mejor valor para tu empresa.
Por ejemplo, debes tener en cuenta el número de servidores MID que implementes en instancias deGoogle Cloud Compute Engine. Si se implementan más MID Servers, el proceso de descubrimiento de recursos será más rápido. Sin embargo, esto aumenta el coste de computación, ya que cada MID Server se implementa en su propia instancia de VM. Para obtener más información sobre si debes implementar uno o varios servidores MID, consulta el artículo Instalar varios servidores MID en un mismo sistema.
Consideraciones sobre la capacidad de asistencia operativa
Es probable que tu implementación incluya controles de seguridad de red, como cortafuegos, sistemas de protección contra intrusiones, sistemas de detección de intrusiones e infraestructura de duplicación de paquetes. Si hay controles de seguridad de red exhaustivos entre Google Cloud y el entorno en el que se implementan los MID Servers, estos controles pueden crear problemas de asistencia operativa. Para evitar estos problemas, le recomendamos que aloje los servidores MID en Google Cloudo lo más cerca posible de la infraestructura de Google Cloud que consultará una detección profunda.
Proteger servidores MID
Te recomendamos que sigas estas prácticas de seguridad para tus instancias de MID Server:
- Asegúrate de que los servidores MID estén aislados para 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 los roles de IAM se apliquen para limitar la capacidad de hacer cambios solo a aquellos que se aprueben mediante procesos de ITIL o a través de una canalización de CI/CD.
Proteger las cuentas de servicio
Te recomendamos que sigas estas prácticas de seguridad para gestionar cuentas de servicio:
- Asegúrate de que los MID Servers usen una cuenta de servicio que solo tenga los roles y permisos de gestión de identidades y accesos que sean absolutamente necesarios para la detección de activos. Para obtener más información, consulta las prácticas recomendadas para trabajar con cuentas de servicio.
- Para autenticarte en ServiceNow, debes copiar el contenido de una clave de cuenta de servicio en la interfaz de usuario de ServiceNow.
Las claves de las cuentas de servicio suponen un riesgo para la seguridad si no se gestionan adecuadamente. Eres responsable de la seguridad de la clave privada y de otras operaciones descritas en las
prácticas recomendadas para gestionar las claves de cuentas de servicio.
Si no puedes crear una clave de cuenta de servicio, es posible que la creación de claves de cuenta de servicio esté inhabilitada en tu organización. Para obtener más información, consulta el artículo sobre
gestionar recursos de organización seguros de forma predeterminada.
Si has obtenido la clave de cuenta de servicio de una fuente externa, debes validarla antes de usarla. Para obtener más información, consulta Requisitos de seguridad de las credenciales de fuentes externas.
Estructura de carpetas y proyectos
Las carpetas y los proyectos son nodos de la Google Cloud jerarquía de recursos. Para facilitar la detección de recursos, la estructura de carpetas y proyectos debe reflejar la estructura de la aplicación y de los entornos en los que se implementa. Si estructura sus recursos de esta forma, ServiceNow también podrá asignar sus activos a los servicios técnicos que proporciona.
Ten en cuenta los cambios que hagas en la estructura de carpetas y proyectos para admitir el descubrimiento de ServiceNow. El objetivo principal de la estructura de carpetas y proyectos es admitir la facturación y el acceso de gestión de identidades y accesos. Por lo tanto, cualquier cambio que hagas para admitir ServiceNow debe ajustarse a laGoogle Cloud estructura de facturación de tu organización. Para consultar las prácticas recomendadas para estructurar la jerarquía de tu organización, carpetas y proyectos, consulta los artículos Jerarquía de recursos y Crear y gestionar organizaciones.Google Cloud
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 en la nube. (ServiceNow, AWS y Azure se refieren a las etiquetas como etiquetas).
ServiceNow usa las etiquetas que asignas a tus recursos para Google Cloud identificarlos y, opcionalmente, asignarlos a servicios. Elegir un buen esquema de etiquetado ayuda a ServiceNow a monitorizar tu infraestructura para generar informes precisos y cumplir los requisitos de ITOM e ITSM.
Te recomendamos que uses etiquetas para los recursos que requieran una identificación única más específica que la que permiten la estructura de carpetas y proyectos. Por ejemplo, puede 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é incluida.
- En un entorno multinube, puede usar etiquetas para identificar el proveedor de la nube y la región de todos los recursos.
- Si necesitas una visibilidad más detallada que la que ofrecen de forma predeterminada los informes de facturación de Google Cloud o la exportación de la facturación a BigQuery, puedes filtrar los datos por etiquetas.
Google asigna automáticamente etiquetas a los recursos gestionados 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 exhaustiva de estos recursos. Para obtener más información sobre las etiquetas de los recursos gestionados por Google, consulta los artículos Asignación basada en etiquetas y Etiquetar recursos automáticamente en función de las notificaciones en tiempo real de Cloud Asset Inventory.
En la siguiente tabla se indican las etiquetas que los servicios asignan a los recursos que gestionan. Google Cloud
| ServicioGoogle Cloud | Etiquetas o prefijos de etiquetas |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
goog-gce-
|
| Dataproc |
goog-dataproc-
|
| Vertex AI Workbench |
goog-caip-notebook and goog-caip-notebook-volume
|
Para gestionar los recursos de forma eficaz, el proceso de implementación de tu organización debe crear estructuras de proyectos y carpetas, así como asignar etiquetas de activos de forma 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 se puedan mantener y que presenten problemas de escalabilidad a largo plazo.
En la siguiente lista se sugieren prácticas recomendadas para que el proceso de implementación sea coherente y repetible:
- Usa infraestructura como código (IaC) o sistemas de aprovisionamiento automatizados, como Terraform, ServiceNow ITOM o aprovisionamiento y gobernanza en la nube con Google Cloud Deployment Manager.
- Tener un buen proceso de gobernanza para las etiquetas. Para obtener una descripción general de la gestión de etiquetas, consulta Gestión de etiquetas en la documentación de ServiceNow.
Siguientes pasos
- Consulta información sobre el conector de integración de ServiceNow.
- Para obtener más información sobre las prácticas recomendadas para estructurar tus recursos de Facturación de Cloud, consulta la guía de organización de recursos y gestión de acceso de Facturación de Cloud y la guía de configuración de Cloud Insights para Google Cloud.
- Para consultar las prácticas recomendadas para estructurar los permisos de gestión de identidades y accesos de tu organización, consulta Prácticas recomendadas para planificar cuentas y organizaciones y Aprovisionamiento y gobernanza en la nube.
- Para consultar las prácticas recomendadas para estructurar las políticas de cortafuegos de VPC en tu organización, consulta Políticas de cortafuegos jerárquicas.
- Consulta cómo usar etiquetas para admitir la detección basada en etiquetas de ServiceNow.
- Consulta información sobre ServiceNow Agent Client Collector, un mecanismo push que se ejecuta en tu proyecto de Google Cloud y envía datos de salida a la instancia de ServiceNow a través del MID Server, almacenando eventos y métricas en la base de datos correspondiente.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.