OpenShift環境のストレージ利用に有効なContainer Storage Interface ~ドライバで違いを吸収し、ストレージ操作を標準化

本稿では、OpenShift環境でデータを保管するのに必要な永続ボリュームについて、バックエンドのストレージの選定や、OpenShift 4以降で使用可能になったContainer Storage Interfaceの概要と実際の使用方法、考慮点について説明する。

OpenShift環境のストレージ 

コンテナで稼働するアプリケーションのデータやOpenShiftのログ、統計情報などを保管する必要がある場合、データを永続化する仕組みが必要となる。

OpenShift環境ではPersistent Volume(永続ボリューム。以下、PV)と呼ばれるバックエンドのストレージを抽象化したリソースによって、コンテナのライフサイクルから独立した形でデータを永続化することが可能である。

開発者はPersistent Volume Claim(永続ボリューム要求。以下、PVC)を使用してコンテナの稼働に必要なストレージを要求することで、バックエンドのストレージに関する知識がなくてもPVリソースを要求できる。

PVには、バックエンドとなるストレージに依存する3つのAccess Modesがあり、コンテナからのアクセス方法によって適切に選択する必要がある。

また事前にPVを作成する必要があるものと、PVCによって動的にPVがプロビジョニングされる(Dynamic Provisioning)ものがある。OpenShiftが提供するボリューム・プラグインでサポートされているストレージには、図表1がある(出典:OpenShift Documentation)。

図表1 OpenShiftでサポートされているストレージ

OpenShift環境で使用可能なストレージ 

OpenShiftでバックエンドのストレージを使用する方法は2つある。1つはOpenShiftの提供するプラグインを使用する方法、もう1つはIBM Container Storage Interface(以下、CSI)を使用する方法である。

Container Storage Interface

CSIとは、Cloud Native Computing Foundationで定義されたContainer Orchestrator(CO)で利用可能な業界標準のストレージ・インターフェースである。

図表2 CSIのイメージ

CSIではコマンドとオプションが共通化されているため、COのユーザーはバックエンドのストレージを意識することなく利用できる。

また、各ストレージ・ベンダーがCSIに準拠したプラグインをCSIドライバとして開発・提供することで、ストレージ機器に搭載されているさまざまな機能をCOでも利用できる。

CSIドライバは通常コンテナ・イメージとして提供され、提供元のベンダーによりサポートされる。バックエンドのストレージとして異なるストレージを複数使用する場合は、それぞれに対応するCSIドライバを構成する必要がある。

CSIで定義されている機能例には、以下がある。

動的プロビジョニング
スナップショット
クローニング
ボリューム拡張
ロー・ブロック

IBMの提供する2つのCSIドライバ

IBMは提供するストレージ製品に合わせて、「Block Storage CSIドライバ」と「Spectrum Scale CSIドライバ」という2つのCSIドライバを提供している。

Block Storage CSIドライバ
DS8000/FlashSystemなどのブロック・ストレージに対応したドライバ。Volume(LUN)に対応したPVを静的・動的に作成したり、スナップショット、クローニングといった機能を提供する。Access ModesはReadWriteOnce(RWO:1ノードからのアクセス)。

Spectrum Scale CSIドライバ
Spectrum Scale/ESS(旧GPFS)などのファイル・ストレージに対応したドライバ。ディレクトリ、ファイルセットに対応したPVを静的・動的に作成する。またSpectrum Scale固有の機能として、複数ファイルシステムへのPV作成や、リモート・クラスタにPV作成が可能。Access ModesはRWO/ReadWriteMany(RWX:複数ノードからアクセス可能)。

Block Storage CSIドライバの構成

Block Storage CSIドライバは、図表3のように構成される。

図表3 Block Storage CSIドライバの構成例

Block Storage CSIドライバをインストールすると、CSI Controllerポッド(ibm-block-CSI controller)とCSIポッド(ibm-block-CSI node)がWorkerノードに導入される。

CSI ControllerはMasterノード内のAPIサーバーからのリクエストを受け、ボリュームの管理、操作(CreateVolume、DeleteVolumeなど)をManagement Path経由で実行する。

CSIノードはKubeletと通信して、Workerノードでのボリュームの動作を管理する(NodePublishVolume、NodeUnpublishVolumeなど)。

Spectrum Scale CSIドライバの構成 

Spectrum Scale CSIドライバは、図表4のように構成される。

図表4 Spectrum Scale CSIドライバの構成例

Spectrum Scaleのクラスタと、Kubernetes/OpenShift Clusterが同居するような形で構成される。ScaleのClientノードのすべて、もしくは一部がWorkerノードを兼ねる。

またKubernetes/OpenShiftには含まれないScale GUI Serverから、CSIドライバに対して、PV作成、マウントなどの命令が実行される。

このドライバの特徴として、リモートのSpectrum Scaleのファイルシステムをマウントする機能も提供している(図表5)。

図表5 Spectrum Scale CSIドライバのリモート・マウント機能

これによりさらに高い拡張性、柔軟性を備えたストレージの提供が可能となる。

また、Spectrum Scale Container Native Storage Access のソフトウェア機能により、Spectrum Scale ClientがPodとして稼働させられる(図表6)。

図表6 Spectrum Scale Container Native Storage Accessの構成イメージ

CSIドライバのリモート・マウント機能と連携して、Kubernetes/OpenShift Clusterにストレージを提供可能となる。

Block Storage CSIドライバの挙動

ここからは、Block Storage CSIドライバが、どのようにOpenShiftおよびIBMのBlock Storageと連携するかを、具体的なオペレーションを交えながら紹介する。

