koie blog

• 日時: 2022年10月28日(金) 13:30〜18:20
• 場所: AP秋葉原 5階Aルーム + オンライン(zoom)
• こくちーず
• 公式

[2022-10-28 14:00]

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

• 資料
• 2000年から開発しているので22年
• JLDG,HPCI共用ストレージ(富岳),NICTサイエンスクラウドで実運用されている
• nextcloudコンテナ gfarmを外部ストレージとしてあつかえるようになった
• gfarm-s3-minio S3互換サービス
• wsl ubuntu上でmountするとexplororからもファイルがみえるので便利
• winscpでS3アクセスするデモ
• GSI(代理証明書)はサポートがおわっている(コミュニティーベースに移行)のでOAuth/OIDCをつかうように。
• 完全性:サイレントコラプションとおもわれる事象はいくつか起きている。

[2022-10-28 14:23]

• Q: gfarmをwslでmountするとは?
• A: ubuntuにgfarmのクライアントを入れてgfarm2fsでマウントされる。

[2022-10-28 14:26]

[2022-10-28 14:27]

Delivering Supercomputing File System Performance on Oracle Cloud with WEKA / Oracle Corporation Clifford Patterson

WEKA on Oracle Cloud Infrstructure (OCI) Overview / ORACLE

• 発音: ワカ ウェカ
• Gen2 arch: L2 virtualization, RDMA, ...
• low-latencyを要求したりio-intensiveなアプリはオンプレに残っていた。
• ホワイトペーパー: weka-on-oci.pdf
• posix, nfs, smb, s3, k8sプロトコルをサポート
• single name space
• s3でデータを保存してposixでアクセスするとか

[2022-10-28 15:12]

• Q:建部さん2つ質問
• A:
• Q:住元さん MPI-IO HPC support?
• A:

[2022-10-28 15:21]

[2022-10-28 15:22]

研究データ管理のためのストレージシステム / NII RCOS 下山

• 2015年オープンサイエンスに関する検討会からスタート
• 第6期科学技術・イノベーション基本計画(2021年)
  • データポリシー策定率・メタデータ付与率100% 2025年までに
• 研究者にとって余計な作業→必要な作業に転換してストレス削減
• GakuMin RDM: 研究データ管理基盤
• e-Radにひもづけ メタデータ15項目
• データを作成したコードの管理
  • データ解析をjupyterでやる
• 標準ストレージだけでなく外部ストレージ(public cloud, private cloud)で研究データを保管したい。
• 外部ストレージ連携: Waterbutler
• 標準ストレージの統計: 1MB以下のファイルが全体の80%をしめる。中央が128KBくらい。
• WaterButler,Gfarm, iRODS, Globus?

[2022-10-28 15:53]

• Q: 建部さん、研究データはどういうものだとおもっているか? 素粒子とか遺伝子とか。
• A: 素粒子とか遺伝子とかはすでに必要性にせまられて整備されている。既存の管理システムと連携する必要がある。
• REST APIだから大きいデータを置こうという気にならないだけかもしれない。
• Q: 海外連携は?
• A: gakunin rdmに関していえば、利用できるのが国内の研究機関(と共同研究しているところ)のみという約款になっている。
• Q: 住元さん、さいきんつかいはじめている。mdx
• A: gakunin rdmのデータを外に公開する機能はまだない。
• オープンデータとの関係
• Q: 東大 塙

[2022-10-28 16:04]

休憩

休憩からもどったらPCのバッテリが切れてメモとれず。まさか席に電源がないとはおもわず延長ケーブルをもってきてなかった。アナログ筆記具ももってきてなかった。スマホ+HHKB+モバイルバッテリの組み合わせにしておけばよかったと後悔。

[2022-10-28 16:16]

キオクシアSSD最新テクノロジーと今後の取り組み / キオクシア株式会社 瀬戸 弘和

• 不揮発メモリはまだ実用段階にない。
• Q:容量そこそこで速いやつ・安いやつがほしい。
• A:SLCからMLCに代わる製品があるが同じ性能で安価になる。

京都大学新スーパーコンピュータシステムの構成と導入アプリ検討 / 京都大学 深沢 圭一郎

• 資料
• 絶賛トラブル中らしい。

Pegasus ビッグメモリスーパコンピュータではじまるこれからのデータ科学・ビッグデータAI / 筑波大学 建部 修見

• 資料
• CHFSをつかったキャッシュ
  • 一貫性を緩和してメタデータサーバなしで性能を出す
  • 入力データはジョブ実行中に変更されない
  • ジョブの新規エントリ作成は成功する
  • ジョブが既存ファイルを更新するときは読込んでから
  • 更新はフラッシュするまで反映されない
  • フラッシュはジョブ終了までには行われる
• CHFSは(メタデータサーバがないので)ファイルサイズを管理してない。分散ハッシュのレンジクエリでチャンクをかきあつめて計算するしかなく遅い(ls -lすると死ぬ)

クロージング / 塙

懇親会

ひさしぶりだぁ〜

• 日時: 2021-03-05 10:30〜16:15
• 場所: WebEx
• 告知
• まとめ

[2021-03-05 10:31]

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

• ワークショップは地方開催だったが、今回はオンライン。
• libreがdebianのパッケージをメンテしているのでubuntuではapt installで入る。
• 新機能: S3互換IF、TLS通信
• 暗号化ファイルシステム
  • encfsをつかう。
• read only
  • メタデータが更新されなくなる。
  • フェイルオーバーでsplit brainの可能性が残る場合(disaster recoveryとか)につかう。
• Gfarm/BBバーストバッファ
  • ノードローカルの高速ストレージをつかう
  • メタデータの同期が不要になるので高速に。
• NSMPI (MPI-IO for Node-local Storage)
  • ノード数に対してスケールする
  • readでもスケールする。
• Q: ROで書きこむと待たされるか?
• A: 待たされずエラーになる。書き込み途中でROになったらcloseで待たされる。

[2021-03-05 10:54]

HPCI共用ストレージ利用者向け情報公開サービスの構築とと今後の展望 / 金山秀智

• 論理 45PB (二重化しているので物理90PB)
• プライマリは7.8PBで容量80%を越えたら古いのは消す。
• Gfarm Zabbixで障害監視しているが管理者向け
• prometheus(監視)+Gfafana(ダッシュボード)でユーザ向けの情報
• apache+shibboleth, grafana+mysql, prometheus+influxdb
  • nginxはshibolethがサポートしてない..
• Gfarmのコマンド出力がjsonだったらなぁ...
• SELECT DISTINCT inumber FROM xattr WHERE attrname in ('gfarm.replicainfo','gfarm.ncopy')
• ダッシュボード作りは大変だった。
• ネットワークの障害(SINETの運用状況)と連携したい
• ユーザ別の情報を提供する予定
• Gfarm Exporter: スクリプトのメンテナンスがたいへんなので。

[2021-03-05 11:27]

• Q: イベントからGUI反映までの遅延は?
• A: 15秒に1回とっているが、バッファ3分なので最大3分。

[2021-03-05 11:29]

スーパーコンピューティングシステムSQUIDとデータ集約基盤ONION / 伊達進

SQUID

• supercomputer for quest to unsolved interdisciplinary datascience
• 汎用CPU計算ノードはdragofly+ でスレージをふくめた全体はfat treeで

ONION

• セキュアフロントエンドを経由するとスパコンを資源分離環境で使える(医療系とかで利用)
• google driveにおいてデータを共有しているのをなんとかしたい。(open research, open innovation)
• 多様なデータをスーパーコンピューティング環境に集約できるデータ基盤
• データフローを妨げないデータ基盤
• データの適正な管理
• sftp,scpでデータ移動しているのはなんとかしたい (HPCI共用ストレージはあるけど) (スパコン内はNFSで)
• Osaka university Next-generation Infrastructure for Open reserch and open InnovationN
• WebUIで利用者がデータ操作ができるようにしたい
• 計測機器のデータを自動的にストレージに保存できるようにしたい

[2021-03-05 12:01]

昼休み

[2021-03-05 13:20]

Gfarm-S3-MinIO GfarmのS3互換ゲートウェイ / 石橋拓也

• https://min.io: S3互換ストレージ、gateway機能がある、Go言語
• WebUIにログイン (Gfarm共有鍵のハッシュ値もつかえる)
• ユーザごとにMinIOプロセスを起動する
• アクセスキーがuser ID、シークレットアクセスキーがパスワードに相当する
• apacheリバースプロキシでアセクスキー → MinIOのポート番号に転送
• /sss/ユーザ名/バケット名 としてみえる。
• WinSCP,Nextcloudとかからもつかえる
• マルチパートアップロードをどうするか
  • ローカルFSに溜めてからGfarmにアップロード
  • ローカルがあふれたらGfarmにためる。
• 注意事項
  • ディレクトリを改名できない
    • そもそもS3 APIにrenameがないのでコピー+削除になるため
    • クライアントの実装次第
  • /sssバケットを消さないように!
    • rm -rf / 相当。削除できるものはすべて削除することになる

[2021-03-05 13:51]

• Q: gfarmから作成されたファイルもS3からアクセスできるか?
• A: S3で共有する設定になっているディレクトリならOKl
• Q: マルチパートアップロードをDNSでエンドポイントを複数に分けたときにどうなるか気になる
• A: S3クライアントは1つのgatewayにしかつながらないなず
• Q: readもマルチパートになる?
• A: minio-gfarmは1本
• Q: マルチパートアップロードはoffsetがわかればpwriteできるのでは?
• A: 最後にならないとoffsetとsizeの情報が飛んでこないのでムリ
• Q: 結合中にエラーになったらどうなる?
• A: クライアントは結合の成功を待つのでだいじょうぶのはず

• MinIOをユーザにちかいところにおくのかgfarmにちかいところにおくのかで性能がちがってくる。

[2021-03-05 14:06]

Amazon Web Services におけるクラウドHPCストレージ ～Amazon FSx for Lustre を中心として～ / 宮本大輔

• 最近は製薬企業のHPC利用をあつかっている
• クラウド: 必要なときに・必要なだけ
• アプリケーションにあわせてクラスタを構成できる(自由度が上がりすぎるけど)
• ひとりあたり1クラスタ構成もありえる
• Mobileye: 自動運転のシミュレーションをAWS Batchで。ピーク40万vCPU。
• Descartes Labs: EC2 C5で2PFlops LINPACK。2.6h 5000$。
• modernaでもAWS活用
• EFA: elastic fabric adapter
  • MPI/NCCL専用アダプタ利用。TCP/IPをはぶく。
  • TCPのかわりに SRD: scalable reliable datagram をつかう。
• amazon FSx for Lustre: フルマネージド
  • scratch(single SSD), persistent(replica ssd), persistent(redundant hdd)
• ふだんはS3にデータをためて、計算するときだけlustreにインポートする。
• 自動インポート設定ができる。fsをつくるときにバケットと関連づけする。
  • lustreのHSM機能をつかっている
  • 明示的エクスポートは lfs hsm_archive FILE
  • 状態は lfs hsm_state FILE でみられる。
• ストレージ構成
  • lustreのみ: すべてのデータを計算につかうばあい
  • lustre + S3: いちぶだけ計算につかうばあい
  • ローカルディスク + S3: 計算でデータの共有が必要ないばあい

