高可用性 VM アプリケーションをデプロイする

このページでは、Google Distributed Cloud（GDC）エアギャップで堅牢で高可用性（HA）の仮想マシン（VM）アプリケーションを構築するためのおすすめのデプロイ戦略について説明します。複数の GDC ゾーンに VM アプリケーションをデプロイし、非同期ストレージ レプリケーションを構成して、予期しないダウンタイムやローカル災害が発生した場合にアプリケーションとそのデータを復元できるようにする必要があります。

このページは、組織のアプリケーション ワークロードの作成を担当するアプリケーション オペレーター グループ内のデベロッパーを対象としています。詳細については、GDC エアギャップの対象読者に関するドキュメントをご覧ください。

目標

  • GDC ユニバース内の 2 つ以上のゾーンにブートディスクがアタッチされた VM インスタンスを作成します。
  • グローバル ロード バランシングを構成します。
  • ブロック ストレージまたはオブジェクト ストレージを使用して、非同期ストレージ レプリケーションを構成します。

始める前に

  • 複数のゾーンが使用可能な GDC ユニバースで作業していることを確認します。gdcloud zones list を実行して、ユニバースで使用可能なゾーンを一覧表示します。詳細については、ユニバース内のゾーンを一覧表示するをご覧ください。

  • 組織の IAM 管理者に次のロールの付与を依頼します。

    • VM ワークロードを作成して管理する VM のロール。
    • ロードバランサ管理者（load-balancer-admin）とグローバル ロードバランサ管理者（global-load-balancer-admin）のロール。ロードバランサを作成して管理するには、これらのロールが必要です。
    • ボリューム レプリケーション グローバル管理者ロール（app-volume-replication-admin-global）。ボリューム レプリケーションを管理するには、このロールが必要です。
    • グローバル PNP 管理者（global-project-networkpolicy-admin）のロール。ゾーン間でプロジェクト ネットワーク ポリシーを作成して管理するには、このロールが必要です。
    • ブロック ストレージ リソースのボリューム レプリケーション関係を管理するボリューム レプリケーション グローバル管理者（app-volume-replication-admin-global）ロール。
    • ストレージ バケットを作成して管理するプロジェクト バケット オブジェクト管理者（project-bucket-object-admin）とプロジェクト バケット管理者（project-bucket-admin）のロール。

    詳細については、ロールの説明をご覧ください。

  • gdcloud CLI をインストールして構成し、ゾーン コンテキストとグローバル コンテキストを構成します。詳細については、ゾーン間のリソースを管理するをご覧ください。

  • kubectl CLI をインストールして構成し、グローバル API サーバーと Management API サーバーに適切な kubeconfig ファイルを設定します。詳細については、kubeconfig ファイルを手動で生成するをご覧ください。

複数のゾーンに VM インスタンスを作成する

VM インスタンスはゾーンリソースであるため、各ゾーンに VM を個別に作成する必要があります。この例では、GDC 提供の OS イメージを使用して VM インスタンスを作成し、ブートディスクを VM にアタッチします。VM インスタンスの作成とカスタム イメージの使用の詳細については、VM を作成して起動するをご覧ください。

デフォルトでは、すべての GDC プロジェクトで GDC 提供の OS イメージから VM を作成できます。

コンソール

  1. ナビゲーション メニューで、[Virtual Machines] > [Instances] を選択します。
  2. [インスタンスを作成] をクリックします。
  3. [名前] フィールドに、VM の名前を指定します。
  4. VM を作成するゾーンを選択します。
  5. [ラベルを追加] をクリックして、VM にラベルを割り当て、VM インスタンスを整理します。
  6. VM に使用するマシン構成を選択します。要件に応じて、マシンタイプがワークロードと一致していることを確認します。
  7. [次へ] をクリックします。
  8. VM インスタンスの外部アクセスを有効にします。
  9. [次へ] をクリックします。
  10. [新しいディスクを追加] を選択します。
  11. VM ディスクに名前を割り当てます。
  12. ディスクサイズとアタッチメントの設定を構成します。
  13. [保存] をクリックします。
  14. [作成] をクリックして VM インスタンスを作成します。
  15. GDC ユニバースの各ゾーンに対して、上記の手順を繰り返します。HA 戦略で必要なすべてのゾーンに VM インスタンスが存在することを確認します。

