VM 工作負載部署作業總覽

本指南涵蓋的概念背景，有助您使用 VM Runtime，將以虛擬機器 (VM) 為基礎的工作負載，部署到裸機上的 Google Distributed Cloud (GDC) 氣隙叢集。本指南中的工作負載是可透過內部部署硬體使用的 ServiceNow 平台範例。

架構

資源階層

在 GDC 中，您會為營運團隊部署 ServiceNow 的元件，這些元件位於專屬的租戶機構中，與任何客戶機構相同。 機構是統一管理的一組叢集、基礎架構資源和應用程式工作負載。GDC 執行個體中的每個機構都會使用專屬伺服器，確保租戶之間有嚴密的隔離措施。如要進一步瞭解基礎架構，請參閱「設計存取權界線」。

GDC 實體隔離資源階層

此外，您可以在專案中一併部署及管理 ServiceNow 資源，透過軟體政策和強制執行機制，在機構內提供邏輯隔離。專案中的資源應配對生命週期必須保持在一起的元件。

ServiceNow 採用三層式架構，透過負載平衡器將流量導向應用程式伺服器，這些伺服器會連線至儲存永久資料的資料庫伺服器。

這種架構可獨立開發及維護各層級，因此具備擴充性和可維護性。此外，它還能清楚劃分關注事項，簡化偵錯和疑難排解程序。將這些層級封裝在 GDC 專案中，可讓您一併部署及管理元件，例如應用程式和資料庫伺服器。

網路

如要在實際工作環境中執行 ServiceNow，必須部署兩個以上的應用程式伺服器，才能在節點故障時達到高可用性。搭配負載平衡器使用時，這種拓撲也能將負載分散到多部機器，以水平擴展應用程式。GDC 的 Kubernetes 原生平台會利用 Cloud Service Mesh，安全地將流量轉送至構成 ServiceNow 的應用程式伺服器。

Cloud Service Mesh 是 Google 根據開放原始碼 Istio 專案建構而成，可管理、監控及保護服務。在 GDC 上代管 ServiceNow 時，會運用 Cloud Service Mesh 的下列功能：

  • 負載平衡：Cloud Service Mesh 會將流量與基礎架構的資源調度加以分離，可提供許多流量管理功能，包括動態要求轉送。ServiceNow 需要持續的用戶端連線，因此我們使用 DestinationRules 啟用黏性工作階段，以設定流量轉送行為。

  • TLS 終止：Cloud Service Mesh 會使用 TLS 憑證公開 Ingress 閘道，並透過 mTLS (雙向傳輸層安全標準) 在叢集內提供傳輸驗證，不必變更任何應用程式碼。

  • 故障復原：Cloud Service Mesh 提供許多重要的故障復原功能，包括逾時管理、斷路器、主動式健康狀態檢查和受限的重試機制。

在 Kubernetes 叢集內，我們使用標準 Service 物件做為抽象方式，將應用程式和資料庫伺服器公開至網路。服務提供便利的方式，可使用選取器指定執行個體，並使用叢集感知 DNS 伺服器在叢集內提供名稱解析。

apiVersion: v1
kind: Service
metadata:
  name: http-ingress
spec:
  selector:
    app.kubernetes.io/component: application-server
  ports:
  - name: http
    port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: database-ingress
spec:
  selector:
    app.kubernetes.io/component: database-server
  ports:
  - name: mysql
    port: 3306

運算

ServiceNow 建議使用 Bare Metal 或虛擬機器來託管內部部署安裝，而我們利用 GDC 虛擬機器 (VM) 管理功能，將應用程式和資料庫伺服器部署為 VM 工作負載。定義 Kubernetes 資源後，我們就能指定 VirtualMachine 和 VirtualMachineDisk，根據不同類型的伺服器調整資源，滿足我們的需求。VirtualMachineExternalAccess 可讓我們設定 VM 的資料移入和移出作業。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: vm1-boot-disk
spec:
  size: 100G
  source:
    image:
      name: ts-service-now-system-app-server-2023-08-18-203258
      namespace: vm-system
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  labels:
    app.kubernetes.io/component: application-server
  name: vm1
  namespace: support
spec:
  compute:
    vcpus: 8
    memory: 12G
  disks:
  - boot: true
    virtualMachineDiskRef:
      name: vm1-boot-disk

---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: vm1
  namespace: support
spec:
  enabled: true
  ports:
   - name: ssh
     protocol: TCP
     port: 22

