デルHPC NFS ストレージソリューション -...

デルHPC NFSストレージソリューション

高可用性構成

デルテクニカルホワイトペーパー

Garima Kochhar、Xin Chen、Onur Celebioglu

デル HPCエンジニアリング

2011年 4月

デル HPC NFSストレージソリューション - 高可用性構成

Page ii

本ホワイトペーパーは、情報の通知のみを目的とし、印刷上のミスおよび技術的な不正確性を含む場合が

あります。内容は現状のまま提供され、いかなる種類の明示的または黙示的な保証もいたしません。

(C) 2011 Dell Inc. All rights reserved. いかなる方法によっても、Dell Inc.の書面による許可なく本資料を

複製することを固く禁じます。詳細はデルにお問い合わせください。

Dell、DELLのロゴ、および DELLバッジ、PowerConnectおよび PowerVault は Dell Inc.の商標です。そ

の他の商標および商標名は、本文書においてそのマークまたは名前を要求する事業体またはその事業体の

製品を言及するために使用される場合があります。Dell Inc.は自社が所有する以外の商標および商標名の

所有権を放棄します。

2011年 4月


Page 1

目次

概要 ................................................................................................................................................................................................. 3

1. はじめに..........................................................................................................................................................................4

1.1. デルの NSSソリューション ..........................................................................................................................4

2. デル NFSストレージソリューションの技術的概要 .................................................................................... 5

3. 高可用性対応 NFSストレージソリューション...............................................................................................6

3.1. ハードウェア .......................................................................................................................................................6

3.2. ソフトウェア .......................................................................................................................................................9

3.3. 高可用性クラスタ ..............................................................................................................................................9

3.4. 考えられる障害とフォールトトレランスメカニズム ....................................................................... 11

3.5. NSS-HAソリューション構成 .................................................................................................................... 12

3.6. 中規模構成から大規模構成へのアップグレード ............................................................................... 12

4. 評価 ................................................................................................................................................................................ 13

4.1. 評価方法 ............................................................................................................................................................. 13

4.2. 試験台 .................................................................................................................................................................. 14

4.3. 機能性とパフォーマンスに影響する設計上の選択肢 ...................................................................... 16

4.4. 機能性テスト ..................................................................................................................................................... 17

5. パフォーマンスベンチマークテストの結果 ................................................................................................. 21

5.1. InfiniBandでのシーケンシャル読み書き ............................................................................................. 22

5.2. 10Gbイーサネットシーケンシャル読み書き ..................................................................................... 23

5.3. ランダム読み書き ........................................................................................................................................... 25

5.4. メタデータテスト ........................................................................................................................................... 27

6. NSSソリューション間の比較 ............................................................................................................................. 29

7. 結論 ................................................................................................................................................................................ 30

8. 参考資料....................................................................................................................................................................... 30

付録 A：NSS-HAレシピ ..................................................................................................................................................... 32

A.1. インストール前の準備 .................................................................................................................................. 32

A.2. サーバ側ハードウェアのセットアップ ................................................................................................. 33

A.3. 各 PowerEdge R710サーバの初期ソフトウェア構成 .................................................................... 34

A.4. サーバのパフォーマンスチューニング ................................................................................................. 36

A.5. ストレージハードウェアのセットアップ ............................................................................................. 37

A.6. ストレージ構成 ............................................................................................................................................... 37


Page 2

A.7. NSS HAクラスタセットアップ ............................................................................................................... 38

A.8. HAセットアップのクイックテスト ........................................................................................................ 47

A.9. 便利なコマンドと参考資料 ........................................................................................................................ 47

A.10. クライアントのパフォーマンスチューニング ............................................................................... 48

A.11. スクリプトと構成ファイルの例 ........................................................................................................... 48

付録 B：中規模構成から大規模構成へのアップグレード .................................................................................... 49

付録 C：ベンチマークテストとテストツール ........................................................................................................... 52 C.1. IOzone ................................................................................................................................................................ 52 C.2. mdtest ................................................................................................................................................................. 54 C.3. checkstream ..................................................................................................................................................... 55 C.4. dd .......................................................................................................................................................................... 56


Page 3

概要本ソリューションガイドには、デル HPC NFSストレージソリューション (NSS) の高可用性構成が記載されています。HPC環境では、ユーザデータの高可用性 (HA) を保証することが一般的な要件の 1つになってきています。デル NSSの高可用性構成は、HPC 計算クラスタへのデータアクセスを提供するためにNFSゲートウェイサーバのペアをアクティブ-パッシブ構成で使用することによって、データの可用性を向上させます。デル NSSの最終目標は、考えられる障害や故障が存在するなかでサービスの可用性とデータの整合性を向上させることと、障害ゼロの場合にパフォーマンスを最大化することにあります。本文書には、そうしたソリューションのアーキテクチャとパフォーマンス、そうしたソリューションを構築するためのベストプラクティスが記載されています。


Page 4

1. はじめにクラスタは現在、ハイパフォーマンスコンピューティング (HPC) のための最も一般的なアーキテクチャの 1つとなっています (1)。しかし、プロセッサとネットワークではデータの読み書きに要する時間に差があり、この差とストレージデバイスの処理速度の低下によって、ほとんどの場合はクラスタのストレージサブシステムがシステム全体のパフォーマンスに悪影響を与えるボトルネックと化しています。さらに、費用対効果の高いクラスタは汎用サーバと汎用ストレージデバイスを使って構築されるのが普通であり、そのためそうしたシステムでは障害や故障を完全に回避することは不可能です。そのような環境において高いレベルの信頼性と可用性を維持するのは、重要な問題の 1つです。優れた設計のクラスタは、計算ニーズと I/Oニーズのバランスを確保しなければならないとともに、信頼性と可用性の要素も考慮する必要があります。

特にハイエンドストレージ (>300TB)を必要とし、I/O需要が集中的に発生するクラスタなどのハイパフォーマンスクラスタでは、パラレルファイルシステムが一般的になっています。この要件を満たすのは、Lustreファイルシステムと Dell PowerVaultストレージアレイに基づいた高スループットのスケールアウト型ストレージアプライアンスであるデル | Terascala HPCストレージソリューション (DT-HSS) です (2)（米国のみ提供）。デル NFSストレージソリューション (NSS) は、MPI-I/O指向アプリケーションに伴って I/Oワークロードが集中的に発生することがなく、高いスケーラビリティを必要としない HPCユーザにとって魅力的な選択肢です。NSSソリューションは、Red Hat Scalableファイルシステム (XFS) 上に構築された NFSファイルシステムと Dell PowerVault ストレージを使用し、構造化されていないデータのための管理しやすく信頼性と費用対効果の高いソリューションを提供します (3)。

本ソリューションガイドは、最新の NSSソリューションに高可用性オプション (以下「NSS-HA構成」) を組み込むことによってアップデートするものです。その最終目標は、考えられる障害や故障が存在するなかで NSS構成サービスの可用性とデータの整合性を向上させることと、障害ゼロの場合にパフォーマンス損失を最小化することにあります。たとえば、1つのクラスタコンポーネントに障害が発生した場合、クラスタのクライアントへの影響が最小化され、システムの可用性とユーザデータの整合性の双方が維持されます。

本ソリューションガイドは、そのような HSS-HAソリューションの詳細を記述するものです。まず、次のいくつかのセクションでは、高可用性機能に特に重点を置いて NSS-HAアーキテクチャを詳しく説明します。それ以降のセクションでは、HSS-HAソリューションのパフォーマンスを取り上げます。さらに、NSS-HA環境の構成に関する詳細な手順を示す詳しい付録を末尾に収録しています。

デル NFSストレージソリューションは、包括的なストレージソリューションとして提供され、デルによる導入サービスと完全なハードウェア/ソフトウェアサポートも併せて利用することができます。本ソリューションは、導入しやすさと使いやすさに重点を置き、標準ベースの HPCコンポーネントを使用して設計されています。

本ソリューションの技術的な詳細については本ソリューションガイドの次のセクション以降に、デルから入手可能な NSSオプションについては次のセクションに記載されています。

1.1. デルの NSS ソリューションデル HPC NFSストレージソリューションは、下記の標準構成で提供されています。貴社の環境に最適なソリューションについての相談や注文プロセスについては、デルの営業担当者にお問い合わせください。あらかじめ構成されたソリューションはどれでもすべて注文可能であり、貴社固有のニーズに合わせたカスタマイズも承ります。選択したカスタマイズの内容によっては、本書で取り上げたベストプラクティスの一部を適用できない場合があります。

HA対応なしのソリューションの詳細は、ソリューションガイド『デル HPC向け NFSストレージソリューション(NSS)』を参照してください。本ソリューションガイドに記載されているのは、HA対応NSSソリューションです。


Page 5

小規模構成中規模構成中規模構成-HA ● 20TBの利用可能スペース。 ● QDR InfiniBandまたは 10Gbイーサネット接続。

● NFSゲートウェイサーバ：Red Hat Enterprise Linux 5.5および XFSファイルシステムが稼働する Dell PowerEdge R710サーバ。

● ストレージ：2TBの NL SASドライブ 12個を搭載した Dell PowerVault MD1200。

● 3年間のデル PRO Support for IT and Mission Critical 4HR 7x24オンサイトパック。

● 迅速なインストール、パフォーマンス最適化、貴社環境との統合を行うデル導入サービス。

● 40TBの利用可能スペース。 ● QDR InfiniBandまたは 10Gbイーサネット接続。


● ストレージ：2TBの NL SASドライブ 12個を搭載した Dell PowerVault MD1200 2台。



● 40TBの利用可能スペース。 ● QDR InfiniBandまたは 10Gbイーサネット接続。

● NFSゲートウェイサーバ： Red Hat Enterprise Linux 5.5、XFSファイルシステム、Red Hat Cluster Suiteが稼働する 2台のDell PowerEdge R710サーバ

● ストレージ:それぞれ2TBのNL SASドライブ 12個を搭載した 1台のDell PowerVault MD3200と 1台のDell PowerVault MD1200エンクロージャ。

● PowerConnect 5424と 2個の切替 PDUで高可用性を管理。


大規模構成大規模構成-HA ● 80TBの利用可能スペース。 ● QDR InfiniBandまたは 10Gbイーサネット接続。


● ストレージ：2TBの NL SASドライブ 12個を搭載した 4台の Dell PowerVault MD1200。

● 3年間のデルPRO Support for IT and Mission Critical 4HR 7x24オンサイトパック。


● 80TBの利用可能スペース. ● QDR InfiniBandまたは 10Gbイーサネット接続.

● NFSゲートウェイサーバ：Red Hat Enterprise Linux 5.5、XFSファイルシステム、Red Hat Cluster Suiteが稼働する 2台の Dell PowerEdge R710サーバ。

● ストレージ：それぞれ 2TBの NL SASドライブ12個を搭載した 1台の Dell PowerVault MD3200と 3台の MD1200エンクロージャ。

● 1台の PowerConnect 5424と 2個の切替 PDUで高可用性を管理。


2. デル NFSストレージソリューションの技術的概要本セクションには、HA対応なしのデル NFSストレージソリューション (NSS) の技術的な詳細に関する概要が記載されています。このソリューションの機能、構成とチューニングに関するガイダンス、パフォーマンス特性、サポートは『デル HPC NFSストレージソリューション (NSS) ソリューションガイド』に記載されています(3)。

HA対応なしの NSSソリューションは、1台の PowerEdge R710サーバとそれに取り付けられた複数のPowerVault MD1200から構成されています。各MD1200ストレージアレイには 12個のディスク (2TB

7200rpm) が搭載され、1個の 10+2 RAID 6仮想ディスクとして構成されています。複数の RAID 6 LUNがRAID 60 (オプションとして Linux LVM) を使用して結合され、Red Hat Scalableファイルシステム (XFS)としてフォーマットされます。この XFSファイルシステムは、NFS経由で計算ノードにエクスポートされます。計算ノードは、InfiniBandまたは 10Gbイーサネットネットワーク経由でストレージにアクセスします。


Page 6

NSSソリューションには小規模構成、中規模構成、大規模構成の 3種類の構成があります。これらはそれぞれ 20TB/40TB/80TBソリューションに対応します。図 1に、2台の PowerVault MD1200を使用するNSS中規模構成を示します。

図 1 - NSS-中規模構成

HA対応 NSS (NSS-HA) は、高可用性機能を導入することによって上記の NSSソリューションを拡張したものです。HSS-HAは、NSSビルディングブロック (サーバ、ソフトウェア、ストレージ、RAID構成など) とパフォーマンスのチューニングに関するベストプラクティスを可能な限り活用しています。

3. 高可用性対応 NFSストレージソリューション高可用性対応 NFSストレージソリューション (NSS-HA) は、Dell PowerEdge R710サーバのペアから構成され、そのペアはどちらも 1台の共有 PowerVault MD3200ストレージエンクロージャ (PowerVault

MD1200ストレージアレイによって拡張されたもの) に物理的にアクセスします。この 2台のサーバにはアクティブ-パッシブ構成が採用されており、そのうち 1台のサーバがデータへの常時アクセスを提供します。計算ノードは、NFSクライアントとして NSS-HAサーバ経由でデータにアクセスします。計算ノードは、どのサーバがストレージへのデータパスを所有しているかを区別しません。

HA機能は、ハードウェアとソフトウェアの組み合わせを通して実現されます。次のいくつかのセクションにはアーキテクチャが、『付録 A：NSS-HAレシピ』には NSS-HA環境の設定に関する段階的な指示が記載されています。

3.1. ハードウェア

NSS-HA構成を図 2に示します。NSS-HA構成では、高いレベルの可用性を実現するために、ハードウェアコンポーネントの冗長性が確保されています。

クラスタ相互接続 InfiniBand/イーサネット

IB/10GbE HCA

R710サーバ

H800

冗長 6Gbps SAS

MD1200s

NSSアプライアンス

計算ノード


Page 7

▪ サーバの冗長性

NSS-HAには、PowerEdge R710サーバのペアが含まれます。この 2台のサーバは、Red Hat Cluster

Suite (以降のセクションで説明します) を使用してアクティブ/パッシブモードで構成されます。アクティブ/パッシブモードでは、1台のサーバに障害が発生すると、障害が発生したサーバ上で実行されているサービスを残りの 1台が自動的に引き受けます。したがって、フェイルオーバが行われている間に短い中断が発生する可能性はありますが (セクション 4.4を参照)、単一サーバ障害によってサービスが失われることはありません。

図 2 - NSS-HA構成

各 PowerEdge R710サーバには、1個の Dell PERC H700内部 RAIDコントローラと 5個のローカルハードディスクが搭載されています。そのうち 2個のディスクは RAID 1で構成され、1個のディスクはオペレーティングシステムイメージのホットスペアとして指定されます。残り 2個のディスクはRAID 0で構成され、スワップスペースに使用されます。各サーバには、外部の PowerVault

MD3200ストレージエンクロージャに接続するためのデュアルポート Dell 6Gbps SAS HBAが 1

個搭載されています。各サーバには、計算ノードに接続するための InfiniBandカードまたは 10Gb

イーサネットカードが 1個装着されています。サーバには、アウトオブバンドシステム管理のための iDRAC Enterprise管理カードも 1個搭載されています。

