2015年2月Power Systemsテクニカル・セミナー「GPFS/ESSの特徴・デザインのポイント」

IBM Power Systems

© IBM Corporation 2015. All Rights Reserved. ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供 の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもあ りません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわら ずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、 IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引 きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結 果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示する ものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつで も変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含ま れている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したもので も、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づい ています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、 ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられ ているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたもの です。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、[当該情報に関連し商標リスト中に掲載されたＩＢＭブランド、製品名称があれば追加する]は、世界の多くの国で登録された International Business Machines Corporationの商標です。

他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。

現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。

Adobe, Adobeロゴ, PostScript, PostScriptロゴは、Adobe Systems Incorporatedの米国およびその他の国における登録商標または商標です。

IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer and Telecommunications Agencyの登録商標で す。

インテル, Intel, Intelロゴ, Intel Inside, Intel Insideロゴ, Intel Centrino, Intel Centrinoロゴ, Celeron, Intel Xeon, Intel SpeedStep, Itanium, および Pentium は Intel Corporationまたは子会社の米国およびその他の国における商標または登録商標です。

Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。

Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標です。 ITILは英国The Minister for the Cabinet Officeの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。 UNIXはThe Open Groupの米国およびその他の国における登録商標です。

Cell Broadband Engineは、Sony Computer Entertainment, Inc.の米国およびその他の国における商標であり、同社の許諾を受けて使用しています。 JavaおよびすべてのJava関連の商標およびロゴは Oracleやその関連会社の米国およびその他の国における商標または登録商標です。

GPFS/ESS の

特徴・デザインのポイント

日本アイ・ビー・エム株式会社

IBM Systems.ハードウェア事業本部

Power Systems テクニカルセールス

2015年2月19日 rev 1.0

2015年2月 Power Systems テクニカル・セミナー

© IBM Corporation 2015. All Rights Reserved. ワークショップ、セッション、および資料は、IBMまたはセッション発表者によって準備され、それぞれ独自の見解を反映したものです。それらは情報提供 の目的のみで提供されており、いかなる参加者に対しても法律的またはその他の指導や助言を意図したものではなく、またそのような結果を生むものでもあ りません。本講演資料に含まれている情報については、完全性と正確性を期するよう努力しましたが、「現状のまま」提供され、明示または暗示にかかわら ずいかなる保証も伴わないものとします。本講演資料またはその他の資料の使用によって、あるいはその他の関連によって、いかなる損害が生じた場合も、 IBMは責任を負わないものとします。 本講演資料に含まれている内容は、IBMまたはそのサプライヤーやライセンス交付者からいかなる保証または表明を引 きだすことを意図したものでも、IBMソフトウェアの使用を規定する適用ライセンス契約の条項を変更することを意図したものでもなく、またそのような結 果を生むものでもありません。 本講演資料でIBM製品、プログラム、またはサービスに言及していても、IBMが営業活動を行っているすべての国でそれらが使用可能であることを暗示する ものではありません。本講演資料で言及している製品リリース日付や製品機能は、市場機会またはその他の要因に基づいてIBM独自の決定権をもっていつで も変更できるものとし、いかなる方法においても将来の製品または機能が使用可能になると確約することを意図したものではありません。本講演資料に含ま れている内容は、参加者が開始する活動によって特定の販売、売上高の向上、またはその他の結果が生じると述べる、または暗示することを意図したもので も、またそのような結果を生むものでもありません。 パフォーマンスは、管理された環境において標準的なIBMベンチマークを使用した測定と予測に基づい ています。ユーザーが経験する実際のスループットやパフォーマンスは、ユーザーのジョブ・ストリームにおけるマルチプログラミングの量、入出力構成、 ストレージ構成、および処理されるワークロードなどの考慮事項を含む、数多くの要因に応じて変化します。したがって、個々のユーザーがここで述べられ ているものと同様の結果を得られると確約するものではありません。 記述されているすべてのお客様事例は、それらのお客様がどのようにIBM製品を使用したか、またそれらのお客様が達成した結果の実例として示されたもの です。実際の環境コストおよびパフォーマンス特性は、お客様ごとに異なる場合があります。 IBM、IBM ロゴ、ibm.com、[当該情報に関連し商標リスト中に掲載されたＩＢＭブランド、製品名称があれば追加する]は、世界の多くの国で登録された International Business Machines Corporationの商標です。

他の製品名およびサービス名等は、それぞれIBMまたは各社の商標である場合があります。

現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtmlをご覧ください。

Adobe, Adobeロゴ, PostScript, PostScriptロゴは、Adobe Systems Incorporatedの米国およびその他の国における登録商標または商標です。

IT Infrastructure Libraryは英国Office of Government Commerceの一部であるthe Central Computer and Telecommunications Agencyの登録商標で す。

インテル, Intel, Intelロゴ, Intel Inside, Intel Insideロゴ, Intel Centrino, Intel Centrinoロゴ, Celeron, Intel Xeon, Intel SpeedStep, Itanium, および Pentium は Intel Corporationまたは子会社の米国およびその他の国における商標または登録商標です。

Linuxは、Linus Torvaldsの米国およびその他の国における登録商標です。

Microsoft, Windows, Windows NT および Windowsロゴは Microsoft Corporationの米国およびその他の国における商標です。 ITILは英国The Minister for the Cabinet Officeの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。 UNIXはThe Open Groupの米国およびその他の国における登録商標です。

Cell Broadband Engineは、Sony Computer Entertainment, Inc.の米国およびその他の国における商標であり、同社の許諾を受けて使用しています。 JavaおよびすべてのJava関連の商標およびロゴは Oracleやその関連会社の米国およびその他の国における商標または登録商標です。

更新履歴

お知らせ

￭ General Parallel File System(GPFS)は2015年4月より

Spectrum Scaleという名称に変更となりました

目次

￭ GPFSのこれだけは知っておこう

• Software Defined Storage

• GPFSとは

• GPFSの適用エリア・ユースケース

￭ GPFSデザインのポイント

• ボトルネックにならないデザイン

• 構築・設計時のポイント

￭ ESS

• ESSとは

• ESSの考慮点

￭ 参考リンク

￭ 補足資料

新たなデータ経済性

の必要性

Systems of

Record

Systems of

Engagement

従来の

ワークロード

新時代の

ワークロード

トランザクション・システム

Eメール、SCM、人事

仮想サーバー

仮想ディスクトップ

ソーシャル、メディア

モバイル・アプリケーション

ビッグデータ &

アナリティクス

ワークロード

＆データの統合

Systems of

insight

大規模なデータの管理・統合がますます重要に！！

