ストレージ管理者のためのOpenShift Virtualization入門【OpenShift環境におけるストレージの基本】

※本記事は OpenShift Virtualization アドベントカレンダーの 5日目の記事です。 qiita.com

目次

はじめに

皆さんこんにちわ、Red Hat Global Learning ServicesでLearning Solution Architectを担当している坂井 大和(@lab8010)です。

主にX.com上でRed Hat製品やサービスについて配信をしているので、もしよければフォローくださると幸いです。

この記事では、『Red Hat OpenShift Virtualization環境では、ストレージ製品ってどう使われるの?』という疑問に対して解説します。

なお、本記事で想定するストレージ=基本的に物理ストレージ製品を想定します。

私は前職でストレージを取り扱うベンダーに居たこともあり、ある程度はストレージ製品について心得があるので、忘れないうちにそうした知見を残しておきたいという個人的な狙いもあります。

【積極採用中!】Red Hat 採用に関するお知らせ

Red Hatでは事業拡大に伴い人材を募集しています。
本記事でご紹介している『OpenShift Virtualization』に関するコンサルタントを募集しています。もし少しでも興味がある方は、ご応募または本記事を執筆している私坂井までお気軽にDMをください。(X / Linkedin)

redhat.wd5.myworkdayjobs.com

この記事のゴール

この記事を読み終わった頃には、読者様が次のことが出来る状態になって頂きたいと考えています。

  1. Red Hat OpenShift Virtualizationにおけるストレージ基礎
  2. 具体的なストレージ製品の管理画面から、構成の様子を読み取る力を身につける

なお、この記事はRed Hat OpenShift Virtualizationを対象として書きますが、ほとんどの内容は仮想マシンだけでなくコンテナワークロードにも対応する話となります。

それでは、早速本編に入っていきましょう。

Q. Red Hat OpenShiftって何?そもそもそこがわからない。

A. Red Hatによってカスタムされた商用環境向けKubernetesです。

https://kubernetes.io/ja/

Kubernetesには、Linuxカーネルを使用するOSのように色々なディストリビューションがあり、Red Hat OpenShiftはそのうちの1つと考えてください。

詳細はこちらの記事をお読みください。

rheb.hatenablog.com

Q. Red Hat OpenShift環境では、従来のブロックストレージやNASは使用可能なのか?

A. はい、使用が可能です。

KubernetesはCSI(Container Storage Interface)と呼ばれるインターフェースを通じてストレージ製品と連携します。

CSIはネイティブなKubernetesが持つ仕組みであるため、Red Hat OpenShift固有の概念や規格ではありません。

kubernetes.io

CSIを通じて物理的なストレージに対して操作を行うにはストレージメーカーが提供するCSIドライバー*1を入手およびOpenShiftにインストールする必要があります。

このCSIドライバーを使用することで、OpenShift経由で物理ストレージに対してデータ保存域の作成リクエストや削除などの管理操作が可能となります。

この際、OpenShiftはKubernetesの世界で登場するリソース*2という概念を通じて使用したいストレージの機能や構成を定義し、CSIドライバーを通じて物理ストレージが解釈可能な命令に変換して転送するという一連の処理を行います。

これを図解してみたものが次の図です。

OpenShiftやKubernetesのレイヤーからストレージ領域を使用するための流れ

以下のページに掲示のあるアイコンで示される要素1つ1つがKubernetesの世界におけるリソースです。

github.com

この中でも特にストレージに関係するリソースとして次のようなものが挙げられます。

Storage Class - どんな特徴のストレージかを定義するリソース

sc-128.pngkubernetes.io

通称SC、SCを複数持つことでシーンごとに使いたいストレージの種別を管理できます。例えば、1台のストレージ製品がiSCSIブロックアクセスとNFSによるNASアクセスに対応している場合、そのストレージ製品に対して2種類のストレージクラスを準備し、それを使い分けることで利用したいストレージを指定可能となります。

例えばDell TechnologiesのUnityというストレージにおけるStorage Classを定義するマニフェストファイルの様子がこちらです。

引用元 https://dell.github.io/csm-docs/docs/concepts/csidriver/features/unity/

 