gdcloud

  1. VM インスタンスをホストするゾーンにログインします。

    gdcloud config set core/zone ZONE

  2. GDC 提供のイメージを使用して、ゾーンに VM インスタンスを作成します。

    gdcloud compute instances create VM_NAME \
    --machine-type=MACHINE_TYPE \
    --image=BOOT_DISK_IMAGE_NAME
    --image-project=vm-system \
    --boot-disk-size=BOOT_DISK_SIZE \
    --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE

    次のように置き換えます。

    • VM_NAME: 新しい VM の名前。名前には英数字とダッシュのみを使用でき、53 文字以下にする必要があります。
    • MACHINE_TYPE: 新しい VM の事前定義マシンタイプ。使用可能なマシンタイプを選択するには、gdcloud compute machine-types list を実行します。
    • BOOT_DISK_IMAGE_NAME: 新しい VM ブートディスクに使用するイメージの名前。
    • BOOT_DISK_SIZE: ブートディスクのサイズ（20GB など）。この値は常に、ブートディスク イメージの minimumDiskSize 以上である必要があります。
    • NO_BOOT_DISK_AUTO_DELETE: VM インスタンスが削除されたときにブートディスクが自動的に削除されるかどうか。

  3. GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略に必要なすべてのゾーンに VM インスタンスが存在することを確認します。

API

  1. GDC 提供のイメージを使用して、ゾーンに VM インスタンスを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: VM_BOOT_DISK_NAME
  namespace: PROJECT
spec:
  source:
    image:
      name: BOOT_DISK_IMAGE_NAME
      namespace: vm-system
  size: BOOT_DISK_SIZE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  compute:
    virtualMachineType: MACHINE_TYPE
  disks:
    - virtualMachineDiskRef:
        name: VM_BOOT_DISK_NAME
      boot: true
      autoDelete: BOOT_DISK_AUTO_DELETE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  enabled: true
  ports:
  - name: port-80
    port: 80
    protocol: TCP
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: VM インスタンスを作成するゾーンの Management API サーバーの kubeconfig ファイル。Management API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
    • VM_BOOT_DISK_NAME: 新しい VM ブートディスクの名前。
    • PROJECT: VM を作成する GDC プロジェクト。
    • BOOT_DISK_IMAGE_NAME: 新しい VM ブートディスクに使用するイメージの名前。
    • BOOT_DISK_SIZE: ブートディスクのサイズ（20Gi など）。この値は常に、ブートディスク イメージの minimumDiskSize 以上である必要があります。
    • VM_NAME: 新しい VM の名前。名前には英数字とダッシュのみを使用でき、53 文字以下にする必要があります。
    • MACHINE_TYPE: 新しい VM の事前定義マシンタイプ。使用可能なマシンタイプを選択するには、gdcloud compute machine-types list を実行します。
    • BOOT_DISK_AUTO_DELETE: VM インスタンスが削除されたときにブートディスクを自動的に削除するかどうか。

  2. VM が使用可能であることを確認し、VM が Running 状態になるまで待ちます。Running 状態は、OS の準備が完全に整い、アクセス可能であることを示すものではありません。

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
    get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT

    VM_NAME と PROJECT は、VM の名前とプロジェクトに置き換えます。

  3. GDC ユニバース内の各ゾーンに対して、上記の手順を繰り返します。HA 戦略に必要なすべてのゾーンに VM インスタンスが存在することを確認します。

ロードバランサを構成する

異なるゾーンの VM 間でトラフィックを分散するには、ロードバランサを作成します。外部ロードバランサ（ELB）と内部ロードバランサ（ILB）を作成できます。どちらもゾーンまたはグローバルに構成できます。この例では、VM アプリケーションのグローバル ILB とグローバル ELB を構成します。

グローバル内部ロードバランサを作成する

内部ロードバランサ（ILB）は、組織に割り当てられた内部 IP アドレス プールから組織内のサービスを公開します。ILB サービスには、組織外のエンドポイントからアクセスできません。

次の手順に沿って、VM ワークロード用のグローバル ILB を作成します。

gdcloud

gdcloud CLI を使用して、VM ワークロードをターゲットとする ILB を作成します。