ストレージ仮想化

SDS は、汎用コンポーネントで構成されたコモディティ

ハードウェアを利用し、ソフトウェアスタックによって

ストレージサービス（機能）を提供するプラットフォーム

Software Defined Storage(SDS)とは

• 機能はソフトで提供

• 汎用的なハードウェアを活用

• 廉価なストレージ

IBMが提供するSDS

XIV

SVC

Elastic Storage ソフトウェア

 あらゆるストレージに対応した

ソフトウェア



真の弾力性

： 制限のないスケール・イン／

アウト、グローバル、仮想化



自動化されたデータ・ガバナンス

：フラッ

シュ、ディスク、テープ

 暗号化による

セキュリティ

の拡張

 オープンなアクセス：POSIX、NFS、

Hadoop &

OpenStack Swiftを利用したオブ

ジェクト・ストレージ

 SoftLayerによる

クラウド展開

ビッグデータ分析やコラボレー

ション、コンテンツ管理、テク

ニカル・コンピューティングな

どの様々なワークロードに対応

した

Software Defined

Storageソリューション

新時代のワークロードに向けた

Software Defined Storage

IBM Watson

に採用され、飛躍

的な進歩を遂げたストレージ

技術の商用利用が可能に

GPFSとは

￭ GPFS = General Parallel File System

• 分散型共有ファイルシステム (並列ファイルシステム)

• IBMソフトウエア

− ライセンスは3種類(クライアント、FPO、サーバー)

￭ 準拠する標準

• POSIX API, POSIX ACL, NFS V4 ACLに準拠

• ユーザーからは通常のファイルシステムとして扱える

￭ オペレーティング環境

• AIX

• Linux(Power, x86, z)

• Windows Server 64bit

￭ スケーラビリティ

• 16384ノード(最大構成、NSDノード、クライアント合計数)をサポート

• 最大、2^99 Byteのファイルシステム・サイズをサポート

• 最大、2^64 個のファイル数をサポート

￭ 多様なトポロジー

• SAN フルメッシュ

• IPによるアクセス [10GbEthernet,InfiniBandなど高速通信ネットワークのサ

ポート]

(InfiniBand RDMA(低遅延通信)はLinuxのみサポート)

• GPFS領域をSamba/NFSなどによって共有可能

分散共有ファイルシステムが活躍するシーン

ディスクI/O負荷を分散

サーバー負荷を分散

NFSサーバが

ボトルネックに

ディスクI/Oも

集中する

サーバー

GPFS

サーバー

GPFS

サーバー

GPFS

適用業務プログラム/GPFS

16,000台以上

まで拡張可能

ファイル・システムとしてアクセス

（専用の API は不要）

SAN経由のストレージ

共用が可能

ソフトウェアRAID機能(ESSのみ)

ソフトウェア

ミラーリング機能

サーバー

GPFS

ソフトウェア遠隔コピー機能

サーバー

GPFS

サーバー

NFS / CIFS

NFSやCIFS経由で利用可能

専用プロトコル

経由でも利用可能

階層管理機能

1998年から

豊富な実績

暗号化機能

分散共有ファイルシステムを

単なるHDDで構成可能

専用のメタデータサーバーが不要

GPFSで実現できること

分散共有ファイルシステムとしてのGPFSの優位性

￭ 高速

• サイズの大きなシーケンシャル I/O が連続して発生するようなアプリケーショ

ン

⇒科学技術計算分野、解析サーバー、マルチメディア・コンテンツ配信など

￭ 多数の機能

• 複数のノードから同じファイルシステムにアクセス可能

⇒ GPFS が備える構成上の特徴 (分散共有ファイルシステム)

• Point-In-Time データ複製機能（FlashCopyに相当）

⇒ GPFS Snapshot 機能

• ハードウェアの機能を利用しないストレージ装置間複製機能（ミラーに相当）

⇒ GPFS Replication 機能

• OpenStackとの連携機能

⇒ OpenStack GPFS dirverの提供

• ストレージプールによる階層管理（Easy Tierに相当）

⇒ GPFS

ILM

機能

• NFS のActive/Active クラスター化機能

⇒ GPFS

Clustered NFS

機能

• 遠隔地同士のファイルの非同期連携

⇒ GPFS

AFM(Active File Management)

機能

• データの暗号化機能

GPFSの提供形態

￭ エディション

同一GPFSクラスター内でのエディションの混在不可

• Express Edition

− GPFSの基本機能

• Standard Edition

− Express Edition機能 ＋

ILM、AFM、cNFS

• Advanced Edition

− Standard Edition機能 +

暗号化

￭ 課金体系

• ソケット課金(GPFS V4.1より)

￭ ライセンス

• サーバー、クライアント、FPO*の3つのライセンス

(参考) GPFS-FPO (File Placement Optimizer)

GPFS

シングルイメージ

GPFSの拡張版

– シェアードナッシング構成

•データ保護はレプリカが基本

従来のGPFSの特長はそのまま

– Active-Active構成の

分散コンポーネントにより構成

– HAクラスタソフト不要で可用性を保持

– スナップショット機能の活用

シェアードナッシング構成向けの拡張

– レプリカ作成数の上限拡大 (2 -> 3)

– レプリカ配置アルゴリズムの拡張

– パイプライン・レプリケーション

– データローカリティ対応用の拡張

ビッグデータ向けMap-reduceワークロード用にデザイン

Hadoopの変わりにGPFS-FPOを利用可能

App.

App.

App.

App.

App.

Application

“meta-block”

FS block

(参考) Information Lifecycle Management(ILM)機能

￭ 複数のストレージを階層化して使用する機能

• 使用例

− よく使用するデータ ⇒ 高価で速いFlashやSSD

− あまり使用しないデータ ⇒ 安価で遅いSATAディスク

− アーカイブデータ ⇒ 大容量のテープ装置（TSM HSM、LTFS EE）

• ファイルの配置・移動は、ポリシー設定に応じて透過的に実施

− ファイル名、ファイルサイズ、ディレクトリ

− 最終アクセス時刻、最終更新時刻

− 所有ユーザー、所有グループ

高速

高価

低速

安価

高速ストレージ

低速ストレージ

テープ装置

大容量

頻繁にアクセスするファイル

優遇ユーザーが所有するファイル

長期間アクセスしないファイル

サイズの大きいファイル

透過的階層管理

(参考) ILMの例

￭ ファイルサイズの大きい順にマイグレーションする

RULE ‘migrule1’ MIGRATE FROM POOL ‘system’ THRESHOLD(90,90)

