gfmd接続上限

GEO Gridで運用中のGfarmにアクセスできなくなった．正確には，新しい接続ができなくなったようだった．gfarm-discuss-ja MLに報告したとおりだが（現時点で送ったメールのアーカイブはまだ無いみたい），

% gfdf
libgfarm: [1000059] cannot connect to gfmd at gfmd.local:601, give up: authentication error
libgfarm: [1000017] connecting to gfmd at gfmd.local:601: authentication error

のように，接続ができなくなった．この時の gfmd 側のログは，

Jul 25 17:35:28 gfmd gfmd[4146]: [1000189] accept, Too many open files
Jul 25 17:35:28 gfmd gfmd[4146]: [1000043] (_gfarmfs@10.0.0.130) _gfarmfs: authorize_sharedsecret: local account doesn't exist
Jul 25 17:35:28 gfmd gfmd[4146]: [1000024] auth_sharedsecret: gives up: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000187] authorize: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000188] peer_authorize: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000286] ((null)@(null)) disconnected
Jul 25 17:35:28 gfmd gfmd[4146]: [1000028] auth_sharedsecret: .gfarm_shared_key: gfarm sharedsecret key - key file not exist
Jul 25 17:35:28 gfmd gfmd[4146]: [1000024] auth_sharedsecret: gives up: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000187] authorize: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000188] peer_authorize: authentication error
Jul 25 17:35:28 gfmd gfmd[4146]: [1000286] ((null)@(null)) disconnected

こんな感じ．file descriptorが足りなくなったのだろうとは推定できるが，何がどうかは分からなかった．ともかく，gfmdを再起動して復旧したが，その後，状況を見たら，

% grep ESTABLISHED /var/log/local0 |wc -l
    8927
なので，かなり接続があるのは間違いない．

上限値はというと，/etc/init.d/gfmdで設定されている

# increase the maximum number of open file descriptors
ulimit -n 16384 2> /dev/null

ということなので，こいつが枯渇したのでしょう．ソースレベルでも，

GFMD_CONNECTION_LIMIT 65536

という上限が設定されているそうなので，60,000くらいに設定しようかと思う（この機材は，gfmd専用機）．

最後に，gfmdの最大コネクション数は，

(1) クライアント1プロセスあたり: gfsd_connection_cache(default 16) + 1 = 17

(2) ファイルシステムノード1台あたり: 2+全ファイルシステムノード数

の合計で求められる．(2)は，version 2.4.1以降ということなので，2.3.2で運用しているうちとしては，(1)だけを考えれば良い．ここで，クライアント１プロセスは，fuseのマウントの数になるわけですが，１ノード辺り60マウントくらいしているので，

17 (connects / clients) x 60 (clients / nodes) x 30 (nodes) = 30,600

なので，軽く上限超えちゃうわけです．あくまでもgfsd_connection_cacheがフルに使われての数字なので，実際にはアクセスがあまりないfuse mount pointからは17もセッションがはられるわけではないです．一方で，アクセスが増えれば，gfmdとのコネクションも増えるので，ある日突然この症状となってしまいます．

GfarmとLustre

GfarmとLustreの違いは何か？

• ローカルディスクの性能をフルに活用するのがGfarm
• 複数ノードを束ねることで，ネットワーク性能をフルに活用するのがLustre

少しディスクを多めに搭載した汎用サーバの場合，数百MB/s程度の性能はリーズナブルな価格で出すことができます．これを使って，Gfarmを構築した場合，ローカルアクセスはディスクの性能を発揮できますが，ネットワークはまだたかだか1Gbpsなので，リモートアクセス（ローカルディスクにデータが無かった場合）の場合，125MB/s(=1 Gbps)が限界になってしまいます．

一方で，各ノード10GbEを持つことも，非現実的ではなくなってきました．この場合，単純に８で割ると，1.25GB/sです．こうなってくると，ローカルディスクのほうが追いつかなくなります．例えば，500MB/sの性能を持ったローカルディスクを３つ持ってきて，Lustreを構築すると，1.25GB/s（ネットワークで頭打ち）のI/O性能を得ることも可能になります．