我們根據 Red Hat Enterprise Linux 建立自訂映像檔，以符合法規遵循和安全方面的需求，透過 VirtualMachineAccessRequest，您可以使用 SSH 連線至執行中的 VM 執行個體，藉此透過 Kubernetes RBAC 限制連線至 VM 的能力，並避免在自訂映像檔中建立本機使用者帳戶。存取要求也會定義存留時間 (TTL)，讓以時間為準的存取要求管理 VM，並自動過期。

自動化

我們為這個專案設計了可重複執行的 ServiceNow 執行個體安裝方法，支援大規模自動化，並減少部署之間的設定差異，做為專案的主要交付項目。

Helm Packaging

Helm 是 Kubernetes 的套件管理工具，可管理應用程式的生命週期，包括安裝及升級構成應用程式的所有元件。Helm 也提供管理依附元件的方法，例如與可觀測性和法規遵循等其他系統整合時所需的自訂資源。建立 Helm 資訊圖表可封裝這些資源，簡化 ServiceNow 的安裝和管理程序。

發布管道

自訂應用程式和資料庫伺服器映像檔時，請先從基本作業系統映像檔開始，視需要修改基本映像檔，安裝每個伺服器映像檔所需的依附元件。我們選擇 Red Hat Enterprise Linux (RHEL) 做為基本 OS 映像檔，因為許多內部部署安裝作業都採用這個作業系統來代管 ServiceNow。Red Hat Enterprise Linux 也提供安全強化功能，可滿足安全技術實作指南 (STIG) 的要求，以提供符合 NIST-800-53 控制項的相容映像檔。

我們的持續整合 (CI) 管道使用下列工作流程，自訂應用程式和資料庫伺服器映像檔：

持續整合工作流程

開發人員變更自訂指令碼或圖片依附元件時，我們會在 CI 工具中觸發自動化工作流程，產生一組新的圖片，並與 GDC 版本一併發布。在建構映像檔時，我們也會重新整理 OS 依附元件 (yum update)，並以壓縮方式稀疏化映像檔，減少將映像檔傳輸至客戶環境所需的映像檔大小。

軟體開發生命週期

軟體開發生命週期 (SDLC) 是一項程序，可協助機構規劃、建立、測試及部署軟體。遵循明確定義的 SDLC，機構就能確保軟體開發方式一致且可重複，並及早發現潛在問題。除了在持續整合 (CI) 管道中建構映像檔，我們也定義了開發環境和預先發布的 ServiceNow 暫存版本，以進行測試和品質保證。

為每個 GDC 專案部署個別的 ServiceNow 執行個體，可讓我們獨立測試變更，而不影響相同 GDC 執行個體上的現有執行個體。我們使用 ResourceManager API，以宣告方式建立及終止專案，並使用 Kubernetes 資源。

apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-dev
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-qa
---
apiVersion: resourcemanager.gdc.goog/v1
kind: Project
metadata:
  name: service-now-staging

搭配 Helm 圖表封裝和管理基礎架構 (例如虛擬機器即程式碼)，開發人員可以快速疊代變更，並與正式版例項一起測試新功能。此外，自動測試執行架構也能透過宣告式 API 執行定期迴歸測試，並驗證現有功能。

可操作性

可操作性是指系統操作和維護的容易程度。設計任何軟體應用程式時，這都是重要的考量因素。有效監控有助於提升可操作性，因為這樣一來，就能在問題對系統造成重大影響前找出並解決。監控作業也有助於找出改善機會，並建立服務等級目標 (SLO) 的基準。

監控

我們將 ServiceNow 與現有的 GDC 可觀測性基礎架構 (包括記錄和指標) 整合。就指標而言，我們會從每個 VM 公開 HTTP 端點，讓 Prometheus 能夠擷取應用程式和資料庫伺服器產生的資料點。這些端點包括使用 Prometheus 節點匯出工具收集的系統指標，以及應用程式專屬指標 (例如使用 MySQL 資料庫匯出工具)。

每個 VM 都會公開端點，我們使用 MonitoringTarget 自訂資源設定 Prometheus 輪詢行為，定義抓取間隔並註解指標。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
  name: database-monitor
spec:
  podMetricsEndpoints:
    path:
      value: /metrics
    port:
      annotation: application.io/dbMetrics
    scrapeInterval: 60s

在記錄方面，我們在每個 VM 中安裝並設定 FluentBit，以追蹤相關記錄，並將記錄資料傳送至 Loki，然後透過 Grafana 為資料建立索引及查詢。稽核記錄會轉送至設定為延長保留期限的特殊端點，以符合法規要求。以容器為基礎的應用程式可以使用 LoggingTarget 和 AuditLoggingTarget 自訂資源，指示記錄管道從專案中的特定服務收集記錄。

