NetApp Tech OnTap NetApp Logo NetApp Logo
NetApp Tech OnTap
     
ネットアップとRed Hatの共同pNFSソリューション
Pranoop Erasani
テクニカル ディレクター、NFS
Justin Parisi
テクニカル マーケティング エンジニア

科学、工学、ビジネス、金融分野向けのさまざまなアプリケーションのパフォーマンスを存分に発揮するためには、共有データへのアクセスが欠かせません。NFSは、共有データへのアクセスに最も広く使用されている標準プロトコルですが、大規模なクラスタ コンピューティング システムでは、ボトルネックとなりかねません。共有ファイル システムに含まれる全ファイルにとって唯一のアクセス ポイントとなるファイル サーバに、過剰な負荷がかかる可能性があるからです。

これまでにも、ハイパフォーマンスと共有データへのアクセスを実現するための手段は考案されてきましたが、その大半は多かれ少なかれ独自仕様で設計されたため、異機種混在型システムのサポートは不可能であり、NFSをはじめとする標準プロトコルのように、広く普及することもありませんでした。

Parallel NFS(pNFS)標準は、NFSのバージョン4.1プロトコル仕様(RFC 5661)のサブ機能です。pNFSは、単一サーバのボトルネック解消に役立ち、並列データ アクセス用のソリューションとして、今後広く利用されることになるでしょう。本稿では、pNFSの仕組みと、ネットアップとRed Hatが共同で進めているpNFSの開発について、また、 clustered NetApp® Data ONTAP®におけるpNFSの仕組みについて説明します。

pNFSとは?

pNFSプロトコルを利用すると、2台以上のデータサーバにストライピングされたファイルに、各クライアントから直接アクセスできます。複数のデータ サーバに並行してアクセスするため、クライアントのI/Oの所要時間が大幅に短縮されます。pNFSプロトコルは、標準的なNFSプロトコルとの下位互換性を維持しながら、クライアント単位、ファイル単位のパフォーマンスを大幅に向上するよう設計されています。また、pNFSの拡張機能が実装されていないクライアントからも、データにアクセスできます。

pNFSアーキテクチャとコア プロトコル

pNFSアーキテクチャは、次の3つの主要コンポーネントで構成されています。

  • メタデータ サーバ:データ トラフィック以外のすべてのトラフィックを処理します。メタデータ サーバは、各ファイルの格納場所および格納方法を示したメタデータの保持に使用されます。
  • データ サーバ:ファイル データの格納先であり、クライアントの読み取り / 書き込み要求に直接応答します。ファイル データは複数のデータ サーバにストライピングできます。
  • 1つ以上のクライアント:メタデータ サーバから取得したメタデータ情報に基づいて、データ サーバに直接アクセスできます。

クライアント、メタデータ サーバ、およびデータ サーバ間では、次の3種類のプロトコルが使用されます。

  • 制御プロトコル:メタデータ サーバとデータ サーバの間で同期処理に使用されます。制御プロトコルは、pNFS仕様によって定義されておらず、ベンダーによって異なります。
  • pNFSプロトコル:クライアントとメタデータ サーバの間で使用されます。実質的には、pNFS固有の拡張仕様を実装したNFSv4を表します。pNFSプロトコルは、レイアウト(複数のデータサーバに格納されたファイルにアクセスするため、格納場所および必要なストレージ アクセス プロトコルを記述したメタデータを含む)の取得と操作に使用されます。
  • ストレージ アクセス プロトコル:クライアントによって、データ サーバへのダイレクト アクセスに使用されます。pNFS標準では現在、ファイルベース(RFC5661)、ブロックベース(RFC5663)、およびオブジェクトベース(RFC5664)の、3種類のストレージ プロトコルが定義されています。clustered Data ONTAPは現在、ファイルベースのストレージ プロトコルをサポートしており、データ サーバへのアクセスにNFSv4.1を使用しています。

pNFSの構成要素。クライアントはメタデータ サーバにレイアウトを要求し(pNFSプロトコル)、その後データ サーバに直接アクセスします(ストレージ アクセス プロトコル)。

図1)pNFSの構成要素。クライアントはメタデータ サーバにレイアウトを要求し(pNFSプロトコル)、その後データ サーバに直接アクセスします(ストレージ アクセス プロトコル)。

クライアントは、ファイルにアクセスするために必ずメタデータ サーバに接続し、ファイルをオープンしてレイアウトを要求します。その後ファイル レイアウトを受信すると、レイアウト情報と適切なストレージ アクセス プロトコルを使用して、複数のデータ サーバと直接、並列I/O処理を行います。また、これ以降の処理には、メタデータ サーバは介在しません。レイアウト情報は、pNFSクライアントの並列I/O処理が完了するまで、キャッシュされます。サーバへの並列アクセスが不可能な場合は、pNFSサーバがファイルのレイアウトを取り消すことができます。さらに、pNFSによってメタデータ アクセスに関するNFSサーバのメカニズムが変更されることはありません。