この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。Backend カスタム リソースは、ゾーンにスコープ設定する必要があります。

gcloud CLI を使用して ILB を作成するには、次の操作を行います。

  1. VM が実行されている各ゾーンにゾーン Backend リソースを作成して、ILB のエンドポイントを定義します。

    gdcloud compute backends create BACKEND_NAME \
    --labels=LABELS \
    --project=PROJECT \
    --zone=ZONE

    次のように置き換えます。

    • BACKEND_NAME: バックエンド リソースに選択した名前（my-backend など）。
    • LABELS: このバックエンド リソースに使用する VM 間のエンドポイントを定義するセレクタ（app=web など）。
    • PROJECT: プロジェクトの名前。
    • ZONE: この呼び出しに使用するゾーン。ゾーンフラグを必要とするすべてのコマンドに対してゾーンフラグをプリセットするには、gdcloud config set core/zone ZONE を実行します。ゾーンフラグは、マルチゾーン環境でのみ使用できます。このフィールドは省略可能です。

    この手順を GDC ユニバースの各ゾーンで繰り返します。

  2. ILB のグローバル ヘルスチェックを定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --check-interval=CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --timeout=TIMEOUT \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --port=PORT \
    --global

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は 5 です。このフィールドは省略可能です。
    • TIMEOUT: 障害を宣言するまでの待機時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • UNHEALTHY_THRESHOLD: エンドポイントが異常とみなされるために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。このフィールドは省略可能です。
    • PORT: ヘルスチェックが実行されるポート。デフォルト値は 80 です。このフィールドは省略可能です。

  3. グローバル BackendService リソースを作成します。

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
    --project=PROJECT \
    --target-ports=TARGET_PORTS \
    --health-check=HEALTH_CHECK_NAME \
    --global

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: バックエンド サービスの名前。
    • PROJECT: プロジェクトの名前。
    • TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは protocol:port:targetport 形式（TCP:80:8080 など）にする必要があります。このフィールドは省略可能です。
    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。

  4. 各ゾーンで、前に作成した Backend リソースに BackendService リソースを追加します。

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --backend-zone=ZONE \
    --backend=BACKEND_NAME \
    --project=PROJECT \
    --global

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: グローバル バックエンド サービスの名前。
    • ZONE: バックエンドのゾーン。
    • BACKEND_NAME: ゾーン バックエンドの名前。
    • PROJECT: プロジェクトの名前。

    この手順は、以前に作成したゾーン バックエンドごとに行います。

  5. サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部 ForwardingRule リソースを作成します。

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --cidr=CIDR \
    --ip-protocol-port=PROTOCOL_PORT \
    --load-balancing-scheme=INTERNAL \
    --project=PROJECT \
    --global

    次のように置き換えます。

    • FORWARDING_RULE_INTERNAL_NAME: 転送ルールの名前。
    • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
    • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開ポートは、実際のアプリケーションが VM 内で公開しているポートと同じである必要があります。

  6. 構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. 割り当てられた VIP を取得するには、転送ルールを説明します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. 転送ルールのフィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

    次のように置き換えます。

    • FORWARDING_RULE_VIP: 転送ルールの VIP。
    • PORT: 転送ルールのポート番号。

API

