電話 03-6410-6070、FAX 03-6410-6073 電子メール ｉｎｆｏ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ / ｓｕｐｐｏｒｔ＠ｈｐｃ−ｔｅｃｈｎｏｌｏｇｉｅｓ．ｃｏ．ｊｐ (アドレスは半角に変更して利用)
研究室のHPC環境をグリッド化
研究室に導入されるシミュレーション用の計算機は増加する傾向にあります。これらの計算機は導入の時期や目的によって仕様が異なるため研究室には様々な計算機が散在することになります。このような計算機システム上で複数のユーザが異なるアプリケーションを利用するとシステムの操作性、処理速度、処理効率が低下するという問題が起こります。
このような問題の解決手段として計算機システム全体を「グリッド化」するという方法があります。一般に「グリッド」とは、各地に散在するスーパーコンピュータやPCクラスタなどの計算リソースをネットワークで結合し、適切なミドルウェアによって単一の「仮想化HPC計算機」を実現する技法のことです。計算機システムをグリッド化することによってシステムの操作性、処理速度、処理効率を同時に向上させることができます。この技術を研究室の計算機システムに応用しても同様の効果を得ることができます。
研究室の計算機システムをグリッド化することにより、ユーザはグリッド環境にログインするだけで、計算機、PCクラスタ、ストレージ、アプリケーション、開発環境、ソフトウェアライセンスなど、システム内の計算リソースを自由に使用できるようになります。さらにシステムの構造が整然とするため全体の見通しが良くなります。その結果、ユーザとして利用するだけなら十数個のコマンドを知っているだけで十分な操作ができるようになり、操作性が向上します。
グリッド化されたHPC計算機にジョブを投入すると、自動的に最適な計算機にジョブが振り分けられるようになります。すなわち、大容量メモリジョブは大容量メモリ計算機へ、OpenMP並列計算ジョブはOpenMP並列計算機へ、ネットワーク並列計算ジョブはネットワーク並列計算機へと、複雑なマッチングでも適切に割り振られます。その結果、システム全体のピーク性能を発揮させることと、スループット性能を維持させることの両立が可能になりました。
グリッド化されたHPC環境ではストレージ環境の高機能化を行うことができます。これまで個々のシステム別に導入していたストレージを、全てのシステムから共有できる高機能なストレージプールとして運用することが可能になります。例えば、中容量-高信頼性ストレージ、大容量-高速ストレージ、超大容量-アーカイブ専用ストレージなどのように機能別に構築したストレージを、グリッド環境上でストレージプールとして共有できるように設定し、各ストレージの長所を活かした運用をすることができます。さらにストレージの管理を一元化することで管理水準の向上、信頼性の確保、障害時の対応の強化を同時実現できます。
グリッド化により計算機システムのセキュリティー水準を向上させることが容易に行えます。システム管理を一元化し、外部からとの接続箇所を集約させることでシステムの安全性を向上させることができます。また、ユーザ情報やネットワーク情報も一元的に管理でき管理水準を向上させることもできます。
グリッド環境の構築には手間と費用がかかります。この問題をクリアするため弊社では「HPC専用マスターサーバ」を製品化しています。「HPC専用マスターサーバ」には弊社がこれまで蓄積してきたHPCやLinuxについての知識と経験を惜しみなく注ぎ込んで完成させたグリッド環境とストレージ環境を搭載しています。しかも導入時や導入後の技術支援サービスと運用支援サービスを行っています。そのため、Linuxの経験が少ない研究室であっても「HPC専用マスターサーバ」を導入するだけで短時間かつ低コストで本格的な「グリッド環境」を構築することができます。
グリッド環境を実現する仮想化技術
HPC環境のグリッド化は次の４種類の仮想化技術によって実現されています。仮想化によって複雑な構造の「実際の計算機」が、単純な構造の「仮想HPC計算機」に変貌し、操作性の向上、処理速度の維持、スループットの向上、を同時に実現しています。
◇ 計算資源の仮想化 ： サーバ、開発環境、アプリケーションなどを仮想化
◇ 計算機の仮想化 ： サーバを複数のクラスタに統合し仮想計算機化
◇ ジョブ投入の仮想化 ： 複数ユーザからのジョブ投入を仮想的に受け付け
◇ ストレージの仮想化 ： 複数のストレージから仮想的なストレージを構築
グリッド環境の設計では各仮想化システムが基礎コンポーネントとなり、それを組み合わせて利用することでグリッド環境を実現しています。
◇ 計算資源をシステム全体から使用できるように定義
◇ 計算機をグループ化、実行可能なジョブ数、並列度、メモリサイズなどを定義
◇ ジョブの特性に応じたジョブキュー (待ち行列) を定義
◇ ストレージの構造、利用方法、運用ポリシーを決定
グリッド環境の利用は簡単です。ユーザはジョブに対応したジョブキュー (仮想的な実行環境) に対して専用コマンドを用いてジョブを投入するだけの操作です。以降はグリッド環境が自動実行します。投入されたジョブは待ち行列に蓄積され、決められたルールに従って計算機に投入されます。処理が完了すると結果ファイルはユーザのホームディレクトリに返されます。
計算資源の仮想化
グリッド環境では「計算資源の仮想化」が重要な役割を担っています。Linux OSは優れたクライアント・サーバ機能を持ち、完全なネットワーク・コンピュータ環境を実現します。そのためログイン先のホーム領域上から全ての計算資源を見渡すことができ、利用することができます。対象となる資源はCPUやメモリだけでなく、ストレージやネットワークなどの物理デバイス、開発環境やアプリケーションなどのファイル類なども含まれます。Linux OSの機能により実現される単一の仮想的なネットワークコンピューティング空間はグレッド環境の利用基盤を構成することになります。
◇ 全ての計算資源が抽象的な名前として管理される
◇ 全ての計算資源をネットワークコンピュータ化できる
◇ システム情報も全体で共有される
◇ システム全体の見通しが良くなる
◇ 少し (十数個) のコマンドを知っているだけで基本的な操作が可能
「計算資源の仮想化」をすることでシステム全体を遠隔操作することが可能になります。もし全てを遠隔操作することが出来るようになるなら、その操作プログラムの品質を高度化することで、より複雑な操作が可能になります。その完成形が「ジョブスケジューラ」と呼ばれるソフトウェアです。
ジョブスケジューラの働き
計算機を次々に導入すると仕様の異なる計算機が混在しジョブの管理が難しくなります。このようなシステム環境では次のような問題が発生します。
◇ 計算機は沢山あるのに空いている計算機を見つけることが難しい
◇ 小さなメモリの計算機に大規模ジョブを流すようなミスマッチ
◇ 並列計算機にシリアルジョブを流すようなミスマッチ
◇ 並列計算機の空きを待っていたら他のジョブが流された
◇ 計算機が混んでいて急ぎのジョブが流せない
◇ 膨大な数の小規模ジョブを能率良く流せない
◇ 共有ソフトウェア環境が変更されアプリケーションが不安定化した
◇ アプリケーション・ライセンスの利用効率が低下した
◇ ファイルサーバが複数あるためファイルが行方不明になりやすい
◇ etc
このような問題は「ジョブ管理」の不十分さに原因があります。そこでこのような混乱を解決するためジョブ投入のルールを定めると、今度はジョブ管理の方に大きな手間を取られるようになります。ジョブ管理は面倒な作業なので。その大変さを知っていただくためにジョブ管理に必要な手続きを示します。このような作業が各ジョブ毎に必要です。
ジョブ受付 → ジョブ確認 →
計算機とのマッチング → 計算機予約 →
計算機の空き確認 → ジョブ投入 →
ジョブ監視 → ジョブ終了確認 →
計算完了連絡 → 後片付け
このような作業を人間が的確に行うことは不可能です。そこで考えられた方法がコンピュータによって自動的にジョブを管理する「ジョブスケジューラ」の開発でした。完成の域に達した現在のジョブスケジューラは２４時間のシステム監視と的確なジョブ投入を複雑な計算機システムに対して安定して行うことができるようになっています。
ジョブスケジューラには次の４つの機能が搭載されています。
◇ 計算機の動作状況の監視
◇ 投入されたジョブの管理
◇ ルールに則った公平なジョブ投入
◇ ジョブと計算機の適切なマッチング
この機能によって次のような処理を行っています。
◇ 優れたアルゴリズムによる公平なジョブ投入
◇ 計算機の動作状況に応じた最適なジョブ投入
◇ ジョブの種類に適した計算機の選択
◇ ネットワーク並列機とマルチコア計算機が複合した環境での適切なジョブ投入
◇ 実行中のジョブを監視と異常処理に対する対応
◇ ジョブの完了報告と次のジョブ実行の準備
ジョブスケジューラの使い方は難しくありません。数個のコマンドを使うだけで日常的な処理のほとんどを行うことができます。極論すればジョブ投入、ジョブ停止、ジョブ状態表示を行うコマンドが使えれば実用に足ります。計算機が終了するとその旨を通知するメールが届き、計算結果は元のディレクトリに戻ってきます。
ジョブスケジューラを利用すると次のようなことをユーザが気にする必要はなくなります。
◇ どの計算機が空いているのか
◇ どの計算機が適しているのか
◇ 順番待ちをしている人は誰なのか
ユーザは自分の都合で自由にジョブを投入することができ、ジョブ管理のストレスから解放されます。
現在のジョブスケジューラは完成度が高く、複数の異なる仕様のマルチコア計算機を用いたネットワーク並列計算機と、複数の異なる仕様のマルチコア計算機から構成された、複合的なクラスタシステムに対して、複数のユーザが複数の並列度や利用メモリサイズ、計算機時間の異なるジョブを大量に投入しても、公平な順番で適切な計算機に効率よく割り当てることができます。
ジョブスケジューラはUnix計算機が全盛の時代から利用されてきた実績のあるソフトウェアです。当時主力のUnix計算機は数千万円から数億円もする高価なシステムでした。それらを共同利用するためには公平かつ的確にジョブ管理する必要がありました。そのような背景で開発されたジョブスケジューラは高い機能と信頼性を備えたミドルウェアとして成長しています。
Linux環境利用負担の低減
現在の科学技術計算用アプリケーションの多くはLinux環境上で開発されています。そのため本格的なシミュレーションを実施するたにはLinuxやHPCクラスタの知識は必須とされていした。しかしLinuxの学習がユーザの目的ではありません。できれば、Linuxによるシステム構築まで深入りすることなく、LinuxやHPCクラスタを用いたソフトウェア開発環境やアプリケーション利用環境を、単なる一般ユーザとして利用することができれば理想です。
市販のLinuxサーバやPCクラスタを導入するだけでこのような希望をかなえることは困難です。満足できるようなシステムを実現するためには、ソフトウェア開発環境、アプリケーション実行環境、並列処理環境、ストレージ環境、ネットワーク環境、ジョブ管理環境、セキュリティー環境などの整備が欠かせません。しかし市販のLinuxサーバやPCクラスタにはHPC独特の環境整備は含まれていないか、あるいは含まれていても一部の整備に限られます。使いやすいHPC環境の整備はユーザが自分で行うか、あるいはHPC専門のSEを派遣してもらって行うことになります。しかしそれでも思い通りの環境を実現するためには長い試行錯誤の期間が必要です。
この課題を解決するために「HPC専用マスターサーバ」を採用することは優れた方法です。「HPC専用マスターサーバ」は本格的なHPC利用環境を実現することができるシステム環境を内蔵しています。そのため「HPC専用マスターサーバ」に通常のLinuxサーバやPCクラスタを接続し設定を変更するだけで、グリッド化やクラウド化にも対応した本格的なHPC環境を構築することができます。「HPC専用マスターサーバ」には次のような機能が搭載されているか、あるいはオプションとして設定されています。
◇ ソフトウェア開発環境
◇ アプリケーション実行環境
◇ 並列処理環境
◇ ストレージ環境
◇ ネットワーク環境
◇ ジョブ管理環境
◇ セキュリティー環境
「HPC専用マスターサーバ」を利用したHPCクラスタの構築方法を採用することで、均質かつ高度なHPCクラスタの構築を確実、短時間、低コストで実現することができます。ユーザは手間のかかるHPC環境の構築作業と管理作業から解放されシステムの利用に専念することができます。
ローカルの計算機と、計算センターの計算機
計算センターのシステムにPCクラスタが採用されるようになったことで幾つかの点で使い勝手が向上しています。それらは次のような点です。
◇ 標準的なCPU、OS、開発環境の採用により一般の計算機との互換性が実現した
◇ CPU数が増えた
◇ インストールされるアプリケーションが増えた
◇ 利用料金が下がった
◇ (保守運用の手間がいらない)
このようなメリットがあるなら計算センターを利用できるユーザは手元に計算機を導入する必要性は無いように思えます。現実には計算センターにも課題があり、完全に依存する場合のデメリットを考慮しておく必要があります。
◇ 利用者数が多い
◇ 混雑する時期がある
◇ 利用制限時間が短い
◇ 巨大ジョブを流しにくい
◇ 搭載されてアプリケーションが限られている
◇ 定期的保守のため停止する
◇ 更新サイクルが長く陳腐化する期間が長い
このようなデメリットを克服し、計算センターの長所を存分に利用するためには、手元に計算センターを補完するような構成の計算機環境を整備し、双方を組み合わせて利用することが効果的です。手元の計算機のメリットは次のようなものです。
◇ 最新の計算機を利用できる
◇ 最新のアプリケーションを搭載できる
◇ 多彩なアプリケーションを搭載できる
◇ 特殊な目的に最適化したシステムを構築できる (大メモリ、高速ディスク、高速ネットワーク)
◇ 超長時間ジョブや大規模並列ジョブを実行できる
◇ ハードウェア、OS、ソフトウェア、開発環境の一貫性を維持できる (バージョン管理が可能)
◇ 独自の優先順位に従って計算を流せる
◇ 大量のファイルを安全に長期間保存できる
柔軟で思い通りの構成が可能な手元の計算機をベース計算機として利用し、計算量の確保や計算規模の実現などのような点については計算資源の豊富な計算センターを利用するというような使い分けが可能です。
なお、手元の計算機には次のようなデメリットがあります。
◇ システムの設計、構築、管理に手間がかかる
◇ 設置場所が必要
◇ 電源、空調などが必要
このようなデメリットの解決についても考えてみます。最初の「システムの設計、構築、管理に手間がかかる」という問題は、それら一切をアウトソーシングすることで解決できます。特に現在では弊社のように、大手ベンダー製の品質に優れサポート体制も充実した計算機をベースに用いて、そのうえに高度なシステムインテグレーションと技術・運用サポートを提供する、ハイブリッド型のHPC専業システムインテグレーターも登場したことで、高品質なHPCクラスタ製品を、安心して導入していただけるようにむなっています。その結果、ユーザはシステム構築の監督と、利用にに専念することができるようになりました。
設置場所の問題はラックマウント型計算機の導入によって解決できます。あらかじめ増設や入れ替えを考慮してラックを導入しておくことで計画的に計算ノードを新陳代謝を行うことができます。縦方向の増設ですから床面積が増えることはありません。ラックは施錠ができるのでセキュリティー対策にもなります。現在のラックサーバは騒音も抑えられているため設置場所の制約が少なくなっています。
空調と電源は拡張計画にも対応した十分な容量が必要です。弊社ではご相談に対応いたします。
HPC専用マスターサーバで計算機を仮想化
マスターサーバの機能
HPC計算機のマスターサーバ (管理サーバとファイルサーバ) は黒子的な役割のため過小評価されています。しかし、マスターサーバが基礎を支えていることでHPCクラスタは最高の状態で稼働できます。HPCクラスタを自動車に例えると、マスターサーバはハンドルやメーター、カーナビ、座席などの役割を担い、HPC計算機はエンジンの役割を担っています。マスターサーバの役割は極めて重要です。その概要をご紹介します。
本格的なマスターサーバは次のような機能を搭載しています。
- ログインサーバ
- 情報管理サーバ
- アプリケーションサーバ
- 開発サーバ
- ライセンスサーバ
- ファイルサーバ
- バックアップサーバ
- ジョブスケジューラ
このような機能を搭載しているマスターサーバにより次のようなメリットが得られます。マスターサーバを導入することで、個々のユーザが計算機システム全体を透過的に利用できるようになります。
- 計算ノードやストレージを抽象化し一元的に取り扱える
- 計算機の詳細な情報を把握できる
- ユーザ情報やネットワーク情報を一元管理できる
- セキュリティーが向上する
- アプリケーションをシステム全体で共有できる
- 開発環境を共有しコンパイルできる
- ライセンスを一元管理できる
- 信頼性の高い大容量ストレージを利用できる
- ストレージのアックアップを実施できる
- 複数ユーザの計算機へのジョブ投入状況を把握できる
- システムの利用状況とユーザのジョブ投入状況を元に最適なジョブ投入をスケジュールできる
- 並列計算ジョブも最適なジョブ投入が可能
- 遠隔地から全てを操作できる
サーバの構築は経験工学です。HPC計算機は独特の構成を持つため一般的なシステム構築とは異なります。そのため一般的なシステム構築の経験は役に立ちません。そこで完成品のマスターサーバを半完成品で提供します。ホームページに掲載している構成でも十分実用的です。ご希望に応じて細部の変更もできます。さらに複数のサーバを直交的に組み合わせ大規模なマスターサーバシステムを構築することも可能です。このようにシステムの側からみるとマスターサーバこそがHPC計算機の本体であり、CPUサーバの方は交換可能なサブモジュール的ポジションにあることがわかります。
マスターサーバはシステム全体を基礎で支える装置ですから品質の高さは基本です。マスターサーバに品質が高く確かなサポート体制を敷く大手ベンダー製のサーバを採用することは良い選択です。
| サーバ区分 | 大手ベンダー (Dell) 製サーバの特徴 | 互換サーバの特徴 |
| 製品特徴 | 部品レベルの徹底なバリデーション 部品メーカーと共同で品質改善 販売後もファームウェア等のアップグレード 保守部品へも改良をフィードバック (品質維持のため選択肢を制限) |
膨大な互換部品を自由に組み合わせて 多様な製品を実現 検証は自己責任 問題は発生してから対策 (選択肢の多さが品質管理に重し) |
| 製品管理 | 製品をデータベースにより単品管理 | 不詳 |
| 修理作業 | 全国のサポート拠点から当日/翌日訪問 | センドバックが基本 |
| 修理部品配送 | 全国展開する物量拠点から当日配送 | センドバックが基本 |
| 修理部品提供 | 製品EOL後から５年間の修理部品提供 | 不詳 |
| サービス区分 | 弊社技術サービス | 他のサービス |
| 設計サービス | 技術スタッフが設計支援 | 不詳 |
| 構築サービス | 専用工場にて責任製造 | 不詳 |
| 保守サービス | 障害時には担当者が復旧支援 | 不詳 |
| 運用サービス | オンサイト設置、ネットワーク接続 OS、ストレージ、システム管理ツール 開発環境、ネットワーク、並列環境 特定アプリケーションまでの利用サポート |
不詳 |
| 管理サービス | システム復旧までサポート | 不詳 |
マスターサーバで利用するストレージは高い信頼性が求められます。約５年間の利用期間中の故障を抑え、もし故障しても被害を最小にする工夫が求められます。故障が少ないストレージを作るためには枯れた標準技術の利用と、数が出ている製品を採用することが基本です。発売されてから半年の製品よりも１年の製品を、販売台数が千台の製品よりも一万台の製品を採用することです。
Linuxを利用すると複数のシステムを直交的に組み合わせ速度を容量を実現することが容易に行えます。基本となるモジュールは信頼性を追及し、速度や容量はこの階層では断念します。それらの追及は上位の階層での実装の工夫で実現することが基本です。Linuxを利用し直交的なシステムを設計を採用することで、使い易さと速度と容量を兼ね備えた素晴らしいストレージを構成することができます。
補助機器類
マスターサーバは基礎を支える製品です。そのため他の基礎製品と組み合わせて利用されます。これは相互に緊密に関係するため整合性の確認された製品の利用が望ましいです。さらに、サポートの体制や期間も合わせることが望まれます。
- ネットワークスイッチ類
- EIAラック
- KVMスイッチ
- コンソール
- 無停電電源装置
次のようなソフトウェア類の提供とセットアップサービスも一括して提供することが望まれます。
- 開発環境
- アプリケーションソフト
- ジョブスケジューラ
HPCクラスタ化の実際
システムの構築
シミュレーションの実施は少数の計算機の導入から始まります。暫くしてシミュレーションの有効性が確認されると計算機の追加導入が始まります。この段階での計算機の管理は紳士協定によるスタイルが通常です。計算機を管理するノウハウを持っている研究室は少数です。
ところが計算機の台数がさらに増加すると紳士協定の限界が訪れます。個々の計算機は正常に動作していても、システム全体に細かな不整合性が蓄積されてゆきます。その不整合が進むと利用できないジョブも現れます。それを予防するため計算機がグループ化 (専用機化などのバリエーションは多数ある) されます。その反作用として利用効率は低下します。
- 計算機の台数が増える
- システム管理が追いつかなくなる
- 計算機を個人管理に委ねる
- ソフトウェア環境が拡散する
- ファイルが分散する
- アプリケーションが分散する
- ライセンスが分散する
- 計算機のグループ化 (専用機化) が進む
- 利用効率が低下する
- システムが使いにくくなる
その対策が考えられます。基本は本格的なファイルサーバの導入です。ファイルサーバによって散らばっているストレージを集約することができ、透過的な利用環境が実現できます。
- 本格的なファイルサーバの導入
- ストレージの集約
- ストレージの信頼性向上
- ファイル転送速度の向上
基本的なNFSサーバの構築と接続では容易に行うことができます。しかし、ここから先のシステム設定はサーバの構築経験が必要になってきます。その手間を省くためNFSサーバの構築とシステム設定を外注することができます。外注する場合はNISの設定やジョブスケジューラの設定などもまとめて頼むことができます。ファイルサーバと併せて作業依頼すると経済的です。
ファイルサーバを導入することで分散していストレージを集約するとユーザファイルのみならず、連鎖的に次のような機能モジュールも集約されます。
- アプリケーションの集約
- OSやコンパイラなどの利用環境の集約
- ライセンス管理の一元化
ファイルサーバの導入により計算機の動作環境の整備が進むと計算機のリモート利用が安定して出来るようになります。ネットワーク情報の管理を行うことで、任意の端末から別の端末にログインし自由に使用できる環境が整います。
NISを導入するとこで、ログイン用サーバを限定しポートを一本化することもできます。するとセキュリティーが向上し、管理レベルも向上し、システムの使いやすさも向上します。ジョブ管理機能を持つジョブスケジューラの導入も可能になります。
- NISの導入
- ログインサーバを用いたシングルシステムイメージの実現
- ジョブスケジューラの導入
このような環境が整備されると立派なHPCクラスタです。システムの使い勝手は格段に良くなります。クラスタ化することで以前と比較すねと見違えるような計算機環境になります。
- CPUやメモリなどの計算資源はジョブスケジューラによって動的に管理され利用効率が高くなる
- 異なる構成の計算機や並列計算機が混在してもジョブが適切に割り振られるようになる
- ユーザが増えても資源が公平に分配され待ち時間も短縮される
- ファイル管理やユーザ管理も適切に行われるようになる
- システムの信頼性やセキュリティー水準が向上する
- 列計算や大量ジョブの自動処理も可能になる
後継者問題
管理者の尽力によって完成した計算機環境には次なる伏兵が待ち構えています。それが後継者問題です。管理の後継者を決めておかないと将来の利用に赤信号が灯ります。なぜなら、HPCクラスタの設計、構築、運用、管理は簡単な仕事ではありません。幅広いHPCについての知識と経験が必要です。しかし誰もが自分の仕事で忙しくHPCクラスタ構築技術の勉強に時間を割くことが難しいのが現実です。
後継者問題の解決にはアウトソーシングの活用が効果的です。ユーザは計算機の監督に徹し、計算機の設計、構築、管理の実務は外注化することができます。HPC計算機の研究室での導入は着実に地歩を築いており、それを支えるHPC業界というものも形成されてきています。
弊社でもそのようにご要望に応えるため、HPCクラスタ専用のマスターサーバ製品「HPC-ProFSシリーズ」を製品化しています。さらにハードウェアと併せて導入することで高度なHPCクラスタ構築・維持管理を実現する「HPC技術サービス」の製品化も行っています。「HPC技術サービス」は弊社のクラスタ構築技術を標準パッケージ化した製品てす。標準化することで低コストと高完成度を両立しています。「HPC-ProFSシリーズ」と「HPC技術サービス」を併せて導入することで実現するぱケージ製品です。
「HPC技術サービス」は使いやすいようにパッケージ化された技術なので、必要事項を専用フォームに記入するだけで完成度の高いHPCクラスタ環境の構築を行えます。システムの設計、組立、導入、技術サポート、運用サポート、保守サービスは専門家が一貫して実施します。管理者の方は作業確認だけですから手間はごくわずかです。管理者の方の交代も簡単な引き継ぎだけで終わります。システムがパッケージ化されていますからシステムの構築・維持管理の連続性が保てます。
「HPC技術サービス」と「HPC-ProFSシリーズ」
「HPC技術サービス」は「HPC-ProFSrシリーズ」、「HPC-ProServerシリーズ」とシリーズ化して利用することを前提としたサービスです。ハードウェアをシンプル化し事前に徹底的な検証をおこなうことでシステムレベルでの高い品質を確立しています。その安定した基盤のがあるからこそ、高度なソフトウェアサービスを行っても安定しておこなうことが可能です。
既存の機器をお持ちの場合でも、ファイルサーバや管理サーバとしての基本的な機能までのサポートで良ければ、機器の提供とサービスの提供を行います。ただしこの場合は、クラインアント機側の設定はお客様に行っていただきます。
HPCクラスタはPCサーバとLinux環境の自由に組み合わせて構築しています。必要な機能を自由に組み合わせて求めるシステムを構築できるようにみえますが、表面的に動いている組み合わせでも、深層に問題が潜在する場合があり、利用条件によっては問題が顕在化する可能性を持っています。このような問題の可能性を事前に予測することは不可能です。安定稼働するシステムの設計には多くの経験の蓄積が必要です。
HPCクラスタで使用するマスターサーバの設計ガイド
このページでは、HPCクラスタで使用するマスターサーバ (管理サーバ、ファイルサーバ) の実用的な構成例をご紹介します。マスターサーバは次のような多くの選択肢があり、用途と規模に応じて構成は千変万化します。
- CPU、メモリ、ハードディスク、ネットワークなどの内部構成
- RAID1、RAID10、RAID6、RAID60などのストレージ構成
- ラック型、縦置き型などの設置形態
- OS搭載、システム設定、ミドルウエア搭載などのシステム構築
- ライセンス管理、ユーザ情報・ネットワーク情報の管理
- セキュリティーの向上
- 設置、運用、保守
しかしこれらの選択肢から適切な項目を指定し、完成度の高いマスターサーバを構成することは容易ではありません。そこで各サーバ別に、マスターサーバの標準構成例を準備し、製品を選択するだけで簡単にマスターサーバを導入できるようにしました。あわせて参考価格も表示し積算にも配慮しています。
ここに掲載しているマスターサーバの標準構成例は十分に実用的です。しかしさらに最適化するため、用途に応じて内容を変更することも可能です。また、大規模なHPCクラスタに使用する場合は、複数のサーバを組み合わせることで、スケーラブルに機能と容量の拡張をおこなうこともできます。
HPCクラスタで使われるマスターサーバの役割は重要になっています。そのためマスターサーバを設計する際の注意点も増えています。このページでは、マスターサーバを設計する上で知って頂きたい基本的な事項についても紹介しています。
高可用性、高性能、大容量が求められるマスターサーバ
HPCクラスタが高速化するとマスターサーバが性能不足に陥り、ユーザがストレスを感じることがあります。予想した時間に計算が終了しない、ファイルサーバが遅くなった、コマンドへの反応が鈍い、などのような症状が続くと困ります。このような症状の一因としてマスターサーバの性能不足が考えられます。
HPCクラスタのマスターサーバは次のようなサービスを提供することによりHPCクラスタの快適な利用環境を実現しています。
- NFSサービス、バックアップ処理などのストレージ関連サービス
- HPCクラスタ全体のCPU状況、メモリ状況、通信状況などの監視
- ジョブ・スケジューリング、リモートログインノード機能などの資源管理サービス
- ネットワーク情報やユーザ情報提供などのネットワーク関連サービス
- 開発環境の提供
- ユーザアプリケーションの提供
しかし、これらの処理は重くしかも相互に依存しているため、一部の処理が過負荷になり応答に遅れると他の処理も影響を受け、連鎖的にマスターサーバの処理全体が停滞する場合があります。
HPCクラスタを中心で支えるマスターサーバが過負荷になり処理が停滞するとHPCクラスタ全体が不安定になります。このような現象を防ぐためにはマスターサーバに十分な性能が必要です。そこで、高性能なマスターサーバを設計する時に注意してほしい点を順に説明します。
HPC計算機に理想的なLinux OS
Linux OSは理想的なサーバの運用を目指して開発されたOSです。ネットワークで接続されたサーバやストレージを仮想化し、それらを一体のものとして取り扱うことができるようにします。この考え方はHPC計算の利用スタイルでは非常に効果的です。HPC計算機の構築ではLinuxの長所を取り入れてシステム設計が理想です。
マスターサーバに接続されたクライアント機やストレージなどは、HPCクラスタを構成するコンポーネントとして仮想的に取り扱うことができます。仮想化されたコンポーネントはOS上でリスト化でき一体的に見ることができます。
リスト化された各コンポーネントをコマンドを使って操作することができます。さらに、リスト化とコマンドを組み合わせたファイルをスクリプトとして実行することができます。
手動で行うコンポーネントの操作をスクリプト化して自動操作することができます。
ジョブスケジューラを利用すると、各コンポーネントの動作状況を自動的に収集することができます。CPUコアの数と稼働状況、メモリのサイズと利用状況、動作しているアプリケーション、利用しているユーザ名など、現在投入されているジョブの詳細を把握することができます。
ジョブスケジューラは現在動作している計算についての情報の他に、投入を待っているジョブの情報も持っています。この双方の情報を使い、予め決められたジョブ投入ルールに従って細かなジョブスケジューリングが可能です。
ジョブスケジューラを介してジョブ投入することでジョブ実行の記録を残すことができます。
マスターサーバには遠くの端末からネットワーク越しにログインし、システム全体を一括して操作することができます。システムの構成が異なっていても、システムの所在地が多少離れていても、システムは仮想的に一体化して見えます。
システムはTSS (タイムシェアリング) により仮想的に複数のサーバが動作しています。そのため、複数のユーザが同時にログインしていてもシステムを独占しているように利用できます。
ジョブの実行についてはジョブスケジューラを利用することでバッチ処理が可能です。バッチ処理を利用することで、計算機に同時投入できるジョブ数を指定することができ、メモリの使い過ぎによるコアダンプや、CPUの性能低下を避けることができます。
マスターサーバの性能チューニング
CPU
新しいXeon (Nehalem)の特徴は並列処理性能の高さです。それを実現するため、CPU内部の通信、CPU間の通信、CPUとメモリ間の通信、CPUとPCI Express間の通信などが独立して行えるようにアーキテクチャが改良されました。さらに通信方法も、従来のバス接続による逐次通信方式から、マルチレーン化されたシリアル通信による並列通信方式へと改良されました。これらの改良により計算機内部の通信性能は劇的に向上しています。マスターサーバを構築する場合はこのようなアーキテクチャの特徴を活かし、並列処理性能を高める構成を工夫することで良いスループット性能を得ることができます。
現在のXeon (Nehalem)はアーキテクチャの改良により、CPUコア数に比例して整数演算スループット性能が向上します。また、HT (Hyper-Threading Technology) と呼ばれるCPUコアを仮想的に増やす技術が採用され、この技術もスループット性能向上に寄与しています。その結果、過去のXeonと性能は約１．８倍にも向上しています。(SPEC int rate base 2006 ベンチマーク結果に公開されているDell Xeon X5460 3.16GHzとDell Xeon X5570 2.93GHzの結果を参照比較)
計算機内部の通信性能が向上したことで、CPUクロック速度の上昇に比例して整数演算スループット性能も理想的に向上するようになつています。エントリー構成のXeon E5506 2.13GHz 4MBキャッシュ 2CPU機と、標準構成のXeon E5530 2.4GHz 8MBキャッシュ HT Turbo-Boost 2CPU機との性能比は約１．５倍もあり、ハイパーリニアな性能向上が発揮されています。さらに、標準構成機と、最高構成のXeon X5570 2.93GHz 8MBキャッシュ HT Turbo-Boost 2CPU機との性能比は約１．２倍です。こちらも良い性能向上を示しています。上位ランクのCPUは高価ですが、システム全体を高速化する効果が価格差を吸収する場合もあります。(SPEC int rate base 2006 ベンチマーク結果に公開されているDell Xeon X5506 2.13GHzとDell E5530 2.4GHz、Dell Xeon X5570 2.93GHzの結果を参照比較)
現在のXeon (Nehalem)にはスループット性能を向上させる新しい技術が採用されています。それが効果を発揮した例が前項で紹介したXeon E5506とXeon E5530との比較でクロック速度比以上の性能比 (ハイパーリニア) を発揮していた場合です。実は、Xeon E5530には載っているのにXeon E5506には載っていない新技術があります。その違いがハイパーリニアな性能差をもたらした理由だと考えられます。その新技術は二つあります。一つはHT (Hyper-Threading Technology)」と呼ばれる技術です。もう一つはTurbo-Boostと呼ばれるオーバークロック技術です。
HTとTurbo-Boostと呼ばれる二つの新技術はマスターサーバに有効な技術です。マスターサーバには多くのプロセスが並列動作しています。例えばNFSサーバ・デーモンはクライアント機の台数分だけ動いています。これら多数のプロセスを効率良く動作させるにはシステムが同時処理できるプロセス数が多い方が良いのです。HTは仮想的にCPUコアを倍増させ平行処理効率を向上させる機能を持っています。そのためマスターサーバには最適の技術です。(L3キャッシュが4MBから8MBへと倍増していることも補助的な効果があると考えられます)
また、マスターサーバで発生する負荷には高低があります。Turbo-Boostは一時的に負荷が高くなった場合にCPUクロック速度をオーバークロックさせピーク負荷を吸収する技術です。Turbo-Boostもマスターサーバに適した技術です。
HTと8MBキャッシュ、Turbo-Boostを搭載しているXeon E5530はXeon E5506よりも少し高価です。しかし、これらの高速化技術を搭載していることでシステム全体の大幅な性能向上が期待できます。その結果、高価なマスターサーバに少しだけ追加投資することで、システム全体を大幅に高性能化でき、結果的に総合的なコストパフォーマンスを向上させることが期待できます。
マスターサーバの性能を高くしたい場合はCPUの増設が効果的です。CPU数を増やすと整数演算性能のスループットが倍増します。また、マスターサーバの性能向上では、限られたプロセスのピーク性能を向上させるより全体のスループットを上げることがたいせつです。そのためにはCPUのクロック速度を高めるよりも、CPUの数を増やすことの方が効果的です。また、CPUの数を増やすことには、次のような別のメリットもあります。
マスターサーバでは多くのプロセスが並列動作しています。これらはネットワークやストレージなどのリソースを使用するため、I/Oでのボトルネックが発生する可能性があります。そのため通信ボトルネックを減らす構成にすることがたいせつです。現在のXeon (Nehalem) は個々のCPUがそれぞれメモリやPCI Express通信するための接続ポートを持っています。そのため、CPU数を増やせばこれらの接続ポート数が増え、ボトルネックの発生が少なくなるような構造になります。このような理由からXeon (Nehalem)を採用したシステムでは、CPUクロック速度を上昇させるよりも先にCPU数を増加させる方が適切です。
HPCクラスタの低騒音化を実現するためには、クロック速度の低いCPUを複数用いることが効果的です。クロック速度の低いCPUは発熱が小さいため冷却用のファンの回転速度を低く保つことができ低騒音化に有利です。性能が必要な場合はCPU数を増やして対応するようにすると、低騒音を維持したまま性能を向上させることができます。反対にCPU数を増やさずクロック速度を高くすると負荷が集中し消費電力が大きくなり発熱密度が高くなることでファンの回転数が速くなり音も大きくなります。
ここまでの情報を元に、マスターサーバに適切なCPUを一覧表に整理します。最初に表の見方をお伝えします。
青字で示した値がSPEC int rate base 2006でのスループット性能の上昇率です。マスターサーバの場合は多くのボトルネックがありますからSPEC値での上昇率がそのまま実効値にはなりません。しかし、そのボトルネックの影響を割り引いたとしても素晴らしいスループット性能向上率が出ています。
これに対して、赤字で示した値がストレージシステムの価格上昇率です。CPU以外のストレージの価格を100万円と仮定し、そこにCPU価格の増分を加算して価格上昇率を算出しています。
表を見ると、最安値のXeon E5506 1CPU搭載機とXeon E5506 2CPU搭載機を比較すると、性能比は２倍近く達しているのに価格比は1.1倍でしかありません。非常にコストパフォーマンスが高いです。高性能なマスターサーバを導入する場合はぜひとも２CPUを選択して欲しいと思います。
CPUを２個にしてCPUの性能を向上させると、次はシステム全体のバランスの確認をしてください。もしメモリ容量やネットワーク構成、ディスク構成などで弱い箇所がありボトルネックが心配でしたら、そのような箇所の強化を優先してください。10GbE化やストレージの強化をしたうえで高性能なCPUの搭載を検討してください。
Xeon E5506 2CPU搭載機とXeon E5530 2CPU搭載機との性能比は約1.5倍です。しかし価格比は約1.1倍でしかありません。先ほどのHT、Turbo-Boost、8MBキャッシュの効果です。E5530 2CPUもコストパフォーマンスに優れた選択です。
ここから先の高性能CPUすなわち、Xeon X5540、さらに上のXeon X5570のコストパフォーマンスは並みに戻っています。予算に余裕があり、少しでも高い性能が必要な切迫した場合の選択肢です。
| Xeon CPU型番 |
周波数 (GHz) |
Turbo Boost (GHz) |
cache | CPU数 | コア数 | HT | HT利用時 スレッド数 |
SPECint-rate base 2006 |
SPECint-rate base 2006 スループット比 |
CPU 価格比 |
システム 価格比 (100万円級 ストレージ) |
| E5506 | 2.13 | 無 | 4MB | 1 | 4 | 無 | 4 | 68 | 1 | 1 | 1 |
| E5506 | 2.13 | 無 | 4MB | 2 | 8 | 無 | 8 | 132 | 1.9 | 2 | 1.1 |
| E5530 | 2.40 | 2.67 | 8MB | 2 | 8 | 有 | 16 | 193 | 2.8 | 4 | 1.2 |
| X5540 | 2.53 | 2.80 | 8MB | 2 | 8 | 有 | 16 | 199 | 2.9 | 5.5 | 1.3 |
| X5570 | 2.93 | 3.33 | 8MB | 2 | 8 | 有 | 16 | 236 | 3.5 | 12 | 1.7 |
メモリ
マスターサーバへの大容量メモリの搭載は大きな効果が期待できます。マスターサーバ上で沢山の処理が行われるとストレージとのI/Oが増え処理待ちが発生することがあります。ところが、大容量メモリを搭載していると一時的にデータをメモリ上に書き込んでおくことができ、負荷を分散させることができます。また、バックアップ処理などでも差分を得るため大きなメモリ空間が必要です。これらの大きなメモリを必要とする処理が複合しても大容量メモリを搭載していると安定した動作が期待できます。メモリ価格が安くなっているので、十分に大きな容量のメモリを搭載しておくことをお勧めします。
現在のXeon (Nehalem)は各CPUごとメモリ接続ポートを搭載しているためCPUの増加に比例してメモリ帯域幅が増大します。これは大きな効果が期待できます。またメモリ容量が同じであればメモリのコストは変わりません。
ネットワーク
マスターサーバでおこなう処理の多くはネットワーク通信と不可分です。そのため、ネットワークが過負荷になり動作が遅くなるとHPCクラスタが不安定になります。この現象を予防するためには、十分に高速なネットワークを搭載しておく必要があります。最近になって24ポートの10GbEスイッチが低価格になってきました。今後のマスターサーバには10GbEの採用をお勧めします。
マスターサーバで求められるネットワークのスループットを向上させる技術として、ネットワーク・ボンディングあるいはチーミングと呼ばれるネットワークを並列化する技術が知られています。具体的には、サーバに搭載された複数のネットワークポートを仮想的に単一のネットワークポートに見せかけ並列処理によりスループットを向上させています。ボンディングの長所はサーバ側の設定を変更するだけで利用でき、クライアント側は何も変更する必要が無いという可搬性の良さにあります。この点が評価され、ボンディングはギガビット・イーサネットの性能不足を補うため広く利用されてきました。またこの技術を利用するために必要な2ポートあるいは4ポートのGbE NICも古くから市販されていて利用を容易にしています。
ネットワーク・ボンディングは10ギガビット・イーサネット (10GbE) でも活躍が期待される技術です。HPCクラスタのファイル共有にはNFSが利用されています。NFSは広く普及し便利に使える反面、処理オーバーヘッドが大きく大幅な高速化は期待できません。この状況は10GbEになっても変わらないと考えられます。そこでボンディングが活躍すると期待されます。幸いにも現在の10GbE-SFP+対応のネットワークカードはSFP+ポートを2ポート備えています。そのため、Linuxカーネル上でボンディングが動作するように設定変更するだけで利用可能となります。
内部転送速度
ネットワークやストレージを高速に利用するためには、これらの拡張カードとCPU間を高速に接続しなければなりません。そこで現在のQuad-Cpre Xeon (Nehale) では、PCI ExpreesとCPU間の接続にQPI (QuickPath Interconnect) と呼ばれる25.6GB/sの帯域幅を持つ通信技術が採用されています。しかもQPIは各CPUに独立して搭載されているため、2CPU機では2本のQPIを搭載し、総帯域幅は51.2GB/sに達します。さらにCPUとメモリ間の通信も独立しており、2CPU機での総帯域幅は51.2GB/sに達します。そのうえCPU間の通信にも独立したQPIが用いられています。これらを総合すると、2CPU機の内部転送速度は128GB/sにも達します。これに対して従来のXeonは10GB/sのフロントサイドバスを２本持っていただけですから、両者を比較すると約６倍にも高速化されています。
PCI Express 2.0
現在のQuad-Core Xeon (Nehalem) は高速化されたPCI Express 2.0を採用しています。PCI Express 2.0のレーン毎の理論性能は1GB/sです。サーバ上には36本のPCIe 2.0のレーンを持っていますから総帯域幅は36GB/sに達しています。この高速なPCI Express 2.0に対応するため、CPUとの接続にはQPI (QuickPath Interconnect) と呼ばれる25.6GB/sの帯域幅を持つ通信技術が採用されています。
10GbE NIC、24Gbps SAS接続RAIDコントローラ
24Gbps (6Gbps x4) SAS接続RAIDコントローラと、Dual-10GbE NICは、双方がPCI Express 2.0に対応した高速な拡張カードです。その性能の高さの一端がベンマークテストで明らかになっています。
PCI Express 1.0に対応した12Gbps (3Gbps x4)のRAIDコントローラのRAID0で性能テストでは、約10個のディスクで性能が飽和し、転送速度はReadで約1400MB/s、Writeで約600MB/sを記録しています。これに対して、PCI Express 2.0に対応した12Gbps (3Gbps x4)のRAIDコントローラのRAID0での性能テストでは、約20個のディスクで性能が飽和し、転送速度はReadで約2500MB/s、Writeで約1800MB/sに達する性能を記録しています。同様のレポートは10GbEについても公開されています。
マスターサーバの平行処理性能を高めるチューニング
マスターサーバは機能を集約させた方が便利でかつコストも安くなります。しかし他方で、過度に機能を集約させるとサーバが過負荷になり障害の原因になります。そこで、マスターサーバの構成を工夫し、高い負荷が掛かっても耐えられるようにチューニングすることがたいせつです。その観点から、現在のQuad-Core Xeon (Nehalem) で高いスループットを得るため基本を紹介してきました。それは、「サーバ内部の通信帯域幅が最大になるように配慮してシステムを構成するにはどの点に配慮すれば良いか」ということです。
しかし、マスターサーバの高速化チューニングを行っても、システムの規模が大きく負荷も大きなHPCクラスタの場合は、複数のサーバを組み合わせてマスターサーバの負荷を分散させる方法をご検討してください。マスターサーバを管理サーバとファイルサーバの２種類のサーバに分割するだけでも効果は絶大です。両者を分割することで、ファイルサーバの側に負荷が集中し応答速度が低下しても、システム全体の管理は管理サーバの側でおこなうため、受ける影響は限定的です。さらに、管理サーバの側にも小規模なRAIDストレージを搭載し、一部のデータをローカルのRAIDストレージに保持すると、マスターサーバシステムの可用性はさらに高くなります。また、ファイルサーバの負荷がより高い場合はファイルサーバを分割することも効果的です。このような場合のシステム設計にも対応します。
さらに高度なシステムチューニングとして並列ファイルシステムの導入も可能です。HPCクラスタ内部で高速なファイルI/Oを追求する場合は複数のファイルサーバを集合的に用い並列I/Oを実現するLuster File Systemの実装経験を持っています。Luster File Systemを組み合わせたHPCクラスタの構築についてはお問い合わせください。
マスターサーバで利用するRAIDストレージ
マスターサーバで利用するRAIDの種類と特徴
ハードディスクの信頼性は向上しています。しかし万一、マスターサーバに搭載されているハードディスクに障害が発生すると、データが失われるばかりかHPCクラスタ全体が一瞬で停止し (ハードランディング) 復旧が困難になる場合もあります。そのような事態を防ぐためマスターサーバには冗長化されたRAID1、RAID10、RAID6、RAID60などが使用されます。下表にHPCクラスタで利用される代表的なRAIDの特徴と用途をまとめました。なおRAIDについて詳しくははページ下部に別資料を掲載しています。
| RAID種類 | 可用性 | 速度 | 最大容量 | 推奨用途 |
| RAID1 | A | C | 1倍 | システムディスク |
| RAID10 | A | B | 8倍 | データ保管 |
| RAID6 (ディスク8個まで) | B | B | 6倍 | データ保管 |
| RAID6 (多数) | C | A | 30倍 | 大容量データ一時保管 (リビルトに時間が掛かるため) |
| RAID60 (RAID6部はディスク8個まで) | B | A | 48倍 | 大容量データ保管 |
※ 最大容量は、RAID化により単体ディスクの何倍まで容量を拡張できるかを表す (2TBの30倍は60TB)
ストレージ筺体の選択
マスターサーバの筺体は必要とするストレージ容量や拡張カード、設置方法などによって異なります。
搭載するハードディスクの台数が８個以下の場合はハードディスク内蔵型のサーバ筺体が適しています。このタイプのサーバはEIAラック搭載型と床置き型を用意しています。筺体のサイズが大きいため拡張カードスロットにも余裕があります。そのため導入後に10GbE NICや外付けディスクアレイ接続用のRAIDコントローラなどを搭載することができ拡張性があります。
もし８個以上のハードディスクの搭載が必要なら、サーバと外付けディスクアレイを組み合わせて構築する分離型サーバをお選び下さい。このタイプのサーバは搭載できるディスクの数が最大で96台と高い拡張性があります。サーバとディスクアレイの接続には12Gbpsあるいは24GbpsのSAS接続か、あるいは10GbpsのiSCSI接続が利用できます。このタイプのサーバはEIAラックに搭載して利用してください。EIAラックが用意出来ない場合は机の上などに直に置くことも可能ですが、保守性が低くなること、運用上のリスクが高くなることなどが懸念され推奨できません。
ストレージの信頼性
ファイルサーバは内部の仕組みが複雑です。しかも常に負荷が加わった状態で利用され、さらに何年間もの安定した動作が求められます。そのためファイルサーバに利用される機器は高い品質をそなえていなければなりません。HPC-ProFSシリーズが採用しているサーバ機器は開発段階から徹底したバリデーションが行われ、全ての問題点をクリアして製品化されています。さらに製造終了後もサポート期間が満了するまで長期間に亘る品質管理が行われています。しかも個々の製品のシリアル番号がデータベースで管理され、構成部品のみならずファームウェアまで把握されています。これらの情報は修理時にも活用され、整合性の取れた部品が提供されることで確実な動作が約束されています。
システムとしての信頼性を高めるためHPCクラスタの完成後に長時間のエージングを行っています。計算ノードのみならずマスターサーバ、RAIDストレージ、スイッチ類まで完成状態に仕上げた後、実際のジョブを連続投入し、システムレベルで発生する不具合を洗い出します。この段階で不具合が見つかると部品を根こそぎ交換し完全な状態に仕上げてから出荷します。HPCクラスタの構成では空前絶後の構成も少なくないため、万一の不整合に備えて、完成システムのエージングと改修はたいせつな製作工程です。
HPC-ProFSに使用しているハードディスクは特に厳選されたサーバ品質の製品を採用しています。MTBF 【平均故障間隔】 は下表のとおりです。この信頼性を製品レベルで達成するためには設計段階での厳しいバリデーション、製造段階での品質管理、サポート段階での単品管理をおこなうことが前提条件となります。 2個のSATAディスクを利用したRAID1の場合のMTBFをみると、70年に一度の確率で障害が発生する可能性が高いことが分かります。 16個のSATAディスクを利用したRAID6の場合のMTBFをみると、8年に一度の確率で障害が発生する可能性が高いことがわかります。実際には５年間の運用期間中に1回はディスク障害が発生すると考えた方が良いでしょう。保守契約を最初から5年間にしておくことは必須です。
| ハードディスク種類 | 利用ハードディスク数によるMTBF 【平均故障間隔】 | |||||
| 1個 | 2個 | 8個 | 16個 | 32個 | ||
| SAS | 160万時間 | 182年 | 91年 | 23年 | 12年 | 6年 |
| SATA | 120万時間 | 137年 | 68年 | 17年 | 8年 | 4年 |
最もクリティカルな部品であるハードディスクについては納入後も自動検査を定期的におこなうような設定をしています。ディスクメディアは定期的にバックグラウンドで巡回検査されており、劣化が始まった箇所は早期に正常箇所とスワップされます。さらに劣化の度合いが閾値を越えると早期のディスク交換を促します。その際のディスクの予防交換も当日4時間オンサイト保守サービスにより経験を積んだサポ訪問しディスク交換します。
RAIDアレイの安全な運用を考える
ハードディスクは一定の確率で故障します。多数のハードディスクを利用するRAIDアレイはハードディスクの故障から逃れられません。RAIDアレイはハードディスク障害が起きても復旧できるように設計しておかなければなりません。また、ハードディスク以外でも、RAIDコントローラの故障、ディスク筺体やケーブルの故障、RAID制御ソフトウェアのバグ、これらの複合的障害、サーバの障害、操作時のヒューマンエラーなども起こります。このようなことから、RAIDに保管しているデータは破損する危機が常にあるということです。ここではそのような視点から運用のポイントを整理します。
RAIDアレイの信頼性を高めるためにはデータの容量を膨張させないことがたいせつです。データの容量が膨張するとバックアップやリストアに時間がかかるようになりリスクが高くなります。一般的な構成でのネットワーク越しのフルバックアップの時間は、GbE経由で4TBのデータをバックアップするには約一日、10GbE経由で10TBのデータをバックアップするには約半日が必要です。RAIDの故障後にフルバックアップを行ってからRAIDの修復を完了させるためには作業が順調に進んでも２日間はかかります。少しでも予想外の事態が起こるとさらに時間がかかります。ストレージの容量が大きくなると処理に時間が掛かりリスクが高くなります。ストレージの信頼性を向上させるためにはストレージの容量を必要以上に膨張させないことがたいせつです。
HPC計算では膨大なファイルが自動的に生成されます。もしストレージを自由に使えるとすぐにデータで埋まってしまいます。そのデータの中には不要となったデータも含まれています。そのデータがストレージの肥大化を招くのです。ストレージの肥大化を予防するためにはユーザが利用できるストレージ容量を制限することが効果的です。容量を制限するとユーザはファイルを整理整頓してくれるためストレージの容量はスリム化できます。
Linux OSにはクォータと呼ばれるストレージの容量を制限する機能が搭載されています。クォータは、各ファイルシステムについてユーザ毎やグループ毎にストレージ容量を指定した値に制限することができます。制限の掛け方も、警告を出す容量、最大容量、警告を出す日数という３種類のパラメータを持っています。クォータのパラメータを利用することで四角四面の管理ではなく、柔軟性のある管理をすることができます。
クォータを導入する場合にはデータのアーカイブ手段を別に用意しておく必要があります。弊社の外付けディスク筺体を用いて大容量のRAID60アレイ利用すると理想的なアーカイブ装置を構築できます。
アーカイブ装置も２重化することを心がけてください。２重化にはサーバ内でRAIDコントローラから２重化する方法と、２台のサーバを用いてネットワーク経由で２重化する方法があります。
RAIDストレージのサポート
RAIDアレイの可用性を高める手段としてホットスペアディスクによるオートリビルト機能の利用をお勧めします。そのメリットを箇条書きで紹介すると次のようになります。
- RAIDアレイのディスクに障害が発生すると自動的に修復
- 全自動で動作するため手動操作によるヒューマンエラーを排除でき安全
- ホットスペアディスクは定期的にメディアチェックを受けているので安心
- 障害が発生した直後から修復を開始するため処理が迅速
- 運用を継続したまま修復が行われ動作しているジョブへの負担が少ない
- 修復後のディスク交換なのでより安全
- お客様の負担が小さい
ホットスペアディスクのような自動修復の仕組みをシステムに組み込んで置くことで、標準的なサービスだけで修復を完了させることができます。お客様の負担を少なくすることができます。
これに対して、ホットスペアディスクを搭載していない場合は、交換作業を終えてからの修復作業を開始するため修理が完了するまでに時間が掛かります。
ホットスペアディスクかあるいは手動交換したハードディスクを用いてRAIDのリビルドが難しい場合は、バックアップが正しく取られているかの確認を行ってください。万一、バックアップが正しく収得されていない場合はバックアップ作業を行ってください。もしバックアップ用のシステムが用意されていない場合でも、バックアップ装置を借りるなどの手段により収得をしてください。フルバックアップが難しい場合は部分バックアップでも良いので実施するようにしてください。バックアップが正しく取れいてないと、もし万一修理途中に不可逆的な障害が発生した場合はデータが失われることがあります。弊社ではハードウェアの復旧は行いますが、消失したデータについては責任を負いかねます。また、バックアップについても最終確認はお客様に行っていただいております。
ストレージの修復作業は、ハードウェアの修復、データの復旧、システムの復旧という三つの階層での復旧をおこなう必要があります。HPCプロサポートはこの３種類の復旧を一貫してサポートしています。なお、この作業についても修理作業は行いますがデータの保護を約束するものではありません。
ストレージは利用期間が長いほど蓄積しているデータは量が増え内容も重要になります。ところが、ストレージは利用期間が長いほど障害のリスクも高くなります。もし保守契約が切れた後に障害が発生すると問題です。その場合でもスポット契約でサポートを行いますが、費用は実費になるため通常の保守契約よりも高い費用が発生します。このようなトラブルを避けるためにも、導入初期に全運用期間の保守サービス契約を締結されることをお勧めします。
ファイルサーバ分散による負荷分散の種類
複数のファイルサーバを用いたファイルサーバの負荷分散では、ネットワークのボトルネックが負荷分散されシステムの応答速度が向上するという効果が得られます。複数のファイルサーバを用いたファイルサーバの負荷分散は、システムの成長に伴い自然に行われているものです。システムの成長に伴うファイルサーバの高度化はつぎのような順番で自然に進みます。
- ファイルサーバの導入
- 水平方向の負荷分散
- 垂直方向の負荷分散
この過程を整理し積極的にファイルサーバの負荷分散をおこなうことで、高速で信頼性の高いシステムの構築目指します。
利用している計算機の台数が増えると管理の手間が増えます。そこでファイルサーバを導入し、各マシンに分散していたファイルを集約することで合理的な管理と無駄の削減を行います。最初はマスターサーバを一台導入し、その上に管理サーバとファイルサーバを一緒に搭載した構成が一般的です。
計算機の台数が増えるとファイルサーバへのI/Oが急増し応答速度が遅くなることがあります。そこで、ファイルサーバを新設しユーザデータを新サーバに移動させます。元のマスターサーバに残されるのは管理サーバと共用データ用のファイルサーバです。ファイルサーバを水平方向に負荷分散することによりユーザ・データ用のファイルサーバが遅くなっても、マスターサーバ側のファイルサーバ機能と管理サーバ機能は正常に動作し続けます。HPCクラスタシステム全体はより安定して動作するようになります。
さらに計算機の台数が増えると１台のファイルサーバでは負荷に対応できないことがあります。このような場合にはファイルサーバを追加して負荷分散を行います。分割方法としては、ユーザのグループ化、計算機のグループ化、アプリケーションのグループ化、ファイル種類のグループ化、搭載するファイルの重要でのグループ化などが考えられます。これらのグループ化の特徴と計算の状況を見極めて利用してください。また、ファイルサーバを設計する際にはバックアップの作成についても併せて考慮することをお勧めします。
ファイルサーバ運用の基本は定期的にバックアップを取ることです。ファイルサーバの容量が大きくなると定期的な差分バックアップを取ることが出来ても、レストア作業に長い時間がかかるようになります。ファイルサーバの運用を考える際には、現実的な時間の範囲内でレストアできる容量を知っておくことは意味があります。
- GbEでのファイル転送速度を40MB/sと仮定すると4TBの転送で約27時間
- 10GbEでのファイル転送速度を120MB/sと仮定すると10TBの転送で約23時間
- ノード内でのファイル転送速度を240MB/sと仮定すると20TBの転送で23時間
ここでのフィル転送速度は条件が良い場合を想定しています。実際はファイルの配置が乱れていたり、他のプロセスが動作しているなどが考えられますから、速度は低下すると考えてください。
「常用データ」と「一時データ」で分割しファイルサーバを分割
HPCクラスタで使用するデータは「常用データ」と「一時データ」２種類に区分できます。
「常用データ」とは、オリジナリティーが高い、再生が不可能、長期保存が必要、利用頻度が高い、というような特徴を持つデータです。このようなデータに適したファイルサーバは、高い信頼性、並みの速度、並みの容量、というような構成が求められます。またバックアップは、より幅広い冗長性が求められるのでサーバ単位での冗長化が理想です。それが難しい場合はRAIDコントローラ単位の冗長化を考えてください。
「一時データ」とは、オリジナリティーは低い、別に存在するオリジナルからの複製が可能、計算機を用いた再生が可能、利用後は消去、というような特徴を持つデータです。このようなデータに適したファイルサーバは、並みの信頼性、高い速度、大きい容量、というような構成が求められます。またバックアップは、速度が求められるのでRAIDコントローラ単位の冗長化が理想です。それが難しい場合はSASポート単位での冗長化を考えてください。
HPCの「常用データ」用ファイルサーバ
「常用データ」とは、オリジナリティーが高い、再生が不可能、長期保存が必要、利用頻度が高い、というような特徴を持つデータです。このようなデータに適したファイルサーバは、信頼性は必要、速度は速い方が良い、容量は並みでよい、というような特徴を持つ構成です。
4TB程度の容量であれば2TBディスク5個で構成したホットスペアディスク付きのRAID10が最良です。RAID10ならディスクが故障した場合は自動的に無停止で迅速に復旧します。さらにシステムディスクはRAID10とは独立したRAID1ボリュームを構築し利用することをお勧めします。ディスクの総数が8個以下なので、単体のサーバ筺体に内蔵するディスクだけで構築が可能です。単体筺体の中に全ての部品を内蔵することで部品点数を抑え、配線も筺体内部で完結するため、高い信頼性を持ちます。
さらに容量と速度を求める場合は、2TBディスク6個で構成したホットスペアディスク付きのRAID6による6TBの構成をお勧めします。この構成なら万一ディスクが障害を起こすと、即座にホットスペアディスクを組みこんでリビルトが自動的に開始され、最短時間で冗長性が回復します。この構成でもRAID1システムディスクは必須です。単体筺体で完結させる構成も踏襲してください。信頼性が低下しません。
「常用データ」にはHPCクラスタ全体を運転するために必要なデータが含まれています。「常用データ」用のファイルサーバが破損することは許されません。もし万一破損した場合は迅速かつ確実な復旧が求められます。ハードウェアの破損とは別に誤操作などからデータを失う事故に対する対策も必要です。万一に備えてバックアップは必須です。さらにバックアップ先からのリストアも十分に高速でなければなりません。そのためには10GbE ネットワークが必要です。「HPC-ProSwitch DPc8024F」は最適のスイッチです。10GbEを利用した6TBの構成でフルレストアに要する時間は転送速度が200MB/sと仮定して約8時間です。
一台のマスターサーバを、「常用データ」用のファイルサーバと、管理サーバとで兼用できます。現在のXeon (Nehalem)は十分に高速です。コア数もHT (Hyper-Threading Technology) を起動しておけば最大16スレッドまでの同時処理が可能です。計算機には大量のメモリも搭載できます。ネットワークもDual-10GbE SFP+ NICのオプションが用意されており十分に高速です。さらに開発ノードしてコンパイラを動作させることも問題ありません。「常用データ」用のファイルサーバを設えることは大きなコストアップにはなりません。
HPCの「一時データ」用ファイルサーバ
「一時データ」とは、別に存在するオリジナルからの複製、再生が可能、一時利用しその後は消去、というような特徴を持つデータです。このようなデータに適したファイルサーバは、信頼性は普通、速度は速い、容量は大きい、というような特徴を持つ構成です。
「一時データ」の例としては観測装置や計測装置から出力されるデータがあります。これらのデータはオリジナルをデータアーカイブ装置などで保管しています。データ処理をおこなう場合はデータをアーカイブ装置からファイルサーバに移して処理を行います。処理が完了すると完成データを次の過程に引き渡し、元データを消去します。
他の例としては科学技術計算で生成される大量の結果データがあります。計算結果データから有用なデータを抽出するまでの間、一時的にデータを保存する場合があります。
ファイルサーバに障害が発生しデータが失われても、その部分をオリジナルから再読み込みするか、あるいは再計算することでデータを復元することができます。しかし、データの容量が数十テラバイトから数百テラバイトと達することもあります。この容量になるとオリジナルを再読み込みしたり再計算するためには長い時間とコストが掛かります。たとえ「一時データ」用のファイルサーバであるても冗長化の高さが求められます。
「一時データ」用のファイルサーバは容量と速度が優先されます。
- Xeon (Nehalem) 2ソケットサーバ
- SAS RAIDコントローラ 「PERC H800」
- 外付けDAS 「HPC-ProServer DPvMD1200」
- 最大接続ディスク数96基、最大物理容量192TB
- RAID6あるいはRAID60構成を推奨
- 10GbEの搭載を推奨
参考 (各接続デバイス別の転送速度と実用的容量)
- GbEでのファイル転送速度を40MB/sと仮定すると4TBの転送で約27時間
- 10GbEでのファイル転送速度を120MB/sと仮定すると10TBの転送で約23時間
- ノード内でのファイル転送速度を240MB/sと仮定すると20TBの転送で23時間
信頼性の高いマスターサーバを工業的に生産
HPCクラスタのマスターサーバには高品質サーバが必要です。大手ベンダー製のサーバは、充実したラインナップにより整合性の良いシリーズ製品のみでスケーラブルなシステム構築が可能です。さらに高い品質と良質な保守体制により長期間の安定稼働が実現されます。HPC-ProFSのハードウェアはデル製のサーバを採用しており、マスターサーバとしての必要条件を満たしています。
マスターサーバはHPCクラスタの運用管理に必要な多くの機能を搭載しています。それらの機能をサーバに実装しシステムと一体化して動作させるためには多くの技術と経験が必要です。そこで、これら必要な機能をパッケージ化した完成度の高い「HPCマスターサーバ・パッケージ」を作成しています。マスターサーバをパッケージ化し設定作業も一貫処理することで、品質の高いマスターサーバシステムの構築に成功しています。
このように、ハードウェア部には大手ベンダー製のサーバを採用し、ソフトウェア部はLinuxをHPCクラスタ用にカスタマイズした高完成度の「HPCマスターサーバ・パッケージ」を使用することで、高品質、大容量、低価格と三拍子そろったマスターサーバを工業的に生産しています。
完成度の高さ
市販のHPCクラスタを購入することで得られる最大のメリットは完成度の高さです。システムの信頼性が低いと機能の重複が起こります。例えばファイルサーバを重複させると、ファイルが分散し、一元的な管理が難しくなります。計算機の管理も自由度を高くすると、ジョブの実行密度が緩くなります。これらの管理にも手間がかがます。修理にも時間がかかります。個々の問題は小さいのですが、これらが重なり合うと大きなロスをうみます。システムを構成する要素が増えるに従いロスの割合は大きくなります。
完成度高いHPCクラスタはシステム全体が緊密に設計されているのでロスが少ないです。全体が一体で動くので操作も簡単です。管理のアウトソーシングが出来るので人でも掛かりません。万一の故障でも修理の専門家が迅速に訪問して一切の作業を行ってくれるので精神的にも楽です。よく設計されているシステムは修理に際しても機能の低下が最小ですみます。修理作業も迅速です。
完成度の高いシステムを目指すと、ハードウェア部に関しては大手ベンダー製のサーバを採用することが最良です。品質が高いのはいうまでもないことです。さらに、シリーズ化されたサーバコンポーネントを組み合わせてスケーラブルに大規模なシステムを構築することを前提としてシステムが設計されテストも十分になされているので、導入での不具合は殆ど発生しません。
大手ベンダーは小規模なHPCクラスタの構築には不向きな組織です。営業システムも技術システムも中規模システムから大規模システムを念頭において構成されているからです。そこで、弊社のような小規模な組織の専門ベンダーが、その小回りの利く体制と専門性を活かし、HPCクラスタのシステム構築を行うことで、双方の長所を活かした協業が可能となります。
充実した技術支援と保守サポート
マスターサーバが停止するとHPCクラスタ全体が停止します。そのためマスターサーバには障害に迅速に対応する保守サービスが必要です。弊社が提供しているマスターサーバ製品には3年間、6営業日、9時〜21時、当日4時間、技術支援付き、オンサイト保守サービスが無償で付属しています。障害が発生し連絡を頂くと次の手順で迅速に修理を完了します。
短いタイムスパンで考えると市販のホワイトボックス系サーバを用いたマスターサーバのコストパフォーマンスは悪くありません。しかし、4年から5年もの長いタイムスパンで考えると大手ベンダー製マスターサーバの独壇場です。大手ベンダー製のサーバはロードマップに従い整然と開発され、長期間にわたって技術サポートが継続されます。しかも沢山の製品が市場に出て利用されていますから、継続的なフィードバックが掛かり、利用開始後も品質が向上してゆきます。
弊社のマスターサーバ製品には標準で「3年間の当日4時間のオンサイト保守サポート」が無償で付属しています。貴重なデータを保管するファイルサーバの保守期間については、導入時から５年間の契約を交わしておくことをお勧めします。万一保守契約が切れていると、再契約の手続きに時間が掛かり迅速な復旧に支障が出ます。弊社の製品には標準で3年間の当日4時間保守サービスが添付されております。これを購入時に最初から5年保守契約に切り替える場合は、後から契約期間を延長するよりも随分お得に行えます。
計算機の世代交代は約２年周期で行われます。計算機の寿命は約4年から5年とみなすことができます。すると計算機と対をなすマスターサーバも約5年のライフサイクルで考えることが妥当です。
 |