ネットアップとRed HatのpNFS共同開発チーム

pNFSソリューションを機能させるためには、クライアントとサーバ双方のコンポーネントが必要となります。ネットアップとRed Hatは、アップストリーム コミュニティと幅広く連携し、業界初となる標準ベースのエンドツーエンドなpNFSソリューションの共同開発を進めてきました。

この共同開発において、ネットアップはストレージのクラスタリング機能とpNFSを組み合わせ、拡張性の向上を図っています。clustered Data ONTAP 8.1以降を搭載したNetApp FAS/Vシリーズ ストレージは、数テラバイトのデータを69ペタバイトにまで拡張できます。すべてのデータは単一のストレージ エンティティとして管理できるため、pNFS環境の管理が簡単に行え、計画的停止や計画外停止も不要となります。

一方、Red Hat Enterprise Linux®が提供する、業界初のpNFS完全対応クライアントを使用すると、次世代型の拡張性に優れたpNFSベースのファイルシステム ソリューションを、計画、設計できます。設定を変更することなく、アプリケーション ワークロードの処理にpNFSのメリットをフル活用できるため、既存アプリケーションもシームレスに移行できます。

pNFSとclustered Data ONTAP

ネットアップでは、pNFSの実装をclustered Data ONTAP 8.1から開始します (7-ModeやData ONTAP 7Gには実装されません)。clustered Data ONTAPにpNFSが実装されることで、以下のようなメリットが実現します。

  • インフラの簡易化: LustreやGPFSなど、他の並列ファイルシステムでは、ストレージ以外に専用のサーバが何台も必要となりますが、こうしたファイルシステムに比べると、pNFSのインフラは全体的にシンプルです。
  • 易管理性。通常,pNFS 包含多个必须单独进行管理的文件服务器。在集群模式 Data ONTAP 中,您可以将所有服务器端 pNFS 组件作为一个系统进行管理。
  • 无中断运行。NetApp 集群中部署的 pNFS 可像其他任何工作负载一样受益于无中断运行,执行存储故障转移、逻辑接口 (Logical Interface, LIF) 迁移和无中断卷移动等维护以及负载平衡操作。
  • 所有节点都可以用作元数据服务器。在集群模式 Data ONTAP 实施中,存储集群中的每个节点都可以用作元数据服务器和数据服务器。这消除了单个元数据服务器带来的潜在瓶颈问题,并且有助于在集群之间分布元数据。

NetApp 和 Red Hat 共同打造 pNFS

pNFS 解决方案需要客户端和服务器组件,才能发挥作用。NetApp 和 Red Hat 与上游社区展开广泛的合作,打造出首个标准化端到端 pNFS 解决方案。

NetApp 通过将存储集群与 pNFS 相结合,解决了扩展难题。运行集群模式 Data ONTAP 8.1 或更高版本的 NetApp FAS 和 V 系列存储可以从区区数 TB 数据扩展到 69 PB,并且可以作为单个存储实体进行管理,不仅简化了 pNFS 环境的管理,而且有助于消除计划内和计划外停机。

借助市面上首款全面支持的 pNFS 客户端(随 Red Hat Enterprise Linux® 提供),您可以开始规划和设计基于 pNFS 的新一代可扩展的文件系统解决方案。应用程序工作负载可以充分利用 pNFS,而无需修改,因此现有应用程序可以实现无缝过渡。

pNFS 和集群模式 Data ONTAP

从集群模式 Data ONTAP 8.1 开始,NetApp 采用了 pNFS 实施。(未提供 7-模式或 Data ONTAP 7G 实施)。在集群模式 Data ONTAP 中实施 pNFS,可以带来以下诸多优势:

  • 简化的基础架构。与 Lustre 和 GPFS 等其他并行文件系统相比,pNFS 的整体基础架构更为简单,除了存储之外,不再需要大量专用服务器。
  • 管理性: pNFSには通常、複数のファイルサーバが含まれ、それぞれ別の管理が必要となりますが、 clustered Data ONTAPでは、サーバ側のpNFSコンポーネントをすべて単一のシステムとして管理できます。
  • ノンストップ オペレーション:ネットアップ クラスタにpNFSを実装すると、ストレージ フェイルオーバー、LIF移行、オンラインのボリューム移動など、保守や負荷分散に伴う処理が、他のワークロード同様に、ノンストップで行えます。
  • 全ノードをメタデータ サーバとして使用可能: pNFSをclustered Data ONTAPに実装すると、ストレージ クラスタ内のノードをすべて、メタデータ サーバとしても、データ サーバとしても使用できるため、 メタデータ サーバを1台のみ使用した場合のようにボトルネックが発生することがなく、クラスタ全体のメタデータ操作がスムーズに行えます。