▪ 電源の冗長性

各サーバには、デュアル電源が用意されています。サーバに組み込まれている電源は、それぞれ 1

個の電源用 PDUを経由して異なる電源バスに接続されています。これにより、電源の単一点障害が回避されます。構成には、2つの電源に使用する 2個の電源用 PDUも含まれます。

INFINIBANDまたは 10GBE (パブリックネットワーク)

POWERVAULT MD3200 と MD1200ストレージ

POWEREDGE R710サーバ

APC 切替 PDU

Gbイーサネットスイッチ (プライベートネットワーク) パブリックネットワーク

プライベートネットワーク電源ストレージネットワーク


Page 8

▪ ネットワークの冗長性

サーバは、アクティブサーバとパッシブサーバ間の通信用プライベートネットワークとして使用される 1個の Gbイーサネットスイッチに接続されています。このネットワークは、アクティブサーバとパッシブサーバ間のハートビートを監視するために使用されます。iDRAC や電源用 PDUとの通信にも、このプライベートネットワークが使用されます。

サーバは、InfiniBandまたは 10Gbイーサネットネットワークにも接続されています。このネットワークは、パブリックネットワークと呼ばれます。計算クラスタは、このパブリックネットワーク経由でサーバにアクセスします。パブリックネットワークスイッチは、NSS-HA設計とは別になっています。パブリックネットワークの信頼性と構成は、クラスタが要求する高可用性を実現しているものと想定されます。1台の NFSサーバで 1件の単一ネットワークカード障害が発生した場合は、クライアントへの同等のデータパスを持つ 2台めのサーバがあるために耐えることができます。

▪ ディスクの冗長性

ユーザデータ用ストレージは、1台の PowerVault MD3200 エンクロージャと 1 台以上のPowerVault MD1200拡張アレイから構成されます。各アレイには、12個の 3.5インチ 2TB 7200rpm NearLine SASディスクが搭載されています。各アレイのディスクは RAID 6でセットアップされ、10個のデータディスクと 2個のパリティディスクによる 10+2構成になっています。こうした RAID構成は、1 件のディスク障害が発生したときにデータを再構築するには十分な冗長性を実現します。各仮想ディスクのセグメントサイズは 512kです。これにより、各ストレージアレイの利用可能スペースのキャパシティは 20TB (10個のデータディスク xディスク当たり 2TB) になります。

PowerVault MD3200は、読み込みキャッシュが有効、書き込みキャッシュが有効、書き込みキャッシュミラーリングが有効、読み込みプリフェッチが有効となるよう構成されています。キャッシュのブロックサイズは 32kに設定されています。キャッシュミラーリング機能が有効であるため、MD3200に搭載されている 2個の RAIDコントローラがキャッシュをミラーリングします。単一の RAIDコントローラ障害は、データの可用性への影響なしに耐えることができます。

図 3 - PowerVaultストレージのケーブル接続の例

アクティブサーバパッシブサーバ


Page 9

▪ I/Oパスの冗長性

各サーバは、MD3200上の 2個のコントローラの両方に接続されています。各サーバは 2本の SAS

ケーブルでMD3200に直接接続されているため、サーバからストレージへの I/Oパスにおいて単一点障害が発生する可能性はありません。MD3200からMD1200アレイへの冗長パスは、ストレージ I/Oパスの可用性を高めるために導入されたものです。ストレージのケーブル接続を図 3に示します。

3.2. ソフトウェア

本ソリューションの重要なソフトウェアコンポーネントを図 4に示します。

NSS-HAは、Red Hat Enterprise Linux 5.5 x86_64 (RHEL 5.5) 上で稼働します。高可用性コンポーネントは、RHEL 5.5から入手可能なアドオン機能の 1つである Red Hat Cluster Suite (4)(5) によって提供されます。

ユーザデータは、共有ストレージ (Dell PowerVaultストレージアレイによって実現される) 上に作成される Red Hat XFSファイルシステムに常駐します。共有ストレージ上の仮想ディスクは、Linux Logical

Volume Manager (LVM) を使用してグループ化されます。このファイルシステムは、ネットワークファイルシステム v3 (NFS) を使用してクライアントまたは計算ノードにエクスポートされます。

クライアントは、InfiniBandまたは 10Gbイーサネット (10GbE) 経由でデータにアクセスします。10GbEドライバは、RHEL 5.5のネイティブです。InfiniBandクラスタには OFED 1.5.1をインストールする必要があります。

PowerVault ストレージアレイは、Dell Modular Disk Storage Manager (MDSM) を使用して管理します。PowerEdgeサーバは、Dell OpenManage Systems Administrator (OMSA) を使用して管理します。

図 4 - NSS-HAソフトウェアコンポーネント

3.3. 高可用性クラスタ

シンプルな NSSソリューションでは、単一の NFSサーバを通して共有ストレージへのアクセスが提

Red Hat Enterprise Linux 5.5

Red Hat Cluster Suite

NFSバージョン 3

XFSディスクファイルシステム

HA LVM

OFED 1.5.1 10GbEドライバ SAS HBA ドライバ

DM- マルチパス


Page 10

供されます。この NFSサーバに 1件の障害が発生した場合や 1件のネットワーク障害が発生した場合は、共有ストレージサービスへのクライアントアクセスが停止し、システム全体の可用性に影響します。より高いシステムの可用性を実現するために、HSS-HAソリューションでは Red Hat Cluster Suite

(RHCS) を使用して NSSを拡張しています。

RHCSベースのクラスタ化には、高可用性機能が含まれます。クラスタサービスは、どのクラスタメンバーまたはクラスタコンポーネントに 1件の障害が発生しても、そのクラスタが提供するサービスが停止することのないよう構成されます。この高可用性機能を活用して、NSS-HAには「HAクラスタ」が構築されています。HAクラスタは 2台の PowerEdge R710サーバから構成され、2台のサーバのうちの 1台で実行される 1件のHAサービスが定義されます。データの整合性を確保するために、この HAサービスは常に 1 台のクラスタサーバ上でのみ稼働するものでなければなりません。１件の障害が発生した場合、HA サービスは他方の PowerEdge R710サーバにフェイルオーバされ、その間はプロセス全体がクラスタのクライアントから可能な限り最大限に透過的に維持されます。

HAとの関連においては、「クラスタ」という用語は PowerEdge R710サーバのペアと RHCSソフトウェアを指します。これは、クライアントと呼ばれる HPCクラスタ (または計算クラスタ)とは明確に異なります。「サーバ」という用語は、HAクラスタを構成する PowerEdge R710 サーバを指します。 HAサービスは、1つ以上のクラスタリソースによって定義されます。クラスタサービスを起動し実行するには、すべてのリソースが利用可能でなければなりません。サービスが 1台のサーバから別のサーバに移行する場合は、すべてのリソースが移行します。クラスタリソースは、定義され構成された後は HAクラスタサービスによって独占的にコントロールされます。HAクラスタ構造の外で操作しないでください。

NSS-HAでは、HAサービスは次のリソースから構成されます。

1) LVM - LVMは、HA サービスが管理する論理ボリュームを指定します。ストレージアレイ上に作成された仮想ディスクは、1つの Linux論理ボリュームにグループ化されます。この LVMは、LVMに常に 1台のサーバのみがアクセスするよう確実を期するために、NSS-HAでは HAで構成されます。

2) ファイルシステム - LVMは、1つの XFSファイルシステムとしてフォーマットされます。ユーザデータはこのXFSファイルシステムに常駐します。このファイルシステムのマウントオプション、マウント、アンマウントは、HAサービスがコントロールします。

3) NFSエクスポート - NFSエクスポートリソースは、NFSデーモンが実行されていることを確認します。XFS ファイルシステムは、NFS 経由でクライアントにエクスポートされます。NFS エクスポートのオプションとクライアントアクセスは、HA サービスがコントロールします。

4) サービス IP - HAサービスには、1個の IPアドレスが関連付けされます。NSS-HAでは、クライアントアクセスがこのサービス IPを使用してファイルシステムにアクセスし、そのファイルシステムを NFS経由でマウントします。この IPは、クラスタサービスを現在実行しているサーバ上のパブリックネットワークインタフェースに関連付けされます。

5) リンク監視 - リンク監視は、サービス IPアドレスが関連付けされているパブリックネットワークインタフェースの状態をチェックします。リンクに障害が発生すると、クラスタサービスは他方のサーバにフェイルオーバします。パブリックインタフェースに障害が発生するとクライアントがファイルシステムにアクセスできなくなることから、これは HA クラスタの重要なコンポーネントの 1つです。

クラスタサービスは、HA クラスタ内の 2台のサーバ間で移行つまりフェイルオーバすることができます。ただし、HAサービスを所有するのは常に 1台のサーバのみです。HAサービスの所有権を得る前に、そのサーバ (「アクティブ」) は 2台めのサーバ (「パッシブ」) がサービスを実行していない


Page 11

ことを確認しなければなりません。これは、データが確実に保護され、両方のサーバが同時にストレージに書き込む状況が決して発生しないようにするためです。「アクティブ」サーバは、最初に「パッシブ」サーバが HAサービスを提供していないことを確認できる場合に限って、HAサービスを開始します。この確認は、「パッシブ」サーバの再起動つまり「フェンシング」によって実行されます。

フェンシングは HAクラスタの運用に不可欠なコンポーネントの 1つであり、そのため HSS-HAソリューションには、NSS-HA ハードウェアに関するセクションですでに説明したように、iDRACとマネージド電源タップ (PDU) という 2種類のフェンスデバイスが含まれます。「アクティブ」サーバが「パッシブ」サーバをフェンスしようとするときは、最初に「パッシブ」サーバの iDRACへのログインと「パッシブ」サーバの再起動を行うことによってフェンシングを試行します。それが失敗した場合、「アクティブ」サーバは APC PDUへのログインを試行し、「パッシブ」サーバのパワーポートの電源スイッチを切ってすぐに入れ直そうとします。「アクティブ」サーバは、フェンシングが成功するまで上記の 2つのフェンス方法を繰り返し試行します。

アクティブ-パッシブという HAの考え方とは、2台のアクティブサーバが同じデータボリュームにアクセスしようとしてデータが破損するリスクを冒すよりも、HAサービスを提供するサーバがゼロになるほうがよいとする考え方です。したがって、2台のサーバがいずれもクラスタサービスを提供していないという状況が発生する可能性があります。このような状況においては、システム管理者が介入して、クライアントがデータにアクセスできる健全な状態にクラスタを復旧させる必要があります。

3.4. 考えられる障害とフォールトトレランスメカニズム

NSS-HAには、HA機能を構築するためのハードウェアコンポーネントとソフトウェアコンポーネントが含まれます。最終目標は、複数のタイプの障害に対する回復力を確保し、クラスタサービスを 1

台のサーバから他方のサーバに透過的に移行することにあります。本セクションは、考えられる障害に対する NSS-HAの対応を取り上げます。下記の障害に耐えるよう NSS-HAを構成する方法に関する詳細な指示は、『付録 A：NSS-HAレシピ』に記載されています。

クラスタサービスがアクティブサーバ上で実行されていると想定し、『表 1 - NSS-HAの障害対応メカニズム』にさまざまなタイプの障害と障害が発生した際の NSS-HAクラスタの挙動を列挙します。

表 1 - NSS-HAの障害対応メカニズム

障害タイプ障害対応メカニズム

1 台のサーバ上の単一ローカルディスク障害

オペレーティングシステムは、ディスクを 2個搭載した RAID 1デバイスにインストールされており、1つはホットスペアです。単一ディスク障害によりサーバが停止する可能性はありません。

単一サーバ障害クラスタサービスにより監視されます。サービスはパッシブサーバにフェイルオーバされます。

電源または電源バス障害各サーバはデュアル電源方式です。電源はそれぞれ別の電源バスに接続されています。サーバは単一の電源で引き続き機能します。

フェンスデバイス障害 iDRACがプライマリフェンスデバイスとして使用されます。切替 PDUはセカンダリフェンスデバイスとして使用されます。

SASケーブル/ポート障害 2 つのポート SAS カードと 2 本の SAS ケーブルでストレージに接続されています。単一 SASポート/ケーブル障害がデータ可用性に影響することはありません。

二重の SASケーブル/ポート障害

クラスタサービスにより監視されます。ストレージへのデータパスがすべて失われた場合、サービスはパッシブサーバにフェイルオーバされます。


Page 12

障害タイプ障害対応メカニズム

InfiniBand/10GbE リンク障害

クラスタサービスにより監視されます。サービスはパッシブサーバにフェイルオーバされます。

プライベートスイッチ障害

クラスタサービスはアクティブサーバで引き続き実行されます。1件のコンポーネント障害が追加発生した場合、サービスは停止し、システム管理者による介入が必要です。

ハートビートネットワークインタフェース障害

クラスタサービスにより監視されます。サービスはパッシブサーバにフェイルオーバされます。

MD3200 ストレージアレイ上での RAID コントローラ障害

MD3200 には 2 個のコントローラが搭載されています。第 2 のコントローラがすべてのデータ要求を処理します。パフォーマンスが低下する可能性はありますが、機能性には影響はありません。

3.5. NSS-HAソリューション構成

HSS-HAソリューションには、中規模構成と大規模構成の 2種類があります。中規模構成の利用可王なストレージは 40TBであり、大規模構成では利用可能なストレージが 80TBに拡大します。

中規模構成と大規模構成は、どちらも 1台の PowerVault MD3200ストレージアレイに接続された 2

台の PowerEdge R710サーバから構成されています。中規模構成と大規模構成の違いは、ストレージのキャパシティだけです。中規模構成では 1台の PowerVault MD1200拡張アレイを使用してMD3200

ストレージアレイを拡張し、大規模構成では 3台の MD1200アレイを使用します。図 3に大規模構成を、図 5に中規模構成を示します。中規模構成や大規模構成のセットアップに関する詳細な指示は、『付録 A：NSS-HAレシピ』に記載されています。

図 5 - NSS-HA中規模ストレージ構成

3.6. 中規模構成から大規模構成へのアップグレード

本ホワイトペーパーに記載されている NSS-HAのアーキテクチャと PowerVault ストレージアレイの設計により、中規模 NSS-HA構成から大規模 NSS-HA 構成へのアップグレードは容易です。アップグレードプロセスでは、NSS-HA中規模クラスタに 2台の PowerVault MD1200ストレージアレイを追加します。追加する新しいストレージアレイは、仮想ディスクを作成することができるように構成しなければなりません。クラスタサービス、スイッチ、構成は同じです。

アクティブサーバパッシブサーバ


Page 13

NSS-HAソリューションをアップグレードするには、次の 2つの方法があります。

1) キャパシティを追加し、パフォーマンスは現状を維持するこの方法では、ユーザデータがアップグレード中に保存されます。最終的な構成はキャパシティが 80TBになりますが、パフォーマンスは中規模構成と同じです。

2) キャパシティを追加し、パフォーマンスを向上させるこの 2 つめの方法では、すべてのユーザデータをバックアップしなければなりません。アップグレードによって既存の中規模構成が消去され、大規模構成が作成されます。

