大規模ストレージ WG 成果報告書「大規模ストレージの課題と今後の展望」(WG 活動期間:2009 年 1 月-2011 年 3 月)

2011 年 5 月 13 日
サイエンティフィック・システム研究会
大規模ストレージＷＧ

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

目 次
1 はじめに(WG 活動概要) ··································································· 1(1)WG 発足の背景 ··········································································· 1(2)活動方針 ··············································································· 1(3)活動内容 ··············································································· 1(4)活動期間 ··············································································· 1(5)WG メンバー············································································· 2(6)活動実績 ··············································································· 22 大規模ストレージシステムの動向 ·························································· 4
2.1 ストレージ技術 ············································································ 4(1)ホストインターフェース技術動向·························································· 4(2)ディスクドライブ動向···································································· 4(3)ストレージシステムとファイルシステムの融合(将来技術) ···································· 5
2.2 高性能ファイルシステム····································································· 6
2.3 HSM システム··············································································· 8(1)現状 ··················································································· 8(2)現状分析 ··············································································· 9(3)製品動向 ··············································································· 9(4)今後 ··················································································· 9
2.4 海外スーパーコンピュータシステムにおけるストレージシステム ································ 11(1)米国のスーパーコンピュータストレージの変遷と概況 ······································· 11(2)米国における巨大ストレージシステムの例:ORNL、LLNL システム······························ 12(3)欧州におけるスーパーコンピュータストレージ事例:CERN と CEA ······························ 13(4)演算性能あたりのストレージ性能························································· 13(5)まとめ ················································································ 14
3 各会員システムの概要··································································· 15
3.1 システムの概要 ··········································································· 15
3.1.1 宇宙航空研究開発機構(調布)···························································· 16(1)JSS のシステム概要と特徴 ······························································· 16(2)ストレージの利用状況··································································· 18(3)認識している課題と将来構想····························································· 19
3.1.2 理化学研究所 ········································································· 21(1)RICC の概要および特徴 ·································································· 21(2)ストレージの利用状況··································································· 23(3)問題点と今後の課題····································································· 24
3.1.3 東京大学宇宙線研究所·································································· 25(1)研究の概要 ············································································ 25(2)計算機システムの概要··································································· 25(3)ストレージの使われ方··································································· 26(4)課題 ·················································································· 27
3.1.4 国立天文台 ··········································································· 28(1)はじめに ·············································································· 28(2)大規模ストレージの利用方法····························································· 28(3)ハードウェア構成······································································· 29(4)現在の課題 ············································································ 30
3.1.5 高エネルギー加速器研究機構···························································· 32(1)KEKCC の概要 ··········································································· 32(2)ストレージシステム····································································· 33(3)階層型ストレージシステム······························································· 33(4)ストレージシステムの利用状況··························································· 34(5)ストレージシステムに関する課題························································· 34
3.2 今後のシステムの強化ポイント······························································ 35iサイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4 大規模ストレージにおける課題とその対策 ················································· 38
4.1 大容量化 ················································································· 38
4.1.1 ハードウェア ········································································· 38
4.1.2 ソフトウェア ········································································· 40(1)大規模化 ·············································································· 40(2)スケーラビリティ······································································· 40(3)使い易さ ·············································································· 41
4.2 高速化 ··················································································· 42
4.2.1 ハードウェア ········································································· 42
4.2.2 ソフトウェア ········································································· 43(1)性能向上 ·············································································· 43(2)運用ポリシー選択······································································· 47(3)輻輳防止(動的フロー制御)······························································· 48
4.3 運用 ····················································································· 49
4.3.1 バックアップ ········································································· 49(1)課題 ·················································································· 49(2)今後の対策 ············································································ 49
4.3.2 リビルド ············································································· 50(1)課題 ·················································································· 50(2)今後の対策 ············································································ 50
4.3.3 データ移行 ··········································································· 51(1)背景 ·················································································· 51(2)研究機関ごとのデータ移行状況··························································· 51(3)各研究機関ごとのストレージ容量と次期システムへの最低データ移行期間······················ 52(4)最低データ移行期間の長期化に対する対策 ················································· 52
4.3.4 高可用性 ············································································· 55(1)ハードウェアの二重化··································································· 55(2)ソフトウェアによる交替・リカバリ制御 ··················································· 55
5 ファイルシステム健康診断······························································· 57
5.1 背景 ····················································································· 57
5.2 目的 ····················································································· 57
5.3 診断モデル ··············································································· 57(1)導入システムの健康診断································································· 57(2)運用中の定期健康診断··································································· 58(3)精密検査 ·············································································· 58
5.4 診断項目 ················································································· 59(1)大規模データ転送(スループット性能:プロセス当たりのファイル量一定、大 IO 長)·············· 59(2)データ量一定(スループット性能:小ファイルサイズ、小 IO 長) ······························· 59(3)メタデータアクセス(レスポンス性能) ····················································· 60
5.5 診断クラス ··············································································· 61
5.6 診断ツール ··············································································· 62
5.7 診断例 ··················································································· 64(1)宇宙航空研究開発機構(調布)····························································· 64(2)理化学研究所 ·········································································· 66(3)国立天文台 ············································································ 68(4)某研究所 ·············································································· 69
5.8 最後に ··················································································· 70
6 今後に向けての提言 ···································································· 71
付録 ···················································································· 72
資料(1)海外スパコンシステムにおけるストレージシステムの動向 ······························· 73
資料(2)高性能ファイルシステムの紹介······················································· 86
資料(3)高速化・大容量化に向けた課題と対応について(ストレージ機器編) ······················· 90

iiサイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書■登録商標について
・AIX は、インターナショナル・ビジネス・マシーンズ・コーポレーションの登録商標です。
・CXFS は、日本 SGI 株式会社の登録商標です。
・ETERNUS、PRIMEPOWER、PRIMEQUEST、PRIMERGY は、富士通株式会社の登録商標です。
・FLASH は、アドビ システムズ，インコーポレイテッドの登録商標です。
・ITANIUM、XEON は、インテル コーポレーションの登録商標です。
・NetVault は、バックボーン・ソフトウエア株式会社の登録商標です。
・ORACLE、SOLARIS、SUN、SUNRAY、ZFS は、オラクル・アメリカ・インコーポレーテッドの登録商標です。
・SINET は、大学共同利用機関法人情報・システム研究機構の登録商標です。
・SPARC、SPARC64、ULTRASPARC は、スパーク・インターナショナル・インコーポレーテッドの登録商標です。
・ULTRIUM は、ヒユーレツト・パツカード リミテツド、インターナシヨナル ビジネス マシンズ コーポレ
ーシヨン、シーゲート リムーバブル ストレージ ソリューションズ エルエルシーの登録商標です。
・WINDOWS は、マイクロソフト コーポレーションの登録商標です。
・その他一般に、会社名、機関名、製品名は各社、各機関の商標または登録商標です。

iii

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

1 はじめに(WG 活動概要)(1)WG 発足の背景
これまで SS 研では、
「ネットワーク時代の統合ストレージマネージメント WG」(活動期間:2001 年 5 月～2003
年 4 月)、「ストレージを中心としたシステムマネージメント WG」(活動期間:2003 年 5 月～2005 年 4 月)、「データマネジメントを意識したストレージソリューション WG」(活動期間:2006 年 2 月～2008 年 4 月)を発足させ、その時点でのストレージに関する広範な技術動向と課題を様々な側面から検討してきた。
現在 HPC の世界では、データの大規模化や計算機の高性能化が一層促進されてきており、今後のシステム検討において、大規模ストレージがますます重要な構成要素となってきている。
こういった状況を踏まえ、大規模ストレージに特化し、大規模ストレージを有する各サイト関係者の参加のもと、大規模ストレージが抱える技術課題と解決策について検討する WG を発足することとなった。
(2)活動方針
情報処理性能の飛躍的な向上による科学技術計算の大規模化や、情報処理システムの入力元となる観測機器
および測定機器の高精度化により、入出力データの大規模化は加速度的に進んでいる。今後もデータの大規模化は一層促進されていくと考えられる。
CPUの種類や構成が多様化する中で、特に大規模データを扱う計算機システムを効率的かつ有効に利用する
ためには、ストレージの性能・構成・運用方法などを最適にすることが大きな要素のひとつとなっており、明確な設計指針が求められている。
更に、ストレージの性能評価方法や測定ツールについては、現状、一般化されておらず、様々なストレージシステムを包含した性能評価指針も求められている。
このような状況を踏まえ、大規模データを扱うシステムにおいて、限られた予算でより効果的なストレージ/IOシステムを選択するための検討および効率的な運用を行うために必要な管理機能の検討を行う。
(3)活動内容
下記の調査・検討を行う。ここで、WGとしてひとつの共通解を出すことには拘らず、ケースごとの要件の優先度の整理を主眼とする。また、大規模ストレージの利用者のみならず、システム管理者やシステム設計者の視点を加えた整理を行い、それぞれの立場の違いによる要件や大規模ストレージへの期待の差異を明確にする。
更に、ストレージ性能測定ツールをモデル化し、いくつかのSS 研会員システムでの性能測定および結果の評価を行い、ストレージシステムの性能評価指針案策定のための準備を行う。
①ストレージ製品の現状と動向の調査【メーカの視点】②参加機関毎の特徴的なストレージ/IO例の整理【ユーザの視点】③ストレージ/IOに対するニーズの明確化【ユーザの視点】④ストレージ/IOの使われ方や考え方の現状把握【ユーザ・システム管理者双方の視点(システム設計者の視点も入れる)】⑤効果的なストレージ/IOシステムの検討【システム管理者の視点】⑥ストレージ運用管理機能の検討と製品への反映検討【製品開発の視点】⑦ストレージ性能測定ツールのモデル化、測定・結果評価および性能評価指針案の策定【システム管理者の視点】(4)活動期間2009年1月～2011年3月

1

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(5)WG メンバー
担当幹事
(まとめ役)
会員

推進委員(まとめ役)
推進委員

賛助会員 オブザーバ
(富士通)

松澤
藤田
八代
竹内
八木
早戸
黒川
栄元
荒木
長屋
住元
甲斐
酒井
阿部
飯島
川村
坂口
塚原
松井

氏名
照男
直行
茂夫
康雄
雅文
良成
原佳
雅彦
純隆
忠男
真司
俊彦
憲一郎
孝之
敏治
寛
吉生
知宏
秀司

機関/所属(2011 年 3 月 31 日現在)
北陸先端科学技術大学院大学
宇宙航空研究開発機構
高エネルギー加速器研究機構
神戸大学
国立天文台
東京大学宇宙線研究所
理化学研究所富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)(6)活動実績■第1回会合 : 2009年3月4日(水) 富士通(株)本社 出席者:会員=6名/富士通=10名
・WG発足の確認
・活動内容および進め方の検討
・成果報告書の基本方針の確認
・フリーディスカッション■第2回会合 : 2009年4月24日(金) 富士通(株)本社 出席者:会員=6名/富士通=9名
・ストレージ製品の現状と動向についての情報提供
・各委員からの事例紹介(システム概要、認識している課題、将来構想など)および議論
・キーワードによる課題抽出・検討■第3回会合 : 2009年8月7日(金) 富士通(株)本社 出席者:会員=5名/富士通=7名
・今後の議論展開の確認・ニーズと現状技術のギャップの整理と技術課題の明確化－システム概要確認シートを基にした各会員のストレージシステムの報告[藤田委員、八木委員、竹内委員、黒川委員](八代委員はシステム概要確認シートを事前提出頂き、他会員の資料と共に議論の基とした)－性能、リソースに対するアクセスコントロール、HSM 等に関する議論－WGで取り扱う技術課題の選定■第4回会合 : 2009年10月30日(金) 富士通(株)本社 出席者:会員=6名/富士通=8名
・技術課題に対する、製品情報・業界動向・今後の取り組み・運用案等の提示と討議－海外スーパーコンピュータセンターでのストレージ・システムの動向[住元委員]－ディスク容量の増大に伴う課題と対策* バックアップ・リビルド・データ移行について[栄元、荒木委員]* HSM の整理と今後について[甲斐委員]* ファイルシステムの現状と課題について[酒井(富士通)]2

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書■第5回会合 : 2010年1月29日(金) 富士通(株)北陸支社 出席者:会員=6名/富士通=10名・大規模ストレージの今後についての情報提供と討議－富士通が目指す次期ファイルシステムについて(ご紹介)[酒井(富士通)]－高速化・大容量化に向けた課題と対応について(ストレージ部分)[荒木委員]－ファイルシステム性能評価[甲斐委員]－高性能ファイルシステムの紹介[住元委員]■第6回会合 : 2010年4月27日(火) 富士通(株)本社 出席者:会員=6名/富士通=9名
・技術課題ごとの報告と討議－ファイルシステム性能評価[甲斐委員]－次世代ストレージ[荒木委員]－ファイルシステム性能測定(再報告)[酒井(富士通)]
・成果報告書作成方針、スケジュール等の検討■第7回会合 : 2010年8月31日(火) 富士通(株) 本社 出席者:会員=7名/富士通=10名
・ファイルシステム性能測定結果についての議論－各システムでの測定結果およびその評価コメントの討議－評価の仕方、レベルなどについての討議
・成果報告書作成についての意識あわせ、スケジュールの確認■第8回会合 : 2010年11月5日(金) 東京大学宇宙線研究所(神岡) 出席者:会員=6名/富士通=8名
・成果報告書暫定版レビュー－各章の記載項目の過不足・バランス確認－ファイルシステム性能評価方法についての内容説明と討議■第9回会合 : 2011年1月18日(火) 富士通(株) 本社 出席者:会員=6名/富士通=7名
・成果報告書最終レビュー1(途中まで)■第10回会合 : 2011年2月17日(木) 富士通(株) 本社 出席者:会員=6名/富士通=10名
・成果報告書最終レビュー2(続き)・成果報告会の検討

3

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

2 大規模ストレージシステムの動向
2.1 ストレージ技術
大規模ストレージシステムに関連するハードウェアの技術動向を以下に記載する。

(1)ホストインターフェース技術動向
ブロックアクセス型のストレージとして現在はファイバチャネルインターフェースが主流であるが、今後のロードマップを考えると中期的には FCoE(Fibre Channel over Ethernet)が有望なインターフェースであると考えられる。ただし、現段階では CNA(Converged Network Adapter)および対応スイッチ間での接続性などに制限が多いが、2012 年頃から第二世代のスイッチや CNA がベンダーから供給され、相互接続性の問題も解
消すると考えられている。

ホストインター
フェース種
ファイバチャネル
FCoE
iSCSI

表 2.1.1 ホストインターフェースの動向
現状
次世代
次次世代
備考
2010 年
2011～2012 年
2013 年～
8Gbit/s
16Gbit/s？
将来のロードマップが未確定－
10Gbit/s
40/100Gbit/s 将来有望
1Gbit/s
10Gbit/s
40/100Gbit/s オーバーヘッド大(2)ディスクドライブ動向
高性能を目指すオンラインディスクは現在 3.5" 15,000rpm が主流であるが将来的(2012 年末頃)には供給停止になるため、今後は 2.5" 10,000rpm のドライブが主流となる。あわせてドライブインターフェースもFC(4Gbit/s)および SATA(3Gbit/s)中心から SAS 2.0(6Gbit/s)に移行していく。さらに将来は NAND Flash を使用した SSD(Solid State Drive)が容量単価でオンラインディスクに近づくことが予想されており、オンライ
ンディスクにとってかわることも考えられる。
これに対し容量対価格重視のニアラインディスクは容量単価で優位な3.5" 7,200rpmが今後も主流となる。
表 2.1.2 ディスクドライブの動向
サイズ
インターフ
現状
次世代
回転数
ェース
2010 年
2011～2012 年
オンラインデ 3.5" 15,000rpm
FC
600GB
←
ィスク
2.5" 10,000rpm
SAS
600GB
900GB
ニアラインデ 3.5" 7,200rpm SATA/SAS
2TB
3TB
ィスク
2.5" 7,200rpm
SAS
－
1TB
SSD
SAS
200GB
400GB(SLC)/
800GB(MLC)
種別

次次世代
2013 年～
－
容量増
4TB
容量増
容量増

備考
将来供給停止容量単価で優位
性能重視の領域では将来有望*SLC:Single Level Cell,素子に 1bit のみ記録する。高速で書き込み回数上限値が多い。
*MLC:Multi Level Cell,素子に 2bit 以上を記録する。容量対コストでは優位であるが書き込み回数上限値が少ない。

ディスクドライブは 1.5～2 年で容量が 1.5～2 倍となるが、性能は 15～30%程度しか向上しない。これに対し HPC システムとして要求される容量・性能はシステム更改の度に 10～100 倍となっており、ドライブの改善
だけでは吸収できない。そのため、ディスクドライブだけでなくストレージ装置自体も増加しシステム全体としての消費電力や設置スペース、コストなど新たな問題が起きている。
性能・消費電力の観点で期待の大きい SSD は、アクセス形態による性能差が大きい特徴がある。小 IO サイズでのリード処理ではオンラインディスクに比べ 50 倍以上の性能が出るが、大きな IO サーズでの連続したライト処理を 1 多重で実効した場合はオンラインディスクとほぼ同等という性能特性を持っている。また、一般には Flash 素子への書き込み上限があり、この問題への対応も必要である。ETERNUS で採用している SSD には
ウェアレベリング技術によりFlash素子全体を平均に使うことにより特定の素子が書き込み上限に達して使えなくなることを防止している。

4サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

現在、SSD(Flash ドライブ)はストレージの内部的には、磁気ディスクドライブと同一のインターフェースとフォームファクター(3.5"や 2.5"など共通の外部形状)を採用しているが将来的には高速化のため、SAS などのディスク用インターフェースではなく、よりオーバーヘッドの少ない PCI-Express などのようなインターフ
ェースを使用した Flash ドライブによるストレージを構成することも検討されている。

(3)ストレージシステムとファイルシステムの融合(将来技術)
ストレージに関する業界団体である SNIA(Storage Networking Industry Association)では OSD(Object
Storage Device)に関する検討が行われ、標準化向けた取組が進められている。
OSD は高速・大容量の共有ファイルシステムとして研究が進められいるもので、従来のファイルシステムはサーバ側でデータが配置されているブロック情報も管理されているが、OSD ではサーバ側でのブロック管理は不要となり、ファイル名とオブジェクト ID のみを管理するようになる。一方、ストレージ側はオブジェクト
ID とデータおよびアトリビュート情報を管理・制御するようになる。
OSD には以下のような特徴がある。
・データをオブジェクトとして管理
・オブジェクト単位にセキュリティのためのアクセスキーや QoS、リテンションなどのアトリビュート情報があり、これらの制御をストレージ側が自律的に行う・アクセスノードおよびストレージノードをスケーラブルに拡張できる・アトリビュート情報の設定により、ストレージノードによる自律的なバックアップやマイグレーションが可能であり、オンラインでのストレージマイグレーションも可能
OSD の機能は Ceph として Linux のカーネルにも盛り込まれており、今後の開発と普及が期待される。

5サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

2.2 高性能ファイルシステム
表 2.2.1 に各社の提供している高性能ファイルシステムを示す。堅牢で大規模な SMP サーバを用いた高性能ファイルシステム SRFS、HFS、ストレージネットワークをベースにした GFS、クラスタファイルシステムとしては、Lustre ファイルシステムベースの LXFS、CFS のほか、GPFS、PanFS、pNFS が製品として提供されている。
表 2.2.1 各社の HPC 向けファイルシステム
ベンダー

ファイルシステム名

備考

日立

HFS：

高性能ファイルシステム： 東大T2K

NEC

GFS
LXFS: Lustreベース

SAN共有ファイルシステム
Lustre動作を保証

富士通

SRFS: NFSベース

ローカルFS＋SRFSの形態で利用
大規模SMPサーバ利用で数千ノードまでサポート

IBM

GPFS

独自クラスタファイル

HP

CFS: Lustreベース

独自に改造、サポート

SGI

CXFS

SAN共有ファイルシステム

CRAY

Lustre, Panfs,
NFS,Storenext, GPFS

主としてXT系でのサポート

Panasas

PanFS
pNFS

ブレード型ＨＷと一体となったファイルシステム＆ス
トレージ

DDN

Lustre

自社製ストレージ向けに最適化提供＆サポート

高性能 HPC システムの中でも TOP500 に代表される大規模 HPC システムでは、演算性能の増加と共にファイル
IO 性能に対する要求が高まっている。特に TOP10 クラスのシステムにおいては、単体のファイルサーバクラスでは、必要なファイル IO 性能を満たさないため、複数のファイルサーバを束ねて高いファイル IO 性能を実現する
クラスタファイルシステムの利用が通例となっている。
表 2.2.2 に 2010 年 11 月の TOP500 リストのうち、TOP10 のシステムが採用しているファイルシステムの調査結果を示す。不明の 1 システムを除き、すべてのシステムにおいてクラスタファイルシステムが採用されていることがわかる。クラスタファイルシステムの中でも Lustre を 6 システム、GPFS を 1 システム、PanFS を 2 システムが採用している。
表 2.2.2 世界 TOP10 システムが利用しているファイルシステム(2010 年 11 月)