[2021-03-05 14:39]

• Q: lustreでアクセスしているときにS3バケットが消えたらどうなる?
• A: おそらくエラーになとおもうが
• Q: toyotaがBeeGFSからAWS Lustreに変えたのはなぜか?
• A: 運用がたいへんだかららしい

[2021-03-05 14:41]

Lustreの最新機能のご紹介 / 井原修一

• HPCではlusterがよくつかわれている
• luster over striping
  • ストライプはOST数が上限
  • プロセス数 > ストライプ数だとOSTで競合がおこる。
  • ストライプ数 > OST数にできるようになった。
  • オブジェクトが分かれるので、競合を減らせる。
  • single shared fileで性能改善
• PCC: persistent client cache
  • ローカルSSD,NVMeをキャッシュにつかう
  • writeは自動同期する
• 暗号化
  • fscrypt kernel APIに準拠
  • クライアントでwrite時に暗号化。サーバはそのままディスクに書く。
  • writeは30%くらい性能が落ちる(現状)
  • readは20%くらい性能が落ちる(現状)
• DNE auto rebalancing
  • distributed namespace environment
    • MDTの負荷分散
  • DNE1: remote direcotry
  • DNE2: striped directory
  • ディレクトリにファイルを入れすぎても自動的に分けてくれる
• OST Quota
  • lustre quota: uid,gid,project-idに対してinode数/容量のquotaが設定できる。
  • HDDとNVMeのOSTが混在したときに別々のquotaを設定したい。
  • OST Pool Quota
    • OST Poolは以前からあった機能
    • これにquotaを設定できるようになった

[2021-03-05 15:05]

• Q: ストライプサイズを47008バイトにできるか?
• A: 64K以上で4K単位の制限がある

[2021-03-05 15:08]

休憩

[2021-03-05 15:25]

Oracle Cloud Infrastructure / 松山慎

• ベアメタルサーバとフラットなネットワークが特徴
• availability domain内はフラットな物理ネットワークで
• SINET接続あり
• ストレージの種類: local, block, fs, object(standard, infrequent, archive)

[2021-03-05 15:50]

[2021-03-05 15:51]

DDN Update / 橋爪信明

• 2020年導入実績
  • EXAScaler:14, FEFS:4, ScaTeFS:1
• NVMe 1.7倍/年、HDD 2倍/年で増えた
• EXAScalerはコミュニティLustreのアドオンの形で開発
• EXA5 Hot Pools: NMVeにキャッシュする。非同期でHDDにコピー。
• GPU Direct storageをつかうと187GB/s
• S3データサービス: lusterにS3 APIを提供。posixとs3の同時読み書き可能
• RED: reiable elastic data service
  • NVMe用sofotware defined storage
  • bulkIOだけでなくIOPS向けのエンジンも追加

[2021-03-05 16:14]

クロージング

[2021-03-05 16:15]

• 案内
• 参加登録
• 日時: 2020-10-09 13:30〜
• 場所: AP秋葉原 O+Pルーム (1F)
• オンラインはWebex
• togetter
• (録画と資料は公開されるはず)

オンラインとライブの両方で開催。久しぶりに外に行きたい気分だったのでライブ会場の秋葉原へ。台風14号(チャンホン)接近中で一日中雨。

[2020-10-09 13:29]

• 司会: HPCソリューションズ 河野
• 参加者: 秋葉原15名、オンライン15名

[2020-10-09 13:30]

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

• ワークショップは2月に別府で開催。おなじくライブとオンラインのミックスで。
• オーストラリアではLibre Solutions
• 開発を始めてから20周年 2000年6月スタート 電総研と高エネ研のGRIDミーティングから
• MTセーフ: 暗号化(EncFS)をサポートするのに必要だった
• read only機能: zabbixでフェイルオーバするときにスプリットブレインを避けるためにメタデータがちゃんとつたわってるのをたしかになるまでread onlyにする。
• githubに移行した(なかなかたいへんだった)
• MPIでバーストバッファがつかえるようにもなっている(IBがつかえない環境もあるので) MPI-IOで高速化
• gfarm2.8ではIPv6,S3,TLSがサポートされる予定。
• (例年は建部さんの話が長いけど今年はずいぶん早くおわった)

[2020-10-09 13:43]

スーパーコンピュータ「不老」
〜大規模コールドストレージ導入によるデータサイエンス支援を指向したスパコン〜
名古屋大学情報基盤センター　片桐 孝洋

• 「不老」2020-07-01正式運用開始
  • type1: 富岳の同型機をつかっている
  • type2: GPU型
  • type3: 大規模共有メモリ
  • 6PBの光ディスク コールドストレージ(ソニー) 100年保存
  • 湧き水でエコ冷却
• 特徴アプリ: 台風と医用画像につよい先生がいるので
• デジタルサイエンス
• 名古屋大学は伝統的に富士通製
• 5年サイクルでリプレイスしている
• 国策スパコンとPCスパコンの二本建
• コールドストレージ: 10PBまでキャパがあるけど4PBはユーザ持ち込みのためにあけてある。
• 最大消費電力: 1.9MW
• 湧き水: 夏でも18℃ 30リットル/分 ポンプで吸い上げて雨水としてすてていたのを冷熱源として利用
• 2〜3℃さがる。
• どのくらい効果があるかは計測中。2〜300万やすくなるはず。
• 夏場の昼のピーク電力カットのためジョブの実行を抑制 12時間キューを用意して実装
• でも今年はコロナで人が来てないので電力は逼迫しなかった
• type1は富岳の1/70の規模
• type2: nvidia V100、ssdもたっぷり、機械学習向き
• type3: プリ処理(メッシュきったり)、ポスト処理(可視化)など
  • ストレージを共有しているのでポスト処理でデータの移動は必要ない
• クラウドシステム: よくつかわれている(稼働率8割くらい)
• ホットストレージ: HDD RAID 30PB 384GB/s
• コールドストレージ: xxx
• フロントエンド: ログインノード以外の利用も想定
• 料金は前払い 優先キューはポイント2倍でつかえる
• IORベンチマーク: /data/group1は一般、group2は大規模向け
• 独自ベンチ: github/exthnet/iotest type2のlocal SSDがおもったより速くない type1のホットストレージがおそい
• 気象 坪木先生
• 医用 森先生
• コールドストレージ操作ツール ODAPLUS
• COVID19用: AIでCTで肺を正常か炎症かセグメント分け
• 臓器のサンプルはあまりないので2つの臓器データ間を連続的に変形させて学習データにする
• シミュレーションせずに機械学習で気象予想 相馬先生
• コールドストレージ
  • ホットストレージ→コールドストレージはアーカイブ、 逆はリコール
  • 利用者支援室からホットストレージにデータ転送 計算結果をホット→コールドに転送
  • コールドストレージに直接光ディスクをつっこむのもあり
  • fibrechannelでフロントエンドにつながっている???
  • 光ディスクはwrite once
  • ドライブユニットは5しかないのでバッチで処理
  • 小さいファイルは固めて大きなファイルにしないと性能がでない
  • ディスクはセンターで買ってユーザが利用申請(早い者勝ち;ふつうに買うより安い) 利用終了したらカートリッジがもらえる

[2020-10-09 14:35]

[2020-10-09 14:36]

Prometheus ではじめる Gfarm サービス監視
— HPCI共用ストレージの1000日無停止連続稼働を強力にサポート —
理化学研究所　金山 秀智、芝野 千尋、原田 浩
東京大学　小瀬田 勇

• 無停止でアップデート、2拠点間でデータ二重化、これにより連続運用ができるようになった。
• gfarm zabbixプラグイン
  • アラートチェック
  • postgreSQL死活監視
  • データ完全性チェック
  • 設定情報の監視
• 稼働率とデータ保護の両方を重視している
• 現状: アラート検知→チケット起票→障害レベル判定→障害対応・緊急連絡・ユーザアナウンス
• これを自動化したい
• 監視ソフト: Prometheus、ダッシュボード: Grafana
• ディレクトリ数、シンボリックリンク数、レプリカ数はコマンドで取得できないのでメタデータを直接参照
• ユーザが利用してないときの障害は利用率にいれてない、タイムアウトも稼働率にいれてない、これはユーザ向けでない。
• shibbolethの認証情報をつかってユーザ向のgrafanaを表示できないか。

[2020-10-09 15:08]

休憩

[2020-10-09 15:30]

IO500 #1 DAOSアップデート
インテル株式会社　石橋 史康

• DAOS デイオス
• IO500で1位
• Optane(オプテーン) Persistent Memoryが前提
• dramとssdの中間的存在
  • dramとちがって永続性がある
  • ssdとちがってbyte addressingが可能
• daosではup direct modeをつかっている (memoryモードではない)
• posixとblockの問題を解決する
• posixで書くときにブロックサイズにあっているわけではない
• ブロックに複数のファイルが混ざるとロック待ちになる問題。

[2020-10-09 15:40]

webex調子わるい

• バイトアドレッシング可能なので問題回避できる。
• DAOSはlustreでつくっていた
• バイトアドレッシングできる永続メモリをベースにアーキテクチャをつくりなおし
• ふつうのファイルシステムというよりはオブジェクトストレージ
• ちいさいデータ・メタデータはoptane persistentへ (interface:PMDK)
• バルクデータはSSDへ (interface:NVMe)
• ユーザ空間で動かすので性能がでる。バージョンアップも楽に。
• posixでつかいたいときは dfuse(アプリ変更なし) or libdfs(変更あり)
• libdaosがnative interface (KV-storeっぽいAPI)
• apache sparkとかのAPIも用意する予定
• lustreとnamespaceを共有するパッチを開発中
• optaneはインターリーブきかせてつかうのがふつうなので障害に弱い → サーバごとにレプリケーションして回避
• erasure codeも将来的にはサポートする予定
• DAOSでデータのコピーを簡単に用意できるのでAIの学習で効果あり。
• ソースコードだけでなくRPMでも提供
• resources: https://github.com/daos-stack/daos
• dramエミュレーションもある

[2020-10-09 16:00]

• Q: IOR hardの性能はpersistent memoryはいいけどSSDはどうか?
• A: libdfsをつかっているのでコードをかえている。persistent memoryをつかっている。
• Q: スパコンのストレージを束ねるのに向いてるようにみえるが?
• A: できるけど、CPUをつかうので計算の邪魔になってダメかも(検証してないけど)。ストレージサーバにするのがいいのでは?

[2020-10-09 16:07]

[2020-10-09 16:11]

DDN ExaScalerのさまざまな性能改善について
株式会社データダイレクト・ネットワークス・ジャパン　井原 修一