HPCに特化した技術支援HPCクラスタは他のITサーバと大きく異なるシステムです。弊社ではHPC技術に精通した専任スタッフよる、手厚い技術支援を行っています。技術支援は、システムの設計段階から始まり、運用中はもちろん、次のシステムへの移行までサポートします。
|
 |
安心のシングルベンダー構成HPCクラスタはサーバ、ストレージ、ネットワークなどが緊密に連携して機能しています。多くのメーカーの製品を寄せ集めたマルチベンダー系のシステムは、障害が複数の機器に跨って発生すると、一元的なサポートが難しくなります。最悪の場合は自己責任での解決が必要です。ところが、シングルベンダーのシステム構成では、障害が複数の機器に跨った発生しても、一括サポートが行われるため迅速かつ確実な復旧が見込めます。HPC-ProFSシリーズは「All Dell」を設計の基本に据え、シングルベンダー構成による安心と品質を提供しています。 |
 |
HPC-ProSupportとAll Dellを一体で実施HPCクラスタはシステム全体が有機的に関連して動作しています。例えばマスターサーバが停止するとHPCクラスタ全体が停止します。そのためサポートもシステム全体をカバーするサポートが必要です。
|
[参考資料]
RAIDポリシーのご紹介
マスターサーバの設計ではストレージ構成が焦点です。そこで、マスターサーバで利用できるRAIDポリシーをご紹介します。
RAID1
RAID1は２個のディスクをミラーリングした信頼性の高いRAIDポリシーです。どちから一方のディスクが障害を起こしても、他方を用いて読み書きを継続できます。冗長性の復活は、新しいディスクと交換しておこなうか、あるいはホットスペアディスクが搭載されている場合は自動的に行われます。RAID1は主にシステムディスク用として利用されています。
- 低コスト
- 対障害性が高い
- 修復中の速度の低下が低い
- 復旧時間が短い
- (短所) 最大容量は2TB
- (短所) I/O速度は並み
- (短所) 搭載したディスク容量の半分しか利用できない
RAID10
RAID10は下位階層においてRAID1で作成された信頼性の高いミラーリング・ディスクのセットを複数作成し、それを上位階層のRAID0で結合しています。信頼性は高い冗長性があるRAID1の階層で実現しています。容量と速度はRAID0の階層で実現ています。RAID10の特徴を列記します。
- 対障害性が高い
- I/O速度が速い
- 大容量化が可能
- 修復中の速度の低下が低い
- 復旧時間が短い
- 容量の大きさに関わりなく復旧時間が一定である
- (短所) 搭載したディスク容量の半分しか利用できない
- (短所) 容量の上限が構成ディスク容量の８倍に限定 (2TB HDDでは16TBが上限)
弊社の採用するRAIDコントローラでは、RAIDのスパニングできる数は8個までら限定されています。RAID10にて2TBのディスクを用いた場合は最大で16TBまでの容量を実現できます。これ容量以上の単一ボリュームが必要な場合は姉妹構成であるRAID60を利用してください。
RAID6
RAID6はパリティーを２重化したストライプ構成のRAIDポリシーです。一個のディスクが障害を起こしても冗長性が維持されているため、短時間なら運用を継続できます。修復中に万一、別のディスクに障害が発生してもデータが保持されています。ホットスペアディスクを搭載していると自動的に修復が行われ冗長性が復活します。
- 耐障害性が高い (二重化パリティーにより修復時でも冗長性を保持)
- I/O速度が速い
- 大容量化が可能
- 実運用上はディスク8個までの構成を推奨
- (短所) RAID6は最大で32個のディスクまでサポートされ大容量ボリュームの構築が可能だが
ボリュームサイズが巨大化するとRAIDの再構築に時間が掛かりリビルトは非現実的 - (短所) 修復中は速度が低下する
RAID60
RAID60はRAID10とRAID6の双方の長所を巧みに取り入れたRAIDポリシーです。大容量、高速のRAIDボリュームを構築する場合はぜひとも利用していただきたいRAIDです。構築のポイントは、下位階層のRAID6のボリュームサイズをなるべく小さく構成することです。RAID6を小さくすると、復旧時間の短縮、速度の高速化、同時ディスク障害時のリスクの低減など多くのメリットが得られます。しかしその反面として全体の容量は少なくなります。なおRAID60ではスペアディスクの搭載を特に強く推奨します。
- 対障害性が高い
- I/O速度が速い
- 大容量化が可能
- 修復中の速度の低下が低い
- 復旧時間が短い
- 容量の大きさに関わりなく復旧時間が一定である
RAID60の構成例
RAID50 (RAID60) は最近登場したRAIDポリシーではありません。RAID50 (RAID60) は古くからバックエンドで利用されてきた実績のある階層型のRAIDポリシーです。往時のRAID50は下位階層にはハードウェアRAID5を、上位階層にはサーバ上のソフトウェアRAID0を利用していました。具体的には、下位階層として複数のハードウェアRAID5を構築します。これらを複数のファイバーチャネルによってサーバと接続します。サーバ上ではソフトウェアRAID0を用いて複数のファイバーチャネル・ストレージをストライピングにより並列化し、高速化と大容量を実現していました。
往時のRIA50に対して最新のRAID60 (RAID50) は二つのRAID階層を単一のRAIDコントローラ上に実装する構造に進化しています。これを可能にした技術がSAS接続です。現在のSAS接続は3Gbps / 6GbpsのSASレーンを4本束にして12Gbps / 24Gbpsの帯域幅を実現しています。24GbpsのSASでのRAIDアレイは2000MB/sの実効性能も記録された高速技術です。この速度が得られたからこそ大量のデータ転送を必要とするRAID60が単一のRAIDコントローラ上で実用化できました。しかもシンプルな構造になったことと、RAID6による冗長性の向上により、可用性が大きく向上しています。
図は2TBディスクを用いて構成した実効容量60TBのRAID60構成例です。8個のハードディスクで構成されたRAID6ボリュームが5セット作成されています。2TBのディスクを使用した場合は12TBの実効容量となります。この5セットある12TBのRAID6ボリュームをRAID0化するとこで、60TBのRAID60ボリュームが作成できます。
ディスク8個で構成されたRAID6の実効性能は約400MB/s程度と考えられます。このRAID6ボリュームを5セット用意しストライプ化するわけですから、理論性能としては2000MB/sという性能が期待されます。実際の構成では転送ボトルネックの影響でここまでの性能は得られませんが、大きな潜在性能を秘めていることはたいせつです。この潜在性能は、RAID60のリビルト時に活きてきます。
下の図は40個のディスクを用いて構成したRAID60での障害発生時の模式図です。図の中のRAID6-#1 Disk0-A1 にてエラーが発生しています。この場合も、リビルトはRAID6-#1の内部に限定されます。8個のディスクで構成されたRAID6アレイのリビルトであるため、比較的短時間で修復が完了します。また、修復中も上位階層がRAID0構成のため高速です。仮にリビルド中のRAID6-#1が40MB/sまで速度を低下させても、5個のアレイをRAID0化しているため理論的には200MB/s弱の実効性能が期待できます。
 |
||
1個のディスクが障害を起こしても |