2種類の構成のパフォーマンスは、『パフォーマンスベンチマークテストの結果』のセクションで取り上げます。『付録 B：中規模構成から大規模構成へのアップグレード』には、前述した 2つのアップグレード方法に関する詳細な指示が記載されています。

4. 評価本ホワイトペーパーにおいて提案されているアーキテクチャは、Dell HPCラボで評価されたものです。本セクションには、テスト方法と検証に使用した試験台についての記述が収録されています。あわせて、機能性テストの詳細も記載されています。パフォーマンステストの結果は、次のセクションに掲載されています。

4.1. 評価方法

検証は、機能性、データの正確性、パフォーマンスの 3つの重要な分野に集中して行われました。

クラスタサービスのフェイルオーバをテストするために、さまざまなコンポーネント障害のシミュレーションを行いました。前のセクションで説明したデュアル電源、ストレージへのデュアル SASリンク、デュアル PDUなどのハードウェアの冗長性とは別に、HAクラスタはいくつかのタイプのコンポーネント障害を自動的に検出し、それらに耐えます。

障害シナリオの進行中は、ストレージからの読み書きを実行中のクライアントとのアクティブデータ接続がある可能性が高いと考えられます。フェイルオーバ中にデータの正確性を維持するのは、重要な要件の 1つです。

NSS-HAソリューションのパフォーマンステストは、本ソリューションの最大限のキャパシティを把握するために、障害ゼロのケースに基づいて実施されました。


Page 14

4.2.試験台

本サブセクションでは、HSS-HAソリューションの機能性とパフォーマンスを評価するために使用した試験台について説明します。図 6に、本研究で使用した試験台を示します。

図 6 - 試験台の構成

2台の PowerEdge R710サーバが、NFSゲートウェイサーバとして使用されました。これらのサーバは、PowerVault MD1200アレイによって拡張された PowerVault MD3200ストレージに接続されていました。中規模構成には 1台の PowerVault MD1200アレイを使用し、大規模構成では 3台の MD1200

アレイを使用しました。サーバ間のプライベート HA クラスタネットワークとして、PowerConnect

5424 Gbイーサネットスイッチを使用しました。HAクラスタには、APCスイッチ電源用 PDUを使用しました。

クライアントクライアント

パブリックネットワーク (IBまたは 10GbE)

NSS-HAコンポーネントパブリックネットワークプライベートネットワーク電源ストレージ接続


Page 15

HPC計算クラスタは、Platform Cluster Manager - Dell Editionバージョン 2.0.1を使用して導入された 64台の PowerEdge R410サーバから構成されました(6)。表 2、表 3、表 4、表 5に構成の詳細を示します。

表 2 - NSS-HAハードウェア構成の詳細

サーバ構成

NFSゲートウェイサーバモデル 2台の PowerEdge R710サーバ

プロセッサ Dual Intel Xeon E5630 @ 2.53GHz

メモリ 12 x 4GB 1333MHz RDIMM

ローカルディスクと RAIDコントローラ PERC H700と 5個の 146GB 10K SASハードドライブ

オプションの InfiniBand HCA (スロット4)

Mellanox ConnectX-2 QDR PCI-Eカード

オプションの 10Gb イーサネットカード (スロット 4)

Intel X520 DA 10Gb Dual Port SFP+ Advanced

外部ストレージコントローラ (スロット3)

6Gbps SAS HBA

システム管理 iDRAC Enterprise

電源デュアル PSU

ストレージ構成

ストレージエンクロージャ 1台の PowerVault MD3200、1つまたは 3つのMD1200拡張アレイ PowerVault MD3200でHigh Performance Tier機能に対応

RAIDコントローラ MD3200に Duplex RAIDコントローラを搭載

ハードディスクドライブ各アレイに 12個の 2TB 7200 rpm NL SASドライバを搭載

その他のコンポーネント

プライベート Gbイーサネットスイッチ PowerConnect 5424

電源タップ (PDU) 2個の APC切替ラック PDU (モデル AP7921)

表 3 - NSS-HAソフトウェア構成の詳細

ソフトウェア

オペレーティングシステム Red Hat Enterprise Linux (RHEL) 5.5

カーネルバージョン 2.6.18-194.el5 x86_64

クラスタスイート RHEL 5.5の Red Hat Cluster Suite

ファイルシステム Red Hat Scalable File System (XFS) 2.10.2-7

システム管理 Dell OpenManage Server Administrator 6.4.0

ストレージ管理 Dell Modular Disk Storage Manager 1.2.0.12


Page 16

表 4 - NSS-HAファームウェアおよびドライバ構成の詳細

ファームウェアとドライバ PowerEdge R710サーバ BIOS 2.2.10

PowerEdge R710サーバ iDRAC 1.54

InfiniBandファームウェア 2.8.00

InfiniBandドライバ Mellanox OFED 1.5.1

10Gbイーサネットドライバ ixgbe 2.0.44-k2

PERC H700ファームウェア 12.10.0-0025

PERC H700ドライバ megaraid_sas 00.00.04.17-RH1

6Gbps SASファームウェア 07.01.33.00

6Gbps SASドライバ mpt2sas 01.101.06.00

表 5 - NSS-HAクライアント構成の詳細

クライアント / HPC計算クラスタ

クライアント 64台の PowerEdge R410計算ノード InfiniBand Mellanox ConnectX-2 QDR HCAs

Mellanox OFED 1.5.1 InfiniBand ファブリック

すべてのクライアントを単一のラージポートカウント InfiniBandスイッチに接続。

R710 NSS-HAサーバも 2台とも InfiniBandスイッチに接続。

イーサネット Onboard 1 GbE Broadcom 5716ネットワークアダプタ。

bnx2ドライバ v2.0.8e

イーサネットファブリック

2個の PowerConnect 6248Gbイーサネットスイッチに接続された 32個の計算ノードが 2セット搭載されています。

PowerConnect 6048スイッチは 2個とも 1個の 10GbE PowerConnect 8024スイッチにアップリンクされています。

R710 NSS-HAサーバは 2台とも PC8024スイッチに直接接続されています。

4.3. 機能性とパフォーマンスに影響する設計上の選択肢

HAクラスタ構成には、機能性とパフォーマンスに影響する複数の設計上の選択肢が含まれます。それらの選択肢は、本セクションに記載されています。HSS-HAソリューションの構成の詳細は、『付録A：NSS-HAレシピ』に記載されています

ストレージアレイ構成

1) ストレージアレイは、12個の 2TB NearLine SASディスクで構成されています。3.5 x 2TBディスクは、費用対効果の高い価格ポイントで大規模なキャバシティを実現します。


Page 17

2) 仮想ディスクは、RAID 6 を使用して 10 個のデータディスクと 2 個のパリティディスクとして作成されています。この RAID構成は、キャパシティと複数のディスク障害に耐える信頼性とのすぐれたバランスを実現します (7)。

3) 仮想ディスクは、パフォーマンスを最大化するために 512kのセグメントサイズで作成されています (7)。この値は、そのクラスタに関して予想されるアプリケーション I/O プロファイルに基づいて設定してください。

4) キャッシュのブロックサイズは、パフォーマンスを最大化するために 32k に設定されています。この値は、そのクラスタに関して予想されるアプリケーション I/O プロファイルに基づいて設定してください。

5) コントローラがデータアクセスパターンに基づいてデータをキャッシュにプリフェッチできるようにすることでパフォーマンスの最大化を図るために、RAIDコントローラの読み込みキャッシュと書き込みキャッシュが有効になっています (8)。

6) コントローラ障害が発生した場合にデータを保護するため、2つの PowerVault MD3200 RAIDコントローラ間で書き込みキャッシュミラーリングが有効になっています。コントローラ間のキャッシュミラーリングにより、2つめのコントローラがディスクへの書き込みを確実に完了することができます (7)。ただし、この設計上の選択肢を選択する場合は、パフォーマンスに不利な条件が1つ発生します。キャッシュミラーリングを有効にする場合は、キャッシュミラーリングを無効にする場合と比較して、サーバからストレージへの直接書き込みが 20～25%遅くなります。キャッシュミラーリングは、読み込みパフォーマンスにはほとんど影響しません。

NFSサーバ構成

7) XFS ファイルシステムは、wsync オプションでマウントされています。ジャーナリングサブシステムの動作が遅くなるのを防ぐために、XFS はデフォルトで非同期ジャーナリングを使用します。つまり、変更がディスクに書き込まれたことをトランザクションが記録する前に、各動作が完了したものとして信号を送ります。ディスクに対して 1つの動作が完了する前に NFSサーバ上の HAサービスがフェイルオーバすると、NFS クライアントとストレージ上の実際のデータとの間のビューが一致しなくなる可能性があります。この問題を回避するためには、XFSファイルシステムが複数のトランザクションを同期的に実行する必要があります。これは、wsync オプションによって強制されます。その結果として、ジャーナル I/O の増加により XFS メタデータパフォーマンスが低下しますが、サーバがクラッシュし HA サービスがパッシブサーバにフェイルオーバした場合はパッシブサーバによってトランザクションの復旧が正しく行われます。

8) XFSファイルシステムは、NFS syncオプションを使用してエクスポートされます。そのためクライアントは NFS サーバで各書き込み操作が完了するのを待つことになり、サーバ障害が発生した場合にもデータの整合性が可能な限り保証されます。sync オプションにはパフォーマンスに不利な条件が伴いますが、データの整合性を確保するためには 1つの絶対的な要件です。

9) パフォーマンスを最大化するために、サーバ上の同時 NFS スレッドの数を (デフォルトの 8 から256に) を増やしました (3)。

10) パフォーマンスを最大化するために、デフォルト OS スケジューラを cfq から deadline に変更します (3)。

11) パフォーマンスを最大化するために、10Gbイーサネットネットワークに大きなMTU (MTU=8192) をセットします (3)。

4.4. 機能性テスト

HAクラスタサービスのフェイルオーバをテストするために、複数のコンポーネント障害のシミュレーションを行いました。

1) サーバ障害

2) ハートビートリンク障害


Page 18

3) パブリックリンク障害

4) プライベートスイッチ障害

5) フェンスデバイス障害

6) 1件の SASリンク障害

7) 複数件の SASリンク障害

本セクションには、さまざまな障害に対する NSS-HA の反応が記載されています。それらの障害シナリオに対処できるよう HSS-SAソリューションを構成する方法に関する詳細は『付録 A：NSS-HAレシピ』に記載されています。

障害に対するサーバの反応

HAクラスタが障害イベントにどのように反応するかについて、サーバの反応が記録されます。その際に、障害から復旧するまでの所要時間が、パフォーマンス指標の 1つとして使用されます。この所要時間については、HAサービスを実行しているサーバ (アクティブ) に障害が挿入された時点から、サービスが移行され他方のサーバ (パッシブ) で実行されるまでが測定されます。

1) サーバ障害 - カーネルパニックの導入によりシミュレーションを実施。アクティブサーバに障害が発生した場合は、2台のサーバ間のハートビートが停止します。パッシブサーバは所定の期間の間待機し、その後でアクティブサーバをフェンスしようとします。サーバが停止したと宣告されるまでのデフォルトのタイムアウト期間は 10秒です。このパラメータはチューニング可能です。フェンシングが成功したら、パッシブサーバがクラスタサービスの所有権を得ます。

図 7 - サーバ障害が発生した場合のフェイルオーバ手順

図 7に、この場合のフェイルオーバ手順を示します。アクティブサーバに障害が発生した後に、パッシブサーバ上で実行されている RHCSエージェントによってハートビートの途絶が検出されます (設定されたタイムアウト時間に応じて、検出プロセスに数妙要する場合があります)。アクティブサーバ上の障害が検出されると、パッシブサーバはクラスタサービスの所有権を得ようとする前にフェンスデバイス経由でアクティブサーバを再起動します。これは、データの整合性を確保するために行われます。この時点で、Red Hat Service (リソースグループ) Managerの

プライベートネットワーク

ストレージアレイ

HAサービス HAサービスフェイルオーバ

RHCS RHEL 5.5 RHEL 5.5

R 710 R 710 フェンスデバイスフェンスデバイス

フェンシング

アクティブサーバパブリックネットワークパッシブサーバ

クライアント


Page 19

rgmanagerによって HAサービスがパッシブサーバへ移行、つまりフェイルオーバします。クライアントは、フェイルオーバプロセスが完了するまでデータにアクセスできません。

アクティブサーバは、起動するとクラスタに再び結合され、HAサービスは引き続きパッシブサーバで実行されます。

2) ハートビートリンク障害 - アクティブサーバ上でプライベートネットワークリンクの接続を解除することによりシミュレーションを実施。ハートビートリンクがアクティブサーバから取り外されると、両方のサーバがハートビートの途絶を検出し、互いいにフェンスします。アクティブサーバはリンクがないためにプライベートネットワーク経由で接続することができず、したがってパッシブサーバをフェンスできません。パッシブサーバはアクティブサーバのフェンスに成功し、HAサービスの所有権を得ます。

アクティブサーバが起動すると、クラスタとフェンスを開始しようとしますが、ハートビートリンクが引き続きダウンしているためにフェンシングは成功しません。アクティブサーバは、パッシブサーバがオフラインであると判断します。フェンシングが成功しないため、HAサービスはアクティブサーバ上では開始せず、パッシブサーバが引き続きクライアントにファイルシステムを提供します。

ハートビートリンクがアクティブサーバに再び接続されると、パッシブサーバはアクティブサーバ上のクラスタデーモンをシャットダウンします。これは、アクティブサーバがクリーン再起動なしでクラスタに参加するためです。この時点でアクティブサーバ上で実行されているクラスタデーモンは存在せず、そのためクラスタの一部ではありません。

アクティブサーバは、電源を手動で切って入れ直した後にクラスタに再び参加します。パッシブサーバは引き続きクラスタサービスを所有し、ファイルシステムをクライアントに提供します。

3) パブリックリンク障害 - アクティブサーバ上の InfiniBandまたは 10Gbイーサネットリンクの接続を解除することによってシミュレーションを実施。 HAサービスは、このリンクを監視するよう構成されています。パブリックネットワークリンクがアクティブサーバ上で接続解除されると、アクティブサーバ上のクラスタサービスが停止し、パッシブサーバに移動します。リンクに障害が発生したことを検出するまでに要する時間は、InfiniBandの場合は約 30秒、10Gbイーサネットの場合は 20秒です。アクティブサーバ上でパブリックリンクの修理が行われる場合、アクティブサーバがクラスタサービスの所有権を得て開始することはできません。

アクティブサーバのパブリックリンクが修理された後は、クラスタサービスは引き続きパッシブサーバで実行され、クライアントに対するサービスが中断することはありません。

4) プライベートスイッチ障害 - プライベートネットワークスイッチの電源を切ることによってシミュレーションを実施。プライベートスイッチに障害が発生した場合、両方のサーバが他方のサーバからのハートビートの途絶を検出し、互いにフェンスしようとします。ネットワークを利用できないためフェンシングに失敗し、HAサービスは引き続きアクティブサーバ上で実行されます。