• lustreベース
• exascalerはソリューション名
• lustre 2.10と2.12 がよくつかわれている (つぎは2.13)
• パッチはアップストリームになげていて、プライベートなパッチはあまりない
• 最近はシングルクライアントの性能も重視される (DGXみたいなファットクライアントがでてきたため)
• strided single shared file writeは性能がでていない lusterのもんだいもあるがblockアドレッシングのもんだいもある byteアドレッシングにたいおうしたい
• ページキャッシュのせいでネットワーク帯域がつかいきれてなかった???
• データベースではO_DIRECT+aioがよくつかわれる (lustre 2.10はサポートしてなかった 2.12はAIOがつかえるけど同期モードでうごく)
• gpfsとくらべてlustreはシングルスレッドの性能が低い問題 readaheadを並列化して改善 writeはまだ改善してない
• lustre IB multi-rail構成だとネットワークをつかいきれてないことがわかった。
• GPUダイレクト
• 4x DNN AI400 --(16xIB-EDR) Mellanox (8xIB-HDR200)-- 1x GDX A100
• CPUのアグリゲート帯域が100Gしかない問題を回避できる
• CPU:シーケンシャル(fio): write 94GB/s read 107GB/s
• GPU:シーケンシャル(gdsio): write 154GB/s read 178GB/s

[2020-10-09 16:38]

• Q: strided-SSF-Hardで何をかいぜんした?
• A: over stripe (OSTの数をこえてストライプできる) ロックのコンテンションを減らせた。 2.13で入る機能。
• Q: byteアドレッシングでなにをやる?
• A: プロジェクトredをやっている。deosにちかいアーキ。deosとちがって提供するサービスはブロックストレージ(kv-storeではなくて)。
• Q: gpu direct はai トレーニングで流行りそう?
• A: nvidiaとしてはやろうとしている。
• Q: gpu directは?
• A: ファイルシステムとしてつかえる。シャドーメモリとしてみえる。apiをlustreで実装するかんじ。

[2020-10-09 16:50]

[2020-10-09 16:51]

次世代のストレージ・ ファイルシステム技術
富士通株式会社　住元 真司

• NGACI(次世代先端的計算基盤)でwhite paper執筆中
• CXL: Compute Express Link
  • pcie 5から入る
  • キャッシュコヒーレンシあり
  • アクセラレータアタッチドメモリ
• redfish
  • DMTF
  • IPMI KCSのおきかえ
  • サーバの管理
• RPMA: remote persistent memory access
  • librpma
• 次世代:
  • アプリケーション特化ストレージ
  • OSバイパス
  • オフロード
• OSがクライアントとサーバで一体化したストレージになる?
• computational network:
  • MPIで転置行列はストライドアクセスできつがバイトアドレッシングできるとうれしい。
• LLIOのはなしはなし

[2020-10-09 17:31]

• Q: persistent memory, cxlは富士通としてはどう?
• A: 標準技術ははいるはず
• Q: グローバルなファイルシステムはひつよう? ローカル(テナント的なのが)なのがあればよい?
• A: daosみたいにがらっとかえるのもあるが、古いファイルシステムものこるはず。ユーザがえらぶ。

[2020-10-09 17:36]

クロージング

[2020-10-09 17:37]

懇親会

Journey×Journey 2号店にて。(参加者７名)

• 日時: 2018-10-26(金) 13:30〜17:53
• 場所: 市ヶ谷AP
• 主催: 特定非営利活動法人つくばOSS技術支援センター
• 告知: http://oss-tsukuba.org/event/gs2018
• 配信: https://www.youtube.com/channel/UC1KnuA8JpenG7kdL-q_WLlQ
• まとめ: https://togetter.com/li/1281389

[2018-10-26 13:30]

Gfarmファイルシステムの最新機能
国立大学法人 筑波大学　教授　建部 修見

• https://www.youtube.com/watch?v=d2Ijv7PG3m4
• 外部配信中
• 他と違うところ：データアクセスの局所性を重視、サイレントデータ損傷に対応
• 利用(共用): JLDG(10.7PB,8site),HPCI(100PB,2site),NICT,クオリティアactive! world。
• 利用(解析): すばる望遠鏡のデータ解析,メタゲノム解析
• 2.7.10が最新リリース
• 2.6.8で書き込み後ベリファイ(数時間後にベリファイ)
• バーストバッファ: ノードローカルなNVMeをつかって分散ファイルシステムを構築する
  • NVMeはジョブが割り当てられたときしか使えない
  • 永続性はすてて性能を重視 メタデータはメモリに載せる (postgresqlをやめる)
  • 196s → 20s
  • 0.3sで構成をつくれる
• データ移行支援: 運用を止めずに10PB→100PBに拡張するときに必要な機能を実装した
  • 書き込み禁止: ファイルに書けないけどファイルは作れるとか
• gfmdレスポンス改善: JLDG 数10PB/日 のアクセス linuxのスレッドの実装の問題だっ たが
• IB RDMA
  • クライアントのユーザバッファをpin-downして直接サーバから転送できるようになっ た。
  • 1.8倍性能向上
  • posix apiだと1.2倍
• quota
  • グループクォータとディレクトリ単位のクォータを併用できる (xfsはできない)
• データ完全性
  • 書き込み時にダイジェスト(SHA1とか)を計算
  • 読み込み時にチェック 異なっていたら lost+found に移動 修復
  • JLDG 9.9PB 111Mfiles 書き込み後ベリファイで5ファイル検出

分散深層学習を支えるストレージ技術〜AI橋渡しクラウド ABCIの事例と将来課題
産業技術総合研究所人工知能研究センター　主任研究員　佐藤　仁

• https://www.youtube.com/watch?v=CnfjLiaEaWc
• 東大柏に 0.550EFlops 37.2PFlops(DP) 19.88 PFlops(peak) 国内最速スパコン
• gfarmも動く (サポートはしてないが検証はした)
• 建物から設計した
• 1node = tesla V100 x4 + Xeon Gold 6148 + 384GiB + NVMe 1.6TB + EDR IB HCA x2
• 1rack = 34 nodes + full-bisection BW fat-tree ; 70kW
• inter-rack = 1/3 BWで接続されている
• storage
  • local: 1.6TB NVMe BeeOnd(like burst-buffer)でまとめることもできる
  • parallel filesystem: GPFS (DDN SFA14K) x3
  • object storage: GPFSの領域の一部でopenstack swiftをうごかしてS3 like APIを提供。グローバルからアクセスできる。暗号化も。
• 分散深層学習
  • データ並列
    • 同期型 パラメータを正確に更新できるので精度が高い デファクトスタンダード
    • 非同期型 はやい
  • モデル並列
• GPU+CuDDN(演算), NCCL2(ネットワーク通信), MPI(プロセスの起動)
• Chainer: forward->backword->optimize
• ChainerMN: forward->backword->allreduce->optimize
• 汎化性能: 局所最適化を避けて全体最適化したい
• ABCI Grand Challenge
• いまどき: linear scaling rule, gradual warmup, LARS
• IOのスループットだけでなくメタデータ性能も重要 データセットが小さい 1画像70kB 弱程度
• 学習時にランダムネスを上げるようにする 汎化性能のため
• chainerだと配列のようにアクセスするのでopen+read+closeが大量発生してしまう。
• フレームワークによってはDBをつかうものもある。
• ファイルキャッシュを入れると1時間のものが30分くらいになる。
• 将来課題
  • マルチテナントとセキュリティ
  • 企業や医療データ
  • 資源を動的にユーザグループ毎に棚貸し

[2018-10-26 14:32]

• Q: キャッシュが有効なのはなぜ？ 何度も同じファイルを読んでいる？
• A: もっと上のレイヤーでのAPIがあるといいかも。

次世代スーパーコンピュータ向けファイルシステムについて
富士通株式会社　次世代TC開発本部　ソフトウェア開発統括部
シニアアーキテクト　住元 真司

• https://www.youtube.com/watch?v=Mf1AocSM1uA
• A64FX
  • 1chip = (12core+1core) x4
  • 1世代前のsparc chipに比べて2倍の性能
  • Tofu2 -> TofuD
    • そのままもっていくとコスト(シリコンと電力)をくう
    • laneを半分に減らして数を増やした
• FEFS for K computer
  • 8万ノード 100PB 1TB/s 当時luster1.8
  • 性能か信頼性かはユーザが選べる
  • stage-in → 計算 → stage-outの3段階 3倍の容量が必要になってしまう
  • ファイルの指定が手間
  • 計算時間が短かいとデータの移動がムダ(利用効率が落ちる)
• ローカルはよりアプリ寄のストレージ → luster-based → アーカイブ
• データのライフタイム、アクセスパターン
• 1プロセスが1ファイルを読み書きするパターン、ファイルをつかってプロセス間のデータ通信するパターンが多い。
• SSDの寿命の問題 アプリが1日にどのくらい書き込むか重要
• intel optaneは性能はいいけど書き込み信頼性はnandと変らず。素子自体は信頼性が上がっているが回路の部分がいまいち。
• How SSD based storage shoud be used?
  • lifetime, application's access pattern, data sharing in a job, data shareing among multiple jobs, ssd lifetime issue
• LLIO (prototype) burst buffer nodeを用意する

[2018-10-26 15:06]

• Q :メタデータは2nd storageをつかう？
• A: キャッシュとしてつかうときだけ。ローカルなら

[2018-10-26 15:07]

休憩

[2018-10-26 15:16]

オブジェクトストレージ、AI＋IoT＋映像における利用事例
クラウディアン株式会社　取締役COO 本橋 信也

• https://www.youtube.com/watch?v=sZCT-W_xFCo
• 日本発だが海外の方が大きくなった。
• オブジェクトストレージ
  • 大手の通信事業者のメールシステム NOSQL
  • amazon S3 とおなじものをつくった -> HYPERSTORE
  • ベンチャー企業として賭けに勝った
• クラウド事業者向けに販売
• P2P 3ノードから
• 日本だとPBを要求する客は少ない。
• 容量はEBくらいまでは拡張できるのを確認している。
• replication + erasure-coding
• バスにカメラ5台をインターネット経由で保存。
• AI向け: メタデータとblobをまとめて扱える。
• 実証実験: 高速道路を走る自動車をリアルタイムで識別してデジタルサイネージを出す。
• →駐車場・ショッピングモールでつかいたいという客が。
• GPUどうする？クラウドだとレイテンシが → AI BOXをつくった。
• 4Kカメラ 圧縮すると意味がない エッジの処理が必要
• 交通量の測定をAIで
• 画角は手動で設定
• 自動で車線を認識 車をカウント 速度 直進 右左折 CSVでデータを送る。
• エッジで学習用の画像を切り出してクラウドに貯める。
• 車の車種はロングテールで自動でタグ付けする必要がある。

Scalityと大規模オブジェクトストレージの運用の実際のご紹介
スキャリティ・ジャパン株式会社　セールスエンジニア　仁戸 潤一郎

• 創業はフランス 2009
• メールサービスのストレージからはじまった
• 製品: RING ZENNKO
• データはつかって価値が出る。
• データはオンプレに置いてワークロードはクラウド。
• object storageは容量重視、flashは速度重視、NASはあまり市場はない。
• NASは人間のスケール。flashはオブジェクトストレージはアプリが相手。
• RING 汎用x86 linuxで動く。ソフトのみ提供。NFS,SMBでもオブジェクトにアクセスで きる。
• P2P CHORD
• アプリケーション RINGコネクタサーバ ストレージサーバ スーパーバイザー
• コネクターはブートストラップノードリストをもっていてリクエストをなげる。
• メンテナンスタスク
  • balance ノードのつけはずしのときにデータを移動する
  • proxy
  • rebuild 最新のバージョンをもっているか定期的にチェックする
  • repair ディスク障害時にインデックス情報から再レプリカをつくる
  • purge 古いバージョンの物理削除
    • オブジェクトはコンテナファイルに保存しているのでinodeを消費しない
  • relocation
    • デフラグ
