本文档介绍了如何使用 ServiceNow 云发现查找和收集 Google Cloud、其他云平台和本地中的资产相关信息的架构模式。本文档适用于熟悉 IT 运维管理 (ITOM)、信息技术基础架构库 (ITIL)、Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Asset Inventory 等 Google Cloud 服务以及 ServiceNow Cloud Discovery 的基础架构团队或云运维团队。
概览
许多大型企业使用混合 IT 基础架构部署，将 Google Cloud、其他云平台和本地基础架构相结合。此类混合部署通常是云迁移策略中的初始迭代。这些企业的 IT 部门需要发现和跟踪其技术生态系统中的所有资产，这些资产可能数以百万计。IT 部门必须构建一个配置管理系统，用于将这些资产与资产提供的技术服务相关联。此系统还必须以支持 IT 运维管理 (ITOM) 和 IT 服务管理 (ITSM) 最佳实践的方式监控资产和服务。
对于 Google Cloud 客户，常见的架构使用 ServiceNow 云资源发现来查找和收集有关 Google Cloud、其他云平台和本地中的资产的信息。ServiceNow 提供了各种工具，用于跨多个云提供商自动执行资源管理 IT 工作流。借助 Cloud Operations 工作区等工具，IT 部门可以创建多云资源信息中心，并通过统一界面（有时称为单一管理平台）管理复杂配置。本文档介绍了针对此场景的一组架构模式、其概要组件概览，以及一般设计考虑事项。
此架构的 ServiceNow 组件
这些架构模式中的 ServiceNow 平台组件包括：
- 包含配置项 (CI) 的 配置管理数据库 (CMDB) 的 ServiceNow 实例。每个 CI 代表运营环境中与数字服务交付相关的组件。CI 具有多个属性，这些属性包含有关组件及其与其他 CI 的关系的特定元数据。
- 在 Google Cloud 项目中运行的一个或多个 ServiceNow 管理、插桩和发现 (MID) 服务器。MID 服务器会收集 CI 的元数据并将其存储在 CMDB 中。
这些架构模式定义了将 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 项目（图中的服务项目 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 部分包含以下各项：
- 服务项目 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 部分包含以下各项：
- 服务项目 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 组件
- 启用 Cloud Asset Inventory API。
- 在虚拟机上安装代理客户端收集器。如需了解详情，请参阅代理客户端收集器安装。
- 为托管 MID 服务器的计算机分配资源。
- 配置防火墙规则以允许虚拟机实例与托管 MID 服务器的计算机之间通过端口 443 建立连接。
- 配置 MID 服务器网络连接。
- 安装 MID 服务器。
- 配置 MID 服务器以调用相关 Google Cloud API。确保 MID 服务器具有有效的网络路由来调用 Google Cloud API。
工作流
- Cloud Asset Inventory 编译 Google Cloud 环境中所有受支持的资产类型的数据库。ServiceNow 使用 Cloud Asset Inventory 作为检索更多信息来更新 CMDB 的来源。
- ServiceNow MID 服务器查询 Cloud Asset Inventory 数据库，以获取有关 Google Cloud 环境中所有资产的信息。
- MID 服务器将云资产信息存储在 Cloud Storage 存储桶中。
- 并非所有必需信息都可以从 Cloud Asset Inventory 数据库获取。在无代理模式中，虚拟机信息不包含当前操作系统补丁版本。对于此详细程度，MID 服务器通过执行以下操作来执行深度发现：
- MID 服务器根据需要深度发现的虚拟机的 IP 地址创建批量作业。
- 在批量作业中，MID 服务器登录每个虚拟机，并查询操作系统以获取补丁版本控制和其他信息。
- 如果安装了代理客户端收集器，则它们捕获的数据会直接传输到 MID 服务器，而不是存储在 Cloud Asset Inventory 数据库中。如需了解详情，请参阅网络准备和 MID 服务器配置。
- 收集资产发现数据后，MID 服务器将其存储到 CMDB 中，如下所示：
- MID 服务器在 CMDB 中创建 CI，以表示每个资产提供的运营能力。
- 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 服务器，并将其复制到其他区域中。
费用影响
选择部署 ServiceNow 组件的位置以进行 Google Cloud 资产发现时，您需要考虑出站流量费用和计算费用。
出站流量费用
每当数据移出 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 服务器实例采用以下安全性实践：
- 确保 MID 服务器处于隔离状态，以帮助确保只有受信任的管理员才能连接到它们。
- 确保 MID 服务器免遭删除。
- 确保应用 IAM 角色，以便将更改权限仅限于通过 ITIL 流程或通过 CI/CD 流水线批准的更改。
保护服务账号
我们建议采用以下安全性实践来管理服务账号：
- 如果您是在 Google Cloud 中托管 MID 服务器，则可以使用关联的服务账号自动处理身份验证。如果您是在 Google Cloud 之外托管 MID 服务器，则您需要负责生成用户管理的服务账号密钥来进行身份验证，并且需要保护和审核此永久性凭据。如需了解详情，请参阅管理服务账号密钥的最佳实践。
- 确保 MID 服务器使用的服务账号仅具有对资产发现绝对必要的 IAM 角色和权限。如需了解详情，请参阅使用服务账号的最佳实践。
文件夹和项目结构
文件夹和项目是 Google Cloud 资源层次结构中的节点。为了支持资产发现，文件夹和项目结构应反映应用和部署应用的环境的结构。以这种方式构建资源还能够使 ServiceNow 将资产映射到它们提供的技术服务。
请注意您为支持 ServiceNow 发现对文件夹和项目结构所做的任何更改。文件夹和项目结构的主要作用是支持结算和 IAM 访问。因此，您为支持 ServiceNow 所做的任何更改都应支持并符合您的组织的 Google Cloud Billing 结构。如需了解构建 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 |
|
| Dataproc |
|
| Vertex AI Workbench |
|
为了有效支持资源管理，您的组织的部署流程必须创建项目和文件夹结构，并在整个组织中以一致的方式分配资产标签。如果不实施手动流程，基础架构和标签不一致可能会导致系统难以维护正确的 CMDB，这些流程可能不受支持且长期造成扩缩难题。
以下列表建议了使部署流程一致且可重复的最佳实践：
- 使用基础架构即代码 (IaC) 或自动预配系统，例如 Terraform、ServiceNow ITOM 或使用 Google Cloud Deployment Manager 的 Cloud 预配和治理。
- 为您的标签实施合理的治理流程。如需简要了解标签治理，请参阅 ServiceNow 文档中的标记治理。
后续步骤
- 如需了解构建 Cloud Billing 资源的其他最佳实践，请参阅 Cloud Billing 资源组织和访问管理指南以及适用于 Google Cloud 的 Cloud Insights 设置指南。
- 如需了解构建您的组织的 IAM 权限的最佳实践，请参阅规划账号和组织的最佳实践以及 Cloud 预配和治理。
- 如需了解在整个组织中构建 VPC 防火墙政策的最佳实践，请参阅分层防火墙政策。
- 了解如何使用标签来支持 ServiceNow 基于标记的发现。
- 了解 ServiceNow 代理客户端收集器，这是一个在 Google Cloud 项目中运行并通过 MID 服务器将输出数据发送到 ServiceNow 实例的推送机制，同时将事件和指标存储在相关数据库中。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。