本文將探討架構模式，說明如何使用 ServiceNow Cloud Discovery，尋找及收集 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 工作流程。IT 部門可透過 Cloud Operations Workspace 等工具，建立多雲資源資訊主頁，並透過統一介面 (有時稱為「單一管理平台」) 管理複雜的設定。本文將介紹這個情境的一系列架構模式、概略說明高階元件，並討論一般設計考量。
此架構的 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 管理的基礎架構和客戶管理的基礎架構之間運作。 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 資產清單和其他 Google Cloud API，收集下列資源的相關資料：
- VM 執行個體
- 標記 (鍵/值)
- 儲存空間磁碟區和儲存空間對應
- 資料中心資源，包括硬體類型
- 雲端網路、子網路和閘道
- 圖片
- Cloud 負載平衡器和可用區
- 雲端資料庫和資料庫叢集
- 容器 (GKE)
- 根據資源標籤進行服務對應
在這個模式中，MID 伺服器不需要憑證，因為 MID 伺服器不會登入 VM 來收集資料。這會限制探索程序收集額外資訊的能力。但由於不需要管理及輪替 MID Server 憑證，因此作業成本較低。
下圖說明這個架構模式。
這個模式的 Google Cloud 部分包含下列項目：
- 一個 Google Cloud 專案 (圖表中的服務專案 A)，其中包含兩個 Google Cloud 負載平衡器、一或多個 VM 執行個體、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID Server 都會在專屬 VM 中執行。
- 第二個 Google Cloud 專案 (圖表中的服務專案 B)，其中包含在自有 VM 中執行的 MID 伺服器。
- 第三個 Google Cloud 專案 (圖表中的「主專案 C」)，其中包含合作夥伴互連。
- 其他代管服務，例如 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 詳細資料
- 執行中的程序
- TCP 連線
- 已安裝的軟體
在這個架構模式中，一或多個 ServiceNow MID 伺服器位於Google Cloud，而 ServiceNow 執行個體則託管在 ServiceNow 雲端平台。MID 伺服器會透過 MID 伺服器外部通訊通道 (ECC) 佇列 (未顯示) 連線至 ServiceNow 執行個體。此架構如下圖所示。
這個模式的 Google Cloud 部分包含下列項目：
- 服務專案 A，包含兩個 Google Cloud 負載平衡器、一或多個 VM、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID Server 都會在專屬 VM 中執行。
- 服務專案 B，內含在各自 VM 中執行的 MID 伺服器。
- 主專案 C，內含合作夥伴互連。
- 其他代管服務，例如 Cloud API、BigQuery 和 Cloud Storage。
- 部署於 GKE 基礎架構的 ServiceNow Kubernetes Discovery。
- 從 MID 伺服器到 Google Cloud API 設定的網路路徑。
- 服務帳戶可讓 MID 伺服器登入任何需要無伺服器 IP 位址探索的 VM。Google Cloud
- 從 MID 伺服器設定至任何需要無伺服器 IP 位址探索的 VM 的網路路徑。Google Cloud
ServiceNow 部分包含 ServiceNow 執行個體，可擷取 MID 伺服器的中繼資料，並儲存在 CMDB 中。
Google Cloud 使用 Agent Client Collector 模式進行探索
這個架構模式包含下列項目：
- 初始雲端探索。
- 一或多個 MID 伺服器。
額外的 ServiceNow 代理程式，即 Agent Client Collector，您必須在 VM 上安裝這個代理程式。這些代理程式會直接連線至 MID 伺服器，並將下列額外資訊轉送至 ServiceNow：
- 近乎即時的推送式探索
- 軟體用量計算
- 即時 CI 檢視畫面
- 伺服器工作流程自動化
下圖說明這個架構模式。
這個模式的 Google Cloud 部分包含下列項目：
- 服務專案 A，包含兩個 Google Cloud 負載平衡器、一或多個 VM 執行個體、一個 GKE 執行個體，以及一或多個 ServiceNow MID 伺服器。每個 MID Server 都會在專屬 VM 中執行。
- 服務專案 B，其中包含在自有 VM 中執行的 MID 伺服器。
- 主專案 C，內含合作夥伴互連。
- 部署於 GKE 基礎架構的 ServiceNow Kubernetes Discovery。
- 其他代管服務，例如 Cloud API、BigQuery 和 Cloud Storage。
- 從 MID 伺服器到 Google Cloud API 設定的網路路徑。
- 從 MID 伺服器設定至已安裝 ServiceNow Discovery Agent 的 VM 的網路路徑。Google Cloud
ServiceNow 部分包含下列項目：
- ServiceNow 執行個體，可從 MID 伺服器擷取中繼資料，並儲存在 CMDB 中。
- 安裝在客戶管理的 VM 上的 ServiceNow 探索代理程式。Google Cloud
雲端資產探索工作流程
下列各節將討論資產探索工作流程。 Google Cloud 這個工作流程適用於本文所述的所有三種架構模式。
安裝及設定 ServiceNow 元件
- 啟用 Cloud Asset Inventory API。
- 在 VM 上安裝 Agent Client Collector。詳情請參閱「安裝 Agent Client Collector」。
- 為託管 MID 伺服器的電腦分配資源。
- 設定防火牆規則，允許 VM 執行個體與 MID 伺服器主機電腦之間透過通訊埠 443 建立連線。
- 設定 MID Server 網路連線。
- 安裝 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 資料庫取得。在無代理程式模式中，VM 資訊不會包含目前的 OS 修補程式版本。如要取得這個詳細程度的資訊，MID 伺服器會執行深入探索，方法如下：
- MID 伺服器會根據需要深入探索的 VM IP 位址，建立批次工作。
- 在批次工作中，MID 伺服器會登入每個 VM，並查詢 OS 的修補程式版本和其他資訊。
- 如果安裝了 Agent Client Collector，系統會將擷取的資料直接傳輸至 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 Server 代理程式
另一個設計考量是是否要使用 MID Server 代理程式和服務帳戶。如果探索程序需要收集的資訊超出 Cloud Asset Inventory 提供的中繼資料，您需要使用具備服務帳戶的 MID 伺服器基礎架構，或是具備 Agent Client Collector 的 MID 伺服器。 這兩種方法都會影響營運支援成本，因此您必須在設計時考量這點。您應使用的方法取決於需要擷取的資料，以及資料的用途。擷取資料的營運成本可能高於資料提供的價值。
支援多個地區的 MID 伺服器
如果貴公司需要 MID Server 基礎架構的多區域支援，請規劃在至少兩個服務區域中部署每個 MID Server，並將其複製到另一個區域。
費用影響
選擇要部署資產探索 ServiceNow 元件的位置時，請考量輸出費用和運算費用。Google Cloud
輸出費用
只要資料移出 Google Cloud，就會產生輸出費用。因此，您應分析使用案例的輸出費用，找出最適合放置 ServiceNow 元件的選項。通常，如果執行深度探索的 MID 伺服器在Google Cloud 中執行，則輸出費用會比在其他雲端或地端執行時低。
運算費用
在 Google Cloud 中執行的 ServiceNow 元件會產生運算費用，您應分析這些費用，找出最符合貴公司需求的價值。 Google Cloud
舉例來說，您應考量在Google Cloud Compute Engine 執行個體中部署的 MID 伺服器數量。部署更多 MID 伺服器可加快資產探索程序。但這樣做會增加運算成本，因為每個 MID Server 都會部署在專屬的 VM 執行個體中。如要進一步瞭解是否要部署一或多個 MID 伺服器，請參閱「在單一系統上安裝多個 MID 伺服器」。
作業支援能力考量
您的部署作業可能包含網路安全控管機制，例如防火牆、入侵防護系統、入侵偵測系統和封包鏡像基礎架構。如果 Google Cloud 與部署 MID 伺服器的環境之間設有廣泛的網路安全控管機制，這些控管機制可能會造成運作支援問題。為避免這些問題，建議您將 MID 伺服器託管在 Google Cloud或盡可能靠近 Google Cloud 深層探索查詢的基礎架構。
保護 MID 伺服器
建議您為 MID Server 執行個體採取下列安全措施：
- 請確保 MID 伺服器已隔離，只有受信任的管理員可以連線。
- 請確認MID 伺服器已啟用防刪除功能。
- 請務必套用 IAM 角色，限制只有透過 ITIL 程序或 CI/CD 管道核准的變更，才能進行變更。
保護服務帳戶
管理服務帳戶時，建議採取下列安全措施：
- 請確保 MID 伺服器使用的服務帳戶，只具備資產探索作業絕對必要的 IAM 角色和權限。詳情請參閱「使用服務帳戶的最佳做法」。
- 如要驗證 ServiceNow，請將服務帳戶金鑰的內容複製到 ServiceNow 使用者介面。
如未妥善管理服務帳戶金鑰，可能會產生安全性風險，您必須負責維護私密金鑰的安全性，以及
管理服務帳戶金鑰的最佳做法一文所述的其他作業。假如無法建立服務帳戶金鑰，可能是因為貴組織已停用這項功能。詳情請參閱「
管理預設安全機構資源」。
如果您是從外部來源取得服務帳戶金鑰，必須先驗證金鑰，才能使用。詳情請參閱「 外部來源憑證的安全規定」一節。
資料夾和專案結構
資料夾和專案是 Google Cloud 資源階層中的節點。為支援資產探索功能，資料夾和專案結構應反映應用程式的結構，以及應用程式部署所在的環境。以這種方式建構資源，ServiceNow 就能將資產對應至提供的技術服務。
請注意，您對資料夾和專案結構所做的任何變更，都會影響 ServiceNow 探索功能。資料夾和專案結構的主要角色是支援帳單和 IAM 存取權。因此，您對 ServiceNow 支援服務所做的任何變更，都應支援並配合貴機構的Google Cloud 帳單結構。如需機構、資料夾和專案階層結構的最佳做法，請參閱「資源階層」和「建立及管理機構」。Google Cloud
下圖為完整形式的 Google Cloud 資源階層範例。在本範例中，資料夾結構會定義應用程式，每個專案則定義一個環境。
標籤
標籤 是您可以指派給雲端資源的鍵/值組合。(ServiceNow、AWS 和 Azure 將標籤稱為「標記」)。
ServiceNow 會使用您指派給資產的標籤 Google Cloud 來識別資產，並視需要將資產對應至服務。選擇適當的標籤配置有助於 ServiceNow 監控基礎架構，確保報表準確無誤，並符合 ITOM/ITSM 規範。
如果資源需要比資料夾和專案結構更具體的專屬 ID，建議使用標籤。舉例來說，您可能會在下列情況使用標籤：
- 如果應用程式有嚴格的法規遵循要求，您可以為所有應用程式資源加上標籤，方便機構輕鬆識別範圍內的所有基礎架構。
- 在多雲環境中，您可以使用標籤識別所有資源的雲端服務供應商和區域。
- 如果需要比Google Cloud 帳單報表或 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，而且手動程序可能無法支援，長期下來也會面臨擴充方面的挑戰。
以下列出幾項最佳做法，可讓部署程序保持一致且可重複執行：
- 使用基礎架構即程式碼 (IaC) 或自動佈建系統，例如 Terraform、ServiceNow ITOM，或使用 Google Cloud Deployment Manager 進行雲端佈建和控管。
- 為標籤制定完善的管理流程。如要瞭解標籤控管的總覽資訊，請參閱 ServiceNow 說明文件中的「標籤控管」。
後續步驟
- 瞭解 ServiceNow 的整合連接器。
- 如需更多有關 Cloud Billing 資源架構的最佳做法，請參閱「Cloud Billing 資源管理與存取權管理指南」和「Google Cloud 適用的 Cloud Insights 設定指南」。
- 如需規劃機構 IAM 權限的最佳做法，請參閱「規劃帳戶和機構的最佳做法」和「Cloud 佈建和控管」。
- 如要瞭解在整個機構中建構虛擬私有雲防火牆政策的最佳做法，請參閱「階層式防火牆政策」。
- 瞭解如何使用標籤支援 ServiceNow 以標籤為準的探索功能。
- 瞭解 ServiceNow Agent Client Collector，這是一種推送機制，可在您的 Google Cloud 專案中執行，並透過 MID Server 將輸出資料傳送至 ServiceNow 執行個體，將事件和指標儲存在相關資料庫中。
- 如需更多參考架構、圖表和最佳做法，請前往 Cloud Architecture Center。