今回使用した機器構成は、図表7のとおりである。

図表7 Block Storage CSIドライバの具体的な構成例

ストレージはIBMのCloud StorageであるSpectrum Virtualize for Public Cloud(SV4PC)で、OpenShiftのクラスタとはネットワーク経由で接続され、管理系接続に加えてPVアクセス用にWorkerノードからiSCSI接続している。

以下に、CSI ドライバに関する用語を説明する。

Array Secret
CSIドライバがストレージ装置に接続、ログインするにあたり、使用するユーザー、パスワードを定義する

Storage Class
使用するストレージ・プール(RAID Arrayの集合)やボリュームの属性値(Thin/Dedupなど)を設定する

Persistent Volume Claim(PVC)
Podから使用するPVを作成する定義。作成、使用するPVごとに作成する

Snapshot/Snapshot Class
PVの静的断面(スナップショット)を取得する。バックアップやクローンで使用。対象のボリュームや保管先のプールを指定する

いずれもの場合もYAMLというテキスト形式のファイルを作成して、ocコマンドで実行する(OpenShiftの場合)。

Array Secretで開発者単位にユーザーを、Storage Classで使用するプールを分けて定義することで、マルチ・テナンシーの実現も可能となる。

これらはユーザーやストレージ・プールに合わせて一度定義を作成しておけばよく、PVCやSnapshotのYAMLはそれぞれPV、Snapshot、クローン作成時に新たに作成・実行する(図表8)。

図表8 YAMLファイルの関係

このYAMLファイルの形式は、ストレージが異なってもほぼ共通化されており、各ベンダーが提供するCSIドライバがそれぞれの違いを吸収する。

そのためユーザーから見ると、ストレージごとに異なるオペレーションを覚える必要がない。それがCSIドライバの利点である。

Persistent Volume/Snapshotの作成 

開発者がPVを必要とした場合にはPVCのYAMLファイルを作成し、実行することで、SV4PCにボリュームが作成され、それに紐づいたPVがOpenShift上に作成される(図表9)。

図表9 PVの動的プロビジョニング、アサインの流れ

StatefulsetからこのPVを呼び出すと、SV4PC側ではWorkerノードに対してボリュームがマップされ、Podに対してPVがアサインされる。

実際のOpenShiftのオペレーションとしては、ocコマンドでPVCのYAMLを実行すると、ストレージ上でボリュームが作成され、OpenShift上ではPVが作成される(図表10)。

図表10 ocコマンドによるPVの作成

また作成したPVのSnapshotを取得する場合は、Snapshotを取得するYAMLを作成・実行することで、SV4PC上ではボリュームのSnapshotが取得され、OpenShiftに対応するPVのSnapshotが作成される(図表11)。

図表11 PVからSnapshot作成の流れ

こちらもPVと同様、ocコマンドでSnapshot作成のYAMLを実行すると、ストレージ上でPVからSnapshotが作成され、それに紐づくSnapshotがOpenShift上で作成される(図表12)。

図表12 ocコマンドによるSnapshotの作成

CSIドライバのメリット 

最後にCSIドライバを利用するメリットをまとめる。

1 開発者のストレージ利用の利便性向上、開発の高速化

ほぼテンプレート化されたYAMLファイルを使用するだけで、ストレージの違いを吸収し、ストレージごとに異なるオペレーションを覚える必要がないので、利用者にとって利便性を向上させられる。

またPVの作成、スナップショット、クローニングなどを開発者自身で行うので、管理者とのやり取りの負担や時間を短縮化でき、開発の高速化につながる。

2 柔軟なストレージの選択、利用

アプリケーションによってサポートされるストレージ、要件や環境によって求められるストレージは異なる。

たとえば比較的小規模なOpenShift環境ではOpenShift Container Storage、高いパフォーマンスが求められる場合にはFlashSystem、ファイル・ストレージやNAS、高い拡張性が求められる場合はSpectrum Scaleなどがある。

これらの環境に合わせてそれぞれにストレージを用意したとしても、オペレーションを統一した柔軟な利用が可能となる。

3 ストレージ管理者の負担減

利用者ごとのユーザー、プール定義などを管理者があらかじめ行っておけば、以降のボリュームやスナップショットの作成は開発者自身で行える。

これにより、ストレージのマルチ・テナンシー化および迅速な開発作業が実現でき、管理者にとって運用管理の負担を軽減できる。

コンテナ環境でストレージを利用する際は、より簡単に、かつ柔軟に利用できるCSIドライバを積極的に活用していただきたい。

 


著者|

坂根 新之介氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープンテクノロジー
ITスペシャリスト

2004年、日本アイ・ビー・エム システムズ・エンジニアリングに入社。2014年までPower Systemsのテクニカルサポートを主に担当。2015年からIBM Spectrum Virutalize/Spectrum Scaleのテクニカルサポートを担当。プロジェクトサポートにも並行して参画し、主にインフラの構築、運用、移行を担当する。

 

 

今井 慶太郎氏

日本アイ・ビー・エム システムズ・エンジニアリング株式会社
オープンテクノロジー
シニアITスペシャリスト

2002年、日本IBMに入社。以来、オープン系ストレージ製品全般(FlashSystem/DS8000/Tape/Spectrum Protect/SANなど)のSMEとして、Pre/Post Salesの各フェーズで提案、PoC、設計、導入構築支援、障害対応など多数のプロジェクトに従事している。

 

[i Magazine・IS magazine]

More Posts