ブロードバンドタワーで Scality RING を担当しているポールです。
今回は RING 6 から加わっている Volume Quota 機能についてご紹介します。
容量の上限がないのに、利用上限の設定が必要？
どこか矛盾したような謎かけで始まるのですが、ここから先の話を理解いただくうえで前置きが必要と思われますので、お付き合いください。RING のようなスケールアウトストレージでは、複数のストレージサーバでストレージを構成し、全体で１つの巨大なデータ領域を提供することが可能です。特に RING では、オブジェクト利用とファイル利用（SOFS：Scale Out File System を利用）の両方で、容量には上限がありません（※1）。
※1: RING に定義できるボリューム数、各ボリュームで利用可能な inode の数、すべてのボリュームにファイルを格納する際に使用可能なオブジェクト数(≒キー範囲)などについて、それぞれの上限はもちろんあります。ただし、それらの上限が天文学的な大きさで定義されているため、RING （および SOFS）には容量の上限がありません。このため、ある種逆説的な説明になりますが、実際に利用可能な容量は使用するハードウェア構成に依存します。
しかし、この素晴らしいスケールアウトストレージの特長も、裏を返せば１つの考慮点が浮かび上がります。何年か前に、Public Cloud のオブジェクトストレージが容量無制限になった旨の報道が出た後に、一部の利用者がデータを無制限にアップロードした結果、Public Cloud 側で制限をかけることになった、というニュースがあったことを覚えているかたもいるのではと思いますが、まさに、それとほぼ同じお話です。巨大なストレージを複数の利用者（ユーザもしくはグループ）で使用する場合は、それぞれの利用者に対して利用可能なストレージ容量の上限を設定することでしか、対処できないケースがでてくるということです。RING であれば、ストレージ容量の上限がないからこそ RING の採用を決めたはずなのに、決めた後から利用者管理の観点で上限を設定する必要が出てくる、、、言われてみれば確かに！という話です。もちろん、RING を単一の利用者（もしくは単一の組織）だけで利用する場合や、良識のある利用者だけが利用することを前提にできる場合は、上限を設定しないで運用し続けることも十分可能です。上限の話はあくまでも、状況が異なれば求められる機能も変わる、ということです。
RING で利用可能な Quota 機能の種類
話の前置きが長くなりましたが、ここからが今回の本題です。RING ではファイル利用（＝SOFS 利用）の場合に、利用者に対して個別に容量の上限を設定する Quota （クオータ もしくは クォータ）機能が用意されています。利用可能な Quota は次の３種類です。
- User Quota
- Group Quota
- Volume Quota
RING 5.1 までのバージョンでは、User Quota および Group Quota のみに対応していました。Volume Quota は RING 6 以降での実装になります。背景を私なりに想像してみるのですが、システムに毎日どんどん新しい User や Group が追加されていく上記の Public Cloud のような環境であれば、毎日個別に上限設定を追加する必要があると思います。なので、User Quota と Group Quota の実装が先に必要になったのでしょう。一方で、利用者の良識ある行動を期待できる社内利用のみの RING 環境であれば、個別の User, Group というレベルまで細分化して上限を管理する必要がない場合が多いと思います。そこで利便性の観点から、User や Group の属性とは関係なく、データの置き場であるボリュームそのものの容量上限を設定する機能として、後から Volume Quota の機能が追加されたのだと思われます。
なお RING のボリュームは、それ自体には容量やサイズという属性がありません。容量に上限のないスケールアウトストレージとしてはむしろ適切な設計だと思いますが、ここが他の SAN/NAS ストレージのボリュームとは大きく違うところだと思います。また、３種類の Quota はどれも設定した上限まで予め容量を確保する効果はありませんので、実際に物理容量を使用した分だけが使用量としてカウントされます。他のストレージの Thin Provisioning 機能とは異なる技術ですが、使用感として得られる効果は近いと思います(※2)。
※2: Thin Provisioning 機能は一般に、物理容量よりも大きな容量を仮想的に見せる機能です。Quota 機能は一般に、限りある物理容量を枯渇させないように利用上限を設定する機能なので、本質的には異なる機能です。しかしどちらも、データ置き場に何らかの枠を設定し、実際に使用した容量しか物理容量を消費しない、という観点からは、得られる効果が近いと思います。（読者の皆様には異論があるかもしれませんが、あくまでも私の感覚です）
Volume Quota を実際に設定してみる
環境の前提
CentOS7 上で動作する RING 6.4 を使用します。SOFS の Quota 機能を利用するには、SOFS に対応したコネクタを用意する必要があります。今回は NFS コネクタを使用し、NFS クライアントには Supervisor を使います。なお、Quota 機能を制御するのは RING に対してデータを読み書きする側のコネクタになります。
以下の例では IP アドレスが２つ出てきますので、補足します。
| IPアドレス | 用途 |
|---|---|
| 192.168.18.17 | 1台目のストレージサーバ |
| 192.168.18.33 | NFS コネクタ |
事前準備
普段は事前準備を Web UI で実施するのですが、なぜか今回は CLI にこだわってみます。
RING に vol1 ボリュームを作成し、NFS コネクタを組み込みます。1 は Device番号で、DATA ARC4+2 は実データを保存する DATA (RING) の保護レベル、META 4+ はメタデータを保存する META (RING) の保護レベル(= COS4+)です。7000 番ポートは、RING の内側でコネクタが管理用コンポーネントと連携するためのポート番号です。
# ringsh supervisor addVolume vol1 sofs 1 DATA ARC4+2 META 4+ DONE # ringsh supv2 addVolumeConnector vol1 192.168.18.33:7000 nfs DONE # ringsh supv2 enableVolume vol1 Volume vol1 enabled #
NFS コネクタ上の /etc/exports.conf に Export 設定を追加します。検証環境なのであまり難しいことを考えず、vol1 のルートディレクトリに対して誰でもアクセスOKな設定です。
/ *.*.*.*(rw,no_root_squash)
NFS コネクタ上の /etc/sfused.conf を編集し、 Quota 関連の設定を追加します。Quota はデフォルトで無効です。
"quota": {
"accuracy_step1_enable": true,
"dev": 1,
"enable": true,
"enforce_limits": true,
"rpc_enable": true
},
ここまで終わったら、NFS コネクタを再起動します。
# systemctl restart scality-sfused
実際に Volume Quota を設定する
Quota を設定する際には squotactl というツールを使用します。scality-nasdk-tools パッケージに含まれていますので、RING インストール時に使用したリポジトリを用いてインストールを行います。
# yum install -y scality-nasdk-tools
次のコマンドで Volume Quota を設定します。
# squotactl -b 192.168.18.17:4250 -d 1 setlimits -v 0 0 0 2097152 5242880 864000
-b オプションで使われている 4250 番ポートは、ストレージサーバ上に 6個ある META RING 用ノードプロセスのうち、1番目のプロセスが使用する chord ポートになります。-d オプションの 1 がデバイス番号になり、vol1 を意味します。-v が Volume Quota になります。そこから先の 6つの数字で上限を設定しますが、前半3つが inode 単位で、後半3つがブロック単位の上限になります。今回は inode 単位の上限は設定せず、ブロック単位の上限として soft limit を 2097152 KB(=2GB)、hard limit を 5242880 KB (=5GB)、猶予期間を 864000 秒(=10日) に設定しています。
Volume Quota の効果を確認する
NFS クライアントから vol1 ボリュームをマウントし、df コマンドを実行してみます。
# mkdir -p /mnt/test # mount -t nfs 192.168.18.33:/ /mnt/test # df -h /mnt/test ファイルシス サイズ 使用 残り 使用% マウント位置 192.168.18.33:/ 5.0G 0 5.0G 0% /mnt/test #
サイズの 5GB は Volume Quota の hard limit と一致しており、Volume Quota がボリュームのサイズ上限を定義していることがわかります。次に、3GB のファイルを vol1 に生成してどうなるのかみてみます。
# mkdir /mnt/test/testdir # dd if=/dev/zero of=/mnt/test/testdir/3g.dat bs=1024k count=3072 3072+0 レコード入力 3072+0 レコード出力 3221225472 バイト (3.2 GB) コピーされました、 14.5626 秒、 221 MB/秒 # df -h /mnt/test ファイルシス サイズ 使用 残り 使用% マウント位置 192.168.18.33:/ 5.0G 3.0G 2.0G 60% /mnt/test #
実は 3GB のデータを格納すると、2GB で設定した soft limit を越えてしまいます。このことを確認するために、再度 squotactl を実行して猶予期間を確認します。
# squotactl -b 192.168.18.17:4250 -d 1 report -v type id name ino usage soft lim hard lim blk usage KB soft lim KB hard lim KB ino grace delay ino grace expires blk grace delay blk grace expires volume 1 1 1 0 0 3145728 2097152 5242880 0 - 864000 Fri May 18 15:20:41 2018 #
（一番右側の表示なのでわかりにくいですが）ファイルを書き終わった時間のちょうど10日後の時間が blk grace expires に表示されていました。猶予期間が過ぎる前にやるべきことがいくつかあるわけですが、今回は Volume Quota を設定し直すことで解決してみます。soft limit を 5GB、hard limit を 10GB に変更します。
# squotactl -b 192.168.18.17:4250 -d 1 setlimits -v 0 0 0 5242880 10485760 864000 # df -h /mnt/test ファイルシス サイズ 使用 残り 使用% マウント位置 192.168.18.33:/ 10G 3.0G 7.0G 30% /mnt/test # squotactl -b 192.168.18.17:4250 -d 1 report -v type id name ino usage soft lim hard lim blk usage KB soft lim KB hard lim KB ino grace delay ino grace expires blk grace delay blk grace expires volume 1 1 1 0 0 3145728 5242880 10485760 0 - 864000 - #
使用量が soft limit を下回ったので、猶予期間が消えました。また、サイズも 10GB で広がっています。このような流れで Volume Quota を利用することで、 RING に設定したボリュームのサイズ上限を管理することが可能になります。
今回の記事は以上になります。いかがでしたでしょうか。
今後も引き続き Scality RING 関連の記事を予定していますので、ご期待ください。
本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。