みなさんこんにちは。 Portworxの機能を連載形式でご紹介しております。

-------------------------------------------------------------------------------------------
　入門編　コンテナ環境と「データ」を考える
　第1回　PX-Storeによるボリュームの提供(初級編)
　第2回　PX-Storeによるボリュームの提供(応用編)
　第3回　ボリュームのスナップショット
　第4回　PX-Autopilotによるボリューム・ストレージの自動拡張
　第5回　PX-SecureによるRBACとOwnership
　第6回　PX-Migrateによるアプリケーションとデータの移行
-------------------------------------------------------------------------------------------

前回までは単一のKubernetesクラスターを前提にPortworxの基礎をご紹介していました。 コンテナ技術によるメリットのひとつとしてアプリケーションの可搬性が挙げられますので、複数のKubernetesクラスターを使い分けたいというお客様もいらっしゃるかもしれません。 アプリケーション自体はイメージをPullすることで簡単に別環境でも稼働させることができますが、データはどうでしょうか。 今回はアプリケーションだけではなくデータも含めて移行ができる「PX-Migrate」についてご紹介いたします。

PX-Migrateとは

メーカーサイトのFull Feature ListによるとPX-Migrateの機能として以下が挙げられています。

・マルチクラウド / マルチクラスター間のアプリケーション移行
・クラウドスナップショット
・アプリケーションの整合性が保たれたスナップショット

ローカルスナップショットはPX-Storeの機能として掲載されていますが、クラウドスナップショットやアプリケーションの整合性が保たれたスナップショットについてはPX-Migrateに区分けされているようです。 スナップショットの基礎については連載第3回でご紹介しましたので、今回は1点目に挙げた「移行」について詳しく見てみたいと思います。

 なお、本ブログ記事ではKubernetes環境を対象とした移行についてご説明いたします。 Kubernetes環境における移行の機能はメーカーサイトでは"Migration with Stork on Kubernetes"として紹介されており、今回はこちらの内容に沿ってアプリケーションとデータを移行します。

ここで移行を行うにあたって扱う主な用語を整理しておきましょう。

ClusterPair (クラスターペア)

移行を実行する前にKubernetesクラスター同士をペアリングします。これをClusterPairと言います。

なお、メーカードキュメントにおいて移行元のクラスターはSource Cluster、移行先のクラスターはDestination Clusterと呼ばれています。

Object Store (オブジェクトストア)

移行を実行するとSource ClusterからObject Storeと呼ばれる領域に情報がエクスポートされ、Destination Clusterでその情報がインポートされます。(移行されるオブジェクトやデータについてはメーカーサイトをご参照ください。) AWS S3 やAzure BlobストレージなどをObject Storeとして用意しておきましょう。

検証環境

今回は2つのKubernetesクラスターを利用します。 それぞれ1台のMasterノードがあり、3台のWorkerノードでPortworxを構成しています。 (両クラスターともNamespace "portworx"にPortworxをインストールしています。) さらにSTORKならびにstorkctlが両クラスターで利用可能な状態になっています。(STORKについては連載第3回でご紹介いたしました。) また、移行の動作確認のためにSource Cluster側でNamespace "mg-test"を作成しNginxを稼働させています。

Source Clusterにおける"pxctl status"コマンドの出力は以下の通りです。

Destination Clusterにおける"pxctl status"コマンドの出力は以下の通りです。

Namespace "mg-test"内のオブジェクトやStorageClassは連載第3回と同様です。 StorageClassによってPX-Storeから動的にボリュームを作成しています。

WebブラウザでこちらのServiceにアクセスすると、PVに格納した以下のコンテンツが表示されるようになっています。
なお、今回はObject Store用に以下のAzureストレージアカウントを用意しました。

　

移行の設定と実行

前述の「PX-Migrateとは」でご紹介した設定を実際に行い、移行の動作を確認します。 なお、Kubernetes環境において移行を行う場合の要件についてはメーカーサイトの"Prerequisites"をご参照ください。

(1) クラスターUUIDの確認

以降の設定にはDestination ClusterのUUIDが必要ですので、まずはDestination Cluster側で以下のコマンドを実行しUUIDを確認します。 <Namespace>はPortworxをインストールしたNamespaceです。
PX_POD=$(kubectl get pods -l name=portworx -n <Namespace> -o jsonpath='{.items[0].metadata.name}')
kubectl exec $PX_POD -n <Namespace> -- /opt/pwx/bin/pxctl status | grep UUID | awk '{print $3}'

(2) Object Storeの認証情報を登録