我們根據 Prometheus 和 Loki 中提供的資料，使用 MonitoringRule 自訂資源建立快訊，以便在 Helm 圖表中以程式碼形式管理這項設定。使用宣告式 API 定義快訊和資訊主頁，也能讓我們將這項設定儲存在 Git 存放區中，並遵循與其他程式碼變更相同的程式碼審查和持續整合程序。

故障模式

早期測試發現了幾種與資源相關的故障模式，有助於我們判斷應優先加入哪些指標和快訊。我們首先監控高記憶體和磁碟用量，因為資料庫設定錯誤一開始導致緩衝區資料表耗用所有可用記憶體，而過度記錄則填滿了附加的永久磁碟磁碟區。調整 InnoDB 緩衝區大小並實作記錄輪替策略後，我們導入了警報，會在 VM 接近高記憶體或磁碟用量時執行。我們也編寫了執行手冊並指派錯誤代碼，以便在觸發快訊時，作業人員能快速查看診斷和解決問題的說明文件。

apiVersion: monitoring.gdc.goog/v1
kind: MonitoringRule
metadata:
  name: monitoring-rule
spec:
  interval: 60s
  limit: 0
  alertRules:
  - alert: vm1_disk_usage
    expr:
      (node_filesystem_size_bytes{container_name="compute"} -
      node_filesystem_avail_bytes{container_name="compute"}) * 100 /
      node_filesystem_size_bytes{container_name="compute"} > 90
    labels:
      severity: error
      code: <a href="/distributed-cloud/hosted/docs/latest/gdch/gdch-io/service-manual/ts/runbooks/ts-r0001">TS-R0001</a>
      resource: vm1
    annotations:
      message: "vm1 disk usage above 90% utilization"

確認系統穩定性後，我們將重點轉移至 ServiceNow 內的應用程式故障模式。由於應用程式內的問題偵錯通常需要我們使用安全殼層 (SSH) 進入每個應用程式伺服器 VM，才能檢查 ServiceNow 系統記錄，因此我們設定 FluentBit 將這些記錄轉送至 Loki，以便在 GDC 可觀測性堆疊上建構，並在 Grafana 中查詢所有 ServiceNow 作業記錄。

集中式記錄功能也讓我們能同時查詢多個 VM 的記錄，進一步整合系統各個元件的檢視畫面。接著，我們將記錄搜尋查詢納入執行手冊，讓作業人員將錯誤情況與已知的解決方法和解決方案相符。

備份

備份對軟體系統的運作至關重要，因為系統發生故障時，備份可讓系統復原。GDC 可透過 Kubernetes 資源備份及還原 VM。建立VirtualMachineBackupRequest自訂資源VirtualMachineBackupPlanTemplate，即可將附加至每個 VM 的永久磁碟區備份至物件儲存空間，並按照透過值區設定的保留政策保留備份。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupPlanTemplate
metadata:
  name: vm-backup-plan
spec:
  backupRepository: "backup-repository"
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineBackupRequest
metadata:
  name: "db-vm-backup"
spec:
  virtualMachineBackupPlanTemplate: vm-backup-plan
  virtualMachine: db1
  virtualMachineBackupName: db-vm-backup

同樣地，從備份還原 VM 狀態時，需要建立VirtualMachineRestoreRequest自訂資源，才能還原應用程式和資料庫伺服器，不必修改任一服務的程式碼或設定。

apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineRestoreRequest
metadata:
  name: vm-restore-1
spec:
  virtualMachineBackup: db-vm-backup
  restoreName: restore1
  restoredResourceName: db1

升級

為支援 ServiceNow 及其依附元件的軟體生命週期，我們定義了三種軟體升級類型，每種升級的處理方式略有不同，目的是盡量減少停機時間和服務中斷：

  1. 作業系統升級。
  2. 平台升級，例如修補程式和主要版本。
  3. 更新設定。

為升級 OS，我們會持續為應用程式和資料庫伺服器建構及發布新的 VM 映像檔，並在每次 GDC 發布時一併發布。這些映像檔包含安全漏洞的修正程式，以及基礎 Red Hat 作業系統的更新。如要部署新映像檔，營運人員必須按照 runbook 中的詳細步驟，上傳及啟動新的 VM、驗證設定，並停用先前的執行個體。

ServiceNow 平台升級需要對現有 VM 映像檔套用更新，因此我們無法依賴不可變更的基礎架構來執行修補作業和重大版本更新。如果是平台升級，我們會先在開發和預備環境中測試及驗證修補程式或主要版本，然後再連同 GDC 版本發布獨立升級套件。如要套用修補程式及升級主要版本，操作人員會按照執行手冊連線至現有 VM 執行個體、上傳升級套件，並從每個執行中的 VM 啟動升級。