WEIGHT(KB_ALLOCATED) TO POOL 'migpool'

￭ ファイルサイズの小さい順にマイグレーションする

RULE ‘migrule2’ MIGRATE FROM POOL ‘system’ THRESHOLD(90,90)

WEIGHT(0-KB_ALLOCATED) TO POOL 'migpool'

￭ ファイルにアクセスした日時の古い順にマイグレーションする

RULE ‘migrule3’ MIGRATE FROM POOL ‘system’ THRESHOLD(90,90)

WEIGHT(DAYS(CURRENT_TIMESTAMP)-DAYS(ACCESS_TIME)) TO POOL 'migpool'

￭ ファイルにアクセスした日時の新しい順にマイグレーションする

RULE ‘migrule4’ MIGRATE FROM POOL ‘system’ THRESHOLD(90,90)

WEIGHT(0-(DAYS(CURRENT_TIMESTAMP)-DAYS(ACCESS_TIME))) TO POOL 'migpool'

￭ 1週間（7日）以上アクセスのないファイルを対象としてサイズの大きい順にマイグレ

ーションする

RULE ‘migrule5’ MIGRATE FROM POOL ‘system’ THRESHOLD(90,90)

WEIGHT(KB_ALLOCATED) TO POOL 'migpool‘

￭ 自動的な非同期ファイル転送で拠点間のグローバルネームスペースを実現す

る機能

• サイト間はTCP/IP 通信を利用し、データの更新も非同期

• 回線切断にも対応(再転送は回線復帰後)

￭ GPFS の1つの機能として提供

• ファイルキャッシュレイヤーとして動作

• Standard Edition、Enterprise Editionで利用可能

(参考) Active File Management(AFM)

(参考) GPFS AFMの基本動作

#

Caching Modes

動作概要

1

Read-only

 Cache側では読み込みのみ可能で、ファイルの変更はできない

 Cache側から定期的にHomeのファイル変更を確認し、変更がある場合はCache側のファイルを更新する

2

Local Update

 Cache側でファイルの変更が可能であるが、Cache側での変更内容はHome側には反映されない

 Cache側でファイルの変更を実施した場合、変更ファイルについてはHome側で更新があっても反映されない

3

Single-Writer

 一度HomeからCache側にコピーされたファイルについては、Home側での更新チェックはおこなわれない

(Home側での更新はCache側に反映されない)

 Cache側で作成・変更されたファイルは、即時にHome側に反映される

4

Independent-Writer

 Cache側でファイルを変更する場合、変更前にHomeの内容と同一かどうかを確認し、同一でない場合は最新

版をHomeからコピーした上で、Cache側でのファイル変更が実施される

 Cache側での変更内容は即時にHome側に反映される

 Cacheが複数定義されていて、複数のCacheおよびHomeでファイル更新が同時におこなわれた場合、最後の

更新のみがHomeに反映されるため、運用に考慮が必要

【基本動作】

 1つのCache Filesetについて、1つのHome Filesetのみ定義が可能

 Cacheの動作についてはすべてCache Fileset側にて実施される (HomeはCache Filesetが定義されていることを認識しない)

(参考) Clusterd NFS

￭

GPFS の機能を使ってNFS サービスを監視し、

障害時は自動的に他ノードにフェイルオーバー

• フェイルオーバーは NFS サービス用の VIP を他ノードに移動

￭

GPFS クラスターの各ノードが CNFS を使ってファイルシステムを NFS エク

スポートすることで、スケーラブルな NFS クラスターを実現

￭

NFS サービス自体は、Linux に付属の NFS パッケージを使用

•

GPFSはNFSサービスのモニタリングとVIPの切り替えを行う

ノード障害

VIP

VIP

VIP

VIP

VIP

VIP

GPFS 構成要素

￭ ハードウェア・コンポーネントの集合体を

「GPFS クラスター」として定義

GPFS

クライアント

インターコネクト

GPFS サーバー

ストレージ接続

ネットワーク

ストレージ装置

(参考) GPFSのデータの流れ

GPFSクライアントから10GBのファイルを書く際の処理イメージ

1.

GPFSクライアントでファイルを分割

2.

同時並行で以下が行われる。

•

チャンク1がNode1経由でdisk1へ

•

チャンク2がNode2経由でdisk2へ

•

チャンク3がNode3経由でdisk3へ

•

チャンク4がNode1経由でdisk4へ

•

チャンク5がNode2経由でdisk5へ

•

チャンク6がNode3経由でdisk6へ

※ readの場合も同じ

Node1

S

Node2

Node3

Storage1

Storage2

Node4

N/W

Fibre Channel

GPFS

サーバー

GPFS

サーバー

_サーバー

GPFS

GPFS

クライアント

GPFS クライアントとサーバー（NSD 接続の有無）

￭ GPFS ではストレージ装置上に構成さ

れたボリュームのことを NSD

(Network Shared Disk) と呼ぶ

• SAN 接続された外部ディスク装置上

では、ボリューム = LUN (Logical

Unit Number)

￭ NSD に SAN 経由で直接アクセスでき

るサーバーのことを「GPFS サー

バー」、NSD に「GPFS サーバー」経

由でアクセスするサーバーのことを

「GPFS クライアント」と呼ぶ

• 利用用途によっては、GPFS クライア

ントが存在しないGPFS クラスターも

ある

• GPFS サーバーが一台も存在しないと

いう構成の GPFS クラスターはない

GPFS

クライアント

インターコネクト

GPFS サーバー

ストレージ接続ネットワーク

ストレージ装置

NSD (LUN)

NSD に直接ア

クセスできる

NSD に直接ア

クセスできない

GPFS クライアントが存在しない構成

￭ GPFS サーバーが GPFS ファイルシス

テムを NFS もしくは CIFS として公開

し、最上端の NFS/CIFS クライアント

からは NFS もしくは CIFS プロトコル

を利用してGPFS ファイルシステムに

アクセス

￭ DB2 pureScale など NFS/CIFS アク

セスするクライアントも存在しない、

純然たる GPFS サーバーのみで構成さ

れた GPFS クラスター構成も存在

NFS / CIFS

クライアント

業務用ネットワーク

（例： Gbit Ethernet など）

GPFS サーバー

ストレージ接続ネットワーク

ストレージ装置

NSD (LUN)

GPFS に直接アクセス

できない

GPFS ファイルシステムを NFS export

もしくは CIFS シェアとして公開

NSD (LUN)

性能とモデル選定の考慮点

￭ 高速化の根本は「横に並べる(並列)」「全体として速い(Aggregate)」

￭ クライアント1台から見たときのスピードは高速化しないことも