スイッチが再び機能するようになったら、両方のサーバが互いに相手のクラスタデーモンを消去します。これは、クリーン再起動なしでサーバがクラスタに再び参加しようとするためです。この時点では HAサービスが引き続き機能し、アクティブサーバ上で稼働し続けます。クラスタ管理デーモンが消去されているため、これは好ましい状態ではありません。クラスタデーモンの再起動は成功しません。デバッグツールを使って HAサービスをストップし、ファイルシステムへのクライアントアクセスを停止させることができます。


Page 20

両方のサーバに手作業で電源を入れ直すと、それらは再びクラスタに参加し、そのうちの 1台がHAサービスの所有権を得て、クライアントにファイルシステムを提供します。

5) フェンスデバイス障害 - サーバから iDRAC ケーブルを取り外すことによりシミュレーションを実施。サーバ上の iDRACに障害が発生した場合、サーバはクラスタ構成ファイルにおいてセカンダリフェンスデバイスして定義されているネットワーク PDU経由でフェンスされます。フェンシングの時点で、1台のサーバが iDRAC経由で他方のサーバをフェンスしようとします。それが失敗すると、ネットワーク PDU経由でフェンスしようとします。サーバはフェンシングが成功するまでこれらのフェンスデバイスを交互に使用します。

6) 1件の SASリンク障害 - PowerEdge R710サーバと PowerVault MD3200ストレージをつなぐ SASリンクの 1つで接続を解除することによりシミュレーションを実施。 1つの SASリンクにのみ障害が発生する場合、クラスタサービスは停止しません。サーバからストレージまでの間には複数のパスがあるため、単一 SASリンク障害によってクライアントからストレージに至るデータパスが中断することはなく、したがってクラスタサービスのフェイルオーバは発生しません。

(1) から (6) までのすべての事例では、HAサービスのフェイルオーバが 1～2分以内に起きることに注意してください。したがって健全なクラスタにおいては、どのような障害イベントであれ、数分以内に Red Hat クラスタ管理デーモンが検知し、対策が実施されます。

7) 複数件の SASリンク障害 - 1台の PowerEdge R710サーバと PowerVault MD3200ストレージをつなぐすべての SASリンクの接続を解除することによってシミュレーションを実施アクティブサーバ上のすべての SASリンクに障害が発生した場合、アクティブサーバ上のマルチパスデーモンが、multipath.confファイルにおいて構成されているパラメータに基づいてストレージへのパスを試します。これはデフォルトで 150秒に設定されています。このプロセスがタイムアウトした後に、HAサービスがパッシブサーバへのフェイルオーバを試みます。

パスが破損しているためにクラスタサービスによって LVMとファイルシステムをクリーンに停止させることができなかった場合は、5分後にウォッチドッグスクリプトがアクティブサーバを再起動します。パッシブサーバがアクティブサーバをフェンスし、HAサービスを再開し、クライアントへのデータを提供します。そのためこのフェイルオーバは、3～8分を要します。

アクティブサーバは、再起動すると再びクラスタに参加します。ただし、サーバとストレージの間で 1つ以上の SASリンクが確立されるまでは、HAサービスを実行するための候補となることはありません。

クライアントへの影響

クライアントは HAサービス IPを使用して、サーバがエクスポートした NFSファイルシステムをマウントします。この IPはサーバ上の InfiniBandまたは 10Gbイーサネットネットワークインタフェースのいずれかと関連付けされています。クライアントへの影響を測定するために、ddユーティリティと iozoneベンチマークを使用して、クライアントとファイルシステム間で複数の大容量のファイルの読み書きを行いました。クライアントがファイルシステムからのデータの読み書きを活発に行っている間に、サーバ上にコンポーネント障害を導入しました。

すべてのシナリオにおいて、クライアントプロセスが読み込み操作と書き込み操作を順調に完了したことが観察されました。フェイルオーバイベント中にプロセスがデータに活発にアクセスしている間は、予想通りクライアントプロセスが操作を完了するまでの時間が長くなりました。InfiniBandの場合、クライアントプロセスが完了するまでの時間は 15～35%長くなりました。10Gbイーサネットの


Page 21

場合、クライアントプロセスが完了するまでの時間は 5～10%長くなりました。クライアントプロセスの所要時間の増分は、実際には分単位 (1～3分)でした。フェイルオーバ期間中にデータ共有が一時的に利用できない場合、クライアントプロセスは連続スリープ状態になることが観察されました。

クライアントプロセスの特徴によっては、フェイルオーバプロセス中に NFSシェアが一時的に利用できなくなるために停止されるかまたはスリープ状態になることが予想されます。ただし、ファイルシステムにすでに書き込まれているデータはすべて、その後も利用可能です。クラスタ構成には、フェイルオーバシナリオにおいてデータを保護するための設計上の選択肢がいくつか含まれています。それらとその他の選択肢についての説明は、『機能性とパフォーマンスに影響する設計上の選択肢』のセクションに記載されています。

フェイルオーバ中の読み書き操作については、checkstreamユーティリティを使用してデータの正確性を検証しました。

使用したツールの詳細は、『付録 C：ベンチマークとテストツール』に記載されています。

5. パフォーマンスベンチマークテストの結果本セクションには、HSS-HAソリューションに関するパフォーマンスベンチマーキングテストの結果を示します。具体的には、パフォーマンステストを行って下記の一般的な I/Oパターンを評価しました。

▪ ラージシーケンシャル読み書き

▪ スモールランダム読み書き

▪ メタデータ操作

これらのテストを、10Gbイーサネットを使用した例と IP-over-InfiniBand (IPoIB) を使用した例について実施しました。この調査には、iozoneベンチマークとmdtestベンチマークを使用しました。ベンチマークテストの詳細は、『付録 C：ベンチマークテストとテストツール』に記載されています。

Iozoneは、シーケンシャルテストとランダムテストに使用しました。I/Oアクセスパターンは N-to-N (自己ファイルへの各スレッドの読み込みと書き込み) でした。Iozoneをクラスタ化モードで実行し、各計算ノードに 1つのスレッドを立てました。シーケンシャルテストに使用したパフォーマンス指標は、スループット (単位：MB/秒) でした。ランダムテストの場合は、1秒あたり I/O操作回数 (IOPS) を指標としました。

ラージシーケンシャル読み込みテストとラージシーケンシャル書き込みテストは、1024KBの要求サイズを使用して実施しました。NFSサーバキャッシュを確実に飽和状態にするため、書き込まれたデータの総量は 128GBに達しました。スモールランダムテストは 4 KBのレコードサイズを使用して実施しました。これは、4 KBというサイズが一般的なランダム I/O ワークロードに対応しているためです。これらのテストでは、すべてのクライアントが 2GBのファイル 1 つの読み込みと書き込みを行いました。

メタデータテストはmdtestユーティリティを使用して実施し、「ファイルの作成 (ファイのル作成)、stats削除 (removals)」が含まれます。これらのベンチマークはすべての I/Oパターンをカバーするものではありませんが、NSS-HAソリューションの I/Oパフォーマンスを特徴付けるには役に立ちます。

NSS-HAソリューションのスケーラビリティをテストするために、任意の範囲のクライアント上で上記のテストの各セットを実行しました。各テストに関与した同時クライアントの数は、1クライアントから 64クライアントまでさまざまでした。

テストは 2種類の NSS-HA 構成 (中規模構成と大規模構成) について行いました。中規模構成では、2個のストレージアレイ全体で 40TBの利用可能スペースがあり、各ストレージコントローラが 1個の仮想ディスクを管理します。大規模構成は、4つのストレージアレイ全体で 80TBの利用可能スペースを提供し、各ストレージコントローラは 2個の仮想ディスクの所有権を持ちます。


Page 22

前述したように、NSS-HAソリューションのキャパシティの上限を把握するために、障害ゼロの状況においてもすべてのパフォーマンスベンチマーキングテストを実施しました。

5.1. InfiniBand でのシーケンシャル読み書き

IPoIBシーケンシャル書き込みテストの結果を、図 8に示します。図に示した数字は、一定数のクライアントが InfiniBandファブリック経由でストレージに同時に書き込みする場合に達成したスループットの合計です。結果は NSS-HA中規模構成と大規模構成に分けて表示しています。これらのベンチマークテスト結果は、NSS-HAソリューションのピークパフォーマンスが 1260 MB/s付近であることを示しています。中規模構成と大規模構成の帯域幅は、両方とも同様です。中規模構成ではストレージコントローラキャッシュを 2個の仮想ディスクが使用し、大規模構成ではこのキャッシュを 4個の仮想ディスク全体で共有します。大規模構成では、仮想ディスク 1個あたりのキャッシュが小さくなるというデメリットがディスクスピンドルを追加することによって得られるメリットによって相殺されるため、2つの構成で同様のパフォーマンスとなっています。それに加えて、NSS-HAソリューションの書き込みパフォーマンスは、NFS syncエクスポートオプションと、MD3200上の RAIDコントローラ間のキャッシュミラーリングによって制限されます。データによれば、2つの構成の両方で、特定のクライアント数を超えた後にパフォーマンスが低下しています。これは、ストレージアレイにNearLine SASドライブが組み込まれているという事実と NFS同時書き込みトラフィックが原因となってディスクの検索処理が多くなり、パフォーマンスが低下するためです。

図 8 - IPoIBラージシーケンシャル書き込みパフォーマンス

IPoIBシーケンシャル読み込みの結果を図 9に示します。この図の数字は、一定数のクライアントがInfiniBandファブリック経由でストレージから同時に読み込む場合に得られる合計スループットを示しています。この結果によれば、NSS-HA大規模構成ソリューションのピーク読み込みパフォーマンスは 2430 MB/秒前後です。中規模構成のピーク読み込みパフォーマンスは 1510 MB/秒です。大規模構成はディスクの数が中規模構成の 2倍であり、ディスクスピンドルが追加されているために読み込みパフォーマンスが高くなっています。したがって、NSS-HAソリューションは規模の拡大/縮小を適切に行うことができ、飽和点は 64クライアントの場合でも観察されていません。

1oIBラージシーケンシャル書き込み

スループット：

MB

/秒

クライアント数

大規模構成中規模構成


Page 23

図 9 - IPoIBラージシーケンシャル読み込みパフォーマンス

5.2.10Gb イーサネットシーケンシャル読み書き

10GbEシーケンシャル書き込みの結果を図 10に示します。この図の数字は、一定数のクライアントが 10Gbイーサネットファブリック経由でストレージに同時に書き込む場合に得られる合計スループットを示しています。

図 10 - 10GbEラージシーケンシャル書き込みパフォーマンス

IPoIBラージシーケンシャル読み込みスループット：

MB

/秒



10GbEラージシーケンシャル書き込み


MB

/秒




Page 24

この結果によれば、NSS-HAソリューションのピーク書き込みパフォーマンスは 1100 MB/秒前後です。大規模構成と中規模構成はともに同様の結果となっており、このソリューションのボトルネックがディスクではなくネットワークであることを示しています。

10GbEシーケンシャル読み込みの結果を図 11に示します。この図の数字は、一定数のクライアントが 10Gbイーサネットファブリック経由でストレージから同時に読み込む場合に得られる合計スループットを示しています。この結果によれば、NSS-HAソリューションのピーク書き込み[訳注：原文がwriteになっていますが、readではないかと思います]パフォーマンスは 550 MB/秒前後です。中規模構成と大規模構成はともに同様の結果となっており、このソリューションのボトルネックがディスクではなくネットワークであることを示しています。

大規模構成と中規模構成のいずれにおいても書き込みパフォーマンスの方が読み込みパフォーマンスを大きく上回ったことは、指摘する価値があります。違いは主に 2つのストレージ RAIDコントローラの 4GBキャッシュの影響によるものです。10GbEネットワークがボトルネックであるように、書き込まれるデータをキャッシュに蓄積してからディスクに送信することでディスク帯域幅を全面的に活用できるため、大容量のキャッシュメモリであれば書き込みパフォーマンスが高くなるのは間違いありません。読み込み要求はただちに充足する必要があるため、読み込み操作がキャッシュによって大幅にスピードアップすることはありません。

図 11 - 10GbEラージシーケンシャル読み込みパフォーマンス

10GbEでの書き込みテストと読み込みテストの両方において、10GbEの方が InfiniBandの場合よりもピークに達するまでが長くなっています。これは、利用可能な最大限のスループットを得るためにより多くのクライアントを必要とするためです。IPoIBでのテストは InfiniBand 接続であるのに対して、試験台の計算ノードは個別の Gbイーサネット接続であることも忘れてはなりません。

このテストは、1個の 10Gbイーサネット接続によって NFSサーバに接続されている単一の NFSクライアントについても実施しました。この場合、NFSクライアントには 1個の 10Gbイーサネットカードのみが装着されています (InfiniBand カードは搭載されていません)。NFSクライアントと NSSサーバの両方が、PowerConnect 8024 10Gbイーサネットスイッチに直接接続されています。この場合の

10GbEラージシーケンシャル読み込み


MB

/秒




Page 25

結果を図 12に示します。図 12に示した 1GbEの場合のデータは、図 10と図 11の結果から得たものです。この 10GbEクライアントの場合、ラージシーケンシャル読み込み帯域幅は、大規模構成では864 MB/秒、中規模構成では 700 MB/秒でした。ラージシーケンシャル書き込み帯域幅は、大規模構成と中規模構成の両方で 219 MB/秒でした。

図 12 - シングル 10GbEクライアント - ラージシーケンシャル読み書き

5.3. ランダム読み書き

InfiniBandと 10Gbイーサネットのランダム読み込みテストとランダム書き込みテストの結果は近似し、平均差は 3%未満でした。本セクションでは、InfiniBandの結果のみを示して説明します。

IPoIBと 10GbEで同様のパフォーマンスとなったことが示しているように、この例におけるボトルネックはネットワークではなくディスクにあります。したがって、ランダム読み書きのパフォーマンスはディスクの検索待ち時間に左右され、ランダム操作に関してキャッシュの果たす役割は小さいことを予期しなければなりません。

シングル 10GbE、1GbEクライアント

ラージシーケンシャル読み書き


MB

/秒

大規模構成-書き込み

1GbE-クライアント

大規模構成-読み込み

中規模構成-書き込み

中規模構成-読み込み

10GbEクライアント


Page 26

図 13 - IPoIBランダム書き込みパフォーマンス

図 13に、IPoIBランダム書き込みパフォーマンスを示します。この図の数字は、一定数のクライアントが InfiniBandファブリック経由でストレージに同時に書き込む場合に得られる合計 1秒あたり I/O

操作(IOPS)を示しています。この結果によれば、NSS-HA大規模構成ソリューションのピークランダム書き込み IOPSは 1930 IOPS前後です。NSS-HA 中規模構成ソリューションでは、950 IOPSです。NSS-HA大規模構成にはディスクスピンドルが追加されているため、パフォーマンスの向上に寄与しています。2つの構成はいずれも、一定範囲のクライアント数にわたってピーク IOPSが同じになっています。NSS-HAランダム書き込みパフォーマンスは、設計上の選択肢である NFS syncエクスポートオプション、MD3200コントローラのキャッシュミラーリング、RAID 6構成でのスモールライトに伴うよく知られたパフォーマンスの制限によって制限されます。図 14に示すランダム読み込みパフォーマンスが書き込みパフォーマンスより優れているのは、このためです。読み込みテストの結果は、NSS-HA大規模構成と中規模構成の両方がクライアント数に合わせた適切な規模の拡大/縮小が可能であることを示しています。さらに、64クライアントでは飽和状態は確認されません。