KRM API を使用して、VM ワークロードをターゲットとする ILB を作成します。この ILB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してグローバル ILB を作成する手順は次のとおりです。

  1. Backend リソースを作成して、ILB のエンドポイントを定義します。VM ワークロードが配置されているゾーンごとに Backend リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: APP_NAME
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。詳細については、ゾーン コンテキストに切り替えるをご覧ください。
    • PROJECT: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。
    • APP_NAME: VM アプリケーションの名前。

    各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

  2. ILB のグローバル ヘルスチェックを定義します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル コンテキストに切り替えるをご覧ください。
    • PROJECT: プロジェクトの名前。
    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-check など）。
    • PORT: ヘルスチェックを実行するポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒）。デフォルト値は 5 です。
    • CHECK_INTERVAL: 1 回のプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。
    • HEALTHY_THRESHOLD: エンドポイントが正常とみなされるために連続して成功しなければならないプローブの数。デフォルト値は 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントを異常とみなすために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。

  3. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。HealthCheck リソースを含めてください。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。
    • PROJECT: プロジェクトの名前。
    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。
    • BACKEND_NAME: ゾーン Backend リソースの名前。

    • ZONE: Backend リソースが存在するゾーン。backendRefs フィールドで複数のバックエンドを指定できます。次に例を示します。

      - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

      targetPorts フィールドは省略可能です。このリソースは、この BackendService リソースが変換するポートを一覧表示します。このオブジェクトを使用する場合は、次の値を指定します。

    • PORT: サービスによって公開されるポート。

    • PROTOCOL: トラフィックが一致する必要があるレイヤ 4 プロトコル。TCP と UDP のみがサポートされます。

    • TARGET_PORT: 値の変換先となるポート（8080 など）。値は、特定のオブジェクト内で繰り返すことはできません。

      targetPorts の例を次に示します。

      targetPorts:
  - port: 80
    protocol: TCP
    targetPort: 8080

  4. サービスが利用可能な仮想 IP アドレス（VIP）を定義する内部 ForwardingRule リソースを作成します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。
    • PROJECT: プロジェクトの名前。
    • FORWARDING_RULE_INTERNAL_NAME: ForwardingRuleInternal リソースに選択した名前。
    • CIDR: 転送ルールに使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
    • PORT: 転送ルールで公開するポート。ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。

    • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。

      ports:
- port: 80
  protocol: TCP

  5. 構成された ILB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. VIP を取得します。

      kubectl get forwardingruleinternal -n PROJECT

      出力は次のようになります。

      NAME           BACKENDSERVICE                  CIDR              READY
ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. 転送ルールのフィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックをテストします。

      curl http://FORWARDING_RULE_VIP:PORT

      次のように置き換えます。

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールのフィールドのポート番号。

グローバル外部ロードバランサを作成する

外部ロードバランサ（ELB）は、組織に割り当てられたプール IP アドレスから、組織外からのアクセス用にサービスを公開します。このプール IP アドレスは、より大きなインスタンス外部 IP アドレス プールから割り当てられます。

VM ワークロードのグローバル ELB を作成する手順は次のとおりです。

gdcloud

gdcloud CLI を使用して、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットとするグローバル ELB を作成します。Backend カスタム リソースはゾーンにスコープ設定する必要があります。

  1. ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy データ転送をポリシーで構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。このため、外部トラフィックがワークロード ポート（8080 など）にアクセスできるように、明示的なネットワーク ポリシーが必要です。

    この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
    • PROJECT: プロジェクトの名前。
    • CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織間のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。
    • PORT: ロードバランサの背後にある VM のバックエンド ポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPortfield フィールドにあります。このフィールドは省略可能です。

    この構成により、プロジェクト内のすべてのリソースが指定された CIDR 範囲にアクセスできるようになります。

  2. 各ゾーンに Backend リソースを作成して、ELB のエンドポイントを定義します。

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT

    次のように置き換えます。

    • BACKEND_NAME: バックエンド リソースの名前（my-backend など）。
    • LABELS: このバックエンド リソースに使用する VM 間のエンドポイントを定義するセレクタ（app=web など）。
    • PROJECT: プロジェクトの名前。

    各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

  3. ELB のグローバル ヘルスチェックを定義します。

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-check など）。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • HEALTHY_THRESHOLD: 失敗を宣言するまでの待機時間。デフォルト値は 5 です。このフィールドは省略可能です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は 5 です。このフィールドは省略可能です。
    • UNHEALTHY_THRESHOLD: エンドポイントを異常とみなすために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。このフィールドは省略可能です。
    • PORT: ヘルスチェックを実行するポート。デフォルト値は 80 です。このフィールドは省略可能です。

  4. グローバル BackendService リソースを作成します。

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: このバックエンド サービスに選択した名前。
    • PROJECT: プロジェクトの名前。
    • TARGET_PORTS: このバックエンド サービスが変換するターゲット ポートのカンマ区切りリスト。各ターゲット ポートは、プロトコル、転送ルールのポート、バックエンド インスタンスのポートを指定します。複数のターゲット ポートを指定できます。このフィールドは、TCP:80:8080 などの protocol:port:targetport 形式にする必要があります。このフィールドは省略可能です。
    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前。このフィールドは省略可能です。

  5. グローバル BackendService リソースを、前に作成したゾーン Backend リソースに追加します。

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT \
  --global

    この手順は、以前に作成したゾーン バックエンドごとに行います。

  6. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT \
  --global

    次のように置き換えます。

    • FORWARDING_RULE_EXTERNAL_NAME: 転送ルールの名前。
    • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
    • PROTOCOL_PORT: 転送ルールで公開するプロトコルとポート。このフィールドは ip-protocol=TCP:80 の形式にする必要があります。公開されるポートは、実際のアプリケーションが VM 内で公開しているポートと同じである必要があります。
    • PROJECT: プロジェクトの名前。

  7. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックを確認します。

    1. 割り当てられた VIP を取得するには、転送ルールを説明します。

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. 転送ルールの PROTOCOL_PORT フィールドで指定されたポートの VIP への curl リクエストでトラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      次のように置き換えます。

      • FORWARDING_RULE_VIP: 転送ルールの VIP。
      • PORT: 転送ルールの PROTOCOL_PORT フィールドのポート番号。

