NFS Kubernetes Persistent Volumesに関するDell PowerStoreのFile Capabilities

 

Itzikr's Blog 日本語翻訳版

＊オリジナルブログは以下URLから参照可能です

https://volumes.blog/2022/04/14/dell-powerstore-file-capabilities-for-nfs-kubernetes-persistent-volumes/

 

我々のお客様は、以前から変わらないもの、もしくはモダンなものなどのバラエティーに富んだワークロードを持っています。これらのワークロードはそれぞれ様々なネットワーキングプロトコルを利用しているインフラに関連しています。ブロック、ファイルそしてvVolsを単一アーキテクチャで扱うことができるPowerStoreは、これらの異なる要望から構成される複数の目的を、ミッドレンジストレージが元々持っているコストエフェクティブさを失うことなく、達成します。PowerStoreは最高のワークロードのフレキシビリティを提供し、ITをシンプルで集約されたインフラにすることが出来るのです。

 

 

Dell PowerStoreはモダンデータセンター向けにデザインされたネイティブ・ファイルソリューションを提供します。このファイルシステムのアーキテクチャはとてもスケーラブルで効率的、パフォーマンスフォーカスであり、そしてフレキシブルです。PowerStoreはリッチなサポート機能セットも持っており、その機能により部門の共有やホームディレクトリなどの幅広いユースケースをサポートします。これらのファイル機能は統合されているので、追加のハードウェア、ソフトウェア、ライセンスは不要です。ファイル管理、監視、そしてプロビジョニング機能はシンプルで直観的なHTML5ベースのPowerStore Managerを通じて処理されます。このブログ投稿ではPowerStore CSIドライバのNFSに関する部分とそのモダン・クラウドネイティブ・アプリケーション向けのユニークな機能にフォーカスします。

 

KubernetesではPersistentVolumeClaimsを利用してPersistentVolumesをダイナミックにプロビジョンすることができます。Pod達はこれらのClaimsをボリュームとして扱います。PVCのアクセスモードはいくつのノードがそれに対して接続を確立できるかを決定します。PersistentVolumeはstorage providerによりサポートされているどのような方法によってもホストにマウントされることが可能です。Dell PowerStore CSIドライバは以下にリストされている3種類のアクセスモードをサポートし、異なる機能を持ち、それぞれのPVのアクセスモードはその個別のボリュームによりサポートされている特定のモードが設定されます。例えば、NFSは複数のRead/Writeクライアントをサポートすることができますが、ある特定のNFS PVはある特定のサーバに対してRead-onlyでエクスポートされているかもしれません。それぞれのPVは独自のアクセスモードセットを所有しそれはその特定のPVの機能を表現しています。

 

それらアクセスモードとは：

- ReadWriteOnce – ボリュームは一つのPodからread-writeとしてマウント可能

- ReadOnlyMany – ボリュームは複数のPodからread-onlyとしてマウント可能

- ReadWriteMany - ボリュームは複数のPodからread-writeとしてマウント可能

 

KubernetesにおけるPCVへのスタンダードなアクセスモードはReadWriteOnceであり、それはボリュームとそのボリュームを利用しているアプリケーションとの間で1対1にマッピングされます。このアクセスモードはデータベースやメッセージバスなどのほとんどのクラウドネイティブワークフローに適しています。ReadWriteManyは複数アプリケーションから同じボリュームへの安全なアクセスを許可し、Kubernetesにて異なるタイプのワークロードを実行することを可能とします。

 

ReadWriteManyボリュームには多くのユースケースがあります。いくつかのアプリケーションは並列的なスケーリングの恩恵を受けることが出来るでしょう。例えば、実行時にダイナミックに作成されるコンテンツと、バックエンドボリュームにある静的なコンテンツを統合させるWebサービスなどです。追加のPodを利用してそのようなサービスをスケーリングすることはとても望ましく、KubernetesのDeploymentを利用すればもちろんスケーリングはとても簡単です。ReadWriteManyボリュームはいくつかのアプリケーションタイプにHAを追加する場合も利用できます。

 

RWXボリュームを利用する別のよくあるユースケースとして「legacy workloads」と呼ばれるものを実現することがあります。共有ファイルシステムへのアクセスと共に書き込みが行われるアプリケーション群やアプリケーションのグループ群があることを考慮するのです。

 

これらの絶えず変化しているストレージへの要求をサポートするために、我々はとてもスケーラブルで効率的、パフォーマンスが良く、フレキシブルなストレージソリューションを提供する必要があります。

 

 

パフォーマンスの観点からは、伝統的にNFSはSANベースのPersistent Volumesより遅いとされていますが、PowerStoreではこれはもはや当てはまりません。

 

PowerStoreは非常にスケーラブルで効率的、パフォーマンスが高く、フレキシブルな64ビット・ファイルシステム・アーキテクチャを利用します。また、PowerStoreはデータのセキュリティや保護、そして容易に監視できるようにするためのリッチなファイルのサポート機能も持っています。

 