IPoIBランダム書き込みパフォーマンス




Page 27

図 14 - IPoIBランダム読み込みパフォーマンス

5.4. メタデータテスト

mdtest (ファイルの作成、stat、削除) の結果は、InfiniBand と 10 Gbイーサネットの結果に近似し、その平均差は 5%未満でした。本セクションでは、InfiniBandの場合の結果のみを示し、解説します。 IPoIBと 10GbEで同様のパフォーマンスとなったことが示しているように、この場合のボトルネックはネットワークではなくディスクです。ランダムテストの結果と同様に、メタデータテストでは大量のスモールランダム I/O 要求が生成されるため、このような結果を予期しなければなりません。

図 15、図 16、図 17にそれぞれファイルの作成、stat、削除の結果を示します。これらの結果は、3

つのメタデータ操作すべてがNFSクライアントの数に関してスケーラブルであることを示しています。

IPoIBランダム書き込みパフォーマンス




Page 28

図 15 - IPoIB ファイのル作成パフォーマンス

図 16 - IPoIB statパフォーマンス

IPoIB ファイのル作成パフォーマンス cr

eate数

() /秒

クライアント数大規模構成中規模構成

IPoIB statパフォーマンス

stat

()数

/秒




Page 29

図 17 - IPoIB ファイルの削除のパフォーマンス

6. NSSソリューション間の比較本文書には、デルが提供した既存の非 HA対応 NFSストレージソリューションをベースとして高可用性機能を実現する方法が記載されています。HA機能を追加するには、いくつかのソリューションコンポーネントを変更します。表 6と表 7に HA対応 NSS構成と非 HA対応 NSS構成の相違点を要約します。

表 6 - ハードウェアコンポーネントの比較

ハードウェアコンポーネント

非 HA型 NSS HA型 NSS

利用可能なソリューション構成

小規模構成 20TB、中規模構成 40TB、大規模構成 80TB

中規模構成 40TBと大規模構成 80TB

ストレージ 1、2または 4台のMD1200 1 台の MD3200、1 台または 3 台のMD1200

サーバ 1台の PowerEdge R710サーバ 2台の PowerEdge R710サーバ

ストレージ接続用 HBA 1個または 2個の PERC H800カード 1個の SAS 6Gbpsカード

システム管理 iDRAC Enterprise (オプション) iDRAC Enterprise（必須)

サーバ電源ユニット

(PSU)

2個の電源 (オプション) 2個の電源 (必須)

PDU 切替ラック PDU (オプション) 2個の切替ラック PDU (必須)

プライベートネットワーク

プライベートネットワークなしプライベートネットワーク用Gbイーサネットスイッチ

ローカルディスク用ス PERC H700、5個のローカルディスク

IPoIBのファイルの削除のパフォーマンスファイル削除

()の数

/秒




Page 30

ハードウェアコンポーネント

非 HA型 NSS HA型 NSS

トレージコントローラ

パブリックネットワークからクライアントへ

InfiniBandまたは 10Gbイーサネット

表 7 - ソフトウェア構成の比較

ソフトウェアコンポーネント

非 HA対応 NSS HA対応 NSS

オペレーティングシステム

Red Hat Enterprise Linux 5.5 x86_64

HAクラスタソフトウェア

不要 Red Hat Cluster Suite for RHEL 5.5

システム管理 Dell OpenManage Server Administrator

ストレージ管理不要 Dell Modular Disk Storage Manager

InfiniBandドライバ Mellanox OFED 1.5.1

10 GbEドライバ RHEL 5.5に対しネイティブ

ファイルシステム Red Hat XFS

LVM createパラメータ lvcreate -i <number_of_arrays> -I 1024 -l 100%FREE VGName

XFS createパラメータ mkfs.xfs -l size=128m <path_to_LV>

XFS マウントオプション

"noatime, allocsize=1g, nobarrier, inode64, logbsize=262144"

"noatime, allocsize=1g, nobarrier, inode64, logbsize=262144, wsync"

NFS エクスポートオプション

パフォーマンスが重要な判断基準である場合は"async"

データ修正には"sync"オプションを使用してください。"async" はデータの正確性を保証しません。

7. 結論本ソリューションガイドでは、高可用性機能を含む NFSソリューションによってデル HPCストレージソリューションを強化しています。デル NFSストレージソリューションは、デルによる導入サービスと完全なハードウェア/ソフトウェアサポートと合わせて利用することができます。本文書は、高可用性に対応するソリューションの設計、導入、チューニングに関する完全な情報を提供しています。本ガイドラインには、ハードウェアおよびソフトウェアに関する情報、詳細な構成手順、導入や管理を容易にするベストプラクティスが記載されています。パフォーマンスチューニングに関する注意事項と結果には、このアーキテクチャの対応能力が記述されています。

8. 参考資料

1) 現在は、クラスタが最も一般的な HPC向けアーキテクチャになっています。

http://www.top500.org/overtime/list/36/archtype


Page 31

2) Dell | Terascala HPCストレージソリューション (DT-HSS) (米国のみ提供)

http://content.dell.com/us/en/enterprise/d/business~solutions~hpcc~en/Documents~Dell-terascala-dt-hss2.pdf.aspx

3) デル HPC NFSストレージソリューション (NSS)

http://i.dell.com/sites/content/business/solutions/hpcc/en/Documents/Dell-NSS-NFS-Storage-solution-final.pdf

4) Red Hat Enterprise Linux 5 Cluster Suiteの概要

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/pdf/Cluster_Suite_Overview/Red_Hat_Enterprise_Linux-5-Cluster_Suite_Overview-en-US.pdf

5) Red Hat Enterprise Linux 5での高可用性ウェブサーバの導入

http://www.redhat.com/f/pdf/rhel/Deploying_HA_Web_Server_RHEL.pdf

6) Platform Cluster Manager http://www.platform.com/cluster-computing/cluster-management

7) ハイパフォーマンスコンピューティング (HPC) 導入に向けた DELLTM PowerVaultTM MD1200ストレージアレイの最適化

http://i.dell.com/sites/content/business/solutions/power/en/Documents/Md-1200-for-hpc.pdf

8) アレイのチューニングに関するベストプラクティス

http://www.dell.com/downloads/global/products/pvaul/en/powervault-md3200i-performance-tuning-white-paper.pdf




Page 32

付録 A：NSS-HAレシピ

セクション付録 A：NSS-HAレシピ .............................................................................................................................................................. 32

A.1. インストール前の準備 ...................................................................................................................................................... 32

A.2. サーバ側ハードウェアのセットアップ ...................................................................................................................... 33

A.3. 各 PowerEdge R710サーバの初期ソフトウェア構成 ......................................................................................... 34

A.4. サーバのパフォーマンスチューニング ....................................................................................................................... 36

A.5. ストレージハードウェアのセットアップ ................................................................................................................. 37

A.6. ストレージ構成 .................................................................................................................................................................... 37

A.7. NSS HAクラスタセットアップ ....................................................................................................................................... 38

A.8. HAセットアップのクイックテスト ........................................................................................................................... 47

A.9. 便利なコマンドと参考資料 ............................................................................................................................................ 47

A.10 クライアントのパフォーマンスチューニング ...................................................................................................... 48

A.11. スクリプトと構成ファイルの例 ................................................................................................................................. 48

A.1. インストール前の準備

図 2は NSS HAクラスタを示しています。NSS-HAの機器リストには下記が含まれます。

▪ 2台の PowerEdge R710サーバ

▪ 1個の PowerConnect 5424 Gbイーサネットスイッチ

▪ 2個の切替 APC AP7921電源用 PDU

▪ 1台の PowerVault MD3200

▪ 1台または 3台の PowerVault MD1200

サーバと PDUの間のプライベートネットワーク用 Gbイーサネット IPアドレス。

すべての IPアドレスは同じサブネット上になります。下記はテスト構成に使用された IPアドレスです。

▪ アクティブサーバ NIC1の IPアドレス - 15.15.10.1/24

▪ パッシブサーバ NIC1の IPアドレス - 15.15.10.2/24

▪ アクティブサーバ iDRACの IPアドレス - 15.15.10.201/24

▪ パッシブサーバ iDRACの IPアドレス - 15.15.10.202/24

▪ PDU 1の IPアドレス - 15.15.10.101/24

▪ PDU 2の IPアドレス - 15.15.10.105/24

NFSクライアントと共有されるネットワーク用パブリックネットワーク IPアドレス。

これらの IPはクライアントと同じサブネット上になります。下記はテスト構成に使用された IPアドレスです。

▪ アクティブサーバの 10GbE/IPoIB用 IPアドレス - 10.10.10.201/16

▪ パッシブサーバの 10GbE/IPoIB用 IPアドレス - 10.10.10.202/16

▪ クライアントが NFS をマウントするために使用するフローティングリソースの IP アドレス - 10.10.10.200


Page 33

A.2. サーバ側ハードウェアのセットアップ

1) 2 台の PowerEdge R710 サーバ (「アクティブ」と「パッシブ」) の準備を行います。各サーバを下記の通りに構成します。

▪ 1つの PERC H700と 5つのローカルディスク(それぞれ 146GB)。 ▪ 2個のディスクを RAID 1で構成し、1個のディスクをホットスペアとして指定します。これはオ

ペレーティングシステムに使用されます。2個のディスクを RAID 0で構成します。これはスワップとして使用されます。

▪ 10Gbイーサネットカードまたは InfiniBandカードをスロット4 (PCI-E x8スロット) に装着します。 ▪ SAS 6 Gbpsカードをスロット 3 (PCI-E x8スロット) に装着します。これは MD3200ストレージ

に接続するためのカードです。 ▪ iDRAC Enterprise ▪ デュアル電源

PERC H700ストレージコントローラの参考資料は以下に記載されています。PowerEdge R710サーバは、2個のディスクがすでに RAID 1で構成された状態でデルの工場から出荷される場合があります。追加の 3個のディスクをサーバに挿入します。本文書を使用してそのうちの 1個のディスクを RAID 1

セットアップのホットスペアとして追加し、残りの 2個のディスクを RAID 0で構成します。 http://support.dell.com/support/edocs/storage/Storlink/H700H800/en/UG/PDF/H700H800.pdf

2) 1個の Gbイーサネットスイッチをプライベートネットワーク用にセットアップします。この Gbイーサネットスイッチには、電源用 PDUの 1つから電源を供給します。このスイッチ上には、6個以上のイーサネットポートが必要です。下記のそれぞれに 1個のポートを割り当てます。

▪ 電源用 PDU 1からのイーサネットケーブル ▪ 電源用 PDU2からのイーサネットケーブル ▪ アクティブサーバからの iDRAC Enterprise ▪ パッシブサーバからの iDRAC Enterprise ▪ アクティブサーバからの NIC1 ▪ パッシブサーバからの NIC1

3) 2個の電源用切替 PDUをそれぞれ 3個以上の電源ポートで下記のようにセットアップします。

▪ PDU 1のポート 1はプライベートネットワーク用ギガビットスイッチ。 ▪ PDU 1のポート 2はアクティブサーバの電源 1 ▪ PDU 1のポート 3はパッシブサーバの電源 1 ▪ PDU 2のポート 2はアクティブサーバの電源 2 ▪ PDU 2のポート 3はパッシブサーバの電源 2

4) 電源用 PDUの IPアドレスをプライベートネットワーク上に構成します。各 PDUのイーサネットポートを Gbイーサネットプライベートスイッチに接続します。

5) 各 R710サーバにオンボード NIC1をケーブル接続し、iDRAC Enterpriseポートを Gbイーサネットプライベートスイッチにケーブル接続します。

6) 各 R710サーバに、そのサーバに使用する 2つの電源ケーブルをプラグインし、2個の電源用切替 PDUにそれぞれ接続します。

7) 各 R710サーバに、プライベートネットワーク上での iDRAC Enterpriseの IP アドレスを設定します。

8) IB または 10GbE ネットワークを「パブリック」ネットワークに接続します。これは NFS クライアントが接続されるネットワークです。


Page 34

A.3. 各 PowerEdge R710サーバの初期ソフトウェア構成 1) RHEL5.5 x86_64オペレーティングシステムを RAID 1仮想ディスクにインストールします。

▪ OSインストール中のサーバに MDストレージが取り付けられていないことを確認してください。

2) OSをインストールした後に、RAID 0デバイス上にスワップをセットアップします。

▪ PERC H700に関連付けされたデバイスは、Multipath -llによって示されます。たとえば/dev/mapper/mpath1

▪ # mkswap -L SWAP /dev/mapper/mpath1 ▪ # swapon -p 10 /dev/mapper/mpath1 ▪ /etc/fstabを編集し、このスワップデバイスのエントリを追加します。

"LABEL=SWAP swap swap pri=10 0 0" このエントリが、OSインストールによって作成されたデフォルトスワップスペース (もしあれば) の前にリストアップされていることを確認してください。

▪ サーバを起動したときにスワップが自動的に有効になることをテストします。 # swapoff -a # swapon -s # swapon -a # swapon -s

3) RHEL 5.5 DVDをサーバにコピーし、yumリポジトリを作成します。各サーバ上で次のコマンドを実行します。 ▪ # cp -r /media/RHEL5.5 /root/

# rpm -ivh /root/RHEL5.5/Server/createrepo-0.4.11-3.el5.noarch.rpm # cd /root/RHEL5.5/Server; createrepo . # cd /root/RHEL5.5/VT; createrepo . # cd /root/RHEL5.5/Cluster; createrepo . # cd /root/RHEL5.5/ClusterStorage; createrepo .

▪ 各リポジトリに、下記の例と同様のファイルを作成します。 /etc/yum.repos.d/Server.repo /etc/yum.repos.d/Cluster.repo /etc/yum.repos.d/ClusterStorage.repo /etc/yum.repos.d/VT.repo

.repoファイルの例： [root@active]# cat /etc/yum.repos.d/Server.repo [Server] name=Server baseurl=file:///root/RHEL5.5/Server enabled=1 gpgcheck=0

▪ リポジトリをチェックします。

[root@passive]# yum repolist Loaded plugins: rhnplugin, security This system is not registered with RHN. RHN support will be disabled. repo id repo name status VT VT enabled: 71 Cluster Cluster enabled: 32 Clusterstorage ClusterStorage enabled: 39


Page 35

Server Server enabled: 3,116 repolist: 3,258

4) Red Hat Network (http://rhn/redhat.com) から XFSパッケージを入手し、インストールします。 xfsdump-2.2.48-3.el5.x86_64.rpm xfsprogs-devel-2.10.2-7.el5.x86_64.rpm xfsprogs-2.10.2-7.el5.x86_64.rpm

5) Dell OpenManage Server Administratorをインストールします。(OM-SrvAdmin-Dell-Web-LX-6.4.0-1266.RHEL5.x86_64_A00.21.tar.gz) 「missing dependencies」と表示されてセットアップが失敗した場合は、欠けている rpmを下記からインストールします。

