VM ワークロードのデプロイの概要

このガイドでは、VM ランタイムを使用して、ベアメタル上の Google Distributed Cloud（GDC）エアギャップクラスタに仮想マシン（VM）ベースのワークロードをデプロイするために必要な概念的なコンテキストについて説明します。このガイドのワークロードは、オンプレミスハードウェアで使用できる ServiceNow プラットフォームのサンプルです。

アーキテクチャ

リソース階層

GDC では、ServiceNow を構成するコンポーネントを、顧客組織と同じように、運用チーム専用のテナント組織にデプロイします。組織は、まとめて管理されるクラスタ、インフラストラクチャリソース、アプリケーションワークロードの集合です。GDC インスタンス内の各組織は専用のサーバーセットを使用するため、テナント間の分離が強化されます。インフラストラクチャの詳細については、アクセス境界を設計するをご覧ください。

GDC エアギャップリソース階層

また、ServiceNow リソースをプロジェクトにまとめてデプロイして管理することで、ソフトウェアポリシーと適用を使用して組織内の論理的な分離を実現できます。プロジェクト内のリソースは、ライフサイクルを通じて一緒に維持する必要があるコンポーネントを結合することを目的としています。

ServiceNow は、ロードバランサを使用して、永続データを保存するデータベースサーバーに接続するアプリケーションサーバー間でトラフィックを転送する 3 層アーキテクチャを採用しています。

このアーキテクチャでは、各階層を個別に開発して維持できるため、スケーラビリティと保守性が向上します。また、関心の分離が明確になるため、デバッグやトラブルシューティングが簡素化されます。これらの階層を GDC プロジェクト内にカプセル化すると、アプリケーションサーバーやデータベースサーバーなどのコンポーネントをまとめてデプロイして管理できます。

ネットワーキング

本番環境で ServiceNow を実行するには、ノード障害が発生した場合に高可用性を実現するために、2 つ以上のアプリケーションサーバーをデプロイする必要があります。このトポロジでは、ロードバランサと組み合わせて、複数のマシンに負荷を分散してアプリケーションを水平方向にスケーリングすることもできます。GDC の Kubernetes ネイティブプラットフォームは、Cloud Service Mesh を使用して、ServiceNow を構成するアプリケーションサーバーにトラフィックを安全にルーティングします。

Cloud Service Mesh は、オープンソースの Istio プロジェクトに基づく Google の実装で、サービスの管理、監視、保護を行います。Cloud Service Mesh の次の機能を利用して、GDC で ServiceNow をホストします。

ロードバランシング: Cloud Service Mesh は、トラフィックフローとインフラストラクチャのスケーリングを分離し、動的リクエストルーティングなどのさまざまなトラフィック管理機能を利用できるようにします。ServiceNow には永続的なクライアント接続が必要なため、DestinationRules を使用してスティッキーセッションを有効にし、トラフィックルーティングの動作を構成します。

TLS 終端: Cloud Service Mesh は、TLS 証明書を使用して上り（内向き）ゲートウェイを公開し、アプリケーションコードを変更することなく、mTLS（Mutual Transport Layer Security）を介してクラスタ内のトランスポート認証を提供します。
障害復旧: Cloud Service Mesh には、タイムアウト、サーキットブレーカー、アクティブヘルスチェック、制限付き再試行など、重要な障害復旧機能が多数用意されています。

Kubernetes クラスタ内では、標準の Service オブジェクトを使用して、アプリケーションサーバーとデータベースサーバーをネットワークに公開します。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 は、オンプレミスインストールをホストするためにベアメタルまたは仮想マシンのいずれかを使用することを推奨しています。Google は、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

ゲスト OS イメージについては、コンプライアンスとセキュリティの要件を満たすために、Red Hat Enterprise Linux に基づいてカスタムイメージを作成しました。VirtualMachineAccessRequest を使用して SSH 経由で実行中の VM インスタンスに接続できます。これにより、Kubernetes RBAC を介して VM への接続機能を制限し、カスタムイメージにローカルユーザーアカウントを作成する必要がなくなります。アクセスリクエストでは、有効期間（TTL）も定義します。これにより、時間ベースのアクセスリクエストで、自動的に有効期限が切れる VM を管理できます。

自動化

このプロジェクトの重要な成果物として、大規模な自動化をサポートし、デプロイ間の構成のずれを減らすことができる、ServiceNow のインスタンスを繰り返しインストールするアプローチを設計しました。

Helm パッケージ

