参考架构：使用 ServiceNow 管理资源

Last reviewed 2024-01-30 UTC

本文档介绍了如何使用 ServiceNow 云发现查找和收集 Google Cloud、其他云平台和本地中的资产相关信息的架构模式。本文档适用于熟悉 IT 运维管理 (ITOM)、信息技术基础架构库 (ITIL)、Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Asset Inventory 等 Google Cloud 服务以及 ServiceNow Cloud Discovery 的基础架构团队或云运维团队。

概览

许多大型企业都在使用将 Google Cloud、其他云平台和本地基础架构结合在一起的混合 IT 基础设施部署。此类混合部署通常是云迁移策略中的初始迭代。这些企业的 IT 部门需要发现和跟踪其技术生态系统中的所有资产，这些资产可能数以百万计。IT 部门必须构建一个配置管理系统，以将这些资产与资产提供的技术服务相关联。此系统还必须以支持 IT 运维管理 (ITOM) 和 IT 服务管理 (ITSM) 最佳实践的方式监控资产和服务。

对于 Google Cloud 客户，常见架构使用 ServiceNow 云资源发现来查找和收集有关 Google Cloud、其他云平台和本地环境的资产的信息。ServiceNow 提供了各种工具，用于跨多个云提供商自动执行资源管理 IT 工作流。借助 Cloud Operations 工作区等工具，IT 部门可以创建多云资源信息中心，并通过统一界面（有时称为单一管理平台）管理复杂配置。本文档介绍了针对此场景的一组架构模式、其概要组件概览，以及一般设计考虑事项。

此架构的 ServiceNow 组件

这些架构模式中的 ServiceNow 平台组件包括下列各项：

这些架构模式定义了将 Google Cloud Asset Inventory 数据导入 ServiceNow 的 Google Cloud Platform 资产清点发现的一些常见实践。

Google Cloud 集成的架构模式

本文档介绍了将 Google Cloud 集成到 ServiceNow 中的以下架构模式：

这些架构模式示例适用于混合部署，其中一些基础架构位于 Google Cloud 中，一些位于 ServiceNow 云中。它们演示了 ServiceNow 在 Google Cloud 中的 Google 管理的基础架构和客户管理的基础架构之间的运行方式。ServiceNow MID 服务器通过调用 Google Cloud API 来查询所有 Google 管理的基础架构。如需详细了解调用的 API，请参阅 ITOM 应用使用的 Google Cloud Platform API。

在以下每种模式中，架构组件在 Google Cloud Platform 资产清点发现过程中协同工作，以收集 ServiceNow 发现应用和相关工具所需的云资产清点信息。

Google Cloud 发现模式

基本 ServiceNow 云发现架构模式使用 ServiceNow MID 服务器调用 Google Cloud Asset Inventory 和其他 Google Cloud API 来收集有关以下资源的数据：

  • 虚拟机实例
  • 标记（键/值）
  • 存储卷和存储映射
  • 数据中心资源，包括硬件类型
  • Cloud 网络、子网和网关
  • 图片
  • Cloud 负载均衡器和可用区
  • 云数据库和数据库集群
  • 容器 (GKE)
  • 基于资源标签的服务映射

在此模式中，MID 服务器不需要凭据，因为它们不会登录虚拟机来收集数据。这限制了发现过程收集更多信息的能力。但是，由于此模式无需管理和轮替 MID 服务器凭据，因此降低了运营成本。

下图说明了此架构模式。

展示 Google Cloud 发现架构模式的图表。

此模式的 Google Cloud 部分包含以下各项：

  • 一个 Google Cloud 项目（图中的服务项目 A），由两个 Google Cloud 负载均衡器、一个或多个虚拟机实例、GKE 实例以及一个或多个 ServiceNow MID 服务器组成。每个 MID 服务器都在其各自的虚拟机中运行。
  • 第二个 Google Cloud 项目（图中的服务项目 B），由在其各自的虚拟机中运行的 MID 服务器组成。
  • 第三个 Google Cloud 项目（图中的宿主项目 C），由合作伙伴互连组成。
  • 其他托管式服务，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 从 MID 服务器到 Google Cloud API 设置的网络路由。

