參考架構：使用 ServiceNow 進行資源管理

Last reviewed 2025-05-08 UTC

本文將說明架構模式，說明如何使用 ServiceNow 雲端探索功能，找出並收集 Google Cloud、其他雲端平台和內部資產的相關資訊。本文件適用於熟悉 IT 作業管理 (ITOM)、資訊技術基礎架構庫 (ITIL)、 Google Cloud Compute Engine、Google Kubernetes Engine (GKE) 和 Cloud Asset Inventory 等服務，以及 ServiceNow Cloud Discovery 的架構團隊或雲端作業團隊。

總覽

許多大型企業都會採用混合式 IT 基礎架構部署作業，結合Google Cloud、其他雲端平台和內部部署基礎架構。這種混合式部署通常是雲端遷移策略中的初始疊代。這些企業的 IT 部門必須探索並追蹤技術生態系統中的所有資產，這些資產可能多達數百萬個。IT 部門必須建構設定管理系統，將這些資產與資產提供的技術服務連結在一起。這套系統也必須以符合 IT 作業管理 (ITOM) 和 IT 服務管理 (ITSM) 最佳做法的做法，監控資產和服務。

對於 Google Cloud 客戶，常見的架構會使用 ServiceNow 雲端資源探索功能，尋找並收集 Google Cloud、其他雲端平台和內部資產的相關資訊。ServiceNow 提供多種工具，可在多個雲端服務供應商環境中自動化資源管理 IT 工作流程。Cloud Operations Workspace 等工具可讓 IT 部門透過統一介面 (有時稱為「單一控制台」) 建立多雲資源資訊主頁，並管理複雜的設定。本文件將介紹此情境的一系列架構模式、概略說明其高階元件，並討論一般設計考量。

此架構適用的 ServiceNow 元件

這些架構模式中的 ServiceNow 平台元件包括：

這些架構模式定義了一些常見做法，可將 Google Cloud Asset Inventory 資料匯入 ServiceNow 的 Google Cloud Platform 資產目錄探索功能。

Google Cloud 整合的架構模式

本文將說明下列架構模式，說明如何將Google Cloud 整合至 ServiceNow：

這些架構模式範例是為混合部署作業所設計，其中包含部分位於 Google Cloud 中的基礎架構，以及位於 ServiceNow 雲端的基礎架構。這些範例說明瞭 ServiceNow 如何在 Google 代管基礎架構和客戶代管基礎架構之間運作。 Google Cloud ServiceNow MID 伺服器會透過呼叫 Google Cloud API 查詢所有 Google 代管基礎架構。如要進一步瞭解系統會呼叫哪些 API，請參閱「ITOM 應用程式使用的 Google Cloud Platform API」。

在下列各個模式中，架構元件會在 Google Cloud Platform 資產目錄探索程序中搭配運作，收集 ServiceNow Discovery 應用程式和相關工具所需的雲端資產目錄資訊。

Google Cloud 探索模式

基本 ServiceNow 雲端探索架構模式會使用 ServiceNow MID 伺服器呼叫 Google Cloud Asset Inventory 和其他 Google Cloud API，收集資源相關資料，例如：

  • VM 執行個體
  • 標記 (鍵/值)
  • 儲存空間磁碟區和儲存空間對應
  • 資料中心資源，包括硬體類型
  • 雲端網路、子網路和閘道
  • 圖片
  • Cloud 負載平衡器和可用性區
  • 雲端資料庫和資料庫叢集
  • 容器 (GKE)
  • 依據資源標籤進行服務對應

在這種模式中，MID 伺服器不需要憑證，因為它們不會登入 VM 來收集資料。這會限制探索程序收集其他資訊的能力。但由於不需要管理及輪替 MID 伺服器憑證，因此作業成本較低。

下圖說明這個架構模式。

顯示 Google Cloud 探索架構模式的圖表。

這個模式的 Google Cloud 部分包含以下內容：

  • 一個 Google Cloud 專案 (圖表中的 Service Project A)，其中包含兩個 Google Cloud 負載平衡器、一或多個 VM 執行個體、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID 伺服器都會在自己的 VM 中執行。
  • 第二個 Google Cloud 專案 (圖表中的服務專案 B)，其中包含在各自 VM 中執行的 MID 伺服器。
  • 第三個專案 (圖表中的主機專案 C)，包含合作夥伴互連網路。 Google Cloud
  • 其他代管服務，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 從 MID 伺服器到 Google Cloud API 的網路路徑。

