koie blog : Gfarmシンポジウム 2016

http://oss-tsukuba.org/event/gs2016
2016-12-09 13:30〜17:00
筑波大学文教キャンパス
http://togetter.com/li/1057672

昼に茗荷谷に着いたら、ちょうど小学校の下校時間なのか、制服を着たちびっこでにぎやかだった。

[2016-12-09 13:29]

開会 / ベストシステムズ西克也

gfarmシンポジウムも4回目

[2016-12-09 13:30]

Gfarmファイルシステムの概要と最新機能 / 筑波大学建部修

18000download越え 2007/4から
Gfarm 2.7.0(201612/8 release)： 2.6.0からはデータ完全性に重点
運用: JLDG(Japan Lattice Data Grid(物理系);8PB越え), HPCI共用ストレージ(22.5PB越え), NICTサイエンスクラウド, クオリティアActive!world
HPCI: 東拠点東大東工大=13.0PB 西拠点AICS=9.5PB
Garm 2.7.0
- InfiniBand RDMA
  - IB Verbs APIをつかってRDMAがあたらしい。(IPoIBではない)
- ディレクトリクォータのサポート
IB RDMA
- よみこみはremote write, かきこみはremote read
- CPUを介在しないのでオーバヘッドがすくないメッリト
- 最近のIB Verbsではメモリを事前に確保しなくても動的にいけるようになっているが、今は事前登録している。
- staticなclient bufferをpin-downするか、ユーザのbufferを動的にpin-downするか、どちらかか。
- IB RDMAにしっぱいしたらIPにfallbackする。
- サイズがちいさすぎるとRDMAのオーバヘッドがあるのでパラメータrdma_min_sizeがある。が、実際にはstaticなbufferをつかうので意味ない？
- 性能比較: rdma-read = 1.8 * ipoib-read, rdma-write = 1.2 * ipoib くらい。
  - POSIX APIだとfuseのオーバヘッドがあるが1GB/sくらいは出る(rdma-read)。
ディレクトリクオータ機能
- ユーザ/グループごとの制限ではなく、ディレクトリ下の制限。制限の設定はユーザの権限でできる。
- 設定はディレクトリセット単位になる。(grdirquotaコマンドでディレクトリセットの作成)
- ディレクトリセットは1つのパーティションになっているイメージなのでパーティション間をまたぐ制限はパーティションにならうかんじ
データ完全性
- サイレントデータ障害を検知する
- 破損ファイルをreadするとEIOしつつlost+foundに移動してレプリカから修復する。
- 書き込み後ベリファイはデフォルト6時間後に行なわれる。
- JLDGでの運用例: md5。5ファイルの書き込み後ベリファイ(6時間後)で検出、複製作成で1ファイルの損傷(書き込み後即時)で検出。IO errorはおきていない。
Pwrakeによる性能測定スクリプトの紹介...

[2016-12-09 14:02]

Q: RDMAはIPでもいける?
A: IBのネットワーク範囲内。IPがはさまると最初のチェックで弾いてIP通信になる。メタデータはIP。(ペイロードがおおきくないとうまみがない)

[2016-12-09 14:05]

[2016-12-09 14:07]

Gfarm Performance on Azure / HPCソリューションズ河野証

Microsoft Azure(アジュール)
- windowsだけではなくlinuxの仮想マシンもつかえる
- 仮想CPUは物理コアを占有する。ただしA0インスタンスをのぞく。
- BLOB storageの冗長オプションもいろいろ: LRS, GRS, RA-GRS.
- LRS: リージョン内レプリカに書き込み完了をまつ。
- GRS: 外リージョンの書き込みは完了待たず(非同期)。
- データディスク=BLOB, ストレージアカウント=set of データディスク, ストレージアカウントは実際の物理構成が透けて見えてるだけ、MAX20000IOPS、スループットは非公開。
Gfarm on Azureをつかうことで
- オンプレとAzureで手元に頻繁にアクセスするデータをもってこれる
- 容量の増減ができる
- リージョン間レプリカで耐災害性
性能テスト
- サーバ1台: 11ディスクで700MB/sがピーク。そこまではリニアがが12ディスクから性能劣化で500MB/s。
- サーバを増やしていくと5台くらいまではリニアに伸びて2700MB/s
- サーバ500MB/s、ストレージ2500MB/sあたりが上限っぽい。
- Azureの冗長オプションの違い(GrS,RAGRS,LRS))による性能差はない。
- gfarmでリージョンをまたいでレプリカつくるとgfgrepが遅い。4倍くらいおそかった。

[2016-12-09 14:34]

Q: Azureでデータ完全性はチェックしてる?
A: silent data corruptionには対応しているとアナウンスされているが、具体的にはナゾ。
Q: ストレージでもネットワーク従量課金があるが、アカデミックな人たちには使いにくい(SINETと比べて高くてスパコンセンターの運用がなりたたなくなってしまう)。
A: Azureから出ていく方向(upload)は課金されるが、入ってくる方向(download)は無料。
X: クラウド内で処理を完結させる・クラウド内で可視化。(ユーザからはデータを見るのに時間がかかる)
X: 広域分散したときに各サイトで容量をあわせて増やしていかないと、データが偏ってしまう。拠点を増やすのも同じ問題がある。

[2016-12-09 14:44]

[2016-12-09 14:45]

Gfarmの高速化のための技術開発 / NICT 村田健史