PowerStoreファイルシステムは高パフォーマンス提供のために調整され最適化されています。それに加え、Non-Volatile Memory Express (NVMe)ドライバやdual-socket CPUなどのプラットフォームコンポーネントが、大きなワークロードを扱っている時でも低いレスポンスタイムを維持することを可能とします。

 

PowerStoreファイルシステムの成熟した構造安定性とこれらのサポートしている機能が、PowerStoreが多くのファイルレベルストレージのユースケースとして利用されることを可能としています。

 

Network File ShareもしくはNFSはネットワークを介してブロックストレージを提供します。我々の提供するCSIの助けにより、お客様は同じストレージリソースを複数のKubernetes Podにわたってマウントすることができます。これは様々なシステムに跨り情報を保存や共有するための素晴らしい選択です。一般的にHAモードにおいてアプリケーションの複数インスタンスを提供したい場合や、近年のAI/MLワークロードによく要求されるようになってきている、アプリケーションの複数インスタンスが読み書きのアクセスを同時に実施するような場合に助けとなります。Kubernetesの共有ファイルシステムはデータを必要とする、分析や機械学習、コンパイルやテストなどの開発ワークロードのようなステートフルなアプリケーションにとって素晴らしいものです。

 

このポストでは、Dell PowerStore CSIドライバを利用してNFS dynamic persistent volumeをReadWriteManyアクセス設定でセットアップし、そのファイルの能力を活用できるk8sのアプリケーションをデプロイします。

 

• Mount：コンテナに外部ストレージへのアクセスを可能とする
• Persistent：この外部ストレージはコンテナがシャットダウンした後もアクセス可能
• Dynamic：外部ストレージの作成とライフサイクルはユーザによる管理が行われない
• NFS：外部ストレージはNetwork File Systemプロトコルを経由して提供される
• ReadWriteMany：複数コンテナがそのストレージに書き込みモードで同時にアクセス可能

PowerStore CSIドライバのインストール方法詳細はここから確認できます

 

KubernetesでPowerStoreのファイル機能を活用するためには、最初にNASサーバを作成する必要があります。PowerStore ManagerのNASサーバページに行き作成ボタンをクリックし、そこでNASサーバの名前やネットワーク設定などの詳細を入力し、そして我々が有効にしたいファイルプロトコルを選択し、ウィザードを続けます。

 

CSIドライバを利用したNFSボリュームの作成開始のために、我々が必要なことは新しいファイルに対するStorageClassを作成することで、そのprovisionerには我々のPowerStore CSIドライバが設定される必要があり、fstypeとしてはNFSを指定し、PowerStoreアレイIDと、今作成したNASサーバも指定します。

 

これで、我々はアプリケーションをデプロイする準備が出来ました。これから一つのpersistent volumeに接続された3-Podからなるフロントエンドアプリケーションをデプロイしていきます、それに加えそれら全てのPod間トラフィックのロードバランスを行うサービスを持ち、アプリケーションはそのpersistentに全てのPodから同時読み書きアクセスが必要であるとします。

 

このアプリケーション作成のためにkubectlコマンドを実行すると、50GBのボリュームが作成されたことを確認することができます。

 

その詳細をクリックすることにより、アクセスモードがRWXに設定され、ストレージクラスはpowerstore-nfsに設定されていることが確認できます。

 

PowerStore Managerより、そのサイズもアップデートされていることを見ることができます。File Systemsタブに行くと、CSIドライバにより作成されたファイルシステムとRWX k8s Persistent Volumeを見ることができます。NFS ExportsタブではCSIドライバが自動で読み書きのパーミッションを、それぞれのアプリケーションPodは異なるノード上で動作している一方で全てのPodは同時に読み書きを必要としているので、全てのWorkerノードに追加したことを見ることができます。

 

 

アプリケーションWebページを更新するたびに、Persistent Volumeに書き込まれる訪問カウント数が増加し、それは異なるPodからの情報に基づきます、これは近頃のクラウドネイティブアプリケーションが必要とするReadWriteManyボリューム機能に関するよい例となります。

 

ここでそのサイトへの訪問数の増加が期待できるとしましょう、我々はPodの数をスケールアップする必要があるのですが、k8sとPowerStore CSIドライバのおかげで、あなたがどのようなタイプの人かによって、ボタンをクリックするようなシンプルな方法、もしくは一つのkubectlコマンドによって実現できます。もし我々がWebサイトに戻ると、我々は既存のPodと共にDeploymentに追加された新しいPodに対してリダイレクトされていることを見ることができ、両方とも同じReadWriteMany Persistent Volumeに接続されています。

 

今、利用しているPersistent Volumeの容量が足りなくなったので、Webアプリケーションに影響を及ぼすことなくサイズを増やす必要が出てきたとします。

 

ここでも我々が行わなくてはいけないことはPersistent Volume Claimオブジェクトのサイズを変更することだけです、例えばサイズを50GBから100GBへ2倍にしたいとしたら、単にsaveをクリックするだけでその変更はk8sとそのPowerStore上の共有に反映され、アプリケーションへの影響は全くありません。

 

Tomer Eitanによるゲスト投稿

 

 

翻訳者：Uehara Y.