もう一度，ディスクに戻ると，SATA 6.0Gbpsに対応したSSDが登場したことで，余り大きくは出来ませんが，SSD x 8のRAID位で1.0GB/sは出せそうです．

もうひとつの比較のポイントは，冗長性．どちらもありますが，

• Gfarmは，ファイルやディレクトリ単位で複製（レプリカ）を作成できるのに対して
• Lustreは，ファイルシステムノードレベルで複製（２重化）する必要があります（最新情報は未確認）

という違いがあります．最新のLustreでどうなっているかは確認する必要がありますが，ともかく全てのデータを２重化するのであれば，GfarmでもLustreでも差はありませんが，特定のファイルだけ複製を多くしたいなど，個々のファイルやディレクトリ単位で冗長性の数を変更したい場合には，Gfarmを選択することになります．

※ SSDなどを使ったローカルストレージも面倒なのでディスクと表記します．
※ ローカルディスクにはRaidカードの性能も加味してください

ノードDISK溢れ対策

Gfarmは，ファイルシステムノードで，書き込みをした場合に，そのノードにファイルを配置します．しかし，version 2.3.2では，minimum_free_disk_spaceの設定(gfmd.confに設定する)の動作が完全とは言えないので，DISKが少なくなってきたノードをreadonlyに設定する必要があります．また，gfmdで一括管理されてしまうので，個別ノードで空き容量がいくつ以下になったら，書き込まない．という設定ができません．

これを回避する一番簡単な方法は，dfで監視しつつ，空き容量が減ってきたら，readonlyに設定するという方法です．dfとって，.readonlyをtouchしたりrmするだけなので，頻繁にやっても問題ないと思います．

スクリプトの例：
（SPOOL_DIRECTORYは書きなおしてください）
#!/bin/sh

PATH=/usr/bin:/bin
LANG=C
export PATH LANG

ROfile="SPOOL_DIRECTORY/.readonly"
DisPnt=100000000
EnbPnt=150000000

# ---------------------------------------------------- #

NowAvail=`df -k -P /data | grep lvol0 | awk '{print $4}'`

if [ $NowAvail -lt $DisPnt ]; then
    test -f $ROfile        || touch $ROfile
fi

if [ $NowAvail -gt $EnbPnt ]; then
    test -f $ROfile        && rm $ROfile
fi

# ---------------------------------------------------- #
exit 0

Gfarmのログ

Gfarmのログは，デフォルトではloca0に出力されます．
このログには，gfmd, gfsd, gfarm2fsのログが出力されるのですが，特に認証（接続）が発生すると大量のログが出力されます．
gfarm2fsで使っている分には頻繁な接続は発生しないのでさほどログは出力されませんが，gfコマンドを使うと，都度ログが出てくるのでログのサイズに注意が必要です．
必要に応じて，rotateすると良いです．

Gfarmレプリカの移動