￭ サーバ数が少ないと高速化しない

￭ LUN数やストレージのコントローラ数が少ないと高速化しない

サーバー

 ストレージとのインターコネクト、クライアントとのインターコネクトを考慮

したI/Oアダプターが十分に構成できるかを考慮

ストレージ

 ローエンド系の製品を複数並べて構成するのが一般的

 ストレージ製品が提供する機能を GPFS がソフトウェア的に実現

(参考) GPFS サーバー推奨モデル



GPFS サーバはストレージとインターコネクト間を高帯域で接続するため、I/O がボトル

ネックにならないような構成を選択する必要あり



PCIeアダプターの枚数上限は、S812LではPCIe(x8)が4枚とPCIe(x16)が2枚、 S822Lでは

PCIe(x8)が5枚とPCIe(x16)が4枚です。S812Lだとアタプター数量が収まらない場合はS822Lも

検討



上記推奨モデル多数構成するか、4U以上の大型 SMP 機を少数構成するか、提案構成に求

められる諸要件を勘案して適切に選択



インターコネクトが十分高速であれば上記推奨モデルを選択する



GPFSサーバ上でGPFS以外のサービス（NFSやSamba など）を稼動させる場合には、

Power S812L



2U



POWER8搭載



10コア 3.42GHz



12コア 3.02GHz



16 GB Memory 以上



2.5” 15krpm HDD x 2 (OS用)



OS管理用NIC



ディスク接続用インターフェース



FC, SASなど



インターコネクト用インターフェース



GbE, 10GbE, InfiniBandなどから選択

Power S822L



2U



POWER8搭載



20コア 3.42GHz



24コア 3.02GHz



32 GB Memory 以上



2.5” 15krpm HDD x 2 (OS用)



OS管理用NIC



ディスク接続用インターフェース



FC, SASなど



インターコネクト用インターフェース

モデル

Storwize V3700

Storwize V5000

Storwize V7000

DCS3860

サーバー接続I/F

•

FC (8Gbps)

•

iSCSI (1Gbps)

•

SAS (6Gbps)

•

iSCSI (1/10 Gbps)

•

SAS (6Gbps)

•

FC (8Gbps)

•

iSCSI

•

FC (8Gbps)

•

iSCSI

•

SAS (6Gbps)

キャッシュ

(標準／最大)

8GB / 16GB

16GB / 32GB

16GB / 64GB

24GB(標準)

コントローラあたり12GB

最大物理容量

(拡張筐体構成

時)

240TB

336 TB

672 TB

480 TB (4TB NL SAS

HDD 使用時)

1920 TB

1440TB (4TB * 260)

選択可能ドライ

ブ

3.5型 10K HDD:1.2TB/900GB 15K HDD:300GB 7.2K NL HDD:4/3/2TB 2.5型 10K HDD:1.2TB/900/600GB 15K HDD:300GB 7.2K NL HDD:4/3/2TB SSD:800/400/200GB 3.5型 10K SAS HDD:1.2TB/900GB 15K SAS HDD:300GB 7.2K NL HDD:4/3/2TB 2.5型 10K HDD:1.2TB/900/600GB 15K HDD:300/146GB 7.2K NL HDD:1TB SSD:800/400/200GB 3.5型 10K SAS HDD:1.2TB/900GB 15K SAS HDD:300GB 7.2K NL HDD:4/3/2TB 2.5型 10K HDD:1.2TB/900/600GB 15K HDD:300/146GB 7.2K NL HDD:1TB SSD:800/400/200GB 3.5型 7.2K NL HDD: 4TB 2.5型 15K HDD:300GB

筐体高さ

•

2U (controller)

•

2U (拡張ユニット)

•

2U (controller)

•

2U (拡張ユニット)

•

2U (controller)

•

2U (拡張ユニット)

•

2U (controller)

•

2U (拡張ユニット)

(参考) GPFSでのストレージ装置推奨モデル仕様一覧

GPFS の適用エリア

GPFS クラスター

Cinder Swift

GPFS

Hadoop

Connector

GPFS NFS

GPFSはさまざまなアプリケーション分野に対応

容量と性能の

スケールアウト性

POSIX

廉価なハードウェアで

エンタープライズ

ストレージクラスの

機能・性能を実現

シングルネームスペース

Technical Computing

(HPC/CAE)

Big Data & Analytics

Cloud

Block Object

File

GPFSをご採用いただいている分野

￭ HPCクラスターのファイルシステム

• HPC/CAEのデータ保管エリア

￭ マルチメディア系ストレージ

• ストリーミングサーバー

• テレビ/ラジオ局

• デジタルアーカイブ

￭ スケールアウト型のファイルサーバー(NAS)

￭ BigData用ストレージ

￭ クラウド環境のストレージ基盤

GPFSを内部的に利用した製品/サービス

• DB2 pureScale

• SAP HANA

• PureData System for Operational Analytics

• SONAS (V7000 Unified)

• InforSphere BigInsights

など

15年以上の実績

ユースケース①HPCクラスターのファイルシステム

GPFSサーバー

スーパーコンピューター

(GPFSクライアント)

/gpfs_root

/sub_dir_1

/sub_dir_2

/sub_dir_3

/sub_dir4

SAN (FC),

TCP/IP

(Ethernet,

InfiniBand

)

グローバルネームスペース

ファイルサーバー部

高速入出力

ユースケース②メディア分野

Optimizing for Higher Productivity and Performance: How IBM’s General Parallel File

System (GPFS) Bridges Growing Islands of Enterprise Storage and Data

ユースケース③アーカイブ用ファイルサーバー

ディスク SANスイッチ テープライブラリー テープカートリッジ

ILMを利用したアーカイブファイルシステム

(GPFSはStandard Edition以上が必要)

ポリシーによる

データマイグレーション

ユースケース④BigData用ストレージ

(IDEA)

ESS

Hadoop コンピュートノード

…



高い柔軟性



ストレージ層をHadoop (コンピュート) ノード層から分離し、IBM Elastic Storage

Server上で稼働

コンピュート層とストレージ層をそれぞれ必要量スケール可能で柔軟にスケールアウト

全コンビュートノードが全ファイル領域にアクセスできるため、全ノードにジョブ分散投入

が可能



シンプル



HDFSに比べて1/3のストレージインフラ量で構築可能、管理ポイント減少でシンプルオペ

レーション

BigInsights

Nova/Glance

Cinder

Swift

ファイルシステムレベルの高速コピー機能を使うこ

とで高速にイメージのコピーができ、仮想マシンの

プロビジョニング時間が短縮。