<dir_where_OM_extracted>/linux/RPMS/supportRPMS/opensource- components/RHEL5/x86_64 libcmpiCppImpl0-2.0.0Dell-1.3.el5.x86_64.rpm sblim-sfcc-2.2.1-1.4.1.el5.x86_64.rpm sblim-sfcb-1.3.7-1.4.2.el5.x86_64.rpm openwsman-server-2.2.3.9-1.5.3.el5.x86_64.rpm

6) MD3200管理ソフトウェア (MGFM4A04_md3200_1_2_0_12.iso) をインストールします。

http://support.dell.com/support/downloads/driverslist.aspx?c=us&l=en&s=gen&ServiceTag=&SystemID=PWV_MD3200&os=RHEL5&osl=EN

7) InfiniBandを使用する場合は、Mellanox OFED 1.5.1 (MLNX_OFED_LINUX-1.5.1-rhel5.5.iso) をインストールします。

8) 両方のクラスタサーバの IPポートを有効にします。有効にするポートのリストは、『Red Hat Cluster

Administration Guide』に記載されています。

http://docs.redhat.com/docs/en- US/Red_Hat_Enterprise_Linux/5/pdf/Cluster_Administration/Red_Hat_Enterprise_Linux-5- Cluster_Administration-en-US.pdf Section 2.3 ファイアウォール構成ツール (system-config-securitylevel) を起動し、[Other ports] をクリックしてから、TCPと UDPのポート番号を追加します。

あるいは、ファイアウォールを無効にします。この選択肢を実行する前に、パブリックインタフェースとプライベートインタフェースが安全なネットワークに接続されていることを確認し、ファイアウォールを無効にした場合のセキュリティへの影響に注意してください。 # service iptables stop; chkconfig iptables off

9) chkconfig ipmi on

10) chkconfig nfs on

11) chkconfig multipathd on

12) 両方のサーバのエントリを記載するために、両方のサーバで/etc/hostsをアップデートします。

[root@passive ~]# cat /etc/hosts # Do not remove the following line, or various programs


Page 36

# that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 15.15.10.1 active.hpc.com active 15.15.10.2 passive.hpc.com passive

13) アクティブサーバとパッシブサーバの間でパスワードを使用しない sshをセットアップします。

active> ssh-keygen -t rsa

active> ssh-copy-id -i ~/.ssh/id_rsa.pub passive

passive> ssh-keygen -t rsa

passive> ssh-copy-id -i ~/.ssh/id_rsa.pub active

14) パブリックネットワークの IPoIB ib0アドレスまたは 10GbEアドレスを構成します。

15 サーバからストレージへのすべての SASリンクが失敗したときに、クラスタサービスのフェイルオーバに影響する可能性のある問題に対処するには、アクティブサーバとパッシブサーバの両方で 2つのrpmをアップデートする必要があります。それらの rpmは、Red Hat Networkから入手可能です。

device-mapper-multipath-0.4.7-42.el5_6.2.x86_64.rpm kpartx-0.4.7-42.el5_6.2.x86_64.rpm

アクティブサーバとパッシブサーバの両方をアップデートします。 # rpm -Uvh kpartx-0.4.7-42.el5_6.2.x86_64.rpm device-mapper-multipath-

0.4.7-42.el5_6.2.x86_64.rpm

参考資料：

http://rhn.redhat.com/errata/RHBA-2011-0379.html https://bugzilla.redhat.com/show_bug.cgi?id=677821 https://bugzilla.redhat.com/show_bug.cgi?id=683447

A.4. サーバのパフォーマンスチューニング

1) クライアントが 10GbE 経由で NFS サーバにアクセスする場合は、アクティブサーバとパッシブサーバの両方で 10GbEデバイス上のMTUが 8192になるよう構成します。大きい MTUをサポートする場合にも、スイッチを構成する必要があることに注意してください。

サーバ上でMTUの値が/etc/sysconfig/network-scripts/ifcfg-ethXにおいて指定されていない場合は、 echo "MTU=8192" >> /etc/sysconfig/network-scripts/ifcfg-ethX、

さもなければ、/etc/sysconfig/network-scripts/ifcfg-ethXにおいて古い値を 8192に変更します。

この ifcfg-ethXは、10GbEネットワークインタフェースです。

ネットワーキングサービスを再起動します。 service network restart

2) アクティブサーバとパッシブサーバの両方で、NFSスレッドの数をデフォルトの 8から 256に変更します。


Page 37

/etc/sysconfig/nfsのバックアップを作成し、スレッドの数を変更します。

# cp /etc/sysconfig/nfs{,.orig}, # sed -i 's/#RPCNFSDCOUNT=8/RPCNFSDCOUNT=256/' /etc/sysconfig/nfs

NFSサービスを再起動します。 service nfs restart

参考資料 - http://i.dell.com/sites/content/business/solutions/whitepapers/en/Documents/hpc- pv-md1200-nfs.pdf

3) アクティブサーバとパッシブサーバの両方で、OS I/O スケジューラを「deadline」に変更します。

/etc/grub.confにおいて、カーネル行の最後に elevator=deadlineを追加します。

これが有効になるよう、サーバを再起動します。

A.5. ストレージハードウェアのセットアップ 1) 図 3に示したように、MD3200をサーバの SAS 6 Gbpsカードにケーブル接続します。

▪ OSインストール前にストレージを R710サーバにケーブル接続しないでください。

参考資料: http://support.dell.com/support/edocs/systems/md3200/en/DG/PDF/DG.pdfのセクション「Dual Controller Configurations」

2) MD1200をMD3200にケーブル接続します。

参考資料: http://support.dell.com/support/edocs/systems/md3200/en/index.htm

A.6. ストレージ構成 1) 1台の R710サーバ上でMDSM管理 GUIを起動します。取り付けたストレージアレイをインバンド管

理経由で検出し、そのストレージアレイを管理 GUIに追加します。

2) 1つのホストグループを作成し、そのグループにアクティブサーバとパッシブサーバを追加します。

3) MDSMの GUIを使用して、ストレージ上に LUNを作成します。

▪ 各ストレージアレイに、1個のディスクグループと、12個のディスクすべてを 10+2 RAID 6で格納する 1個の仮想ディスク(セグメントサイズ 512k)で作成します。NSS-HA中規模構成の場合、これは合計 2つの LUNです。NSS-HA大規模構成の場合、これは合計 4つの LUNです。

▪ 各仮想ディスクの読み込みキャッシュ、書き込みキャッシュ、書き込みキャッシュミラーリング、ダイナミックキャッシュ読み込みプリフェッチを有効にします。

▪ MD3200のハイパフォーマンスティアを有効にします。 ▪ キャッシュのブロックサイズを 32k にセットします。

ストレージアレイを構成する方法に関する指示については、下記の参考資料を使用してください。 http://support.dell.com/support/edocs/systems/md3200/en/OM/PDF/MD3200.pdf

4) すべての仮想ディスクを、アクティブサーバとパッシブサーバが格納されているこのホストグループにマッピングします。

参考資料：http://support.dell.com/support/edocs/systems/md3200/en/index.htm

5) 各 R710サーバ上で、コマンド rescan_dm_devsを実行します。

http://support.dell.com/support/edocs/systems/md3200/en/index.htm


Page 38

6) 各 R710サーバ上で、cat /proc/partitionsとmultipath -llを実行するとストレージ上のすべての LUN

が表示されます。

参考資料：http://support.dell.com/support/edocs/systems/md3200/en/OM/HTML/config_n.htm

A.7. NSS HAクラスタセットアップ本レシピにおいて「クラスタ」はアクティブ-パッシブ NSS-HA Red Hatクラスタを指します。

1) 2台の R710サーバにクラスタソフトウェアパッケージをインストールします。

# yum install -y ricci rgmanager cman openais # service ricci start; chkconfig ricci on

2) そのうちの 1台の R710サーバ (「アクティブ」サーバ) にクラスタ管理 GUIをインストールします。 # yum install luci # luci_admin init # service luci restart

3) HA LVMをセットアップします。HA LVMは、一度に 1台のサーバだけが LVMにアクセスするようにします。

アクティブ R710サーバで下記を行います。 ▪ /etc/lvm/lvm.confを編集し、locking_typeが 1になるよう編集します。 ▪ multipath -llアウトプットからのmpathデバイス名を使用して、LVMを作成します。

NSS-HA中規模構成の場合

# pvcreate /dev/mapper/mpath2 /dev/mapper/mpath3; # vgcreate DATA_VG /dev/mapper/mpath2 /dev/mapper/mpath3 # lvcreate -i 2 -I 1024 -l 100%FREE DATA_VG -n DATA_LV NSS-HA大規模構成の場合

# pvcreate /dev/mapper/mpath2 /dev/mapper/mpath3 /dev/mapper/mpath4 /dev/mapper/mpath5 # vgcreate DATA_VG /dev/mapper/mpath2 /dev/mapper/mpath3 /dev/mapper/mpath4 /dev/mapper/mpath5 # lvcreate -i 4 -I 1024 -l 100%FREE DATA_VG -n DATA_LV

▪ lvdisplay を実行すると DATA_LVが表示されます。

▪ /etc/lvm/lvm.confを編集し、ボリュームリストを以下に変更します。 volume_list = [ "VolGroup00" , "@active" ] VolGroup00は OS用の "/" ファイルシステムを含むボリュームグループです。「active」はクラスタ構成に使用するよう cluster.confファイルにおいて定義したサーバの名前です。

▪ initrdを作り直します。 # mkinitrd -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5


Page 39

他方の (パッシブ) サーバに HA LVMをセットアップします。

▪ lvdisplayを実行すると DATA_LVが表示されます。

▪ /etc/lvm/lvm.confを編集し、locking_typeが 1になるよう編集します。

▪ /etc/lvm/lvm.confを編集し、ボリュームリストを以下に変更します。 volume_list = ["VolGroup00" , "@passive" ] VolGroup00は、OS用の "/" ファイルシステムを含むボリュームグループです。

「パッシブ」はクラスタ構成に使用するよう cluster.confファイルにおいて定義したサーバの名前です。

▪ initrdを作り直します。 # mkinitrd -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5

参考資料 - http://kbase.redhat.com/faq/docs/DOC-3068

4) アクティブサーバ上に、XFSファイルシステムを作成します。 # mkfs.xfs -l size=128m /dev/DATA_VG/DATA_LV

5) 両方のサーバ上に、XFS ファイルシステムのマウントポイントを作成します。これは XFS ファイルシステムがマウントされるディレクトリであり、NFS経由でクライアントにエクスポートされます。 # mkdir /mnt/xfs_data

6) クラスタを構成します。図 18のスクリーンショットを参照してください。

▪ 「アクティブ」R710サーバ上で以下を行います。 ▪ luci web GUIを起動します (https://active:8084)。 ▪ [cluster] タブに移動し、[Create a New Cluster] をクリックします。 ▪ クラスタ名 (たとえば「NSS_HA_CLUSTER」) を入力します。 ▪ ノードホスト名「アクティブ」と「パッシブ」を入力します。パスワードを入力します。 ▪ [Use locally installed packages] を選択します。 ▪ [Enable Shared Storage Support] にチェックマークを入れます。 ▪ ノードのパスワードが同じである場合は [Check if node passwords are identical] にチェックマー

クを入れます。 ▪ [View SSL cert fingerprints] をクリックします。 ▪ [Submit] をクリックします。


Page 40

図 18 - 新規クラスタの作成

7) 両方のサーバ上で、cmanサービスが実行されていることを確認します。 # service cman status

8) 両方のサーバ上で、クラスタのステータスを確認します。 # clustat

クラスタステータスに両方のサーバがオンラインとして表示されます。クラスタが立ち上がって時稼働している場合は、次のステップに進みます。

[root@active ~]# clustat Cluster Status for NSS_HA_CLUSTER @ Wed Mar 2 17:36:36 2011 Member Status: Quorate

Member Name ID Status ------ ---- ---- ------ active 1 Online, Local passive 2 Online

9) クラスタパッケージをインストールした結果変更された可能性のあるすべてのHA LVM構成をリセットします。

▪ 両方のサーバ上で/etc/lvm/lvm.confを編集し、locking_typeを 1にセットします。

▪ initrdを作り直します。

# mkinitrd -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5


Page 41

10) InfiniBandクラスタの場合は、セクション A.11に記載されている ibstat-script.shファイルを両方のサーバの/root/ibstat-script.shにコピーします。このスクリプトは、ibstatコマンドを使って InfiniBand

リンクのステータスをチェックします。これは、InfiniBand リンクを確実に監視するためのクラスタサービスのリソースとして含まれます。(10Gbイーサネットクラスタの場合は、RHCSが 10GbEリンクを監視し、スクリプトを追加する必要はありません)。

11) セクション A.11に記載されている sas_path_check_script.shファイルを

両方のサーバの/root/sas_path_check_script.sh にコピーします。このスクリプトは、共有ストレージ上の 1 個のデバイスのステータスをチェックします。所定の時間内にこのデバイスにアクセスできない場合、サーバは再起動し、クラスタサービスを他方のサーバにフェイルオーバするかどうかを確認する質問が画面に表示されます。パスに障害が発生したためにクラスタサービスが正常に終了しない場合は、再起動されます。

チェック対象デバイス (/dev/mapper/mpath2) とタイムアウトまでの時間 (300秒) はチューニング可能です。スクリプト/dev/mapper/mpath2 に含まれるデバイスが、共有MD3200ストレージ上の 1

つの LUNを指示していることを確認します。これは、multipath -llコマンドの出力を見ることによって確認できます。

12) 両方のサーバ上でパブリックインタフェースが起動していることを確認します。これは 10GbEリンクまたは InfiniBandリンクのいずれかになります。

13) アクティブサーバ上だけで、/etc/cluster/cluster.confを修正します。

▪ セクション A.11 に記載されている cluster.conf ファイルの例を使用して、アクティブサーバ上の/etc/cluster/cluster.conf ファイルをアップデートします。フェンスデバイス、リソース、サービスなどのセクションを追加します。

▪ 一意のハードウェアおよびソフトウェア構成に対応するよう/etc/cluster/cluster.confファイルを編集するのを忘れないでください。これは重要な手順です。この手順は、NSS-HA クラスタのリソースとクラスタサービスを定義します。cluster.confファイルが不正確または不完全である場合、作成されるクラスタは機能しません。下記の環境固有パラメータに注意してください。下記の指示には、xml ファイルの関連する部分を特定しやすいよう、xmlスニペットが含まれています。

a) クラスタ名 xmlファイルの 2カ所でこの変更を行います。

<cluster alias="NSS_HA_CLUSTER" config_version="2" name="NSS_HA_CLUSTER">

b) 両方の R710サーバ (アクティブとパッシブ) のホスト名を正しい名前に訂正します。各ホストの xmlファイルの 2カ所でこの変更を行います。

<clusternode name="active" nodeid="1" votes="1"> <clusternode name="passive" nodeid="2" votes="1"> <failoverdomainnode name="active" priority="1"/ <failoverdomainnode name="passive" priority="2"/>

c) 両方のサーバの DRAC IPアドレス


Page 42

各ホストの xmlファイルの 3カ所でこの変更を行います。

<fence> <method name="1">

<device name="15.15.10.201"/>

<fencedevice agent="fence_drac5" cmd_prompt="admin1->" ipaddr="15.15.10.201" login="root" name="15.15.10.201" passwd="calvin" secure="1"/>