ServiceNow 部分包含 ServiceNow 例項，可擷取 MID 伺服器的中繼資料，並儲存在 CMDB 中。

Google Cloud 無代理程式 IP 探索模式

這個架構模式會使用批次作業和Google Cloud 服務帳戶登入 VM 並收集其他詳細資料，藉此在基本雲端探索模式中加入以 IP 為基礎的探索。相較於基本模式，這個模式需要管理 MID 伺服器的作業負擔較重，因為您必須管理及輪替 MID 伺服器憑證。不過，這項功能會擴大探索程序，除了 Cloud Asset Inventory 提供的資料之外，還會納入其他資料，例如：

  • OS 憑證管理和安全性
  • 強化探索功能，例如檔案探索功能和授權探索功能
  • OS 詳細資料
  • 執行中的程序
  • TCP 連線
  • 已安裝的軟體

在這個架構模式中，一或多部 ServiceNow MID 伺服器位於Google Cloud中，而 ServiceNow 執行個體則託管在 ServiceNow 雲端平台中。MID 伺服器會透過 MID 伺服器外部通訊通道 (ECC) 佇列 (未顯示) 連線至 ServiceNow 執行個體。下圖說明此架構。

顯示 Google Cloud 無代理程式 IP 型探索模式的圖表。

這個模式的 Google Cloud 部分包含以下內容：

  • 服務專案 A 包含兩個 Google Cloud 負載平衡器、一或多個 VM、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID 伺服器都會在自己的 VM 中執行。
  • 服務專案 B，其中包含在各自 VM 中執行的 MID 伺服器。
  • 主機專案 C，包含合作夥伴互連網路。
  • 其他代管服務，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 在 GKE 基礎架構上部署的 ServiceNow Kubernetes Discovery。
  • 從 MID 伺服器到 Google Cloud API 的網路路徑。
  • 服務帳戶可讓 MID 伺服器登入任何需要無伺服器 IP 位址探索功能的Google Cloud VM。
  • 從 MID 伺服器到任何需要無伺服器 IP 位址探索的Google Cloud VM 所設定的網路路徑。

ServiceNow 部分包含 ServiceNow 例項，可擷取 MID 伺服器的中繼資料，並儲存在 CMDB 中。

Google Cloud 使用代理程式用戶端收集器模式進行探索

這個架構模式包含下列項目：

  • 初始雲端探索。
  • 一或多個 MID 伺服器。

  • 在 VM 上安裝的額外 ServiceNow 代理程式，即 Agent Client Collector。這些代理程式會直接連線至 MID 伺服器，並將下列額外資訊轉送至 ServiceNow：

    • 近乎即時的推播式探索
    • 軟體計量
    • 即時 CI 檢視畫面
    • 為伺服器自動化工作流程

下圖說明這個架構模式。

這張圖表顯示使用代理程式用戶端收集器模式的 Google Cloud 探索功能。

這個模式的 Google Cloud 部分包含以下內容：

  • 服務專案 A 包含兩個 Google Cloud 負載平衡器、一或多個 VM 執行個體、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID 伺服器都會在自己的 VM 中執行。
  • 服務專案 B，其中包含在各自 VM 中執行的 MID 伺服器。
  • 主機專案 C，包含合作夥伴互連網路。
  • 在 GKE 基礎架構上部署的 ServiceNow Kubernetes Discovery。
  • 其他代管服務，例如 Cloud API、BigQuery 和 Cloud Storage。
  • 從 MID 伺服器到 Google Cloud API 的網路路徑。
  • 從 MID 伺服器到已安裝 ServiceNow Discovery Agent 的Google Cloud VM 所設定的網路路徑。

ServiceNow 部分包含以下內容：

  • ServiceNow 執行個體，可擷取 MID 伺服器中的中繼資料，並儲存在 CMDB 中。
  • 在客戶管理的Google Cloud VM 上安裝的 ServiceNow 探索代理程式。

Cloud Asset Discovery 工作流程

以下各節將說明 Google Cloud 資產探索的工作流程。這個工作流程適用於本文件中所述的所有三種架構模式。