Gfarm v2 (v1とはオプション違ったかも）で，レプリカを移動する方法．

gfrep -m -h slist -H dlist target_dir

slistに含まれるホストのレプリカをdlistにあるホストに「移動」する．このやり方では，敢えて -N <#> オプションを指定せず，一つのレプリカを対象としています．考え方としては，

• レプリカを退避したいノードをslistに記載
• slist以外のノードをdlistに記載
• かつ，レプリカを書き込まれたくないノードは，readonlyに設定．

readonlyに設定するのが面倒だったら，dlistに含めなければOKです．readonlyになっていれば，dlistで指定されたとしてもレプリカは書き込まれません．

たとえば，負荷集中が起こっているノードをdlistに書いて，それ以外をslistへ．加えて，残量100GBを切っているノードをreadonlyに設定．とかするとぼちぼち動きます．

ちなみに，Gfarmファイルシステム上のファイルをシェルの補完機能で追跡することは出来ません．なので，gfarm2fsを用いてマウントしたディレクトリに移動してからgfrep等のGfarmコマンドを操作すると，ファイル名補完ができるので便利です．
ただし，Gfarm v2では，$GFS_PWDが無くなってしまったので，トップディレクトリから移動せずに操作する必要があります．ちょっと使いにくい．

gfmdのメモリサイズ

Gfarmを構成するメタサーバについては，メモリ量を予め予測してサーバを用意しておく必要があります．

2010/11/07現在，2500万ファイルで，8.5GBのメモリが利用されています．単純な割り算ではレプリカの数とか，パス名の長さによって変わってくるので定かではありませんが，ファイル辺り，365Bのメモリを使用しているようです．

メタサーバメモリ ＝ 想定されるファイル数 × 400B

と思っておけば良いでしょうか．余裕を見て1KBとすると，100万ファイルで1GBのメモリが必要という計算．

さらに，gfmdはメモリ上にしかメタ情報を持たないため，DISKに書き込むためにPostgreSQLサーバも用意する必要があります．Gfarmのインストールスクリプトでは1GBに設定されているようですが，多いにこしたことは無いでしょう．

gfmdとPostgreSQLは単一サーバでも良いですし，2台に分けても大丈夫です．

2010/11/09追記
そんなに使わないはず．という指摘を頂いたので，再計算．

8.7GB / 25,471,942 files = 366.7B

あほだ．KBじゃない．Bだ．
また，ほとんどレプリカをまだ作成していない状態です．

Gfarmで特定のノードを書き込み不可にする

Gfarmを使っていると，特定のノードのDISKが溢れそうになったり，RAID再構築中は書き込みを避けたいとか思ったりします．このような場合は，

${gfarm_sppol_dir}/.readonly

というファイルを作成すれば，仮想的にそのノードのDISKの残容量が0になり，書き込みスケジュールの対象から外れます．gfdfの出力も，

28118482944 28118482944           0   100%   xxxx

のように利用率が100%もしくは，100%以上？！になります．
v1安定化開発の時に思いつきで入れてもらった機能でしたが，v2の今でも健在です．

RELNOTES:
  - support read-only mode experimentally, which is enabled by
    creating ".readonly" file in the top spool directory by
    administrators.

ということなのですが，どの辺がexperimentallyなのかはよく分かりません．
少なくとも，v1当時はgfrepでdistinationを明示するとこのreadonlyを無視してしまっていたのですが，v2ではこの問題は無くなっています．

蛇足ですが、readonlyにしたとしても、レプリカの削除は出来ます。なので、readonlyにしておいて、他のノードにレプリカを gfrep -m で移動する等が可能です。これをうまく使って空き容量の平滑化をしたり、アクセス集中を避けたりするのでしょう。

ローカルI/Oの罠

Gfarmの最大の特徴は、ローカルにデータがある場合に台数に応じたファイルI/O性能をスケーラブルにすることにある。
一方で、特定のファイルシステムノードでファイルを書き出した場合、基本的に常にローカルノードが選択されてしまい、ファイル実体がそのノードに集中してしまうという問題がある。これによって、例えばある観測日のデータが特定のノードに集中していてそれを並列処理しようとすると、readアクセスがそのノードに集中するため、そのノードのロードアベレージが軽く10とかいってしまう。
これを明示的に回避するためには、ファイルシステムノードでは無いノードからデータを書き出すようにするか、ローカルディスクを優先しないという設定を入れる必要がある。

Gafrm v1の場合、

export GFARM_WRITE_LOCAL_PRIORITY=disable

とすると出来る。v2はまだ分からない。

アクセスが集中すると，こうなる．

Down PostgreSQL

７月にGfarm v2の構築を始めてはや3ヶ月．
とりあえず暫定で動かしていたPostgreSQL + gfmdのメタサーバですが，メモリが8GBしかなく，ついにメモリ不足でPostgreSQLがkillされてしまった．．．．
しばらくはファイルの追加もgfmdに対して行えていたが，沈黙．
が，PostgreSQLのメモリを減らして起動したところ， gfarm2fs を使っていたプロセスがそのまま動き始めた！すばらし．