今回は、Portworx のコンテナのディザスタ・リカバリ機能を提供する PX-DR の非同期レプリケーション機能についてご説明します。同期レプリケーション機能については、こちらのブログご覧ください。本ブログは、テクニカル・マーケティング・マネージャーのライアン・ウォルナー（Ryan Wallner）による記事を参考に、わたくし溝口が日本語化および加筆、再構成したものです。
なお、PX-DR は 30 日間のトライアル・ライセンスには含まれません。もし、PoC をご検討いただける場合は、sales-japan@purestorage.com までお問い合わせください。
非同期レプリケーション
同期レプリケーションに関するブログでご説明したとおり、データベースのようなステートフル・アプリケーションを Kubernetes プラットフォームで実行しようとする場合には、データ保護の問題が発生します。PX-DR は、主に同期レプリケーションと非同期レプリケーションという 2 つの方法でこれらの問題を解決します。
非同期レプリケーションは、2 つの異なる Portworx クラスタを地理的に異なるエリアに配置し、それらをクラスタ・ペアにします。スタンバイ・サイトでは、継続的に非同期にレプリケーションをスケジューリングして、定義された RPO（目標復旧時点）および RTO の条件のもと、ディザスタ・リカバリ先のクラスタとして動作します。
ボリュームの非同期レプリケーションの設定
非同期レプリケーションには 2 つの Portworx クラスタを使用します。このうち 1 つのクラスタは DR サイトです。クラスタ・ペアは PX-DR の 2 つのクラスタ間で作成されます。クラスタがペアリングされた後、非同期レプリケーションは、スケジュール・ポリシーとマイグレーション・スケジュールの 2 つを使用して実施されます。
スケジュール・ポリシー
スケジュール・ポリシーは、マイグレーションをトリガーするタイミングを指定します。ポリシー自体にはアクションは含まれていませんが、マイグレーション機能によって参照および使用されます。
スケジュール・ポリシーには 4 つのセクションがあります。
- インターバル（
interval）：アクションがトリガーされる間隔を分単位で指定します。 - 日次（
daily）：アクションが毎日トリガーされる時刻を指定します。 - 週次（
weekly）：アクションがトリガーされる曜日と、その日の時刻を指定します。 - 月次（
monthly）：アクションがトリガーされる月の日付と、その日の時刻を指定します。
以下に mysql という名前空間（namespace）を対象として、インターバル、日次、週次および月次で DR サイトと同期する設定例を示します。
[crayon-67f65b61e3d2f621687780/]
マイグレーション・スケジュール
マイグレーション・スケジュールにより、SchedulePolicy とマイグレーションを関連付けることができます。以下は、上記の testpolicy を使用した例です。このマイグレーションは mysql という名前空間を指し、その名前空間で remotecluster という名前の clusterPair（後述）が存在する場合、それを使用します。また、includeResources、includeVolumes および、startApplications を spec の中で指定することでマイグレーションを制御できます。
includeResources：Secret、ConfigMaps、Service など、ボリュームに関連付けられた Kubernetes オブジェクトを含めるかどうか。includeVolumes：PVC に関連付けられた Portworx ボリュームのマイグレーションを含めるかどうか。startApplications：リソースやボリュームが同期した後、Destination クラスタでアプリケーションを開始するかどうか。
[crayon-67f65b61e3d3c392585669/]
Kubernetes ディザスタ・リカバリのワークフロー例
では、Portworx で Google Kubernetes Engine（GKE） を使用して、2 つのサイト間で DR サイトの非同期レプリケーションを設定してみましょう。
以下のゾーンでクラスタを作成しました。us-east4-c に存在するクラスタは、DR サイトです。
- クラスタ 1：米国サウスカロライナ州モンクスコーナーのゾーン D、別名 us-east1-d
- クラスタ 2：米国バージニア州北部アッシュバーンのゾーン C、別名 us-east4-c（DR サイト）
クラスタ 1 とクラスタ 2 をペアにするには、DR 側のクラスタ（以降、「宛先クラスタ」）からトークンを取得し、ソース・クラスタがアクセス可能な宛先クラスタの Portworx ノードの IP アドレスを少なくとも 1 つ用意します。
[crayon-67f65b61e3d40979249689/]
宛先クラスタで storkctl を使用して、DR を行う名前空間の clusterpair を生成します。
[crayon-67f65b61e3d44849061459/]
出力を pair.yaml という名前のファイルに保存し、Portworx のノード IP と、先に取得したトークンを追加します。詳細は、同期レプリケーションに関するブログの「手順 2. ClusterPair」をご参照ください。
次に、pair.yaml をソース・クラスタに適用し、状態が Ready であることを確認します。
[crayon-67f65b61e3d46448814254/]
これでクラスタがペアになったので、アプリケーションの非同期レプリケーションを設定できます。MySQL データベースを使用してこれを行う方法を以下に示します。
まず、先に作成した clusterpair がターゲットとする mysql という名前の名前空間を作成します。
[crayon-67f65b61e3d4c505625474/]
次に、Portworx ボリュームと MySQL ポッドを含む MySQL デプロイメントを適用します。
[crayon-67f65b61e3d4e259580680/]
pxctl コマンドを使用して、MySQL デプロイメントによって作成された Portworx ボリュームを一覧表示します。
[crayon-67f65b61e3d51322486313/]
次に、MySQL データベースにデータをいくつか追加します。
[crayon-67f65b61e3d54345534098/]
非同期 PX-DR のセットアップ
スケジュール・ポリシーを適用します。
[crayon-67f65b61e3d57973533333/]
次に、マイグレーション・スケジュールを構成します。
[crayon-67f65b61e3d5a680472347/]
以上で完了です！
現在の名前空間のアクティブなマイグレーションのリストを取得するには、kubectl を使用します。ここでは、ポリシーで選択した 1 分の間隔に基づいた初期同期であることを示しています。ポリシーで構成されている時間設定ごとに同期（マイグレーション）が表示されます。
[crayon-67f65b61e3d5d834778696/]
マイグレーションの詳細を表示するには、kubectl を使用します。これにより、ボリュームやその他の Kubernetes リソースのマイグレーションの成功または失敗を示す以下のようなイベントが表示されます。
[crayon-67f65b61e3d5f542538297/]
また、storkctl コマンドを使用すると、作成したスケジュールで実施されたマイグレーションの成功や失敗、進捗状況といった Stage や Status を表示できます。
[crayon-67f65b61e3d62922425559/]
それでは、ソース・クラスタから同期したデータを使用して、DR サイトでアプリケーションをリストアしてみましょう。
まず、新しいクラスタで使用可能なボリュームを確認します。Creation time は、ソース・クラスタからの最新の同期と一致している必要があります。startApplications は false に設定したため、detached になっていることに留意してください。
[crayon-67f65b61e3d64746906408/]
次に、ボリュームを調べて、そのタイム・スタンプをメモします。
[crayon-67f65b61e3d67434786621/]
DR サイトのクラスタ内にあるポッド（pod）とデプロイメント（deployment）を見て、これらが正しく動作しているかを確認できます。
[crayon-67f65b61e3d6a272329802/]
上記のとおり、こちらにはアクティブなポッドはありませんが、デプロイメントが存在します。これは、Kubernetes オブジェクトをマイグレーションするかどうかを設定する includeResources を true にしたためです。Kubernetes オブジェクトはマイグレートされましたが、startApplications を false に設定したため、ポッドのアクティブなレプリカはない状態となっています。
includeResources を false に設定します。
DR サイトでアプリケーションをリストアするには、storkctl コマンドを使用して、最新のマイグレーションを activate します。
[crayon-67f65b61e3d6c757764494/]
次に mysql という名前の名前空間内のポッドを DR サイトで確認します。
[crayon-67f65b61e3d74389290969/]
これで、アプリケーションのコピーが DR サイトに正常にリストアされました。
補足情報として、動画をご紹介します。MySQL と WordPress を使用して複数のボリューム、サービスおよびオブジェクトを DR サイトにマイグレーションするという同様のユースケースのデモ動画です。ぜひご覧ください。
PX-DR により、さまざまなタイプの災害からのフェイルオーバーが可能となり、より自信を持ってミッション・クリティカルなデータ・サービスを提供できるようになりました。将来のリリースでは、ここでご紹介したクラスタ・ペアリングやレプリケーション・タイプの設定などは、今後 GUI 等の提供により、直感的でシンプルなものにすることを目指してまいります！
Pure Storage、Pure Storage のロゴ、およびその他全ての Pure Storage のマーク、製品名、サービス名は、米国およびその他の国における Pure Storage, Inc. の商標または登録商標です。その他記載の会社名、製品名は、各社の商標または登録商標です。