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 de forma local mediante el descubrimiento de 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. Por lo general, una implementación híbrida es la iteración inicial 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 configuraciones que vincule estos recursos con los servicios técnicos que proporcionan. Este sistema también debe supervisar los recursos y los 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).
En el caso de 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 en la nube y de forma local. ServiceNow ofrece una amplia variedad de herramientas para automatizar los 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 de ServiceNow en estos patrones de arquitectura incluyen los siguientes:
- Una instancia de ServiceNow que contiene una base de datos de administración de configuraciones (CMDB) de elementos de configuración (CI). Cada CI representa 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.
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 parte de la infraestructura en Google Cloud y parte en la nube de ServiceNow. Demuestran cómo ServiceNow opera 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 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 de Cloud
- Contenedores (GKE)
- Asignación de servicios según 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 lo siguiente:
- Un proyecto de Google Cloud (proyecto de servicio A en el diagrama), que consiste en 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 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 socios.
- 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 sin agente basado en IP 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 una carga operativa mayor para administrar el servidor MID que con 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 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 de Google Cloud de este patrón consta de lo siguiente:
- 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 MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- Proyecto host C, que consiste en la interconexión de socios
- 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 de 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 el descubrimiento 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 el patrón de Collector de clientes de agentes
Este patrón de arquitectura incluye lo siguiente:
- 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 notificaciones 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 de Google Cloud de este patrón consta de lo siguiente:
- Proyecto de 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 MID se ejecuta en su propia VM.
- Proyecto de servicio B, que consiste en servidores MID que se ejecutan en sus propias VMs.
- Proyecto host C, que consiste en la interconexión de socios
- 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 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 detección de recursos de nube
En las siguientes secciones, se analiza el flujo de trabajo del descubrimiento de activos de Google Cloud. Este flujo de trabajo se aplica a los tres patrones de arquitectura describidos 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 agente de recopilación de clientes.
- Asignar recursos para las computadoras que alojan los servidores MID
- Configura reglas de firewall para permitir conexiones en el puerto 443 entre la 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 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 activos en 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 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 MID acceden a cada VM y consultan el SO para obtener la versión del parche 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 redes y Configuración del servidor de MID.
- Después de recopilar los datos de descubrimiento de activos, los servidores de MID los almacenan en la CMDB de la siguiente manera:
- Los servidores de MID crean CI en la CMDB para representar la capacidad operativa que proporciona cada activo.
- Los servidores de MID descubren automáticamente las etiquetas de Google Cloud y las almacenan en la CMDB. Estas etiquetas se asignan a las CI automáticamente y son útiles para crear mapas de servicio.
El proceso de 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 “Cómo administrar el ciclo de vida de la 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 MID en Google Cloud. De esta manera, las instancias están cerca de los recursos de la nube en los que realizan el 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 para todos los recursos locales, no solo para tus activos de Google Cloud. La CMDB se puede ubicar 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.
Cómo decidir si usar agentes de servidor de MID
Otra consideración de diseño es si usar agentes de servidor MID y cuentas de servicio. 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 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 necesitas 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 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 el descubrimiento de activos de Google Cloud, debes tener en cuenta el costo de salida y el costo de procesamiento.
Costo de salida
Los cargos de salida se generan cada vez que los datos salen de Google Cloud. Por este motivo, debes analizar el costo de salida de tu caso de uso para determinar la mejor opción para ubicar tus componentes de ServiceNow. Por lo general, los servidores MID que realizan un descubrimiento profundo incurren en 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 incurren en costos de procesamiento que debes analizar para determinar el mejor valor para tu empresa.
Por ejemplo, debes considerar la cantidad de servidores MID que implementas en las instancias de Google Cloud Compute Engine. La implementación de más servidores MID acelera el proceso de descubrimiento de recursos. 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 Cómo instalar varios servidores MID en un solo sistema.
Consideraciones de 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 la infraestructura de duplicación de paquetes. Si hay controles de seguridad de red extensos 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 consultará un descubrimiento profundo.
Protege los servidores de MID
Recomendamos las siguientes prácticas de seguridad para tus instancias de servidor de MID:
- 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 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:
- 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 copiar 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.
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 carpetas y proyectos debe reflejar la estructura de tu aplicación y de los entornos en los que se implementa. Estructurar 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 de 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 presenta un ejemplo de 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 recursos de Google Cloud para identificarlos y, de manera opcional, asignarlos a servicios. Elegir un buen esquema de etiquetado ayuda a ServiceNow a supervisar tu infraestructura para generar informes precisos y cumplir con ITOM/ITSM.
Te recomendamos que uses etiquetas para los recursos que requieran una identificación única más específica que la que permiten la carpeta y la estructura del proyecto. Por ejemplo, te recomendamos que uses etiquetas en los siguientes casos:
- Si hay requisitos de cumplimiento estrictos para tu aplicación, 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 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 automáticamente a los recursos administrados por Google que se ejecutan en tu
VPC. Las etiquetas asignadas por Google tienen el prefijo goog-. Tus servidores de 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 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.
| Servicio de Google Cloud | Etiquetas o prefijo de etiquetas |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
|
| Dataproc |
|
| Vertex AI Workbench |
|
Para admitir 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 recursos de manera coherente en toda la organización. Las inconsistencias 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.
- Debes tener implementado 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 en la documentación de ServiceNow.
¿Qué sigue?
- Si deseas obtener más prácticas recomendadas para estructurar tus recursos para la Facturación de Cloud, consulta la Guía de administración de accesos y organización de recursos de la Facturación de Cloud y la Guía de configuración de Cloud Insights para Google Cloud.
- Si deseas obtener 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 gobernanza de Cloud.
- Si deseas obtener prácticas recomendadas para estructurar las políticas de firewall de VPC en 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 relevante.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.