• バックグラウンドタスクの負荷調整
• 国内事例: KDDI iphone mailでつかっている
• キースペースの設計が必要でシミュレーションで確認する。障害時に負荷が分散するように配置しないといけない。サポート体制が重要。
• オジェクトストレージはアプリケーションの関する知識が必要。

[2018-10-26 16:16]

• Q: 物理的な配置は?
• A: データセンターをまたいでも構成できる。スプリットブレインになってもデータは アクセスできるように複製している。ラック単位・シャーシ単位でも考慮できる。

HPCI共用ストレージにおけるディザスタリカバリ、
データ二重化運用による高可用性 と災害対策の実現
国立研究開発法人理化学研究所　開発研究員　原田 浩

• https://www.youtube.com/watch?v=9i76p_njrOc
• 8/23 台風20号 電源障害
• 8/31 落雷で停電
• HPCI共用ストレージ そろそろ運用もおわるけど
  • 補足:運用が終わるのは京でHPCIは続くらしい。認証基盤だし。
• 通信はGSI(grid security infrastructure)で暗号化している
• 物理的には100PBくらい、二重化しているので使えるのは50PBくらい。
• SINET5
• メタデータサーバは東大と理研で二重化
• フェイルオーバは自動化されてないのがつらい
• データ破損があっても1営業日くらいで通知できる体制になっている。ユーザにはデー タは1週間くらい保存するようにいってるけど。
• スパコンでつくるデータはお金がかかるのでデータ消失は防ぎたい。
• 理研台風
  • 受電設備に水が入って止まった
  • 京コンピュータが止まったがストレージは止まらなかったのは幸運だった。
  • 仮復旧で停電する可能性があるので全マシンを止める必要があったのでマスターを理研から東大にフェイルオーバー。readonlyに。
• 柏落雷
  • 東大にマスターがなかったのでたすかった。
• 重度障害報告はしなくてすんだ。
• IPアドレス変更・ドメイン変更のときはさすがに止めた。
• 次の増強時は容量に余裕があるのでサイト内で二重化できそう。
• 計算機センターに設置できるのはキャッシュメモリだけになって、ストレージは外部に、ということになりそう。場所の問題。
• セキュリティレベルは民間レベルはむつかしいのではないか。お金の問題だとおもうけど。

[2018-10-26 17:01]

休憩

[2018-10-26 17:07]

パネル：ポストムーア時代のストレージシステム

建部

1. ポストムーア時代に想定されるストレージへの要求と問題点
2. その問題点を解決するために必要な技術、デバイス
3. ストレージの向かうべき方向

佐藤

• スパコン業界からは「ストレージなんでどうでもいい」とおもわれているのではないか。
• 高速なメモリ(HBM)をどう生かすか
• NVDIMMをチェックポイントにどうつかうか
• HPCコンテナ -- オールフラッシュストレージ -- オブジェトストレージ オンプレ・クラウド
• トラディショナルなストレージだとユーザ・グループ単位の認証になるが、APIキーの ようなものも必要。

住元

• 電力vs性能が重要
• アメリカでは many-core と gpgpu の二種類
• さまざまなarch
  • ノイマン型
  • アナログ型
  • ニューロ関係
  • 量子
• こういうコンピュータとストレージをどうつなぐ？
• なにがひつよう？
  • 移動データを抑制する
  • 主記憶の電力を抑制しながら大量データ処理
  • 蓄積型からストリーミング型のデータ処理に

本橋

• flash hdd tape が連携
• NBC テープアーカイブをHDD化した。トランプの若いころの映像を探すのに手間どった 。
• メタデータ データの中身の情報のこと タグ付け 自動で

仁戸

• ムーアの法則が終わって何がこまるのか？
• クラウドに資本が集中する
• データはまだサービスにくっついている
• 個人にデータのものになるとよいのではないか。(おくすり手帳のような)

原田

• 地理的な壁を越えたい。
• 軽いストレージがほしい。床の耐荷重が問題になる。半分くらいしか積めない。

建部

• まとめ

質問

• Q: コンピューティングのためのストレージとストレージとしてのストレージ ポストムーアで分散になってストレージのブレークスルーはなに？
• A:
  • 佐藤 スパコン屋はデータの使い方を考えてないのが問題 データの整理を自動化する 方向に。
  • 住元 ストリーミングで計算 蓄積しない方向へ
  • 本橋 GPUもストレージもひとつの箱で客に提供したい
  • 仁戸 ひとつの箱にはおさまらないのでネットワークの中にストレージがふくまれる 融合する
  • 原田 スパコンセンターはバッチスケジューラだけでいいのか？ データの場所で処理 する方向に。

[2018-10-26 17:53]

懇親会は鳥元。

そのあと曽田さん・白水さんとエクセルシーオルへ。

• http://oss-tsukuba.org/event/gs2017
• 2017年12月22日(金)
• 筑波大学東京キャンパス文京校舎 122講義室
• 主催: 特定非営利活動法人つくばOSS技術支援センター
• https://togetter.com/li/1182456

司会 NPO 松山

[2017-12-22 13:31]

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

• 19000 downloads since 2007/03.
• オーストラリアでもサポート(Libre solutions Pty Ltd; 主にdebian package担当)
• HPCI共有ストレージ 大学間 〜100PB
• release 2.7.8が最新
• 書き込みキャッシュストレージ支援
  • クライアントとストレージのあいだにキャッシュをはさむ。
  • write back
  • キャッシュの仮想負荷よりもストレージの仮想負荷を上げてキャッシュに書き込まれるようにする。
• データ移行支援
  • ストレージを書き込み禁止にできる。
  • 書き込み禁止だけどファイルの複製はつくれる。
• Gfarm/バーストバッファ
  • 計算ノード上のNVMeを分散ファイルシステムにする。
  • 一時データ用
  • メタデータは永続化しない・冗長化しない (どうせジョブの動いているあいだだけでいいので)
  • 5400 iops (pgsql+journal+slaveMDS) -> 12000 iops(-slaveMDS) -> 15000iops (永続化なし)
• ファイルシステム構築撤去の高速化
  • 構築0.31s 撤去0.19s
• InfiniBand RDMA
  • 内部バッファをつかった転送とユーザバッファ(pin downed)に直接転送するのもできる。
  • max 1.8GB/s
  • max 1.2GB/s (POSIX API)
• ディレクトリクォータ
  • ディレクトリ単位のファイル数・サイズの制限
  • XFSのとはちょっとちがう
  • パーティションにみせかけているので、ディレクトリ間のmv/linkはできない
• 完全性
  • digestを書き込み・読み込みで計算してチェック。
  • 破損していたらlost+foundに移動。
  • 書き込み後6時間後に読んでチェッックしている。
  • 性能は -10%
  • 実際にIOエラーがないのにファイルが壊れたことがあった。
• クラウドストレージとの連携も進行中

[2017-12-22 13:57]

大規模言語資源を活用した自然言語処理 / 井之上 直也、山口 健史（東北大学）

• 乾研究室でgfarmをつかって研究している。
• 言葉がわかるコンピュータ
• メンバー 40名
• 形態素解析、構文解析、述語構造解析・照応解析・省略語解析
• 言葉がわかるとは? -> 行間を読むこと
  • 「庭に洗濯物を干したとたんに雨が振ってきた」
  • 目的・条件を知識からみちびいて、残念だったという推論ができる。
  • どうやって膨大な知識をあつめるか?
  • トレンド: webから知識をあつめてくる。
  • 言語構造解析による大規模知識獲得: パターン(フレーズ)とインスタンスのマトリクスから知識を抽出
  • 意見解析: 文章からトピック賛成・反対しているのかを推論する。うまくいかない例: 言論弾圧 vs 言論の自由を抑圧 表現がちがいすぎてうまくマッチングできない例
  • サイレントマジョリティの意見の予測: ソーシャルネットワークから意見を表明してない人の意見を推定する。
  • 論述問題の自動添削: 記述力を養うためには添削によるフィードバックが必須
• うまく言語表現の多様性のせいでマッチングできない問題はdeep learningで解決する方向.
  • 例: the girl gasped -> she heard the news.
• 典型的な処理
  • SNSデータ: JSON圧縮で14TB。これを基本的解析+フィルタ+頻度して実験データをつくるところまでgfarmで。そのあとはCPUサーバへ。
  • gfarm+GbEで構築。データの局所性が利用できるのがメリット。
  • 学生はまずpython。makeになじみがない。pwrakeをつかってもらうのはむつかしい。 -> シェルをたたいてがんばる。
  • gfwhereでデータがあるノードをさがしてsshで計算させる、というのがメイン。

[2017-12-22 14:21]

休憩

[2017-12-22 14:30]

HPCI共用ストレージ東拠点の機材更新に伴うデータ移行について / 中 誠一郎（東京大学）

• 5年ぶりの機材更新: 西:理研(AICS) 東:東大 SINET5
• 東大のスパコン室に空きがなく、新旧のストレージ機材の共存は不可
  • パイロットストレージのラックをつかってデータ移行
• データ移行が終了->撤去->新規ストレージを設置 を順にくりかえしていく
• データ移行方式
  • 複製数1のファイルが多数存在 平均1.3 (ユーザまかせにしたら、こうなってしまった)
  • moveではなくcopyで。 gfprep --mmオプション + 余剰レプリカを残す
  • replicainfo方式: COMPLEMENT_GROUP=移行元以外 こっちの方が速度が出た
• まる1年かけて移行: 最初のころは並列度1で 17T/day。並列度あげて96TB/dayまででた。
  • gfprepはファイル数が増えると遅くなるっぽい。 -> 建部先生に相談して replicainfo に。
  • replicainfoで 3-15TB/dayしかでないレスポンスも悪化(gfarm 2.6.21)。 改良して 152TB/day (gfarm 2.6.23)
• 移行ストレージはもったいないのでログインノードに転用予定。

[2017-12-22 14:50]

• Q: サイレントデータコラプション対策した?
• A: write verifyで確認している。

[2017-12-22 14:51]

[2017-12-22 14:52]

HPCI共用ストレージにおける階層型ストレージの導入構想 / 原田 浩（理化学研究所）

• Gfarm日本征服計画
• AICSも機材更新中
• azureにアーカイブサービス実証実験中
• RAID6(8D2P;100TB/disk) x 58set x11set
• UNCAIによるクラウド基盤の提供
• Gfarmの階層化支援機能
  • 余剰レプリカ自動削除機能をつかてキャッシュぽくする。
  • replica_check_remove_grace_used_space_ratio & replica_check_remove_grace_time
  • 二次ストレージへの一次書き込み抑制
    • 一次書き込み先選択アルゴリズム: busy hostには書かないようになっている
• 手離れのいいGfarmサービス/Gfarmサーバのワンストップサービスが求めれれる。。。
• 文科省から3年間はエビデンスを残すように指導がある -> スピードよりも容量がもとめられている -> クラウド
• Azure(西日本リージョン)にgfarmスプールサーバをおいて実証実験中 (メターデータは東大)
  • azure VM -> client: 2Gbpsでている(たぶん帯域制限をくらっている)
  • 速度が出てないが調べてみたらおそいプロセッサがまざってるっぽい。
  • クラウドストレージはバイト単価も安くなってきたし、予算の年度区切り問題がなくなれば。