Top
システム
500
1
NSCC
Tianhe-1A2• LustreとGPFSが多い
ORNL
Jaguar (Cray)
3
NSCS
Nebulae
4
TITECH Tsubame2(NEC/HP)
5
NERSC Hopper(Cray)
6
CEA
Tera-100(Bull)
7
LANL
Roadrunner (IBM)8
NICS
Kraken (Cray)
9
Juelich JUGENE(IBM)10 LANL
Cielo(Cray)

6

ファイルシ
ステム
LustreLustre不明
LustreLustreLustrePanFS
Lustre
GPFS
PanFS

容量
1PB
10PB
不明
7PB
2PB
20PB
2PB
2.4PB
2.3PB
10PB

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

表 2.2.3 に 2010 年 11 月の TOP500 リストのうち、TOP100 以内の日本のシステムが採用しているファイルシス
テムの調査結果を示す。国産ベンダ製のファイルシステムの利用が多いが、クラスタファイルシステム(Lustre)の利用も 8 システム中 4 システムで見られる。
表 2.2.3 TOP100 以内の日本のシステムが利用しているファイルシステム(2010 年 11 月)

ファイルシス
容量
テム
4
TITECH
Tsubame2
Lustre
7PB
JAEA
BX900
SRFS
1.2PB
•33Lustreが多いが、国産ベンダ製ファイルシス
41 ISSP
Lustre91TB
Altix ICE 400EX
テムも利用されている
54 JAMSTEC
SX-9/E
GFS
0.5+1.5PB
59 JAXA
JSS-M
SRFS
1PB
70 Tokyo Univ.
T2K-Tokyo
HFS,Lustre 1.0+0.2PB
74 RIKEN
RICC
SRFS
550TB
96 Tsukuba Univ. T2K-Tsukuba Lustre
0.8PB

Top500Rank

システム

クラスタファイルシステムは、複数のサーバを束ねて高いファイルIO性能を実現するファイルシステムである。
例えば Lustre ファイルシステムを構成するサーバはディレクトリ構造などを司るメタデータサーバ(MDS)とファイルのデータを扱うオブジェクトストレージサーバ(OSS)に分類される。論理的に MDS、OSS 共にクラスタ構成を組むことができるが、Lustre の現状のバージョン(2.0)では、MDS のクラスタ構成はサポートされていない。この
ため、Lustre ファイルシステムは大規模なデータ転送には適するが、ディレクトリアクセスや小規模ファイルの大量アクセスなど、MDS に負荷がかかる処理は得意ではない。Lustre のロードマップには MDS のクラスタ構成も提供スケジュールに入っているが、現状ではサポートされていないためファイルシステムを分割するなどの工夫が必要である。一方、GPFS は MDS のクラスタ構成もサポートしているほか、ストレージの動的削除、スナップシ
ョットなど Lustre が備えていない機能をもっている。
IETF で標準化が進んでいる並列ファイルシステムとしては pNFS がある、pNFS は NFS 4.1 の一部として仕様策定が進んでいる。Lustre と同様、メタデータを扱うメタデータサーバとデータを扱うストレージデバイスが定義されているが、ストレージデバイスとして、NFS サーバ、オブジェクトストレージデバイス(OSD)、SAN アクセス可能なブロックデバイスが定義されている。実現形態としては SAN 共有(EMC)での実現、ネットワーク上での実現(Panasas)がある。
今後の動向として、
HPC システムの巨大化と共にファイルIO 性能に対する要求はますます高まっていくため、
Lustre をはじめとするクラスタファイルシステムへの移行が進むと考えられる。しかし、ファイル IO 性能の向上への要求は、すなわち、所要ストレージデバイス(HDD)数と OSS を構成するサーバ数の増大なって現れてくる。
このため設置面積の増大、ストレージデバイスとサーバ数増加によるコストの増大とその消費電力を如何に小さくするかが課題になってくる。コストパフォーマンス、省スペース、低消費電力を実現するストレージと高性能
ファイルシステムが実現の課題となっている。

7

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

2.3 HSM システム
(1)現状
大規模ストレージシステムで使用される HSM システムについて、現在の状況と今後について考察を行う。
まず議論の明確化のために HSM(Hierarchical Storage Management)を以下のように定義する(広義)。
「ディスク、テープなど速度・容量の異なるメディア間でデータのマイグレーション・リコールを透過的に行う」
HSM の利用用途は以下のように 3 つに大別される。
①階層ストレージ
ユーザには単に巨大なファイルシステムとして見える(利用時には特別に何も意識しない)。大規模ストレージの低コスト化を目的に小容量ディスクと大容量テープを組み合わせ頻繁なステージングを行う。
②アーカイブ
データの蓄積が目的。ユーザはデータがアーカイブされている事を認識する。
アクセスはほとんどが ディスク→テープ。ディスクに戻す頻度は少ない。
③バックアップ
障害時のデータ保全が目的。一般的にはシステム管理者が意識してファイル単位、ファ
イルシステム単位でバックアップを採取する(エンドユーザが意識する事もある)。
ほとんどが ディスク→テープ のみ。ディスクに戻すのは緊急時(高速性が必要)。

テープへのアクセス頻度高低

現在は昨今のディスク高性能化・大容量化・低価格化により元来の HSM 使用方法である①よりも②、③の用途が多くなっている。WG 参加機関のセンターの状況を表 2.3.1 に示す。

図 2.3.1 HSM の利用用途

8サイエンティフィック・システム研究会

センタ名
JAXA 調布
理化学研究所東京大学宇宙線研
国立天文台

高エネルギー加速器研究機構

大規模ストレージ WG 成果報告書

表 2.3.1 WG 参加機関のセンターの HSM の現状
現システムのシステム
主な用途
ストレージ容量
SAM-QFS・ディスク: 1PB 階層ストレージ
事業所間分散ファイルシス ・テープ : 10PBテムとして HPSS も利用
HPSS
・ディスク: 1PB アーカイブ
・テープ : 4PB バックアップ(8PB に拡張予定)
VD-800・ディスク:709TB バックアップ
・テープ :547TB アーカイブ－①ディスク: 80TB アーカイブ
テープ : 40TB バックアップ②ディスク:200TB
テープ :100TB③ディスク: 80TB
HPSS
・ディスク:205TB 階層ストレージ・テープ : 3PB

今後
現状と同等
未評価
現状と同等
①不要(忌避)
②強化要
③要
強化要

(2)現状分析
ディスク大容量化に伴い階層ストレージからバックアップ・アーカイブ用途がメインへ。
[アーカイブの方法例]
・HSM ソフトウェア(HPSS など)を利用し テープ←→ディスク でデータ格納・取り出し[バックアップの方法例]
・バックアップ専用ソフトウェア利用(netvault、netbackup など)
・ディスク to ディスク (SAS→SATA rsync、ハードウェアコピー機能)
・ディスク to NAS (rsync、バックアップ専用ソフトウェア)
・各ユーザ毎にバックアップ(センタは関知しない)(要因:ネットワーク高速化、個人で TB 級ストレージ所有)
従来の HSM ユーザは単純バックアップ・アーカイブとハイエンド HSM へ二極化して行き、HSM ユーザ数は減少方向へ向かうと考えられる。

(3)製品動向
HSM ソフトウェアは大規模 HPC ユーザでは SAM-FS、HPSS、PetaServe が殆どであるが、ここ数年は HSM 機能
としては画期的な進歩は無い。
一方ストレージ(NAS、DAS)はインテリジェント化が進み、容量仮想化、ストレージによる自律 snapshot や
自動マイグレーションを実現する方向であり、HSM ソフトウェアとストレージの進化は独立して進んでいる。
・著名 HSM ソフトウェアは特定ハードウェアに依存しない・ストレージのインテリジェント化は特定アプリケーションや特定の運用方法でのみサポート(4)今後
上記の現状から HSM の今後を予測する。以下の 3 ケースが考えれるが、当面は CASE1、2 の傾向が強まると考えられ、次なる展開の CASE3 はベンダ間の協調対応がどこまで可能かに掛かる。
CASE1:ユーザ数が絞られ、HSM ソフトウェアは数種のみ生き残る 現状の延長(先細り)
ユーザ自体も HSM ソフトウェア(ベンダ)に縛られる傾向が強くなる9サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

CASE2:HSM 自体が衰退 ILM(Infomation Lifecycle Management)に吸収
特定バックアップソフトウェアや特定アプリケーションによる囲い込みor
単純バックアップ(rsync、バックアップソフトウェア)
CASE3:ストレージインテリジェント化と HSM が融合
ストレージのインテリジェント化を規格化(OSD)し、オープン性を実現
・メリット:ハードウェアアシストによる高速性、規格化によるデータの可搬性向上、コストダウン・課
題:各ストレージ、HSM ベンダの足並みが揃うか？
動向を見極めるには 2～3 年掛かる？

10サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

2.4 海外スーパーコンピュータシステムにおけるストレージシステム(1)米国のスーパーコンピュータストレージの変遷と概況
米国でのスーパーコンピュータストレージは 1970 年代より利用されてきた。ストレージシステムのアーキ
テクチャは次に述べるように変遷してきている。長年にわたりデータを蓄積し、シミュレーションデータの比較をするといった利用をするため、磁気テープを用いたアーカイブシステムと計算結果の記憶、データ処理を行うための磁気ディスクベースの記憶システムの階層的なストレージシステムとなっている。
1970-1990 年代前半:大型汎用機付帯のストレージを利用(磁気ディスク＋テープ装置)
ストレージの価格が高価であったため、スーパーコンピュータ自体に大きなストレージを持たず、大型汎用機付帯のストレージが使われた。
1990 年代後半:スーパーコンピュータ自体に強力なストレージを直結、共通のアーカイブ
コモディティのディスク装置が広く出回るようになってきたため、スーパーコンピュー
タ自体に強力なストレージを持つようになった。
2000 年以降:複数の大規模システムで共有する巨大オブジェクトファイルシステム
計算能力が 1TFLOPS を超えるのが通常になり、スーパーコンピュータ自体が扱うデータ量が飛躍的に増えてきた。この結果、個々のスーパーコンピュータ自体には巨大なストレージを持つことは現実的に難しくなってきた。このため、複数のシステムで共用する巨大なストレージを持つアーキテクチャが主流となると見られている。
1990 年代からのインターネットの広がりと共に、ユーザは米国中(世界中)のシステムを利用することができるようになった。テラグリッドに始まるプロジェクトにより広帯域のネットワークが米国中に張られるようになったため、これまで巨大なデータ処理を行ってきたスーパーコンピュータユーザもネットワーク経由でデータを転送し、米国中のセンターを活用してシミュレーションを行えるようになった。しかし、巨大なデータの管理や処理にユーザは多くの時間が必要となり、これらを効果的に実行することがシミュレーション効率を向上するのに不可欠となった。これを解決するために、Scientific Data Management(SDM)というプロジェク
トが 2000 年代初頭に立ち上がった。SDM は、シミュレーション全体処理をワークフローと定義し、シミュレーション処理の自動化、最適化を目指したプロジェクトである。ベンダではなく利用機関が主体となって推進したのが特徴である。
核劣化シミュレーションなど米国では過去の計算結果と最新の計算結果を比較するために大量のデータをアーカイブに格納している。アーカイブからのデータ転送、シミュレーション、シミュレーション結果の可視化、アーカイブへの蓄積という過程で処理が進む。この一連の作業をデータ転送、データ管理をフローとして定義して自動化、最適化を進めている。複数の計算機センターを活用するためのツールなどが開発された。

11

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(2)米国における巨大ストレージシステムの例:ORNL、LLNL システム
米国の中でも、ORNL(Ork Ridge National Laboratory)、LLNL(Lawrence Livermore National Laboratory)
はスーパーコンピュータのストレージに関して精力的なシステム開発を行っている。
この2つの研究所は、
HPCS
プロジェクトにおいて 2012 年に 20PFLOPS 規模の大規模システムの導入を予定しており、このためのストレージ開発を進めている。
[ORNL]
2010/6 の TOP500 リストで TOP1 のシステムである Jaguar システムを運用している。ファイルシステム
としては、Center Wide File System として Spider を導入している。
Spider の概要は次のとおり。なお、バックアップは HPSS を採用、インタコネクトは InfiniBand を採用している。
・DDN のストレージ＋Lustre ファイルシステム
・容量 10PB 以上、1TB SATA ディスクを用いた RAID-6
・192 のストレージサーバ(3TB メモリ)
・200GB/s の転送バンド幅2010 年 HPCS システム導入時のストレージシステムへの要求としては、次のものがある。
・ファイルシステム帯域 1.5TB/s、244PB(8TB SATA)、61PB(SAS)、SATA、SAS、SSD を活用したストレージプール
・-100K クライアント(HPCS、Jaguar)、-200 IO サーバ(400 クライアント/OSS)・HPSS によるアーカイブシステム、pNFS、QOS
・データ保全性:T10-DIF、ZFS(ライセンス問題あり)
・MDS 性能の向上:クラスタ MDS・小容量ブロック IO、ランダム IO 性能の向上
・レスポンス性能の向上:ls -l 実行時間 30 秒
[LLNL]LLNL も古くより多くの HPC システムを導入してきており、2012 年に導入予定の Sequoia システムに向けて大規模なストレージの導入を計画している。LLNL では従来よりファイルシステムを用途に応じて使い分けていることが特徴的である。
・Home:NFS(600TB、
12GB/s)、
並列ファイルシステム:Lustre(8.5PB、
152GB/s)、
アーカイブ:HPSS(42PB、2.5GB/s)・HPSS は新旧 2 システム(SCF、OCF)－SCF は 1967 年からのデータを格納、OCF は 1995 年から、稼働率は 95％以上－SCF は平均 1.24M ファイル/日、OCF は平均 1.53 ファイル/日
Sequoia システム導入に向けての課題は次のとおりである。
・現在の、24 倍のスピードを 2011 までに実現、新しいビルが必要か？
・HPSS を 7.1 にアップデート、5.5PB の Repack をどうするか？
・メタデータサーバをどうするか？
・運用中の効果的な repack/reclaim ポリシーが必要
・動的制御、RAIT ができないか？
・アーカイブに対する考え方－ファイルシステムの一部であるべきではない－しかし、よりインテリジェントに高速にファイルシステムと融合すべきである12

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(3)欧州におけるスーパーコンピュータストレージ事例:CERN と CEA[CERN]CERN では、従来より独自のテープによるアーカイブを中心としたストレージシステムを構築運用してきている。そのシステムは CASTOR(CERN Advanced STORage Manager)と呼ばれている。
CASTOR の特徴としては次に述べる点がある。
・テープの格納情報をデータベース化
・独自コマンドにより、データのステージングと参照を実現
・2007 年現在、60M ファイル、7PB のデータを格納・UNIX ファイルシステムと同様のディレクトリの階層構造とファイル
・GRID 経由のデータ転送をサポート
・専用の検索コマンドを提供[CEA]
CEA では、精力的に Lustre 上で HSM を実現するストレージシステムを開発している。
具体的には、
Lustreと外部アーカイブシステムを結合する Lustre-HSM を開発しており、Lustre 2.0 にマージされた。そして、Lustre の OSS 上のデータをディスクとアーカイブの間でマイグレーションすることにより実現している。
このための Policy Engine として Robinhood が、そして、マイグレーションするためのツールとしてコピーツールが開発された。Robinhood は、ファイルシステム情報の収集、ファイルのパージ、マイグレーショ
ンを実行する。その際の個別のポリシールールを記述することが可能となっている。
コピーツールは、以下のテープストレージシステムに対応している。
・CEA-HPSSコピーツール
・SAM-QFSコピーツール(by SUN)・DMF コピーツール(SGI)(4)演算性能あたりのストレージ性能
一般的に演算性能の向上と必要とされるストレージ性能は比例するとされる。表 2.4.1 に、LLNL(米国)、
ANL(米国)、JAXA(日本)、理研(日本)システムにおける計算性能に対するファイルシステム性能についてまとめた表を示す。
Purple、White、BG/L、Thunder、Jaguar は Top500 リストでそれぞれの時代の TOP レベルのマシンであり、それらの性能を比較すると 1TFLOPS あたり 0.1GB/s から 1GB/s あたりとなっている。
表 2.4.1 LLNL、ANL、JAXA、RIKEN システムにおける計算性能に対するファイルシステム性能
Peak演算性能

メモリ量

48TiB

ディスク量

ファイルシステムバンド幅

TFLOPSあたりのファイルGB/s

2PB

100GB/s

1.0GB/s

Purple100 TFWhite

12.3 TF

8TB 100TB

6.4GB/s

0.52GB/s

UM&UV

12.3 TF

4TB 140TB

12 GB/s

0.98GB/s

Lilac

9.2 TF

3.1TB

n/a

9GB/s

0.98GB/s

BG/L

360 TF

16TB

n/a

40GB/s

0.11GB/s

Thunder

20.1 TF

7.2TB

n/a

6.4GB/s

0.31GB/s

MCR

11.1 TF

4.6TB

n/a

4.8GB/s

0.43GB/s

ALC

9.2 TF

3.8TB

n/a

6GB/s

0.65GB/s

Jaguar(ANL)

119 TF

92TB 648TB

57GB/s

0.48GB/s

JSS(JAXA)

120 TF

94TB

36GB/s

0.30GB/s

RICC(RIKEN)

108 TF 12.3TB

0.5PB 12.8GB/s

0.12GB/s

1PB

n/a: 共用利用でシステム単位分割不能 ()表記のないものはLLNLのシステム

システムに必要なストレージバンド幅は実行するアプリケーションに依存するが、システムの性能向上のスピードに比べてストレージ性能の向上のスピードは遅いため、今後もこのレベルを維持するのが課題である。
13

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(5)まとめ・ORNL、LLNL:ますますストレージシステムは巨大化－テープシステムはアーカイブとして顕在(LLNL は 1965 年から運用)－データ保全性:T10-DIF、ZFS－MDS 性能の向上:クラスタ MDS、小容量ブロック IO、ランダム IO 性能の向上－レスポンス性能の向上:ls –l 実行時間 30 秒
－5.5PB の Repack をどうするか？
－運用中の効果的な repack/reclaim ポリシーが必要－動的制御、RAIT ができないか？
－巨大化が進むほど、故障時の影響が甚大になる
・今後のシステム性能向上にストレージ性能向上をあわせられるかが課題

14

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3 各会員システムの概要
3.1 システムの概要
大規模ストレージの課題や、これからのシステムに対する要求を明確化するために、参加機関毎の特徴的なストレージ IO 例の事例報告を行った。ユーザからの事例として、各会員が関わっているストレージに関するシステ
ムについて、システム概要、認識している課題、将来構想(もしくは最近のシステム更新でやり残したこと)などについて報告を行った。本章は、その報告の要約である。

15

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.1.1 宇宙航空研究開発機構(調布)(1)JSS のシステム概要と特徴
JSS(JAXA Supercomputer System)は、総演算ピーク性能約 141TFLOPS の計算エンジン部、合計 11PB の容量を持つストレージ部と、統合スーパーコンピュータ環境を提供する分散環境統合部からなる(図 3.1.1.1)。計算エンジン部には、様々な計算需要に対応するために 4 つのサブシステム、M システム(Main システム)、P シ
ステム(Project システム)、A システム(Application システム)、V システム(Vector システム)を用意している。ストレージ部は、実効容量 1PB、総実効転送性能 25GB/s の RAID5 装置と、総容量 10PB、LTO4 ドライブ 40
台、LTO3 ドライブ 8 台の LTO ライブラリ装置を SAM-QFS で階層管理している。図 3.1.1.2 に、ストレージ部の構成概要を示す。また、JSS の主要計算エンジンである M システムをクライアントとした場合のファイルシ
ステム構成を図 3.1.1.3 に示す。JSS の計算エンジン部は調布事業所に設置されているが、これを角田、相模原、筑波の各事業所からもシームレスに利用するために、分散環境統合部は、ログインノード機能を提供する
L システム(Local システム)と、遠隔共有ファイル機能を提供する J-SPACE(JSS's Storage Platform for
Archiving, Computing, and Exploring)を、これら 3 事業所に配置している。
ストレージ部は、ネットワークファイルシステム、ローカルファイルシステムと階層ストレージ管理、OSのデバイスドライバ、ストレージエリアネットワーク、ストレージデバイスから構成される。ネットワークファイルシステムはネットワークへのインターフェースとして InfiniBand と Ethernet を持つ。InfiniBand イ
ンターフェースにより M システムと A システムを、Ethernet インターフェースにより L システムを収容できる。ローカルファイルシステムからストレージデバイスまでは冗長構成をとっており、各部分の一部に故障が発生しても、迂回経路やバックアップ機能を用いてユーザへのファイルシステムサービスを継続できるようになっている。
ストレージ部では、数千並列という高並列度演算においても、総実効転送性能 25GB/s を確保しつつ、ファイルシステムが自動的に排他制御を厳密に実施するシステムを構築することにより、ユーザのプログラム開発の時間を確保するよう努めた。また、物理的なストレージ媒体のエラー等によるデータ消失に備えるため、合計 11PB の容量を持つストレージ装置では、ディスク装置は RAID5 構成をとり、テープ装置へのアーカイブ時には同時に 2 つのテープ媒体に書き込みを行っている。