Helm は、アプリケーションを構成するすべてのコンポーネントのインストールやアップグレードなど、アプリケーションのライフサイクルを管理する Kubernetes 用のパッケージマネージャーです。Helm には、オブザーバビリティやコンプライアンスなどの他のシステムとの統合に必要なカスタムリソースなど、依存関係を管理する方法も用意されています。Helm チャートを作成すると、これらのリソースをカプセル化できるため、ServiceNow のインストールと管理のプロセスが簡素化されます。

リリースパイプライン

アプリケーションサーバーイメージとデータベースサーバーイメージのカスタマイズは、ベースオペレーティングシステムイメージから始まり、各サーバーイメージに必要な依存関係をインストールするために必要に応じてベースイメージを変更します。Red Hat Enterprise Linux（RHEL）は、オンプレミスインストールで ServiceNow をホストするために広く採用されているため、ベース OS イメージとして選択しました。Red Hat Enterprise Linux には、NIST-800-53 制御を満たす準拠イメージの提供に必要な Security Technical Implementation Guides（STIG）を満たすために必要なセキュリティ強化機能も用意されています。

継続的インテグレーション（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）のベースラインを確立するためにも使用できます。

モニタリング

ロギングや指標など、既存の GDC オブザーバビリティインフラストラクチャと ServiceNow を統合しました。指標については、各 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 に送信しました。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 内のアプリケーション障害モードに焦点を当てました。アプリケーション内の問題のデバッグでは、各アプリケーションサーバー VM にセキュアシェル（SSH）を使用して ServiceNow システムログを確認する必要があることが多いため、これらのログを Loki に転送するように FluentBit を構成し、GDC オブザーバビリティスタックを構築して、Grafana で ServiceNow のすべての運用ログをクエリできるようにしました。

一元化されたロギングにより、複数の VM から同時にログをクエリできるようになり、システム内の各コンポーネントのビューを統合できました。次に、ログ検索クエリをランブックに組み込み、オペレーターがエラー条件を既知の回避策や解決策と照合できるようにしました。

バックアップ

バックアップは、障害が発生した場合にシステムを復元できるため、ソフトウェアシステムの運用性にとって重要です。GDC は、Kubernetes リソースを介して VM のバックアップと復元を提供します。VirtualMachineBackupPlanTemplate カスタムリソースを使用して VirtualMachineBackupRequest カスタムリソースを作成すると、各 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 とその依存関係のソフトウェアライフサイクルをサポートするために、3 種類のソフトウェアアップグレードを特定しました。ダウンタイムとサービスの中断を最小限に抑えるため、それぞれを少しずつ異なる方法で処理します。

OS のアップグレード。
パッチバージョンやメジャーバージョンなどのプラットフォームアップグレード。
構成の更新。

OS のアップグレードでは、アプリケーションサーバーとデータベースサーバーの両方に対して新しい VM イメージを継続的にビルドしてリリースします。これらのイメージは、各 GDC リリースで配布されます。これらのイメージには、セキュリティの脆弱性の修正と、基盤となる Red Hat オペレーティングシステムのアップデートが含まれています。新しいイメージをデプロイするには、オペレーターは、新しい VM のアップロードと起動、構成の検証、以前のインスタンスの廃止に必要な手順を詳しく説明するランブックに従います。

ServiceNow プラットフォームのアップグレードでは、既存の VM イメージに更新を適用する必要があるため、パッチ適用とメジャーリリースバージョンの更新に不変インフラストラクチャを使用することはできません。プラットフォームのアップグレードでは、パッチまたはメジャーリリースバージョンを開発環境とステージング環境でテストして検証してから、GDC リリースとともにスタンドアロンのアップグレードパッケージをリリースします。パッチとメジャーバージョンのアップグレードを適用するには、オペレーターはランブックに従って既存の VM インスタンスに接続し、アップグレードパッケージをアップロードして、実行中の各 VM からアップグレードを開始します。

最後に、更新セットやその他のユーザーデータ用の ServiceNow API を使用して、ダウンタイムなしで構成の更新が適用されます。構成のアップデートは、開発環境とステージング環境で開発とテストを行い、GDC リリースプロセスで複数のアップデートセットをまとめてパッケージ化します。オペレーターは、ランブックに沿って、適切な ServiceNow API を呼び出して更新セットをアップロードして適用する、Google が開発したコマンドラインツールを呼び出します。

統合

ID プロバイダ

