電話 03-6410-6070、FAX 03-6410-6073 電子メール ｉｎｆｏ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ / ｓｕｐｐｏｒｔ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ (アドレスは半角に変更して利用)
HPC-ProFS DPvMD3200i
HPC-ProFS DPvMD3220i
ストレージ統合を実現する高速・大容量なiSCSI システム
3.5インチドライブを12個搭載できるDPvMD3200iと
2.5インチドライブを24個搭載できるDPvMD3220iをラインナップ
姉妹製品のDPvMD1200シーズの追加により最大96ドライブまで拡張可能
４個のGbEポートを持つRAIDコントローラを最大２枚搭載可 (8x GbE)
最大３２台のサーバと接続ができる
RAIDコントローラとGbE接続ポートが冗長化でき高い可用性を実現
高機能な統合システム管理ツールを持ちストレージ管理が簡単
既存のHPCクラスタのストレージ統合を支援するSIサービスを提供
３年間の当日４時間オンサイト保守と技術支援を実施
「集中型ストレージ」から「分散型ストレージ」へ
HPCクラスタの高速化に対応しストレージの世代交代
信頼性、速度、容量、経済性を同時実現
HPCクラスタに必要不可欠な「共有ストレージ」
HPCクラスタを正常に動作させるためには、入力データ、計算結果データ、ソースコード、実行バイナリ、開発環境、ネットワーク情報、共有アプリケーションなどを安定して利用できなければなりません。「共有ストレージ」はこれらのファイル類を集中管理しHPCクラスタに確実に供給する装置です。
「集中型ストレージ」から「分散型ストレージ」へ
HPCクラスタの性能が急速に向上し、HPCクラスタが読み書きするファイルの量も急速に増加しています。ところがそれらを集中管理する「共有ストレージ」の性能はあまり向上していません。そのためストレージの応答速度が低下し、HPCクラスタのスループットの低下や、不安定な動作が発生するようになっています。このような現象を防ぐためには共有ストレージの高速化が必要です。
共有ストレージの高速化を実現する簡単な方法があります。それはネットワークをGbE並列化する、あるいは10GbE化するという方法です。しかし、このようなボトルネック対策による共有ストレージの高速化には限界があります。時間がたつとHPCクラスタの性能が向上しボトルネックが再発するからです。
共有ストレージの超高速化を実現する優れた方法があります。それは共有ストレージの分散化です。HPCクラスタの将来を見通すと共有ストレージの分散化は避けられません。そこで、このページでは今後の普及が予想される共有ストレージの分散化についての様々な考え方をお伝えします。
性能の限界が迫る「集中型ストレージ」
広く利用される「集中型ストレージ」
現在、多くの中小型HPCクラスタで使われている共有ストレージは「集中型ストレージ」と呼ばれる構造のものです。このストレージの特徴は「１台のストレージに全てのファイルを搭載し集中管理する」という構造の単純さにあります。
集中型ストレージはこの構造の単純さによって、使い易さ、信頼性の高さ、容量の大きさ、コストの安さなどを実現した優れたストレージです。そのため他の追随を許さず今も多くのHPCクラスタで使われています。
「集中型ストレージ」は過負荷に弱い
ところがこの優れた集中型ストレージにも「過負荷に弱い」という弱点があります。HPCアプリケーションが激しいファイルの読み書きを繰り返すと、ストレージが過負荷になり、HPCクラスタのスループットが低下し、やがてHPCクラスタ全体が不安定になることがあります。これが集中型ストレージが過負荷に弱いといわれる現象です。
「集中型ストレージ」が過負荷に弱い理由を予想
集中型ストレージが過負荷に弱い原因を探ると、利用方法が異なる２種類のファイル群を、同じストレージに搭載していることに起因することがわかりました。そこでこの２種類のファイル群にそれぞれ「ユーザ系・システム系ファイル」と「ワーク系ファイル」と名付け、どのような仕組みで問題が発生するのかを調べました。
2種類のファイル群の説明
はじめに、「ユーザ系・システム系ファイル」と「ワーク系ファイル」について説明します。(内容が細かいので下に対比表を掲載)
「ユーザ系・システム系ファイル」に属するファイルは、ソースコード、実行モジュール、入力データ、最終計算結果ファイル、開発環境、共有アプリケーション、各種ツール群、ネットワーク情報などです。これらのファイルの特徴は、ユーザやシステムが利用すること、データの再現性が低いこと、データの利用頻度が高いこと、システムの運用に必須なこと、データの総容量が少ないこと、データの更新量が少ないこと、データの変動量が少ないことなどです。そのため、これらのファイルを搭載するストレージは、応答速度の速さ、信頼性の高さが必要です。しかし容量の大きさ、スループットの高さは必要ありません。
「ワーク系ファイル」に属するファイルは、計算結果や一時ワークファイルなどです。これらのファイルの特徴は、HPCアプリケーションが計算のために直接読み書きすること、データの再現性が高いこと、利用期間が短いこと、システムの運用に関係が無いこと、データの総容量が大きいこと、データの更新量が多いこと、データの変動量が多いことなどです。そのため、これらのファイルを搭載するストレージは、スループットの高さ、容量の大きさ、拡張性の高さが必要です。しかし信頼性の高さと応答速度の速さは必要ありません。
次の表はこれらの特徴を対比させたものです。これを見ると両者がストレージに求める機能は反対であることがわかります。ストレージの使用量が少ない間は性能がミスマッチを吸収します。しかし使用量が増えると吸収しきれなくなり、問題が表面化します。
|
||||||||||||||||||||||||||||||||||||||||||||||||
２種類のファイル群をいっしょに保管することの問題
では２種類のファイル群を同じストレージに保管するとどのように問題が発生するのでしょうか。それの様子を典型例で説明します。
[ 激しくファイルを読み書きするアプリケーションの平行処理 ]
・ ワーク系ファイルを激しく読み書きする
・ ストレージが過負荷になり、それが長く続く
・ ストレージの応答速度が低下し、それも長く続く
・ ユーザ系・システム系ファイルを利用する各プロセスに遅れが発生
・ HPCクラスタ全体のスループットが低下
・ HPCクラスタ全体が不安定になる
ストレージが過負荷になると「HPCクラスタ全体のスループットが低下する」ことは理解できます。しかし「HPCクラスタ全体が不安定になる」ことは理解できません。なぜそのような現象が発生するのでしょうか。
HPCクラスタ全体が不安定になる理由
マルチコア化が進むHPCクラスタでは、搭載しているコアの数が相当な数になります。そして各コアでは複数のプロセスが動作しています。さらに各プロセスはユーザ系・システム系ファイルを何回も参照します。そのためHPCクラスタ全体がユーザ系・システム系ファイルを参照する数は膨大なものになります。
もしストレージの応答速度が低下すると、各プロセスがユーザ系・システム系ファイルを参照する時間が長くなります。個々の参照での時間の遅れは僅かでも、それが重なると大きな遅れに発展します。その結果、HPCクラスタのスループットは大幅に低下します。
さらにHPCクラスタでは多くのプロセスが依存関係にあります。そのためプロセスの遅れが長く続くと輻輳状態となりデッドロックが発生する確率が高まります。このような現象がHPCクラスタを不安定にします。
応答速度の低下が長く続く理由
(ジョブスケジューラの特性)
また、ストレージの応答速度の低下はなぜ長く続くのでしょうか。その理由も調べます。
HPCアプリケーションはストレージの応答速度が低下しても耐えられます。また、ストレージの方も過負荷に耐えられます。そのため両者が一緒に動作し過負荷が発生しても、それに耐えることができます。そのため過負荷が発生した状態が長く続きます。
さらに両者が過負荷に耐えていると、ジョブを管理しているジョブスケジューラはシステムが正常に動作していると認識します。そのためCPUの空きを検出すると次々と新しいジョブを投入し、過負荷の状態が長く続きます。
ジョブスケジューラはCPUの利用状況を監視していますが、ストレージの負荷は監視していません。そのためCPUからは負のフィードバックが掛かりますが、ストレージからは負のフィードバックが掛かりません。そのため、CPUの処理能力がストレージの処理能力よりも大きな場合は、先にストレージにボトルネックが発生します。
「集中型ストレージ」から「分散型ストレージ」へ
これらのことから、集中型ストレージが過負荷に弱いという問題を防ぐ対策を考えます。よく考えると、ユーザ系・システム系ファイルとワーク系ファイルを２台の独立したストレージに搭載し、両者の影響を物理的に切り離すこと、問題が解決できることがわかります。
この構成は、長い間HPCクラスタを支えてきた単純な構造の「集中型ストレージ」を卒業し、複雑な構造の「分散型ストレージ」へと、ストレージの構造を大転換することになります。
(余談) プロセッサのマルチコア化が
集中型ストレージの限界を表面化させた
余談になりますが、「集中型ストレージ」が過負荷に弱いという問題はこれまでなぜ表面化しなかったのでしょうか。その理由は、従来のプロセッサが搭載するコア数が少なかったためユーザ系・システム系ファイルを参照する回数が桁違いに少なく、集中型ストレージの能力に余裕があったためでした。
ところがマルチコア化が進み中小型のHPCクラスタが多くのコアを搭載するようになると、ユーザ系・システム系ファイルが参照される回数が急激に増加し、問題が表面化してきたのです。
プロセッサの高速化とマルチコア化は今後も続きます。そのためこれまで問題が発生しなかったシステムでも、やがて問題が表面化する可能性があります。
実は大型計算機は昔からこの問題がありました。そのため分散ストレージは古くから利用されていました。その状況がマルチコア・プロセッサの普及によって中小型のHPCクラスタにも波及してきました。
「分散型ストレージ」の概要
分散型ストレージの構造
分散型ストレージは２台の独立したストレージに、２種類のファイル群を別々に搭載し、相互の影響を切り離した構造のストレージです。
具体的な実装は、１台を「ユーザ系・システム系ファイル専用ストレージ」として運用します。搭載するファイルは、ソースコード、実行モジュール、入力データ、最終計算結果ファイル、開発環境、汎用アプリケーション、各種ツール群、ネットワーク情報などです。
もう１台を「ワーク系ファイル専用ストレージ」として運用します。搭載するファイルはHPCアプリケーションが直接読み書きするファイルです。
分散型ストレージは役割を合理的に分担し
真の最適化が可能
分散型ストレージの応答速度の速さは、分散型ストレージが持つ能力の一部でしかありません。分散型ストレージはそれ以外にも多くの優れた点を持っています。それが可能な理由は、２台のストレージが役割を合理的に分担することで真に最適化できるためです。
次の表は、集中型ストレージと分散型ストレージの能力を比較したものです。集中型ストレージは全ての機能を１台のストレージで実現しなければなりません。そのため機能に無駄が生まれ性能を十分に発揮できません。そのため全ての評価項目で並みの評価しか得られません。
これに対して、分散型ストレージは、２台のストレージが役割を分担し最適化しています。そのためシステムに無駄がなくなり、機能と性能を十分に発揮できます。そのため全ての評価項目で高い評価を得られます。
|
|||||||||||||||||||||||||||||
「分散型ストレージ」の数々の長所
もし分散型ストレージの長所が応答速度の速さだけなら、積極的に導入する気にはなりません。しかし、上掲の表のように、応答速度、冗長性、スループット、容量、拡張性、おおよそストレージに求められる機能の全てが優れているなら積極的に導入する価値があります。そこで、分散型ストレージが持つ優れた機能の数々について紹介します。
ユーザ系・システム系ファイル専用ストレージは
３種類の仕組で応答速度の低下を阻止
ユーザ系・システム系ファイル専用ストレージは応答速度が常に速くなければなりません。そこで、それを実現するため３種類の仕組みを採用しています。
１番目の仕組みは、既に述べてきた２種類のファイル群の分離です。すなわち２台のストレージを物理的に独立させ、過負荷の影響からユーザ系・システム系ファイル専用ストレージを保護し、応答速度が低下する時間を少なくします。
２番目の仕組みは、ユーザ系・システム系ファイルだけを冗長化する方法です。冗長化する対象のファイルを限定することで応答速度が低下する時間を少なくできます。しかもユーザ系・システム系ファイルの総容量は少なく、さらに日々の更新量も僅かです。そのためバックアップの時間が短くなります。例えば2TBのデータのフルバックアップは実効速度50MB/sの環境で約１２時間です。また日々のデータの更新量が10GBの場合の差分バックアップは約２００秒です。
３番目の仕組みは、１番目と２番目の仕組みで防ぐことができなかったバックアップ処理中の応答速度の低下を無くす対策です。実はバックアップ処理のボトルネックはネットワークポートで発生します。そこで、バックアップ用のストレージを同じサーバの中に搭載し、ネットワークを使わないでバックアップが出来るようにすることで、ネットワークによるボトルネックを回避でき、バックアップ処理中も応答速度を常に速く保つことができます。上の例ての１２時間のフルバッアップの時間と２００秒の差分バックアップの時間も、ストレージの応答速度が低下しなくなります。
これら３種類の仕組みを組み合わせることで、ユーザ系・システム系ファイル専用ストレージは応答速度の低下が発生しません。ファイルの応答速度を常に高速に保つことができます。
ワーク系ファイル専用ストレージは
過負荷を制御するフェィルセーフ機能を実現
HPCクラスタを使う時、自分が投入したジョブが他のユーザの迷惑にならないように注意することは大切なマナーです。しかし注意していてもミスを完全に防げません。そこでHPCクラスタの側が過負荷に対するフェイルセーフ機能を備えている必要があります。なおここではワーク系ファイル専用ストレージに限定して考えます。
例えばあるユーザが非常に大きな負荷をストレージに与えると他のユーザのジョブを圧迫します。この問題を防ぐためには、ストレージの処理能力を各ユーザに公平に分配する仕組みが必要です。
ストレージの処理能力を公平に分配するためには次の３種類の方法が利用できます。１番目の方法は、ネットワークポートを利用しユーザからの負荷に対して入口規制をかける方法です。２番目の方法は複数のストレージを導入し負荷分散する方法です。３番目の方法はストレージの並列化です。
これらの方法はそれぞれ長所と短所があるため目的に応じて選択します。さらにこれらの方法を組み合わせると、ストレージの処理能力をより複雑に分配できる環境を実現できます。
１、ストレージの処理能力を分割しフェアシェアを実現
複数のユーザがストレージを共同利用するとOSが負荷を分散します。しかし、特定のユーザがストレージに非常に大きな負荷をかけると、ユーザ間でのストレージ資源の公平な分配 (ファエシェア) が機能しなくなります。
しかも、ジョブスケジューラはCPU資源を公平に分配できるだけで、ストレージ資源を公平に分配する機能は持っていません。
ユーザ間でストレージ資源を公平に分配する手段の１つとして、各ユーザが利用できる処理能力に上限を設ける方法があります。上限の設定にはネットワークーポートが利用できます。具体的に次のように実装します。
・ ユーザ／ジョブをいくつかのグループに分割する
・ ストレージに複数のネットワークポートを搭載する
・ GbEは約50MB/sec/portが処理能力の上限
・ 10GbEは約300MB/sec/portが処理能力の上限
・ 各グループ毎にネットワークポートを割り当てる
・ 割り当てられたネットワークポートが処理能力を規定する
例えば50MB/sのGbEを４ポートと、300MB/sの10GbEを１ポートをサーバに実装するとします。もしこれをボンディングすると沢山ジョブを投入している一部のユーザが帯域幅を使い尽くします。しかし、ネットワークポートをユーザ (グループ) 毎に割り当てると、割り当てられた帯域幅以上の処理能力を使うことができなくなります。そのため他のポートを割り当てられたユーザ (グループ) はその帯域幅を存分に使うことができます。
運用方法の例を挙げますと、４グループある学生のグループにGbEのポートを１ポートづつ割り当て、先生方には10GbEを１ポート割り当てると仮定します。ある学生のグループは400MB/s平均の負荷を与え、他の学生のグループは50MB/s平均の負荷を与えるとします。しかし、ネットワークで性能を制限しているため、双方とも50MB/sの性能しか利用できません。さらにその後、他のグループや先生方が利用し始めてもジョブは普通に動作します。
しかし、高い性能を追求するHPC計算機にとって、性能を抑制する実装は次善の策です。もしファイル性能に強く律速されるジョブを利用されるなら、そのようなジョブ専用のストレージを別に搭載することをお勧めします。それを次で説明します。
２、ジョブに最適化したストレージの追加
HPC計算では、利用するアプリケーションによってワークファイルの大きさが何桁も違う場合があります。そのようなアプリケーションが同じストレージを共有することは望ましくありません。公平性と高性能とでジレンマが起こるからです。
このような場合は新たに高負荷処理専用のワーク系ファイル専用ストレージを導入して分散処理の最適化を検討してください。
例えば、１台目は、RAID6とGbE x8を採用した標準的なワーク系ファイル専用ストレージとして運用し、２台目を、RAID0と10GbE x2を採用した高速大容量ファイル専用ストレージとして運用するような構成です。
この例のようにワーク系ファイル専用ストレージの分散では、ジョブの特性に最適化したストレージを追加することで、HPCクラスタの機能をさらに向上させることができます。
３、並列処理による超高速ワーク系ファイル専用ストレージの実現
大量のファイルを読み書きするアプリレーションを大規模なHPCクラスタで大量に動作させる場合は超高速なストレージが必要になります。しかも巨大な共有データ群を多数のジョブが同時に利用する場合は特に大容量かつ高速なストレージが必要になります。
このような用途で広く利用されるストレージが超高速並列ストレージ・システムです。利用実績の多い方式は、ソフト的に並列化するラスターファイルシステムです。その他にハード的にストレージを並列化する方法もあります。
超高速並列ストレージ・システムの実装はアプリケーション、HPCクラスタ、ストレージの性能バランスを考慮して設計しないと期待した性能が得られません。そのため詳しいシステム設計を承っています。
ユーザ系・システム系ファイル専用ストレージは
高い信頼性を実現
従来の集中型ストレージは全てのファイルを１台のストレージに集約しています。そのためストレージの全体を冗長化する必要があります。しかしそのような処理には大きな処理能力が必要です。さらにバックアップ先となる大容量のストレージも必要でコストもかかります。しかもストレージの信頼性は容量の大きさに反比例して低下するため集約のメリットが相殺されます。さらにバックアップに時間がかかるため処理が困難になり、薄氷を踏むようなシステムも少なくありません。集中型ストレージは容量が大きくなるにつれて運用の限界が近づきます。
これに対して、分散型ストレージは容量が大きくなっても運用の限界に達しない仕組みを持っています。ここでその仕組み説明します。
HPCクラスタで利用するファイル群は、高い冗長性が必要なユーザ系・システム系ファイル群と、それを必要としないワーク系ファイル群に分かれます。それならば、ユーザ系・システム系ファイルの信頼性だけを維持すれば全体の冗長性を維持できることになります。全体を冗長化する必要はないのです。
さらにユーザ系・システム系ファイルの内部は、ユーザ系ファイルとシステム系ファイルに分けることができます。中小型のHPCクラスタの場合、ユーザ系ファイルの容量は約1TB〜2TB、システム系ファイルの容量は約1TB〜2TBです。
ユーザ系ファイルは頻繁に更新されるため毎日差分バックアップを取る必要があります。これに対してシステム系ファイルは設定を変更する時だけ (例えば半年に１度) バックアップが必要です。このように両者のバックアップのタイミングは全く異なります。そのためユーザ系ファイルとシステム系ファイルは別々にバックアップする方が合理的かつ安全です。
バックアップの対象となるファイルの容量を2TB単位でグループ化できるなら、RAID化していない単体ディスクをバックアップ先として使えます。
単体ディスクはストレージとして完結しているため高い耐障害性と可搬性があります。万一サーバに障害が発生しても容易にデータを取り出せます。また、バックアップ先に使用するディスクはアクセスの頻度が低いため機械的な摩耗が少なく長寿命です。
ユーザ系ファイルとシステム系ファイルを別々にバックアップするだけなら２台のディスクで十分です。２台数のディスクならユーザ系・システム系ファイル専用ストレージの中に内蔵することができます。例えば１２個のディスクが内蔵できるシャシなら２個を割り当ててもまだ１０個残りますから、14TBのスペアディスク付きRAID6を構成できます。
バックアップ元のRAIDとバックアップ先のディスクを同じサーバの中に搭載できれば、ネットワークに経由せずバックアップでき、システム全体に対する負担を軽減できます。
分散ストレージをファイルの特徴に合わせて設計することで、性能、信頼性、利便性、経済性を全て満たしてシステムを実現できます。これも分散型ストレージの長所です。
なお、ユーザ系・システム系ファイル専用ストレージは容量の維持が大切です。この例では2TBが上限です。このサイズを維持するには使い終わったファイルをアーカイブする必要があります。アーカイブ用のストレージはシステムに別途搭載することができます。あるいは市販の廉価な外付けディスクを使用することもできます。また、アーカイブ先に使用するディスクもアクセスの頻度が低いため機械的な摩耗が少なく長寿命です。
ワーク系ファイル専用ストレージも
適切な信頼性を持つ
ワーク系ファイルは再現性があるためバックアップを取る必要はありません。また、容量が大きく日々の更新量も多いためバックアップを取ることは現実的でもありません。
ワーク系ファイル専用ストレージに必要な冗長性はファイルの利用方法によって異なります。自動リビルトが必要なワーク系ファイル専用ストレージならスペアディス付きRAID6が適しています。リビルドを必要としないならRAID5で十分です。
分散型ストレージは
巨大な容量のストレージを低コストで実現
分散型ストレージは複数のストレージで構成されているため高価な印象があります。しかし実際にシステムを積算すると分散型ストレージは集中型ストレージよりも安価です。それは分散型ストレージが合理的で無駄がないためです。ここではそれを具体的に説明します。
ストレージの構成例として、2TBのユーザ系・システム系ファイルと8TBのワーク系ファイルで構成された10TBのストレージとそのバックアップが可能なシステムを想定します。
これまでの集中型ストレージによってこのストレージを構築するためには容量が10TBのファイルサーバが２台必要です。そのうちの１台を本番用に使い、もう１台をバックアップ用に使います。すると必要な機器は２台のサーバと32TBの物理ディスクになります。
分散型ストレージで同じくこのストレージを構成するためにも２台のサーバが必要です。１台のサーバは2TBのバックアップ機能付きユーザ系・システム系ファイル専用ストレージとして使用し、もう１台は8TBのワーク系ファイル専用ストレージとして使用します。サーバは２台必要ですが、ハードディスクは20TBしか必要ありません。集中型ストレージよりも物理ディスクを10TBも節約できます。
分散型ストレージが安価な理由は、バックアップが必要な領域が小さく物理ディスクを節約できるからです。しかもバックアップが必要な領域を絞り込んでいるため、バックアップの高速化、信頼性の向上を実現しています。
これは余談ですが、ストレージのサイズが大きくなると適切なバックアップが困難になります。それでもバックアップを行うおとするとコストが高騰します。この観点からも分散型ストレージは優れています。また後ほども触れますが、分散型ストレージの運用が定着し、ジョブスケジューラと連携した運用が安定して行われるようになると、ファイル群の内部をさらに機能的に分散して利用できるようになります。すると信頼性と性能はより向上します。しかもコストの上昇は僅かです。しかも、システムの複雑さはジョブスケジューラが吸収するためユーザの負担が増えることはありません。
このようにコスト節約の観点からも分散型ストレージは今後の主役となるストレージです。
「分散型ストレージ」 は
次世代HPCクラスタの基盤を支える
ワーク系ファイル専用ストレージは分散化による高速化の方向に向かっています。その実装を支えている仕組みが「分散型ストレージ」です。
分散型ストレージの本質は、HPCクラスタを支える基盤的な情報を一箇所に集約して管理していることです。それがユーザ系・システム系ファイル専用ストレージです。
ユーザ系・システム系ファイル専用ストレージがHPCクラスタの要として機能している限り、HPCクラスタがどのように複雑化し、ワーク系ファイル専用ストレージが並列化しても、システムの基本構造は保たれています。
逆の視点から説明すると、ユーザ系・システム系ファイル専用ストレージのキャパシティーを向上させるために、ワーク系ファイルを追いだしたと考えることができます。
ユーザ系・システム系ファイル専用ストレージがHPCクラスタを統合していることによって、HPCクラスタ全体をユーザから見ると、たとえシステムがどれほど複雑であっても、単純なシングルシステムイメージとして捉えることができます。すなわち簡単な構成のワークステーションのように見えます。
また、ストレージの構造が複雑になると、「HPCクラスタの利用が煩雑にならないかと心配だ」という声がよく寄せられます。しかしご心配にはおよびません。ジョブスケジューラが普及した現在では、全てのシステムはジョブスケジューラを介して利用するため、一般ユーザが使い方に困られるようなことは何も起こりません。自分のホームディレクトリから適切なジョブキューにジョブを投入するだけで操作は完了します。
次世代のHPCクラスタシステムは、ヘテメジニアスなHPCクラスタシステムと、ユーザ系・システム系ファイル専用ストレージと、分散ワーク系ファイル専用ストレージと、マスターサーバ機が有機的に一体化してHPCクラスタを構成します。次世代のHPCクラスタシステムの基盤を支えるものが「分散型ストレージ」です。
完成度の高い「分散型ストレージ」の実装
ユーザ系・システム系ファイル専用ストレージの構成
「ユーザ系・システム系ファイル」に属するファイル群はさらに「システム関連ファイル」と「ユーザ関連ファイル」という２つのグループに分割できます。システム関連ファイルに属するファイルは、開発環境、ネットワーク情報、アプリケーションなどのような計算機が読み書きするものです。ユーザ関連ファイルに属するファイルは、ソースコード、入力データ、最終計算結果データなどのようなユーザが直接読み書きするものです。これらのファイル群は、ユニークなファイルが多く、長期的に利用され、常にアクセスがあり、応答速度の速さと信頼性の高さが求められます。またユーザ系・システム系ファイルは総容量が小さく、変動量が少ないことも特徴です。
このようなユーザ系・システム系ファイルを蓄積するストレージの容量の目安は、システム関連ファイル用として約1TB、ユーザ関連ファイル用として利用者が４〜５人のHPCクラスタなら1〜2TBと見積もることができます。ユーザ領域が小さすぎるような感じを受けますが、別にワーク系ファイル専用ストレージやアーカイバを利用できるので不自由することはありません。しかもそれでも容量が足りない場合は2TBをひとつの単位として、ユーザ関連ファイル領域を追加することが可能です。
ユーザ系・システム系ファイル専用ストレージの冗長化は、高い信頼性と可用性を実現するため、スペアディスクによる自動リビルド機能を備えたRAID6を採用します。この物理ボリュームを通常は３個の理論ボリュームに分割し、それぞれをOS領域、システム関連ファイル領域、ユーザ関連ファイル領域に割り当てて使用します。定期バックアップはそれぞれの理論ボリュームごとに別のディスクに行います。
バックアップのポイントは理論ボリュームの容量を2TB以下にしていることです。理論ボリュームが２TB以下なら、バックアップ先として2TBの生ディスクを利用できます。生ディスクはRAIDを利用しないので異なる階層の信頼性を実現できます。万一サーバ全体がダメージを受けた場合には生ディスクを別のサーバに接続して読み出すことができます。
バックアップ用の生ディスクはユーザ系・システム系ファイル専用ストレージに内蔵しています。そのためRAID６ボリュームのバックアップを同一サーバの内側で行うことができます。サーバ内のバックアップはネットワークを介さないため高速です。しかも一般的なファイルI/Oとのネットワーク競合が起こらないためそれらの応答速度を低下させません。またバックアップ元は高速なRAID6であるのに対してバックアップ先は低速な生ディスクであるため、バックアップ処理中でもRAID6側の帯域幅に余裕があり、この面でも外部からの応答速度を低下させません。
ユーザ系・システム系ファイルはデータの総容量が少ないためバックアップを短時間でおこなうことができます。さらにデータが更新される量も少ないため差分バックアップも短時間でおこなうことができます。
ユーザ系・システム系ファイルは応答速度の速さが大切です。そのためユーザ系・システム系ファイル専用ストレージに適したネットワークは、帯域幅は狭いけれどレイテンシーが低くポート数の追加が容易で廉価なGbEが優れています。これからの計算機はマルチコア化がさらに進むため、多数のプロセスが平行動作する過程で膨大な数のファイルの読み書きが同時に要求されるような現象がますます頻発するようになります。それを効率良く処理してゆくためには多数のネットワークポートを搭載していることが必須です。すなわち、４ポートのGbE NICを用いた４ポートのGbEの実装、さらにそれを２枚用いた8ポートのGbEの実装が現実味を帯びてきます。
ユーザ系・システム系ファイルは総容量が小さいのでストレージの障害発生率が小さくなります。またバックアップとリストアに際しての障害発生率も小さくなります。そのため総合的な信頼性は桁ひとつ向上します。
ユーザ系・システム系ファイル専用ストレージはワーク系ファイルを搭載していないため過負荷が発生せず応答速度の低下がありません。しかし、ワーク系ファイル専用ストレージを上手に利用せず、ワーク系ファイル型のファイルをユーザ系・システム系ファイル専用ストレージに置くことが習慣化すると問題です。定期的な運用状態の確認が必要です。
ユーザ系・システム系ファイル専用ストレージの容量の膨張を防ぐためにはアーカイブ専用のストレージが必要です。アーカイブ専用ストレージを利用し使い終わったファイルをアーカイブすることでユーザ系・システム系ファイル専用ストレージを常に最高のコンディションにしておくことができます。アーカイブ専用ストレージはアクセスの頻度が低いため物理ディスクの消耗が少なく高い信頼性が期待できます。アーカイブ専用ストレージの実装方法は幾つかあります。○ 高速なアーカイブ装置が必要ならユーザ系・システム系ファイル専用ストレージに拡張RAIDコントローラを追加し外付けのDASを接続する方法が適しています。○ 信頼性と可搬性を求めるならiSCSIが適しています。○ アーカイブ専用NASも信頼性と可搬性に優れています。○ 性能を気にしないならUSB接続の外付けディスクも優れています。
ワーク系ファイル専用ストレージの構成
「ワーク系ファイル」に属するファイル群は、計算結果データなどのHPCクラスタが読み書きするファイルです。計算結果データは再現性があり、利用期間が短く、利用し終わると消去されます。そのためストレージの信頼性は低くてもかまいません。しかしストレージの速度と容量は大切です。
ワーク系ファイルの総容量はHPCクラスタの規模と計算内容で決まります。一般的な容量の目安はXeon ２ソケット機に対して500GBから1TBです。Xeon ２ソケット ８ノード 16CPUクラスタ構成のクラスタならは4〜8TBです。
ワーク系ファイル専用ストレージに搭載するネットワークは実効性能で500MB/sが期待できるDual-Port 10GbEをお勧めします。ワーク系ファイル専用ストレージはスループット性能が重要です。その性能はネットワークによって律速されます。ワーク系ファイル専用ストレージに接続されるネットワークのNFSの実効性能は、Single-Port GbE 約60MB/s、Quad-Port GbE 約200MB/s、Single-Port 10GbE 約300MB/s、Dual-Port 10GbE 約500MB/sが現実的な値です。
ワーク系ファイル専用ストレージでも突発的な停止は許容されません。しかしデータを確実に復旧させる必要もありません。用途に応じた適切な冗長性が必要です。選択できるRAIDポリシーはRAID5あるいはRAID6です。両者の違いはオートリビルトを利用するかしないかということです。ここではその実践的な違いを説明しています。
◇ RAID5
RAID5は１個のディスクを用いた冗長化です。ディスクが障害を起こした場合でも突発的なストレージの停止を防ぎ、システムを停止させるまでに一定の時間を確保し、大切なデータを退避させたうえで安全に計算機を停止させることができます。全ての退避作業が完了したところでRAID5を初期化し白紙の状態からRAID5を構築することで最短時間でストレージを復旧することができます。
RAID5のボリュームサイズが大きくなるとリビルトにも長い時間がかかります。ワーク系ファイル専用ストレージに保存しているデータの大部分がポスト処理済みで利用価値の低いデータの場合は全てを消してしまい。必要な部分の計算だけを再計算するという運用も非現実的ではありません。RAID5はこのような場合に適したRAIDポリシーです。
◇ スペアディスク付のRAID6
ワーク系ファイル専用ストレージに保存しているデータの大部分がポスト処理待ちのデータであり、全てのデータを再計算するためには相当の時間がかかるような場合には、スペアディスク付きのRAID6による自動リビルトを利用が適しています。RAID6は２重の冗長化を採用しているため１個のディスクが故障しても冗長性が保たれています。そのため自動リビルト中に別のディスクが新たに故障してもまだデータを読み出せます。そのため自動的リビルトを安心して利用することができます。
自動リビルドを設定していると、障害が検出されるのと同時に自動的にリビルドが開始されます。RAID6のリビルドはバックアップを取っていないため完全にデータが保護されているわけではありません。本当に大切なファイルは速い段階で退避しておくと安全です。
◇ RAID0 (RAID5)
RAID0 (RAID5) を利用した共有スクラッチファイルの実装も有意義です。本格的なスクラッチディスクはローカルディスクとして実装することが基本です。しかし不定期に任意のサーバ上でスクラッチディスクを利用した計算を行う場合はスクラッチディスク専用の共有スクラッチディスクを設定しておくと経済的です。
ストレージの平行化と並列化
ストレージの平行化による超高速化
分散型ストレージを導入していても時間が経つと性能不足が再発します。そのような場合にはストレージを平行化あるいは並列化してストレージの性能をさらに向上させる必要があります。ストレージの並列化/平行化はワーク系ファイル専用ストレージに対して行います。
ワーク系ファイル専用ストレージを平行化する場合は、新たなワーク系ファイル専用ストレージを増設するハードウェア側の増設作業と、システム設定を変更するソフトウェア側の作業を行うだけで導入が完了します。
ワーク系ファイル専用ストレージの平行化の運用方針は、ユーザをグループ化する方法と、計算機をグループ化する方法の２種類が代表的です。運用方針を決めれば、ユーザが決めた方針に従いジョブスケジューラが自動的にジョブを管理しますから、ユーザが不自由さを感じることはありません。
ストレージの平行化によって実効データ転送性能はDual-Port 10GbEサーバを１台追加するたびに約500MB/sづつリニアに増大します。
ストレージの並列化による超高速化
ストレージの並列化は高度なデータの並列処理を行います。複数のストレージを用いて並列ファイルシステムを実装することで高速かつ大容量な仮想ストレージを形成し、HPCクラスタから一体のストレージとしてシームレスに利用でき便利です。ストレージの並列化を実現するためには、ラスターファイルシステムのようなソフトウェアによる並列化、あるいは専用のハードウェアを利用した並列化を利用する必要があります。それぞれの方法には長所と短所があります。弊社はこれらのシステムインテグレーションについても豊富な経験があります。システム設計から運用支援まで一括して受注することができます。
分散ストレージはストレージの平行化/並列化と相性が良い
分散型ストレージを導入していると平行/並列ストレージの導入は簡単です。分散型ストレージによってユーザ系・システム系ファイルとワーク系ファイルは分散しています。そのためストレージを平行化/並列化する場合はワーク系ファイル専用ストレージだけが対象となり、導入作業が簡単になるのです。具体的には、新しいストレージを追加し、システムの設定とジョブスケジューラの設定を少し変更するだけで導入作業は完了します。運用の変化はほとんどありません。
「分散型ストレージ」の運用
分散型ストレージの運用のポイント
分散型ストレージの運用で大切なことは、ユーザ系・システム系ファイル専用ストレージとワーク系ファイル専用ストレージの役割分担を明確にして運用することです。分散型ストレージを導入しても運用方針にブレがあると十分な効果が得られません。
そこで大切なことは、ワーク系ファイルと差分バックアップの関係の理解です。従来の集中型ストレージは両者を一緒に取り扱っていたので応答速度の低下を招いていました。分散ストレージでは両者を独立したストレージに置くことで干渉の発生を予防しています。ところが、運用の手を緩くするとワーク系ファイルがユーザフィル専用ストレージに置かれることが予想されます。すると応答速度の低下が発生する可能性があります。これは避けなければなりません。
ユーザ系・システム系ファイル専用ストレージが応答速度の高さを維持できる利用はバックアップの対象となるデータ量が少なく、データの更新量も小さいことです。それを長く維持するためには、ワーク系ファイルはユーザ専用ストレージには置かずワーク系ファイル専用ストレージに置くようにすることです。
分散型ストレージにより柔軟なシステム拡張を実現
これまで小型のHPCクラスタを継続的に導入していると、いつの間にか小型のHPCクラスタが乱立しシステムの管理が難しくなっていました。ところが分散型ストレージを導入するとこのような問題は発生しません。
分散型ストレージを利用していると、全てのHPCクラスタは単一のユーザ系・システム系ファイル専用ストレージ兼マスターサーバの管理下に入ります。ユーザ系・システム系ファイル専用ストレージの処理能力に余裕を持たせていると、多数のHPCクラスタを一括して管理することができます。さらに新しいHPCクラスタを追加しても余裕を持ってシステムに組み込むことができます。
HPCクラスタが必要とする高速大容量なストレージサービスは、ワーク系ファイル専用ストレージが集中的に引き受けます。このストレージの性能が不足すると、簡単に新しいストレージをクラスタに追加することができます。
運用は単一のマスターサーバの管理下に全てのHPCクラスタを収め、その内部に複数のサブクラスタを設定、それらのグループとワーク系ファイル専用ストレージを、任意にグループ化しジョブスケジューラで管理することができます。
物理的な構造は複雑ですが、一般のユーザからシステムを見ると、そのような複雑さを感じることは殆どありません。物理的なシステムは抽象化され、単一のマスターサーバ (管理サーバ兼ユーザ系・システム系ファイル専用ストレージ) がシステムの複雑さを吸収しているため、ユーザから見ると単一の仮想計算機と、単一の仮想ストレージを独占的に利用しているような感覚で利用することができます。
このような「導入時期が異なるHPCクラスタであっても一体のシステムとして運用したい」というお客様のご要望はよく寄せられます。分散型ストレージを採用することでこのようなご要望に柔軟にお応えすることができます。
ユーザ系・システム系ファイル専用ストレージと管理サーバの兼用
ユーザ系・システム系ファイル専用ストレージと管理サーバとの相性は良好です。そのため両者を同じサーバに実装することをお勧めします。管理サーバで利用するファイルの多くはユーザ系・システム系ファイル専用ストレージに搭載されています。両者を同じサーバに搭載するとファイルの読み書きを同じサーバ内で行うことができネットワークの影響を受けず非常に速い応答速度が得られます。そのためシステムの高速化に効果があり、信頼性も向上します。
ストレージに関する周辺技術の整理
半導体製造プロセスの微細化の進歩により
急速に性能を向上させつづけるHPC計算機
この１０年間でプロセッサの性能は２０倍に向上しました。またプラットホームの主流が１ソケットから２ソケットへと移行したことでシステムレベルの性能は４０倍に向上しました。
ではこの１０年間の前半と後半では、それぞれ性能がどれだけ向上したのでしょうか。2000年に登場したPentium4 2.0GHz １ソケット機の理論性能は４ギガフロップです。その５年後に登場したDual-Core Pentum D 3.2GHz １ソケット機の理論性能は１２．８ギガフロップです。前半の５年間でプロセッサの性能の３倍にしか向上していません。
ところが後半の５年間で計算機の性能は飛躍的に向上してした。2010年に登場したHexa-Core Xeon 3.33GHzの理論性能は８０ギガフロップスですから、後半の５年間でプロセッサの性能は６倍に向上したことになります。さらに計算機の標準プラットホームが１ソケットから２ソケットへと移行したことで、システムレベルの性能は１２倍に向上しました。
すなわち１０年間で性能が４０倍に向上した内訳は、前半の５年間の性能の向上が僅か３倍だったことに対して、後半の５年間の性能の向上はプロセッサレベルで６倍、システムレベルでは１２倍に達していたことがわかりました。
後半の５年間で計算機の性能が飛躍的に向上した理由は並列化が進んだことによります。ちょうど2005年頃からプロセッサのマルチコアが普及しはじめました。さらに2008年頃からはマルチソケット機の並列性能が格段に向上しはじめました。
プロセッサを並列化するためには沢山のトランジスターが必要です。それを支えたものが半導体製造プロセスの微細化です。2006年に利用されていたプロセス技術は65nmです。それが2008には45nmになり、今使用されているプロセスは32nmです。これが2011年には22nmになり、その先の15nmプロセスも開発中だとのことです。このように製造プロセスの微細化は今後も順調に向上してゆくと考えられます。
では次の１０年では、計算機の性能はどれほど向上するのでしょうか。現在の２ソケット機を基準に考えると。次の５年間の前半でアーキテクチャが更新され性能が２倍に、その後プロセスが改良されコア数が倍増すれば４倍になります。さらに後半の５年間でもこの傾向がスケールすると仮定すると２ソケット機の性能は８倍になり、その後１６倍になると予想できます。また４ソケット機まで考えると、それは１６倍から３２倍になると予想できます。
このように過去１０年間で約４０倍に向上した計算機の性能は、次の１０年間でも４ソケット機を導入する前提で考えると同様に約４０倍の性能向上を達成すると考えることができます。
参考ですが、計算機に搭載するメモリのサイズも大容量化しています。１０年前の計算機のメモリ容量は１〜２ギガバイトでした。それが現在では４８〜９６ギガバイトになっています。メモリサイズは１０年間で５０〜１００倍に拡大しました。さらに４ソケット機では１００〜２００倍に拡大しています。この傾向も継続すると考えられます。
また計算機のメモリバンド幅も広がりました。１０年前の１ソケット機のメモリバンド幅は3.2GB/sでした。これが現在の２ソケット機では64GB/sになっています。メモリバンド幅も１０年間で約２０倍に拡大しました。さらに４ソケット機では４０倍に拡大しました。
このように計算機の性能は並列処理が利用できるようになったことで、半導体製造プロセスの微細化に沿って順調に性能を向上させています。
性能向上のペースが遅い「汎用ネットワーク」
これまでの１０年間でネットワークの性能は１０倍にしか向上していません。具体的には、１０年前の2000年代の初頭にGbEが普及し始めました。そして１０年後の2010年になってようやく10GbEが普及し始めています。
さらに次の１０年間でネットワークの性能は４倍程度までしか向上しないと考えられます。それは端末側のネットワーク市場の主流が無線に移り始めているため、GbEが普及した時のような勢いは、10GbEや40GbEの場合にはみられないと考えられるからです。
すなわち、計算機は１０年前から現在までが４０倍、現在から１０年後までが４０倍、２０年間の通しでは１６００倍の理論性能の向上があると推定されることに対して、ネットワークは、１０年前から現在までが１０倍、現在から１０年後までが４倍、２０年間の通しでは４０倍の理論性能の向上があると推定されます。
計算機とネットワークとの性能の乖離の拡大を見ると、ワーク系ファイル専用ストレージが対応できる計算ノードの数は減ってゆくと予想できます。ワーク系ファイル専用ストレージの分散化もストレージの分散化を追う形で始まります。
「DAS型ファイルサーバ」の速度向上の遅さは
ネットワークの性能向上の遅さに原因がある
HPC計算機は急速に性能向上しています。ところがファイルサーバの性能向上はペースが遅く問題です。その原因はネットワークの速度向上のペースの遅さに原因があります。
先にも書きましたが、ネットワークの速度向上のペースはこの１０年間で約１０倍です。さらに次の１０年間では４倍程度の性能向上しか期待できそうにありません。ところが計算機の性能向上のペースは過去１０年間で約４０倍、そしてこれからの１０年間でも約４０倍の性能向上が期待されます。計算機の性能向上と、ネットワークの性能向上の乖離を埋めることは不可能です。ネットワークポートの並列化を用いても焼け石に水の状態です。
さらに別の問題があります。それは計算機の性能向上が並列処理によって実現されていることです。すなわち単一のジョブであっても、各計算機の上では多数のプロセスが動作しています。それらが動作する際には個々にファイルの読み書きを求めます。そのため多数のファイルI/Oが発生しています。これらの処理ではファイルI/Oの帯域幅の広さとは別にレイテンシーの低さも求められます。一概に10GbE化すれば問題が解決できるということでもありません。
ファイルサーバのネットワークを高速化する方法1
GbE、GbE x4、10GbE、10GbE x2
ファイルサーバのボトルネックはネットワークポートの部分にあります。そのためファイルサーバを高速化するということはネットワークポートの部分をいかに高速化するのかということでもあります。
現在選択できるネットワークはGbE (実効性能80MB/s)と、10GbE (実効性能300MB/s) です。さらに高い性能を得るためには同一サーバ内の並列化、さらに複数サーバによる並列化と、並列化が階層化してゆきます。
次の構成はユーザ系・システム系ファイル専用ストレージを高速化する方法です。GbEのマルチポートNICを利用することでレイテンシーの低下を抑えることを主眼に置いています。例えば４８コアのノードが一挙に数百個のファイルが読み書きされる可能性があります。もちろん各ポートは分割使用されますが、それでも過負荷になる場合があります。その影響を最小限に抑えるためにはネットワークポートの並列分散が必要です。
次の１番目の構成は同一サーバ上でのGbEの並列化です。２番目の構成はサーバレベルのGbEの並列化です。この構成では２台のサーバに置くディレクトリを機能別に分けています。分散することで相互の干渉が無くなりさらにスループットが向上します。
- GbEポートのマルチポート化
４ポートで300MB/s程度のスループットが期待できる
レイテンシーの維持が期待できる (同時アクセス時の)
ユーザ系・システム系ファイル専用ストレージに適する
適するディレクトリは /opt、/usr、/home - 複数のGbEファイルサーバを用いたサーバレベルのネットワーク並列化
GbE x4構成で300MB/sの実効速度を持つサーバを複数用いることでリニアな性能向上を達成
この構成はレイテンシーの維持を主眼においたサーバレベルの並列化
ユーザ系・システム系ファイル専用ストレージの並列化に適する
１台目に適するディレクトリは /opt、/usr、２台目に適するデロイレクトリは /hom
ファイルサーバのネットワークを高速化する方法2
GbE x4 xN、10GbE x2 xN
次の構成は10GbEを使用した構成です。10GbEは帯域幅は得られますがレイテンシーの維持はマルチポートのGbEにかないません。そこで、10GbEを用いたストレージは、分散型ストレージを構築する場合のワーク系ファイル専用ストレージに利用することをお勧め増しす。
- 10GbEにアップグレード
１ポートで300MB/s程度のスループットが期待できる
レイテンシーの維持は期待できない (同時アクセス時の)
ワーク系ファイル専用ストレージに適する
適するディレクトリ /work、/scr - 10GbEのマルチポート化
10GbE x2構成で500MB/sの実効速度を持つサーバの利用
レイテンシーの維持は期待できない (同時アクセス時の)
ワーク系ファイル専用ストレージに適する
適するディレクトリ /work、/scr - 複数の10GbE x2ファイルサーバを用いたサーバレベルのネットワーク並列化
10GbE x2構成で500MB/sの実効速度を持つサーバを複数用いることでリニアな性能向上を達成
帯域幅の向上に主眼においたサーバレベルの並列化
ワーク系ファイル専用ストレージの並列化に適する
適するディレクトリ /work、/scr
ファイルサーバのディスクアレイを高速化する方法
DAS、FiberChanel、iSCSI
ディスクアレイについても概要を整理します。HPCクラスタはサーバに直結するタイプのRAIDが今後も主流となります。しかし、大規模なクラスタのユーザ系・システム系ファイル専用ストレージではFiberChanelやiSCSIの利用も考えられます。これらのストレージはバックアップ機能が優れています。
- DASを用いたストレージ
低価格で大容量を実現出来る
DASは6Gbps x4でサーバに接続されているので、10GbE x2に追従できる理論性がある
ランダムアクセスに対応するためには主メモリを多くすると良い
適するディレクトリ /opt、/usr、/home
適するディレクトリ /work、/scr
- FiberChanel ストレージは並列化ユーザ系・システム系ファイル専用ストレージに適する
4Gbpsの帯域幅のものはGbEと理論性能がマッチ
適するディレクトリ /opt、/usr、/home
- iSCSI トレージは並列化ユーザ系・システム系ファイル専用ストレージに適する
GbE iSCSIはGbE並列機に最適
10GbE iSCSIは10GbE並列機に最適
適するディレクトリ /opt、/usr、/home
分散型ストレージを導入する場合は
ディレクトリーの使い分けを明確にする
分散型ファイルサーバを導入する場合は、利用するファイルの系統に応じてストレージの使い分けを明確に区別する必要があります。ユーザ系・システム系ファイル類はユーザ系・システム系ファイル専用ストレージへ、ワーク系ファイル類はワーク系ファイル専用ストレージへということです。その区別はディレクトリーによって行います。一般的なHPC計算では次の５種類のディレクトリを使用しています。これらを２種類に区分します。
◇ ディレクトリーの種類
- /opt
開発環境、固定データ
高い耐障害性、バックアップとリストアを行う
システム更新時にデータ移行を管理者が実施
ユーザ系・システム系ファイル類 - /usr
アプリケーション、固定データ
高い耐障害性、バックアップとリストアを管理者が実施
システム更新時にデータ移行を管理者が実施
ユーザ系・システム系ファイル類 - /home/user_name
ユーザ領域 (ソースコード/実行ファイル/インプットファイル/結果ファイル)
高い耐障害性、バックアップとリストアを管理者が実施
システム更新時にデータ移行を管理者が実施
ユーザ系・システム系ファイル類 - /work/user_name
計算結果などの利用後に消去する短期利用ファイル
並みの耐障害性、バックアップとリストは行わない
システム更新時にデータ移行を管理者は行わない
ワーク系ファイル類 - /scr/user_name (/highspeed-work)
スクラッチファイルなどの超短期利用ファイル
冗長化は行わない、バックアップとリストは行わない
システム更新時にデータ移行を管理者は行わない
ワーク系ファイル類
◇ ユーザ系・システム系ファイルに属するディレクトリ
/opt はHPC計算機上で動作するアプリケーションが利用するファイル類を置いておくディレクトリーです。その内容も固定的なものが多いことが特徴です。また殆どは読み出しで利用されます。ひとつのアプリケーションが起動する場合には実行ファイルだけでなく各種ライブラリ類やネットワーク情報、ライセンス情報など多くのファイルを順次読み出して起動が完了します。この読み出しが遅れるとアプリケーションの起動も遅れます。
/usr、 /home は主に利用者 (人間) が対話型の処理で使うファイルを保存するディレクトリーです。その内容も固定的なものが多いことが特徴です。そのためシステムの規模の大小や処理速度の高低によって容量のサイズが大きく変化することはありません。
◇ ワーク系ファイルに属するディレクトリ
/work は主に計算機が出力したファイルを一時的に保存しておくディレクトリーです。データのサイズが大きく、書き込み速度が速く、複数の計算機から平行して書きこまれます。そのため容量の大きさと速度の速さが優先されます。ある程度の耐障害性は必要ですが、万全の復旧は求められません。
/scr (/highspeed-work) は主に計算機が入出力するファイルを一時的に保存しておくディレクトリーです。ストレージの種類としてはRAID0やラスターファイルシステムなど、単体のファイルサーバでは不可能な超高速ファイルI/Oを実現します。このストレージは高速処理を優先し冗長性はありません。超高速処理と信頼性の双方が必要な場合は、別にバックアップを作成する必要があります。
DASを用いたNAS型ストレージ
DASを用いたNASストレージはHPC計算機に適しています。サーバのPCIeスロットにRAIDコントローラを搭載し、そのRAIDコントローラから高速なマルチレーンSAS接続でハードディスクを繋ぎますから最高の性能が得られます。
ストレージ規模のスケーラビリティーもディスク１個から１００個以上までの幅広さがあります。価格もサポート付きで廉価に導入できます。信頼性も冗長化を階層化させることで柔軟に向上させることができます。
DASで課題があるとすれば、ディスクアレイの管理をサーバ側で行わなければならないことです。バックアップ処理、リストア、データ移動などを全てサーバのプロセッサとサーバのネットワを介して行います。これらの作業はストレージの容量が小さい間は現実的ですが、容量が大きくなるに従って非現実的になります。
SANを用いたNAS型ストレージ
DASを用いたNASストレージの課題を解消できるストレージソリューションがSANを用いたシステムです。SANは古くから大型計算センター利用されてきたストレージの管理システムです。
NASの特徴はディスクアレイの管理はSANサーバ側が一元的に行い、NASサーバ側の管理はサーバ側が行うという、ストレージ部とサーバ部を階層化している点が最も大きな特徴です。SANの特徴を次に挙げます。
- 複数のホスト機と複数のストレージを専用ネットワークを介して "多対多" で接続できる
- 一台のストレージ上のボリュームを仮想化し複数のサーバに提供することができる
- ストレージ上のボリュームをSANを経由で他のストレージに転送できる
- ホスト機が障害を起こした場合、他のホスト機に再接続することができる
- データ転送は専用のストレージエリアネットワーク上で行う (他に影響しない)
- 既存のホスト機へ新しいストレージを追加することが容易
このように計算センターで育まれたストレージエリアネットワークはストレージの運用と管理を便利に行うことができます。そのため業務用のストレージとして広く普及しました。
Fiber ChanelはHPC用としては高価すぎる
現在ひろく普及しているFiberChanelは業務用のシステムのため低価格化には限度があります。大量のストレージを必要とするHPC分野には価格が高過ぎ導入できる場合は大型計算機センターなどに限られています。
iSCSIを用いたSANはHPC用として利用できる価格帯を実現
SANが普及することを阻んでいたFiber Chanelの価格の壁を破り、さらに既存のネットワークスイッチとの互換性を実現したSANの規格が "iSCSI" (Internet SCSI、アイスカジー) です。
iSCSIは、広く普及し低価格化はたイーサネット用のハードウェアを利用し、下位階層のIPネットワークの上にSCSI用のプロトコルをパケット化して通信できるようにした実装です。そのためiSCSIは既存のイーサネットカードに専用のソフトウェアスタックを実装するだけでiSCSI化することができます。さらに、iSCSIは既設のイーサネットスイッチと互換性があるため、スイッチに空きがあれば既存のスイッチに相乗りすることができます。あるいは新設する場合も廉価なスイッチを利用することができます。もちろんイーサネットカードやネットワークケーブルなども既存の製品を利用できます。iSCSIはこの高い互換性が特徴です。
iSCSIで課題とされていた、サーバ側のプロセッサを用いて行われる通信処理については、ネットワークカード側でその処理を行う "TOE" と呼ばれる機能を搭載したiSCSIカードが製品化されています。そのカードを利用することでサーバ側への負担が軽減され、システム全体の性能向上にも貢献しています。
参考価格をご紹介
参考にHPC-ProServer DPvMD3200i/3220i の概算価格をご紹介します。RAIDコントローラと４基のGbEポートを備えたコントローラ装置付きの本体が約１００万円です。この本体に内蔵ディスクを搭載すると基本システムが完成します。例えばRAID6で20TBの物理ボリュームを実現できる2TBの3.5" SAS 7200回転ディスク１２個のディスクと本体の合計金額は約１９０万円です。
さらにディスクを指追加する場合は、弊社のDAS用のストレージをディジーチェーン接続できます。接続できる最大ディスク数は９６個です。2TBディスクを利用すると192TBの物理容量を実現できます。この追加ストレージは単なるDASです。価格もDASの価格です。
サーバに搭載するiSCSI対応オフロードエンジンを搭載したDual-Port GbE NICの価格は約２万円です。システムのカギとなるGbEスイッチは一般のイーサネット用のスイッチがそのまま利用できます。
このようにiSCSIストレージシステムはDASを用いたNASにかなり近い価格です。しかも、容量を拡張するに従って価格差は小さくなります。ます。さらに、保守運用の容易さ、信頼性の高さ、万一の障害時の耐障害性の高さなどを総合的に判断するとコストパフォーマンスではDASを用いたNASを超えています。
将来へ備えたiSCSI化
iSCSIの価格を見ると、DAS型ストレージよりも若干ですが高価です。それでもiSCSIを導入するメリットはあるのでしょうか。あるとすればどのような点なのでしょうか。
iSCSIをこの時期から導入するメリットは、将来のiSCSI化へ向けての助走をつけておく意味があります。ストレージを総iSCSI化しSAN化してゆくためには何年もの時間がかかります。今導入したストレージがDAD型ファイルサーバであれば、将来のデータ移行で課題を抱えることになります。そのため、データが巨大化する前にストレージのiSCSIを部分的に開始しておくことは意味があります。
つづく