ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

Portworxを利用したステートフルアプリケーションのマイグレーションを試してみた

ライター:金只 圭司
2008年にネットワンシステムズに入社。
入社当初からストレージ製品技術担当として様々なストレージ製品の検証、技術支援を行っている。最近はハイブリッドクラウド、マルチクラウド環境におけるデータのあり方を模索中。

目次

こんにちは。

近年、コンテナオーケストレーションツールであるKubernetesについて、DevOpsDXの観点で検討されている、実際に本番で運用されている、というお話をよく耳にするようになりました。さらに、ステートフルアプリケーションの本番運用を可能とするため、ストレージメーカー各社が様々な製品をリリースしています。

そんな中、果たしてどの製品が良いのか疑問に思い、最近ではストレージメーカー各社が提供しているコンテナ向けの永続ストレージ対応製品の評価、比較を行っています。

そこで、本記事ではその中でピュア・ストレージ社のPortworxを利用したKubernetesクラスタ間のステートフルアプリケーションのマイグレーションの動作を簡単にご紹介します。

早期からKubernetes対応してきたSoftware-Defined Storage「Portworx」

Portworxは、202010月にピュア・ストレージ社に買収される以前から、海外ではKubernetes環境向けのストレージレイヤーを担う製品として注目されていました。PX-Storeをはじめ、PX-BackupPX-SecurePX-CentralPX-Autopilotなど様々なコンポーネントで構成されています。基本的な機能としては、STORKStorage Orchestrator Runtime on Kubernetes)と呼ばれるストレージランタイムを活用したVolumeのプロビジョニング、最適配置、バックアップ/リストア、マイグレーション、Async DRなどがあります。また、CSI(Container Storage Interface)にも対応しており、CSIに準拠した操作も可能です。

PX-Backupについて

PX-Backupは、Kubernetes Namespace内のリソースおよびPVPersistent Volume)をバックアップ/リストアする機能を持っています。バックアップ先のストレージとしては、オブジェクトストレージが必要となっており、MinIOFlashBlade、その他のS3互換のオブジェクトストレージがサポートされています。

実はPX-Backupの機能で取得したバックアップは、異なるクラスタへのリストアも可能ですので、これをステートフルアプリケーションのマイグレーションに活用できます。実際に弊社のラボ環境で動作を確認しましたので以降でその流れをご紹介いたします。

Kubernetesクラスタ間でのステートフルアプリケーションのマイグレーションの動作確認

今回はテスト用の環境として以下を利用しました。

  • Kubernetesクラスタ

・VMware vSphere with Tanzu – Tanzu Kubernetes Cluster(TKCv1.20. 9

Red Hat OpenShift Container PlatformOCPv4.9.23

 ※両クラスタにPortworxおよびPX-Backupをインストール済み

  PX Version: v2.9.1.1

  PX-Backupv2.1.2

  • オブジェクトストレージ

Amazon S3

  • アプリケーション

WordPress PodはWordPress、MySQLの利用)

上記の環境を使った動作のイメージを下図にまとめています。まず、PX-Backupを利用してTKC上のWordPressアプリケーションをS3にバックアップします。その後、同じくPX-Backupを利用してバックアップしたWordPressアプリケーションを、OCP上にリストアするという手順でマイグレーションを行います。

では実際に動作を確認してみましょう。

1.事前準備

①TKC上のWordPressで新規に記事を投稿しておきます。

※リストア後にこの記事が表示されれば正しくマイグレーションできたと判断します。

2.PX-Backupを利用してTKC上のWordPressのバックアップの取得

①PX-BackupのUIからWordPressのバックアップを取得します。

主な設定

[バックアップ対象のNamespace]wordpress

[バックアップ対象のリソース]Namespace内のすべてのリソースを選択

[バックアップ先]nos-og31-px-testbucket (S3)

 ※ここではバックアップ前後に処理を実行できるPre-ruleとPost-ruleも設定できます。

  今回は省略していますが、本番環境ではこれらを正しく設定することでPVの静止点を取得する必要があります。

②バックアップが正常に取得されたことを確認します。

③S3のバケット内にもバックアップされたデータが存在していることを確認します。

3.PX-Backupを利用してバックアップしたWordPressをOCP上にリストア

①リストアする前にTKC上のWordPressのingressリソースを削除しておきます。

 ※リストア後も同じFQDNでアクセスしますので、競合回避のため実施しています。

この時点でブラウザからもアクセスができなくなります。

②先ほど取得したバックアップのメニューから「Restore」を選択

③リストア設定を行い、「Restore」を実行します。

主な設定

 ・[Destination Namespace] wordpress-ocp

 ・[リストア対象のリソース]: すべてのリソースを選択

④リストア処理が完了したことを確認します。

4.OCP上で正しくリストアされたことを確認

OCP上でリストアされたPodPVCが正常に動作し、Ingressリソースが作成されていることを確認します。

②情報を修正し、新しいIngressリソースに対するAレコードのIPアドレスを更新します。

③ブラウザからWordPressに正常にアクセスできることを確認します。

 バックアップ直前に作成した投稿も反映されているので正常にリストアができていることがわかります。

以上で、異なるKubernetesクラスタ環境へのマイグレーションが完了です。

まとめ

本記事では、ピュア・ストレージ社のPortworxを利用したステートフルアプリケーションのマイグレーションの動作について、ご紹介しました。シンプルな構成での確認ですが、実際のバックアップ/リストアの手順もシンプルだと感じられたのではないでしょうか?今後も様々なストレージやデータ保護製品の動作を評価していきますので、他の製品についてもいずれご紹介したいと思います。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND