用語と定義

[クライアント・ロケーション]の GRS{: tag-red}

IBM Power Virtual Server プライベート・クラウドで GRSを有効にすると、プライマリ・ロケーション・インフラストラクチャとセカンダリ・ロケーション・インフラストラクチャの間でデータの非同期レプリケーションが可能になる。 この2つのインフラ拠点には、 IBM データセンター の IBM Power Virtual Server が提供する同一の機能セットがある。

プライマリ・ロケーションとセカンダリ・ロケーション間のレプリケーション用ネットワーク構成を提供する：

• ネットワーク帯域幅は10Gbps以上でなければならない。
• ネットワークの待ち時間は200ms以下でなければならない。

最初の同期では、プライマリ・ボリュームのデータ全体が補助ボリュームにコピーされる。 その後の同期では、2つの同期操作の間の変更のみがコピーされる。 効果的な復旧ポイント目標（RPO）は、基礎となるネットワーク・スループットの能力とアプリケーションの特性に依存する。 ネットワークのスループットが定義されたRPOに到達するには不十分である場合、同期間の時間は長くなる。

定義されたRPOが8時間以上超過した場合、 IBM オペレーション・チームが警告を発します。

IBM データセンター 環境の IBM Power Virtual Server と クライアント・ロケーション 環境の IBM Power Virtual Server プライベート・クラウド の VM 間では、レプリケーションはサポートされません。

GRSの価格

部品番号は、プライマリボリュームに関連するストレージ階層に基づいてGRSのコストを計算するために使用される。 詳しくは、 グローバル・レプリケーション・サービス（GRS）の価格を ご覧ください。

Power Virtual Server GRSをサポートする地域

次の表は、レプリケーションをサポートするロケーション・ペアを示している：

レプリケーション可能なロケーション名のリストを取得するには、以下のAPIまたはCLIコマンドを使用する：

• API ： 現在地の災害復旧サイトの詳細を取得する

• CLI ： ibmcloud pi disaster-recovery. --all-regions フラグを true とする。

レプリケーションに使用するプライマリおよびセカンダリのロケーションがレプリケーション・サービスで有効になっており、レプリケーション有効ペアのリストにあるかどうかを確認します。

次の例では、 wdc07 と dal10 のデータセンターがレプリケーション可能なペアになっている：

{
  "location": "dal10",
  "replicationSites": [
    {
      "ReplicationPoolMap": [
        {
          "remotePool": "General-Flash-92",
          "volumePool": "General-Flash-83"
        }
      ],
      "isActive": true,
      "location": "wdc07"
    }
  ]
}

Power Virtual Server GRSをサポートするストレージプール

レプリケーションをサポートするストレージプールからのみ、レプリケーション対応ボリュームを割り当てることができます。 レプリケーションをサポートするストレージプールを特定するには、以下のAPIまたはCLIコマンドを使用します：

• API ： リージョン内のすべての利用可能なストレージプールのストレージ容量

• CLI ： ibmcloud pi storage-pools

ストレージプールがレプリケーションをサポートしている場合、 replication-enabled プロパティは true に設定されます。

レプリケーションが有効なボリュームを作成すると、デフォルトでは、レプリケーションをサポートするストレージプールの1つ内にボリュームが作成されます。 ボリュームを更新してレプリケーションを有効にする場合は、レプリケーションをサポートするストレージプール内に作成するようにしてください。 そうでなければ、更新操作は失敗する。

GRS用ボリュームグループの作成

ボリューム・グループは Power Virtual Server で管理されるリソースである。 ボリューム・グループを使用すると、ストレージ・レプリケーション一貫性グループを有効化、無効化、および管理できます。 ボリュームグループには、災害時に復旧しなければならないボリュームが含まれる。 レプリケーション対応ボリュームをボリュームグループに追加することができます。 レプリケーションが有効なボリュームは、一度に1つのボリューム・グループにのみ属することができます。 さらに、ボリュームグループ内のすべてのボリュームは、同じストレージプールの一部でなければならない。

プライマリ・ロケーションにボリューム・グループを作成すると、プライマリおよびセカンダリ・ロケーションの両方のストレージ・バックエンドにストレージ・レプリケーション一貫性グループが作成されます。 ストレージ・レプリケーション一貫性グループは、ボリューム・グループ内のボリュームの一貫性コピーを保存する。 一貫性グループに対して何らかの操作を実行するには、その一貫性グループを表すボリューム・グループに対して操作を実行する必要があります。 Power Virtual Server は、ストレージ・バックエンドの一貫性グループを直接管理しません。 ストレージバックエンドとは、ストレージプールとストレージコントローラを含むストレージサブシステムのことである。