スケールアウトによるIOパフォーマンスの向上。

FPOを利用したシェアードナッシング構成の場合

はさらにスケーラビリティが向上。

実績がある機能を活用したオブジェクトストレージを構築

可能。バックエンドにストレージを利用することでストレー

GPFSの持つ機能を組み合わせられる

スナップショット

データ暗号化

データ階層化機能

テープとの統合

レプリケーション

マルチクラスター

ユースケース⑤クラウド環境のストレージ基盤

(GPFSとOpenStackの連携)

ユースケース⑥災害対策ソリューション

￭ 本番環境のデータを災対環境の GPFS クラスターに転送

•

災対環境は GPFS クラスターである必要はない

￭ 本番環境でデータ更新後、非同期で災対環境にデータ転送

￭ 災対環境では通常時はデータの参照のみを許可し、更新を不可とする運用が必要

•

AFM のモードは Single-writer (SW) を使用する

•

災対から本番への切り戻し時のデータ同期は手動で実施する

 AFMの機能を利用(GPFSはStandard Edition以上が必要)

– 災対先にてデータ参照を必要とし、データ転送は即時とするシステム

GPFS クラスター

本番環境

災対環境

NFS or GPFS

災対環境では通常時は

参照のみ可能とする

運用が必要

自動的にデータ転送

￭ 各支店データは各支店がローカルに保持し、他支店のデータは必要に応じて各支店に

キャッシュ

•

データのディレクトリ構成は全支店で同一構成

￭ 各支店でデータ更新後、非同期で本店にデータ転送

￭ 他支店のデータはファイルを読み込んだタイミングでローカルにデータが保持される

￭ 他支店のデータは参照のみを許可し、更新を不可とする運用

•

AFM のモードは Single-writer (SW) または Independent-writer (IW) を使用する

ユースケース⑦遠隔地データ統合基盤

 AFMの機能を利用(GPFSはStandard Edition以上が必要)

– 各支店で他支店のデータを参照可能とするデータ統合システム

本店

支店A

支店B

支店C

支店D

GPFS クラスター

GPFS クラスター

GPFS クラスター

GPFS クラスター

GPFS クラスター

更新時に本店に反映

参照時に支店に転送

構成例①シンプルファイルサーバー構成

(V7000 +S822L)

構成

‒ GPFS Server : S822L＊2台

‒ Storage

: V7000＊1台

GPFS ServerにSamba/NFSのサービス

提供環境を設置する構成

GPFS Server ごとの拡張、 V7000ごと

の拡張が可能

スケールアウト方法

S822L＊1台ずつ

V7000＊1台ずつ

⇒S822Lの台数とGPFSライセンスを

おさえることが出来るため、コス

トを抑えた構成となっています。

構成例②スケールアウト型NAS構成

(V7000 + S822L)

構成

‒ GPFS Server : S822L＊2台

‒ Storage

: V7000＊1台

‒ GPFS Client

: S822L＊2台

GPFS Clientでの処理を複数のGPFS

Serverに分散することにより高速処理化が

実現可能

バックエンド側とフロント側の両方でス

ケールアウト可能な構成

スケールアウト方法

‒ バックエンド側

S822L＊1台ずつ

V7000＊1台ずつ

(容量はエンクロージャー追加)

‒フロント側

S822L＊1台

⇒拡張時のニーズに合わせて、柔軟

なスケールアウト方法を選択可能

高い性能を発揮するためのポイント

￭ GPFSサーバーのノードを増やすだけで性能が増加する場合もある

￭ GPFSサーバーのインターコネクトアダプターを増やすだけで性能が

増える場合もある

￭ 同じ実効容量の場合、1本あたりの容量を落としてHDDのトータル本数を増やすほ

うが性能がよい

ディスクI/O負荷が

分散された構成

サーバー負荷が

分散された構成

サーバ台数が

ボトルネックに

ディスクI/Oの集中が

ボトルネックに

⇒ 性能要求を満たすために適切なハードウェア構成を選択・提案

(ハードウェアがもつキャパシティ以上の性能を出すことはできません)

性能要件に関する対処方針

￭ 性能要件がない場合：

• 容量や可用性を優先して構成を決定

• 理論値での性能予測

• （可能であれば）事前のテストによってどの程度の性能が発揮でき

るかを計測

￭ 性能要件がある場合の検討項目：

• 最初からストレージ装置の機種を決めてかかるのは誤りで、性能要

求の内容を明確にしてから、構成を決定

• お客様予算額によっては、性能要求を満たせない可能性も有る

• 可能な限り、事前のテストによってどの程度の性能が発揮できるか

を計測

• 性能要件がある場合の検討項目：

− クライアント台数

− クライアント一台の I/O 性能（単体性能）、もしくは複数の

クライアントを合計した I/O 性能（アグリゲート 性能）の何

れが問われているのか

− 求められている総容量

− アプリケーション I/O 特性

性能要件を満たす GPFS デザインの要点

￭ 全てのコンポーネント階層間で、アグリ

ゲート性能が、性能要件を下回らないよう

に構成

￭ 右の例の場合：

• クライアント10台 (1Gbps Ether x 10)

−全 GPFS クライアントのネットワーク I/O 帯域合計値

AR1: 10Gbps

• サーバー3台 (1Gbps Ether x2、4Gbps FC

x2)

−全 GPFS サーバーのネットワーク I/O 帯域幅合計値

AR2:

6Gbps

−全 GPFS サーバーの FibreChannel I/O 帯域幅合計値

AR3: 24Gbps

• ストレージ4台 (4Gbps FC/コントローラー)

−全ストレージ装置の帯域幅合計値

AR4: 16Gbps

￭ 最もアグリゲート性能が低いのは、

AR2 の

6 Gbps

￭ サーバーのインターコネクト速度の合計値

がボトルネックと判明

x 2 x 2 x 2 x x6 x x6 x x4 x x4 Storage (x = 4) GPFS Clients (x1= 10) GPFS Servers (x3= 3) x2 x5 x7 x9

AR1

AR2

AR3

AR4

注： 図中の機器の台数や数値はあくまで例です。

インターコネクトの重要性

￭

GPFS クラスターの性能を左右する重

要なコンポーネント

￭

AとB が釣合うように構成すると最適

A) GPFSクライアントが要求する帯域

B) GPFSサーバーが提供できる帯域

￭

A>B であれば GPFS サーバー側に

ボトルネックがあり、A < B であれば

高価な H/W 資源が無駄となる

￭

殆どのケースでは、最も低速なデバイ

スであるストレージ装置の帯域が