<fence>

<method name="1"> <device name="15.15.10.202"/>

<fencedevice agent="fence_drac5" cmd_prompt="admin1->" ipaddr="15.15.10.202" login="root" name="15.15.10.202" passwd="calvin" secure="1"/>

d) 両方のサーバの DRACユーザ名とパスワード各ホストの xmlファイルの 1カ所でこの変更を行います。

<fencedevice agent="fence_drac5" cmd_prompt="admin1->" ipaddr="15.15.10.201" login="root" name="15.15.10.201" passwd="calvin" secure="1"/> <fencedevice agent="fence_drac5" cmd_prompt="admin1->" ipaddr="15.15.10.202" login="root" name="15.15.10.202" passwd="calvin" secure="1"/>

e) 両方の PDUの PDU IPアドレス各ホストの xmlファイルの 6カ所でこの変更を行います。

<method name="2"> <device name="15.15.10.101" option="off" port="2"/> <device name="15.15.10.105" option="off" port="2"/> <device name="15.15.10.101" option="on" port="2"/> <device name="15.15.10.105" option="on" port="2"/>

</method> <method name="2"> <device name="15.15.10.101" option="off" port="3"/> <device name="15.15.10.105" option="off" port="3"/> <device name="15.15.10.101" option="on" port="3"/> <device name="15.15.10.105" option="on" port="3"/>

</method> <fencedevice agent="fence_apc" ipaddr="15.15.10.101" login="apc" name="15.15.10.101" passwd="apc"/> <fencedevice agent="fence_apc" ipaddr="15.15.10.105" login="apc" name="15.15.10.105" passwd="apc"/>

f) 両方の PDUの PDUログインユーザ名とパスワード

各 PDUの xmlファイルの 1カ所でこの変更を行います。

<fencedevice agent="fence_apc" ipaddr="15.15.10.101" login="apc" name="15.15.10.101" passwd="apc"/> <fencedevice agent="fence_apc" ipaddr="15.15.10.105"


Page 43

login="apc" name="15.15.10.105" passwd="apc"/>

g) 4つの電源すべての PDUポート 4つの PDUポートのそれぞれの xmlファイルの 2カ所でこの変更を行います。

<method name="2"> <device name="15.15.10.101" option="off" port="2"/>

<device name="15.15.10.105" option="off" port="2"/> <device name="15.15.10.101" option="on" port="2"/> <device name="15.15.10.105" option="on" port="2"/>

</method> <method name="2">

<device name="15.15.10.101" option="off" port="3"/> <device name="15.15.10.105" option="off" port="3"/> <device name="15.15.10.101" option="on" port="3"/> <device name="15.15.10.105" option="on" port="3"/>

</method>

h) VG名と LV名 VGと LVの xmlファイルの 2カ所でこの変更を行います。

<lvm lv_name="DATA_LV" name="HA_LVM" self_fence="1" vg_name="DATA_VG"/> <fs device="/dev/DATA_VG/DATA_LV" force_fsck="0" force_unmount="1" fstype="xfs" mountpoint="/mnt/xfs_data" name="XFS" options="noatime,allocsize=1g,nobarrier,inode64,logbsize=26214 4,wsync" self_fence="0"/>

i) XFSマウントポイント xmlファイルの 1カ所でこの変更を行います。

<fs device="/dev/DATA_VG/DATA_LV" force_fsck="0" force_unmount="1" fstype="xfs" mountpoint="/mnt/xfs_data" name="XFS" options="noatime,allocsize=1g,nobarrier,inode64,logbsize=26214 4,wsync" self_fence="0"/>

j) パブリックネットワークのサービス IP (クライアントがNFSをマウントするために使用するフローティング IP)

xmlファイルの 2カ所でこの変更を行います。 <ip address="10.10.10.200" … <ip ref="10.10.10.200"/>


Page 44

k) NFSエクスポートオプション xmlファイルの 1カ所でこの変更を行います。「sync」は NSS-HAの必須オプションです。 <nfsclient allow_recover="1" name="NFS_client" options="fsid=55,rw,sync,no_root_squash" target="*"/>

l) InfiniBandクラスタの場合は、ibstat_scriptファイルのロケーション。このロケーションは両方のサーバ上で同じでなければなりません。xmlファイルの 1カ所でこの変更を行います。 <script file="/root/ibstat_script.sh" name="ibstat_script"/>

m) sas_path_check_script ファイルのロケーション。このロケーションは両方のサーバ上で同じでなければなりません。xmlファイルの 1カ所でこの変更を行います。 <script file="/root/sas_path_check_script.sh" name=" sas_path_check_script "/>

▪ config_versionを 1つ増やします。これは/etc/cluster/cluster.confのライン 2にあります。

▪ 以下の次のコマンドは、アクティブサーバとパッシブサーバの間でクラスタ構成ファイルを同期します。クラスタサービス (HA LVMのアクティブ化、XFSファイルシステムのマウント、NFS経由での XFS システムのエクスポート、フローティングリソース IP の作成を含む) も、このコマンドで開始します。アクティブサーバ上で下記のコマンドを実行します。 # ccs_tool update /etc/cluster/cluster.conf

14) クラスタサービスが実行されていることを確認します。

▪ クラスタのステータスは、両方のサーバがオンラインであることを示します。クラスタが稼働している場合は、次のステップに進みます。 [root@active ~]# clustat Cluster Status for NSS_HA_CLUSTER @ Thu Mar 3 10:41:48 2011 Member Status: Quorate

Member Name ID Status ------ ---- ---- ------ active 1 Online, rgmanager passive 2 Online, Local, rgmanager Service Name Owner (Last) State ------- ---- ----- ------ -----

service:HA_service アクティブ started

▪ サービスを実行しているサーバ上で、XFS ファイルシステムがマウントされていることを確認します。

[root@active ~]# mount | grep xfs /dev/mapper/DATA_VG-DATA_VG_LV on /mnt/xfs_data type xfs (rw,noatime,allocsize=1g,nobarrier,inode64,logbsize=262144,wsync)


Page 45

▪ サービスを実行しているサーバ上で、リソース IPが割り当てられていることを確認します。パブリックネットワークへのインタフェースには、2 つの IP アドレス (静的に割り当てられたアドレスとフローティングサービス IPアドレス) があります。 [root@active ~]# ip addr show ib0 9: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65520 qdisc pfifo_fast qlen 256 link/infiniband 80:00:00:48:fe:80:00:00:00:00:00:00:00:02:c9:03:00:07:7f:a7 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff inet 10.10.10.201/24 brd 10.10.10.255 scope global ib0 inet 10.10.10.200/24 scope global secondary ib0 inet6 fe80::202:c903:7:7fa7/64 scope link valid_lft forever preferred_lft forever

15) Selinuxポリシーをアップデートします。クラスタサーバが他方のクラスタメンバーをフェンスし、クラスタサービスの所有権を得ることができるようにするためには、このポリシーが必要です。セクション A.11に記載されている SELinuxポリシーの Type Enforcementファイル (.te) を使用して、ポリシーモジュールを構築します。そのポリシーモジュールを、両方のサーバにインストールします。

# checkmodule -M -m NSSHApolicy.te -o NSSHApolicy.mod # semodule_package -o NSSHApolicy.pp -m NSSHApolicy.mod # semodule -i NSSHApolicy.pp

あるいは、SELinuxポリシーは拒否された操作のログから作成することができます。拒否された操作は、/var/log/audit/audit.logで確認します。該当するクラスタに関連するものがない場合は、『HAセットアップのクイックテスト』セクションの記述に従ってフェンシングをテストし、次に下記の手順に従います。 # grep avc /var/log/audit/audit.log | audit2allow -M NSSHApolicy

作成したポリシーモジュールを、botサーバにインストールします。 # semodule -i NSSHApolicy.pp

参考資料 https://bugzilla.redhat.com/show_bug.cgi?id=588902

16) 両方のサーバで、CLVMを無効にします。 # chkconfig clvmd off; service clvmd stop

17) 両方のサーバで、GFSを無効にします。 # chkconfig gfs off; service gfs stop; # chkconfig gfs2 off; service gfs2 stop

18) luci web GUI (https://active:8084) を起動して、最新のクラスタ構成を確認します。その一例を図 19に示します。

注意： cluster.confファイルの例では、複数の既知の問題に対処しています。web GUI経由で変更を保存する場合は、それらの修正に注意し、保存する内容にそれらが含まれていることを確認してください。

a) luci web GUIを使用して変更を保存する場合は、1台のサーバ上で cluster.confファイルを手作業で編集します。 - ファイルシステムタイプ fstypeを「xfs」に変更します。

<fs device="/dev/DATA_VG/DATA_LV" force_fsck="0" force_unmount="1" fstype="xfs" mountpoint="/mnt/xfs_data" name="XFS" options="noatime,allocsize=1g,nobarrier,inode64,logbsize=262144,wsyn c" self_fence="0"/>


Page 46

参考資料 https://bugzilla.redhat.com/show_bug.cgi?id=636554

- iDRAC 用フェンスデバイスに cmd_prompt パラメータが組み込まれていることと、両方のiDRACデバイスのセキュアパラメータが 1にセットされていることを確認します。

<fencedevice agent="fence_drac5" cmd_prompt="admin1->" ipaddr="15.15.10.201" login="root" name="15.15.10.201" passwd="calvin" secure="1"/> 参考資料 https://bugzilla.redhat.com/show_bug.cgi?id=577913 https://bugzilla.redhat.com/show_bug.cgi?id=496749 http://linux.dell.com/wiki/index.php/Products/HA/DellRedHatHALinuxCluster/Cluster#Configure_iDRAC6_Fencing

b) バージョン番号を 1つ増やし、変更を全ノードに拡大適用します。 ccs_tool update /etc/cluster/cluster.conf

あるいは、それらの修正が組み込まれたバージョンとして、luci rpmのアップデートされたバージョンを使用することもできます。

luci rpmのバージョン： luci-0.12.2-24.el5_6.1.x86_64.rpm

参考資料: http://rhn.redhat.com/errata/RHBA-2011-0033.html

図 19 - クラスタリソース

https://bugzilla.redhat.com/show_bug.cgi?id=636554

http://rhn.redhat.com/errata/RHBA-2011-0033.html


Page 47

A.8. HAセットアップのクイックテスト 1) フェンシングをテストします。

▪ 最初に、クラスタサービスを無効にします。 [root@active ~]# clusvcadm -d HA_service

▪ アクティブサーバからコマンド fence_node passiveを実行します。これにより、DRAC経由でパッシブサーバの電源が一度オフになってから再びオンになります。アクティブサーバの/var/log/messagesを確認します。

▪ パッシブサーバからコマンド fence_node activeを実行します。これにより、DRAC経由でアクティブサーバの電源が一度オフになってから再びオンになります。パッシブサーバの/var/log/messagesを確認します。

▪ パッシブサーバの DRAC ケーブルの接続を解除します。「アクティブ」サーバからコマンドfence_node passiveを実行します。これにより、切替 PDU経由でパッシブサーバの電源が一度オフになってから再びオンになります。

▪ アクティブサーバの DRAC ケーブルの接続を解除します。パッシブサーバからコマンドfence_node activeを実行します。これにより、切替 PDU経由で「アクティブ」サーバの電源が一度オフになってから再びオンになります。

2) 簡単な HAフェイルオーバテスト：

▪ 「アクティブ」サーバ上でサービスを起動します。 [root@active ~]# clusvcadm -e HA_service -m active

▪ 電源ボタンを押しながら電源コードを両方とも引き抜き、アクティブサーバの電源をオフにします。

▪ サービスはパッシブサーバに移行します。/var/log/messages を見て、パッシブサーバの clustatのステータスを確認します。

A.9. 便利なコマンドと参考資料

1) clustat

2) cman_tool status

3) /etc/cluster/cluster.conf ファイルを手作業で編集する場合は、1 台のサーバ上でのみ変更を行い、バージョン番号フィールドに 1 つ多い数を入力します。下記のコマンドに従って、変更を両方のサーバに拡大適用します。 cs_tool update /etc/cluster/cluster.conf

4) service cman status

5) service rgmanager status

6) clusvcadmは、クラスタサービスを手作業で停止、開始、無効化、移動するために使用します。

7) group_tool

8) rg_testはデバッグツールです。注意して使用してください。このツールを使用する前に、クラスタサービスが停止し無効化されていることを確認してください。

▪ clusvcadm -s HA_service ▪ clusvcadm -d HA_service ▪ rg_test test /etc/cluster/cluster.conf start service HA_service

- mountは、マウントされているファイルシステムを表示します。 - ip addr listは、構成したフローティングリソース IPを表示します。


Page 48

- クライアントはファイルシステムにアクセス可能になります。したがって、rg_test は注意して使用し、デバッグだけに使います。clustat と clusvcadm は、正常稼働中にクラスタとクラスタサービスを管理します。

▪ rg_test test /etc/cluster/cluster.conf status service HA_service ▪ rg_test test /etc/cluster/cluster.conf stop service HA_service ▪ clusvcadm -e HA_service

9) アクティブサーバまたはパッシブサーバを起動または再起動する場合は、最初にクラスタを正常に終了させます。さもなければ、他方のサーバはそのサーバが機能を喪失したと考え、フェンシングします。クラスタを正常に終了させるには、下記の順序でコマンドを実行します。

▪ fence_tool leave ▪ service rgmanager stop ▪ cman_tool leave remove ▪ service cman stop

10) Red Hat Cluster Suiteに関する優れた FAQ：http://sources.redhat.com/cluster/wiki/FAQ

A.10. クライアントのパフォーマンスチューニング

1) クライアントが 10GbE 経由で NFS サーバにアクセスする場合は、すべてのクライアントについて10GbEデバイスのMTUが 8192になるよう構成します。大きいMTUをサポートするためには、スイッチも構成する必要があることに注意してください。

クライアントのMTUの値が/etc/sysconfig/network-scripts/ifcfg-ethXで指定されていない場合は、

echo "MTU=8192" >> /etc/sysconfig/network-scripts/ifcfg-ethX

さもなければ、/etc/sysconfig/network-scripts/ifcfg-ethXで古い値を 8192に変更します。10GbEネットワークインタフェースの場合は ifcfg-ethXです。

ネットワーキングサービスを再起動します。service network restart

2) 各クライアントについて、下記を /etc/sysctl.confに追加します。

# increasing the default TCP receive memory size net.ipv4.tcp_rmem = 4096 2621440 16777216

nges with sysctl -pで変更を有効化します。

A.11. スクリプトと構成ファイルの例

1) /etc/cluster/cluster.conf InfiniBandクラスタ用のファイル

2) /etc/cluster/cluster.conf 10Gbイーサネットクラスタ用のファイル

3) /root/ibstat_script.sh InfiniBandクラスタ用のファイル

4) /root/sas_path_check_script.sh

5) NSSHApolicy.te SELinuxポリシーType Enforcement ファイル


Page 49

付録 B：中規模構成から大規模構成へのアップグレード中規模構成は 1台の PowerVault MD3200と 1台の PowerVault MD1200から構成され、キャパシティは約 40TBです。大規模構成は、1台の PowerVault MD3200と 3台の PowerVault MD1200から構成され、キャパシティは約 80TBです。