API

KRM API を使用して、VM ワークロードをターゲットとする ELB を作成します。この ELB は、Backend オブジェクトで定義されたラベルに一致するプロジェクト内のすべてのワークロードをターゲットにします。KRM API を使用してゾーン ELB を作成する手順は次のとおりです。

  1. ELB サービスが機能するには、独自のカスタマイズされた ProjectNetworkPolicy データ転送をポリシーで構成して適用し、この ELB サービスのワークロードへのトラフィックを許可する必要があります。ネットワーク ポリシーは、ロードバランサ自体ではなく、ワークロードへのアクセスを制御します。ELB はワークロードを顧客ネットワークに公開します。このため、外部トラフィックがワークロード ポート（8080 など）にアクセスできるように、明示的なネットワーク ポリシーが必要です。

    この ELB のワークロードへのトラフィックを許可する外部 CIDR アドレスを指定します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。グローバル API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
    • PROJECT: プロジェクトの名前。
    • CIDR: ELB にアクセスする必要がある外部 CIDR。このポリシーは、外部ロードバランサが Direct Server Return（DSR）を使用し、送信元外部 IP アドレスを保持して、戻りパスでロードバランサをバイパスするため必要です。詳細については、組織間のトラフィック用のグローバル上り（内向き）ファイアウォール ルールを作成するをご覧ください。
    • PORT: ロードバランサの背後にある VM のバックエンド ポート。この値は、Service リソースのマニフェストの .spec.ports[].targetPortfield フィールドにあります。このフィールドは省略可能です。

  2. Backend リソースを作成して、ELB のエンドポイントを定義します。ワークロードが配置されているゾーンごとに Backend リソースを作成します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: server
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: ゾーン Management API サーバーの kubeconfig パス。ターゲット ゾーンの API サーバーの kubeconfig ファイルをまだ生成していない場合は、kubeconfig ファイルを手動で生成するをご覧ください。
    • PROJECT: プロジェクトの名前。
    • BACKEND_NAME: Backend リソースの名前。

    各ゾーンに同じ Backend リソースを使用することも、各ゾーンに異なるラベルセットを持つ Backend リソースを作成することもできます。

  3. ELB のグローバル ヘルスチェックを定義します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    次のように置き換えます。

    • HEALTH_CHECK_NAME: ヘルスチェック リソースの名前（my-health-check など）。
    • PORT: ヘルスチェックを実行するポート。デフォルト値は 80 です。
    • TIMEOUT: 失敗を宣言するまでの待機時間（秒単位）。デフォルト値は 5 です。
    • CHECK_INTERVAL: 1 つのプローブの開始から次のプローブの開始までの時間（秒単位）。デフォルト値は 5 です。
    • HEALTHY_THRESHOLD: エンドポイントが正常とみなされるために合格しなければならないプローブの連続回数。デフォルト値は 2 です。
    • UNHEALTHY_THRESHOLD: エンドポイントを異常とみなすために連続して失敗しなければならないプローブの数。デフォルト値は 2 です。

    これはグローバル ELB であるため、グローバル API でヘルスチェックを作成します。

  4. 前に作成した Backend リソースを使用して BackendService オブジェクトを作成します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