お客様にシームレスなジャーニーを提供し、組織がユーザーをオンボーディングできるようにするため、ServiceNow を GDC で利用可能な複数の ID プロバイダと統合します。通常、企業や公共部門のお客様は、従業員に利用資格を付与したり取り消したりするために、Active Directory などのシステムを独自に管理しています。コンプライアンス要件と ID およびアクセスガバナンスの容易さから、これらの顧客は既存の ID プロバイダを信頼できる情報源として使用し、ServiceNow への従業員のアクセスを管理したいと考えています。

ServiceNow マルチテナンシーの概要

ServiceNow は、マルチ ID プロバイダモジュールを介して SAML 2.0 と OIDC の両方のプロバイダをサポートしています。このモジュールは、アプリケーションサーバー VM イメージで事前に有効になっています。インフラストラクチャオペレーター（IO）とお客様は、組織の ID プロバイダを介して認証を行います。これにより、ServiceNow 内でユーザーが自動的に作成され、ロールが割り当てられます。

ID プロバイダサーバーへの下り（外向き）は ProjectNetworkPolicy カスタムリソースで許可されます。これにより、GDC の組織から外部サービスにアクセスできるかどうかが制限されます。これらのポリシーを使用すると、ServiceNow がネットワーク上でアクセスできるエンドポイントを宣言的に制御できます。

アラートの取り込み

ユーザーがログインして手動でサポートケースを作成できるようにするだけでなく、Prometheus AlertManager と統合して、システムアラートに応じて ServiceNow インシデントを作成することもできます。この統合により、オペレーターはオブザーバビリティシステムとチケット発行システムを一元化されたエントリポイントに接続して、GDC 環境内のソフトウェアとハードウェアの問題をトリアージして解決できます。

この統合を実現するために、オープンソースの Kubernetes Webhook をカスタマイズして、Prometheus からアラートを受信し、Cloud Service Mesh を介して公開された ServiceNow API エンドポイントを使用してインシデントのライフサイクルを管理しました。ServiceNow でインシデントが作成されると、オペレーターはインシデントワークフローを開始して、インシデントの発生時にインシデントを分類して優先順位を付け、リンクをたどって Grafana でアラートのライブステータスを確認できます。

API キーは、ロールベースアクセス制御（RBAC）で制御される Kubernetes シークレットによってバックアップされた GDC シークレットストアを使用して保存されます。API エンドポイントやインシデントのカスタマイズフィールドなどの他の構成は、Kubernetes ConfigMap の Key-Value ストレージで管理されます。

メール

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 Service として公開すると、サービスディスカバリとドメイン名解決も提供され、メールサーバーのバックエンドと ServiceNow などのクライアントがさらに分離されます。

コンプライアンス

監査ロギング

監査ログは、ソフトウェアの使用状況を追跡してモニタリングし、システムアクティビティの記録を提供することで、コンプライアンス体制に貢献します。監査ログは、権限のないユーザーによるアクセス試行を記録し、API の使用状況を追跡し、潜在的なセキュリティリスクを特定します。監査ログは、医療保険の相互運用性と説明責任に関する法律（HIPAA）、ペイメント・カード情報に関するセキュリティ基準（PCI DSS）、サーベンスオクスリー法（SOX）などのコンプライアンス要件を満たしています。

GDC は、プラットフォーム内の管理アクティビティとアクセスを記録し、これらのログを構成可能な期間保持するシステムを提供します。AuditLoggingTarget カスタムリソースをデプロイすると、アプリケーションから監査ログを収集するようにロギングパイプラインが構成されます。

ServiceNow の場合、Red Hat Enterprise Linux の auditd デーモンから収集されたシステム監査イベントと、ServiceNow セキュリティ監査ログによって生成されたアプリケーション固有のイベントの両方に対して、監査ロギングターゲットを構成しました。どちらのタイプのログも、一元化された Loki インスタンスに送信されます。ここで、クエリを作成し、Grafana でダッシュボードを表示できます。

アクセス制御

アクセス制御とは、アクセスをリクエストするユーザーまたはプロセスの ID に基づいて、リソースへのアクセスを許可または拒否するプロセスです。これにより、データが不正アクセスから保護され、承認されたユーザーのみがシステムを変更できるようになります。GDC では、Kubernetes RBAC を使用してポリシーを宣言し、ServiceNow アプリケーションで構成されるシステムリソースに対する認可を適用します。

