Takeru CoreDCの機能紹介 : ログインノードの分離

概要

本日は、Takeru CoreDCのメリットの一つであるログインノードの分離について紹介します。  
Takeru CoreDCとは、従来のクラスタサーバーにクラウド構築基盤ソフトのOpenStackを組み込んだ解析システムです。

https://www.nabe-intl.co.jp/CoreDC

一般的なクラスタサーバーは、ファイルサーバー、ヘッドノード、ログインノード、計算ノードなどの機能によって構成されます。

規模が比較的小さい環境では、一台でこれらの機能を全てカバーするケースが多いと思います。

一報、規模が大きくなり、利用ユーザーが増えてきた場合にはそれぞれに別のサーバーに分けてこれらの機能を持たせることが必要になってきます。

ログインノード、ヘッドノード、といったあたりの用語については用語の使われ方に幅があるため、ここではそれぞれの用語について下記の意味で用いることにします。

• ファイルサーバー : NFSなどのネットワーク共有ファイルシステムを提供するサーバー
• ヘッドノード : ジョブスケジューラーのマスター、ユーザー管理ツール、その他管理系機能
• ログインノード : クラスタを利用するユーザーが外部からログインするサーバー。ここからジョブスケジューラーを介してジョブを投入する。ファイルのコピーもこのログインノード経由でファイルサーバーにアクセスする
• 計算ノード : 投入されたジョブを実行するサーバー群

分離について

ここで取り扱う分離という言葉について は
ログインノード上で取り扱われる様々な情報についての権限の分離のことを指しており  
ログインノード上で取り扱われる情報については以下のようなものを想定しています。
全ユーザー共通のログインノードの場合と、ラボ毎に専用ログインノードを用意した場合を比較して書きます。
ログインノードが関係する情報には以下のようなものがあります。

• ユーザーが扱うデータ、ファイル
    ユーザーデータの分離においてはLinuxのパーミッション設定が適切に行われている限り分離はされています。他ユーザーのファイルを見ることはできません。  
    ただ、ラボ毎の専用ログインノードの場合はパーミッション設定以外にもNFSサーバー側の設定により自分のラボのユーザー領域しかマウントされていないため、他ラボのユーザーディレクトリの存在自体にアクセスすることができません。この点で一段高い分離が実現されます。
• アカウント情報 : ユーザー名やグループ名などのユーザー情報 
    共通ログインノードの場合、$ ls /home とした場合に全ユーザーのホームディレクトリの情報が見えてしまう一方、専用ログインノードの場合、NFSサーバー側の設定により$ ls /home をしても自分のラボのユーザーのホームディレクトリしか見えません。
• プロセスの情報 
    共通ログインノードの場合、$ ps axf とすることで他のユーザーのプロセスや処理しているファイル名が見えてしまうことがありますが、専用ログインノードの場合、そもそもログインしているサーバーが分かれているため見えることはありません。
• ジョブの情報 : ジョブスケジューラーに投入されたジョブの情報
    Slurm, AGEなどのジョブスケジューラーの設定によるもので、共通ログインノード、専用ログインノードどちらの場合でも設定は可能ですが、実行中のジョブ情報や過去に実行したジョブの履歴情報などについて自分のラボのユーザーのジョブ以外は見せなくする設定が可能です。

[共通ログインノードのイメージ]

[専用ログインノードのイメージ]

ログインノードの分離の違いやメリットはだいたい上記のようなところです。  
次に、具体的にラボ専用ノードから各ラボユーザーのホームディレクトリがどのように見えるのか(見えないのか)についてNFSサーバーの設定を含めて紹介します。

NFSサーバーの分離設定

/etc/以下の各ツールの設定ファイルにおいて、xxxx.conf.d というディレクトリが用意され、ここに置かれたファイルの設定が自動的に読まれるようになってきていますが、NFSサーバーのExport設定に関してもCentOS7移行 /etc/exports.d というファイルが用意されています。
内部の計算ノード全体に対して、/homeや/usr/localなど2,3個のディレクトリをexportするだけであれば /etc/exports への直書きのみで十分ですが、ログインサーバーの分離のように、運用過程で追加設定がたびたび発生するようなケースでは、/etc/exports.d の機能はこの機能はとても便利です。
ちなみに、ファイル名は xxxx.exports というように .exports で書かれている必要があるという点は注意が必要です。
実際に下記のような環境で動作を確認します。

共通ログインノードの場合の設定

まず、共通ログインノードの場合の設定手順を見ていきます。
/homeだけをマウントするケースの場合以下のようになります。

• NFSサーバーの/etc/exportsの設定

$ vim /etc/exports              
/data/home           192.168.255.0/24(sync,rw,root_squash)

$ exportfs -ar                  ## 設定の反映
$ exportfs -s                   ## 設定の表示
/data/home      192.168.255.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

• NFS Clientでマウントした場合、当然ですが下記のように全ユーザーのホームディレクトリを参照することができます。

[root@strand ~]# grep nfs /etc/fstab
192.168.255.200:/data/home         /home           nfs             defaults

