みなさんこんにちは。 以前にこちらの記事で、Portworxの製品概要をご紹介しました。 Portworxの屋台骨である「PX-Store」はコンテナ環境にSDS (ソフトウェア・ディファインド・ストレージ)を提供すること、"ソフトウェア・ディファインド"であるからこそ様々な環境でディスクの違いを意識することなく同様のデータ・プラットフォームが利用できることなどをご説明いたしました。

今回はこの「PX-Store」に焦点を当て、ノードのディスクがどのように管理されるか、ボリュームがどのようにコンテナ環境へ提供されるかといった点を見ていきたいと思います。

 

検証環境

今回は4台のUbuntu 20.04.4LTS仮想マシンで構成したKubernetesクラスター(Kubernetes 1.22, Docker 19.3.11)を利用します。Kubernetesクラスターには3つのWorkerノードがあり、その空きディスクでPortworxクラスター(Portworx Enterprise 2.11)を構成しています。

なおPortworxのインストールについては弊社オリジナルの手順書が公開されておりますのでこちらをご参照ください。(OpenShiftをご利用の場合はこちらをご参照ください。)

　

Portworx CLI「PXCTL」

Portworx (PX-Store)の動作を確認する前に、Portworxの操作についてご紹介します。
Portworxの管理のためにCLI「PXCTL」が提供されています。 Portworxのインストール後、Portworxクラスターの各ノード(Workerノード)上でPXCTLを実行することができるようになります。(PXCTLは特権ユーザーで実行する必要があります。)

"pxctl --help"を実行するとコマンドの用法を確認することができます。 "Available Commands"に"cluster"や"volume"といった記載がありますように、PXCTLを利用することでPortworxクラスターやボリュームなどの管理ができるようになっています。
例えばPortworxのステータス概要を確認するには"pxctl status"を実行します。コマンド実行結果からノードやクラスターのID、バージョンなど様々な情報を確認することができます。容量に着目しますと、3ノードそれぞれの"Capacity"が200GiBになっています。さらに末部の"Total Capacity"が600GiBとなっていますのでこのPortworxクラスターはグローバルでは600GiBの容量があるということが分かります。
詳細なPXCTLの用法についてはこちらをご参照ください。

　

ディスクをまとめる「Storage Pool(ストレージプール)」

まずはPortworxにおけるディスクの扱い方を確認しておきましょう。Portworxは各ノードのディスクを「Storage Pool」として整理・分類して扱います。Portworxクラスター構成にあたり、ディスクそれぞれの容量や種別を識別して同じものを同一のStorage Poolとしてグルーピングします。この仕組みにより、Portworxクラスター内の各ノードを同じディスク構成にする必要がありません。インストール要件を満たしていれば、各ノードで任意の容量・種別(SSD / HDD)のディスクをそれぞれ利用できるようになっています。

例として単一のノードを対象にStorage Poolがどのように作成されるかご説明いたします。例えばあるノードにおいて、Portworx用途で100GiBのディスクが1つ、150GiBのディスクが2つあったとします。 この場合、100GiBのディスクをひとつのStorage Pool、150GiBのディスク2つをさらに別のStorage Poolとして管理します。下図のようにPool0は合計100GiB、Pool1は合計300GiBということになります。
今回利用する環境では各ノードにつき空きディスク(200GiB) 1つでPortworxクラスターを構成しましたので、各ノードに200GiBのStorage Poolがひとつ存在するという状態になっています。
なお、作成されたStorage Poolはそれぞれパフォーマンスが測定され"IO Priority"としてHigh / Medium / Lowのいずれかがラベル付けされます。

ここでPortworxクラスターセットアップ後のStorage Poolを確認してみましょう。あるノード上で"pxctl service pool show"コマンドを実行するとStorage Poolの情報が表示されます。 Storage Pool (ID:0) がひとつ存在し、IO Priorityが"HIGH"になっていること、容量が200GiBであること、ドライブが/dev/sdbであることなどが分かります。

さらに別のノード上で同じコマンドを実行した結果が以下です。こちらにも200GiBのStorage Poolがひとつ存在しています。 先程と同様にID:0ではありますがUUIDが異なっていますので、先程のStorage Poolとは別物となっているようです。

　

PX-Storeによるボリュームの提供

