みなさんこんにちは。 Portworxの機能を連載形式でご紹介しております。

-------------------------------------------------------------------------------------------
　入門編　コンテナ環境と「データ」を考える
　第1回　PX-Storeによるボリュームの提供(初級編)
　第2回　PX-Storeによるボリュームの提供(応用編)
　第3回　ボリュームのスナップショット
　第4回　PX-Autopilotによるボリューム・ストレージの自動拡張
-------------------------------------------------------------------------------------------

連載「Portworx基礎」ではこれまでPX-StoreによるSDS (ソフトウェア・ディファインド・ストレージ)の機能を主にご紹介して参りました。 エンタープライズ環境でストレージを運用するにあたっては、データの増加にどう対処するかという点が課題になることも多いのではないでしょうか。 今回(第4回)はPortworxの「PX-Autopilot」により容量を自動的に拡張する方法についてご紹介いたします。

 

「PX-Autopilot」とは

以前のブログ記事(入門編)でご紹介しましたように、Portworxには様々な機能があり「PX-」で始まる名称がつけられています。 PX-Autopilotもその中のひとつです。

物理環境の場合は将来の容量増加をある程度見込んでディスクを用意することもあるかもしれませんが、クラウドを利用しているような場合はその柔軟性を活かしてその時々で必要な容量だけ確保したい(スモールスタートし必要に応じてスケールしたい)とお考えのお客様もいらっしゃるかと思います。
PX-Store上のデータが増えてボリュームやStorage Poolの容量を増やしたくなった場合にはPVCの容量を増やしたり、Storage Poolを拡張することが可能です。しかしながらこれらはあくまで「手動」の操作になってしまいます。 オブジェクトの数が少ないうちはあまり負担にはならないかもしれませんが、オブジェクトが増えるにつれ手動での操作は負担が大きくなります。 また、「段階的」に容量を増やしていこうとするとオペレーションの頻度が増えてしまいます。

これらを「自動」で実行できるようにするのが「PX-Autopilot」です。
PX-Autopilotはある条件(ルール)を設け、その条件に合致する状態になった場合にPVCやStorage Poolを自動で拡張してくれます。さらに拡張時に容量をどの程度増やすか指定することができるため、段階的に容量を少しずつ増やしていくといったことも可能です。

条件に合致しているかどうか判断するためにはPortworxの利用状況をモニタリングする必要がありますが、これにはPortworxクラスター上のPrometheusが利用されます。

なお、PX-Autopilotの機能としてはこの他にStorage Pool間におけるボリュームのリバランシングもございますが、本連載は「Portworxの基礎」がテーマですのでPX-AutopilotについてはPVCの自動拡張に焦点を当て動作の様子をご紹介したいと思います。(リバランシングについてはメーカーサイトをご参照ください。)

検証環境

今回は以前のブログ記事でご紹介した「VMware共有アーキテクチャ」の手法でインストールしたPortworxを利用します。 この環境ではメーカーサイトに記載の手順を参照しPX-Autopilotを構成しています。

　

PX-AutopilotによるPVC(ボリューム)の自動拡張

ここではPX-AutopilotによりPVC(ボリューム)を自動拡張してみます。 今回は以下の条件下で自動拡張が行われるようにします。

・ボリュームの50%の容量が使用されたら拡張する
・拡張時は容量の100%を追加する
・10GiBまで拡張可能とする

 条件「拡張時は容量の100%を追加する」については、例えば初期の容量が1GiBだった場合には初回の拡張によって容量が2GiBになり、その次の拡張によって容量が4GiBになります。

事前準備

前述したPX-Autopilotによる拡張の条件は"AutopilotRule"というオブジェクトで定義します。 また、この条件の適用対象となるNamespaceやPVCを特定するためにLabelが利用されます。

今回は以下のようなオブジェクトを作成して動作を確認します。Namespace "autopilot-test"内にAlpineのPodを作成し、StorageClassから動的に作成したPVに対しデータを書き込みます。AutopilotRuleでは"type: expandable"というLabelでNamespaceを、"app: alpine"というLabelでPVCを特定できるようにします。

それでは実際にこれらのオブジェクトを作成していきます。 まずは前述の自動拡張の条件に基づいてAutopilotRuleを作成します。(設定項目の詳細についてはメーカードキュメントをご参照ください。)

さらに以下のNamespace / StorageClass / PVC / Deploymentを作成しました。

Namespace "autopilot-test"内のオブジェクトは以下のようになっています。

また、今回は前述の通りStorageClassを使用していますのでPVがひとつ動的に作成されます。PXCLIでボリュームを確認すると以下のようになっています。

自動拡張の動作確認

動作確認のための環境が整いましたので、PodからPVに対してデータを書き込んでPX-Autopilotの動作を確認します。 今回は拡張の条件として「容量の50%を超えたとき」としていましたので1GiBの半分以上が使用されるようデータを書き込みます。

PX-Autopilotの動作状況を確認するために"kubectl get events"コマンドを実行します。ボリュームへのデータ書き込みから2分ほどしたタイミングでアクションがトリガーされ、拡張が行われていることが確認できます。(AutopilotRuleイベントの詳細についてはメーカーサイトをご参照ください。)

PVやPVCを確認すると容量が倍の2GiBになっていることが確認できます。

"kubectl describe pvc"コマンドを実行すると、容量拡張に成功した旨のイベントが記録されています。

念のためPXCLIでPortworx側からボリュームの見え方を確認してみます。 こちらでも容量が2GiBになっていることが分かります。

PX-AutopilotによるPVCの自動拡張は以上です。

　

まとめ

今回はPX-Autopilotによる自動拡張の機能をご紹介しました。 拡張の条件を設定しておくことで、その条件に合致する状態になると自動で拡張が行われます。 設定にはkubectlを使用することができ、PXCLIを利用する必要がありません。(本ブログ記事の中ではPXCLIの実行結果をご紹介している箇所がございますが、こちらはあくまでボリュームの状態をPortworx側から確認した際の「見え」をお伝えするためのものです。) PX-AutopilotはPortworxの機能ではありますが、Kubernetesから一元的に管理・運用できることがお分かり頂けたのではないかと思います。

また本ブログ記事では詳細に触れませんでしたがPX-AutopilotにはStorage Poolを拡張する機能もございますので、その時々で必要な分だけストレージリソースを確保すればよい(ストレージリソースをオーバープロビジョニングする必要がない)ということになります。 パブリッククラウドのような従量課金の環境において無駄なコストの発生を抑制する効果も期待できそうです。

なお、容量拡張時には一気に最大サイズまで容量を増やすのではなく、「容量のxx%を追加する」というように段階的に容量を増やしていくことができます。クラウドやSDS (ソフトウェア・ディファインド・ストレージ)の柔軟性を活かし、小さな環境から始めて少しずつ自動で大きくしていくことができるのがPortworx (PX-Autopilot)の利点のひとつと言えるでしょう。

 

 

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