[2017-12-22 15:15]

[2017-12-22 15:17]

Gfarmを加速するDDN GfarmScaler / 橋爪 信明（DDN）

• SFA4KXE,SFA7700XE: バックエンドはXFSで、Gfarmをコントローラ上でうごかす。
• 14KXE/1VM: wriet 7GB/s read 8.5GB/s
• pacemaker/corosync で XFSフェイルオーバー

[2017-12-22 15:30]

• Q: 1MBからブロック変えたら?
• A: 1MBより小さいとダイレクトIOがつかえなくて性能が落ちるはず。ブロックサイズはRAIDを組むときのchunksizeに関係。

[2017-12-22 15:32]

[2017-12-22 15:33]

ひまわりデータ解析を支えるPwrake/Gfarm / 村田 健史（NICT）

• 気象災害は人口あたりでみるとアジアは多い。
• http://himawari.asia
• 公開されてないデータがあるのでは? -> データを1bitも隠さない・リアルタイム更新・だれでも見られるをポリシーに。
• 日本なら10分以内に更新される。年間100万アクセスある。最大のユーザは気象庁?
• ズームインしたときの画像は常につくりつづけている -> 3年間で73TB。ファイル数が多いのでinodeが足りなくなる。
• 映像IoTがGfarmに期待すること
  • カメラをあらゆるところに設置する
  • raspinihaH264のエンコーダが載っていて高性能
  • ドライブレコーダのようにリアルダイム伝送できている
  • hpvt(high-performance vide transfer)映像伝送ツール
    • ACK 300msごとにネットワーク帯域を監視して、動的にエンコードパラメータを変えている。映像が途切れない。
  • raspiをつかっているのはOpenCVで画像処理できるため。
  • 2.5GB/day
  • 処理・保存でpwrake/gfarmの利用可能性
  • パッケージングして売れそうな予感

[2017-12-22 15:51]

• Q: raspiはくるしくない?
• A: FHD 30fpsはくるしい。730p 30fpsくらいならなんとか。
• Q: ディレクトリ毎にメタデエータサーバを変えたら解決するのでは?
• A: そんな金はないし、そこまでしてgfarmしてつかわなくても。。。

[2017-12-22 15:56]

休憩

[2017-12-22 16:11]

パネル討論「ファイルシステムのこれから」

• モデレータ: 建部 修見（筑波大学）
• パネリスト:
  • 住元 真司（富士通） Post京
  • 井原 修一（DDN） Luster
  • 曽田 哲之（SRA） gfarm
  • 石橋 拓也（創夢） gfarm
  • 守分 淑子（数理技研） gfarm

守分

• 数理技研の紹介
• UNIXの移植
• 1983年 socketがでてきた
• 1993年 mosaicがでた
• ファイルシステムをやるようになった
• 2003年 gfarmの開発に関係するように
• ディレクトリの名前管理は難しい。1ディレクトリに1万個もファイルつくられてこまる。（曽田さんコメント：Gfarmのディレクトリ構造は、オンメモリ・赤黒木なので、1万でも100万でも困りません)
• readdirとファイル削除の競合は難しい問題 readdirのAPIが変えられないのがつらい
• mmapは癌 マップされているとread/write権を剥奪できなくてつらい
• 50年前のAPIをひきづっていて、変わらないのはいいけど、そろそろ変わってもいいのでは?
• hard linkはなくてもいい。
• ビッグデータで小さな大量のファイルのあつかいをなんとかしたい

石橋

• 2002年 gfarm v1 の開発にかかわる
• 当時はsyscallをフックしてたのをfuseをつかうように
• もっとも大切なことは: 簡単に普通につかえること。普及していること。
• 分散ファイルシステムはローカルディスクよりも速い!?
• 無限のファイル数をあつかえるように。メタデータアクセスも分散させて。
• ユーザ管理・アクセス制御・セキュリティを簡単に。
• Gfarmの利点: POSIXインタフェースの妥協なき実装

曽田

• 1996-2000 SCore
• 2000/11- Gfarm v1
• 2004-2007/3 Gfarm v2初期実装
• (予算が...)
• 2008/10- Gfarm
• だいじなこと: 信頼性、性能、スケーラビリティ、拡張・移行が用意(リバランスが不要)
• クラウドベンダーごとのストレージ、アプリケーションごとのストレージ、用途別のストレージが乱立しすぎ
• 汎用の並列ファイルシステムに収束してもいいのでは メタデータ集中型・メタデータ分散型
• 同期複製機能がほしい (現状はgfarmは非同期複製)
• fine-grained lock (理研の64coreだと性能が出せてない)
• メモリ外メタデータ (gfarmはメタデータがメモリに載っているのでスケールしなくなってる原因)
  • おもってたよりメモリが安くならず
• リモートアクセスでの性能向上
  • 遠隔ファイルシステムとしては使われているほう
  • できる最適化ができてないものがある
• 各クライアントでうごかすNFS gateway

井原

• 2010年 DDN入社 (その前はSUN; OracleではHPCできないということで)
• LustreとH/Wをインテグレーションして販売してた
• 欲しい機能が実装されるのを待つのではなくDDN内でLustreの開発をするように
• 開発メンバーは6人くらい
• オープンソースの開発ではプライオリティづけがむつかしい
• 欲しいデータに安全に確実にアクセスでいることが重要
• Lustreをみているとかなり足りない機能がおおい (性能にふりすぎている)

住元

• 1986-1997まではUNIXいじり 分散FTフィルシステムつくた(log based)
• SCore
• RCCS
• PACS-CS
• 京 MPI FS
• ファイルシステムの現状と課題
  • VFSがでて作りやすくなったけどkernelオーバヘッドが
  • メモリ階層を考慮すべき
  • OSのプロセスだけでなく、仮想マシンとかコンテナとかLWKの考慮
  • Luster: posixセマンティック確保のほか、linuxオーバヘッド回避の話題がおおい
• 用途別につかいわける時代になっている
• ローカルは軽く・高速に
  • VFSじゃま: アプリケーション特化型・OSバイパス → ユーザレベルのファイルシステム
  • NVMeが持つ機能をもっとつかおう
• ネットワークファイルシステムはユーザレベルでOSバイパス。

建部

• POSIXやめましょう。

• Q: (西) gfarmの普及を阻害している原因は?
• A: むつかしそうだから? ユーザが構築できない。 CentOS/RHのバイナリ配布がないのが問題。 世界に配信すべき。

• Q: (原田) gfarmの最大のライバルはクラウドストレージでは? ここ数年でAPIが高度化している。 scatter/gatherもできる。 データ移行もしやすく。 gfcopyを拡張して。
• A: gfarmもMacからつかえるといいなぁ。 クラウドストレージはGとかAとか以外は共通APIがでてきてもいいなぁ。標準化活動が必要。

[2017-12-22 17:33]

• 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連携

[2016-12-09 17:00]

• Q: クラウド活用はこれまでのテープアーカイブの代わり？
• A: もうちょっと違う可能性もあるのではないか？ 遠隔可視化とか。
• Q: 遠隔可視化について：名古屋大小野先生によると：可視化の表示自体を遠隔で行う(クラウド側でOpenGL)のも良い解法。

[2016-12-09 17:03]

閉会

なにやら学生野球資格回復プロ研修会というのをやっていて報道関係者もきてた。

(懇親会には参加せず帰りました)

関係ないけど、駅前にTRC(図書流通センター)ってのができてた。ビルにパースがついてるように見えるのがおもしろかったので。

• http://kokucheese.com/event/index/352921/
• 2015-12-14 13:30〜17:20
• 筑波大学東京キャンパス文教校舎 122
• http://togetter.com/li/912835

朝に参加申し込みしようとしたらすでに締め切られていたので突撃。余裕もって出発したのに山手線が遅延して時間ぎりぎりに到着。会場はWiMAX圏外。お茶大もWiMAXつかえなかったし茗荷谷はWiMAXよわいな。

[2015-12-14 13:32]

特定非営利活動法人 つくばOSS技術支援センター / 筑波大学 建部修見

• Gfarmをホームディレクトリにしてautomountする情報など提供

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

• JLDG(7PB,8拠点), HPCI共用ストレージ(22.5PB,3拠点): アーカイブ用途がメイン
• 最新版: Gfarm2.6.7
  • ファイルシステムにノードグループ: 複製配置機能
    • グループにいくつ複製をつくるか指定できる。
    • 余剰複製の削除をするようになった。(ノードが止まった→ノードを追加→ノードが復帰→余計なノード削除)
  • クライアント透明なフェイルオーバ: クライアントにエラーを返さずに処理続行
    • 自動でサーバ切り替え。
    • ファイル書き込み中でもフェイルオーバも可。
    • closeのタイミングで競合状態があって、期待しないほうがlost+foundに入ってしまう可能性がある。
    • 運用中のソフトウェアアップデートもできる。(先日JLDGでライブ更新をした。問題なし。)
  • end-to-endのデータ完全性
    • こわれていたらread→EIOでlost+foundに移動→正しいデータをもってきて自動修復
    • write→ちょっとまつ→verify
    • クライアントでもチェックすることでネットワークエラーも検出できる
  • gfpcopyの高速化
    • BULKWRITE/BULKREAD: FTPのようなアプリ向けのAPIを新設。
  • 運用監視
    • Zabbixプラグイン→slaveフェイルオーバすることも
    • Gangliaプラグイン
  • automount
    • gfarm-sambaプラグイン (gfarm2fsなしにアクセスできる)
  • CentOS 7対応
  • Linuxカーネルモジュール
• 分散並列処理
  • ワークフロー: データインテンシブ・サイエンスアプリでよくつわれる。
    • ファイルとプロセスに依存関係がある。
    • Rakefileをつかって依存関係を記述できる。
    • Rakefileなら14行のところDAXだと41行にもなる。
    • pwrakeで並列実行。データの移動が少なくなるように、ディスクキャッシュを効かせるようにスケジューリングする。(多制約グラフ分割問題)
    • LIFO+HRF
  • Pwrake 2.0.0リリース
  • gfarm Hadoopプラグイン: gfarm://で
    • HDFSとの比較: レプリカ増やしても性能劣化が少ない。
• close-to-open一貫性
  • writeがcloseしたときにreadレプリカを更新する。

[2015-12-14 14:18]

• Q: pwrakeでのLIFOってなに?
• A: 最近実行されたタスクの依存関係で次のタスクを優先的に実行する感じ。
• Q: 大きいファイルから処理するオプションがあったらい便利かも。(ファイルのサイズで計算量がわかるケースで依存関係がない場合)
• A: 次期リリースで

[2015-12-14 14:21]

[2015-12-14 14:23]

HPCI共用ストレージにおけるデータ一貫性管理 / 理化学研究所 原田浩

