みなさんこんにちは。 Portworxの基礎的な内容をご紹介するブログを公開して参りましたが(ブログ記事の一覧はこちらです)、今回は少し寄り道をして「Portworxのインストール」についてご紹介したいと思います。

Portworxのインストール手順については以前に弊社にてリリースした「Portworx - PX-Backup インストール、操作手順書」で紹介されておりますが、こちらはオンプレミスのCentOSで構成されたKubernetesクラスターやAzure Kubernetes Service (AKS)に対してPortworxをインストールする内容となっています。

Portworxはこの他にも様々な環境に対してインストールすることができるようになっています。今回は「VMware共有アーキテクチャ(VMware shared architecture)」でのPortworxインストールについてご紹介したいと思います。 

※本ブログ記事には「PX-Store」や「Storage Pool」といったPortworx独自の語句が登場します。Portworxの基礎については別途連載形式のブログでご紹介しておりますので、先にこちらの「Portworx基礎」にリストされている記事をご覧頂くことをお奨めいたします。

Portworxの「VMware共有アーキテクチャ」とは

前述の手順書で説明されている「オンプレミスのCentOSで構成されたKubernetesクラスター」へのPortworxインストールは、ベアメタル環境にPortworxをインストールする手法です。Kubernetesクラスターを構成する各Workerノードに対し予め空きディスクを用意しておき、それを利用してPX-Storeを構成します。
一方で「VMware共有アーキテクチャ」によるPortworxのインストールでは、VMware vSphereのデータストアから仮想ディスクを切り出して各Workerノードに接続させる仕組みになっています。

今回はこの「VMware共有アーキテクチャ」によるPortworxのインストールを実施してみたいと思います。

検証環境

今回は下図の環境を利用します。 vSphere上で4台のUbuntu 20.04 LTS仮想マシンを用意しこれでKubernetesクラスター(Kubernetes 1.23)を構成しています。vSphere環境はvCenter Serverにより管理されています。また、"datastore1"という名称のデータストアが存在しています。
Workerノードには以下のようにハードディスクが1つのみ存在しています。

「VMware共有アーキテクチャ」によるPortworxインストール

「VMware共有アーキテクチャ」によるPortworxのインストールについてはメーカーサイトに手順がございますが、GUI操作の方が分かりやすいかと思いますので今回はPX-Centralのスペックジェネレーターを利用したインストール方法をご紹介します。Portworxをインストールするにはマニフェストを作成する必要がありますが、PX-Centralのスペックジェネレーターを利用すると各種パラメータを指定するだけでマニフェストが生成されます。(PX-Centralを利用するためのアカウント作成方法や細かなパラメータの説明についてはこちらの手順書をご参照ください。)

1. Secretの作成

「VMware共有アーキテクチャ」でPortworxを構成する場合、前述の通りvSphereのデータストアから自動的にディスクが作成されます。従ってvSphereの操作を行うためにvCenter Serverのクレデンシャルが必要です。具体的にはvCenter ServerのクレデンシャルをKubernetesのSecretとして利用できるようにしておく必要があります。

今回はvCenter ServerのAdministratorのクレデンシャルを利用します。(利用するユーザーに必要な権限についてはメーカーサイトをご参照ください。)

まずはvCenter Serverのユーザー名・パスワードをbase64でエンコードします。

$ echo '<vcenter-server-user>' | base64　#文字列(1)
$ echo '<vcenter-server-password>' | base64　#文字列(2)

Masterノード上でこの文字列を利用したマニフェストからSecretを作成します。なおSecretの名称は後ほど利用しますので控えておきます。

2. PX-Centralを利用したPortworxのインストール

PX-Centralのスペックジェネレーターを利用してマニフェストを作成し、Portworxをインストールします。

(a) PX-Centralにログインし"Portworx Enterprise"で"Continue"をクリックします。
(b) 今回はPortworx Enterpriseをインストールしますので、"Portworx Enterprise"が指定されていることを確認し"Continue"をクリックします。
(c) 今回はバージョン2.11をインストールします。"Portworx Version"で2.11を指定し、"Next"をクリックします。
(d) 今回利用するvSphereはオンプレミスに存在していますが、"Select your environment"で"Cloud"を選択します。続いて"vSphere"をクリックします。(今回利用するvSphereではTanzuは利用していません。Tanzuは"vSphere"の右隣に"VMware Tanzu"として別の選択肢が設けられています。)
(e) 今回はPX-Storeを構成するディスクをサイズ指定しつつ新たに生成して欲しいため、"Select type of disk"で"Create Using a Spec"を選択します。

続いてディスクのvSphereにおけるプロビジョニング方法とサイズを指定します。今回は手順(c)でETCDを"Build-in"にしていたため、kvdbデバイスのディスクも指定する必要があります。上段がkvdbデバイス、下段がPX-Storeとしてユーザーが利用するディスクです。プロビジョニング方法はLazy Zero Thick Provision Disks / Eager Zeroed / Thinの中から選択します。 今回は検証ですのでプロビジョニング方法はThinにし、サイズはデフォルトのままにしました。