GPFS クラスターの性能のボトルネッ

ク

GPFS

クライアント

インターコネクト

GPFS サーバー

ストレージ接続ネットワーク

ストレージ装置

A

B

単体性能とアグリゲート性能

￭

性能要件には、以下の二種類が存在

• ① クライアント一台の I/O 性能（単体性能）

• ② 複数のクライアントを合計した I/O 性能（アグリゲート性能）

￭

①の高い単体性能が求められる場合、GPFS クライアントとサーバーを接続する

インターコネクトは可能な限り高帯域なネットワークが求められるため、

InfiniBand もしくは 10Gbit Ethernet / 40Gbit Ethernet を選択

￭

②の場合には、Gbit Ethernet など低廉なネットワークで多数のクライアントを

接続することで、必要な性能要件を満たすことが可能

GPFS クライアント インターコネクト GPFS サーバー ストレージ接続ネッ トワーク ストレージ装置

②

GPFS クライアント インターコネクト GPFS サーバー ストレージ接続ネッ トワーク ストレージ装置

①

(参考) 理論帯域と実効帯域の経験値

メディア

理論帯域

実効帯域の経験値

Gbit Ethernet

1 Gbps

100 MB/s 程度

10 Gbit Ethernet

10 Gbps

300 MB/s ～ 1 GB/s （多重度やドライバーの成熟度に依存）

InfiniBand DDR 4x

16 Gbps

1.5 GB/s 程度（多重度やドライバーの成熟度に依存）

InfiniBand QDR 4x

32 Gbps

2～3GB/s 程度（多重度やドライバーの成熟度に依存）

InfiniBand FDR 4x

56 Gbps

4～5GB/s 程度（多重度やドライバーの成熟度に依存）

GPFSの構築・設計におけるポイント

￭ ノードの設計

• ノードの役割を決定

− 連続稼動性に影響

￭ NSDの設計

• ディスクの用途の決定

− ディスクの負荷分散、可用性について影響

• 機能面での決定(Replication、ILMの利用)

￭ ファイルシステムの設計

• ブロックサイズの決定

− 作成後の変更不可

− 性能、利用可能ファイル数に影響

￭ パラメータチューニング

• 必要に応じて

(参考) GPFS クラスター・ノード設計の考え方

￭ GPFSを構成するノードの役割は、2属性(各2種類)ある

• manager か client

• quorum か nonquorum

￭ Manager か clientの選択

• managerに成りうるノードはmanagerとし、それ以外はclientとする

•

一般的には、NSDサーバー(ディスクとローカルに接続する)となるノードを

managerとし、それ以外をclientとする。

• Managerの種類

•

Cluster Manager

•

クラスターに一つ存在し、クォーラム・ノード間の投票によって自動的に決定される

•

Cluster Manager ノードの障害時は、他のManagerノードにFailoverされる

•

File Systems Managerノードの選択やFailoverを行う

•

File System Manager

•

各ファイルシステムに一つ存在し、複数ノードからのファイルアクセスに対して整合性を保障する

•

File System Managerに障害が発生した場合は、Cluster Managerによって他のノードにFailoverされる

￭ quorum か nonquorumの選択

• スプリットブレインなどが発生した際に、生存ノードを決定するため

のクォーラム・ノードの対象にする場合は、quorumノードと指定

(参考) GPFS クラスター・ノード構成の考え方：障害時の動き

Tie-B

3ノード以上のGPFSサーバーで構成

• Quorum充足数が維持される限り連続稼動

• Quorum対象ノード : 3 の場合

• 充足数 : 2ノード

• 障害ノードが1つ → 連続稼動

• 障害ノードが2つ → サービス停止

• Quorum対象ノードは、ノードの役割として任意に指定

Q

Q

Q

3ノードQuorum (充足数2)の場合

1ノード障害は連続稼動

一般的に2ノード構成の場合に利用

• 全体で8ノード以下の構成であることが前提

• 先にTie-Breakerディスクとして指定したディスク への

アクセス権を取ったノードが連続稼動

Q

Q

アクセス権の確保

ノード障害

通信障害

連続稼動

停止

GPFSサーバー障害時の連続稼動は、ノード・クォーラムやTie-Breakerディスク、

またはそれらを組み合わせた仕組みで維持する。

ノード・クォーラム

_{Tie-Breakerディスク}

(参考) NSDおよびディスク設計の考え方

￭ NSDとOSにアサインされたディスク(AIXの場合hdiskXなど)は、

1対1の関係

￭ 単一または複数のNSDで、ファイルシステムを作成する

• 一つのファイルシステムを構成するNSD間で、I/O能力に偏りがないように

LUN設計を行う

• ストレージ装置間でReplicationを行う場合も同様の考慮

• ILM(Information Lifecycle Management)機能でpoolを構成する場合、同

じpoolを構成するNSDについても同様の考慮

￭ NSD単位の属性

• NSD名：任意の名称

• サーバー名リスト：

NSDに対するサーバーの優先順位を決定(優先順位順に

左から指定)

• GPFSクライアントからのアクセスは、記載されているサーバーのみ経由する

• GPFSクライアントからのアクセスは、優先順位の最も高いサーバーを経由する

• Usage：dataAndMetadata | dataOnly | metadataOnly | descOnly

• 一般的にはdataAndMetadataを選択。Replicationを利用する場合の3つめのファイル

システム・ディスクリプタとしてNSDを作成する場合はdescOnlyを指定

• FailureGroup：Replication機能を使用する場合に指定

• ストレージ装置間で冗長性を維持する場合は、同じストレージ装置上のNSDの

FailureGropを同一の値で指定する。

• Pool：ILM機能を使用する場合に、高速/低速ストレージ・プールなどを分

離するために指定

(参考) ファイルシステム設計の考え方

￭ ファイルシステムの分け方

• 業務内容によってファイルシステムを分ける

• ファイルサイズの傾向によってファイルシステムを分ける

• 非機能要件によってファイルシステムを分ける(Replicationの必要性有無、

ILM機能の有無)

￭ I/O Workload タイプとファイルシステム・ブロックサイズの関係

• サイズの大きなファイルのシーケンシャルI/O Workloadの場合、極力大き

なブロックサイズを指定することにより、GPFSの最大性能を活かすことが

できる

• ファイルサイズが小さい、あるいはランダムなI/O Workloadの場合、小さ

めのブロックサイズのほうが比較的望ましい。

• 小さいファイルサイズのファイル群を、ブロックサイズの大きいファイルシ

ステムに配置するとスペース効率は良くない。