Source ClusterとDestination Clusterの双方でObject Storeの認証情報を登録します。 Source ClusterとDestination ClusterそれぞれでPXCLIにより認証情報を登録しますが、利用するObject Storeによって構文が変わります。 今回はObject StoreとしてAzureストレージアカウントを用意しましたので以下のコマンドを実行します。(Amazon S3やGoogle Cloudを利用する場合のコマンド構文についてはメーカーサイトをご参照ください。)
pxctl credentials create \
--provider azure \
--azure-account-name <azure_storage_account_name> \
--azure-account-key <azure_account_key> \
clusterPair_<UUID_of_destination_cluster>
"--azure-account-key"ではAzureストレージアカウントのアクセスキーを指定します。
なお、"pxctl credentials list"コマンドを実行すると作成した認証情報を確認することができます。

(3) ClusterPairのSpec作成

PX-MigrateではClusterPair オブジェクトをSource Cluster側で作成する必要がありますが、そのためのSpec(マニフェスト)をDestination Cluster側で生成します。
Source Cluster側で以下のコマンドを実行します。今回はClusterPair名を"remotecluster"とします。
storkctl generate clusterpair -n <移行対象のNamespace> <ClusterPair名>
コマンドを実行するとSpecが表示されますので、コピーしてYAMLファイルとして保存します。 ここではSource Clusterのローカルにclusterpair.yamlという名称のファイルとして保存しました。

(4) Specの編集

生成されたSpecを確認するとspec.optionsに"insert_storage_options_here"という項目があります。こちらにDestination Clusterの情報(IPアドレス、ポート、トークン)や移行のモードといったオプションを追加する必要があります。各オプションの名称についてはメーカーサイトで確認可能です。
トークンはDestination Clusterで"pxctl cluster token show"コマンドを実行すると確認できます。
ここでは以下のように設定しました。 今回は1回のみ移行を実行しますので、"mode"の設定はスキップしました。 なお各設定値は引用符で囲っておきます。

(5) ClusterPairの作成

2つのクラスターをClusterPairとして設定するために(4)で編集したYAMLファイルをSource Cluster側で"kubectl apply"します。

"storkctl get clusterpair"コマンドを実行すると設定が成功したかどうかを確認することができます。 STORAGE-STATUSとSCHEDULER-STATUSが"Ready"になっていれば成功です。

(6) 移行

移行するにはSource Cluster側で"migration"オブジェクトを作成します。 今回は以下のようなYAMLファイル(migration.yaml)を用意し"kubectl apply"しました。(各項目の詳細についてはメーカーサイトをご参照ください。)

"storkctl get migration"コマンドを実行すると移行の状況を確認することが可能です。STAGEが"Final"、STATUSが"Successful"になっていれば完了です。

移行の詳細な状況については"kubectl describe migration"コマンドの出力のEventsで確認できます。今回はPortworxボリューム、PVC、PV、Service、Deploymentの移行にそれぞれ成功していることが分かります。

移行後の確認

移行が完了しましたのでDestination Cluster側の状態を確認してみます。

まずNamespace "mg-test"が新たに作成されています。

このNamespace内にPodやPVC、PVなどのオブジェクトが作成されています。

このServiceにWebブラウザでアクセスすると以下の通りコンテンツが表示され、データも含めて移行されたことが確認できました。

なお、移行後のSource Cluster側のオブジェクトは以下の通りです。PodはRunningのままになっています。
　

まとめ

今回はPX-Migrateの「移行」をピックアップし機能や操作手順をご紹介しました。 移行はNamespace単位で行われ、アプリケーションが稼働するPodだけではなくPVCやServiceといったオブジェクトも含めて移行することができました。 複数のKubernetesクラスターを利用している場合、クラウドへのリフト＆シフトや開発環境からの昇格といった場面で利用できそうです。

また、Kubernetesのリリースサイクルは年に約3回とされており、パッチリリースシリーズのサポート期間については12ヶ月間が標準期間とされています。パブリッククラウドのディストリビューションを利用している場合でも、例えばAzure Kubernetes Service (AKS)であればサポートされるのは3つのGAマイナーバージョンとされています。 長期にわたってKubernetesを利用する場合、バージョンアップが検討事項になるかと思います。 Kubernetesをバージョンアップする場合は当然ながらその上で稼働するPortworxとのCompatibilityに注意する必要があります。場合によってはPortworxのバージョンアップも必要になるかもしれません。「既存環境のアップグレードは怖い」とお考えの方もいらっしゃるでしょう。そのような場合、新しいバージョンのKubernetes / Portworxクラスターを平行稼働させ、アプリケーションやデータをPX-Migrateによって移行し動作確認を行うといった使い方もできそうです。

なお、PX-Migrateの移行と似た機能としてクラスター間でのレプリケーションを提供する"PX-DR"というアドオンがございます。 こちらについてはまた改めてご紹介できればと思います。

　

　

※ サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 本ブログにおける記載はPortworxバージョン2.12.1の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。