なお、このサイズはクラスター全体ではなく各ノードに対して作成されるディスクのサイズです。今回の例ですと以下のようなイメージです。(PX-Centralの表示上は容量の単位が"GB"になっていますが、Portworxインストール後に"pxctl status"コマンドを実行すると単位はGiBになっています。)
(f) vCenter Serverのホスト名(またはIPアドレス)、ポート、データストア名のプリフィクス、「1. Secretの作成」で作成したSecret名を指定して"Next"をクリックします。
(g) Network設定画面が表示されます。今回はデフォルトのまま"Next"をクリックします。
(h) Customize設定画面が表示されます。Customizeで"None"を指定します。また、今回はPortworxのクラスター名プリフィクスを"px-cluster-v"と指定しました。"Finish"をクリックします。
(i) EULA画面が表示されますので"Agree"をクリックします。
(j) Kubectlコマンドが2つ表示されます。まずは上段のコマンドをMasterノード上で実行し、Operatorが"Running"になることを確認します。
(k) 下段のコマンドをMasterノード上で実行します。Portworxを構成するPodが"Running"になるまで待機します。

これで「VMware共有アーキテクチャ」によるPortworxのインストールが完了しました。Workerノードのひとつで"pxctl status"コマンドを実行した結果は以下の通りです。ローカルストレージデバイスとして/dev/sdbがありサイズが150GiBになっていること、kvdbデバイスとして/dev/sdcがありサイズが32GiBになっていることが分かります。さらにグローバルのStorage Poolとして450GiB(150GiB * 3ノード)あることが分かります。

次にvSphere ClientからWorkerノードの仮想マシンのディスクがどのようになっているか確認してみます。Portworxインストール前にはなかったハードディスク2、3が存在しています。
新たに作成されたvmdkファイルはdatastore1の"fcd"というフォルダに格納されているようです。

今回利用した環境にはWorkerノードが3台ありますので、3ノード分のvmdkファイルが"fcd"フォルダに格納されています。(今回はThinでプロビジョニングしていますので各vmdkファイルのサイズは指定よりも小さくなっています。)

永続ボリュームを切り出してデータを書き込んでみる

今回は「VMware共有アーキテクチャ」でPortworxを構成していますが、永続ボリュームを利用するにあたって特に手順の差分はありません。Kubernetesから動的に永続ボリューム(PV)を切り出したい場合、以前に投稿したブログ記事(PX-Store 初級編、応用編)と同様にStorageClassやPVCを利用することが可能です。ここからはその様子をご覧頂きたいと思います。

ここでは「VMware共有アーキテクチャ」で構成したPortworx上で試しにPX-Store 応用編でもご紹介したAggregationを有効(Aggregationレベル:2)にしたボリュームをPVとしてデータを書き込んでみます。今回利用している環境では1つのWorkerノードにStorage Poolとして150GiBあります。
従ってここでは150GiBを超えて書き込みができるか確認します。今回は以下のStorageClassとPVCを利用します。 ここではNamespace "test"を利用します。
さらに以下のDeploymentを作成してAlpineのPodからこのボリュームを利用できるようにしました。

作成したKubernetesオブジェクトは下図のようになっています。
作成されたボリュームに対し"pxctl volume inspect"コマンドを実行した結果が以下です。"Replica sets on nodes"の内容から2ノード(2つのStorage Pool)をまたがって利用できるボリュームであることが分かります。
このPodからPVに対してランダムなデータを書き込みます。lsコマンド実行結果では"total 195G"となっており、150GiBを超えた後もデータの書き込みができたことが分かります。
Portworx側からも150GiBを超えて書き込みできたことが確認できます。
このように「VMware共有アーキテクチャ」で構成されたPortworxであっても、ベアメタル環境のPortworxと全く同じ使用感で永続ボリュームを利用することが可能です。

　

まとめ

今回は「VMware共有アーキテクチャ」によるPortworxのインストールの様子をご紹介しました。以前に投稿したブログ記事でPortworxの魅力のひとつとして「Portworxを利用すると、各環境におけるストレージの差異を感じさせずに永続化データを格納・利用することができる」ことを挙げました。ベアメタル環境におけるWorkerノードの内蔵ディスクであっても、vSphereデータストアであってもPortworxを利用すれば同様の使用方法で永続ボリュームを利用することが可能です。本ブログ記事を通し、Portworxが環境の差異を吸収できることを実感頂ければ幸いです。

　

　

※ サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。
※ 本ブログにおける記載はPortworxバージョン2.11の情報に基づいています。 異なるバージョンにおけるサポート範囲 / 仕様変更等についてはメーカードキュメントをご確認ください。
※ 本ブログで扱った構成はメーカーサイトで"Portworx VMware shared architecture"という名称で紹介されています。2022年10月時点ではドキュメントが日本語化されていないため筆者にて「VMware共有アーキテクチャ」と訳しましたが、今後異なる日本語訳がなされる可能性がございます。
※ 一部オブジェクトのマニフェストを変更しコマンド実行結果を更新しました。(2022/11)