• I/O Workloadタイプが不明な場合、ファイルサイズが不明な場合などは、

デフォルトを利用する。

￭ 指定可能なブロックサイズ

• 16KB | 64KB | 128KB | 256KB | 512KB | 1M | 2M | 4M | 8M |16MB

IBM Elastic Storage Server (ESS) 概要

￭ 極限のデータ保全性

•

2 または 3 個のディスク障害に対するフォールトトレラント

•

エンドツーエンドのチェックサム保護

•

Protection against lost writes

•

Declustered RAID によるリビルド時間の短縮

￭ 優れたパフォーマンス

•

Declustered RAID によるリビルド中のディスクへの負荷軽減

•

リビルドによるオーバーヘッドは 1/3 以下

•

書き込みパフォーマンスのためのビルト・イン SSD と NVRAM

•

現在から将来にわたって代替製品よりも高速！

￭ 共通仕様

•

Power S822L 2台（各20コア構成）

•

Red Hat Enterprise Linux 7 for POWER

•

GUIによる管理

•

管理サーバー(Power S812L) と HMC が付属

•

Elastic Storage ソフトウェア

•

Elastic Storage Native RAID

•

xCat または Platform Cluster Mgr （オプション）

•

10 Gb, 40 Gb イーサネット, FDR Inifiniband サポート

•

3 年保守

Elastic Storage Server （ESS, Model: 5146）

￭ ２モデルのラインナップ

•

GS：小容量、小ファイルサイズ、ランダムI/Oの多い環境向け

•

GL：大容量、スループット重視

•

各モデル、

SSD２本はシステム領域

123456789101112131415161718192021222324 FC 5887 123456789101112131415161718192021222324 FC 5887 123456789101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 12345678 9101112131415161718192021222324 FC 5887 モデル GS1 GS2 GS4 GS6 GL2 GL4 GL6 ディスク本数 SSD 24本 SASx46+SSDx2 またはSSD48本 SASｘ94+SSDx2 またはSSD96本 SAS 142本 +SSD 2本 NL-SAS116本 +SSD 2本 NL-SAS232本 +SSD 2本 NL-SAS348本 +SSD 2本 ディスク種類 SSDディスク（400GB/800GB）, 1.2TB SASドライブ 2TBまたは4TB NLSASドライブ 実 効 容 量 ※ 400GB SSD 最大5.4TB 最大11.4TB 最大23.3TB 800GB SSD 最大10.8TB 最大22.8TB 最大46.6TB 1.2TB SAS 最大35.2TB 最大72.2TB 最大109.1TB 2TB NLSAS 最大151.1TB 最大313.3TB 最大470TB 4TB NLSAS 最大302.1TB 最大626.6TB 最大939.9TB

ユニット数 6U 8U 12U 16U 12U 20U 28U

参考スループット 6 GB/Sec SAS 2GB/S

SSD 12GB/S

SAS 5GB/S

SSD16GB/S 7 GB/Sec 5+ GB/Sec 10+ GB/Sec 12+ GB/sec

拡張筐体 EXP24S ストレージ・ドロワー（2U 24ドライブ） 1818-80E 拡張ユニット（4U 60ドライブ）

ESSをeConfigで構成すると。。。(GL6の例)

￭ T42ラック

￭ HMC、コンソール

￭ Power8 S812L(マネージメントサーバー)

￭ Power8 S822L(GPFSサーバー:GNR) x2台

• インターコネクトが選択可能

− 3 x InfiniBand FDR

− 2 x InfiniBand FDR + 1 x 10Gb Ethernet

− 1 x InfiniBand FDR + 2 x 10Gb Ethernet

− 3 x 10Gb Ethernet

− 3 x 40Gb Ethernet

− 1 x InfiniBand FDR + 2 x 40Gb Ethernet

− 1 x 40Gb Ethernet + 2 x 10Gb Ethernet

￭ DCS3700

• HDDの容量が選択可能

− 2TB or 4TB(GL6の場合は348本)

￭ スイッチ類(オプション)

• 10Gbスイッチ、40Gbスイッチ、InfiniBandスイッチなど

ESSの構造(GL6の例)

NSD

Server

0

2

w ith t hre e L SI 92 06

NSD

Server

0

1

w ith t hre e LSI 92 06

DCS3700 Disk Enclosure JBOD04 (60 disk slots)

DCS3700 Disk Enclosure JBOD03 (60 disk slots)

DCS3700 Disk Enclosure JBOD02 (60 disk slots)

DCS3700 Disk Enclosure JBOD01 (60 disk slots)

DCS3700 Disk Enclosure JBOD06 (60 disk slots)

RG01

RG01_DA3 (+29 disks) p

RG02

RG02_DA3 (+29 disks) p p

DCS3700 Disk Enclosure JBOD05 (60 disk slots)

RG01

RG01_DA3 (29 disks) p p

RG02

RG02_DA3 (29 disks) p

RG01

RG01_DA2 (+29 disks) p

RG02

RG02_DA2 (+29 disks) p p

RG01

RG01_DA2 (29 disks) p p

RG02

RG02_DA2 (29 disks) p

RG01

RG01_DA1 (+29 disks) p

RG02

RG02_DA1 (+29 disks) p p

RG01

RG01_DA1 (29 disks) p p

RG02

RG02_DA1 (29 disks) p SSD SSD p p p p p p p p p p p p p p p p

(参考) ESSの用語

￭ Recovery Group(RG)

• どちらのノードがプライマリーアクセスとなるかの物理ディス

クのグルーピング

• ストレージコントローラーの管理下のディスクに相当

￭ Declustered Array(DA)

• RAIDアレイに相当(実際は物理ディスクの集合)

￭ Vdisk

• LUNに相当

• Vdiskの単位でNSDを登録

￭ NVRAM

• GPFS Native RAIDの構成情報などを

内蔵SASコントローラー内に保管

− ノード間で同期

￭ システムのMESは不可

• ディスクエンクロージャーだけの追加はできない

• 容量追加などの場合はESSごと新規で購入が必要

− 2システム以降はマネージメントサーバーは不要

− 同一ファイルシステムへの追加の場合はリバランス処理が必要

￭ 利用可能な容量はモデルと保護レベルで決定

• データエリア

− 8+2P の保護レベル

− 8+3P の保護レベル

• メタデータエリア(全実効領域のパーセンテージで指定可)

− 3wayレプリケーション

− 4wayレプリケーション

ESSの考慮点(1)：事前の取り決めが重要

￭ システムの最大スループットはGPFSクライアントからの

アクセスを想定

• GPFS以外のプロトコルによるアクセスの場合は、