parameters配下を読むと、どのようなストレージ特性かが読める
このSCを使ってストレージ領域をリクエストすると
arrayIdが一致するDell Unityが指定され、その中のpool_7という領域内に
NFSによる保存域を作成するような構成が宣言されています

また、別のストレージメーカーの例として、PureStorage社のPortworxのStorageClassは以下のようになっています。

引用元 

helm/charts/portworx-daemonSet/templates/portworx-storageclasses.yaml at master · portworx/helm · GitHub

1つのマニフェストファイルに3つのStorage Classが定義されています

ここでお伝えしたいポイントは、『StorageClassに含まれる内容はベンダーや機器によって大きく異なる』ということです。

特に、StorageClassにはストレージによる暗号化やレプリケーションなども含むことができるので、KubernetesやOpenShift環境でストレージ固有の機能を使用する場合はその機能を含むStorageClassの作成と使用が必要となってきます。

クラスによって提供されるサービスが異なるというのは、エコノミークラス、ビジネスクラス、ファーストクラスで提供されるサービスが違う航空機のようですね✈️

Persistent Volume Claim - 希望するボリューム構成を定義する

pvc-128.png

通称PVC、Kubernetes環境において使用したい永続ストレージのリクエスト内容を定義するものであり、この中に次の要素を含めます。

  • どのストレージクラスに、
  • どのくらいの容量が必要で、
  • どのようなアクセスモードが必要で
  • どのようなボリュームモードが必要か

次の例は、Dell Unityに対し2GiBの永続ストレージをリクエストするためのPVCです。

上記で確認したStorageClassであるunity-nfs(下図一番下の行)

引用元 https://dell.github.io/csm-docs/docs/concepts/csidriver/features/unity/

Persistent Volume - StorageClassとPVCの内容に基づき生成された永続ストレージ

pv-128.png

kubernetes.io

通称PV、永続的にデータを保存する箇所であり、物理ストレージ上のLUNやNFS共有域に関連づく論理的なオブジェクトです。

PVCの作成により、対応するPVがKubernetesやOpenShiftのレイヤーで作成されるが、
物理ストレージのレイヤーではこのPVに対応するLUNやNFSの作成が作成されます。

このため、物理ストレージ上の管理ソフトウェア上ではKubernetesやOpenShift上で作成命令されたPVC/PVに対応する新たな記憶域の様子が次のように確認できます。

Dell Technologies PowerStore上のBlock StorageをリクエストするPVC
VOLUME名のcsivol-239a9c2dc4に注目

Dell PowerStore Manager上のBlockストレージの様子
上記のVOLUME名と同じ値でストレージのVolume(LUN)が作成されている

HPEのNimble Storageでも同様の状況が確認できます。

HPE Nimble Storage上に永続ストレージを作成するためのPVCとPV

HPE Nimble Storageの管理ツール上のBlockストレージの様子
上記のkubectl get pv, pvc -o nameで取得した名前と同じ値で
ストレージのVolume(LUN)が作成されている


今回参考にした2つのストレージの操作の動画は次の2つの動画です。

www.youtube.com

www.youtube.com

 

ここでいう、命令の変換や転送などを受け付ける存在こそがCSIドライバーです。

CSIドライバーはストレージソリューションを提供する各ベンダーが提供します。

ストレージ利用者はこれをストレージベンダーから入手、セットアップをすることでストレージが利用可能となります。

Q. ブロックストレージの場合は上記の解説で分かったが、NASの場合の動きが知りたい。

A. 以下の解説をご覧ください。

次の動画では、実際にその様子をデモンストレーションしています。

www.youtube.com

この動画では、Red Hat OpenShiftとDell TechnologiesのPowerStoreと呼ばれるユニファイドストレージ*3を使用して、上述しているPVを作成するとてもシンプルなデモを実施しています。

上記のデモでは、PVC(Persistent Volume)を通して『こんなストレージが欲しい』というリクエストをOpenShift Web Console上で作成をしたことで、そのリクエストがDell Technologies PowerStoreに転送され、リクエストを受け付けたPowerStoreが要望に応じたストレージ領域をNFS共有域として準備したという結果を確認しています。

Q. (上記の動画では)PVCを作成した際に、なぜPowerStoreに保存域が作成されたのか?

