ブロードバンドタワーで Scality RING を担当しているポールです。
2017年に Lustre の HSM 機能と Scality RING の組み合わせを試した記事（その１）と（その２）の続きです。
（その２）では Lustre ファイルシステムを構成し、コマンドベースで HSM 動作を確認するところまで進みました。
（その３）ではポリシーベースで HSM 動作を制御する Robinhood のインストールから始まります。
・・・ところで、本題に入る前に、小話です。（その１）でも Lustre HSM を試すきっかけになったイベント会場の場面で登場した某本部長ですが、私との会話では Robinhood （ロビンフッド）のことをかなりの頻度でロビンソンと言い間違えます。「ポールさん、ロビンソンのブログ記事はどんな感じ？」というノリです。そこで、そもそもロビンフッドってなんのことだったかな？と思いインターネット検索で調べてみました。どうやら中世イングランド、リチャード獅子心王の時代に活躍した「弓の名手で義賊」という架空の人物のことで、過去にいくつか映画も製作されているようです。そして、某本部長がよく間違えてしまうロビンソンはというと、ロビンソン・クルーソーというこちらも架空の人物で、漂着した無人島を舞台にしたイギリスの作家による冒険小説が有名です。どちらもイギリス由来の架空の人物なので混同してしまうのかもしれませんが、決してロビンソンではありませんので、くれぐれも皆さんは間違えないでください。
今回構築を進めているテスト環境の全体図を（その１）から引用します。
Robinhood のビルドとインストール
Robinhood は CentOS や EPEL 等のリポジトリに入っているわけではありませんので、yum で楽々インストール、というわけにはいきません。GitHub からクローンしてビルドする必要があります。copytool を動かしている Lustre クライアントとは別のLustre クライアントに導入してください。
Robinhood をビルドおよび動作させるために、私の環境では CentOS 7.4 に対していくつかパッケージを追加する必要がありました。依存性もあり、様々なパッケージがインストールされました。
yum install -y git flex bison libtool mariadb mariadb-devel mariadb-server glib2-devel libuuid-devel libattr-devel
パッケージ追加後は以下のコマンドを淡々と実行していくと、ビルド（RPM の作成）が終わります。
git clone https://github.com/cea-hpc/robinhood.git cd robinhood/ ./autogen.sh ./configure make rpm
生成された RPM です。これらを yum localinstall でインストールします。
[root@Client2 robinhood]# ls rpms/RPMS/x86_64/ robinhood-adm-3.1.3-1.x86_64.rpm robinhood-debuginfo-3.1.3-1.lustre2.10.el7.centos.x86_64.rpm robinhood-lustre-3.1.3-1.lustre2.10.el7.centos.x86_64.rpm robinhood-tests-3.1.3-1.x86_64.rpm robinhood-tools-3.1.3-1.lustre2.10.el7.centos.x86_64.rpm robinhood-webgui-3.1.3-1.x86_64.rpm [root@Client2 robinhood]#
yum localinstall -y rpms/RPMS/x86_64/robinhood-*.rpm
今回使用した Robinhood のバージョンは、2018年2月時点で最新の 3.1 系になります。Lustre クライアントが入っている環境であれば、Lustre と組み合わせられるようにビルドされていることがわかります。
[root@Client2 ~]# robinhood --version
Product: robinhood
Version: 3.1.3-1
Build: 2018-02-XX XX:XX:XX
Compilation switches:
Lustre filesystems
Lustre Version: 2.10
Address entries by FID
MDT Changelogs supported
Database binding: MySQL
Report bugs to: <robinhood-support@lists.sourceforge.net>
[root@Client2 ~]#
Robinhood を動かすための事前準備
Lustre ファイルシステムと copytool の準備
（その２）の流れに沿って実施してください。copytool は Robinhood が動作する仮想マシンではなく、別の Lustre クライアントで動作させてください。
Lustre ファイルシステムのマウント
Robinhood を動かす Lustre クライアントでも Lustre ファイルシステムをマウントしておきます。[MGS/MDS] は MGS/MDS 仮想マシンのホスト名もしくはIPアドレスです。
[root@Client2 ~]# mkdir -p /mnt/lustre [root@Client2 ~]# mount -t lustre [MGS/MDS]@tcp0:/test /mnt/lustre
Robinhood を動かす Lustre クライアントでは、アーカイブ先になる外部ストレージをマウントする必要は特にありません。外部ストレージは copytool 経由で使用します。
MariaDB の設定
Robinhood は Lustre ファイルシステムの更新履歴を DB を使って管理します。今回は Robinhood が動作する仮想マシン上で動く MariaDB を使いました。最初に次のコマンドで MariaDB インスタンスを起動します。
systemctl enable mariadb systemctl start mariadb
次に、 rbh-config コマンドで Robinhood 用の DB を作成します。filesystem の custom identifier には test、DB の robinhood ユーザには適当にパスワードを入力しました。確認を求められて y を入力後、MariaDB 側の root ユーザのパスワードを求められます。ここまでの手順の場合 MariaDB 側の root ユーザのパスワードは未設定なので、何も入力せずに Enter を押します。その後淡々と処理が進み、DB の作成が終わります。
[root@Client2 ~]# rbh-config create_db
Checking system configuration...
mysqladmin command OK.
mysql_config command OK.
MySQL version is 5.
Checking service mariadb...
● mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: active (running) since ？ 2018-02-XX XX:XX:XX JST; 1min 18s ago
Process: 401 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=0/SUCCESS)
Process: 314 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Main PID: 398 (mysqld_safe)
CGroup: /system.slice/mariadb.service
tq398 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
mq561 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plug...
（中略）
mariadb is running
mysql command OK.
Enter a custom identifier for your filesystem. E.g. lustre
fsname (max 8 chars): test
Enter hosts where robinhood commands will run. E.g. localhost
You can use '%' as wildcard: "%" for all hosts, "cluster%" for nodes starting with 'cluster'...
hosts: conn%
Choose a password for connecting to the database (user 'robinhood').
password: <-- パスワードを入力
confirm password: <-- パスワードを再入力
Write this password to /etc/robinhood.d/.dbpassword file
Configuration summary:
- Database name: 'robinhood_test'
- Client hosts: 'conn%'
- Database user name: 'robinhood'
Do you agree? [y/N]y
Enter password for root's database account (leave blank if none is set):
root's DB password: <-- 何も入力せずに Enter を押す
Creating database 'robinhood_test'...
done
Setting access right for user 'robinhood'@'conn%'...
(notice: user robinhood must have SUPER privilege to create triggers)
Grants for robinhood@conn%
GRANT SUPER ON *.* TO 'robinhood'@'conn%' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19'
GRANT ALL PRIVILEGES ON `robinhood_test`.* TO 'robinhood'@'conn%'
Testing connection to 'robinhood_test'...
Database successfully created!
[root@Client2 ~]#
事後談的な感じではありますが、入力値があらかじめ決まっている場合は、コマンドを1行で入力することも可能です。
rbh-config create_db robinhood_test localhost PASSWORD
Robinhood のポリシー設定
ポリシーのサンプル
ようやく、ポリシーエンジンである Robinhood にポリシーを設定するところまでたどり着きました。とはいえ、いきなりポリシーをゼロから書くのは至難の業です。Robinhood に用意されているサンプルが /etc/robinhood.d/templates ディレクトリにあるのですが、Lustre HSM 用のサンプル（example_lhsm.conf）は 5KBほどもあるテキストファイルで、これを読み解くのは大変です。そこで、こちらのチュートリアルを参考に次のようなサンプルを作成し、/etc/robinhood.d/test.conf として配置しました。
General {
fs_path = "/mnt/lustre";
# filesystem type, as displayed by 'mount' (e.g. ext4, xfs, lustre, ...)
fs_type = lustre;
}
fs_scan {
scan_interval = 5m;
}
Log {
log_file = "/var/log/robinhood.log";
report_file = "/var/log/robinhood_actions.log";
alert_file = "/var/log/robinhood_alerts.log";
debug_level = VERB;
}
ListManager {
MySQL {
server = localhost;
db = robinhood_test;
user = robinhood;
password = XXXXXXXXXXX;
}
}
# Lustre 2.x only
ChangeLog {
MDT {
mdt_name = "MDT0000";
reader_id = "cl1";
}
polling_interval = 10s;
}
# this defines policies for Lustre/HSM
%include "includes/lhsm.inc"
lhsm_archive_rules {
rule default {
condition {last_mod > 6h}
}
}
lhsm_archive_trigger {
trigger_on = scheduled;
check_interval = 5min;
}
lhsm_release_rules {
rule default {
condition { last_access > 1d }
}
}
lhsm_release_trigger {
trigger_on = ost_usage;
high_threshold_pct = 10%;
low_threshold_pct = 5%;
check_interval = 5min;
}
MDT の更新履歴を10秒ごとにチェックし、対象の Lustre ファイルシステムを 5分間隔でスキャンします。
大まかなルールの内容としては、次のようになっています。
| 項目 | ルール | トリガー |
|---|---|---|
| lhsm_archive | 最終変更から6時間以上 | 5分間隔 |
| lhsm_release | 最終アクセスから1日以上 | OSTの10%以上、5分間隔 |
最後に、データと更新履歴の初回スキャンを実施し、robinhood のサービスを開始します。
robinhood --scan --once -L stderr robinhood --readlog --once -L stderr systemctl start robinhood
実際にポリシーベースで動かしてみる
Robinhood の示すファイルの状態
Robinhood が管理する HSM の状態を示すものです。
NEW (no flag) ---- archive -----> SYNCHRO ----- release ---> RELEASED
| ^ <----- restore ----
| |
write archive
| |
v |
MODIFIED
実際にファイルの状態を確認するには、rbh-report コマンドを使用します。以下の例では、1GB のファイルがカレントファイルシステムだけに存在する状態（NEW）を示しています。
[root@Client2 ~]# dd if=/dev/zero of=/mnt/lustre/1g.dat bs=1024k count=1024
（しばらく待つ）
[root@Client2 ~]# rbh-report --status-info lhsm
Using config file '/etc/robinhood.d/test.conf'.
lhsm.status, type, count, volume, spc_used, avg_size
new, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
Total: 1 entries, volume: 1073741824 bytes (1.00 GB), space used: 1073745920 bytes (1.00 GB)
[root@Client2 ~]#
ファイルをアーカイブさせてみる
ファイルをアーカイブさせるには、ファイルが最終変更から6時間たっている必要があります。普通に待つと業務時間の大半が終わってしまいますので、ファイルの日付を touch コマンドで6時間以上前の過去時点にずらして mtime と atime を更新し、archive されるか確認します。MMDDhhmm には2ケタの数字でそれぞれ月日時分を記述します。
[root@Client2 ~]# touch -t MMDDhhmm /mnt/lustre/1g.dat
（しばらく待つ）
[root@Client2 ~]# rbh-report --status-info lhsm
Using config file '/etc/robinhood.d/test.conf'.
lhsm.status, type, count, volume, spc_used
new, file, 0, 0, 0
archiving, file, 0, 0, 0
synchro, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
Total: 1 entries, volume: 1073741824 bytes (1.00 GB), space used: 1073745920 bytes (1.00 GB)
[root@Client2 ~]#
synchro は Lustre ファイルシステムと HSM 先の外部ストレージの両方にファイルが存在する状態です。無事、外部ストレージへアーカイブされました。
ファイルを release させてみる
ファイルが RELEASED に移動されると、Lustre ファイルシステムの空き容量が増えます。今回用意したポリシーでは時刻だけでなく容量割合も加味していますので、16GB の10% である、1.6GB を総容量が越している必要があります。1GB ファイル１つでは足りませんので、1GB のファイルを追加します。ファイルを追加した後に少し待つと、次のようにコマンド結果が変わり、追加したファイルが new で検出されていることがわかります。
[root@Client2 ~]# dd if=/dev/zero of=/mnt/lustre/1g-1.dat bs=1024k count=1024
（しばらく待つ）
[root@Client2 ~]# rbh-report --status-info lhsm
Using config file '/etc/robinhood.d/test.conf'.
lhsm.status, type, count, volume, spc_used, avg_size
new, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
synchro, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
Total: 2 entries, volume: 2147483648 bytes (2.00 GB), space used: 2147491840 bytes (2.00 GB)
[root@Client2 ~]#
さらに touch コマンドでアーカイブ済みのファイルの時刻を１日以上前に変更してからしばらく待つと、元々あったほうのファイルが release されて space used が 1GB に減ったことがわかります。
[root@Client2 ~]# touch -t MMDDhhmm /mnt/lustre/1g.dat
（しばらく待つ）
[root@conn34 ~]# rbh-report --status-info lhsm
Using config file '/etc/robinhood.d/test.conf'.
lhsm.status, type, count, volume, spc_used, avg_size
new, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
synchro, file, 0, 0, 0
released, file, 1, 1.00 GB, 512, 1.00 GB
Total: 2 entries, volume: 2147483648 bytes (2.00 GB), space used: 1073746432 bytes (1.00 GB)
#
ファイルを restore する
release の条件にあてはまるファイルを restore しただけでは数分後にすぐまた release されてしまうので、ファイルの時刻を 12時間前に設定し、 lfs hsm_restore で復元します。
[root@Client2 ~]# touch -t MMDDhhmm /mnt/lustre/1g.dat
[root@Client2 ~]# lfs hsm_restore /mnt/lustre/1g.dat
（しばらく待つ）
[root@Client2 ~]# rbh-report --status-info lhsm
Using config file '/etc/robinhood.d/test.conf'.
lhsm.status, type, count, volume, spc_used, avg_size
new, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
archiving, file, 0, 0, 0
synchro, file, 1, 1.00 GB, 1.00 GB, 1.00 GB
released, file, 0, 0, 0
Total: 2 entries, volume: 2147483648 bytes (2.00 GB), space used: 2147491840 bytes (2.00 GB)
[root@Client2 ~]#
ファイルの状態が released から synchro に戻りました。無事 Lustre ファイルシステム上へリストアされていることがわかります。なお、ファイルを release させないためには、コマンドでファイルに属性を設定することでも実現可能です。
[root@Client2 ~]# lfs hsm_set --norelease /mnt/lustre/1g.dat [root@Client2 ~]# lfs hsm_state /mnt/lustre/1g.dat /mnt/lustre/1g.dat: (0x00000019) exists archived never_release, archive_id:1 [root@Client2 ~]#
本ブログ記事での Lustre HSM および Robinhood の動作確認はここまでになります。今回試したポリシーは Robinhood の機能の１部しか使用していませんが、無償のツールでポリシーベースの HSM 動作を確認できたことは、非常に有意義なことだと思います。
Lustre の HSM と Scality RING を組み合わせるメリット
そろそろまとめに入るのですが、Scality RING を Lustre の HSM と組み合わせるメリットは次の４点と考えています。
- Lustre と RING のどちらも、OS には Linux を使用している。
- HSM 用の外部ストレージとして、PB クラスの広大なディスクスペースを提供可能
- データ転送にはその時点で最高性能のネットワークを利用可能（参考：100ギガ時代のLAN配線(3)）
- 容量だけでなく性能もスケールアウト可能で、データの耐久性も高い。
Scality RING は複数のストレージサーバを用いた分散ストレージ構成を取っているため、構成可能なストレージ容量にはほぼ上限がありません。このため、外部ストレージの容量不足に悩まされることはおそらくないでしょう。利用するネットワークの観点でも、RING はメーカーによる互換性リストに縛られないことから、その時点でサーバに組み込める最高性能の NIC を随時利用可能です。加えて Lustre はスパコンで採用されるファイルシステムですから、データの移動を行う場合でも外部ストレージにはそれなりの高性能が求められます。これらのニーズを満たし、なおかつイレージャコーディングによる容量効率とデータの耐久性を追加します。
とはいえ私が試した Lustre HSM の動作は極めて初歩のところだけですので、実際にスパコンの環境に採用いただく場合は PoC やカスタマイズが様々必要だと思います。ブロードバンドタワーとしては柔軟な対応が可能ですので、このブログ記事を読まれたスパコン関係の方々からのお問い合わせをお待ちしております。
以上で、Lustre HSM 関連のブログ記事は（その３）で完了になります。いかがでしたでしょうか。次回以降も引き続き、Scality RING 関連の技術検証ネタを載せていく予定です。ご期待ください。
本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。