最後，系統會使用 ServiceNow API 更新集和其他使用者資料，在不中斷服務的情況下套用設定更新。我們會在開發和預先發布環境中開發及測試設定更新，然後在 GDC 發布程序中，將多個更新集封裝在一起。然後，作業人員會按照執行手冊，呼叫我們開發的指令列工具，該工具會呼叫適當的 ServiceNow API，上傳及套用更新集。

整合

識別資訊提供者

為提供客戶流暢的體驗，並協助機構導入使用者，我們將 ServiceNow 與 GDC 中提供的多個身分識別提供者整合。一般來說，企業和公部門客戶都有自己的身分提供者 (例如 Active Directory 或其他類似系統)，可授予及撤銷員工的權利。為符合法規要求並簡化身分和存取權控管作業，這些客戶希望使用現有的身分提供者做為單一事實來源，管理員工對 ServiceNow 的存取權。

ServiceNow 多用戶架構總覽

ServiceNow 透過多重身分識別提供者模組，同時支援 SAML 2.0 和 OIDC 提供者。我們已在應用程式伺服器 VM 映像檔中預先啟用這個模組。基礎架構營運人員 (IO) 和客戶都會透過機構身分識別提供者進行驗證，系統會自動在 ServiceNow 中建立使用者並指派角色。

透過 ProjectNetworkPolicy 自訂資源，系統允許連出至身分識別提供者伺服器，這會限制 GDC 中機構是否可連上外部服務。這些政策可讓我們以宣告方式控管 ServiceNow 能在網路上存取的端點。

快訊擷取

除了讓使用者登入並手動建立支援案件，我們也整合 Prometheus AlertManager，以便在系統發出快訊時建立 ServiceNow 事件。透過這項整合功能，營運人員可將我們的可觀測性和票證系統與集中式進入點連結，在 GDC 環境中分類及解決軟硬體問題。

為達成這項整合，我們自訂了開放原始碼 Kubernetes Webhook，以便接收 Prometheus 的快訊，並透過 Cloud Service Mesh 公開的 ServiceNow API 端點，管理事件的生命週期。在 ServiceNow 中建立事件後，作業人員即可啟動事件工作流程，在事件發生時進行分類和設定優先順序，並追蹤連結，在 Grafana 中查看觸發快訊的即時狀態。

API 金鑰會儲存在 GDC 密鑰存放區，並透過角色型存取權控管 (RBAC) 機制控管 Kubernetes 密鑰。其他設定 (例如 API 端點和事件自訂欄位) 則透過 Kubernetes ConfigMap 鍵/值儲存空間管理。

電子郵件

ServiceNow 提供郵件伺服器整合功能，方便客戶透過電子郵件取得支援。自動化工作流程會將收到的客戶電子郵件轉換為支援案件，並自動回覆客戶，附上案件連結，讓支援團隊更有效率地管理收件匣、有系統地追蹤及解決電子郵件要求，並提供更優質的客戶服務。

如要與 GDC 中公開的 SMTP 和 POP3 服務整合，我們會使用網路政策控管跨專案的存取權。在獨立專案中代管電子郵件元件，可將電子郵件視為服務，供其他應用程式重複使用。

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-traffic-from-service-now
spec:
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - service-now

將電子郵件公開為 Kubernetes 服務，也能提供服務探索和網域名稱解析功能，進一步將電子郵件伺服器後端與 ServiceNow 等用戶端分離。

法規遵循

稽核記錄

稽核記錄可追蹤及監控軟體使用情形，並提供系統活動記錄，有助於提升法規遵循狀態。稽核記錄會記錄未經授權的使用者嘗試存取行為、追蹤 API 使用情形，以及找出潛在的安全風險。稽核記錄符合法規遵循要求，例如《健康保險流通與責任法案》(HIPAA)、支付卡產業資料安全標準 (PCI DSS) 和《沙賓法案》(SOX) 的要求。

GDC 提供系統，可記錄平台中的管理活動和存取權，並在可設定的時間範圍內保留這些記錄。部署AuditLoggingTarget自訂資源會設定記錄管道，從應用程式收集稽核記錄。

對於 ServiceNow，我們為從 Red Hat Enterprise Linux 上的 auditd Daemon 收集的系統稽核事件，以及 ServiceNow 安全性稽核記錄產生的應用程式專屬事件，設定了稽核記錄目標。這兩種記錄檔都會傳送至集中式 Loki 執行個體，我們可以在其中編寫查詢，並在 Grafana 中查看資訊主頁。