ServiceNow 部分由 ServiceNow 实例组成，该实例会从 MID 服务器捕获元数据并将其存储在 CMDB 中。

Google Cloud 基于 IP 的无代理发现模式

此架构模式通过使用批量作业和 Google Cloud 服务账号登录虚拟机并收集更多详细信息为基本云发现模式增加了基于 IP 的发现。与基本模式相比，此模式需要更多的运营负担来管理 MID 服务器，因为它要求您管理和轮替 MID 服务器凭据。但是，它会将发现过程扩展到 Cloud Asset Inventory 提供的数据之外，从而包含更多数据，例如：

  • 操作系统凭据管理和安全
  • 增强的发现功能，例如基于文件的发现和许可发现
  • 操作系统详细信息
  • 运行进程
  • TCP 连接
  • 已安装的软件

在此架构模式中，一个或多个 ServiceNow MID 服务器位于 Google Cloud 中，而 ServiceNow 实例托管在 ServiceNow 云平台上。MID 服务器通过 MID 服务器外部通信渠道 (ECC) 队列（未显示）连接到 ServiceNow 实例。下图展示了此架构。

展示 Google Cloud 基于 IP 的无代理发现模式的图表。

此模式的 Google Cloud 部分包含以下各项：

  • 服务项目 A，由两个 Google Cloud 负载均衡器、一个或多个虚拟机、GKE 实例以及一个或多个 ServiceNow MID 服务器组成。每个 MID 服务器都在其各自的虚拟机中运行。
  • 服务项目 B，由在其各自的虚拟机中运行的 MID 服务器组成。
  • 宿主项目 C，由合作伙伴互连组成。
  • 其他托管式服务，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 部署在 GKE 基础架构上的 ServiceNow Kubernetes 发现。
  • 从 MID 服务器到 Google Cloud API 设置的网络路由。
  • 服务账号：使 MID 服务器能够登录任何需要无服务器 IP 地址发现功能的 Google Cloud 虚拟机。
  • 从 MID 服务器到任何需要无服务器 IP 地址发现的 Google Cloud 虚拟机设置的网络路由。

ServiceNow 部分由 ServiceNow 实例组成，该实例会从 MID 服务器捕获元数据并将其存储在 CMDB 中。

使用代理客户端收集器的 Google Cloud 发现模式

此架构模式包含以下各项：

  • 初始云发现。
  • 一个或多个 MID 服务器。

  • 一个额外的 ServiceNow 代理，即代理客户端收集器，安装在虚拟机上。这些代理直接连接到 MID 服务器，并将以下更多信息中继到 ServiceNow：

    • 近乎实时的基于推送的发现
    • 软件计量
    • 实时 CI 视图
    • 工作流自动化到服务器

下图说明了此架构模式。

展示使用代理客户端收集器的 Google Cloud 发现模式的图表

此模式的 Google Cloud 部分包含以下各项：

  • 服务项目 A，由两个 Google Cloud 负载均衡器、一个或多个虚拟机实例、GKE 实例以及一个或多个 ServiceNow MID 服务器组成。每个 MID 服务器都在其各自的虚拟机中运行。
  • 服务项目 B，由在其各自的虚拟机中运行的 MID 服务器组成。
  • 宿主项目 C，由合作伙伴互连组成。
  • 部署在 GKE 基础架构上的 ServiceNow Kubernetes 发现。
  • 其他托管式服务，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 从 MID 服务器到 Google Cloud API 设置的网络路由。
  • 从 MID 服务器到安装了 ServiceNow 发现代理的 Google Cloud 虚拟机设置的网络路由。

ServiceNow 部分包含以下各项：

  • ServiceNow 实例，该实例会从 MID 服务器捕获元数据并将其存储在 CMDB 中。
  • 安装在客户管理的 Google Cloud 虚拟机上的 ServiceNow 发现代理。

Cloud 资产发现工作流

以下部分介绍了 Google Cloud 资产发现的工作流。此工作流适用于本文档中所述的所有三种架构模式。