Portworxノードにおけるディスクの扱い方を確認しましたので、ここから永続ボリューム(PV)がどのように切り出されるかを見てみましょう。

Portworxクラスター内のボリューム一覧を確認するには"pxctl volume list"コマンドを利用しますが、最初はボリュームが存在していませんのでリストは空になっています。

ボリュームをPXCTLにより手動で作成することもできますが、ここではKubernetesのStorageClassやPVC (PersistentVolumeClaim)を利用して動的にボリュームを切り出してみたいと思います。以下のようにStorageClass「portworx-sc」、PVC「pvcsc001」を作成します。なお、ここではテスト用に作成したNamespace「vol-test」を利用します。
これらのリソースを作成後、新たに1GiBのPVが動的に作成されました。
それではPortworx側からボリュームがどのように見えるか確認してみましょう。
"pxctl volume list"コマンドを実行すると新たにボリュームが1つ作成されていることが分かります。 さらに"STATUS"が"detached"となっています。これは当該ボリュームが利用されていないことを示すものです。この時点ではPVが動的に作成されたのみで、PVを利用するPodが存在していないため"detached"になっています。
ボリュームのより詳細な情報は"pxctl volume inspect <volName>"コマンドで確認することが可能です。 "Replica sets on nodes"で当該ボリュームがどのノード / Storage Poolに存在しているか確認することができます。ここではUUID:b2575aab-...のStorage Poolに存在しているようです。
次にPVを利用するPodを同じNamespaceに作成してボリュームの状態がどのように変わるか見てみましょう。ここでは以下のようなDeploymentを利用してNginxのPodを作成しました。

この時点で存在するKubernetesオブジェクトは下図のようになっています。
改めて"pxctl volume list"コマンドを実行すると、"STATUS"が"attached"に変化していることが分かります。
さらに"pxctl volume inspect <volName>"コマンドの実行結果を見てみると"Volume consumers"という項目が追加されており、当該ボリュームを利用しているPodやNamespaceなどが表示されています。

　

ReadWriteManyで使いたいときは...「sharedv4」

今回作成したPVC「pvcsc001」はアクセスモードが「ReadWriteOnce」になっていました。Kubernetesは複数ノードをクラスタリングして利用することができますので、「ReadWriteMany」で利用できるボリュームが必要な場合もあるでしょう。
このような場合にはPortworxの「sharedv4」ボリュームを作成します。

StorageClassとPVCにより動的にボリュームを切り出し、sharedv4ボリュームの動作を確認してみましょう。 ここでは以下のようにStorageClass「portworx-sc-shared」、PVC「pvcsc-shared」を作成しました。sharedv4を利用する場合、StorageClassにsharedv4のパラメータを指定します。なお、ここではNamespace「sharedvol-test」を利用します。
続いて各WorkerノードでPodが起動するようDaemonSetを作成します。

この時点で存在するKubernetesオブジェクトは下図のようになっています。
Kubernetes側でリソースを確認します。PVC、PVのアクセスモードがRWX(ReadWriteMany)になっています。
Podは3ノードそれぞれの上で"Running"になっています。
次にPXCTLでボリュームの詳細を確認してみましょう。
"Shared"が"v4"になっており、"Volume consumers"に先ほど確認した3つのPodが表示されています。
sharedv4によりReadWriteManyのボリュームを作成し、複数のノードから利用できることが確認できました。

なお、データベース用に「sharedv4」ボリュームを利用することはメーカーが非推奨としている点にご留意ください。(詳細についてはこちらをご参照ください。)

　

今回はPX-Storeの「初級編」ということで、Portworxノードのディスクがどのように扱われているか、ボリュームをどのように切り出すかといった点を中心にご紹介しました。

今回は基礎的な機能・操作をご紹介するために、ある単一ノード上の単一Storage Poolの中にボリュームがあるという状態になっていました。
Portworxは最小3ノードをクラスタリングして利用しますので、ノードを跨って利用できる機能もございます。また改めて詳細をご紹介できればと思います。お楽しみに。

　

　

※ 本ブログにおける記載はPortworxバージョン2.11の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。
※ 本ブログは弊社にて把握、確認された内容を基に作成したものであり、お客さま環境での動作や製品機能の仕様について担保・保証するものではありません。サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 一部オブジェクトのマニフェストを変更しコマンド実行結果を更新しました。(2022/11)