pNFSを実装したData ONTAPとNFSの比較。全ノードを、メタデータ サーバ / データ サーバとして使用可能。

図2) pNFSを実装したData ONTAPとNFSの比較。全ノードを、メタデータ サーバ / データ サーバとして使用可能。

ではここで、pNFSがclustered Data ONTAPとどのように連携するかをご説明しましょう。まず、クラスタ内のノードにあるpNFSファイルシステムを、クライアントにマウントしたと想定してください。このファイルにアクセスするため、クライアントはファイルが格納されているノードに対して、メタデータ要求を送信します。実装されたpNFSにより、ファイルの格納場所やレイアウト、ネットワーク情報など、ファイルにアクセスするために必要な情報が収集され、返信されます。クライアントは、その情報を使い、1つまたは複数のノードに格納されているデータに直接アクセスします。pNFSは、ボリュームへのダイレクト パスを提供するため、アプリケーションのスループットが向上し、レイテンシを低く抑えられます。

pNFSは、LIF移行、ストレージ フェイルオーバー、ボリューム移動など、clustered Data ONTAPのノンストップ オペレーションとシームレスに統合されます。ノンストップ オペレーションが開始すると、pNFSクライアントとサーバが通信情報を交換し合い、新しいI/Oパスを自動的に確立するため、スループットを均一に保つことができます。しかもアプリケーションの処理が中断されることは一切ありません。ファイルシステムへのネットワーク パスを明示的に提供しなくても、クラスタの保守作業が行えるようになるため、ストレージ管理者の負荷は大幅に軽減されます。こうして、pNFSをclustered Data ONTAPに実装すると、パフォーマンスが向上するだけでなく、保守作業時の管理ワークフローがシンプルになります。大規模クラスタのプロビジョニングや導入をスムーズに行うには、こうした機能が欠かせません。

Flexvol pNFS

図3)pNFSを使用しない場合は、メタデータとデータ パス双方がほぼ静的となります。pNFSを実装すると、メタデータ サービスを複数のノードに提供し、ファイルを格納しているノードのネットワーク インターフェイスとの間にダイレクト データ パスを確立できます。データ移動時には、最高のパフォーマンスを維持できるように、データ パスが自動調整されます。

ベストプラクティス

ではここで、最高レベルのpNFSパフォーマンスを実現するためのベストプラクティスをご紹介します。

  • NFSv4.1およびpNFSクライアントに関する最新の互換性情報は、NetApp Interoperability Matrixでご確認いただけます。
  • pNFSをサポートするクラスタ ノードには、1つ以上の論理インターフェイス(LIF)を定義する必要があります。こうすることで、pNFSクライアントがそのノードに格納されているボリュームに直接アクセスできます。
  • 大量のメタデータを含むワークロードを扱う場合は、マウントをクラスタ内の全ノードに提供できるよう、pNFSクライアントを設定する必要があります。こうすることで、すべてのノードをメタデータ サーバとして使用できるようになります。この設定は、clustered Data ONTAPに標準搭載されているDNSロード バランシング機能か、ドメイン ネーム サーバ(DNS)のラウンドロビン機能によって行えます。

pNFSをネットアップ ストレージに導入する方法については、TR-4063をご参照ください。

Red HatのpNFSクライアント

Red HatのpNFSクライアントが最初にリリースされたのは、2011年のRed Hat Enterprise Linux(RHEL)6.2カーネル バージョンでした。RHEL 6.2とRHEL 6.3は、どちらもpNFSの「評価版」として発表されました。

2013年2月にリリースされたRHEL 6.4には、正式版のpNFSが含まれています。NFSかpNFSを実装したネットアップ ストレージでRed Hatクライアントを使用する方法については、TR-3183をご覧ください (このテクニカル レポートは現在改訂中のため、本稿の公開時にはご覧いただけません。しばらく時間を置いてご参照ください)

pNFSのユースケース

pNFSは、高度な並列処理を必要とする科学アプリケーションや工学アプリケーションに最適です。さらに、独自の機能を備えているため、企業のIT環境にも適しています。以下にその例を挙げます。

ビジネスクリティカルなアプリケーション

通常、ビジネスクリティカル アプリケーションには、最も高度なサービス レベルが求められます。ストレージの帯域幅と容量は、サーバの要件に応じてシームレスに拡張できなければなりません。ネットアップのストレージ ボリュームが、ネットアップ クラスタ内にある、より処理能力の高いコントローラへと透過的に移動されると、Red Hat Enterprise Linux pNFSクライアントは、データの動きを自動的に追い、データ パスを自己調整、最適化します。その結果、停止時間がほぼゼロになり、サーバやアプリケーションの再設定も不要となります。