安装和配置 ServiceNow 组件

  1. 启用 Cloud Asset Inventory API。
  2. 在虚拟机上安装代理客户端收集器。如需了解详情，请参阅代理客户端收集器安装。
  3. 为托管 MID 服务器的计算机分配资源。
  4. 配置防火墙规则以允许在虚拟机实例与托管 MID 服务器的计算机之间通过端口 443 进行连接。
  5. 配置 MID 服务器网络连接。
  6. 安装 MID 服务器。
  7. 配置 MID 服务器以调用相关 Google Cloud API。确保 MID 服务器具有有效的网络路由来调用 Google Cloud API。

工作流

  1. Cloud Asset Inventory 编译 Google Cloud 环境中所有受支持的资产类型的数据库。ServiceNow 使用 Cloud Asset Inventory 作为检索更多信息来更新 CMDB 的来源。
  2. ServiceNow MID 服务器查询 Cloud Asset Inventory 数据库，以获取有关 Google Cloud 环境中所有资产的信息。
  3. MID 服务器将云资产信息存储在 Cloud Storage 存储桶中。
  4. 并非所有必需信息都可以从 Cloud Asset Inventory 数据库获取。在无代理模式中，虚拟机信息不包含当前操作系统补丁版本。对于此详细程度，MID 服务器通过执行以下操作来执行深度发现：
    1. MID 服务器根据需要深度发现的虚拟机的 IP 地址创建批量作业。
    2. 在批量作业中，MID 服务器登录每个虚拟机，并查询操作系统以获取补丁版本控制和其他信息。
  5. 如果安装了代理客户端收集器，则它们捕获的数据会直接传输到 MID 服务器，而不是存储在 Cloud Asset Inventory 数据库中。如需了解详情，请参阅网络准备和 MID 服务器配置。
  6. 收集资产发现数据后，MID 服务器将其存储到 CMDB 中，如下所示：
    1. MID 服务器在 CMDB 中创建 CI，以表示每个资产提供的运营能力。
    2. MID 服务器自动从 Google Cloud 发现标签并将其存储在 CMDB 中。这些标签会自动映射到 CI，并且可用于创建服务映射。

您应根据需要定期重复此工作流流程。根据部署的规模和配置，您可以选择基于事件或基于时间表的发现。如需了解详情，请参阅 CMDB 设计指导中的“管理 CI 生命周期”。

设计考虑事项

以下部分提供了实现本文档中所述的任何架构模式的设计指南。

ServiceNow 实例的位置

对于大多数应用场景，我们建议在 Google Cloud 中部署 MID 服务器。这样，实例会靠近它们对其执行深度发现的云资产。

本文档中的架构模式假定 CMDB 存储所有云资源和所有本地资源的发现数据，而不仅仅是存储 Google Cloud 资产的发现数据。CMDB 可以位于 ServiceNow 云、Google Cloud 或本地环境中。最终决定 CMDB 在您的环境中的位置取决于您的具体要求。

决定使用 MID 服务器代理

另一个设计考虑事项是是否使用 MID 服务器代理和服务账号。如果发现过程需要收集 Cloud Asset Inventory 提供的元数据之外的信息，您需要将 MID 服务器基础架构与服务账号结合使用，或者将 MID 服务器与代理客户端收集器结合使用。这两种方法都会影响运营支持费用，您必须在设计中考虑这一点。您应使用的方法取决于您需要捕获哪些数据以及将如何使用这些数据。捕获数据的运营成本可能超出数据提供的价值。

对 MID 服务器的多区域支持

如果您的公司需要多区域支持 MID 服务器基础架构，您应该计划在至少两个可用区中部署每个 MID 服务器，并将其复制到其他区域中。

费用影响

选择在哪里部署 Google Cloud 资产发现的 ServiceNow 组件时，您需要考虑出站流量费用和计算费用。

出站流量费用

每当数据移出 Google Cloud 时，都会产生出站流量费用。因此，您应该分析您的使用场景的出站流量费用，以确定定位 ServiceNow 组件的最佳方案。通常，执行深度发现的 MID 服务器在 Google Cloud 中运行时比在其他云或本地运行时产生的出站流量费用低。