GDC で ProjectRole を定義すると、事前設定された認可ロールを使用して Kubernetes リソースへのきめ細かいアクセス権を付与できます。VM 管理者（vm-admin）ロールなどの他の既存のロールと組み合わせることで、オペレーターは 1 つ以上のロールにバインドして、問題をデバッグし、定期メンテナンスを実行できます。

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 などの Infrastructure as Code（IaC）システムと、Config Management などの同期サービスを使用してロールとロールバインディングを管理することで、オペレーターは承認プロセスを通じてロールへの一時的な昇格アクセスを取得できます。また、システム変更の監査ログを維持しながら、システムへの時間制限付きアクセスも提供します。

ランブック

ランブックは、タスクを完了するための手順ガイドを提供するため、準拠したソフトウェアアプリケーションを維持するために重要です。これにより、すべてのタスクが正しく完了し、適用されるすべての法律や規制を遵守していることを確認できます。ランブックは、すべてのチームメンバーが自分の責任範囲とそれを完了する方法を認識していることを確認するうえでも役立ちます。ServiceNow のランブックを作成し、パスワードのローテーションやサーバーの再起動などの管理タスクや、その他の標準作業手順書（SOP）を実行しました。

障害復旧

データベースレプリケーション

障害復旧（DR）の要件を満たすため、複数の GDC インスタンスにまたがるプライマリ / セカンダリ構成で ServiceNow をデプロイします。このモードでは、ServiceNow へのリクエストは通常プライマリサイトに転送され、セカンダリサイトは MariaDB データベースのバイナリログを継続的に複製します。フェイルオーバーイベントが発生すると、セカンダリサイトが新しいプライマリサイトに昇格し、リクエストが新しいプライマリに転送されます。

MariaDB レプリケーション

MariaDB レプリケーション機能に基づいて、Helm デプロイ時に設定されたパラメータに基づいて、GDC インスタンスごとにプライマリデータベースサーバーとレプリカデータベースサーバーの両方を構成します。

バイナリログの保持期間よりも長く実行されている既存のインスタンスでレプリケーションを有効にするには、Mariabackup を使用してレプリカデータベースを復元します。これにより、グローバルトランザクション ID（GTID）も記録され、プライマリデータベースからのレプリケーションが開始されます。

プライマリモードでは、アプリケーションサーバーとデータベースは現在と同じように動作しますが、レプリケーションを有効にするようにプライマリデータベースが構成されます。次に例を示します。

バイナリログを有効にします。
サーバー ID を設定します。
レプリケーションユーザーアカウントを作成します。
GTID 情報を含むバックアップを作成します。

レプリカモードでは、アプリケーションサーバーは ServiceNow ウェブサービスを無効にして、レプリカデータベースに直接接続しないようにします。レプリカデータベースは、プライマリデータベースからのレプリケーションを開始するように構成する必要があります。例:

サーバー ID を設定します。
レプリケーションユーザーの認証情報と、ホストやポートなどのプライマリ接続の詳細情報を構成します。
バックアップからの復元で、GTID からバイナリログの位置を再開します。

データベースレプリケーションでは、レプリカがプライマリデータベースに接続してレプリケーションを開始するために、ネットワーク接続が必要です。レプリケーション用にプライマリデータベースエンドポイントを公開するには、Cloud Service Mesh を使用して、Istio ゲートウェイで TLS 終端をサポートする Istio Ingress Gateway を作成します。これは、ServiceNow ウェブアプリケーションで HTTPS データ転送を処理する方法と似ています。

フェイルオーバー手順

フェイルオーバーが発生すると、セカンダリサイトが新しいプライマリサイトに昇格し、リクエストは新しいプライマリに転送されます。このプロセスは最初は手動の手順ですが、追加の作業を行うことで自動化を進めることができます。

プライマリサイトで、次のようにします。

アプリケーションサーバーで ServiceNow サービスを停止します。
レプリカモード用にデータベースサーバーを構成します。
アプリケーションサーバーで使用されている場合は、リバースプロキシサービスを開始します。

セカンダリサイト:

データベースサーバーでレプリケーションを停止します。
アプリケーションサーバーで使用されている場合は、リバースプロキシサービスを停止します。
プライマリモード用にデータベースサーバーを構成します。
アプリケーションサーバーで ServiceNow サービスを開始します。

ランブックに記載されているフェイルオーバー手順を導入することで、障害発生時にオペレーションが中断されないようにし、障害からの復旧にかかる時間を短縮できます。

VM ワークロードのデプロイの概要 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。