• 2015年3月末にユーザからデータ障害の報告
• 5月に障害規模が特定
• 2週間かけてチェックサム照合 (ディスク15PBの全チェック、ファイル容量としては8PBくらい)
• 5課題5ユーザ922ファイルを消失していた。
• 152392ファイルに破損あり。オリジナルからの復元可能。
• 2014/8/20〜10/29のあいだに障害がおきていた。7ヶ月後に発覚。
• 京740万ノード時間が再計算に必要になった。小規模なスパコンセンターの1年分の資源量に相当。
  • 年度を跨ぐと計算時間を与えたくても課題がおわってしまっていたり。
  • 論文のデータが失なわれてしまったらエビデンスがなくなってしまう。
• ストレージコントローラだけでエラーログがでていると管理者が把握しにくい。
• 運用上、ユーザのデータを読むのはむつかしい。
• 対策: ユーザが一定期間オリジナルを保存する。
• データ破損とデータ消失
  • 破損: どこかに正しいデータがのこっている
  • 消失: すべてデータが壊れている
• 消失ファイルリストは1日2回管理者に通知(UIDとinum)。消失ファイルはメタデータから消して、新たな消失ファイルの見落としをなくすように。
• gfspooldigestで毎日チェックした破損検出するようにした。
• 原因はIBのsrpdの二重起動だった。

[2015-12-14 14:54]

• Q: gfarmの問題ではなくHW障なのでネガティブキャンペーンにつかわれないようにしないと
• Q: 書き込み後にエラーを検出できいなのでは?
• A: 1日後など定期チェックで検出できる。

[2015-12-14 15:00]

[2015-12-14 15:01]

HPCI共用ストレージにおけるITIL視点でのGfarm運用分析 / 東京大学 中誠一郎

• 8月からITIL(information technology infrastructure library)実施
• 問題: 破損から検出まで時間がかかった・破損検知の監視運用が弱い・真の原因が判明せず
• 各拠点のSIベンダーはばらばら(H/F/N)。ここまでマルチベンダーの例はあまりない。
• 成熟度レベル(CMMI)
• レベル2+αを参集レベルとしてガイドラインを策定
  • 構成ガイドラインと運用ガイドラインと
• 参入レベル:メタデータサーバはなし、ストレージサーバのみ供出
• ITIL: 運用の手本として民間では活用されている
  • サービスサポート: 日々の運用 (サービスデスク・インシデント管理・問題管理・変更管理・リリース管理・構成管理)
  • サービスデリバリー: 中長期 (維持管理)
• gfmdフェイルオーバの運用ガイドラインも策定したい。
• 運用4P(processプロセス,people要員,productsツール活用,patners外部組織連携)
  • それぞれについて成熟度レベルを目安を定義

[2015-12-14 15:38]

休憩

[2015-12-14 16:01]

Gfarm/Pwrakeを拡張した様々な科学研究アプリケーションとそれを支える高速データ通信プロトコルの開発 / 情報通信研究機構 村田健史

• NICTサイエンスクラウド
  • 3PB どちらかというと小規模
  • アーカイブというよりは計算用途
  • 予算がつかなくてサーバがどんどん死んでいくけどシステムの可用性は保たれている。
• 可視化: データが増えてもそれを表示するディスプレイが小さいままなのが問題。
  • これまではオンデマンドで可視化。でもレスポンスタイムが悪化するばかり。
  • 事前に想定される画像を作っておく。意外とバリエーションはない。
    • 大量の画像をつくるのにgfarm/pwrakeが役にたつ。
    • ひまわり8号: 遅延10分で新しい画像をどんどん作っている。時間軸があるのでgoogle mapよりもデータ量が多い。
    • 読売新聞の明治6年移行のカテゴリ毎の記事の出現率のグラフ。これも画像を大量生成しておく。
  • アプリの種類: リアルタイムかオンデマンドか
• 高速化
  • HbVRS: high-andwidth virtual remote storage
  • UDTプロトコル
  • 日米間で7.2Gbps
  • HpFPプロトコル: http://hpfp.nict.go.jp
    • TCP比: 遅延やロスが大きくてもスピードがでる。(RTT500ms,loss1%でも)
    • ライバルは ASPERA/Fasp
  • でも1ファイル1GBもいかない。小さいファイル10MBとかが多い。HpFPでは性能がでる。
• Gfarmはデカい話をしすぎているのではないか?コンパクトな話もすべき。

[2015-12-14 16:37]

• Q: なぜTCPより速い?
• A: ウィンドウサイズの上限がない。
• Q: APIは?
• A: アプリレベル。
• Q: TCPとの公平性は?
• A: 実装してない。月とか南極で使う話が進んでいるので後回しになっている。狭帯域ではTCP friendlyで、広帯域で帯域つかうようにするか。難しいのでソフトのバージョン分けしちゃうかも

[2015-12-14 16:41]

[2015-12-14 16:42]

(株)クオリティアにおけるGfarm活用事例 / クオリティア 駒木義孝

• メールホスティングサービス(SaaS)におけるストレージ
• active! mail (パッケージソフト)
• Active! World: 独自ドメイン・メールホスティングサービス
• メールホスティングではIOPSを稼がないといけない。たいていのストレージベンダーがにげだすレベル。
• dovecot

[2015-12-14 16:56]

「Active! World」におけるGfarm / クオリティア 根本昌孝

• メリット: メールのデータでも性能がでる
• デメリット: gfarmメタサーバに高スペックが要求される
• dovecotはgfarm APIをたたくように改造。3台に書き込み(レプリケーションつかわず3回書き込み)。書けなかったらトランザクションエラー。
• dovecotでactive→standbyにindex/cache転送している。
• メタサーバのdiskにはfusio-io iodrive duo 640GB
• ネットワークトラフィックで100Mbpsでてる。メールでこれはけっこうな量。
• ファイルサイズ: 30KB 4億ファイル数

[2015-12-14 17:07]

• Q: なぜgfarm?
• A: 当時は分散ファイルシステムがなかった。
• Q: 次もgfarmをつかうか?
• A: 価格と実績とIOに強いという点で最終選考にのこっている。
• Q: 性能は?
• A: 秒間60セッションをさばけるのが目安。(月曜朝)
• postfix→dovecotはLMTPで。

[2015-12-14 17:12]

懇親会

海鮮居酒屋 はなの舞 茗荷谷駅前店。ビールたくさん飲んだ気がする。締めがえびせんというのはちょっと納得いかない。

池袋でふらふら写真撮ってから帰宅。

• 日時: 2014-12-16 13:30〜17:30
• 場所: 筑波大東京キャンパス文教校舎(茗荷谷)
• 案内: http://oss-tsukuba.org/?page_id=554
• 申込: http://kokucheese.com/event/index/233115/
• まとめ: http://togetter.com/li/758525

一日中、冷たい小雨が降っていた。風も強めで体が冷える。

[2014-12-16 13:31]

理事長挨拶 / 建部修見

• サポートのためNPO昨年設立
• gfarmファイルシステム
• gfarm2fs
• sambaプラグイン
• zabbixプラグイン
• Pwrake(プレイク) 大規模向け
• gfarmをホームディレクトリとしてautomountする情報などを掲載

[2014-12-16 13:35]

Gfarm2.6の新機能 / 筑波大学 建部修見

• リリースする予定
• 今朝sourceforge.netのCVSサーバにトラブルがありreadonlyになっててリリースできてない。。。
• 2000年から研究開発している。14年。
• 広域ネットワークで遅延があっても性能が落ちないように工夫。
• 単一障害点がない。(自動ファイル複製、ホットスタンバイMDS)
• ダウンロード数: 15175
• これまで複製の数の指定はできたが、場所も指定できるようになった。
• クライアント透明なフェイルオーバ：アクセスしている最中でもアプリにエラーを返さないようになった。(もっとも工数がかかってる! 異常系3年以上テストした! 自信あるよ!)
• end-to-endのデータ完全性 (確実に書けて、確実に読める、データ化けがない、下のファイルシステムでデータ化けがあっても)
• gfs_pio_sendfile： read/writeじゃなくてsendfile系apiでgfpcopy(並列コピー)が高速化。
• CentOS7対応：起動ファイルがsystemdになったり。
• Linuxカーネルモジュールがつかえるようになった(CentOS6.4で動作確認)
• ファイルシステムノードグループによる複製配置指定機能
  • ノードグループの指定: gfnodegroup -s hostname groupname
  • 複数属性の指定: gfncopy -S GroupA:2,GroupB:1 directory グループごとの複製数を指定
  • 従来: gfncopy -s NUM directory 複製属性の方が優先、Σ複製属性<複製数なら、残りはてきとうに配置
• フェイルオーバ
  • すべてのAPIが再接続して処理継続。クライアントにはエラーをかえさない。
  • フェイルオーバと書き込みが競合した場合(書いたのに消えるケース)は、lost+found に移動。
    • proc Aがファイル更新中(複製あり)にgfmdフェイルオーバ発生
    • proc Bが同一ファイルを更新(フェイルオーバ中のためproc Aが更新していることに気づかない)してcloseした。
• end-to-end完全性
  • gfsdでチェックサム(md5)を計算してた。(gfarm 2.5.8.5以降) 逐次読み書きのみ。
  • ファイル複製のときにチェックサム計算ようにした。
  • クライアントライブラリでもチェックサム計算して、ネッーワークエラーもチェック。
  • sha256もサポート
  • チェックサム計算は連続アクセスか複製時。はじめて計算したときにMDSに登録。
• gfpcopy高速化
  • BULKWRITE/BULKREADプロトコル新設。ftpのように連続転送。RTTが大きくても性能がでるように。
  • Q: 京大fwは遅いはずだが？
  • A: 実測値なので出ているはず。
• 2.6は去年だす予定だったものをend-to-endを入れて遅れた。
• 2.5.8系はバグフィックス中心にサポート

[2014-12-16 14:03]

• Q: チェックサムによる性能低下は?
• A: 測ってないけど、ユーザから文句はでてない、数%も遅くなってないはず。

[2014-12-16 14:05]

WebGfarm: 分散ファイルシステムGfarmのHTTPインターフェース / 筑波大学 鷹津冬将

• 建部さんのところで研究
• gfarmのインターフェース
  • libgfarm (低レベル)
  • gfarm2fs (FUSEベース)
  • mpiio_gfarm (MPI I/O)
  • gfarm_hadoop (ふつうはHDFSをつかうけど)
  • gfarm_samba
  • NEW: WebGfarm (REST API)
• Apache HTTP serverモジュールとして実装
  • Apacheのシェアは37.05%。
  • mod_webgfarm: Cで700行ほど。
  • Rangeヘッダの処理がめんどくさい。
  • RESTゲートウェイとして動作。
• https://github.com/fuyumacha/mod_webgarm
• つかいかた
  • httpd.confに書くだけ。
    • WebGfarm on ← 有効
    • WebGfarmBase /v1/ ←URLのパスを指定 mod_rewriteのrewritebaseとおなじかんじ
• GET → read, readdir
  • メタデータはヘッダにはいってくる。
• PUT(idempotent) → create,mkdir,write(truncateしてからwrite)
• POST(追記) → write
• DELETE → unlink,rmdir
• ステータス
  • 200 OK, 201 Created: 成功
  • 404 NotFound: ENOENT
  • 403 Forbidden: EPERM
  • 307 TEMPORARY_REDIRECT: 複数ノードのとき
  • 500 Internal Server Error: 実装できてないものとか