マルチテナント ストレージ ソリューション

pNFSを使用すると、並列データ アクセスが行えるため、マルチテナントで異機種混在の環境にも、直接的なメリットがもたらされます。データは、特定のネットアップ コントローラに縛られることなく、「ネットアップ クラスタ」に格納できます。pNFSを使用すれば、Red Hat Enterprise Linuxサーバは、最適なデータ パスを見つけ、スループット最適化することができます。

異種クライアント、異種ワークロードにも対応

NFSv4.1とpNFSを使用すると、クラスタのネームスペース内のどこにあるファイルシステムでも、自在にマウントすることが可能となります。クラスタ対応のアプリケーションはpNFS経由で、また、従来型のアプリケーションはNFSv3経由でマウントできます。ストレージからエクスポートされたファイルシステムには、さまざまな種類のNFSを介してクライアントをマウントできるため、データにアクセスするアプリケーションの設定を大幅に変更しなくても、複数のファイルシステムを共存させることが可能です。これだけの柔軟性があると、変更管理を頻繁に行って、管理負荷を低く抑えることができます。

仮想環境

Red Hat Enterprise Linux pNFSクライアントを使用するハイパーバイザと仮想マシンは、1セッションあたり複数の接続を維持できるため、複数のネットワーク インターフェイスに負荷を分散することができます。つまり、マルチパス ドライバを別途用意したり設定を変更することなく、NFSをマルチパス化できるということです。

まとめ

ネットアップは、NFSv4.1とpNFS双方の開発を牽引しており、ワーキング グループの共同議長を務めているほか、 NFSv4.1仕様の大部分を開発、編集しています。こうした取り組みは、業界標準の採用によってストレージの問題を解消するという当社の方針に合致しています。

先日、RHEL 6.4のリリースによって、正式版のpNFSクライアントが利用可能となりました。今なら、Red Hatクライアントとclustered NetApp Data ONTAPを組み合わせることで、テスト環境や本番環境にpNFSを導入できます。

 pNFSに関するご意見をお寄せください。

ご質問、意見交換、情報提供は、ネットアップのコミュニティ サイトまでお願いいたします。 著者紹介:Pranoop Erasani(テクニカル ディレクター、NFS)、Justin Parisi(テクニカル マーケティング エンジニア)

作者:NFS 技术总监 Pranoop Erasani 和技术营销工程师 Justin Parisi

Pranoopは、ネットアップのプロトコル テクノロジ エンジニアリング部門で主任NFSアーキテクチャを務めており、Data ONTAP用のNFSプロトコル開発を指揮しています。同氏は、かつてclustered Data ONTAP用pNFSの開発にも貢献しており、 クラスタ システムにNFSv4.1やpNFSを採用することを強く提唱しています。また、これまでにもpNFS IETF標準に関する数多くのディスカッションに参加し、NFSの相互運用性をテーマにしたイベントでも頻繁に講演を行っています。Pranoopは現在、主要なテクニカル アドバイザとして、お客様が運用されている環境やストレージ ソフトウェア ソリューションのテクニカル マーケティングと製品開発に関する助言を行っています。

Justinは、RTPに勤務しており、ここ5年間はネットアップ グローバル サポートで、テクニカル サポート エンジニアと、重大な問題を解消するエスカレーション エンジニアを兼任しています。同氏は主にclustered Data ONTAPを担当しており、これまでトラブルシューティングのトレーニング資料や、多数の技術情報記事を制作してきました。また、CIFS、NFS、SNMP、OnCommand® System Manager、Unified Manager、SnapDrive®、SnapManager®、Microsoft® Exchange、SQL Server®、Active Directory®、LDAPなど、幅広い分野に精通しており、ネットアップに関する知識をすべて備えた万能エンジニアでもあります。

Tech OnTap
ご購読はこちらから
Tech OnTapは、ITに関する解説のほか、実用性の高いベストプラクティス、ヒントやツール、開発の舞台裏を探るインタビュー、デモ、ピア レビューなど、貴重な情報満載の月刊ニュース レターです。

ネットアップ コミュニティのTech OnTapから今すぐご登録ください。

Explore
pNFSに関する詳細情報

pNFSの詳細情報、ならびに、
pNFSでIT環境を高速化する方法については、
次のリンクをご覧ください。

Explore
 
TRUSTe
お問い合わせ   |   購入方法   |   フィードバック   |   採用情報  |   登録   |   プライバシーポリシー   |   © 2013 NetApp