今回は、以前のブログでもご紹介したコンテナのバックアップ/リストア機能「PX-Backup」を使用して手軽にハイブリッド・クラウドを実現する方法をデモ形式でご説明します。
PX-Backup で実現するハイブリッド・クラウド — シナリオ
オンプレにあるクラスタ(px-cluster-primary)で動く nginx を AWS 上の S3 バケツ(mizo-aws-bucket01)にバックアップし、AWS 上で動くクラスタ(mizo-aws-cluster01)にクラスタをまたいでリストアが可能なことを確認します。
ここでは、手軽にハイブリッド・クラウドを実現するサンプルとして、ステートレスな(Portworx のボリュームを使用していない) nginx を Portworx Enterprise(SDS)が稼働していない AWS 上のクラスタへ移動する一連の流れを試行しました。
実行手順
手順 1:AWS 上で S3 のバケツを作成する
AWS 上で S3 のバケツを作成します(例:mizo-aws-bucket01)。
手順 2:PX-Backup の GUI からクラウド・アカウントを追加する
メイン画面右上にある「Settings」→「Cloud Settings」を選択し、Cloud Account の横に位置する 「+ Add」をクリックします。
cloud provider として「AWS / S3 Compliant Object Store」を選択し、AWS アカウント情報を入力したら、画面右下の「Add」をクリックします。
手順 3:PX-Backup の GUI からバックアップ・ロケーション(Backup Location)を追加する
メイン画面右上の「Settings」→「Cloud Settings」を選択し、Backup Locations の横に位置する「+ Add」をクリックします。
手順 2 で登録した AWS の「Cloud Account」と、手順 1 で作成した「Bucket」、「Region」、「Endpoint」を入力します。
登録完了後の「Cloud Settings」の画面は下図のようになります。複数のクラウド・アカウント(Cloud Accounts)や、バックアップ・ロケーション (Backup Locations)の作成が可能で、バックアップごとに最適なロケーションを選択できます。
手順 4:AWS の EKS サービス上でテスト用のクラスタを作成する
今回はシンプルに、AWS CloudShell から eksctl
コマンドを利用して 3 つの worker ノードを持つクラスタを作成しました。
1 2 3 4 5 6 7 8 9 |
[cloudshell–user@ip–10–x–xx–xxxx ~]$ eksctl create cluster —name mizo–cluster02 —nodes–min 3 —nodes–max 3 [cloudshell–user@ip–10–x–xx–xxxx ~]$ kubectl get node NAME STATUS ROLES AGE VERSION ip–192–168–yy–yyy.ap–northeast–1.compute.internal Ready <none> 127m v1.19.6–eks–49a6c0 ip–192–168–yy–yyy.ap–northeast–1.compute.internal Ready <none> 90m v1.19.6–eks–49a6c0 ip–192–168–yy–yyy.ap–northeast–1.compute.internal Ready <none> 90m v1.19.6–eks–49a6c0 |
手順 5:AWS 上に作成したクラスタとオンプレのクラスタを PX-Backup に登録する
メイン画面の右上にある「+ Add Cluster」をクリックします。
Add Kubernetes Cluster の画面で、必要な情報を入力します。
- Cluster name:クラスタ名として任意の名前を入力します。
- Kubeconfig:対象クラスタ上で
kubectl config view --flatten --minify
コマンドを実行して得られる、クラスタのコンフィグレーション情報を入力します。 - Kubernetes Service:今回は EKS を選択します。
- Cloud Account:手順 2 で登録したクラウド・アカウント(Cloud Account)を選択します。
AWS 側のクラスタ(mizo-aws-cluster01)と同様に、オンプレ側のクラスタ(px-cluster-primary)も登録します。
手順 6:STORK をインストールする
Portworx(STORK*1)がインストールされていないクラスタをバックアップ/リストア対象とする場合は、画面下部に表示されるインストラクションに従って「Non PX Cluster」をクリックし、インストール・コマンドをコピーします。
インストール・コマンドを対象クラスタ上で実行します。今回は、オンプレのクラスタには Porworx がインストールされているので、AWS 側のクラスタのみでの実行になります。
1 2 3 4 |
[cloudshell–user@ip–10–x–xx–xxxx ~]$ curl –fsL –o stork–spec.yaml “https://install.portworx.com/2.6?comp=stork&storkNonPx=true” [cloudshell–user@ip–10–x–xx–xxxx ~]$ kubectl apply –f stork–spec.yaml |
上記のコマンドが実行されると、対象クラスタに STORK がインストールされます。
*1 STORK(STorage Orchestrator Runtime for Kubernetes)は、CNCF にオープンソース(Apache 2.0 License)として Portworx が開発、保守している Kubernetes Scheduler Extension です。ボリューム・スナップショット、ボリューム暗号化、分離、クラスタ内の最適なボリューム配置を Portworx Service などと連携して実現します。
手順 7:テスト用に nginx をオンプレのクラスタ上に作成する
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
apiVersion: apps/v1 kind: Deployment metadata: name: nginx–deployment namespace: default spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: – name: nginx image: nginx:1.14.2 ports: – containerPort: 80 |
手順 8:オンプレ側の nginx を、手順 1 で作成した AWS 上の S3 バケツにバックアップする
default 名前空間にあるリソースの中から nginx を選択し、「Backup」ボタンをクリックします。
任意のバックアップ名を入力し、手順 3 で作成したバックアップ・ロケーション(Backup location)を選択して「Create」ボタンをクリックします。
バックアップの作成に成功すると、AWS 上の S3 に新しくオブジェクトがバックアップされているのが見えます。
手順 9:バックアップしたアプリケーションを AWS 上のクラスタにリストアする
バックアップ一覧画面から、先ほど取得したバックアップのケバブメニュー「︙」をクリックして「Restore」を選択します。
任意の名前を入力します。リストア先のクラスタ(destination cluster)として、バックアップ取得元の px-cluster-primary ではなく、AWS 上の mizo-aws-cluster01 を選択し、「Restore」ボタンをクリックします。なお、ここでは、元のアプリが存在した名前空間である default ではなく、AWS 上のクラスタにない名前空間 green を指定しています。
AWS 上のリストア先のクラスタで、新しく green という名前空間が作成され、レプリカ 2 で設定した nginx が実行されていることが確認できます。
今回は、バックアップ/リストアを GUI を使用して手動で行う方法をご説明しましたが、PX-Migrate 機能を利用することで、リストアを含めたマイグレーションをスケジューリングして自動的に行うことができます。PX-Migrate 機能については、以前の投稿「Portworx PX-DR:コンテナのディザスタ・リカバリ(非同期レプリケーション編)」をご参照ください。
以上、PX-Backup で実現する簡単なハイブリッド・クラウドのデモでした。数 100 KB サイズのステートレスな nginx コンテナでのデモでしたが、コンテナの特長である軽量さ、ポータビリティの高さ、ハイブリッド/マルチクラウドとの親和性を実感できました。MySQL のようなステートフルなデータを持つアプリケーションや、Kubernetes クラスタ自体が持つリソース、複数のコンテナが混在するアプリケーション(名前空間)でも、PX-Backup を使用することで、シンプルな GUI で手軽にハイブリッド/マルチクラウドを実現できそうだとご想像いただけますと幸いです。
最後に、Google Cloud と Azure 間でのアプリケーション移行のデモ動画をご紹介します。あわせてご覧ください。
Pure Storage、Pure Storage のロゴ、およびその他全ての Pure Storage のマーク、製品名、サービス名は、米国およびその他の国における Pure Storage, Inc. の商標または登録商標です。その他記載の会社名、製品名は、各社の商標または登録商標です。