Portworx のデータ保護機能：Kubernetes 環境のデータを止めずに守る

Kubernetes は、ステートレスなアプリケーションだけでなく、データベースをはじめとするステートフルなアプリケーションの実行基盤としても広く採用されています。しかし、ステートフルなアプリケーションを本番環境で稼働させる以上、「データをいかに守るか」、「障害発生時にいかに迅速に復旧させるか」という点は避けて通れない課題です。

Portworx Enterprise は、Kubernetes 向けのクラウドネイティブなデータ・プラットフォームです。ストレージ機能に加えて、スナップショット、レプリケーション、ディザスタ・リカバリ（DR）、バックアップを含めた包括的なデータ保護機能を提供します。本投稿では、スナップショットとレプリケーションに関して、実際の運用でどのように活用できるかをご紹介します。

なお、本投稿でご紹介する同期・非同期レプリケーション機能を利用するには、Portworx Enterprise ではアドオン・ライセンスが必要です。ライセンスに関してはこちらのブログをご覧ください。

コンテナ時代のデータ基盤を支える Portworx 入門

2026.05.08　投稿者：戸田 貴夫

Portworx は、Kubernetes 向けのデータ基盤です。コンテナや KubeVirt などのモダンな仮想化向けに、ストレージ、データ保護、DR、バックアップを統合的に提供し、コンテナ時代に最適なデータ管理を実現します。

スナップショットによるデータ保護

Portworx は、Kubernetes の永続ボリューム（PersistentVolume、以下 PV）に相当するボリューム単位でスナップショットを作成する機能を備えています。取得先に応じて、ローカル・スナップショットとクラウド・スナップショットの 2 種類が利用できるほか、Volume Trash Can というボリュームの誤削除保護機能があります。

ローカル・スナップショット

• 手動での取得と、スケジュールの設定による定期的な取得が可能
• ストレージ側の CLI による取得と、Kubernetes の YAML マニフェストの作成による取得が可能
• スナップショットの取得前／取得後のルールを設定し、アプリケーションの整合性を維持した状態でスナップショットを取得可能

クラウド・スナップショット

• 保存先以外はローカル・スナップショットと同様
• 保存先として FlashBlade、Amazon S3、Azure Blob Storage、Google Cloud Storage、MinIO などの S3 互換オブジェクトストレージを指定可能

スナップショットにより、アプリケーションを停止させることなくデータのリカバリ・ポイントを確保できます。

Volume Trash Can

• ボリュームが誤って削除された場合でも、スナップショットをゴミ箱に保持し、データの損失を防ぐ機能
• ゴミ箱での保持期間は「分」単位で指定可能
• ゴミ箱に保持されたスナップショットから復元したボリュームを新しい PV に再度紐づけることで、アプリケーションを復旧可能

誤操作などによる意図しないボリューム削除に対しても、シンプルな仕組みでリスクを低減できます。

Skinny Snap による
容量効率的なスナップショット

Portworx は、レプリケーション係数（Replication Factor）に応じて、ボリューム（≒ PV）の複製を異なるワーカー・ノードに配置します。デフォルトの動作では、スナップショットもボリュームの複製と同じ数だけ、各ノードに作成されます。

Portworx の Skinny Snap 機能を有効にすると、スナップショットを全ノードに複製するのではなく、各ノードに分散して 1 つずつ配置できます。例えば、3 ノードのクラスタで StorageClass のレプリケーション係数が 3、スナップショットの保持数が 3 という構成では、次のようになります。

• デフォルト：各ノードに 3 個ずつ、合計 9 個のスナップショットが作成される
• Skinny Snap を有効にした場合：各ノードに 1 個ずつ、合計 3 個のスナップショットが作成される

これにより、スナップショットの保持数を増やしても、ストレージ容量への影響を最小限に抑えることができます。

非同期レプリケーションによる
アプリケーション DR

Portworx は、ストレージ内のデータだけでなく、Deployment や Secret などのコンテナ情報（Kubernetes リソース）も含めて、ネームスペース単位でディザスタ・リカバリ（DR）を実現する非同期レプリケーション機能を備えています。

• ストレージ内のデータだけでなく、Deployment や Secret などの Kubernetes 情報も含む
• ネームスペース単位で DR を実施
• 最小 15 分間隔でデータ転送スケジュールを設定可能
• Portworx のスナップショットをベースにデータを転送
• 転送はオブジェクトストレージを経由

プライマリ・クラスタが利用できなくなった場合には、セカンダリ・クラスタ側で対象のアプリケーションを有効化することで、業務を継続できます。クラスタ間の距離やネットワーク・レイテンシーの制約が同期レプリケーションと比べて緩やかであるため、リージョンをまたいだ DR にも適しています。

同期レプリケーションによる
アプリケーションの DR

非同期レプリケーションより短い RPO（Recovery Point Objective：目標復旧時点）が求められる環境では、Portworx の同期レプリケーションが有効です。これは、2 つの Kubernetes クラスタで、1 つの Portworx クラスタを構成する方式です。

• ストレージ内のデータだけでなく、Deployment や Secret などの Kubernetes 情報も含めて、リアルタイム（同期）でDR を実現
• ネームスペース単位で DR を実施
• 2 つの Kubernetes クラスタにまたがる形で、1 つの Portworx クラスタを構成
• StorageClass のレプリケーション係数を “2” に設定することで、各データセンターのクラスタに 1 つずつレプリカを配置
• クラスタ間のネットワーク・レイテンシーは 10 ミリ秒（ms）以内
• スプリットブレイン防止のため、第三のデータセンターにウィットネス・ノードを配置

同期レプリケーションであるため、一方のデータセンターに障害が発生しても、もう一方のデータセンターでデータの損失なくアプリケーションを継続できる点が最大のメリットです。ただし、レイテンシーの制約上、地理的に離れた 2 拠点間での構成には適しません。レイテンシーに応じて非同期レプリケーションと使い分けることが推奨されます。

同期／非同期レプリケーションで
サポートされる Kubernetes リソース

Portworx の同期／非同期レプリケーション機能では、PV や PersistentVolumeClaim（PVC）に加えて、次のような幅広い Kubernetes リソースをサポートしています。

なお、ここに記載のない CRD（Custom Resource Definition：カスタム・リソース定義）についても、追加で対象に含めることができます。これにより、レプリケーション先でのアプリケーションの再稼働が容易になります。

まとめ

Kubernetes 上でステートフルなアプリケーションを本番運用する際には、要件に応じたデータ保護が不可欠です。Portworx は、スナップショットから同期／非同期レプリケーションまで、単一のプラットフォームで幅広い DR 要件に対応できるソリューションとして、Kubernetes 環境におけるデータ保護の有力な選択肢となり得る存在です。

次回は、Portworx のバックアップ機能である PX-Backup をご紹介します。

Everpure、Everpure のロゴ、「P」のロゴ、Pure Storage および、Everpure の商標リストに記載されているマークは、米国およびその他の国における Everpure, Inc. またはその子会社の商標または登録商標です。その他記載の全ての名称は、それぞれの権利者に帰属します。