図 3.1.1.1 JSS の全体構成

16サイエンティフィック・システム研究会
M-System

大規模ストレージ WG 成果報告書

A-SystemInfiniBand

L-System

CPUs

Ethernet

Inter-/Intra- Connect Network

SRFS/SRFS on Ether

Network File System

SAM-QFSSAM-QFSSAM-QFS

Local File System
Hierarchical Storage Management

Solaris10

Solaris10

Solaris10OS

FC-SAN
SwitchFC-SAN
Switch

RAID
×90

LTO
×48

Storage Area Network

Storage Devices

図 3.1.1.2 ストレージ部の構成概要
Compute node
←12,032cores / 3,008nodes
Computenode
ComputeFilenode
node
Cache
ComputeCompute node

クラ イアント
2GB/s per node
(Total:6,016GB/s)←IB ×3,008
IB:2GB/s
FC:0.4GB/s

IB switch

ｲﾝﾀｰｺﾈｸﾄ←IB ×54

108GB/s

File server

ﾌｧｲﾙｻｰﾊﾞ←3 servers

File Cache
36GB/sＳＡＮ(0.4GB/s)×180←FC ×(20+4)

FC ×90→FC switch

FC switch(FC×1)×180→

ストレージ
デバイス

←FC ×40

RAID5
RAID5
RAID5

(8+1.6)GB/s←FC ×4

Metadata
RAID1

LTO4
LTO4

【ファイルシステム構成】
項目

数値

・クラ イ アント数
・クラ イ アントOS・クラ イ アント一台当たりのコア数
・クラ イ アント一台当たりのメ モリ量・クラ イ アント一台当たりのイ ンタ コネクトバンド幅

3008
Open Solaris
4
32GB
2GB

・フ ァイ ルサーバ／クラ イ アント間総バンド幅

108GB/s・フ ァイ ルサーバ数( メ タ データ サーバと データ 処理サーバ)・フ ァイ ルサーバOS・フ ァイ ルサーバ一台当たりのコア数・フ ァイ ルサーバ一台当たりのメ モリ量3Solaris 10
128
1TB サーバキャッシュ 640GB・フ ァイ ルサーバ／ストレージ 間総バンド幅36GB/s・フ ァイ ルシステ ム当たりのストレージ 台数・ストレージ処理能力( 一台当たりのバンド幅)

90台
Read:400MB/s
Writ e:200MB/s【運用方法】
項目

内容・フ ァイ ルシステ ムのブ ロック長・quot a有無・データ 暗号化有無
・ACL有無

1MB
あり
なし
あり

図 3.1.1.3 ファイルシステム構成

17

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

以下に、JSS ストレージシステムの特徴を列挙しておく。
・IO ノードの冗長化(3 台構成)
・DAS から FC-SAN へ・LTO1 から LTO4 へ・高価格 RAID から中価格 RAID へ・ファイルシステムにおけるクライアントキャッシュの利用(2)ストレージの利用状況
JSSでは、
SAM-QFSにより階層管理されているユーザ計算データ蓄積領域として、
大ファイルサイズ用にlarge
領域を、小ファイルサイズ用に small 領域を用意している。図 3.1.1.4 に、これらのディスク上に蓄積されているファイル数(上段)とデータ量(下段)の 2010 年 11 月時点の分布状況を示す。ファイルサイズ 50MB 以上はlarge 領域を、それ以下は small 領域を使用するよう利用案内をしているが、実際は large 領域に 16MB 未満のファイルが多数あったり(図 3.1.1.4 左上グラフ)、small 領域に 64MB を超えるファイルが少し存在している(同右上グラフ)ことがわかる。JSS ジョブの特徴のひとつは、システムの約半分の計算資源を用いて行う戦
略的大規模解析ジョブの存在であり、JAXA 事業への貢献、大規模性、学術的価値の 3 つの観点から有識者により採択された課題に JSS の計算資源を優先的に割り当て研究開発を促進するものである。このジョブは数百
TB の解析結果ファイルを出力するものが多く、図 3.1.1.4 左下のグラフのファイルサイズ 256MB 以上でデー
タ量が急増しているのは、このジョブの影響が大きい。
JSS(large)ファイル数分布(戦略的大規模データ含む)
ファイル数

1,200,000

ファイル数

600,000
400,000
200,0000

ファイル数

1,200,000

累積1,000,000

Total:555万files

800,000
600,000
400,000
200,0000

JSS(small)データ量分布

累積

200

Total:919TB

100
50
0

データ量[TByte]

データ量

5
4.5
4
3.5
3
2.5
2
1.5
1
0.5
0

100
90
80
70
60
50
40
30
20
10
0

データ量
累積

Total:20.4TB

18

4G ≦

<large ファイルシステム><small ファイルシステム>
図 3.1.1.4 JSS ストレージの利用状況< 4G< 256M

< 1G

< 64M

< 4M

< 16M

< 1M

< 256K

< 64K

< 4K

< 16K

< 1K

4G ≦

< 4G

< 1G

< 256M

< 64M

< 4M

< 16M

< 1M

< 256K

< 64K

< 4K

< 16K

< 1K

ファイルサイズ[Byte]

ファイルサイズ[Byte]

データ量累積[%]

100
90
80
70
60
50
40
30
20
10
0

データ量累積[%]データ量[TByte]

4G ≦

< 4G

< 1G

< 256M

< 64M

< 16M

< 4M

< 1M

JSS(large)データ量分布(戦略的大規模データ含む)
300

150

< 256K

< 64K

< 4K

< 16K

< 1K

4G ≦

< 4G

< 1G

< 256M

< 64M

< 16M

< 4M

< 1M

< 256K

< 64K

< 16K

< 4K

< 1K

ファイルサイズ[Byte]

ファイルサイズ[Byte]

250

100
90
80
70
60
50
40
30
20
10
0

ファイル数累積[%]

Total:614万files

JSS(small)ファイル数分布
1,400,000

ファイル数累積[%]累積1,000,000
800,000

100
90
80
70
60
50
40
30
20
10
0

ファイル数

1,400,000

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(3)認識している課題と将来構想
以前の数値シミュレーションにおいては、"データは計算し直せばよい"という考え方があり、保護すべきはソースコードとジョブ投入コマンド群である、との認識が少なからずあった。しかし、最近の数値シミュレーションの大規模化や、非定常計算への関心の高まりにより、多くの CPU タイムを使用して得たシミュレーシ
ョン結果ファイルや、急速に増加している非定常解析用データファイル群が現れ、"データは保管するもの"という考え方が広がってきた。
(a)データプロテクション
HSM を大規模に導入しデータプロテクションの機能は向上したと考えられる。バックアップソフトウェ
アではなく HSM によりデータプロテクション機能を実現しているため、ユーザは今まで通りのファイル管理を行うだけで、データプロテクションのための操作を新たに覚える必要はない。システムが自動的にバックアップとリストアを行っている。具体的には、ディスクに書き込まれたファイルを一定のポリシーに従ってテープ媒体 2 本にコピーする。一定のポリシーに従ってディスクから削除されたファイルを使用する場合は、システムが自動的にテープ媒体にコピーしたファイルをディスクにコピーしユーザが利用可能な状態にする。ひとつのテープ媒体が破損していた場合は、もう一方のテープ媒体を使用するようになっている。従来のバックアップ/リカバリの考え方や操作とは異なる方法ではあるが、このような方法でデー
タプロテクションを実現している。この運用で大きな課題は発生していないが、あえて課題を挙げると次のようなものがある。
・全てのファイルを分け隔てなくバックアップしてしまうため、バックアップ不要なファイルまでバックアップしてしまっている可能性がある。
・ユーザはこれから使おうとしているファイルがテープ媒体上に存在することを意識していない場合があり、このとき、ファイル IO 開始までの待ち時間が通常の場合と比べて非常に長時間となってしまう。現在はバッチジョブのスケジューリングの仕組みを工夫して、この問題が発生しないようにしている。
(b)アーカイブ・HSM
HSM の便利さに気付き始めたユーザからは、スーパーコンピュータシステム内だけでなく、構内ネット
ワークや更にはインターネットからもその機能を使えないかという声が挙がり始めており、遠隔ファイルシステム等と連携したデータプロテクションシステムの実現が望まれる。また、ストレージシステムが広く利用されるようになると、その構築コストにも目が行く。
現在は比較的高価なRAID装置を用いているが、装置自体の低価格化が望まれる。また、HSM ソフトウェアのライセンス料も課題のひとつである。HSM 管理
される容量に対して従量課金するライセンス形態の場合、大規模なシステムの構築に支障が生じる可能性があるため、定量課金ライセンス形態の方がシステム構築し易い場合が多い。
(c)ストレージ管理
ストレージ管理での課題のひとつは、ストレージハードウェア故障時の交換対応である。単体ディスクが故障した場合は RAID 構成となっていれば運用を停止することなく復旧可能であるが、RAID コントローラ
や複数故障が発生した場合、運用を停止する必要が出てくる。大容量化が進めばこの課題は今まで以上に顕在化してくると思われる。
また、ストレージ換装時のデータ移行が次の課題として挙げられる。ディスク装置だけでペタバイトのシステムを持てるようになった現在では、今までの手法だとデータ移行に長期間を要してしまう。大容量のストレージを長期間にわたり連続的に運用管理できる仕組みの構築が望まれる。

19

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(d)データアクセス管理
データアクセス管理で一番の課題は、データ共有である。スーパーコンピュータのみならず、他のコンピュータからも、スーパーコンピュータにあるファイルにアクセスしたいという要求である。上記(b)でも述べたが、このアクセス範囲は、構内ネットワークに留まらず、外部の組織との連携を考え、インターネ
ット越しのアクセス要求も出てきている。
次の課題としては、データアクセス権の細かい制御である。現状でも拡張アクセスコントロール機能を利用すれば実現できるものであるが、広く利用されていない現状を考えると、その利用には課題がいくつかありそうである。具体的要求としては、メインフレームで実現しているような、個人単位のアクセス許可や、個人が複数のグループに属した場合の分かりやすいアクセス制限のかけ方のようである。
(e)デバイス管理
スーパーコンピュータシステムの場合、一度システムを構築してしまったら、ストレージシステムの構
成変更はあまり発生しない。一方で、大規模なシステム構築をすることから、日々の動作状況監視が重要となる。今後のシステム設計のための参考資料としても、この日々の動作監視が重要であると考える。
(f)データレプリケーション
JSS では、データレプリケーション機能は実現していない。スーパーコンピュータの役割として、スーパーコンピュータでなければできない数値シミュレーションの実行を主眼としてきているためであると考えられる。今後も、この方針は変わらないと考えられるが、ユーザニーズの多様化や、遠隔地事業所からの利用等の観点で、データレプリケーション機能が必要になってくる可能性がある。
(g)ファイルシステム
ファイルシステムに要求されるものは、高速性と共有性である。高 FLOPS 化する計算エンジンの入出力に耐えられるファイルシステム、遠隔地事業所からのスーパーコンピュータ利用や共同開発体でファイル管理を実現する遠隔共有性の実現が望まれる。
(h)その他(圧縮、暗号化など)
JSS では、データ圧縮や暗号化は行っていない。今後、多岐にわたるユーザが単一システムであるスーパーコンピュータを利用する場合、暗号化は利用者から要求される可能性がある。具体的には、システム内でのデータ漏洩防止やデータをシステム外に持ち出す場合のセキュリティの観点からファイルの暗号化が必要になる可能性がある。また、データ量が増大する中、ストレージの媒体総量を圧縮するためにデー
タ圧縮技術を利用することが期待される。

20

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.1.2 理化学研究所(1)RICC の概要および特徴
RICC(RIKEN Integrated Cluster of Clusters)システム(図 3.1.2.1)は 2009 年 8 月から運用から開始した
スーパーコンピュータ・システムで、演算システムとして超並列 PC クラスタシステム、多目的 PC クラスタシ
ステムおよび大容量メモリサーバシステム(理論ピーク性能として、CPU:108TFLOPS、GPU:93TFLOPS(SP)、MDGRAPE-3:64TFLOPS)、ストレージとして 2 システム(ディスク:550TB、テープ:4PB、そのうち 2PB を利用)ファイルシステムには QFS+SRFS、テープマネジメントソフトウェアには HPSS を用いている。それらを繋ぐネットワーク(InfiniBand DDR、10GbE)から構成されている。本システムは理研の幅広い研究分野のユーザをサポートするために、様々な計算資源を組み合わせた構成になっている。
ストレージ・システムについては、RICC ではディスク・ストレージ上のファイルへのダイレクト・アクセ
スとステージングの 2 通りの方式を混成して利用しており、超並列 PC クラスタのバッチ運用部分はステージ
ング運用、インタラクティブ運用部分はダイレクト・アクセスと多目的 PC クラスタおよび大容量メモリサー
バに関してはダイレクト・アクセスとなっている。データアクセス系の構成、データパス、帯域、台数などを
図 3.1.2.2 および図 3.1.2.3 に示す。図 3.1.2.3 の帯域は RAID 装置からファイルサーバまでの帯域はバラン
スが悪く感じられるが、実際には RAID 装置単体には FC の帯域を埋める能力はなく、10GB/s 以上程度の実効性能を考慮している。RAID 装置の実効能力を設計値に用いたバランスの構成となっている。
演算システム部からディスク・ストレージまでの最大理論帯域は 12.8GB/s(ファイルサーバ－FC スイッチ間の FiberChannel 本数)、実効性能として 8GB/s 程度を確保している。ディスク・ストレージの RAID 装置はRAID6 構成で構築している。現時点で 40%程度をユーザに開放している。
また、テープ・アーカイブまでの理論帯域 5GB/s(スイッチ間の 10GbE×4)となり、テープ帯域の方が広い
ためネットワーク帯域は全部使い切れる程度の実効性能を有する。テープ・アーカイブへの書き込みは 2 テープへの 2 重書き込みを行っている。テープ・アーカイブの利用形態は、データバックアップやユーザデータの保存領域として利用している。テープ・アーカイブは HSM 構成を取っているが、ディスク領域はキャッシュとして利用しているのみで、運用として HSM を意識して利用していない。

図 3.1.2.1 RICC システム全体構成

21

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

図 3.1.2.2 システム全体のネットワーク構成←9,504cores / 1,188nodes

Node
クライアント2GB/s per node
(Total: 488GB/s)

10GE× 4 →1 server →Ethernet switch

10GE ×1 →←10GE × 4

File server

Ethernet switch

File Cache←10GE × 2

10GE× 12 →6 servers →FC × 32 →FC switch

SAN

ストレージ装置←1GE x 2 × 34

IB Spine switch
IB × 16 →1GE:0.1GB/s

Ethernet switch

IB Leaf switch

ファイルサーバ

38.4GB/s

10GE:1GB/s

IB × 1,188 →インターコネクト

12.8GB/s

FC:0.4GB/s←1GE ×1,188

IB × 244 →32GB/s

IB:2GB/s

Computenodenode
ComputeFilenode
Cache
ComputeComputenode

DataMover
Mover
Data
Data
Mover
Data
Mover
Data
Mover
Data Mover

FC × 6 →FC × 96 →FC Switch

FC×12 →
RAID6
RAID5
RAID5

Core Server←FC × 12

Cache
Cache
Cache
RAID5
Cache
RAID5
Cache
RAID5
Cache
RAID5
RAID5
RAID5

LTO4
LTO4
LTO4
LTO4
LTO4
LTO4

図 3.1.2.3 ストレージ概要のデータパスの帯域

22← FC×4
Metadata
RAID5

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

表 3.1.2.1 ファイルシステム構成【ファイルシステム構成一覧】
項目・クライアント数
・クライアント OS・クライアント一台当たりのコア数
・クライアント一台当たりのメモリ量
・クライアント一台当たりのインタコネクトバンド幅・ファイルサーバ／クライアント間最大バンド幅・ファイルサーバ数(メタデータサーバとデータ処理サーバ)
・ファイルサーバ OS・ファイルサーバ一台当たりのコア数
・ファイルサーバ一台当たりのメモリ量
・ファイルサーバ／ストレージ間総バンド幅
・ファイルシステム当たりのストレージ台数
・ストレージ処理能力(1 台当たりのバンド幅)

数値
1,188
Linux
8
12GB(1040 台),24GB(100 台),
32GB(32 台),512GB(1 台)
2GB/s
32GB/s1
Solaris 10
128
512GB
12.8GB/s
24
R:400MB/s W:200MB/s【運用方法】
項目
・ファイルシステムのブロック長
・quota 有無
・データ暗号化有無
・ACL 有無内容
256KiB(Home),4MiB(Data)
あり
なし
なし

(2)ストレージの利用状況
ストレージのユーザ利用に関して、ファイルシステムはユーザのホームにあたる領域(50TB)と大容量のデータ利用としての領域(500TB)に分けている。ファイルシステムは現時点で全領域を開放していないが、テープ領域は全領域を解放している。図 3.1.2.4 に示すように、運用開始 1 年 2 カ月で開放ファイルシステムの70%程度(ディスク領域全体の 30%程度、ディスク容量として 210TB 程度)を利用しており、テープ領域で 16%程度(テープ容量として 320TB 程度)を利用している。テープ領域は別途高エネルギー物理の実験グループが利用している約 2PB のデータが別に存在する。

図 3.1.2.4 ファイルシステムの利用状況
23サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

図 3.1.2.5 HPSS の利用状況(3)問題点と今後の課題
現時点におけるストレージ部分の問題点はハードウェアやデータパスではなく、ほとんどが小ファイルの大量 IO 時にファイルシステム内部の問題に起因する IO 性能のスローダウン問題である。現時点において、対症療法的な対応はなされて、運用において致命的な問題点は顕在化していない。今後バイオ系の実験データとの連携をしていく上で、現在のファイルシステムでこのまま対応できるかは注視している。
また、問題点とまでは言えないが、RAID 装置の HDD 予防交換の頻度が高いことがある。あくまでも予防であるため、本質的に問題はないと考えられるが、予防交換と完全な故障の交換手順および切り分けポイントを明確な説明が無く、リビルドにほぼ 1 日を要する現在の RAID 装置で、実際に RAID6 の HDD エラー・エラー予
兆(Eturnusの機能)が発生した場合にどのような挙動になるのか実際のフローを確認しておく必要があると考えている。
今後の課題として、大きく 3 点を考慮しなければならないと考えている。1 点目として、次期スーパーコン
ピュータ・システムは現在の 10 倍前後の性能になると考えられるが、ファイルシステムに対する要求は IO 性
能・容量ともに 10 倍を超える性能になると考える。その場合に安定した運用が可能なファイルシステムが必要となる。2 点目はデータ移行であり、次回のデータ移動は高エネ・グループのデータも含めて 6PB を超える値が予測されており、システム移行だけを見据えただけでは、移行計画が立てられない可能性もあり、システ
ムのリプレースとは別に現在のストレージ装置内で、テープだけを移動するなどの検討が必要と考える。3 点
目は現時点でそれほど顕在化した問題ではないが、理化学研究所全体で生成されるデータを保管するようなシステムを検討する必要があるかもしれない。そのような状況になった場合、それらデータを災害対策なども含
めてどのように安全に保管しておくか、包括的な対応を検討する必要がある。

24

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.1.3 東京大学宇宙線研究所(1)研究の概要
東京大学宇宙線研究所(ICRR)附属神岡宇宙素粒子研究施設は、岐阜県飛騨市の神岡鉱山の地下 1000m に、宇宙・素粒子研究のための実験スペースを有している。
この神岡坑内の物理学実験用のスペースは日本最大で、世界でも有数の地下物理実験エリアとなっている。神岡の地下では宇宙線の強度を 10 万分の 1 に低減できる
ため、バックグラウンドの少ない実験が可能となる。特に、ニュートリノと呼ばれる素粒子の性質を調べる研
究や、宇宙暗黒物質の直接探索を目指す研究等が現在進められている。
神岡での実験プロジェクトの中で最大のものにスーパーカミオカンデ(SK)実験がある。スーパーカミオカ
ンデ検出器は、直径 40m 高さ 40m の円筒形のステンレス製容器の内壁面から約 2m 内側に遮光用の壁を作り、内向きに直径 50cm の大口径の光電子増倍管(PMT)を約 11200 本配置、外向きにも 1885 本の直径 20cm の PMT を配置、容器中に 50000 トンの純水をいれたものである。この検出器で飛来してきたさまざまなニュートリノが純水と反応した際に出る微弱な光を測定している。観測しているニュートリノとしては、太陽で核融合時に生成する太陽ニュートリノ、宇宙線が地球の大気と反応した際に生成する大気ニュートリノ、重い星の一生の最終段階で起こる超新星爆発時に大量に放出される超新星ニュートリノ、加速器からのニュートリノ等がある。
スーパーカミオカンデはこの研究分野で世界最大規模の検出器であり、これまでにニュートリノに質量がある
実験的証拠を世界で初めて示す等の注目される観測結果を公表している。図 3.1.3.1 に検出器の様子を、図3.1.3.2 に事象の例を示す。