ひまわり8号リアルタイムWeb実績
- 7号から8号でデータサイズが50倍になった。データが150TB/年で増える。ひまわりwebでさらに70TB増える。
- ファイル数が2億/年。
- 気象庁は自分でデータをためるのをあきらめて外部に利用させる代わりにデータを保存してもらうことに。
- 8Kの10倍くらいの画像データとでかい。
- 台風が来るとアクセスが増える。平時でも2千人くらいみてる(マニアと専門家)。日食のときにもアクセスが増えた(雨だったので)。沖縄からのアクセスがおおい(台風がおおいから)。平日は職場からスマホで、休日は自宅からPCで。
- netCFD/HTTPでgfarmにもってくる。(Himawari Cloud)。
- 研究者にはFTP,HTTPで配布。
- ファイルの数が問題になっている。
- 名古屋大学情報基盤センターの8Kディスプレイで静止画をOpenGLで連続レンダリングして疑似動画表示。ただデータをもってくるのに1分くらいかかる。
JHPCN2017: 京大・名大・九大・千葉大・愛媛大・NICT・筑波大
- FWなしに通信できるのは限られる。
- SINETが速くなってもFWやキャンパスネットワークがボトルネックになる。遅延・パケットロスも組織間でいろいろ。
- クライアントサイドの並列化はメンドクサイのでさけたい。
HpFP(UDP独自)とxTCP(TCPの高速化;TCPインターセプター)
HpFP: 500ms loss数%なら10Gbpsはだせる(静止軌道の通信のめやす)
HbVRS: gfarmの上にHpFPを載せてファイル転送(gfpcopy相当)を高速化
- UDT(UDPベースの通信；昔からあるやつ)と比較してみた: UDTはパケロスに弱い。
xTCPによるGfarm高速化実験
- 遅延ロスなしならTCPの方がよい。あるならxTCPが圧倒的に速い。
- 小さなファイルの転送は時間がかかる。もしかするとmetadata server--client間は素のTCPの方がよいのか？
- 素のTCPはスループットがたちあがるのに5秒くらいかかる、HpFPでは3秒。
Amaterassプロジェクト
- NPO太陽放射コンソーシアム
  - 1日あたり1000万ファイル・250GB

[2016-12-09 15:24]

Q: ディレクトリを分ければファイル数は増やせるが。
A: メモリを買う予算が。メタデータ圧縮がほしい。

[2016-12-09 15:26]

休憩

ドリンク購入。コーラがなかったので朝摘みオレンジ。

[2016-12-09 15:39]

Gfarmシステム運用におけるアウトソーシング活用の試み / 東京大学中誠一郎

アカデミック分野の運用現場
- 現場に入って2年3ヶ月：いろいろ企業とは雰囲気がちがう。雇用形態の違いか？成果に対するインセンティブがない。
保守管理業務の本質(ITIL)
- 見える化(運用目標・運用成果・教務カタログ)・基盤(ドキュメント・スキル・ツール)・管理(情報管理・プロジェクト管理・予算管理・品質管理) 経営層との合意。CMSツールがつかえうる。
- CMMで2,3あたりにとどまっている。
最近の目だった障害: DNSダウン、ストレージ障害(IBのバッファサイズが不適切だった)、Gfarmレプリカ不正作成によるファイル消失、Gfarmメタデータサーバダウン(高負荷すぎてzabbixまで落ちてfailoverしなかった; zabbixがSPOFになってた)
アウトソーシング: 夜間(16:30-9:30)休日限定。作業内容は最低限の被害拡大防止のマニュアルベース。
- 工数ベースではなく、遠隔運用監視サービスなどのメニューにもとづく契約。
要員: 東大3名、委託先6名(ローテーションで15名)
監視は時間帯を決めてログ取得するなど。
アウトソーシングすることで保守ノウハウの見える化をねらっている
- 属人的な蓄積は組織としては無意味。
障害時の対応: システムの更新を伴う作業はやらない、参照だけ。協議の結果、zabbixサーバの再起動はやってもらうことになった。
外部pingによって障害切り分けに役立つはず(内部からのpingだとやりにくい)。
見える化→改善サイクルの習慣化
Enterprise WiKi (CMS): atlassian Confluenceが人気→今回活用した。
委託費用: 初期数百万、月額数十万(土日休日のみ)。
(管理画面デモ)
- CMSベースの報告・マニュアル作成

[2016-12-09 16:24]

Q: メタデータサーバダウン
A: globusの設定の問題(globusをバージョンアップしたときに設定を追加しないといけなかった)
X: むしろ外部の人間がやったいいことの方があるのではないか？間違いを発見しやすい。セキュリティのチェックも外部の人をつかった方がよいのではないか？

[2016-12-09 16:28]

[2016-12-09 16:29]

次世代HPCI共用ストレージの設計とクラウド活用 / 理化学研究所原田浩

10PB級のストレージを運用しながら短時間で機材更新した。
データ保護と安全性・サービスの継続性・メニューの多様化
- データの破損があると再計算の必要→計算資源の提供(千万円単位の計算もあったり)
- 年間350日以上のサービス提供: 測ってみたら初期の方が稼働率が高かった。電源二重化してたので電源断はなかったが漏電により全館ダウンがあったため定期的に検査することに。
稼働率が数%しか違わなくても、1日8時間だとおもうとけっこうちがう。
東大とAICSでデータに二重化してサービス継続性を上げるしかない。
- MTBF: 400hour->2154hourに改善できそう (3ヶ月に1回メンテナンスするかんじ)
サービスレベル
- 初期投資が巨額になる→需要拡大にこたえるのがむつかしい。
- 容量が足りないので2015年度から完全二重化をやめてユーザにレプリカの設定をまかせるようにした。
- 柔軟な機材設置→クラウドを活用するしかないか？
- 負担の公平化: 大規模課題で資源を寡占されてしまう、非公開課題の扱い、長期保存データ(容量比40%超が1年以上の長期保存:atime調べ)
2017年度
- クラウド環境の調査・クラウドにGfarm環境構築・クラウドストレージとGfarm連携