セカンダリロケーションにボリュームをオンボードすると、ボリュームグループがまだ作成されていない場合、ボリュームが作成され、オンボードされた補助ボリュームがそこに追加されます。 このボリューム・グループは、セカンダリ・ロケーションの Power Virtual Server。 詳細については、 補助ボリュームのオンボーディングを 参照してください。

最初のデータ同期では、プライマリ・ボリュームのデータ全体が補助ボリュームにコピーされます。 その後のデータ同期では、2つの同期操作の間の変更のみがコピーされる。 効果的な復旧ポイント目標（RPO）は、ネットワークのスループットの能力とアプリケーションの特性によって決まる。 ネットワークのスループットが定義されたRPOを満たすのに不十分な場合、データ同期間の期間が長くなる。

ボリューム・グループを使用して、ストレージ・ボリューム内のレプリケーション対応一貫性グループを有効化、無効化、管理します。 一貫性グループを使用すると、各ボリュームを個別に管理する代わりに、複数のボリュームに対して操作を実行できます。 整合性グループには、グループ内のボリュームの copy 操作の状態を示す state プロパティがあります。

ストレージ・ボリュームのレプリケーション有効整合性グループのさまざまな状態を示した以下の表を参照。

あるロケーションのボリュームグループに対して何らかの操作を行うと、他のロケーションの関連ボリュームグループにも影響します。 たとえば、ボリューム・グループがプライマリ・ロケーションで停止しているとします。 しばらくすると、セカンダリ・ロケーションの関連ボリューム・グループが更新され、ボリューム・グループ内のペアのレプリケーション・ステータスが反映される。 この場合、 replicationStatus フィールドには、プライマリおよびセカンダリロケーションの両方でボリュームグループの状態が disabled と表示されます。

あるロケーションのボリュームグループに対して操作を実行する前に、プライマリロケーションとセカンダリロケーションの両方のボリュームグループのレプリケーションステータスを確認してください。

機能が類似しているレプリケーション有効ボリュームをグループ化することができます。 たとえば、特定のワークロードに関連するボリュームは、1つのボリュームグループにまとめることができます。 レプリケーション対応ボリュームを追加作成する場合、機能に基づいて、類似ボリュームのある既存のボリュームグループにボリュームを追加できます。 ボリュームの機能が既存のボリュームと同じでない場合は、新しいボリュームグループを作成することができます。

災害復旧の準備

ワークロードを実行しているデータボリュームを持つ仮想サーバーインスタンスがあるとする。 障害が発生し、データボリュームがレプリケートされている場合、セカンダリロケーションからデータボリュームをリカバリすることができます。 ボリューム・レプリケーション・サービスを有効にするには、以下の手順を実行します：

• プライマリー・サイトでの措置
• セカンダリー・サイトでの行動

セカンダリ・サイトのアクションを実行する前に、プライマリ・サイトのアクションを完了する必要があります。

フェイルオーバーとフォールバックの実行

プライマリ・ロケーションで災害が発生した場合、プライマリ・ロケーションに割り当てられているすべてのストレージ・ボリュームへのアクセスが失われる。 レプリケーションが有効なプライマリボリュームのレプリケーション関係が、セカンダリロケーションとの間で壊れています。 整合性グループ（ボリュームグループ）の状態が inconsistent-disconnected に変わります。 プライマリロケーションでは、ボリュームグループのプライマリロールにボリュームが関連付けられていません。

以下の手順を実行して、セカンダリ・ロケーションでフェイルオーバー処理を実行します：

1. 補助ボリュームグループを停止し、セカンダリロケーションの補助ボリュームにアクセスします。 セカンダリー・ロケーションへのフェイルオーバー
2. 補助ボリュームグループがアイドル状態であることを確認する。

フェイルオーバーの手順を完了すると、ボリュームはI/O要求を受け付ける準備が整います。 これらのボリュームがアタッチされている仮想サーバーインスタンスはパワーオンでき、実行を続行できる。

    Request Body:
    {
      "start": {
        "source": "aux"
      }
    }

    Request Body:
    {
      "stop": {
        "access": true
      }
    }

    Request Body:
    {
      "start": {
        "source": "master"
      }
    }

既存のボリュームをレプリケーション対応ボリュームとして更新する

レプリケーション・プロセスをサポートするストレージ・プール内に作成された既存のボリュームを、レプリケーション対応に変更することができます。 検証するには、ボリュームの詳細を照会し、そのボリュームを含むストレージ・プールの詳細を取得し、レプリケーションをサポートするストレージ・プールのリストで検証する。 レプリケーションをサポートするストレージプールの詳細については、 Power Virtual Server GRSをサポートするストレージプールを 参照してください。