存取權控管

存取權控管程序會根據要求存取資源的使用者或程序身分，授予或拒絕存取權。這有助於保護資料，避免未經授權的存取，並確保只有授權使用者可以變更系統。在 GDC 中，我們依賴 Kubernetes RBAC 宣告政策，並強制授權給由 ServiceNow 應用程式組成的系統資源。

在 GDC 中定義 ProjectRole，即可使用預設授權角色，授予 Kubernetes 資源的精細存取權。結合其他現有角色 (例如 VM 管理員 (vm-admin) 角色)，運算子可以繫結至一或多個角色，以便偵錯問題及執行例行維護作業。

在 GDC 中定義 ProjectRole，即可使用預設授權角色，授予 Kubernetes 資源的精細存取權。

apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectRole
metadata:
  name: service-now-admin
  labels:
    resourcemanager.gdc.goog/rbac-selector: system
spec:
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    - events
    - pods/log
    - services
    verbs:
    - get
    - list

透過 Gitlab 等基礎架構即程式碼 (IaC) 系統和設定管理等同步服務管理角色和角色繫結，運算子就能透過核准程序取得角色的臨時提升存取權。這些系統也會提供系統的限時存取權，同時維護系統變更的稽核記錄。

Runbook

執行手冊提供完成工作的逐步指南，因此對於維護符合規範的軟體應用程式至關重要。這有助於確保所有工作都正確完成，並符合所有適用法律和法規。此外，Runbook 也能確保所有團隊成員都瞭解自己的責任，以及如何完成責任。我們為 ServiceNow 撰寫了執行手冊，可執行密碼輪替、重新啟動伺服器等管理工作，以及其他標準作業程序 (SOP)。

災難復原

資料庫複製

為符合災難復原 (DR) 需求，我們在多個 GDC 執行個體中，以主要/次要設定部署 ServiceNow。在這個模式下，對 ServiceNow 的要求通常會轉送至主要網站，而次要網站則會持續複製 MariaDB 資料庫的二進位記錄檔。發生容錯移轉事件時，次要網站會升級為新的主要網站，要求也會改為傳送至新的主要網站。

MariaDB 複寫

我們以 MariaDB 複製功能為基礎，根據 Helm 部署期間設定的參數，為每個 GDC 執行個體設定主要和副本資料庫伺服器。

如要為執行時間超過二進位記錄保留期限的現有執行個體啟用複製功能，可以使用 Mariabackup 還原副本資料庫，這項工具也會記錄全域交易 ID (GTID)，以便從主要資料庫開始複製。

在主要模式中，應用程式伺服器和資料庫的運作方式與現在相同，但主要資料庫會設定為啟用複製功能。例如：

  1. 啟用二進位記錄檔。

  2. 設定伺服器 ID。

  3. 建立複製使用者帳戶。

  4. 建立包含 GTID 資訊的備份。

在副本模式下，應用程式伺服器會停用 ServiceNow 網路服務，避免直接連線至副本資料庫。副本資料庫必須設定為從主要資料庫開始複製，例如：

  1. 設定伺服器 ID。

  2. 設定複寫使用者憑證和主要連線詳細資料，例如主機和通訊埠。

  3. 從備份還原，並從 GTID 繼續執行二進位記錄檔位置。

資料庫副本必須連上網路，才能連線至主要資料庫並開始複製資料。如要公開發布主要資料庫端點以進行複製，我們可以透過 Cloud Service Mesh 建立 Istio Ingress Gateway，在 Istio Gateway 支援 TLS 終止，類似於我們處理 ServiceNow Web 應用程式 HTTPS 資料傳輸的方式。

容錯移轉程序

發生容錯移轉時，次要網站會升級為新的主要網站，要求也會改為傳送至新的主要網站。這項程序一開始是手動程序，但透過額外努力，可以逐步自動化。

在主要網站：

  1. 在應用程式伺服器上停止 ServiceNow 服務。

  2. 設定資料庫伺服器以進入副本模式。

  3. 如果應用程式伺服器使用反向 Proxy 服務，請啟動該服務。

在次要網站：

  1. 停止資料庫伺服器上的複製作業。

  2. 如果應用程式伺服器使用反向 Proxy 服務，請停止該服務。

  3. 設定主要模式的資料庫伺服器。

  4. 在應用程式伺服器上啟動 ServiceNow 服務。

在我們的執行手冊中記錄備援程序，有助於確保作業不會因發生災害而中斷，並縮短災害復原時間。