図 3.1.3.1 スーパーカミオカンデ検出器の内部(2006 年 6 月)

図3.1.3.2 スーパーカミオカンデ検出器で観測した
高エネルギーのニュートリノ事象の例。
中央が内側の円筒型検出器の展開図で、各点が光を受けた PMT を示し、色が受けた光の強度を表す。

(2)計算機システムの概要
神岡宇宙素粒子研究施設では、スーパーカミオカンデ実験の観測データの収集、蓄積、解析のために、「スーパー神岡実験解析用電子計算機システム」を有している。本システムの概要を図 3.1.3.3 に示す。スーパー
カミオカンデ検出器内部の PMT からのアナログ信号はフロントエンドの電子回路装置でデジタル化され、光の量、到達タイミング、PMT 位置を、前段処理装置でリアルタイムに記録する。現在は、1 秒間に約 3000 事象が選別・記録されている。1 事象あたり、30～13000 程度の PMT が光を受けた信号を出し、これは 200～80000 バ
イト/事象のデータ量に相当する。
現在の平均のデータ流量は、坑内のリフォーマット計算機までで430MB/sec、
坑外の解析装置では 590GB/day となっており、このデータにさらに選別をかけることで最終的にストレージには 120GB/day の割合で記録している。1996 年の観測開始から現在までの期間に蓄積したデータ量は約 250TBとなっている。この観測データは、容量 700TB の磁気ディスク装置上で保管されている。解析装置は Linux ベースの PC クラスタで、NQS の管理下で最大 1080 ジョブが同時に実行される。個々のジョブは独立した処理である。ユーザーは国内外の研究者約 300 名だが、この中にはスーパーカミオカンデ以外の研究プロジェクトの参加者も含まれる。これらのプロジェクトに参加している研究者向けのネットワーク、電子メールなどのインフラとしても本計算機システムは利用されており、遠隔地からの共同研究者のネットワーク経由でのデータへ
25

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書のアクセスも常時行われている。
スーパーカミオカンデは 24 時間 365 日観測を行うため、計算機システムもこれに対応した運用を行っている。特に超新星ニュートリノに関しては、銀河系内での超新星爆発の発生頻度が数十年に 1 度と予測されているだけで、いつ発生するかわからない。また仮に超新星爆発が発生した場合、約 20 秒程度の間に大量のニュートリノが飛来して来るため、検出器のデッドタイムは極力少なくする必要があり、特に前段処理装置とネットワークに関しては 24 時間、障害発生から 2 時間以内に作業員が現地に到着できる体制をとっている。

図 3.1.3.3 計算機システムの概要(3)ストレージの使われ方
スーパーカミオカンデの観測データとして、現在、1 日当たり約 100MB の大きさのファイルが約 1000 ファ
イル作成される。解析装置では、それらのファイルを別々のジョブで解析している。解析時間はおおむね 1 フ
ァイル 30 分程度以下である。解析目的に応じて同じ観測生データを別々のプログラムで複数回処理することもあり、また数ヶ月に 1 回程度、全ての観測データを再解析することもある。よって、磁気テープのみで観測データを保管すると不便なため、現在はほとんどの観測データが容量700TBの磁気ディスク装置上で保管され、磁気テープ装置は主に観測生データの 2 重化を行う目的で導入されている。
700TB の磁気ディスク装置は、1080 プロセスからの並列アクセスがあった場合でも、必要なデータ転送性能を維持することを要求している。そのため、ファイルシステムに SRFS を採用しています。また、実験デー
タ解析ではインタラクティブにプロットを表示させる操作もあり、その際にも十分高速なレスポンスが必要となる。この要求に対応するため、約 290 台のクライアント計算機がある状況下でも NFS 経由で比較的高速なレスポンスを提供する NR1000 をユーザーのホームディレクトリを管理する磁気ディスク装置として使用している。
SRFS は本計算機システム向けのチューニングを行い、IO サイズを 8MB に固定した場合に、1080 ジョブから100MB の容量の異なるファイルに対する同時アクセス時に、962MB/s のデータ転送能力を実現している。実際には 1 ディスクサーバあたり 20 ジョブ同時アクセス時に最高の性能(357MB/s)を出し、1 ディスクサーバあたり 1080 ジョブアクセスの場合に約 7%の性能低下に抑えられている。

26

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(4)課題
現在のスーパー神岡実験解析用電子計算機システムはおおむねユーザーの要求を満たすシステムとなっていますが、何点か改善の余地がある。例えば、本計算機システムの SRFS は、同時・多数のアクセスが行われている際に、(IO サイズの小さい)インタラクティブなアクセスに関してレスポンスが急激に悪化する。現在は、データファイルを IO サイズを 8MB に固定した専用の copy コマンドでローカルディスク等にコピーしてからインタラクティブな操作をすることで対処しており、SRFS 上でもインタラクティブなアクセスに関して十分なレスポンスを発揮できれば使いやすくなると考えられる。また、神岡の SRFS では IO サイズを 8MB に固定した時に最大性能がでるように調整してあるが、8MB から 1 バイトでもずれると、転送速度が約 60%に減少する。この点はまだ改善の余地があると思われる。
、また、通常の OS 標準の cp -r、mv、ls、tar などもユーザーが意識しないで高速に実行できることが理想的である。

27

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.1.4 国立天文台(1)はじめに
国立天文台では研究所内の職員や大学院生が利用するシステムと、大学共同利用機関として全国の天文学研究者に天文データや計算機機能を提供するための共同利用システムの両方を運用している。
国立天文台では統合的な大規模計算機システムは使われておらず、中規模〜大規模ストレージを用いたシステムが複数あり、それぞれをプロジェクトごと、例えばデータ解析システム、すばるアーカイブシステム、
公開アーカイブシステム、ヴァーチャル天文台システム、など別々に管理運用されている。本章ではこの中で2つのシステムについて述べる。
(2)大規模ストレージの利用方法(a)データ解析システム
国立天文台では大規模ストレージは2種類の用途で用いられている。一つは共同利用のデータ解析シス
テムの中で用いられるような解析途中の中間ファイル置場としてである。このようなストレージではユーザが頻繁かつランダムにディスク領域をアクセスし、データを更新し、その結果を一定の期間保持する事が求められる。これは例えて言えばメモ帳のような機能である。
図3.1.4.1はこのデータ解析システムの概略である。データ解析システムでの主な利用形態は対話型処理である。バッチシステムも準備はされているがデータ解析の途中で画像を確認したりインタラクティブ
処理が入ったりするアプリケーションの利用が多いため、特に観測データ解析では対話型システムを利用する慣習が根強い。ユーザは端末から ssh で計算サーバのいずれかにログインし、そこでプログラムを実行する。その際の作業領域として、NFS4経由でマウントされたディスクを用いている。ユーザのホーム領
域は9.4TB の Network Attached storage(NAS)である。
この領域には1ユーザあたり6GB のクォータ制限がかけられているため、ほとんど全てのデータ解析処
理は、前述の作業領域で行なわれる。作業領域中のファイルは最終更新日(ctime)から8週間を過ぎた次の水曜日の未明に有無をいわさず自動消去される。この自動消去は従来からの伝統であり、ユーザも既に馴染んでいる。

図3.1.4.1 国立天文台のデータ解析システムの概要(b)すばるアーカイブシステム
天文台でのもう一つのストレージの用途は、すばるアーカイブシステムなどのように観測データを保持しておく貯蔵装置としての利用である。こちらは半永久的にデータを管理保持し、要求に応じてデータを提供する機能が期待されている。例えて言えば、図書館(古文書館)のような機能である。特に天文学は観測はできても実験はできず、かつ一過性の現象にも大いに学問的価値があるという特性から過去のデータを全て保持しておく事は極めて重要だと認識されている。
すばる望遠鏡のアーカイブシステムはすばる望遠鏡で得られたデータ、主に観測データを管理保管するためのシステムである。データは一度書き込むと消されずに次期システムにも引き継がれていく。2012年
度頃から大型装置が稼働しはじめる計画があり、次回のシステム更新の際に引き継ぐべきデータは300-400TB
28

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書であろうと予想されている。
すばる望遠鏡のアーカイブは、ハワイ島にあるハワイ観測所に1システム、ほぼ同構成のシステムが三鷹キャンパスに1システムある。このように2箇所に同じデータを置いておく理由は、地震や火災や洪水などによる不慮のデータ損失に対する保険と、日本国内のユーザに毎回太平洋経由でデータを提供するのは無駄も多く遅延も大きいというキャッシュ的な意味合いの両方が含まれている。実際に数年前にミドルウ
ェアの障害でデータ破壊のインシデントがあったが、バックアップが複数あったことで、無事完全復旧をすることができた。データは多い日には現在1日50GB が保存される程度だが、将来的には500GB/日程度になる見込みである。

(3)ハードウェア構成(a)データ解析システム
データ解析システムには大容量ファイルサーバ群とホーム領域という2つの大規模ストレージがある。
大容量ファイルサーバ群は4つの Red Hat Enterprise Linux5(以降 RHEL5)のサーバに、RAID5(5+1)ス
トレージを複数、ファイバーチャネルで接続している。サーバは4コアでメモリは8GB である。ファイルシ
ステムは ext3である。サーバ1台あたりのディスクへのバンド幅はシーケンシャル4多重で4Gbps である。
ファイルシステムのブロック長は4096バイトで、Access Control List(ACL)、quota、暗号化は利用していない。これらサーバは NFS サーバとしてディスク共有に供している。複数の RAID5ディスクは1サーバあたり1-1.3TB の22個の論理ボリュームに分割して提供されていたが、利用者の利便性の観点からこれら領域を再編成し6TB ほどの RAID6領域に変換する計画が現在進められている。
NFS のクライアントは、対話型解析サーバ14台、バッチジョブノード6台と端末12台である。これらク
ライアントは大容量ファイルサーバを Gb-ether 経由で NFS4でオートマウントしている。解析サーバの2台
は Oracle Solaris10(以降 Solaris10)で、2コア、メモリは8GB である。解析サーバの残り12台は RHEL5の4
コア、メモリは16GB である。またバッチジョブノード6台はこの12台の解析サーバと同構成である。端末12台は RHEL5で2コア、メモリは8GB である。
ホーム領域は、GB のスイッチと1Gbps 4本で接続された専用の NAS を用いている。OS は Data ONTAP 7.3.2で、1コア、2.5GB メモリ、で総計48台のディスクを結合して用いている。ブロック長は不明、NFS の window
サイズは32768である。Quota は一般ユーザに対し、6GB で設定しており、ACL、暗号化は利用していない。
実効容量は12.5TB である。このホーム領域も前述の、解析サーバ14台、バッチジョブノード6台と端末12台から Gb-ether 経由で NFS3マウントしている。
また、これら運用系とは別に小規模の開発試験系を用意しており、こちらには1-1.3TB×3領域の RAID5
ディスクを備えた大容量サーバと、小規模な NAS(home 領域)を、3つの解析サーバと2つのバッチジョブノードが同様の NFS マウントをする構成になっている。

図3.1.4.2 国立天文台のデータ解析システムの大規模ストレージの構成

29

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

表3.1.4.1 国立天文台のデータ解析システムの大規模ストレージの諸元【システム構成】
ホーム領域
大容量サーバ
対話型解析サーバ(A、B)、バッチ型サーバ(C)、端末(D)
12(A)+2(B)+6(C)+12(D)RHEL5(A、C、D)、Solaris10(B)
4(A、C)、2(B、D)
16GB(A、C)、8GB(B、D)
1Gbps