EOF

    次のように置き換えます。

    • BACKEND_SERVICE_NAME: BackendService リソースに選択した名前。
    • HEALTH_CHECK_NAME: 以前に作成した HealthCheck リソースの名前。Pod ワークロードの ELB を構成する場合は、このフィールドを含めないでください。
    • ZONE: Backend リソースが存在するゾーン。backendRefs フィールドで複数のバックエンドを指定できます。次に例を示します。
    - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

  5. サービスが利用可能な VIP を定義する外部 ForwardingRule リソースを作成します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    次のように置き換えます。

    • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal リソースに選択した名前。
    • CIDR: 転送ルールで使用する CIDR。このフィールドは省略可能です。指定しない場合、IPv4/32 CIDR はグローバル IP アドレス プールから自動的に予約されます。この転送ルールと同じ Namespace 内の Subnet リソースの名前を指定します。Subnet リソースは、グローバル サブネットのリクエストと割り当て情報を表します。Subnet リソースの詳細については、サブネットを管理するをご覧ください。
    • PORT: 転送ルールで公開するポート。ports フィールドを使用して、この転送ルールで構成されたバックエンドにパケットが転送される L4 ポートの配列を指定します。少なくとも 1 つのポートを指定する必要があります。port フィールドを使用して、ポート番号を指定します。公開されるポートは、実際のアプリケーションがコンテナ内で公開しているポートと同じである必要があります。
    • PROTOCOL: 転送ルールに使用するプロトコル（TCP など）。ports 配列のエントリは次のようになります。
    ports:
- port: 80
  protocol: TCP

  6. 構成された ELB を検証するには、作成された各オブジェクトの Ready 条件を確認します。VIP への curl リクエストでトラフィックをテストします。

    1. プロジェクトの VIP を取得します。

      kubectl get forwardingruleexternal -n PROJECT

      出力は次のようになります。

      NAME           BACKENDSERVICE                  CIDR              READY
elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. 転送ルールの PORT フィールドで指定されたポートの VIP に curl リクエストを送信して、トラフィックを確認します。

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP:PORT は、転送ルールの VIP とポート（192.0.2.0:80 など）に置き換えます。

非同期ストレージ レプリケーションを構成する

GDC マルチゾーン ユニバースでは、障害復旧シナリオで非同期モードのボリュームやバケットなどのレプリケートされたストレージ リソースを使用できます。これらのストレージ リソース オプションは、同じリージョン内の任意の 2 つのゾーン間で非同期データ レプリケーションを提供します。非同期レプリケーションはバックグラウンドで実行され、障害が発生した場合に目標復旧時点（RPO）をゼロに近い値に設定できます。複製されたすべてのデータはオンラインで、すぐにアクセスできますが、セカンダリ ゾーンへの書き込みを有効にするには、手動のフェイルオーバー手順が必要になる場合があります。

VM アプリケーションには、次のいずれかの非同期ストレージ レプリケーション タイプを選択できます。

オブジェクト ストレージ用のデュアルゾーン バケットを作成する

オブジェクト ストレージ データは、両方のゾーンにデータが保存されている単一のバケットに書き込まれます。データはゾーン間で非同期でコピーされるため、ゾーンに同じオブジェクト バージョンが含まれていない可能性がありますが、追加の変更が行われない限り、最終的には同等になります。ボリューム レプリケーションとは異なり、レプリケートされたバケットはゾーン パーティション中に書き込み可能です。オブジェクトへの書き込みごとに異なるバージョンが生成され、接続が復元された後の最終状態は、いずれかのゾーンの最新バージョンになります。

  1. インフラストラクチャ オペレータ（IO）が BucketLocationConfig カスタム リソースを作成したことを確認します。これは、オブジェクト ストレージのゾーン間の非同期レプリケーションに必要です。このリソースは、ルート グローバル API サーバーにデプロイする必要があります。

  2. デュアルゾーンの Bucket カスタム リソースを作成します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: object.global.gdc.goog/v1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: PROJECT
spec:
  location: LOCATION_NAME
  description: Sample DZ Bucket
  storageClass: Standard
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig ファイル。
    • BUCKET_NAME: ストレージ バケットの名前。
    • PROJECT: バケットが存在するプロジェクトの名前。
    • LOCATION_NAME: バケット内のオブジェクト データが存在する物理的な場所。これは、既存の BucketLocation リソースの名前にマッピングする必要があります。組織のグローバル API サーバーに利用可能な BucketLocation リソースのリストをクエリするには、kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations を実行します。BucketLocation リソースがない場合は、IO に連絡して、非同期レプリケーションが有効になっていることを確認します。