计算费用

在 Google Cloud 中运行的 ServiceNow 组件会产生计算费用，您应该分析这些费用以确定您的公司的最佳价值。

例如，您应考虑在 Google Cloud Compute Engine 实例中部署的 MID 服务器数量。部署更多 MID 服务器可加快资产发现过程。但这样做会增加计算费用，因为每个 MID 服务器都部署在自己的虚拟机实例中。如需详细了解部署一个还是多个 MID 服务器，请参阅在单个系统上安装多个 MID 服务器。

运营可支持性考虑事项

您的部署可能包括网络安全控制措施，例如防火墙、入侵保护系统、入侵检测系统和数据包镜像基础架构。如果 Google Cloud 与部署 MID 服务器的环境之间实施了大量网络安全控制措施，则这些控制措施可能会产生运营可支持性问题。为避免这些问题，我们建议您将 MID 服务器托管在 Google Cloud 中，或尽可能靠近深度发现将查询的 Google Cloud 基础架构。

保护 MID 服务器

我们建议对 MID 服务器实例采用以下安全性实践：

保护服务账号

我们建议采用以下安全性实践来管理服务账号：

文件夹和项目结构

文件夹和项目是 Google Cloud 资源层次结构中的节点。为了支持资产发现，文件夹和项目结构应反映应用和部署应用的环境的结构。以这种方式构建资源还能够使 ServiceNow 将资产映射到它们提供的技术服务。

请注意您为支持 ServiceNow 发现对文件夹和项目结构所做的任何更改。文件夹和项目结构的主要作用是支持结算和 IAM 访问。因此，您为支持 ServiceNow 所做的任何更改都应支持并符合您的组织的 Google Cloud Billing 结构。如需了解构建 Google Cloud 组织、文件夹和项目层次结构的最佳实践，请参阅资源层次结构以及创建和管理组织。

下图展示了完整形式的 Google Cloud 资源层次结构示例。在此示例中，文件夹结构定义了应用，每个项目定义了环境。

展示 Google Cloud 资源层次结构示例的图表。

标签

标签是可为云资源分配的键值对。（ServiceNow、AWS 和 Azure 将标签称为“标记”。）

ServiceNow 使用您为 Google Cloud 资产分配的标签来识别资产并视需要将其映射到服务。选择理想的标签方案有助于 ServiceNow 监控您的基础架构，以获得准确的报告和 ITOM/ITSM 合规性。

我们建议您对需要唯一标识（比文件夹和项目结构允许的内容更具体）的任何资源使用标签。例如，在以下情况下，建议您使用标签：

  • 如果您的应用有严格的合规性要求，您可以为所有应用资源添加标签，以便您的组织能够轻松识别范围内的所有基础架构。
  • 在多云环境中，您可以使用标签来识别所有资源的云服务提供商和区域。
  • 如果您需要比 Google Cloud Billing 报告或 将 Cloud Billing 数据导出到 BigQuery默认提供的内容更精细的可见性，可以按标签过滤数据。

Google 会自动为 VPC 中运行的 Google 管理资产分配标签。Google 分配的标签带有 goog- 前缀。MID 服务器不应尝试对这些资产执行深度检测。如需详细了解 Google 管理的资源的标签，请参阅基于标记的映射和根据 Cloud Asset Inventory 实时通知自动为资源添加标签。

下表列出了 Google Cloud 服务分配给那些服务管理的资源的标签。

Google Cloud 服务 标签或标签前缀
Google Kubernetes Engine goog-gke-
Compute Engine

goog-gce-

Dataproc

goog-dataproc-

Vertex AI Workbench

goog-caip-notebook and goog-caip-notebook-volume

为了有效支持资源管理，您的组织的部署流程必须创建项目和文件夹结构，并在整个组织中以一致的方式分配资产标签。如果不实施手动流程，基础架构和标签不一致可能会导致系统难以维护正确的 CMDB，这些流程可能不受支持且长期造成扩缩难题。

以下列表建议了使部署流程一致且可重复的最佳实践：

后续步骤