クライアントクライアント数
クライアント OS
クライアント一台当たりのコア数
クライアント一台当たりのメモリ量
クライアント一台当たりのインタコネクトバンド幅
ファイルサーバ／クライアント間
4Gbps
総バンド幅
ファイルサーバ数(メタデータサーバとデー1
タ処理サーバ
ファイルサーバ OS
Data ONTAP 7.3.2
ファイルサーバ一台当たりのコア数
1
ファイルサーバ一台当たりのメモリ量
2GB+512MB
ファイルサーバ／ストレージ間
4Gbps
総バンド幅
ファイルシステム当たりの48
ストレージ台数
ストレージ処理能力
R:162MB/s W:127MB/s(1 台当たりのバンド幅)

32Gbps
4
RHEL5
4
8GB
4Gbps
5+1(RAID5)
R:235MB/s W:102MB/s【運用方法】
ホーム領域
ファイルシステムのブロック長
quota 有無
データ暗号化有無
ACL 有無

不明
あり
なし
なし

大容量サーバ
4096 Byteなし
なしなし(b)すばるアーカイブシステム
三鷹側の構成について述べると、ディスクの主な部分は観測データを保管する場所で、
18TB×4+12TB×2の RAID6ディスクである。ファイルシステムは ZFS である。ここに保管されたデータは定期的に LTO のジュークボックスにもバックアップされるが、ここ3年の運用では LTO からの書き戻しが必要になった事例はない。
この観測データ領域は NFS サーバにファイバーチャネルで直結され、その領域を NFS3で4台の管理サー
バ(登録サーバ、検索サーバ、提供サーバ、評価サーバ)でマウントし、利用している。領域への書き込み
は登録サーバからのみであり、他のサーバは参照のみ行なっている。

(4)現在の課題
データ解析システムについては、現時点では大きな課題はない。ディスクアクセスの性能は決して高くはないが、特に大きな苦情は出ていない。中長期的な課題としてはこの低値安定のシステムの今後の存在意義であるが、大規模データを産出する観測装置の稼動開始に伴い、各研究者や研究室の保持する計算機では扱いきれないような大規模データの解析に対する利用者の要望をどれだけ吸収できるかが焦点となるであろう。
また、
国立天文台では定期的にデータ解析講習会などを開催しており、その際のプラットホームとしてある程度の規
模のストレージ、サーバ、端末を備えておくことは今後も重要であろうと考えられている。
すばるアーカイブシステムに関する大きな課題は、次期大型装置への対応とそれに伴う大量のデータの次期システムへの移行である。現在ストレージ自体の書き込み性能は十分に余裕があり、大型装置への対応で一番の問題になるのは、ハワイと三鷹の間のデータ転送の高速化になると予想されている。また300TB 以上のデータを次期システムに引き継ぐ場合、その移行をどのような手順で行なうかも課題である。これは現在の想定では主に設置スペースと電力および空調の問題であり、同時にサービス停止期間をいかに短くさせるかという30

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

課題も含んでいる。
また、両システムに関して強いて懸念材料を挙げれば、ディスクの大容量化に伴いリビルド時間が長くなっていることである。現在までの運用ではダブルデッド等によるデータロストは発生していないが、運用期間が長くなるにつれ加速度的にディスク故障が増えた場合にどのような状況になるかは現時点では未知数である。
また論理ボリュームの大きさを大きくすることの得失も今後2〜3年の運用を通じて明らかになるであろう。

31

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.1.5 高エネルギー加速器研究機構
KEKには、高エネルギー加速器による実験で生成されるデータを保存・解析するための共通計算機システム(KEKCC)、
B ファクトリー実験で生成されるデータを保存・解析するための B ファクトリー計算機システム、大規模数値シ
ミュレーション用のスーパコンピュータシステムの 3 つの大規模算機システムがある。本稿では、この中の KEKCCの紹介をする。なお、B ファクトリー計算機システムの利用形態は KEKCC と同様なので、システム構成も KEKCCと同様である。

(1)KEKCC の概要
KEKCC は B ファクトリー実験のデータの蓄積および解析を除いた、全ての KEK で行なわれる研究活動に利用するためのシステムである。研究分野は、素粒子・原子核実験、放射光実験、中性子実験、加速器開発、理論計算と多岐にわたっている。分野は異なっても利用形態やシステムに対する要求内容が共通する部分があるので、それをまとめてシステム構築を行なっている。しかし、同時に分野毎に異なる部分も少なくなく、システ
ムの構築と運用が難しくなっている面もある。
2009 年 3 月に導入した本システムでは、従来から KEK で行なわれている研究活動での利用に加えて、つくばから約 60km 北東にある茨城県東海村に建設された J-PARC 実験施設で行なわれる実験のデータの保管にも利用される。このデータは計算サーバで解析されるだけでなく、機構内の研究グループの計算機からのアクセスや共同利用者により大学の計算機との間でファイル転送が行なわれる。
システムの概要を表 3.1.5.1 および図 3.1.5.1 に示す。利用者が直接に利用するサーバの OS は Red Hat
Enterprise Linux 5(RHEL5)である。分散ファイルシステムは General Parallel File System(GPFS)で実現している。階層化ストレージは High Performance Storage System(HPSS)で管理している(詳細は後述)。ジョブ
は Platform LSF で管理しており、ワークサーバから計算サーバにジョブを投入する。機構外から KEKCC への
ログインはアクセスサーバを経由して、あるいは前もって登録されている特定のホストからはワークサーバに直接に SSH で行なう。GRID 環境は、LHC Computing GRID(LCG)、NAREGI ミドルウェアそれぞれで構築している。
Integrated Rule-Oriented Data System(iRODS)によるデータ管理環境も構築している。

磁気ディスク
階層化ストレージ
ワークサーバ
計算サーバ
並列サーバ
アクセスサーバ
GRID サーバ

表 3.1.5.1 KEKCC の構成要素とその概要
資源
ソフトウェア
機能
205TB
GPFS
ホーム領域およびデータ領域
3PB、10TB ステー HPSS
実験データの保存。ユーザインターフェイスは
ジング領域
API、pftp、VFS、SCP、iRODS、GRIDftp
IBMx3550 8 台、 RHEL5
ログインして、プログラム開発、ジョブの投入な
64CPU
どの作業を行う
IBMx3550 80 台、 RHEL5、LSF
LSF によりスケジューリングされたジョブを実行
640CPU
IBMx3550 4 台、 RHEL5
Gaussian 03 の並列処理に利用している
32CPU
2台
AIX
機構外からワークサーバにログインするための中
継サーバ
LCG、NAREGI、 GRID 環境から計算サーバ、階層化ストレージを
iRODS
利用する

32

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

共通計算機システム
計算サーバ
84 IBM System x3550
Intel Xeon-QX 5460 x2
メモリ 16GB/ノード

GPFS/API/VFS LSF
GRID システム
GPFS

API/VFS

LSF

GPFS
API/VFSLCG システム
Naregiシステム
iRODSシステム

GPFS

東海地区
J-PARC
Storages
HPSSデータサーバ
IBM TS3500（3PB）
IBM 3592 テープ装置
IBM DS4800（10TB）

API/FTP
CIFS/NFSv4

磁気ディスクシステム
IBM DS4800（205TB）
LTO4テープ装置

CIFS/NFSv4

ワークサーバ
4 x3550
Xeon-QX 5460 x2
メモリ 16GB/ノード

SSH

並列サーバ
SSH

4 x3550
Xeon-QX 5460 x2
メモリ 32GB/ノード

FW
FW

KEK 内

KEK-FW

SINET3SINET3

KEK内クライアント

図 3.1.5.1 KEKCC の概要図

(2)ストレージシステム
205TB の磁気ディスクシステムと総容量 3PB の階層型ストレージシステムがある。磁気ディスクシステムには、ホームディレクトリ領域および研究グループに作業用領域として配分する領域がある。ホームディレクト
リ領域は自動アックアップ機能により 2 重化されているが、作業用領域は希望のある場合にのみ自動アックア
ップの対象としている。階層型ストレージシステムは実験の生データや解析結果の保管場所として使われている。
(3)階層型ストレージシステム
階層型ストレージシステムは 10 台の IBM TS1130 磁気テープ装置を搭載した総容量 3PB の磁気テープが収納可能の磁気テープライブラリ、10TB のキャッシュディスク、およびソフトウェア HPSS により構成されている(図 3.1.5.2)。HPSS では一般的にデータの保存場所は磁気テープであり、磁気ディスクはキャッシュ領域として使われる。
C 言語で書いたプログラムからの入出力は API で行なう。アクセスの要求を core server に送ると、moverとクライアントの間でコネクションが張られデータの転送が行なわれる。
その他、各種のファイル転送のインターフェイスがあり、利便性と転送性能面から最適な機能を選択して利用する。Pftp は parallel ftp であり、クライアントから core server に接続要求があると、API の場合と同様にmoverとクライアントとの間でコネクションが張られてファイル転送が行なわれる。
高速処理のために、複数の mover との間で並列に転送を行なう設定が可能である。
Kftp は ftp の認証を kerberos で行なうものであり、core server を経由してファイル転送が行なわれる。
Linux では固有のソフトウェアの導入は必要なく、ディストリビューションに含まれる kerberos を導入して設定を行なえば利用できる。
HPSS ではファイルシステム・インターフェイスとして VFS が用意されている。利用者の作業用ノードであるワークサーバのうち 2 台には VFS が導入されており、このノードに対して SCP や SSHFS でアクセスしてファイル転送を行なうことができる。また VFS ノードに Samba サーバや NFS サーバを導入して、CIFS や NFS で VFS
経由のファイル転送を可能にしている。更に iRODS サーバや GRID サーバに VFS を導入して、iRODS や gridftpを用いて HPSS にアクセスできるようにした。
33

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書
Tape library: TS3500
3000vols,
max. 3PetaBytes
Tape drives: 10 3592E06
1TB/vol, 160MB/s
Cache disk
10TB
GRID server(VFS node)

5 movers

Core server

API, pftp

kftp

2 SMB/NFS servers(VFS node)
CIFS

Work servers(VFS node)

SCP

gftp

iRODS server(VFS node)

iput/iget

図 3.1.5.2 HPSS の概略図

(4)ストレージシステムの利用状況
図 3.1.5.3 は 2010 年度の、HPSS のデータ量とファイル数の月毎の増減の状況である。この図に示されているのは現システム導入後の HPSS データである。更に旧システムから移行した 120TB、70 万ファイルが保管されている。システム移行時に運用方針を変更したために、別の quota 管理となっている。
(TB)

(個)

500

2,500,000
データ量
ファイル数

400

2,000,000

300

1,500,000

200

1,000,000

100

500,000

0
年
10
20

0
2月

月
月
月
3月
4月
5月
6月
7月
8月
9月
1月
2月
3月
10
11
12
年
年
年
年
年
年
年
年
年
年
0年
0年
0年
10
10
10
10
10
10
10
11
11
11
0
0
0
0
0
0
0
1
1
1
0
0
0
2
2
2
2
2
2
2
2
2
2
20
20
20

図 3.1.5.3 磁気テープライブラリのデータ量(5)ストレージシステムに関する課題
ストレージシステムは KEKCC の根幹を成すものであるので、システムの構成を検討するにあたっては、信頼性、性能、運用の柔軟性に留意した。磁気テープ装置の信頼性、高負荷時にも安定して動作できる機器構成、全てのパスの二重化、運用中に動的に資源の割り当てが可能であること、ネットワーク経由でのアクセスに関するセキュリティなどを特に検討した。磁気テープの場合には書き換えを行なった結果できる無効領域の処理が必要である。HPSS では、リパック機能が低プライオリティでバックグラウンドで実行されるので運用への影響が無視できている。磁気テープの台数を十分に備えることは条件である。
ストレージシステムに対する要求が増大する中で、電力使用量、システム更新時のデータ移行が今後の重要な検討課題と予想される。

34

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

3.2 今後のシステムの強化ポイント
今後のシステムの強化ポイントを検討するにあたり、各サイトにおける現在のシステム状況を整理し、次期システムに向けて改善すべき点、注力すべき点について検討した。尚、各サイトでの検討に際して、事前に検討すべき項目について以下の通り決定した。
【検討項目】
データ生成パターン、ユーザ数、ノード数、システム設置面積、システム消費電力、ストレージ設置面積、ストレージ消費電力、ディスク物理容量、テープ最大収容容量、HSM 利用の有無、データ量、単 IO スルー
プット、Total スループット、単 IO レスポンス、Total レスポンス、データ信頼性、データ移行、セキュ
リティ、データ遠隔利用環境、システム運用継続性、運用面の工夫、システムへの要望、次期システムでの課題、可能性
各サイトにて検討した結果を表 3.2.1 に示す。
表 3.2.1 各システムのまとめ
組織名

JAXA調布JAXA調布

理化学研究所業務

数値シミュレーション（データ生成フェーズ）

可視化（データ解析フェーズ）

データ生成パターン※3
ユーザ数

連続型
約600
(アクティブユーザは100程度)
約3400

DB型
約600(アクティブユーザは10程度)

シミュレーション（データ生成フェーズ）・データ解析（データ解析フェー
ズ）
例示パターンは全部あり300名程度(登録)，50名程度(アクティブ)
1160程度

ノード数
システム設置面積2ストレージ設置面積

調布：320+850m
遠隔３事業所：2m 2 ×3
調布事業所：2100kVA,
遠隔3事業所：10kVA×3
調布事業所：約150 m2

ストレージ消費電力

調布事業所：330kVA

DISK物理容量

調布事業所：1.17PB
遠隔3事業所：36TB
調布事業所：10.6PB
遠隔３事業所：なし
SAM-QFSを利用
調布事業所：約500TB
遠隔３事業所：約9TB
write 750MB/s
read 1.5GB/s

システム消費電力

テープ最大収容容量
HSM利用の有無
データ量
単I/Oスループット

Totalスループット

write ?GB/s
read 28GB/s

単I/Oレスポンス
Totalレスポンス
データ信頼性未評価
未評価
DISK：RAID5
テープ：2copy
方法：メタデータ移行＆テープ媒体物理的移動
日数：３日程度
データ量：約70TB
データの所有権によるアクセスコントロール
SRFS on EthernetとHPSSにて遠隔地とデータ共有

データ移行

セキュリティ
データ遠隔利用環境

システム運用継続性
運用面の工夫システムへの要望

複数台ストレージサーバによる冗長化(手動切り替え)I/O長指定可能なcpコマンドによる高速コピー

4ノード(各事業所に１ノード)

調布：320+850m 2 、遠隔３事業所：？ 約135m 2

東京大学宇宙線研究所附属神岡宇
宙素粒子研究施設
データ解析（データ解析フェーズ）

連続型
約300人 (アクティブユーザは100程
度)
ジョブサブミット用10台、実行用270(4core/node)
約50m2 (30ラック＋机５台程度)

調布事業所： 2100kVA, 遠隔3 事業 887.2kVA(カタログピーク)
約200kW
所：？
調布事業所：約150 m 2 、 遠隔3 事業 約35m2
約25m2
所：？
調布事業所：？、遠隔3事業所：？ 93.2(54.7:DISK,38.5:TAPE)kVA(カタ ディスク56kW、 テープ17kW
ログピーク)
調布事業所：1.17PB、遠隔3事業所： 495TB(ローカルDISK総量)，
709TB
36TB
550TB(共有DISK)
調 布事 業所 ： 10.6PB 、遠 隔３ 事業 4PB(現状)，8PB(拡張予定)
547TB
所：なし
SAM-QFSを利用
HPSSを利用有り（VD-800）
調布事業所： 約500TB、遠隔３事業 1.4TB
観測生データ200TB、解析データ
所：約9TB
400TB
write 750MB/s、read 1.5GB/s
Peak: 300MB/s(Local DISK)，
317MB/s (read/write平均, 1080並
1.5GB/s(共有DISK)，
列、100MB/file)
120MB/s(Tape)write ?GB/s、read 28GB/s
Peak: 307GB/s (Local DISK)，
893MB/s (read/write平均, 1080並
12GB/s(共有DISK)，
列、100MB/file)
1.44GB/s(Tape)
未評価
評価していない
未評価
未評価
未評価
評価していない
未評価
未評価
DISK：RAID5、テープ：2copy
共有DISKはRAID6構成．Tapeは2重 ディスクRAID5
化
方法：メタデータ移行＆テープ媒体物 方法：repack
ディスク内全ファイル(約700TB)のコ
理的移動
日数：5ヶ月程度
ピーとテープ内の部分的なファイル
日数：３日程度
データ量：1.3PB(約200TB)のコピーが必要。
データ量：約70TB
データの所有権によるア クセスコント UNIX程度のアクセス制限
データの所有権によるアクセスコント
ロール
ロール
SRFS on Ethernetにて遠隔地とデー 遠隔利用可能なファイルシステムは SunRay2システムによって、デスク
タ共有
なし．Webサービス・インターフェース トップを柏キャンパスなどから高速に
HPSSにて遠隔地とデータ共有
によるデータ利用，ジョブ投入が可能 操作する。海外の共同研究機関へ
はリダクション後のファイルをscpなどで転送。
複数台ストレージ サーバによる冗長 複数ファイルサーバによる冗長化な サーバ３台にファイルシステムを分散化(手動切り替え)し(サーバーの冗長化はなし)
特になし。
ファイル・ステージング機能を併用
8MB I/Oでのコピー(rdasscp)、
C,FORTRANプログラムからの8MB
I/O用のAPI (RDASSライブラリ)
ユーザがインタラクティブに行う解析操作でも高速なレスポンスがほしい。ROOT、PAWなど。

次期システムでの課題
可能性35サイエンティフィック・システム研究会
組織名業務
データ生成パターン※3
ユーザ数

ノード数
システム設置面積
システム消費電力
ストレージ設置面積
ストレージ消費電力
DISK物理容量
テープ最大収容容量

HSM利用の有無

データ量

単I/Oスループット
Totalスループット

単I/Oレスポンス
Totalレスポンス
データ信頼性
データ移行

セキュリティ
データ遠隔利用環境

システム運用継続性

運用面の工夫システムへの要望
次期システムでの課題

可能性

国立天文台
すばるアーカイブ
格納はバースト型。解析はＤＢ型。
10年累積で700弱のアカウント。
ここ１年の間に利用されたアカウントは187。
運用系は専用ノードが12台(ハワイ５、三鷹７)
ハワイにラック１本
三鷹にラック２本
ハワイで28kW、三鷹で9kW（ストレージは除く）
ラックはハワイに6,三鷹に4
テープアーカイブ各1
ハワイ15kW。三鷹5kW。
ハワイに 100TB 三鷹に 90TB
(いずれも RAID6)
各サイトとも現行40TB。
テープを追加すれば非圧縮最大165TB。
無し

大規模ストレージ WG 成果報告書

国立天文台
公開アーカイブ格納は多種混在。解析はＤＢ型。
200名程度。

国立天文台
データ解析システム
連続型
120(アクティブは10程度)

高エネルギー加速器研究機構
データ解析
連続型
500

50台程度。

端末12,サーバ14+6,管理ノード

センターに88、ユーザ所有が数100

ラック３本＋買いとり分

サーバがラック3本,ユーザ端末14200m 2 以下

18kW＋買いとり分

27kW

200kVA以下

ラック３本＋買いとり分

ラック６本

MSS 10 m 2 + 磁気ディスク 4 m2

8kW＋買いとり分
17kW
200TB 強80TB
（レンタルと買い取り分の合計）
現行は100TB程度。最大までテープを増やすと 325TB。

MSS 16kVA + 磁気ディスク 4kVA
205TB
3PB

今期は無いが大量の差分更新が必 無し。システムやログのバックアップ HPSS
要なためHSMが無いと不便。次期は 目的ではHSM 不要。
検討。
現 時 点 で ハ ワ イ に 36TB 、 三 鷹 に 約100TB。
定期的に削除されており、2011年春 現在約300TB
27TB。2013 時点で はハワイで 50時点での利用率は30%前後。
80TB と予想。
特にNFSが遅い。
未評価
ネットワークの許容範囲によるのが現状
現行、ヒロ三鷹転送 2MB/s が特に
NFSが体感的に遅い。
ネットワークの許容範囲によるのが待ちな し 。 将 来は 300GB/night(〜
現状
平均 10MB/s)の書き込み必須。
特にNFSが絡むと遅い
未評価
ネットワークの許容範囲によるのが現状
ユーザ提供時にス テ ージ ング に転 遅い。システム運用継続に従い耐え NFSが絡むと遅い。
ネットワークの許容範囲によるのが送。実質的に不自由無し。
難くなる。
現状
RAID6。将来も同程度以上が必要。 RAID5。
RAID5、一部RAID6。
RAID, 磁気テープは高信頼性ドライブ＆媒体を選択必須。 2013 年時点で の移行量は、 必須。前回の移行は半年以上もか データ移行はユーザ任せ。移行時に 今回入れ替え時の方法は：repack
各サイトごと 40-80TB （典型的には かって大変。
半月程度の期間同時設置可能だと 次期入れ替え時については検討課
70TBを予想）。
良い。
題HTTP BASIC 認証
Firewall とノード個々に ipfilter。
特に考慮せず。Firewallの内側でssh UNIXレベルの ACL
ログインを許可。
ハワイ－三鷹間でのデータ転送に加 ユーザは ftp で取得する形態が主。 DMZ に置いたゲートウェイマシン経 東海- つくば間: HPSS(API, pftp,
え 、利用者は外部か ら proxy 経由
由の ssh ログインを許可。
Kerberos ftp), CIFS
HTTP/HTTPS でデータを転送。
その他：HPSS, grid ftp, iRODS
三鷹、ハワイの２箇所でデータ保管し 例えばパッチ適用等で年に１度、数 月に一度定例メンテナンス。
アクセスパスの2重化運用。必ず一方は動いている事が必 日の停止は許容できるが、１週間の要。月１回メンテナンス。
サービス停止は不可。
パッチやバージョンアップ前に必ず試監視の自動化の推進、ファイルの自 JPARC(東海), 大学からのデータアク
験系でテスト。
動削除、ユーザの成果報告書の提 セスの容易さ、インターネット経由で出義務。
のセキュアな環境の構築
ハードの耐障害性。
ソフトの安定性と性能。
電力、空調がネックになる可能性あ
りデータ移行期間のシステムの設置
場所
SSD は価格面、信頼性の面

でいつ頃検討対象になりうるか？

36サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

さらに、上述した各システムの現状を踏まえた上で、今後、どのポイントについて強化すべきかについて検討した。各サイトでの強化ポイントについて、表 3.2.2 に示す。
表 3.2.2 強化ポイントのまとめ
組織名
業務

JAXA調布
可視化

ユーザ数
ノード数
システム設置面積
システム消費電力
ストレージ設置面積
ストレージ消費電力
DISK物理容量
テープ最大収容容量
HSM利用の有無
データ量

JAXA調布
数値
ｼﾐｭﾚｰｼｮﾝ
○
○
○
◎
○
◎
★
◎
○
◎

○
○
○
◎
○
◎
★
◎
○
◎

理研
ｼﾐｭﾚｰｮﾝ
ﾃﾞｰﾀ解析
○
◎
○
△
◎
△
◎
◎
◎

単I/Oスループット
Totalスループット
単I/Oレスポンス

★
◎
-

○
○
★

◎
◎
-

Totalレスポンス
データ信頼性
データ移行
セキュリティ
データ遠隔利用環境
システム運用継続性
運用面の工夫

○
◎
◎
◎
◎
◎

◎
○
◎
◎
◎
◎
◎

○
◎
○
-

東大宇宙線研
データ解析

国立天文台
すばる
ｱｰｶｲﾌﾞ
○◎◎(2～3倍程度以上)
△
○
○
○
○
○
○
○
○
◎(2～3倍程度以上)★
◎(2倍程度)◎○◎(生データ40○50TB/◎
年)◎(同程度以上)★(５倍程度以上)★
◎(高速なls, mv, rmな
どあると良い)
◎
○
○
★
○
○
○
○
◎（サーバの冗長化）
○
○
○

国立天文台
公開ｱｰｶｲﾌﾞ

高エネ研
ﾃﾞｰﾀ解析

◎
○
○
○
○
★
◎
◎
◎

国立天文台
ﾃﾞｰﾀ
解析ｼｽﾃﾑ
○
○
◎
★
○
★
○
○

◎
◎
◎

◎
★
◎

◎
◎
-

★
○
★
○
○
○
-

◎
○
○
○
○
○
○

★
○
★
★
○

◎
○
○
○
○
◎
◎
◎
-

★:注力すべきポイント◎:現在より強化すべきポイント○:現在と同等でよいポイント△:現在より弱くてよいポイント－:不要なポイントあるいは評価していないポイント

検討の結果、今後のシステムの強化ポイントとして、ストレージのスループットと容量が重要な要素であることが各サイト共通の認識として捉えられている。また、レスポンス、バックアップ、リビルド時間、およびデー
タ移行についても今後の重要な課題であるという意見が多く挙がっていた。

37

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4 大規模ストレージにおける課題とその対策10年先のエクサ世代にも対応できるファイルシステムを目指して取組むべき課題の中から、
大容量化、
高速化、
運用について本 WG の中で検討した結果を報告する。

4.1 大容量化
計算ノードの総数、総コア数や搭載されるメモリ量は益々増加する傾向にある。その結果、必要な総 IO スルー
プットも増大し、ファイルシステムの主流が「SAN 共用ファイルシステム」から「ネットワーク経由のファイルシステム」に変わり、ファイルサーバも単一サーバ型からクラスタ化へと変わりつつある。

ネットワーク共有

FC共有

計算ノード
（高性能SMP）

計算ﾉｰﾄﾞ
ｸﾗｽﾀ化

クラスタ型ファイルシステム

計算ノードクラスタ（~数千ノード）

計算ノードクラスタ（~数万ノード）

ネットワークSW
FC SW

ネットワークSW
ファイル
サーバ

ﾌｧｲﾙｻｰﾊﾞ
ｸﾗｽﾀ化

FC SW

ファイルサーバ群
ファイル
サーバ

帯域：~数十GB/s
容量：~数PB

帯域：~数百GB/s
容量：~数100PB

図 4.1.1 大規模ストレージ向けファイルシステムの方向性

4.1.1 ハードウェア
一次ストレージの大容量化への対応はディスクの容量と数によって決まる。ディスクドライブの容量は前述のとおり 1.5～2 年で 1.5～2 倍となっているが、システム更改時の要求容量は性能と同様に 10～100 倍と大幅な乖離がある。従ってディスクドライブの数が大幅に増え、設置面積・消費電力・空調能力・コストといった問題を引き起こしている。
設置面積の改善としては高密度実装による対応が考えられるが、データセンターの床耐荷重・電力供給・空調を合わせて対策する必要がある。消費電力の削減については高効率電源の採用やコントローラ部分の小型化、冷却用ファンの削減や回転数を細かく制御することによる電力削減がある。ただ、ディスクドライブについては、その種類によって消費電力は決まっており、ディスク数に比例して消費電力が増える。将来的には SSD(Flash ドライブ)に移行することにより大幅な消費電力の改善が期待される。
現時点ではドライブ単体での消費電力の削減
効果は約 50%であるが、容量あたりでは約 150%となりかえって増えてしまうことになる。これは SSD の容量の少なさが要因であり、今後 SSD の大容量化により、容量あたりでも消費電力の改善が期待されている。
バックアップやアーカイブ用途のストレージでは、一次ストレージとは異なり大容量・低価格・省スペース・
省電力などが求められる。それらのニーズに対応する新しい技術として Thin Provisioning(図 4.1.1.1)やDe-duplication(図 4.1.1.2)といった機能が提供されており、従来のテープメディアに代わるものとして注目を集めている。これらの技術はいずれもディスクメディアを使用するが利用効率の向上によりコストを削減しながら、オンラインアクセスを確保することが出来、ユーザ利便性を向上させることを可能にしたものである。また
一部のファイルシステムではストレージのエコモード(MAID 技術)を利用できるものもあり、アクセスのない時間
帯でディスクドライブの回転を止めることによる消費電力の削減という方法も考えられる。

38

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

図 4.1.1.1 Thin Provisioning

図 4.1.1.2 De-duplication
一方でアクセス頻度の極端に低いデータの格納領域として保管コストの観点でテープメディアを使った HSM な
どのニーズもある。多くのユーザでは利便性の観点でディスクメディアを使いたいという意向があるものの、コスト観点でテープメディアを選択せざる得ない状況となっている。
テープメディアとしてはLTO(Linear Tape Open)が実質的な業界標準となっている。現在は第 5 世代が出荷されているが、第 8 世代までロードマップ(図 4.1.1.3)が示されており長期にわたって使用できるものとなっている。

出荷開始年

2000 年

2002 年

2004 年

2007 年

2010 年

2012 年(予定)

図 4.1.1.3 Ultrium ロードマップ(出典:LTO コンソーシアム)

39

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.1.2 ソフトウェア
ここでは、ソフトウェアによる大容量化への取組みとして下表に示す内容について述べる。
表 4.1.2.1 大容量化への取組み
分類
大規模化

ファイルサイズ
ファイルシステム規模施策
10年後にはエクサバイト（EB）へ⇒ EBのサイズに対応

スケーラビリティ

性能
容量

ハード増設で性能・容量がスケールアウト⇒ ２年で５～１０倍のペースでup

使い易さ

動的なハード増設
運用状態の監視運用中にディスクやサーバの増設が可能
稼動状態の見える化 ⇒監視・チューニングを容易に(1)大規模化
演算速度の高速化が進むと単位時間あたりのデータ量が増加してより高い IO 性能が必要になり、また搭載
メモリ量の増大が進むとトータルデータ量が増加してより大容量のストレージが必要になる。数年後のファイルシステムは現状の 100 倍規模の性能・容量が必要になると予想でき、TB/s 級のファイル性能と EB 級のファ
イルシステム規模やファイルサイズへの対応が必須である。
演算性能
ファイル性能ディスク容量スパコン構成現状
100 テラフロップス
10GB/s1PB

100倍

数年後のターゲット
10ペタフロップス~
1TB/s~
100PB~

計算ノードクラスタ（~数千ノード）

計算ノードクラスタ（~数万ノード）

ネットワークSW
ネットワークSW

ファイル
サーバ

ファイルサーバ群
FC SW
フ ァイル
サーバ

ファイルサーバ

ネットワーク共有型

クラスタ型

図 4.1.2.1 ファイルシステムの大規模化(2)スケーラビリティ
多数のファイルサーバ群を束ねるクラスタファイルシステムでは、並列化によりスループット性能をスケー
ルアップ、台数増により容量をスケールアップでき、原理的にはサーバ・ストレージ台数に比例して性能・容量をスケールアップすることが可能である。
サーバ増設
ネットワーク増設

ディスク増設（HDD，RAID装置）

図 4.1.2.2 スケーラビリティ
40

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(3)使い易さ(a)動的なハードウェア増設
大規模ファイルシステムでは、運用を止めることなくファイルサーバやディスクを増設できることが必要である。
同じファイルシステム内に異なる性能のファイルサーバや異なる容量のディスク装置が混在していると、性能のばらつきや空き容量の偏りが生じる。システムとしての性能と容量のバランスを保つためには、増設元と同じ構成・容量のファイルサーバ・ディスク装置を増設する必要がある。
サーバ増設
サーバ増設
運用継続

同一構成を増設

ディスク増設
ディスク増設・サーバ＋RAID装置

運用継続

同一容量を増設
・RAIDグループ単位
・RAID装置単位

図 4.1.2.3 動的ハードウェア増設(b)運用状態の監視システム管理者が想定した運用が行えているかどうかを、簡単に監視できる手段が必要である。全体の稼働状況が一目で分かるように見える化できること、その結果を元にチューニングが容易にできること、異常な IO を出しているユーザを特定できることが求められる。
表 4.1.2.2 運用状態の監視
対象
負荷 サーバネットワークディスク
ディスク容量
統計情報

内容
負荷の偏り（CPU，メモリ）
通信量の偏りIO量の偏りアクション
・統計情報から原因調査
・QoS設定変更

・ジョブ運用ポリシィ見直し
空き容量の偏り
・格納先の優先度を調整
クライアント・ユーザ単位に取得 ・悪さをしているユーザを特定・指導・ディスクIO量（IOサイズ別）
・メタ操作数（open回数等）

41

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.2 高速化
4.2.1 ハードウェア
ストレージの性能はストレージに使用されるドライブ種とその数によってほぼ決まる。そのため、高速ドライブの採用と分散処理が高速化の基本となる。
ドライブの動向としては2.1章にも触れたようにSSD(Flashドライブ)が高速化のキーとなることが予想されている。小 IO サイズでのリード処理ではオンラインディスクに比べ 50 倍以上の性能が出るが、大きな IO サイズでの連続したライト処理を 1 多重で実効した場合はオンラインディスクとほぼ同等という性能特性を持っている。
ただし、同一 SSD へのアクセスが増えると 4 倍程度の性能となるためより多くの IO 処理が行われる環境では効果が出やすいと考えられる。また、性能が出しにくい数 KB 程度の小サイズの IO については SSD による性能向上の効果はより大きくなる。
分散処理についてはハードウェアでのストライピングだけでなくファイルシステムでの対応も解決方法の 1 つとなる。
一次ストレージ装置に求められる性能を満たすためには、最先端のインターフェースやドライブの採用と共にコントローラ部分のスループット性能向上が不可欠である。そのために最新のプロセッサ、メモリ、バスといったコモディティー素材をいち早く取り込むことと、チェックコード生成機能付きのプロトコルチップなどのストレージ装置特有の専用部品については関連ベンダーと並行開発による早期の製品化と安定化を図る取り組みが必要となっている。

42

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.2.2 ソフトウェア
ここでは、ソフトウェアによる高速化への取組みとして表 4.2.2.1 に示す内容について述べる。
表 4.2.2.1 高速化への取組み
性能向上

分類
メタデータアクセス

TSSレスポンス保障

施策①SMPによりハード増設（CPU等）で性能スケールアップ②MPI-IO対応（ファイル数減⇒メタアクセス緩和）③メタアクセスの分散化
TSSノードの要求に対する帯域保障

小サイズIO・多数ファイル クライアントキャッシュ（データ，属性）
ディスク性能超え運用ポリシー選択 フェアシェア
（センター運用）
総スループット優先
安定したジョブ実行
輻輳防止
動的フロー制御

サーバキャッシュ（大容量キャッシュ）一人の悪行が他人に迷惑をかけることを防ぐ（QoS）
帯域を最大限有効利用（ベストエフォート）
ジョブ実行時間のバラツキを抑える
サーバ能力を最大限に引き出す動的なフロー制御(1)性能向上(a)メタデータアクセス
Lustre などクラスタ型ファイルシステムでは、多数サーバを並べることで台数に比例して高スループットを実現できるが、メタデータサーバ(MDS)は 1 台のサーバで管理するため負荷が集中する。このため、大規模システムでは特に MDS の性能向上が重要である。
メタデータアクセスの高速化としては MDS をクラスタ化する考え方があるが、現状では MDS 単体の性能を使い切る状況にないことから、本 WG では「高性能 SMP サーバの活用」、「メタデータアクセスの緩和」、「メ
タデータアクセスの分散化」について検討した。
・高速 SMP サーバの利用
メタデータサーバの単体性能を高めるアプローチである。CPU やメモリ、ネットワークなどハードウ
ェアの増設によりタアクセス性能をスケールさせる。現状は、図 4.2.2.1 に示すようにソフトウェアネ
ックにより性能ピーク時にもハードウェアを使いきれていない状況にある。

図 4.2.2.1 ソフトウェアネックによる MDS 性能の頭打ち43

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

・メタデータアクセスの緩和使用するファイルの数を減らすことでメタデータサーバへのアクセスを緩和するアプローチである。
多数ある計算ノードがそれぞれ別々のファイルにアクセスすると、計算ノードの数に比例して MDS へのアクセスが増える。MPI-IO など一つのファイルを計算ノード全体で共有してアクセスすることで、計算ノード数によらずファイル数が増えないため、ファイルアクセス時の MDS アクセスを一定に保つことができる。

非共有ジョブ
非共有ジョブ

共有ジョブ
共有ジョブ

逐次・バルクジョブ

MPI-IOジョブ

計

計

・・・

計

計

小サイズ・多数ファイル↓
メタアクセス：多

計

・・・

計

大サイズ・少数ファイル↓
メタアクセス：少図 4.2.2.2 共有ファイルによるメタデータアクセス削減
・メタデータアクセスの分散化
ファイルシステムを分けることでメタアクセスを分散化するアプローチである。
一番シンプルなのは、
現行システムでも一般的に行っているファイルシステムを分ける方法である。分割数、すなわちメタデータサーバの台数に比例してシステム全体としてのメタデータのアクセス性能が向上する反面、分割するファイルシステム数分のメタデータサーバが必要になることや、名前空間が分かれるなど使い勝手が低下するデメリットがある。
上記を改善する方法として、ユーザ単位やジョブ単位、ノード単位などファイルを共有する範囲・用途に応じてファイルシステムを動的に構成する考え方があり、メタデータアクセスを分散化しつつ、利便性を高めるアプローチの一つになると考える。
(b)TSS レスポンス保障
共有ファイルシステムは、計算ノード側からのバッチジョブによるファイル IO に加えて、利用者が TSS
ノード(ログインノード)からファイルにアクセスする運用が考えられる。バッチジョブからの共有ファイ
ルシステムへのファイルアクセスにより、ログインノードからの TSS レスポンスが低下する課題がある。
施策として、TSS ノードに対する IO 帯域とジョブ用の IO 帯域を分離し、TSS ノードへの IO 帯域を常時確保しておくことで、利用者に安定したレスポンスで共有ファイルを利用させることができる。
ログインノード

Job
Job
Job
Job

ユーザ間で
フェアシェアTSS用IO帯域
全IO帯域
ジョブ用IO帯域

計算ノード

図 4.2.2.3 TSS レスポンス保障

44

ファイル
サーバ
（MDS/OSS）

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(c)小サイズ IO・多数ファイル
・小サイズ IO の性能向上
小さい IO 長によりアクセスが行われた際に、そのつどクライアントからサーバに通信していたのではオーバーヘッドが多く IO 性能が低下する。
施策として、クライアントキャッシュ上で複数の小 IO を束ね、IO 長を拡大して IO 回数を削減することで IO 性能を向上させることができる。

クライアントキャッシュなし
クライアントキャッシュなし

クライアントキャッシュあり
クライアントキャッシュあり

クライアント
ユーザアプリ

ユーザアプリクライアントキャッシュ

1KBx1000回

1MBx1回サーバ

ディスク

図 4.2.2.4 クライアントキャッシュによる小サイズ IO の性能向上
・小サイズ・多数ファイルの性能向上(クライアントキャッシュ)
サイズが小さい多数ファイルへのアクセスでは、ファイルサーバへのアクセスコストが IO 時間に占める比率が高くなり、これがオーバーヘッドとなって IO 性能が低下する課題がある。
施策として、データの実体に加えてメタデータをクライアントでキャッシュすることで、クライアン
トからサーバへの IO 発生を抑えて性能を向上させることができる。実現例として、共有ファイルシス
テム上のファイルを計算ノードでループバックデバイスとしてマウントする方法があり、図 4.2.2.5 に示すように性能が向上することを実験レベルで確認した。

IOzone no-direct WRITE, file size 4KB

IOzone no-direct READ, file size 4KB
900ext3 on Lustre
Lustre250

Throughput[MB/s][MB/s]
Throughput

Throughput[MB/s][MB/s]
Throughput

300

200

性能
向上

150
100
50
0

ext3 on Lustre
Lustre

800
700
600
500

性能
向上

400
300
200
100
0

0

1

2

3
4
5
6
Number of clients

7

8

9

0

1

図 4.2.2.5 ループバックデバイスの適用例

45

2

3
4
5
6
Number of clients

7

8

9

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(d)ディスク性能超え(サーバキャッシュ)ファイルシステムのボトルネックはディスク装置であるが、サーバキャッシュを使うことでディスク性
能を超える IO 性能を実現できる。サーバキャッシュにはディスクへの書き込みを保障しない「ライトバック型」と、ディスクへの書き込みまで行う「ライトスルー型」がある。前者の例には SRFS、後者の例にはLustre がある。
・ライトバック型(SRFS 型)
書き込まれたデータはサーバのキャッシュに載せてディスクへの書き込みを待たないため、Read/Write
共に高速化できるメリットがあるが、サーバダウン時にサーバキャッシュ上にあるディスクに書き込まれていないデータは消失するデメリットがある。
・ライトスルー型(Lustre 型)
書き込まれたデータはサーバのキャッシュに載せると共にディスクに書き込みを行うため、高速化されるのは Read のみだが、サーバダウン時に Write が保障されるメリットがある。データ保障と性能を考慮してどちらを使用するか決める必要がある。

SRFS型
SRFS型

Lustre型
Lustre型

クライアントクライアントWrite backWrite through

サーバ

サーバ

大容量キャッシュ

大容量キャッシュ

非同期write

同期writeディスク装置ディスク装置
図 4.2.2.6 サーバキャッシュ46

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(2)運用ポリシー選択
多数の利用者が共同で利用するセンター運用では、1 ユーザによる大量のファイルアクセスにより他の利用者のレスポンスが低下したり、特定ジョブによる大量のファイル IO により他ジョブの実行時間がばらつくといった問題が発生している。
このため、センターの運用方針に応じて、特定ユーザの IO が他の利用者に影響を与えないようにするなど、
QoS の運用ポリシーを選択できる仕組みが求められている。以下に本 WG で検討した QoS について報告する。
なお、(a)(b)の運用ポリシーは、管理者がシステムの利用状況をチェックして手動で切り替えることに加え、利用ユーザ数やサーバー・ネットワーク負荷などシステムの状況に応じて動的に制御できることが望ましい。
(a)フェアシェア
ユーザ単位に一定の IO 資源を割り当てて制限をかけることで、1 ユーザの大量の IO がシステム全体に影響を与えないようにする運用である。各ユーザが一定の IO 資源を安定して利用できる半面、ユーザが少ない場合には IO 資源が空いてしまうデメリットがある。

1ユーザ
1ユーザ

フェアシェアなし
フェアシェアなし
複数ユーザ
複数ユーザ

IO帯域

ユーザA

多量なIO

ユーザA

他ユーザに
悪影響

ユーザB
ログイン ノー ド

ファイ ルサーバ

フェアシェアあり
フェアシェアあり
複数ユーザ
複数ユーザ

1ユーザ
1ユーザ

ユーザA
ユーザA
ユーザB

ユーザAが使える
最大帯域

各ユーザが均等に帯域を 使用

図 4.2.2.7 フェアシェア
(b)総スループット優先(ベストエフォート)
帯域全体をクライアントで分かち合って使用することで、ディスクや通信資源を空きなくユーザやジョブに割り当て、IO 資源を最大限に有効利用させる運用である。IO 資源全体を活用できる反面、クライアン
トノード数に反比例して各クライアントの資源が少なくなる。
1ノードが全IO資源を使用
1ノードが全IO資源を使用
IO帯域

サー
ーバ
バ
サ

11

クライ アン ト
1ノー ド

1サーバ

複数ノードで全IO資源をシェア
複数ノードで全IO資源をシェア
クライ アン ト
複数 ノー ド

全IO帯域

複数
数サ
サー
ーバ
バ
複
複数サーバ

図 4.2.2.8 ベストエフォート

47

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(c)安定したジョブ実行
ユーザごとにジョブが使えるハードウェア資源(サーバ、ディスク、ネットワーク)を割り当てる運用と、ジョブ単位にユーザに直接さわらせないジョブ専用のローカルディスク領域にファイルを転送(ステージン
グ)する運用がある。両者を組み合わせることで、より安定したジョブ実行を期待できる。
後者はユーザが利用する共用保存域とジョブが使用する一時域でファイルシステムを分ける運用を前提としている。共用保存域にはジョブ用の入出力データや実行ファイル、スクリプト等を格納し、ジョブ実行前に必要なファイルを一時域に転送(ステージイン)し、ジョブ完了後に出力ファイルを共用保存域に転送(ステージアウト)する運用モデルである。
現状ではユーザがステージングで転送するファイルを指定する必要があるが、システム側でジョブが使用するファイルを識別して自動的にファイル転送するなど、利便性の観点からユーザにステージングを意識させない施策が望まれる。
計算ノードクラスタ
ジョブA

ジョブB
ネットワーク分離
サーバ・ディスク分離

ジョブBの使用範囲

ジョブAの使用範囲

図 4.2.2.9 ハードウェア資源の分離によるジョブばらつき抑止

ログインノード（TSS）

アクセス禁止

共用保存域

計算ノードクラスタ（バッチジョブ）ステージング

ジョブ用一時域

図 4.2.2.10 ステージングによるジョブばらつき抑止(3)輻輳防止(動的フロー制御)
クライアントからファイルサーバの性能を超える IO 要求が発生すると、再送による輻輳が発生してファイ
ルシステムの性能が大幅に低下する。全クライアントからのメタデータ処理を行うメタデータサーバでは特に発生する危険性が大きく、システム全体に与える影響も大きい。このような輻輳を防止するため、動的なフロー制御により常にサーバが最大性能を発揮できる状態を維持することが重要である。
施策例としては、サーバ側で受信可能な要求数と、クライアントが送出可能な要求数を相互にカウントし、
クライアント・サーバ各ノードがそれぞれ与えられた要求数の範囲内で送受信を行うクレジット方式がある。
最大性能を超えるIO要求が発生しないよう制御

IO性能

この範囲で使用

IO要求数

図 4.2.2.11 動的フロー制御

48

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.3 運用
大規模ストレージにおいては、ストレージの大容量化、高速化だけでなく、ストレージの運用の観点においてもいくつかの課題が挙げられる。本項では、各サイトにおいて重要な課題と捉えられている「バックアップ」
、
「リ
ビルド」
、
「データ移行」、および「高可用性」について課題とその対策について検討を実施した。

4.3.1 バックアップ
大規模ストレージにおいては、ストレージ容量の検討とあわせてデータの保管をどのように行うかということについて検討する必要がある。本節では大規模ストレージにおけるバックアップの課題および今後の対策につい
て示す。

(1)課題
データの保管方法として、以下の 3 つのパターンが挙げられる。
・物理バックアップ:二次メディアに対する完全なバックアップを取得。物理障害からデータを保全。
・論理バックアップ:ある時点のファイルシステムのスナップショットを取得。
論理障害からデータを保全。
・データ移動:保存すべきデータを一次領域から保存領域へ移動。データ保全ではない。
各サイトでは、データ種別(観測データ／解析データ／ソースファイル等)やデータ容量、運用ポリシー等を基にデータの保管方法を決定しており、現状では物理バックアップが一般的に行われている。そのため、今後のストレージ容量の増大に比例してバックアップ機器の規模(コスト、電力、設置場所)も増加するため、今後の大規模ストレージにおいては、いかにバックアップデータ量を抑えるかが課題となっている。

(2)今後の対策
バックアップデータ量の削減という課題に対して、現状、以下の対策が挙げられる。
・論理バックアップ(スナップショット)
・De-Duplication の導入
・運用(バックアップ世代数/頻度の削減、バックアップ対象の限定、ユーザ自身でのバックアップ)
ただし、上述の対策においては、それぞれメリットとデメリットが存在する。
論理バックアップでは処理時間や運用性という面でメリットがある半面、データが完全保全ではないため、観測データ等のバックアップ先として運用するのはリスクがあり、採用されにくいのが現状である。
また、De-Duplication の導入ではデータ保全や運用性の面でメリットがあるが、他の解決策と比較して新規にシステムを導入することから、コスト面や運用面を考慮する必要がある。
さらに、サイトによっては、ユーザデータの大容量化に伴い、システム管理者側で全てのデータをバックアップすることはバックアップ先の確保やバックアップ時間、コストの面において限界にきているケースがある。
そのため、信頼性やエンドユーザへのサービスレベル低下とのトレードオフとなるが、バックアップ世代数／頻度の削減や例えばホーム領域や希望ユーザのみ実施するといったバックアップ対象の限定を実施するということが運用面での対策の一つとして考えられる。また、データバックアップの要・不要が判別できないため、バックアップ用の領域を別途用意し、ユーザ自身にて必要データをバックアップしてもらったり、システムとしてはテンポラリーな作業領域という位置づけで特定領域を公開するといったこともひとつの解となりうる。
上述の通り、今後のデータ量削減への対策としては明確な対策が存在しておらず、それぞれの対策のメリット／デメリットを踏まえ、データ種別や各サイトの運用ポリシーに応じていくつかの対策を組み合せ、サイト独自の最適なバックアップ運用を検討していく必要がある

49

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.3.2 リビルド
本章では大規模ストレージシステムにおけるリビルドの課題および今後の対策について示す。

(1)課題
ディスク障害に対する運用継続性と信頼性確保の手段として RAID 技術が一般的となっているが、ディスク障害に伴う RAID のリビルド処理が長時間化してきている。
リビルド処理時間は、ディスクの単体性能、ディスクの単体容量、RAID 種とストライプ量といった要素に依存する。
参考例として、以下に富士通製ディスク装置 ETERNUS DX80 でのリビルド処理時間を示す。
【ETERNUS DX80、ディスク単体容量 1TB(7200rpm)、RAID6(4D+2P)】
・無負荷時: 約 18.5 時間
・業務 IO 100[IOPS]時: 約 81.5 時間
尚、リビルド処理中にはレスポンスが約 15%程度悪化する。
今後、単体容量が 2TB や 3TB といったディスクが登場してきた場合、他の条件が同じであれば、リビルド処
理時間はほぼディスク容量比で増加していく。リビルド時間の長時間化に伴い、リビルド中のレスポンス悪化の長時間化や別ディスクでの障害発生(ダブルフォルト)といったリスクもあわせて増加していく。

(2)今後の対策
リビルド処理においては、ディスク障害発生後にあらかじめ用意されたホットスペアディスクにデータを復元し(リビルド)、障害発生ディスクの交換後、ホットスペアディスクから交換後のディスクへのデータ書き込
み(コピーバック)が実施される。リビルド処理時間の短縮化として、上述のコピーバックを行わず、交換したディスクを新規にホットスペアディスクとして認識させることが考えられる。しかし、この場合にはディスク交換に伴いホットスペアディスクのポジションが変わっていくため、保守が困難となるため、コピーバックをはずすことができないのが現実である。
なお、
主要なストレージベンダーの製品においても同様となっている。
そのため、運用における具体的な対策として、1RAID での性能低下の影響を局所化するようにファイルシス
テムを構築することが挙げられる。1 ファイルシステムを全 RAID でストライプした場合にはファイルシステ
ム全体に影響が発生するため、1 ファイルシステムを複数の RAID グループで構築することにより、該当 RAIDに存在するファイルだけが影響を受けるように局所化することが可能である。
現在のところ、リビルド処理の長時間化に対する根本解決策は見つかっていない状況であり、当面は運用において影響範囲を狭めることが現実解となっている。リビルド時間の長時間化は、実際のストレージ運用において必ず直面する問題であり、早々に根本的な対策が見出されることが望まれる。

50

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.3.3 データ移行
データ移行期間の見積もりは、運用を開始するための重要な要素である。しかしながら、各研究機関のデータの生成状態やシステムの仕組みにより、データ移行期間の見積もりに幅がある。
本章では本 WG にて調査したデータ移行方法とデータ移行期間および、今後の課題と対策について報告する。

(1)背景
現在のデータ移行では、研究機関により最大数ヶ月のデータ移行期間を要した。各研究機関にて次期システ
ムを考慮する場合、データ生成状態とデータの質により移行方法がことなる場合がある。
そこで、研究機関のデータ生成状態から、大規模ストレージでのデータ移行の状況をまとめ、課題と対策を検討することとなった。
(2)研究機関ごとのデータ移行状況
表 4.3.3.1 に研究機関ごとのデータ移行状況をまとめた。表中の[テープ→テープ]は物理移動を示し、[テープ→ディスク]は、ネットワークを媒体としたデータの移動を示す。[ディスク→ディスク]も[テープ→ディスク]と同様である。
表 4.3.3.1 より、旧・現システムにおいて、ファイルシステムに互換性がある場合、媒体の物理的な移動やリパック等により短期間(数日間)に移行できる。しかしながら、ファイルシステムに互換性がない場合、旧・現システムをネットワークにて接続し、NFS+cp/tar、rsync 等によりデータ移行を実施しており、この場合においてはデータ移行期間が長期化(数ヶ月間)する。
その他に、データ検証が必要な場合は、データ転送期間に加え sum コマンド等による転送元と転送先のデー
タの一致性を確認のためデータ移行期間が長期化する。また、移行データ量がすくなくてもファイル数が多い
場合もデータ移行期間が長期化する。
表 4.3.3.1 データ移行の状況
機関名

移行データ量移行方法
移行日数(旧→現システム)
JAXA 調布 旧→第一期システム
・旧システムおよび第一期システムともに SAM-QFS
数日間(3 期に分け移 約 70TB[テープ→テープ]
・メタデータ移行＋テープ媒体の物理的移動(LTO1 媒体は行を実施)
LTO3 ドライブにて読み込み、書き込みは LTO4 ドライブ)第一期→第二期システム
・第一期システムと第二期システムを併設し、N/W 経由でのコピー
数日間
約 10TB[ディスク→ディスク] (rsync 3 多重で実施)
理化学研究所 約 1.3PB[テープ→ディスク] ・新旧システムともに HPSS
数ヶ月間
1 ファイルの容量が小さなデー・新旧システムを併設(ネットワークに接続)。コアサーバを新システムのコタも多数存在する
アサーバに切替後、旧システムのムーバ、テープドライブ等を新システムの一部に組み込み、リパックを実施(データは N/W 経由で移行)
東京大学
約 320TB[テープ→移行用ディ・移行用として NAS 環境を用意し、テープ装置から NAS 領域上にデータをコ 数ヶ月間
宇宙線研究所 スク→ディスク]ピー(hpsscat コマンド)。データ検証後、NAS 領域から新システムのディ
スクに N/W 経由でコピー(NFS+cp)。
国立天文台 すばるアーカイブ(三鷹)・移行用サーバ(3 台)を用意し、テープから移行用サーバのディスクに N/W 数ヶ月間
約 16TB[テープ→移行用ディ 経由でコピー(scp)。移行用ディスクから新システムのディスクへの移行
スク→ディスク]は 3 並列で N/W 経由でコピー(NFS+tar)。
データ解析システム
・移行は各ユーザで実施。
数ヶ月間
約 1TB[ ディスク→ディス・移行用のデータ環境(NAS)を用意し、移行用サーバに NFS マウント。各ユク](ホーム約 400GB、テンポラ ーザにて旧システムから移行用サーバに対して、ftp、fcp、rsync にて必
リ約 600GB)
要なデータを移行(テンポラリ領域は併設期間終了後、約 3.5 ヶ月間、ユーザ公開後、利用停止)
高エネルギー 約 328TB[テープ→テープ] ・新旧システムともに HPSS
数日間加速器研究 ①現テープ:約 200TB
・媒体の移動＋テープのリパック(HPSS)機構②新テープ:約 128TB[補足]天文台(公開アーカイブシステム)
データ移行に加え DB 移行も実施。DB 設計/移行検討(互換性/移行手順)、性能チューニングを実施し、移行日数は半年以上。
JAXA 調布(第一期システム→第二期システム)
第二期システムは、第一期システムと第三期システムの橋渡しシステムのため、表 4.3.3.2 では対象外とする。

51

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(3)各研究機関ごとのストレージ容量と次期システムへの最低データ移行期間
情報提供いただいた各研究機関の現行システムのストレージ容量より、次期システムへのデータ移行期間を算出した。
算出条件として、
現システムと次期システム間のデータ転送の隘路はネットワークと定義、転送能力は50MB/sとし、現システムの主データを次期システムに移行すると設定した。その結果を、表 4.3.3.2 に示す。
この結果から、データは増加の一途をだどっており、最低データ移行期間が長期化していることが解り、移行データ量の削減を含め、どれだけデータ移行期間を短縮できるかが大きな課題である。

研究機関名
JAXA 調布
理化学研究所東京大学宇宙線研究所
国立天文台

高エネルギー加速器研究機構

表 4.3.3.2 ストレージ容量とデータ移行期間
現システムのストレージ容量
最低データ移行期間
ディスク: 1PB
データ量:10PB
テープ : 10PB
移行期間:6.5 年間
ディスク: 1PB
データ量:4PB
テープ : 4PB
移行期間:2.6 年間
ディスク:709TB
データ量:709TB
テープ :547TB
移行期間:5.5 ヶ月間
すばるアーカイブ(三鷹)
データ量:80TB
ディスク: 80TB
移行期間:0.7 ヶ月間
テープ : 40TB
公開アーカイブ
データ量:200TB
ディスク:200TB
移行期間:1.6 ヶ月間
テープ :100TB(最大 325TB)
データ解析システム
次期システムではデータ移行は行わないた
ディスク:80TB
め、対象外。
データ解析システム
データ量:3PB
ディスク:205TB
移行期間:2 年間
テープ : 3PB

(4)最低データ移行期間の長期化に対する対策
前項の課題に対して、ハードウェア/ソフトウェア/運用/次世代テクノロジの観点で対策案を検討した。その結果を、表 4.3.3.3 に示す。
表 4.3.3.3 データ移行の対策
観点
項
対策
ハードウェアでの対策案
1.1 ・移行時のネットワーク帯域を増強する。
(GbE を複数本利用し帯域と多重度を確保する。ファイル数が多い場合、
ファイルサイズが小さい場合を考慮し想定帯域 50MB/s と規定)
・移行用テープドライブを増強する。
1.2 ・新システムでの De-Duplication 装置を適用する。
1.3 (データ移行は bit copy(OPC、EC))
ソフトウェアでの対策案
2.1 ・媒体の物理移動/リパックにて対応する。
(現・次期システムでのファイルシステムの互換性が必要)
2.2 ・NFS V4 を活用する。
(複数のネットワークにてデータ移行用のプロセスを多重実行する)運用での対策案
3.1 ・期間を削減するために、データ量を削減する。
(不要データの削減をうながす。ディスク課金をする。)
3.2 ・テープ→ディスク の移行を ディスク→ディスク に変更しデータ移行の速度を向上させる。
3.3 ・現行運用中にテープ媒体を次世代媒体に変更する。
(データ格納容量を向上させる。テープ巻数を削減する。)
次世代テクノロジでの4.1 ・OSD(Object Strage Device)を適用する。
対策案
表 4.3.3.1 を分析し対策案を検討した結果、データ移行方法について表 4.3.3.3 のデータ移行対策を導くことができた。また、ネットワークを経由したデータ転送の場合、表 4.3.3.2 にあるようにデータ移行期間が長期化することも分かった。

52

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

表 4.3.3.3 の施策をそれぞれの機関の特徴に合わせ適用した場合、表 4.3.3.4 にあるように、概ね 8 ヶ月以
内でデータ移行が完了できることが分かった。
それぞれの見積もりの方法と見積もり条件の概要を以下に示す。
[JAXA 調布]
表 4.3.3.3 の対策 1.2、2.1、3.3 を適用した。3.3 の方法にて、現システムにて媒体を 2 世代新しい
ものに変換(データの読み込みは LTO4→データの書き込みを LTO6)する。現システムの LTO4 の 25%(10ドライブ)利用し、LTO6 を新規に 10 ドライブ増設し占有できると規定した。また、移行用のディスク領
域は十分にあると規定した。データの移動は、LTO4 の規格より 10PB の LTO4→ディスク に 3.3 カ月間。
LTO6 の規格より ディスク→LTO6 は 1.5 ヶ月間かかる。また、10PB の容量のテープ巻数は 2500 巻となる。現システムから次期システムへのテープの移動は、1 日 250 本と規定した。上記期間を加算し、データ移行期間は、5.2 ヶ月間とした。
[理化学研究所]
表 4.3.3.3 の対策 1.2、2.1、3.3 を適用した。3.3 の方法にて、現ステムにて媒体を 2 世代新しいものに変換(データの読み込みは LTO4→データの書き込みを LTO6)する。現システムの LTO4 の 25%(3 ドライブ)利用し、LTO6 を新規に 3 ドライブ増設し占有できると規定した。また、移行用のディスク領域は十分にあると規定した。データの移動は、LTO4 の規格より 4PB の LTO4→ディスクに 4.3 ヶ月間。LTO6の規格よりディスク→LTO6 は 2.0 ヶ月間かかる。また、4PB の容量のテープ巻数は 1000 巻となる。現
システムから次期システムへのテープの移動は、1 日 250 本と定義した。上記期間を加算し、データ移
行期間は、6.5 ヶ月間とした。
[東京大学宇宙線研究所]
表 4.3.3.3 の対策 1.2、2.2、3.2 を適用した。2.2 の方法にて、現行システムに新システムから NFS
にてマウントを実施する。NFS のネットワークは複数のネットワークを利用できると定義する。ネット
ワークを経由したデータ転送は 50MB/s と規定する。移行データはディスク上にあるものと規定する。
データ移行期間は、709TB／50MB/s にて 5.5 ヶ月間とした。
[国立天文台](すばるアーカイブ)
表 4.3.3.3 の対策 1.2、2.2、3.2 を適用した。2.2 の方法にて、現行システムに新システムから NFS
にてマウントを実施する。NFS のネットワークは複数のネットワークを利用できると定義する。ネット
ワークを経由したデータ転送は 50MB/s と規定する。移行データはディスク上にあるものと規定する。
データ移行期間は、80TB／50MB/s にて 0.7 ヶ月間とした。
(公開アーカイブ)
表 4.3.3.3 の対策 1.2、2.2、3.2 を適用した。2.2 の方法にて、現行システムに新システムから NFS
にてマウントを実施する。NFS のネットワークは複数のネットワークを利用できると定義する。ネット
ワークを経由したデータ転送は 50MB/s と規定する。移行データはディスク上にあるものと規定する。
データ移行期間は、200TB／50MB/s にて 1.6 ヶ月間とした。
[高エネルギー加速器研究機構]
表 4.3.3.3 の対策 1.2、2.1、3.3 を適用した。3.3 の方法にて、現ステムにて媒体を 2 世代新しいものに変換(データの読み込みは LTO4→データの書き込みを LTO6)する。現システムの LTO4 の 25%(2 ドラ
イブ)利用し、LTO6 を新規に 2 ドライブ増設し占有できると規定した。また、移行用のディスク領域は十分にあると規定した。データの移動は、LTO4 の規格より 3PB の LTO4→ディスクに 4.9 ヶ月間。LTO6の規格よりディスク→LTO6 は 2.3 ヶ月間かかる。また、3PB の容量のテープ巻数は 750 巻となる。現システムから次期システムへのテープの移動は、1 日 250 本と規定した。上記期間を加算し、データ移行
期間は、7.3 ヶ月間とした。
53

サイエンティフィック・システム研究会

研究機関名
JAXA 調布
理化学研究所東京大学
宇宙線研究所
国立天文台

高エネルギー
加速器研究機構

大規模ストレージ WG 成果報告書

表 4.3.3.4 施策を適用した現システムからのデータ移行期間
現システムの実施 最低データ移行期間
最低データ移行期間
ストレージ容量
施策 (施策実施後の理想値)(施策実施前)
ディスク: 1PB
1.2 データ量:10PB
データ量:10PB
テープ : 10PB
2.1 移行期間:5.2 ヶ月間
移行期間:6.5 年間
3.3
ディスク: 1PB
1.2 データ量:4PB
データ量:4PB
テープ : 4PB
2.1 移行期間:6.5 ヶ月間
移行期間:2.6 年間
3.3
ディスク: 709TB
1.1 データ量:709TB
データ量:709TB
テープ : 547TB
2.2 移行期間:5.5 ヶ月間
移行期間:5.5 ヶ月間
3.2
すばるアーカイブ(三鷹) 1.1 データ量:80TB
データ量:80TB
ディスク: 80TB
2.2 移行期間:0.7 ヶ月間
移行期間:0.7 ヶ月間
テープ : 40TB
3.2
公開アーカイブ
1.1 データ量:200TB
データ量:200TB
ディスク: 200TB
2.2 移行期間:1.6 ヶ月間
移行期間:1.6 ヶ月間
テープ : 100TB
3.2(最大 325TB)
データ解析システム
1.2 データ量:3PB
データ量:3PB
ディスク: 205TB
2.1 移行期間:7.3 ヶ月間
移行期間:2 年間
テープ : 3PB
3.3

54

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

4.3.4 高可用性
数百台規模のファイルサーバ・ストレージ装置で構成する大規模なファイルシステムでは、常にどこかのハードウェアが故障している状態が予想される。このような状況下でもファイルシステムには運用を止めることなくサービスを継続することが求められ、ハードウェアおよびソフトウェア両面での施策が必要である。以下にハードウェアおよびソフトウェアによる各アプローチについて示す。

(1)ハードウェアの二重化
クライアントノードからストレージ装置までのデータ経路上にあるハードウェア各所において、単点故障のないハードウェア構成を取ることで、片系が故障した場合に他方に切り替えることで単点故障を迂回する。
以下に例を示す。
・ネットワーク :ネットワークパス(IB、IB-SW)の二重化
・ストレージ:ディスクパス(FC、FC-SW)、RAID コントローラの二重化、RAID によるデータ保護
・ファイルサーバ:ファイルサーバ(MDS/OSS)の二重化

計算
ノード

計算
ノード

IB SW

MDS
（運用）

MDS
（待機）

計算
ノード

ネットワークパス
二重化

IB SW

OSS
（運用）

OSS
（運用）

サーバ二重化
ディスクパス
二重化

RAID

RAID

メタデータサーバ
(MDS)

RAID

RAID構成データサーバ(OSS)

図 4.3.4.1 ハードウェアの二重化(2)ソフトウェアによる交替・リカバリ制御
ソフトウェアでは、上述した二重化したハードウェアを利用し、ハードウェア故障の検出と運用系と待機系の切り替え、切り替え後のリカバリ処理を制御する。
Lustreでは、
キャッシュやバッファ上のデータが残っていても故障によるデータ消失を発生させないため、ジャーナリングに加えてプロトコルレベルでのリカバリの仕組みを取り入れている。ファイル IO 時にサーバ・クライアント間のトランザクション処理のログを両者で記録し、サーバ・クライアント間でアトミック性が必
要なひとまとまりの処理が完了するまでログを保持する。ファイルサーバやネットワークがダウンして交替先に切り替えた後に、ログに基づいて未完了の処理を再開・リトライすることでクライアントからの IO 処理を正常に完了させる。
以上のように、ハードウェアの二重化とソフトウェアによる交替・リカバリの制御により、ハードウェア故障が発生した場合でもファイルシステムのサービスを継続し、ユーザやアプリケーションのファイル操作を正常に完遂させ、信頼性と高可用性を実現することができる。

55

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

図 4.3.4.2 ソフトウェアによる交替制御

56

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5 ファイルシステム健康診断
ファイルシステムの検討を行なう際に、ファイルシステム性能は非常に重要な要素である。しかし、ファイルシステムに関する汎用的なパフォーマンスアナライザは存在せず、個別で対応しているのが現状である。本章では本 WG にて検討したファイルシステムの汎用的な健康診断について報告する。

5.1 背景現在、大規模ストレージの計測に適したファイルシステム性能測定の共通的なツールは存在せず、システムごとに個別で性能測定ツールを作成して性能評価を行なっている。さらにこれらはファイルシステム固有の操作が必要となる場合があり、他ファイルシステムでのファイルシステム性能測定結果と比較することが難しい。
そこで、本 WG において測定ツール、測定項目をモデル化し、そのツールを使った測定結果を元に、大規模スト
レージシステムの特性を簡易に診断する方法を検討することとなった。

5.2 目的以下の二点を短時間でかつ汎用的に測定できる事を目的とする。
①導入システムの健康診断システム管理者によるシステム導入時に狙った性能が出ているかを調べる②運用中の定期健康診断
運用中におけるユーザ視点における性能レンジの把握。運用性能を測定する
このため診断ツールによる健康診断においては、以下の項目に着目して測定する。
・最大スループットバンド幅(キャッシュヒット性能)・最小スループットバンド幅(ボトルネック部分の性能。ネットワークやディスク性能など)
・レスポンス性能

5.3 診断モデル(1)導入システムの健康診断
モデルは以下とする。
・最大スループットバンド幅性能
Write 直後の Read 性能。データはクライアントキャッシュ上にある事を想定
・最小スループットバンド幅性能
Write 後に fsync を掛けキャッシュは全て実ストレージデバイスへ転送される事を想定
・メタデータアクセス
キャッシュの有無は考慮しない(キャッシュ管理をブラックボックステストでは制御不可能なため)

図 5.3.1 診断ツールによる測定モデル57

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(2)運用中の定期健康診断
実運用中に本診断ツールを定期的に動作させ、状態把握を可能とする。この場合ユーザ視点の観点から最大性能(キャッシュヒット性能)を採取する事を想定している。しかし運用時の測定においてはシステム構成に
より過負荷を掛け運用に悪影響を与える事があり得る。
このため測定ツールを定期的に動作させるためにはシステム管理者による十分な事前確認と必要であれば測定ツールのカスタマイズ(測定規模縮小など)を行うこと。

図 5.3.2 診断ツールによる運用中測定モデル(3)精密検査
ファイルシステム性能を測定する場合、ファイルシステムにはクライアントキャッシュ、サーバキャッシ
ュが存在することが多く、単純に測定をおこなったのでは、キャッシュに対する IO なのか、ディスクに対す
る IO なのか区別が付かない。またファイルシステムごとにクライアントキャッシュ、サーバキャッシュのク
リア方法は異なり、ファイルシステムによってはサービスの停止が必要なものもあり、共通の測定を汎用的に行なうことが困難である。
本診断ツールは、健康診断より詳細なテストが可能なように考慮されているが、キャッシュの影響を排除した上で Read におけるストレージデバイスの性能を測定するために、以下のいずれかの前処理を診断ツール
内のスクリプトに各システムで追記して測定する。
・Write 後に一旦クライアント・サーバすべてからファイルシステムを umount する・クライアントやサーバのメモリ量の数倍のデータ量を読み込む
・ファイルシステム固有のキャッシュ廃棄処理を行う

図 5.3.3 診断ツールによる精密検査

58

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5.4 診断項目
前述の通りファイルシステム性能には大きく分けて二つの観点がある。一つはデータ転送の性能であるスルー
プット性能であり、もう一つはファイル操作の性能であるレスポンス性能である。
スループット性能に関しては、・流体・分子力学計算等で見られるファイルサイズ、IO 長が大きい場合・遺伝子・たんぱく質解析等に見られるファイルサイズ、IO 長が小さい場合の 2 点に着目し、レスポンス性能と合わせて、計 3 点の観点で診断を行う。
この3 点について、
IO 長、
プロセス数(並列数)をシステム設計時に想定した範囲でパラメタとして測定を行う。

(1)大規模データ転送(スループット性能:プロセス当たりのファイル量一定、大 IO 長)
モデル :プロセス数とデータ量が比例＝解析モデルと計算量が比例
着眼点 :多数プロセスからの多数ファイルへの一斉アクセスで性能を有効に使える範囲
一般的にソフトウェア・ハードウェアの性能キャパシティを大幅に超える IO リクエストが発生すると、データ輻輳が発生しはじめ、性能が劣化し得るため、適正なシステム負荷範囲を評価する
期待値 :IO 長、プロセス数増加に比例して性能(転送量／単位時間)は増加
システムキャパシティの上限に達した後は一定
性能劣化:IO 長、プロセス数が想定したシステムキャパシティを超える前に劣化
単位時間転送量

単位時間転送量

期待値
性能劣化

IO 長

期待値
性能劣化

ﾌﾟﾛｾｽ数

図 5.4.1 着眼ポイント(大量データ転送)(2)データ量一定(スループット性能:小ファイルサイズ、小 IO 長)
モデル :1 ジョブで解析対象は一定、並列数のみ増(並列度が上がるとジョブ内 1 プロセス当たりのファイルが小さくなる)
着眼点 :並列化を進めファイルが細分化されていくが、並列化効果が期待できる範囲
一般的にファイルが小さくなり数が増えると、データ転送コストよりも Open/Close などの制御オー
バヘッドが大きくなりシステム負荷が増大していく。
この増大が漸増であれば大きな問題ではないが、一定以上の負荷を超えるとシステム資源の奪い合いが発生して極端な悪化が発生し得るため、負荷がどの範囲で適正かを評価する。
期待値 :IO 長、並列度に比例して性能(転送量／単位時間)は増加
システムキャパシティの上限に達した後は一定
性能劣化:IO 長、並列数が想定したシステムキャパシティを超える前に劣化
単位時間転送量

単位時間転送量

期待値
性能劣化

IO 長

期待値
性能劣化

並列(ﾌﾟﾛｾｽ)数

図 5.4.2 着眼ポイント(データ量一定)

59サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

単位時間(3)メタデータアクセス(レスポンス性能)
モデル :プロセス数とメタデータアクセス数が比例
着眼点 :1 ジョブから数百～数千のファイルに対し stat、touch、rm を頻発させてもシステム性能を引き出せる範囲
メタアクセスへは一定量を超えると待ち制御が入るため IOPS(Input Output Per Second)は漸減す
るのが一般的であるが、システム資源の奪い合いや輻輳を引き起こした場合には極端に性能が劣化する可能性があるため、適正な負荷範囲を評価する。
期待値

IO
数

性能劣化

プロセス数
図 5.4.3 着眼ポイント(メタデータアクセス)60

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5.5 診断クラス
システムのスループット性能が数十 GB/s にも及ぶ大規模システムと、
ワークステーション程度のシステムで同じ測定を実施すると、測定に何日も必要としてしまうことが想定されるため、システムの規模に応じて、プロセス並列数などのパラメータを変更することを検討した。
システム規模の想定とモデルのクラス分けは以下の通り。

クラス
XL
L
M
S

規模
超大規模
大規模
中規模
小規模

表 5.5.1 システム規模とクラス
理論スループット
最大
最大ディスク
(オーダ)
プロセス数
使用量
100GB/s
1000
1TB
10GB/s
100
100GB
1GB/s
10
10GB
100MB/s
5
5GB

最大
ファイル数
1,000,000
100,000
10,000
5,000

システム
次世代マシン
センタマシンセクションマシン
個人マシン

次にファイルシステムの測定項目とパラメータの検討を実施した。各クラス間で性能比較を行なうことができるよう各クラスに 1 プロセスでの測定を設定した。また、測定の精度と測定時間のバランスを考慮し、大規模データ転送、データ量一定、メタデータアクセスの測定が一時間で完了することをターゲットとした簡易測定項目を設定した。各測定項目とパラメータは以下の通り。

クラス
XL
L
M
S

クラス
XL
L
M
S

クラス
XL
L
M
S

タイプ
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定

表 5.5.2 大規模データ転送の性能測定パラメータ
プロセス数
転送データ量IO 長1000,500,100,50,10,5,1
1GB/プロセス
100KB,1MB,10MB,100MB,1GB
1000,1
100,50,10,5,1
1GB/プロセス
100KB,1MB,10MB,100MB,1GB
100,1
10,5,1
1GB/プロセス
100KB,1MB,10MB,100MB,1GB
10,15,1
1GB/プロセス
100KB,1MB,10MB,100MB,1GB
5,1

タイプ
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定

表 5.5.3 データ量一定の性能測定パラメータ
プロセス数
総ファイル量IO 長1000,500,100,50,10,5,1
1GB, 100MB
100KB, 10KB, 1KB
1000,1100MB
100KB, 1KB
100,50,10,5,1
1GB, 100MB
100KB, 10KB, 1KB
100,1
100MB
100KB, 1KB
10,5,1
1GB, 100MB
100KB, 10KB, 1KB
10,1
100MB
100KB, 1KB
5,1
1GB, 100MB
100KB, 10KB, 1KB
5,1
100MB
100KB, 1KB

タイプ
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定
全測定
簡易測定

表 5.5.4 メタデータアクセスの性能測定パラメータ
プロセス数
総ファイル数 or ディレクトリ数
1000,500,100,50,10,5,11000 ファイル or ディレクトリ/プロセス
1000,1
100,50,10,5,11000 ファイル or ディレクトリ/プロセス
100,1
10,5,11000 ファイル or ディレクトリ/プロセス
10,1
5,11000 ファイル or ディレクトリ/プロセス
5,1

61

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5.6 診断ツール
本測定で使用する診断ツールには以下の条件が必要であると考えた。
・オープンソースソフトウェア(OSS)であること
本ファイルシステム性能評価ツールは、誰でもそのツールを取得して測定を行なうことが出来ることを考慮し、OSS である必要がある。
・導入が簡単であること
Red Hat Enterprise Linux 等の一般的な OS において、source の修正等を行なう必要がなく、configure、
make、make install の一般的な方法でシステムに適用可能である必要がある。
・MPI によるプロセス並列に対応していること大規模なストレージシステムの性能を評価するためには、逐次プロセスからの測定ではファイルシステムの総合性能を測定することが出来ないため、
MPIによるプロセス並列に対応したツールである必要がある。
・必要な測定ができるツールであること
ファイルシステム性能評価を行なうために必要な測定が行なえるツールである必要がある。スループット
性能測定では、IO 長とファイルサイズが変更可能であること、レスポンス性能測定では、ファイル、ディ
レクトリの create、stat、unlink ができること、各プロセスごとに別々のディレクトリに出力できることが挙げられる。
上記の条件を元に検討した結果、ファイルシステム性能測定(診断)の際に使用するツールとして、スループッ
ト性能は IOR、レスポンス性能は mdtest で行なうこととした。MPI は普及している OSS の MPI ソフトウェアである OpenMPI を使用することとした。各ソフトウェアの概略は以下のとおり。

名称
OpenMPI

Version
1.4.2

MdtestIOR

1.8.3
2.10.2

表 5.6.1 診断ツール概要
備考
最も普及している OSS の MPI ソフトウェア。
ただし、測定対象システムに既に MPI 環境が整備されている場合は不要。
ファイルの操作(create、stat、unlink 等)の応答性能を評価するツール。
データ転送性能を評価するツール。IO 長やファイルサイズ等が指定可能。

IOR、mdtest はオプションが多数存在しており、上記パラメータに対する測定を行なうだけでも、オプションの意味を理解し、パラメータを設定しなければならない。また、パラメータごとにオペレーションが必要となる
ため、非常に手間がかかる。そこで、測定項目の統一と、測定の自動化を目的として、IOR、mdtest を使用して簡単に性能を測定するためのラッパースクリプトの作成を行なった。
以下に本ツールで使用した IOR、mdtest のオプションの意味と、本ツールで設定するオプションおよびその値を以下に示す。(※各測定は 2 回行い、その平均値を診断する)オプション名-a [API]-b [num]-F-i [num]-o [filename]-r-t [num]-w

表 5.6.2 IOR 使用オプション一覧
内容
Default 値
API を指定。POSIX、MPIIO、HDF5、NCMPI が指定 POSIX可能。
総転送データ量を指定。単位はバイト。
1MBそれぞれのプロセスが別々のファイルに IO。
なし
測定を[num]回繰り返す。
1
IO する対象ファイル名を指定。
testFile
Read 性能測定を実施。
なし
IO 長を指定。単位はバイト。
256KB
Write 性能測定を実施する。
なし

62

設定値
POSIX
測定パターンに依存あり
2
測定パターンに依存あり
測定パターンに依存ありサイエンティフィック・システム研究会

オプション名-d [dirname]-i [num]-n [num]-p [num]-u-v

大規模ストレージ WG 成果報告書

表 5.6.3 mdtest 使用オプション一覧
内容
Default 値
出力先のディレクトリ指定。
空白
測定回数を指定。
1
出力ファイル/ディレクトリ数を指定。
0
測定間の wait 時間を指定
0
各プロセスが別々のディレクトリに出力。
なし
詳細表示
なし

本診断ツールの運用は以下のとおりとする。
・診断ツールは SS 研会員限定で公開
・診断ツール自体のサポートはベストエフォートで対応

63

設定値
MDTEST
2
1000
3
あり
あり

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5.7 診断例
最小性能(ストレージデバイスへのアクセス)とレスポンス性能をピックアップした診断例を示す。

単位時間転送量

単位時間転送量(1)宇宙航空研究開発機構(調布)・システム設計方針
大ファイル・大 IO 長、多数プロセスでのバンド幅を重視したシステム。
アプリケーションからの IO 長は MB 単位を想定しファイルシステムブロックサイズは 1MB に設定。
大量データ転送
大量データ転送
方針
方針

IO 長

プロセス数

・診断
設計方針通り、1 ファイル 1MB 以上での多数プロセスによるアクセスに適切。注意点は以下。
－同時にファイル stat を行うジョブは 50 プロセス未満とすべき－ファイル／ディレクトリの create/remove は 100 プロセス同時実行がピークで以降は頭打ち・測定時間
約 6 時間図 5.7.1 宇宙航空研究開発機構(調布) 大規模データ転送

図 5.7.2 宇宙航空研究開発機構(調布)
データ量一定(データ量 1GB)

図 5.7.3 宇宙航空研究開発機構(調布)
データ量一定(データ量 100MB)
64

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

メタデータアクセス(ファイル)

10000
100

1000

File creation
File removal
File stat

10

100
10

1

1
1

5

10

50

100

500

stat(1秒当たりの操作数)

1000

creation/removal(1秒当たりの操作数)100000

プロセス数

1000000
100000

1000

10000
100

1000

50プロセス以上で性能劣化

10

Directory creation
Directory removal
Directory stat

1
5

10

50

100

500

プロセス数

図 5.7.4 宇宙航空研究開発機構(調布)
メタデータアクセス(ファイル)

図 5.7.5 宇宙航空研究開発機構(調布)
メタデータアクセス(ディレクトリ)

65

100
10
1

1

1000

10000000

100プロセスで
頭打ち傾向

10000
1000000

stat(1秒当たりの操作数)

100プロセスで
頭打ち傾向

10000

creation/removal(1秒当たりの操作数)

メタデータアクセス(ディレクトリ)
10000000

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(2)理化学研究所
・システム設計方針
小頻度大 IO から多頻度小 IO まで幅広く高いレンジで安定したバンド幅性能を出す。
ブロックサイズは 64KB に設定。
方針

IO 長

データ量一定方針

単位時間転送量

単位時間転送量

単位時間転送量

大量データ転送

大量データ転送
方針

プロセス数

プロセス数

・診断
－データアクセスは設計方針通りの性能を発揮。プロセス数や IO 長を意識せず使用可能。
－ファイル操作系ではファイル stat を同時に 50 超発行するジョブでは性能劣化がある点に注意。
・測定時間
約 1 時間半

図 5.7.6 理化学研究所 大規模データ転送

図 5.7.7 理化学研究所
データ量一定(データ量 1GB)

図 5.7.8 理化学研究所
データ量一定(データ量 100MB)66

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

1000000
1000001000

10000
File creation
File removal
File stat

100

1000
100

10
10
1
5

10

50

100

500

50プロセス以
上で頭打ち1000000
1000

10000
100

Directory creation
Directory removal
Directory stat

プロセス数

1000
100

10

10
1
1

1000

10000000

100000

1

1
1

10000

5プロセス
時のみ突出

5

10

50

100

500

1000

プロセス数

図 5.7.9 理化学研究所
メタデータアクセス(ファイル)

図 5.7.10 理化学研究所
メタデータアクセス(ディレクトリ)

67

stat(1秒あたりの操作数)

50プロセス超で性能劣化

creation/removal(1秒あたりの操作数)

10000

メタデータアクセス(ディレクトリ)
10000000stat(1秒あたりの操作数)

creation/removal(1秒あたりの操作数)

メタデータアクセス(ファイル)
プロセス数に比例して増サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(3)国立天文台
・診断－IO 長やファイルサイズに関係なくほぼ一定性能(read/write とも)。
－write 性能はサーバ性能そのものであり、プロセス数やファイルサイズにはあまり依存しない。
・測定時間
約 1 時間図 5.7.11 国立天文台 大規模データ転送

図 5.7.12 国立天文台
データ量一定(データ量 1GB)

図 5.7.13 国立天文台
データ量一定(データ量 100M)

メタデータアクセス(ファイル)

メタデータアクセス(ディレクトリ)
10000000
10000

1000001000

File creation
File removal
File stat

100

10000
1000
100

10
10
1

1
1

5

10

50

100

500

1000

1000000
1000

Directory creation
Directory removal
Directory stat

100

10000
1000
100

10

10
1

1
1

プロセス数

100000

5

10

50

100

500

プロセス数

図 5.7.14 国立天文台
メタデータアクセス(ファイル)

図 5.7.15 国立天文台
メタデータアクセス(ディレクトリ)

68

stat(1秒あたりの操作数)1000000

creation/removal(1秒あたりの操作数)10000

stat(1秒あたりの操作数)

creation/removal(1秒あたりの操作数)10000000

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書(4)某研究所
・診断－10 プロセス以上による一斉アクセスでは性能劣化が見られる。
－このため本システムでの IO を一斉に行うジョブは数十プロセス程度に抑えて使用すべき。
－IO 長は気にせず使用可能。
・測定時間
約 2.5 日図 5.7.16 某研究所 大規模データ転送

図 5.7.17 某研究所
データ量一定(データ量 1GB)

図 5.7.18 某研究所
データ量一定(データ量 100M)
メタデータアクセス(ディレクトリ)

メタデータアクセス(ファイル)

10000000
10000

100000

1000

10000

File creation
File removal
File stat

100

1000
100

10
10
1

1
1

5

10

50

100

500

1000000
100000

1000

10000
100

Directory creation
Directory removal
Directory stat

10

プロセス数

100
10

1

1
1

1000

1000

5

10

50

100

500

1000

プロセス数

図 5.7.19 某研究所
メタデータアクセス(ファイル)

図 5.7.20 某研究所
メタデータアクセス(ディレクトリ)

69

stat(1秒あたりの操作数)1000000

creation/removal(1秒あたりの操作数)10000

stat(１秒あたりの操作数)

creation/removal(１秒あたりの操作数)10000000

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

5.8 最後に大規模ストレージシステムの特性を簡易に診断する方法として、ファイルシステム健康診断を提案しました。
皆様のシステムの不具合の中で、ファイルシステムの不具合は運用停止に直結する重要な課題です。
ファイルシステム健康診断は、単にファイルシステムの不具合を早期に発見するだけでなく、運用中のファイ
ルシステム状態を的確に把握し、その結果に基づいた現行ファイルシステム利用への助言や、次期システムへの反映等を実施し、エンドユーザが研究活動を健やかに行えことに資するものでなければなりません。そのため、定期的なファイルシステム健康診断が重要となります。
なお、本報告書の電子版とともに、ファイルシステム性能評価手順書を SS 研公開 Web サイトに掲載致します。
本情報がシステム不具合対策の一助になれば幸甚です。

70

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

6 今後に向けての提言
スーパーコンピュータの演算性能の向上や、観測機器・測定機器の高精度化・大型化により、近年、入出力データの大規模化が急速に進んだ。この急速な変化の中で、大規模ストレージの抱える課題の存在がぼんやりとではあるが一般に認識され始めている。一方、SS 研では、ストレージシステムの重要性を古くから認識し、精力的に活動を展開してきた。本 WG は、過去３回の SS 研でのストレージに関する WG 活動での広範な技術動向と課題の検討を受け、大規模ストレージに特化した技術課題と解決策について検討した。SS 研会員からは古くから大規模なストレージシステムの運用管理を行ってきた日本有数の組織の方々と、賛助会員からは単体デバイスからソフ
トウェアまで広範な分野にわたる第一線で活躍する方々が検討メンバとして参加した。ぼんやりと認識され始めた課題を、古くから問題意識をもつこれらメンバの議論を通して、少しでも鮮明化することで、世間一般の大規
模ストレージの議論を活発化させる一助となる成果を生み出すことが本 WG の大きな目的である。
検討の対象を大規模ストレージに絞ってはいたが、過去の WG の報告からも分かるように、ストレージのニーズや今後必要とされる技術は、組織のミッションやストレージシステムの位置付けによって各々異なるものとなる。
従って、本 WG ではひとつの共通解を出すことには拘らず、ユーザ、管理者、メーカ等それぞれの視点からの議論をする中で、ニーズの明確化、技術課題の明確化を行おうとした。この結果は、第 3.2 節にまとめられている。
WG の多くの時間はこの明確化作業に費やした。議論が進むうちに、明確化された６つの課題：「大容量化」、「高速化」、「バックアップ」、「リビルド」、「データ移行」、「高可用性」として整理されていった。
課題整理の次の段階として、課題への対策の検討を行い第４章にまとめたが、この章をまとめる際の WG での議論をここで簡単に紹介しておく。６つの課題のうち「大容量化」と「高速化」は、ハードウェアによる対策、ソフトウェアによる対策が具体的に提案できることが分かったが、「バックアップ」、「リビルド」、「データ移行」に関しては、同様な仕分けで対策を具体的に提案することが難しいという結論に至った。この結論に達する中で、これらの課題は「運用」の技術や方針で解決することが現時点では現実的な対策であるとの意見で一致し、同様の視点で整理可能な課題「高可用性」と共に「運用」の課題として再整理し課題認識と今後の対策を整理し直した。
技術課題の明確化と対策の提案に並行して、ストレージシステムと密接に関係するファイルシステムの検討に必要なファイルシステム性能測定に関するモデル化の議論を行い第５章に「ファイルシステム健康診断」という診断ツールの提案としてまとめた。
このように、本 WG の成果物としての報告書は完成した。しかし、いくつかやり残したと考えている点もある。
先に対策検討の議論を紹介したが、この議論を通して、あらためて現在のストレージシステムにおいて、「運用」
がとても重要な要素であることを再認識し、より深い検討が必要であると感じた。また、「ファイルシステム健康診断」ツールを提案したが、ツールの評価は使われ始めてから行われるものであり、その意味で現時点は出発点に立っていると言える。今後、このような点を含めた、ストレージシステムの議論が SS 研で継続的に行われることを期待している。
稿を終えるにあり、担当幹事松澤先生の的確な WG の議論の方向付けと、SS 研事務局の WG 運営に対して感謝の意を表すると共に、WG メンバとオブザーバの熱心な活動に敬意を表したい。また、本報告書が、大規模ストレー
ジの議論を活発化させる一助となることを願っている。

71サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

付録72

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

資料(1)海外スパコンシステムにおけるストレージシステムの動向

1

2

3

4

5

6

73

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

7

8

9

10

11

12

74

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

13

14

15

16

17

18

75

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

19

20

21

22

23

24

76

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

25

26

27

28

29

30

77

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

31

32

33

34

35

36

78

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

37

38

39

40

41

42

79

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

43

44

45

46

47

48

80

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

49

50

51

52

53

54

81

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

55

56

57

58

59

60

82

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

61

62

63

64

65

66

83

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

67

68

69

70

71

72

84

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

73

74

75

76

77

78

85

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

資料(2)高性能ファイルシステムの紹介

1

2

3

4

5

6

86

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

7

8

9

10

11

12

87

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

13

14

15

16

17

18

88

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

1989サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

資料(3)高速化・大容量化に向けた課題と対応について(ストレージ機器編)

1

2

3

4

5

6

90

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

7

8

9

10

11

12

91

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

13

14

15

16

17

18

92

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

19

20

21

22

23

24

93

サイエンティフィック・システム研究会

大規模ストレージ WG 成果報告書

25

26

27

28

94

【発行者】サイエンティフィック・システム研究会【編 集】サイエンティフィック・システム研究会 大規模ストレージＷＧ【発行日】2011 年 5 月 13 日
◆ ◆ ◆
＜連絡先＞
サイエンティフィック・システム研究会 事務局〒105-7123 東京都港区東新橋 1-5-2 汐留シティセンター
TEL : 03-6252-2582、FAX : 03-6252-2798
E-mail : office@ssken.gr.jp
URL : http://www.ssken.gr.jp/MAINSITE/※著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。