ゾーン間の非同期ブロック ストレージ レプリケーションを構成する

レプリケートされたブロック ストレージは、プライマリ ボリュームとセカンダリ ボリューム間のブロックの同等性を維持する非同期レプリケート ボリューム（PV）を提供します。非同期であるため、セカンダリ ボリュームには過去のある時点のプライマリ ゾーンの状態が反映されます（RPO はゼロではありません）。セカンダリ ボリュームはレプリケーションのターゲットである間はマウントできません。関係を終了して書き込みを有効にするには、手動での操作が必要です。

ソースゾーンのデータが使用できなくなった場合にフェイルオーバーに使用できる複製データを作成するには、VolumeReplicationRelationship カスタム リソースをグローバル API サーバーにデプロイする必要があります。

開始する前に、インフラストラクチャ オペレーター（IO）が StorageClusterPeering カスタム リソースと StorageVirtualMachinePeering カスタム リソースを作成して構成し、ゾーン間のブロック ストレージ レプリケーションを許可していることを確認します。このリソースは、ルート グローバル API サーバーにデプロイする必要があります。

gdcloud

  1. プライマリ ゾーンとセカンダリ ゾーン間の非同期レプリケーション ボリュームの関係を設定します。

    gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
    --project PROJECT \
    --zone PRIMARY_ZONE \
    --secondary-disk SECONDARY_DISK_NAME \
    --secondary-zone SECONDARY_ZONE

    次のように置き換えます。

    • PRIMARY_DISK_NAME: レプリケートされるソースディスクの名前。
    • PROJECT: プライマリ ディスクの GDC プロジェクト。
    • PRIMARY_ZONE: プライマリ ディスクが存在するゾーン。
    • SECONDARY_DISK_NAME: レプリケート先のディスクの名前。
    • SECONDARY_ZONE: セカンダリ ディスクが配置されるゾーン。

  2. 宛先ゾーンに VolumeFailover カスタム リソースを作成します。これにより、ソースゾーンが何らかの理由で使用できない場合、宛先ゾーンへのレプリケーションが停止します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: Management API サーバーの kubeconfig ファイル。
    • FAILOVER_NAME: フェイルオーバーの名前。
    • PROJECT: ストレージ インフラストラクチャが存在するプロジェクト。
    • REPL_NAME: ボリューム レプリケーションの関係の名前。

    VM ワークロードの非同期レプリケーションの管理の詳細については、ボリュームを非同期で複製するをご覧ください。

API

  1. VolumeReplicationRelationship カスタム リソース YAML ファイルを作成し、グローバル API サーバーにデプロイします。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

    次のように置き換えます。

    • GLOBAL_API_SERVER: グローバル管理 API サーバーの kubeconfig ファイル。
    • VRR_NAME: ボリューム レプリケーション関係の名前。非同期レプリケーションを停止するときは、同じ名前を使用する必要があります。
    • PROJECT: プライマリ ディスクの GDC プロジェクト。
    • PRIMARY_DISK_NAME: レプリケートされるソースディスクの名前。
    • PRIMARY_ZONE: プライマリ ディスクが存在するゾーン。
    • SECONDARY_DISK_NAME: レプリケート先のディスクの名前。
    • SECONDARY_ZONE: セカンダリ ディスクが配置されるゾーン。

  2. 宛先ゾーンに VolumeFailover カスタム リソースを作成します。これにより、ソースゾーンが何らかの理由で使用できない場合、宛先ゾーンへのレプリケーションが停止します。

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    次のように置き換えます。

    • MANAGEMENT_API_SERVER: Management API サーバーの kubeconfig ファイル。
    • FAILOVER_NAME: フェイルオーバーの名前。
    • PROJECT: ストレージ インフラストラクチャが存在するプロジェクト。
    • REPL_NAME: ボリューム レプリケーション関係の名前。

VM ワークロードの非同期レプリケーションの管理の詳細については、ボリュームを非同期で複製するをご覧ください。

次のステップ