ボリュームの詳細を照会するには、以下のAPIおよびCLIコマンドを使用します：

• API ： ボリュームグループに対してアクションを実行 します。 VOLUME_ID パラメータにプライマリ・ボリュームIDを設定する。 APIを使用して、以下のコードで定義されているようにボリュームの詳細を照会する：

    Request Body:
    {
      "replicationEnabled": true
    }

• CLI: ibmcloud pi volume-group action. VOLUME_ID パラメータにプライマリ・ボリュームIDを設定し、 --replication-enabled フラグが True に設定されているかどうかを問い合わせる。

既存のボリュームグループへのレプリケーション対応ボリュームの追加

以下のAPIおよびCLIコマンドを使用して、既存のボリュームグループにレプリケーション対応ボリュームを追加できます：

• API ： ボリュームグループを更新 します。 VOLUME_GROUP_ID パラメータにプライマリ・ボリューム・グループIDを設定する。 APIを使用して、以下のコードで定義されているように、プライマリ・ボリュームIDをボリューム・グループに追加する：

    Request Body:
    {
      "addVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

• CLI: ibmcloud pi volume-group update。 VOLUME_GROUP_ID パラメータにプライマリ・ボリューム・グループIDを設定し、 --add-member-ids フラグにボリューム・グループに追加する必要があるプライマリ・ボリュームIDを設定する。

ボリュームのレプリケーションを無効にする

プライマリ・ボリュームのレプリケーションを無効にすると、セカンダリ・ロケーション上の関連する補助ボリュームが削除されます。

指定された順序でこの手順を完了しないと、ソース・ボリュームのデータが失われる可能性があります。 まず、プライマリ・ロケーションのアクションを完了させ、次にセカンダリ・ロケーションのアクションを完了させる必要があります。

プライマリ・ボリュームのレプリケーションを無効にするには、以下の手順を実行します：

1. プライマリー・ロケーションでの行動

   1. ボリュームグループからプライマリボリュームを削除する
   2. プライマリ・ボリューム・グループが空の場合は削除する
   3. プライマリ・ボリュームのレプリケーションを無効にする
   4. プライマリ・ボリュームでレプリケーションが無効になっていないか確認する

2. セカンダリーロケーションでのアクション

これらの手順は、補助ボリュームのオンボーディング操作が完了した場合にのみ実行できます。

1. ボリュームグループから補助ボリュームを削除する
2. 空の場合、補助ボリュームグループを削除する
3. 補助ボリュームの削除

    Request Body:
    {
      "removeVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

    Request Body:
    {
      "replicationEnabled": false
    }

    Request Body:
    {
      "removeVolumes": [
        "AUXILIARY_VOLUME_ID"
      ]
    }

レプリケーション対応プライマリボリュームの変更

レプリケーションが有効なプライマリ・ボリュームの属性を変更できます。 プライマリおよび補助ボリュームのプロパティの一部を変更するには、プライマリおよびセカンダリロケーションで関連するアクションを実行する必要があります。

  Request Body:
  {
    "size": SIZE_IN_GB
  }

プライマリ・ボリュームのブート可能および共有可能プロパティの変更

プライマリ・ボリュームの bootable または shareable プロパティの値を変更するには、以下のAPIまたはCLIコマンドを使用します：

• API ： クラウドインスタンスボリュームを更新 します。 VOLUME_ID パラメータをプライマリ・ボリュームIDに設定し、 --bootable または --shareable フラグを True または False 値に設定する。

• CLI: ibmcloud pi ボリューム更新。 VOLUME_ID パラメータの値をプライマリ・ボリュームIDに設定し、 --bootable または --shareable フラグの値を True または False 値に設定する。

ボリュームは共有可能かブート可能かのどちらかであるが、両方にはできない。

プライマリ・ロケーションのプライマリ・ボリュームの bootable または shareable プロパティ値を変更した後、セカンダリ・ロケーションの補助ボリュームの同じプロパティを更新する必要があります。

プライマリボリュームの階層を変更する

レプリケーション有効ボリュームの階層を変更することはできません。

レプリケーション対応プライマリボリュームの削除

ボリュームまたはレプリケーション対応のプライマリ・ボリュームを削除するには、ボリュームのステータスが次のいずれかの状態を示している必要があります： available error, error_restoring, error_extending, または error_managing。 また、ボリュームが migrating または attached の状態にある場合、ボリュームグループに属している場合、スナップショットがある場合、または転送後にスナップショットから切り離された場合は、ボリュームを削除できません。

プライマリボリュームを削除するには、プライマリおよびセカンダリロケーションの操作を完了する必要があります：

• プライマリ・ロケーションで以下のアクションを完了する：

  1. プライマリボリュームがボリュームグループに関連付けられている場合、そのボリュームグループからプライマリボリュームを削除する。
  2. プライマリボリュームを削除する

• 補助ボリュームがセカンダリロケーションにオンボードされている場合は、セカンダリロケー ションで以下の操作を完了します：

  1. 補助ボリュームがボリュームグループに関連付けられている場合、そのボリュームグループから補助ボリュームを削除する。
  2. 補助ボリュームの削除

補助ボリュームがセカンダリサイトから削除されない場合、24時間ごとに発生する帯域外の定期チェックによって、補助ボリュームが ERROR 状態に設定されます。 ボリュームが ERROR の状態ではボリュームを使用することはできず、できる操作はボリュームの削除のみです。

    Request Body:
    {
      "removeVolumes": [
        "PRIMARY_VOLUME_ID"
      ]
    }

レプリケーション対応の補助ボリュームの削除

補助ボリュームを削除すると、関連するプライマリ・ボリュームも削除されます。

プライマリ・ボリュームのレプリケーション・サービスを無効に するか、 プライマリ・ボリュームを削除 すると、ストレージ・バックエンドでプライマリ・ボリュームとセカンダリ・ボリューム間のレプリケーション関係が削除されます。 セカンダリロケーションの補助ボリュームがボリュームグループに関連付けられている場合は、 ボリュームグループから補助ボリュームを削除 します。 補助ボリュームを手動で削除します。 セカンダリサイトから補助ボリュームを削除しない場合、24時間ごとに発生する帯域外の定期チェックによって、補助ボリュームが ERROR 状態に設定されます。 補助ボリュームの outOfBandDeleted プロパティを確認して、補助ボリュームの状態を確認する。

GRSが他の Power Virtual Server 業務に与える影響

他のPower Virtual Server操作に対するGRSの影響は以下の通りである：

• イメージ・インターフェースは変更されず、イメージのレプリケーションはサポートされない
• 仮想サーバーインスタンスのストレージプールの操作インターフェイスおよびアフィニティポリシーに変更はありません。 レプリケーションおよび非レプリケーション対応ボリュームは、ボリュームの接続と切り離しをサポートします。
• スナップショット操作とキャプチャー操作は、ボリュームが同じストレージ・プールからのものである場合に、複製ボリュームと非複製対応ボリュームを持つ仮想サーバー・インスタンスに対して許可されます。 スナップショット操作およびキャプチャー操作は、仮想サーバー・インスタンスのボリュームが複製に対応している場合でも、複製に対応していないボリュームを内部で使用することによって実行されます。
• デフォルトでは、レプリケーション可能なボリュームをクローンすると、クローンされたボリュームはレプリケーション可能になります。 クローン作成中に、クローン作成ボリュームをレプリケーション可能にするかどうかを指定できます。 クローン ボリュームをレプリケーション可能にする場合は、クローン ボリュームのポリシーを指定します。 ボリュームのクローンを作成するには、以下の方法を使用できます：
  • APIを使用してボリュームをクローンします。
  • CLIを使用してボリュームをクローンする。
  • Terraformを使ってボリュームをクローンする。

GRSのベストプラクティス

• 必要に応じて、オンボードボリュームに明示的に Shareable フラグと Bootable フラグを設定する。
• プライマリボリュームとボリュームグループが一貫したコピー状態にある場合にのみ、補助ボリュームのオンボーディングを開始する。 get volume API を使用してボリュームの詳細を取得し、プライマリ サイトのミラーリング状態におけるプライマリ ボリュームとボリューム グループの状態を確認できます。 ボリューム グループ API のストレージ詳細取得を使用して、ボリューム グループが正常に作成され、一貫したコピー状態にあることを確認します。

• 以下の方法でボリュームの詳細を入手する：
  • パワークラウドAPI。
  • テラフォーム.
• 以下の方法で、ボリュームグループのストレージの詳細を取得する：
  • パワークラウドAPI。
  • 仮想サーバーCLI
  • テラフォーム.

• ボリュームグループからプライマリボリュームまたは補助ボリュームを1つの場所から追加または削除する場合は、データを同期させるために、もう1つの場所から同じ操作を実行します。
• プライマリとセカンダリの場所からボリュームを削除する。 補助ボリュームを削除し、プライマリボリュームを削除しなかった場合、ボリュームは課金されます。
• すべてのボリューム操作にプライマリ・ロケーションを使用し、フェイルオーバー時のみセカンダリ・ロケーションで補助ボリュームに対する操作を実行する。