A. これもやはりStorageClassによる指定内容に基づいているから。(上記ブロックストレージの箇所ですでに解説済み)

上記の動画の1:34あたりをご覧頂くと、SC(Storage Class)の紹介をしています。

このSCは、PVCで定義したストレージ要件をどのストレージで叶えたいかを含む定義です。以下の図は動画内で表示されたSCのマニフェストを拡大表示したものです。

動画内で登場したStorage Classのマニフェストファイルの内容
  • 行番号25では、csi-powerstore.dellemc.comとあるため、このストレージクラスを使用するとDell PowerStoreに対してストレージ保存域が作成されます。
  • 行番号 27では、nfsの記載があるため、このストレージクラスを使用するとNFS保存域常にデータが保存される領域が確保されます。
  • 行番号29では、ストレージが持つ一意のIDが記載されていおり、このIDと一致するDell PowerStoreに対する命令として処理されます。

上記のSCを利用し、実際にストレージ領域をPVCを通じてリクエストした結果が次の図です。

SCでは『どのストレージで、どんな特性を持つ保存域を使用するか』を定義し、

PVCでは『どれくらいの容量で、どんなアクセスモードにするかなど』を定義します。

どちらもストレージに対する設定/構成といえばそうかもしれませんが役割が違います。

結果として、上記の2つのリソースが定義した構成を持つPVが払い出されます。

Kubernetesのレイヤーと物理ストレージのレイヤーの俯瞰図

なお、本記事の本題であるOpenShift Virtualizationにおける仮想マシンにおいても、ここで登場するPVC/PV/SCの概念は使用します。

Q. つまりPVとは、VMwareのvmdk/Hyper-Vのvhdx/Nutanixのvdiskのような存在か?

データを保存する媒体という性質で言えば、その解釈は非常に近いと言えます。

PV自体はKubernetesやOpenShiftのレイヤーに存在する論理的な存在であり、データ実体を収納しているのはあくまでもブロックストレージのLUNやNASの共有保存域です。

上記の形式に近い仕組みとしては、VMwareのVirtual Volumes(VVOL)*4 はかなり近い考えだと言えます。

blogs.vmware.com

あとがき

みなさんお気づきでしょうか。

OpenShift Virtualizationとストレージの連携について書こうと思っていた所が、どちらかというとOpenShiftや物理ストレージの内容にかなりよった記事であることに...

しかし、この記事の読者層の多くはおそらく『OpenShift Virtualizationをこれから使っていこうと考えている現役仮想化エンジニア』だと考えています。

ストレージ製品への適切な理解は、仮想化基盤において欠かせない知識です。
仮想マシンのデータを預かるストレージ製品、もしクリティカルな障害が起きた場合仮想マシンの全停止など業務停止クラスの影響が予想されます。

KubernetesをベースとしたRed Hat OpenShiftでは、vSphereやHyper-V、Nutanixなどの仮想化基盤とは全く異なる仕組みでストレージを制御するため、まずはこの記事を通じて、どのような差分学習をすればいいのかを掴んでいただくことで、将来のトラブルを少しでも回避できるようになると言えます。

余談ではありますが、私自身もKubernetesのリソースを通じたストレージの利用の仕組みへの理解は最初は苦戦しました。

この記事を通じて、少しでもKubernetesやOpenShiftにおけるストレージの連携の仕組みを理解できた!という人が増えてくれると嬉しいです。

また、OpenShift Virtualizationに向けたストレージ関連記事はこの後も掲載予定です。

以上の内容をもち、本記事の締めとしたいと思います。

この記事の内容が、少しでもRed Hat OpenShift Virtualizationを活用した組織づくりのお役に立てば幸いです。

*1:CSIドライバーのサポートは、それを提供するストレージメーカーにより提供されます

*2:ここでいうリソースとは、CPUやメモリ、ディスク容量などの物理リソースではなく、Kubernetesの世界で登場する論理的な管理単位の総称です。

*3:ブロックアクセスやファイルアクセスなどの複数のデータアクセス手法に対応したストレージ

*4:VVOLはvSphere 9にてリタイアが決定しています。https://knowledge.broadcom.com/external/article?articleId=401070

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。