• apacheとgfsdが異なるノードの場合は性能劣化→HTTPリダイレクトさせることで誘導。(ファイルサイズが小さいと無駄が大きいので注意)
  • WebGfarmRedirectSSL on
  • WebGfarmReadRedirect on
  • ...

[2014-12-16 14:34]

• Q: httpユーザとgfarmユーザのマッピングは？
• A: 認証でやろうとおもったが、現在はApache専用ユーザを用意してアクセスする。

[2014-12-16 14:35]

ZabbixによるGfarm障害監視 / SRA 笠原基之

• 止まらなくても高負荷で使いものにならなくなることともある。
• zabbix
  • 監視対象はUNIX
  • デザインを意識したUI、多国語対応している。gfarm-zabbixは英語のみorz
• テンプレート: 監視項目のセット (linux OS用のテンプレートとか)
• ホスト: zabbixはホスト単位でしか監視できない。ホスト上でzabbixエージェントを動かす。
• gfmdフェイルオーバ対応で、障害検出して自動フェイルオーバできる。
• CentOS6対応。7は近日対応。
• Gfarm： クライアントにパッチあててるので特定のバージョンじゃないと動かない。
• Zabbix: 1.8と2.2 LTS。
• テンプレート
  • gfsdが動いているか
  • 認証がとおるか
  • syslogになにか出てないか
  • スプールの空き
• gfarm代表クライアント
  • このクライアントをとおしてGfarmの全ノードの監視をおこなう。zabbixの監視アプローチとはちょっとちがう。
• gfarm一般クライアント
  • 認証がとおるかどうかチェック
• gfarm-zabbix 1.x
  • 2012年4月に1.0をリリース
  • gfsdが20台以上の環境に投入された → アラート多発・master gfmdに負荷
  • master gfmdに障害があるとアラートメールの洪水になって問題が把握できなくなる。
  • 多数のエージェントがgfarmに問い合わせするのでgfmdの負荷上昇
• gfarm-zabix 2.0
  • 2014年10月リリース
  • 代表クライアントをもうけることでgfrmdの負荷軽減
  • gfmd 4台、gfsd 28台の環境で運用中。スプール 5PB。ユーザ数100。

[2014-12-16 15:10]

• Q: 代表クライアントの障害時は?
• A: フェイルオーバはないが、zabbixサーバ上に置いておけばよい。

[2014-12-16 15:11]

休憩

自販機でココア購入100円。廊下は寒いのですぐに部屋に戻る。

[2014-12-16 15:34]

HPCI共用ストレージの歩み / 理研 原田浩

• http://www.mext.go.jp/a_menu/kaihatu/jouhou/hpci/1307375.htm
• 各大学でアカウントをとって利用していたのを、HPCI事務局で一括管理。シングルサインオン。
• レプリカ数2で運用。1PBくれといったユーザは2PBの割り当てになる。
• 2年運用して1度データ消失があった。
• ストレージ容量は21.5PB。
• 利用は活発。そろそろ枯渇しそう。資源割り当ての見直しを実施。
• 2011/5に東大に納入。Lustre/IBで納入されたのを2012/4にGfarmに改修。
• テープストレージも入れている。
• 2012/5にHPCI共用ストレージのリハーサル。HPCI構成機関からのgfarmマウント。
• IPoverIBで外に見えてる。
• 最初はあまり利用されなかった(1PB)が、初年度後半では研究成果を残す目的で利用されるようになった。
• 京コンピュータからは直接書けない。ログインノードからのみ読み書き。IPリーチャブルじゃないとだめなので。
• 2.7PBくらいつかってる課題が3課題もあって60%くらい占めてる。
• HPCIのヘルプデスクがある。そこでトラブルは一元管理。
• FUSEマウントを推奨。予想以上に使ってくれている。GSI認証にたどりつくところの敷居が高いようだ。
  • マニュアルにはgfコマンドも書いてある。
  • マウントすることが難しいのではないか？ マウントポイントに(マウントする前に)ファイルを書いてしまって(マウントが)EBUSYなってしまうとかあった。京のように複数ログインノードがあると、毎回マウント・アンマウントしなくてはいけなかった。(今はautomounterがあるけど)
  • 複数ノード使わないユーザはsshをつかってしまう。GSI認証の普及が課題。
• 2013/11ごろから2014/1にかけて4ユーザ135ユーザでデータ消失。レプリカをつくるまえにデータが消えた。
• xfsをふくむパッチをあてまくって今は安定。
• SATAの信頼性はおもったよりも高い。4800台のうち故障は月1桁台。
• サーバの一斉起動でUPSの容量越えたり障害はヒューマンエラーが多い。ハードやソフトは少ない。
• mdsは冗長化しているがファイルデータはランダム配置なので片側運転ができない状況。
• 国プロでオープンソースはどうなの？
  • うまくいっている。
  • ベンダー単独ではむつかしいシステム規模。
• HCPI共用ストレージはHPC向けとしては世界最大級(参加組織・容量・実績)。

[2014-12-16 16:27]

• Q: xfsの問題でgfarmデータ消失なら、もっとxfsの事故を調査しては？
• A: 事故のあと、毎週データ整合性のレポートを取るようにしている。

[2014-12-16 16:30]

NICTサイエンスクラウドでのGfarm利活用及び開発事例紹介 / NICT 村田健史

• JGN
• データ消失を経験してからは、ユーザはフロントエンドのNASをさわる。バックエンドにGfarm。スパコンからは直接Gfarm。
• 観測系がファイル数が多い、シミュレーション系がファイルサイズが大きい。
• サーバは随時追加している(google方式)。
• (水増しできる)ユーザ数で比較するのではなく(ごまかせない)論文数で利用規模を比較しよう。
• ファイルの操作履歴とっている(トレーサビリティ)。
• タイムスタンプサーバをつかって、インテグリティチェックを実装中。コピーが改竄されているかどうかチェックできる。インターネットからの問い合わせも可能。
• ひまわり8号のデータをサイエンスクラウドで受けることになっている。
• 3次元レーダの可視化はMPIだと遊びができちゃうのでpwrakeをつかって計算をつめこむ方が効率がよい。
• HPCスパコン的 ⇔ Many-Task-Computing (MTC)クラウド的
• 4K 900fps:FT-ONE 自動車の衝突解析など 2TBでも10秒しか記録できない。90Gbps。
  • 10Gbpsを5本たばねて50Gbpsくらいは出るようになった。
  • カメラからのRAWデータを保存しながら計算できるメリット
• GPFS/Lustreのシステムが圧倒的におおい。

[2014-12-16 17:07]

総括 / ベストシステムズ 西克也

• ベンチャーでお金をほしかったら国からもらう→しかしまきとられてしまう問題。大企業はうまいことやるけど。
• そのなかでGfarmは奇跡的に生きのこった。
• NICTのGfarmはちょこちょこ増築していった。データ消失のときにはネガティブキャンペーンがひどかった。大きなお金はつかわないようにしている。
• オープンハウスのときにはタイムスタンプとトレーサビリティが人気だった。
• REST API: HEADでメタデータをとれる。今後S3互換のものもつくっていきたい。

[2014-12-16 17:24]

懇親会

• くいもの屋 わん 九州自慢 茗荷谷店 にて 18:00〜20:00

二次会

• 白木屋 茗荷谷駅前店 20:00〜22:00

• http://datafarm.apgrid.org/event/gfarm10/
• http://datafarm.apgrid.org/event/gfarm10/program.html (当日の資料もここに)
• 東京工業大学 東工大蔵前会館 蔵前ホール http://www.somuka.titech.ac.jp/ttf/

TSUBAME2.0のスカラー・ベクター混合型アーキテクチャによるマルチ・ペタフロップス計算の可能性とバイオインフォマティックスへのインパクト / 松岡聡(東工大)

• GPUをメインにしたい知見が話の中心。
• 1.0 Top5004期連続日本一7期連続性能向上世界初
• アップグレード(GPU追加)をしたので寿命が伸びた。
• CELLとかmulti-coreでない理由
• strong scaling(強スケーリング)が重要
• GPU=multithreaded vector
• 地球シミュレータはvector型だがスケールしない。
• GPU: killer vector micro
• vector型の復権か
• vector型はピーク性能に対して実性能がいい→超まぬけ議論
• latency bound vs. bandwidth bound?
• もちろんアプリケーションによるが、だいたい95%はlatency bound。(メッセージバッファの埋まり具合から)
• BGのように問題をどんどん大きくする方法はweak scalingだが、latencyは改善できない。
• weak scalingでいいじゃん→でもO(n^2)の問題だと規模を大きくすると実行時間が問題になる。
• latencyを短かく
  • Fat nodeをつかう
  • 近接通信をつかう
  • RDMA
• latency隠す
  • dynamic multithreading OLD:dataflow NEW:GPUs (レイテンシの問題をバンド幅の問題にすりかえる)
• アルゴリズムをlatency tolerantにする
  • implicit解放をやめるとか
  • 統計的手法にするとか
  • global bandwidthを用意してあげる
• 計算密度とメモリアクセス密度
• 計算寄りn-body メモリアクセス密度寄りCFD/FFT
• 昔のスパコンはpower gatingをしてなかったのでピーク性能が低くなってた。
• IOの90%はcheckpointかtemp(ジャガーのデータ)。ステージングにつかっているのは10%ということに。
• なのでノードにflash mem 200GBをつけた。
• とにかくネットワークバンド幅をリッチに。ふつうのPCだと弱い。あっても4Uの電力ばかぐい。
• レイテンシをへらすには小さくまとめる必要がある→水冷ラック(部屋は人間用の空調のみ) マシン自体は空冷。PUEを上げる原因に加湿がる。冬場は冷却効率がいい。マシンは1Fか地下に置くのがいい。最上階に置くのはよくない。
• 計算ノードのアーキテクチャはかなり変態らしいが9月の製品発表までヒミツ。
• ストレージサーバ RENKEI-PoP(point of presence)(アプライアンス) でデータ転送 セキュティポリシの違いの吸収
• 地球シミュレータのデザインはたいへん参考にしている (vector machineの先輩として)
• BG/Qに対抗できるぜ。
• 経済的な予測はできるか？ テクノロジーがかわるとパラメータがかわったり、アーキテクチャがかわるとパラメータがかわったり、まだだれもできてない。

• PUEが低いのは水冷ラックで加湿が必要ないのもある。加湿器が電気をくうらしい。

NVIDIA(R) Tesla(TM) BioWorkbenchのご紹介 / 平野幸彦(NVIDIA)

• 「ンビディア」とか「エヌビデオ」とか、なかなかちゃんと読んでもらえなかった。
• GeForce ゲーム向け ボードメーカーが1年間保証
• Quadro OpenGL最適化 nvidia3年保証
• Tesla nvidia3年保証
• G80→GT200→Fermi パフォーマンスはだいたい2倍ずつふえている。
• M2050 巨大ヒートシンク(ヒートパイプつき) 筐体のファンで冷す Data Center product
• C2050 強制空冷 workstation
• GTX480はC2050と比較してdouble precisionが半分程度の性能 (おなじfermi世代だが)
• 最近はC/Fortrunで普通に書くとGPUを使うようにしてくれる製品もあるが、普通はCUDAをつかって書く。

Gfarmファイルシステム最新機能概要 / 建部修見(筑波大)