安裝及設定 ServiceNow 元件

  1. 啟用 Cloud Asset Inventory API。
  2. 在 VM 上安裝代理程式用戶端收集器。詳情請參閱「代理程式用戶端收集器安裝程序」。
  3. 為託管 MID 伺服器的電腦分配資源。
  4. 設定防火牆規則，允許 VM 執行個體與主機代管 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 資料庫取得。在無代理程式模式中，VM 資訊不會包含目前的 OS 修補程式版本。針對這層級別的詳細資料，MID 伺服器會執行深入探索作業，方法如下：
    1. MID 伺服器會根據需要進行深入探索的 VM IP 位址建立批次工作。
    2. 在批次工作中，MID 伺服器會登入每個 VM，並查詢 OS 的修補程式版本和其他資訊。
  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 伺服器基礎架構，或是搭配Agent Client Collector 的 MID 伺服器。無論採用哪種方法，都會影響營運支援成本，因此您必須在設計中考量這點。您應採用的方法取決於您需要擷取哪些資料，以及如何使用這些資料。擷取資料的營運成本可能超過資料提供的價值。

支援 MID 伺服器的多區域

如果貴公司需要 MID 伺服器基礎架構的多區支援功能，請務必至少在兩個可用性區部署每個 MID 伺服器，並將其複寫到其他地區。

費用影響

選擇部署 ServiceNow 元件的位置時，您需要考量Google Cloud 資產探索功能的資料傳出成本和運算成本。

輸出費用

資料從 Google Cloud移出時，系統會收取輸出費用。因此，您應分析用途的傳出成本，以便決定將 ServiceNow 元件放在何處的最佳選項。通常，如果執行深入探索的 MID 伺服器在Google Cloud 上執行，所產生的傳出費用會比在其他雲端或內部執行時更低。

運算費用

在 Google Cloud 中執行的 ServiceNow 元件會產生運算成本，您應分析這些成本，以便為貴公司決定最佳價值。

舉例來說，您應考量在Google Cloud Compute Engine 執行個體中部署的 MID 伺服器數量。部署更多 MID 伺服器可加快資產探索程序。但這樣做會增加運算成本，因為每個 MID 伺服器都會部署在專屬的 VM 執行個體中。如要進一步瞭解是否要部署一個或多個 MID 伺服器，請參閱「在單一系統上安裝多個 MID 伺服器」。

作業支援性考量

您的部署作業可能會納入網路安全控管機制，例如防火牆、入侵防護系統、入侵偵測系統和封包鏡像基礎架構。如果在 Google Cloud 與部署 MID 伺服器的環境之間，有大量網路安全性控管機制，這些控管機制可能會造成作業支援問題。為避免這些問題，建議您將 MID 伺服器託管在 Google Cloud中，或盡可能靠近深度探索會查詢的 Google Cloud 基礎架構。

保護 MID 伺服器

我們建議您為 MID Server 執行個體採用下列安全做法：

保護服務帳戶

我們建議您採用下列安全做法來管理服務帳戶：

資料夾和專案結構

資料夾和專案是 Google Cloud 資源階層中的節點。為支援素材資源探索功能，您的資料夾和專案結構應反映應用程式結構，以及應用程式部署的環境。以這種方式建構資源，ServiceNow 就能將資產對應至資產提供的技術服務。

請注意，您對資料夾和專案結構所做的任何變更都必須支援 ServiceNow 探索功能。資料夾和專案結構的主要角色是支援帳單和 IAM 存取權。因此，您為支援 ServiceNow 而做的任何變更都應符合貴機構的Google Cloud 帳單結構，如要瞭解建立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 service 標籤或標籤前置字元
Google Kubernetes Engine goog-gke-
Compute Engine goog-gce-
Dataproc goog-dataproc-
Vertex AI Workbench goog-caip-notebook and goog-caip-notebook-volume

為了有效支援資源管理，貴機構的部署程序必須建立專案和資料夾結構，並在整個機構中一致地指派資產標籤。基礎架構和標籤不一致，可能會導致 CMDB 無法正確維護，除非採用可能無法支援且長期難以擴充的手動程序。

下列清單列出讓部署程序一致且可重複執行的最佳做法：

後續步驟