プロトコルノードのインターコネクト性能に大きく依存

￭ NFS(Clustered NFSを含む)はESSのGPFSサーバーでは

サポートなし

• 別途プロトコルノード or マネージメントサーバー上での別

LPAR をGPFSクライアントとして構成

(NFSエクスポートを行うためGPFSサーバーライセンスが必要)

￭ CIFSサポートは計画中

ESSの考慮点(2)：性能要件・利用予定プロトコルに注意

GPFS ネイティブアクセス(10GbE の例)

10Gbps x6 x2nodes

GPFS利用サーバ群

サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ

1GbE or 10GbE x N

XXX Gbps

120Gbps

ESS

GPFS client

NFSでのアクセス(10GbE の例)

10Gbps x6 x2nodes

GPFS利用サーバ群

サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ

1GbE x N

XXX Gbps

120Gbps

10Gbps x n

10Gbps x n

10Gbps x n

_{10Gbps x n}

GPFS client

(cNFS)

ESS

NFS client

XXX Gbps

台数やインターコネクト数により

ボトルネックになる可能性

参考リンク

￭ Knowledge Center : General Parallel File System (GPFS)

http://www-01.ibm.com/support/knowledgecenter/SSFKCN/gpfs_welcome.html

￭ Knowledge Center : GPFS FAQ

http://www-01.ibm.com/support/knowledgecenter/SSFKCN/com.ibm.cluster.gpfs.doc/gpfs_faqs/gpfsclustersfaq.

html

￭ GPFS Wiki

https://www.ibm.com/developerworks/community/wikis/home?lang=ja#!/wiki/General%20Parallel

%20File%20System%20%28GPFS%29

￭ GPFS Wki: Active File Management (AFM)

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel

%20File%20System%20(GPFS)/page/Active%20File%20Management%20(AFM)

￭ GPFS Wiki: Using AFM

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/General%20Parallel

%20File%20System%20(GPFS)/page/Using%20AFM

GPFSノードのロール

• GPFS Configuration Server (Repository) （設定ファイルを持つ）

• GPFS Cluster Manager

• File System Manager

• Meta-node

GPFSノードのロール GPFS Cluster Manager

-￭ GPFS Cluster Manager

− クラスタ毎に必ずひとつ存在

− クォーラム・ノード間の投票により決定

− File System Managerの Failoverを実施

Cluster

Manager

FM

FM

クラスタに対し１

GPFS

クラスタ

File System Managerの障害時には新しいファイル

システムマネージャを選択する



ノード障害時にクオーラム数を判断



ファイルシステム・マネージャを選択



ファイルシステム・マネージャの障害時には

GPFSノードのロール File System Manager

-￭ File system Manager

− 各ファイルシステムにひとつ存在

− File System Manager ノードに障害が発生し

た場合は、Cluster Managerによって他のノー

ドにTakeoverされる

− ファイルシステムを管理するためにCPUとメモ

リをより消費

− クラスタ構成時、変更時、ノード追加時にFile

system Managerとなれるノードを指定可能

File system Manager

1対1

File system

File system

File system Manager

Cluster

Manager

指定

NSD

NSD

NSD



ファイルシステムの構成



ディスクスペースアロケーションの管理



トークンの管理

分散ロックマネージャー トークンの管理（１）

-￭ トークン

• GPFSでは、ファイルへの同時アクセス制御にトークンを使用

• File System Managerが発行

• 複数のノードが同一ファイルにアクセスしたときに効果を発揮

− データ整合性の維持

分散ロックマネージャー トークンの管理（２）

-File system

File System Manager

Node A

Node B

①トークン取得要求

②トークン発行

③ファイルアクセス

④トークン取得要求

⑤ノードリスト

⑥トークンの受け渡し

NSD

①トークン取得要求

Node AよりFile System Managerへ要求

②トークン発行

該当ファイルの対象部に関して最初の要求

であるため、トークンを発行

③ファイルアクセス

トークンを取得しファイルにアクセス

④トークン取得要求

Node Bより File System Managerに要求

⑤ノードリスト

既に該当部に対してトークン発行済みなので

そのトークンを使用しているノードリストを渡す

⑥トークンの受け渡し

Node Aがトークンをマネージし、必要に応じて

Node Bとやり取りしトークンを受け渡す

⑦ファイルアクセス

トークンがわたってきた段階でファイルにアクセス

⑦ファイルアクセス

Data

File system

GPFSノードのロール Metanode

-￭ Metanode

− オープンされるファイル毎にひとつ存在

− 多くの場合最も長く継続してファイルをオープンし続けたノード

− 全てのノードは、ファイルの内容を直接、読み/書きできるがメタ･データへの変更は

Metanodeのみ可能

メタデータの整合性の保持

メタデータの更新依頼 メタデータの更新 metanode

NSD

MetaData

NSD

Data

Q

Q

Q

3ノードクォーラム(充足数2)の場合

1ノード障害は連続稼動

ノード障害

クラスター・マネージャの障害で も他のノードへ引き継ぐ

GPFS

GPFS

GPFS

ノード・クォーラム：

・クォーラム充足数が維持される限り連続稼動

・クォーラム対象ノード : 3 の場合

・充足数 : 2ノード

・障害ノードが1つ

→ 連続稼動

・障害ノードが2つ

→ サービス停止

・クォーラム対象ノードは任意に指定可能

【例】

GPFS環境における障害時の動き（１）（ノード障害ケース）

GPFS環境における障害時の動き（２） （通信障害ケース）

T

Q

Q

Q

通信障害

クラスター・マネージャー・ノード(CM)のいる島がサービスを継続する

２サーバーの島にCMがいれ

ば、クォーラムを維持している

ので、サービスを継続する。

１サーバーの島の方は、サー

ビスを停止する。

１サーバーの島はクォーラムを維持できな

いので、サービスを停止する。（ＣＭがいて

も同じ） ２サーバーの島でサービスを再開

する。CMは２サーバーのどちらかに移動す

る。ただし、１サーバーからタイブレーカー

ディスクにアクセスできる場合、１サーバー

の方でサービスを継続する。

GPFS

GPFS

GPFS

【例】

GPFS環境における障害時の動き（３）（通信障害ケース）

T

Q

Q

アクセス権の確保

通信障害

連続稼動

停止

シングルノード・クォーラム：

全体で8ノード以下の場合、先に特定のディスク (Tie-Breaker

ディスク) へのアクセス権を取ったノードが連続稼動

CMが稼動を継続する。タイブレーカーにアクセスできる。

クラスター・マネージャー・ノードでない方はサービスを停

止する。