• 広域でもスケールアウトする。NFSとしてつかえる。
• サーバもクライアントも追加すればスケールアウトする。
• ローカルアクセス優先。ファイル複製。
• gfarm 10年目!
• グローバルユーザ名がある(組織間の違いを吸収)
• 運用中にノード追加可能
• 自動ファイル複製
• XML拡張属性 XPath検索
• メタデータサーバは1台(active-standby可)。ただopen/closeのときだけ。
• InTrigger(情報爆発)で大規模プラットフォーム 146TB 1年以上安定稼動。RTT ～50ms。
• メタデータ操作性能 ひたすらディレクトリをつくる max3500ops/sec(だいたい3000くらい平均)。100ノードくらいでサチってるか。
• read性能 25000MB/s write性能4500MB/s メタデータサーバはだいじょうぶ。
• 1GBのフファイルを同時読み込み 複製をもつことでスケールする 4GB/sくらい。
• close時に自動コピーする。mount時に複製の数を指定する。
• 書き換えがないことがわかっているならより高速化できる。
• quotaがはいった。複製も含めた物理制限もある。open時にチェックするので、append writeすると越えられる!
• MDS障害: 書き込みopen中以外は復旧をまって続行可能。書き込みopen中のはclose時にエラーになる。
• NOSPC対策: 残り少ないと書き込み対象にならない。readonlyにして書き込み不能にしてしまう。
• Samba VFS for Gfarm
• debian packaging
• make + GXP並列シェル
• Pwrakeワークフローエンジン。Rakeの拡張。
• HDFSよりもgfarmがちょっとはやい。HDFSをつかわなくてすむとなるとgfarmだけで済むのでfile copyが不要に。

GXPとオーバーレイ分散ファイルシステムによる，データ集約的計算環境の実現 / 田浦健次朗，鴨志田良和，横山大作，柴田剛志，頓南，崔升準(東京大)

• データ集約的計算: 第4のパラダイムとも (第3はシミュレーション)
• プログラムは部品のあつまり(ブラックボックス)からなるので性能予想がむつかしい。
• black-boxを簡単にくみあわせられる
• エラー箇所の特定が容易
• 失敗したところから再開できるような耐故障性
• 環境(ノード数、ファイルシステムが共有かどうか)にあわせてワークフローを書き換えたくはない。
• 複数のファイルシステムをユーザレベルでつなぐアプローチ。
• ssh/torque/sge/conder/sh → GXP → GXP make
• make -jを分散環境に拡張したもの。

• ゴール: いつでもどこでもファイルシステム
• fuse sshfs
• gmount: sshfsベースのオーバーレイ分散ファイルシステム
• ユーザの要求:自分の所とスパコンを簡単につなぐソリューションが欲しい。
  • うちのスパコンですべて済まそうというのはまちがい。
• プライバシーデータのことをかんがえると、こっから出してはいけない、とか制限はかけたい。
• make以外のGXPフロントエンドもかんたんに書けるようになっている。
• セキュリティー的にどうなのか: おれおれプロトコルはうけいれにくい。

GEO Gridにおける衛星データアーカイブの構築と運用 / 山本直孝(産総研)

• どんな木をどれだけ植えればCO2がどれだけ吸収できるのかは、じつはよくわかっていない。
• MODIS まいにち全球観測
• ASTER より高解像度
• gfarm ※write once/read many環境

• これはだいたいメーカーどおり。
• ストレージと計算を分ける方向で検討中。
• ASTER(200TB)→PALSAR(2PB)大地にのっているやつ

Gfarmを用いた分散ログ解析環境とその利用 / 村上直(KEK)

• 狭域・中規模データ、better NFSの話
• 2TB、同一ハブを共有する規模
• 2TBは小さいけど工夫は必要なレベル
• 当初はデスクトップPCにためこんでいたが、データコピーの時間がかかるとか、解析をもっとちがうとこでやりたいとか。
• NAS遅い、SAN高い、B社からの提案でgfarmに。
• 2ヶ月に1度ほどフリーズする。syslog-ngをgfarmに書く。log rotateは1日ごと。syslogをローカルに書いて圧縮してgfarmにコピーすることに。(1GB/day)これでA安定稼動している。
• DBPowder
• MDSのバックアップはとってないけど、データのレプリカはあるので復旧できるとおもっている。
• ログ解析は一旦RDBMSに入れてやっている。直接hadoopとかつかってという研究もあるが、自分のところの研究がRDBなので。

ペタバイトスケール大規模データ処理にむけた東京工業大学の取り組み / 佐藤仁，滝澤真一朗(東工大)，松岡聡(東工大・NII)

• tsubame: 0.02%が1TB以上をつかっている

NICT(情報通信研究機構)のサイエンスクラウド / 村田健史(NICT)

• 縦割りプロジェクトのよるメガサイエンスの孤立
• 異なるメガサイエンスの融合は衝突のみを生み出してきた。
• クロスメガサイエンスデータハウス
• オーロラは人工衛星で観測できるけど磁気圏はみえないからシミュレーション。これを合成する。
• 地球環境のセンシングは人間のいないところ→ネットワークは貧弱 (街中での観測は都市環境の観測) センサーネットワークの研究は理想的すぎ。
• gfarmは大規模ストレージの面と並列処理の面とがある。
• gfarm1で構築していたが24時間連続で計算しているが規模がおおきくなってきてだんだんおいつかなくなってv2にしたい。
• NICTは大きな組織なので他のグループのことはよくわからない。

JGN2plusとGfarmによるNICTサイエンスクラウド広域分散ストレージ / 森川靖大(NICT)，山本和憲(愛媛大)，佐藤建，井上諭，坪内健(NICT)，建部修見(筑波大)，崔超遠，加藤久雄，亘慎一(NICT)，木村映善(愛媛大)，村田健史(NICT)

• 容量単価を最適化したデータ保管用FSN dell server + eSATA RAID5箱 を RAID0で組む
• データ処理用CN/FSN スピード優先
• データ参照用CN gfarm2fs,samba,http,ftp
• gfarmを東京ー沖縄(L2)だと9MB/sくらいしかでない。NASとしては使えない。
• ユーザによってつかうディスクを制限したい。(たとえば大規模データ保存と計算用とでディスクセットを変えたい)
• スパコンだと10GB/sくらいのデータをさばけるようにならないとだめ(貯められるだめではダメ) by 松岡
• ステージングする時間も考えよう by 松岡

サービス共通基盤としてのGfarmの利用と課題 / 大岸智彦，西谷明彦，寺下雅人(KDDI研究所)

• 顧客は直接gfarm clientにはならず、アプリケーションサーバ経由で利用。
• 運用コストがさがればいいかなぁと。運用スキルを含めて。

初めてのGfarm --- 初心者のためのGfarm / 江波均(ベストシステムズ)

• v1はfindかければMDSが死んでも復旧できるけど
• v2はパスが戻せないのでlost+foundに回収できるくらいのコマンドはある。

パネル「皆が欲しいストレージクラウドとは」

• モデレータ
  • 小西史一(東工大)
• パネリスト(left to right)
  • 高杉英利(NTTコミュニケーションズ)
  • 建部修見(筑波大)
  • 西谷明彦(KDDI研)
  • 松岡聡(東工大)
  • 村田健史(NICT)
  • 山本直孝(産総研)

1. クラウドストレージのユーザ像について
2. ストレージクラウドが持つべき機能について
3. あなたにとって、理想のクラウドスレージとは

= 1.クラウドストレージのユーザ像について

• 高杉
  • 金融関係は1ビットもちがってはいけない。
  • 大容量はスパコンがひっぱっていたが、いまは商用の方がひっぱっている。いまは300PBくらい。はやくEBがほしい。
• 建部
  • e-scienceの研究者、mapreduceつかい、facebook/gmail/dropbox/picasa...
• 西谷
  • 機密情報をクラウドに移すのは不安。クラウドに暗号化するよりも自社設備で平文。(自前主義) クリティカルじゃない方面でつかわれていくのか。
• 松岡
  • ストレージってなに？
  • 計算能力(flopos) vs データ処理能力(io,space)
  • HPC in the Cloud.
  • データセンターとスパコンとの違いはあるのか? 規模の違いはちがわない。
  • Top500にクラウドがはいったことはない。
  • why?
    • Macho factor
    • Technical
    • Financial
    • Operational
  • 現状はHPCではクラウドはつかいものにならない。
• 村田
  • センサーネットワークの研究
  • センシングの研究
  • 数100の画像をみてなにがたのしいのか!
  • まずはネズミがかじらないケーブルがほしいとか、1Gbpsのネットワークとか、現場の観測している人はそういうレベル。
  • 個別対応できるストレージがないとだめだ。現場の要求は多様。
• 山本
  • ユーザがふつうにつかえることが重要。とりあえずposix API。

• 高杉
  • ネットワークのQoSはおとせばいいけど、ストレージは時間軸がある。どのくらい保存しなければいけないとか。
• 松岡
  • インターネットはたくさんのユーザの同時利用でスループットはでるようにアーキテクチャができている。
  • パラメータサーベイでもBWはいる。gaussianはtmpファイルをどんどんつくるのでたくさんのユーザが動くとたいへん。
  • クラウドはスモールビジネス+B2Cに特化している。CPUの割り当てもばらばら。これは耐故障性もある。でもBWがでなくなる。
  • クラウドでハイエンドアプリケーションをどうやったら動かせるようになるか研究がベンダーは始めている。

= 2.ストレージクラウドが持つべき機能について

• 高杉
  • クラウドはサービス。うれてるものがいいもの。だからdebianに登録した!
  • 30件くらいまずそうな特許がある。10件くらいは継続監視中。
  • 品質とか保守とか重要
• 建部
  • 高速、高可用性、高信頼、安全性、green,,,
• 西谷
  • 物理的な分散。移動体のときでも最適なとこから。
• 松岡
  • 技術で安くするか、高付加価値か。でないと中国アメリカにのみこまれてしまう。
  • じつはクラウドストレージはとてもボッタクリ。
• 村田
  • 地球観測はデータは絶対失いたくない。
  • シミュレーション屋はそこまでは。再計算すればいいから。
  • 個人がデータをかかえこんでしまって、その人が死んだらデータも死んでしまうこともよくある。
  • クラウドとかアクセス方法が標準化されたらありがたい。
• 山本
  • 重要だけどあまりつかわれないものアーカイブして電気をくわないようにしたい。

• 高杉
  • 社内ではgframの地位があがってきている。
  • スパコンはファイナンスの問題。
  • gfarmがうれたら保守にまわして。。。
• 松岡
  • まったくちがう要求をまとめられる抽象化が要求されている...

や○な○さん情報

• チラーとは外で水を冷す装置のことで、水冷ラックは外気温以下には下らない。
• サーバルームの加湿は乾燥しすぎると静電気が発生するのでそれを防ぐため。
• テープデバイス: HDDバックアップだとどうしても普通のストレージとしてつかいたくなってしまうが、テープならあきらめがつく。
• テープを交換するだけでヘッドはそのままで容量アップできる。
• tsubame1はリースなのでリース会社にひきとられ、再利用の予定はない。
• http://www.tsubame2.org 自腹でドメインとった。
• 青いネットは、落下事故があったのでその対策。設計したのは...