中規模構成から大規模構成にアップグレードするには、追加する 2台の PowerVault MD1200の構成が最初のセットアップと同一でなければなりません。追加する 2台の PowerVault MD1200は、ストレージにケーブル接続します。

当初の中規模構成のためのストレージ構成と同様に、新たに追加する 2台の PowerVault MD1200は、それぞれセグメントサイズを 512kとし、RAID 6で 10+2仮想ディスクとなるよう構成します。この仮想ディスクをホストグループに追加し、アクティブサーバとパッシブサーバの両方が２つの新しい LUNにアクセスできるようにします。

XFSファイルシステムを中規模構成から大規模構成に拡張するには、2つの方法があります。

オプション 1：現在のファイルシステムはそのままとし、キャパシティを 40TB追加することによって中規模構成を拡張します。この場合は、

▪ 最初の 40TBのデータは 1台の PowerVault MD3200と 1台の PowerVault MD1200による当初の中規模構成に保存されます。データは PowerVault MD3200と 1台めの PowerVault MD1200にまたがって配置されます。

▪ データの次の 40TBは、追加された 2台の PowerVault MD1200にまたがって配置されます。

▪ システムの合計キャパシティは大規模構成と同じ 80TBです。

▪ ストレージのパフォーマンスは中規模構成と同じです。

▪ ファイルシステムとユーザデータは、アップグレードの影響を受けません。ただし、アップグレードを行う前にユーザデータをバックアップすることをおすすめします。

オプション 2：第 2のオプションは、ストレージに大規模構成を作成します。この場合は、

▪ ユーザデータは外部にバックアップしなければなりません。これは要件です。データは保存されません。

▪ ボリュームグループ、論理ボリューム、ファイルシステムは 4台の PowerVault MDストレージエンクロージャをすべて使用して再現されます。80TB のデータすべてが、4 台の PowerVault MDアレイにまたがって配置されます。

▪ システムの合計キャパシティは 80TBです。

▪ システムのパフォーマンスは、大規模構成と同様です。

▪ アップグレードを行った後に、ユーザデータを復元しなければなりません。

実装オプション 1 - 中規模構成の拡張

下記の手順は、現在クラスタサービスを実行しているサーバ上で実施しなければなりません。

1) ユーザデータをバックアップします。

2) 2つの新しい LUNに新しい物理ボリュームを作成します。 pvcreate /dev/mapper/mpath4 /dev/mapper/mpath5

3) 既存のボリュームグループを拡張し、新たに作成した物理ボリュームを組み込みます。 vgextend DATA_VG /dev/mapper/mpath4 /dev/mapper/mpath

4 既存の論理ボリュームを拡張し、新たに作成した物理ボリュームを組み込みます。

lvextend /dev/DATA_VG/DATA_LV /dev/mapper/mpath4 /dev/mapper/mpath5 -I 1024 -i 2


Page 50

5) ファイルシステムを拡張して、論理ボリュームに追加スペースを組み込みます。 xfs_growfs -d /mnt/xfs_data

6) 新しいファイルシステムのサイズを確認します。df -hは、ファイルシステムの合計サイズが約 80TB (以前の 2倍) になっていることを示します。

7) ユーザデータに影響がなかったことを確認します。必要に応じて復元します。

実装オプション 2 - 大規模構成の作成。

1) ユーザデータをバックアップします。これは要件です。データは保存されません。

2) クラスタサービスを停止し、無効にします。クラスタを停止します。クラスタサービスを実行しているサーバ上で：

clusvcadm -s HA_service clusvcadm -d HA_service fence_tool leave service rgmanager stop cman_tool leave remove service cman stop

他方のサーバで：

fence_tool leave service rgmanager stop cman_tool leave remove service cman stop

3) 両方のサーバで/etc/lvm/lvm.confを編集し、HA_LVMを削除します。volume_list lineをコメントアウトします。

4) 両方のサーバで、initrdを作り直します。

mkinitrd -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5

5) 1台のサーバ上で、古い論理ボリュームを削除します。

lvchange -a y /dev/DATA_VG/DATA_LV lvremove /dev/DATA_VG/DATA_LV

6) 1台のサーバ上で、古いボリュームグループを削除します。

vgremove DATA_VG

下記の手順は、NSS HA構成レシピと同様です。

7) アクティブサーバ上で、2つの新しい LUN上に新しい物理ボリュームを作成します。 pvcreate /dev/mapper/mpath4 /dev/mapper/mpath5


Page 51

8) アクティブサーバ上で 4つの LUNすべてにまたがって 1つのボリュームグループを作成します。以前と同じ VG名を使用しなければなりません。さもなければ、/etc/cluster/cluster.confファイルの編集が必要になります。

vgcreate DATA_VG /dev/mapper/mpath2 /dev/mapper/mpath3 /dev/mapper/mpath4 /dev/mapper/mpath5

9) このボリュームグループを使用して、アクティブサーバ上に 1つの論理ボリュームを作ります。 lvcreate -i 4 -I 1024 -l 100%FREE DATA_VG -n DATA_LV

10) HA LVMをセットアップします。 ▪ アクティブサーバ上で/etc/lvm/lvm.conf を編集し、以下になるようボリュームリストを変更しま

す。 volume_list = [ "VolGroup00" , "@active" ] VolGroup00は、OS用"/"ファイルシステムを含むボリュームグループです。「active」は cluster.confファイルにおいて定義したサーバの名前です。

▪ パッシブサーバ上で/etc/lvm/lvm.confを編集し、以下になるようボリュームリストを変更します。 volume_list = [ "VolGroup00" , "@passive" ] VolGroup00は OS用"/"ファイルシステムを含むボリュームグループです。「Passive」は cluster.confファイルにおいて定義したサーバの名前です。

▪ 両方のサーバ上で、initrdを作り直します。 mkinitrd -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5

11) アクティブサーバ上で、ファイルシステムを作成します。 mkfs.xfs -l size=128m /dev/DATA_VG/DATA_LV

12) クラスタを再起動します。その結果、HA LVM が有効化され、XFS ファイルシステムがマウントされて NFS経由でエクスポートされ、フローティングリソース IPが作成されます。

両方のサーバで同時に以下を実行します。 service cman start service rgmanager start

13) 新しいファイルシステムのサイズを確認します。df -hはマウントされたファイルシステムを示し、ファイルシステムの合計サイズは約 80TB (以前の 2倍) になっています。

14) ユーザデータを復元します。


Page 52

付録 C：ベンチマークテストとテストツール iozoneベンチマークは、シーケンシャル読み書きのスループット (MB/秒) とランダム読み書きの 1秒あたり I/O操作 (IOPS) を測定するために使用したものです。

mdtestベンチマークは、メタデータ操作パフォーマンスをテストするために使用しました。

checkstreamユーティリティは、障害が発生した場合とフェイルオーバが行われる場合のデータの正確性をテストするために使用しました。

Linux ddユーティリティは、最初のフェイルオーバテストと、データスループットとファイルコピー操作を完了するまでの時間の測定に使用しました。

C.1. IOzone IOzoneは、http://www.iozone.org/からダウンロードできます。今回のテストにはバージョン 3.353を使用し、NFS サーバとすべての計算ノードの両方にインストールしました。

IOzoneテストは、クラスタ化モードで 1～64ノードから実行しました。すべてのテストは N-to-N (N個のクライアントが N個の独立したファイルの読み込みまたは書き込みを行う) で実施されました。

キャッシュ効果を最小化するため、テストとテストの間に下記の手順に従いました。

▪ クライアント上の NFSシェアをアンマウントしました。 ▪ サーバ上のクラスタサービスを停止しました。それにより、そのサーバ上の XFSファイルシステ

ムがアンマウントされます。 ▪ サーバ上のクラスタサービスを起動します。 ▪ クライアント上に NFSシェアをマウントします。

下記の表は、IOZoneコマンド行の引数を記述しています。

IOzone引数説明

-i 0 書き込みテスト

-i 1 ランダムアクセステスト

-i 2 1台の PowerEdge R710サーバ

-+n 再テストなし

-c タイミング計算にクローズを含める

-t スレッド数

-e タイミング計算にフラッシュを含める

-r レコードサイズ

-s ファイルサイズ

-t スレッド数

+m クラスタ化モードのときに IOzoneを実行するクライアントのロケーション

-w 一時ファイルをリンク解除 (削除) しない

-I O_DIRECTを使用し、クライアントのキャッシュをバイパスする

-O 結果を ops/秒で表示する


Page 53

シーケンシャルテストについては、書き込みされたデータが合計 128Gになるよう、クライアント数に応じてファイルサイズを変更しました (クライアント数 x クライアントあたりのファイルサイズ=128G)。 IOzoneシーケンシャル書き込み # /usr/sbin/iozone -i 0 -c -e -w -r 1024k -s 2g -t 64 -+n -+m ./clientlist IOzoneシーケンシャル読み込み # /usr/sbin/iozone -i 1 -c -e -w -r 1024k -s 2g -t 64 -+n -+m ./clientlist ランダムテストについては、各クライアントが 2Gのファイル 1個を読み込みまたは書き込みしました。小規模ランダムデータアクセスのシミュレーションを行うため、ランダムテストに使用したレコードサイズは 4kでした。 IOzone IOPsランダムアクセス (読み込みと書き込み) # /usr/sbin/iozone -i 2 -w -r 4k -I -O -w -+n -s 2G -t 1 -+m ./clientlist IOzone テストの-c や-e は、典型的なアプリケーションの挙動に関する現実的な見方を可能にします。O_Directコマンドドラインパラメータは、IOzoneスレッドが実行されている計算ノードのキャッシュをバイパスします。


Page 54

C.2. mdtest mdtest は、http://sourceforge.net/projects/mdtes/からダウンロード可能です。今回のテストでは、バージョン 1.8.3 を使用しました。mdtest は、コンパイルしてから、計算ノードがアクセス可能なNFS シェアにインストールしました。mdtest は、mpirun とともに起動しました。今回のテストについては、Mellanox OFED 1.5.1からの OpenMPIを使用しました。下記の表に、mdtestコマンド行引数を示します。

mpirun引数説明

-d mdtestを実行すべきディレクトリ

-i テストの反復回数

-b ディレクトリ構造の分岐因子

-z ディレクトリ構造の深さ

-L ツリー構造の葉のレベルに相当するファイルのみ

-I ディレクトリツリー1つあたりのファイル数

-y 書き込み後にファイルを同期化する

-u 各タスクの一意の作業用ディレクトリ

-C ファイルやディレクトリを作成する

-R 無作為にファイルを statする

-T ファイルとディレクトリのみを statする

-r テスト実行時に残ったファイルやディレクトリを削除する

IOzoneランダムアクセスパターンと同様に、メタデータテスト中にキャッシュ効果を最小化するために下記の手順に従いました。

▪ クライアントの NFSシェアをアンマウントします。

▪ サーバ上のクラスタサービスを停止します。これにより、サーバ上の XFSファイルシステムがアンマウントされます。

▪ サーバ上でクラスタサービスを起動します。

▪ クライアントに NFSシェアをマウントします。

メタデータファイルとディレクトリの作成 # mpirun -np 32 --nolocal --hostfile ./hosts /nfs/share/mdtest -d /nfs/share/filedir -i 6 -b 320 -z 1 -L -I 3000 -y -u -t -C メタデータファイルとディレクトリの stat # mpirun -np 32 --nolocal --hostfile ./hosts /nfs/share/mdtest -d /nfs/share/filedir -i 6 -b 320 -z 1 -L -I 3000 -y -u -t -R -T メタデータファイルとディレクトリの削除 # mpirun -np 32 --nolocal --hostfile ./hosts /nfs/share/mdtest -d /nfs/share/filedir -i 6 -b 320 -z 1 -L -I 3000 -y -u -t -r


Page 55

C.3. checkstream checkstream ユーティリティは、http://sourceforge.net/projects/checkstream/から入手可能です。今回のテストでは、バージョン 1.0を NFSサーバにインストールしたうえでコンパイルしました。最初に、genstream ユーティリティを使用して大きなファイルを作成しました。このファイルは、クライアントが dd を使用して NFS シェアへのコピーと NFS シェアからのコピーを行います (書き込み操作と読み込み操作を模倣するため)。ファイルコピープロセスの途中で障害のシミュレーションを行い、NFSサービスは 1台のサーバから別のサーバへフェイルオーバしました。その結果得られた出力ファイルは、データの正確性をテストするための checkstream ユーティリティを使用してチェックし、データの破損が発生していないことを確認しました。下記は、データの破損が発生しなかったテスト成功例のサンプル出力です。 checkstream[genstream.file.100G]: ------------------------------------------------ checkstream[genstream.file.100G]: valid data for 107374182400 bytes at offset 0 checkstream[genstream.file.100G]: ------------------------------------------------ checkstream[genstream.file.100G]: end of file summary checkstream[genstream.file.100G]: [valid data] 1 valid extents in 261.205032 seconds (0.00382841 err/sec) checkstream[genstream.file.100G]: [valid data] 107374182400/107374182400 bytes (100 GiB/100 GiB)

checkstream[genstream.file.100G]: 読み込み 26214400 blocks 107374182400 bytes in

261.205032 seconds (401438 KiB/sec), no errors 比較のため、コピーしたファイルにデータの破損が発生したテスト失敗例を示します。たとえば、ファイルシステムが NFS async 操作によりエクスポートされ、書き込み操作中に HA サービスフェイルオーバが発生する場合、データの破損が発生する可能性は高くなります。 checkstream[compute-00-10]: ------------------------------------------------ checkstream[compute-00-10]: valid data for 51087769600 bytes at offset 45548994560 checkstream[compute-00-10]: checkstream[compute-00-10]: ------------------------------------------------ checkstream[compute-00-10]: end of file summary checkstream[compute-00-10]: [valid data] 1488 valid extents in 273.860652 seconds (5.43342 err/sec) checkstream[compute-00-10]: [valid data] 93898678272/96636764160 bytes (87 GiB/90 GiB) checkstream[compute-00-10]: [zero data] 1487 errors in 273.860652 seconds (5.42977 err/sec) checkstream[compute-00-10]: [zero data] 2738085888/96636764160 bytes (2 GiB/90 GiB)

checkstream[compute-00-10]: 読み込み 23592960 blocks 96636764160 bytes in 273.860652

seconds (344598 KiB/sec) checkstream[compute-00-10]: ------------------------------------------------ checkstream[compute-00-10]: encountered 1487 errors, failing


Page 56

C.4. dd ddは、coreutils rpmが提供する Linuxユーティリティの 1つであり、RHEL 5.5とともに配布されます。ddは、1件のファイルをコピーするために使われます。

ファイルシステムは、クライアント上の/mnt/xfsにマウントしました。ストレージにデータを書き込むために、下記のコマンド行を使用しました。 # dd if=/dev/zero of=/mnt/xfs/file bs=1M count=90000 ストレージからデータを読み込むために、下記のコマンド行を使用しました。 # dd if=/mnt/xfs /file of=/dev/null bs=1M

デルHPC NFS ストレージソリューション -...

Documents

Transcript of デルHPC NFS ストレージソリューション -...