[root@strand ~]# mount -a

[root@strand ~]# df -TH /home
Filesystem                 Type  Size  Used Avail Use% Mounted on
192.168.255.200:/data/home nfs4   44T  171G   44T   1% /home

[root@strand ~]# ls /home -l
total 43
drwx------ 3 gram  weight  7 Nov 10 18:18 gram
drwx------ 3 inch  length  8 Nov 10 18:31 inch
drwx------ 3 meter length  7 Nov 10 18:20 meter
drwx------ 3 mile  length  7 Nov 10 18:21 mile
drwx------ 3 monme weight  7 Nov 10 18:20 monme
drwx------ 3 ounce weight  7 Nov 10 18:19 ounce
drwx------ 3 pound weight  7 Nov 10 18:20 pound
drwx------ 3 shaku length  7 Nov 10 18:21 shaku

専用ログインノードの場合の設定

専用ログインノードの場合は、自身の所属グループのメンバーだけが参照できる状態にする必要があります。

• /etc/exports.d/以下に それぞれlength.exports, weight.exports というファイルを用意して下記のように記載します。

[root@triobite ~]# cat /etc/exports.d/length.exports
/data/home/inch         192.168.255.10(rw,sync,root_squash)
/data/home/meter        192.168.255.10(rw,sync,root_squash)
/data/home/mile         192.168.255.10(rw,sync,root_squash)
/data/home/shaku        192.168.255.10(rw,sync,root_squash)

[root@triobite ~]# cat /etc/exports.d/weight.exports
/data/home/gram         192.168.255.20(rw,sync,root_squash)
/data/home/monme        192.168.255.20(rw,sync,root_squash)
/data/home/ounce        192.168.255.20(rw,sync,root_squash)
/data/home/pound        192.168.255.20(rw,sync,root_squash)

• 2台のNFS Clientのstrand, probe どちらも /etc/fstab には192.168.255.200:/home のみをNFSサーバーとして指定するだけでOKです。  
  下記のように、NFSサーバー側の/homeだけを指定していても、exportされたユーザーのホームディレクトリしか見えません。

[strand側]

[meter@strand ~]# df -TH /home
Filesystem              Type  Size  Used Avail Use% Mounted on
10.16.12.113:/data/home nfs4   44T  171G   44T   1% /home
[meter@strand ~]#
[meter@strand ~]#
[meter@strand ~]# ls -l /home
total 12
drwx------ 3 inch  length 8 Nov 10 18:31 inch
drwx------ 3 meter length 7 Nov 10 18:20 meter
drwx------ 3 mile  length 7 Nov 10 18:21 mile
drwx------ 3 shaku length 7 Nov 10 18:21 shaku

[probe側]

[gram@probe home]$ df -TH /home
Filesystem              Type  Size  Used Avail Use% Mounted on
10.16.12.113:/data/home nfs4   44T  171G   44T   1% /home
[gram@probe home]$
[gram@probe home]$
[gram@probe home]$ ls -l /home
total 12
drwx------ 3 gram  weight 7 Nov 10 18:18 gram
drwx------ 3 monme weight 7 Nov 10 18:20 monme
drwx------ 3 ounce weight 7 Nov 10 18:19 ounce
drwx------ 3 pound weight 7 Nov 10 18:20 pound

NFS Client側の/etc/fstabを書き換えなくても済むのは便利ですね。

この状態で、実際にstrand側からgramやmonmeといったユーザーディレクトリにアクセスしようとしても、"No such file or directory" と表示されます。

[meter@strand ~]$ ls /home/gram
ls: cannot access '/home/gram': No such file or directory
[meter@strand ~]$ ls /home/monme
ls: cannot access '/home/monme': No such file or directory

その他

• 上記以外の設定について  
  上記は、NFSサーバー側で/home/直下に全てのユーザーがいる中でどのように簡単に分離を実現するか、という設定について書きました。
  ただ、NFSサーバー側で/home/[グループ名]/[ユーザー名] というようなディレクトリ構造にすればもう少しシンプルにすることができそうです。
  また、NFSサーバー側は/homeのみをexportしてNFSクライアント側だけで全てユーザー毎のマウント対象を定義するという設定も可能です。
• 共有リソースと分離のバランスについて
  上記設定は、専用ログインノードにログインされるユーザーが限定されている、という前提の上で成り立つものですが、ジョブスケジューラーに割り当てられたジョブによってどのユーザーもログインする可能性がある共用の計算ノードについては上記のように設定するわけにはいきません。
  あるユーザーのジョブが割り当てられた計算ノードは、ジョブ開始時にNFS領域をautomountし、他のユーザーのジョブが入らないように設定する、といったこともできそうですが、かなり潤沢な計算ノードが無いと計算リソースがもったいないケースが増えそうです。

ログインサーバーのメリット、というよりはNFSサーバー設定のTIPsのような内容となりましたが、共有リソースの良さを生かしつつ、分離も実現するというのはなかなか難しい課題について問題意識やお悩みがある方はぜひご相談頂ければと思います。