本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Technical Marketing EngineerのDwayne Lessner氏です。原文を参照したい方はNFS v4 to Enable Acropolis File Servicesをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら。
ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。
Acropolis ファイルサービス(AFS)はソフトウェアで定義された、スケールアウトファイルストレージソリューションで、ホームディレクトリ、ユーザープロファイル、組織内のファイル共有、アプリケーションのログ、バックアップ、そしてアーカイブなどの非構造化データのリポジトリを提供します。柔軟にワークロードの要件に対応するため、AFSはNutanixのエンタープライズクラウドプラットフォームのコアコンポーネントと完全に統合されています。ワシントンD.Cとフランスのニースの.Next ユーザーカンファレンスの両方において、AFSが現在のSMBのサポートに加えて、NFSを新た今後のヴァージョンで、サポートするという機能がハイライトされました。
NFSは私にとって80年台の赤ん坊時代と同じぐらい長い昔から、空気を呼吸するような存在でした。オープンスタンダートであり、NFSは何年にも渡って進化し、今では複数のヴァージョンが利用できるようになっています。殆どの場合、利用されるバージョンはサーバにアクセスしようとするクライアントによって決められます。Nutanixはこれを念頭に、現在のSMBをサポートしながら、最初はヴァージョン4でNFSの領域に踏み出すことにしました。NFS v4は安定しており、2000年台から何度も繰り返し利用されてきました。殆どの最近の様々なプラットフォーム、例えばLinux(CentOS、Ubuntu)、Solaris、AIXではNFS v4を標準のプロトコルとして利用しており、加えてセキュリティに目を向けるとこれはすばらしく簡単な選択肢です。
セキュリティ
NFS v4はプロトコルを運用するために開放しなければならないポート数を制限することでセキュリティを向上させています。NFS v4で開放しなければならないポートは2049のみで、これに対してNFS v3はマウント、ファイルロック、ネットワークステータスモニタをプロトコルの外で運用しなければならないため、追加のポートが必要となります。ファイヤウォールのルールも1つだけになり、更に重要な事には上で述べてきたようなプロトコルを減らすことで、被攻撃面を減らすことができるのです。
NFS v4ではローカルのパスワードファイルをもはや必要とせず、すぐに無秩序化してしまうUID/GIDも必要としません。クライアントとサーバがユーザーとグループのアサインにはKerberosとActive Directory(AD)がサポートされています。NFS v4は'user@domain'と'group@domain'という文字列を利用します。ここでのdomainはDNSに登録された、ドメインもしくはサブドメインを顕します。大抵の場合、これについてはクライアントのidmapd.confで構成されます。
もしもADのサポートを利用したいという場合にはKerberosの認証のレベルには3つのオプションが有ります。以下の全てのオプションで、Kerberos ヴァージョン5を利用しています :
- krb5, DES (Data Encryption Standard - 標準データ暗号化) 対称鍵暗号化とMD5のいち方向ハッシュがAFSでの認証に利用あsれます
- krb5i (Integrity - 統合), krb5に加え、すべてのリクエスト/応答にMD5ベースのMACが利用されます
- krb5p (privacy - プライバシー), krb5 と krbiに加え、krb5にはDES暗号化が行われ、クライアントとサーバ間の通信が暗号化され、プライバシーが保証されます
krbp以外の場合、理論的には誰かがデータを再生成し、中間から攻撃を仕掛けるということは可能です。理論的にはと付け加えたのはNFSデータを別のネットワークに分離保持することができ、こうした盗聴が発生する危険性を減らすことができるからです。
管理
もし、ADがRFC-2307のサポートを有効にしている場合、AFSの管理をより簡単に実行することができるようになります。RFC-2307によって、Linux統合においてもユーザーとグループの情報をAD内に保持することができるようになります。ADからUID/GIDを変換することができるのです。RFC-2307のサポートは以下を実現します :
NFS v4プロトコル内に含まれているリースベースのロック機構によって、ロックの管理もとても簡単になります。ヴァージョン4以前では、アプリケーションがロックを行わなければなりませんでした。これはサーバー上にロックが残ってしまうということを引き起こし、ロックのクリーンナップという追加の管理オーバーヘッドを生み出していました。クライアントとAFSが同一のリースを設定していれば、同期を取って運用することができます。
NFS v4はサーバ、つまり今回はAFSによって擬似的ファイルシステムを構成します。この擬似的なファイルシステムによって、クライアントが見ることのできるネームスペースの一部を制限するためにも利用できます。この機能は管理そしてセキュリティのためのものです。
もしも以下をエクスポート下なら:
/SAP/marketing
/SAP/sales
/Backup/archive
クライアントは共通のルートディレクトリからは/marketingと/salesとarchiveしか見ることができません。擬似的なファイルシステムは上で青く表示されている部分を切り離し、隠すということを実現しているのです。
NFS v3 から NFS v4 へ
NFS v3からの移行を簡単にするため、ADまたはLDAPのサポートは必須ではありません。AUTH_SYSもしくはAUTH_NONEの認証をAFS上で利用することができます。AUTH_NONEでは認証情報を聞かれることはありません。単にネットワークがつながるかどうかとACLを利用して他の場所からマウントされているエクスポートを保護します。
AUTH_SYSはクライアントで認証を行い、NFSヴァージョン3からの変更が見えることはありません。AUTH_SYSはクライアントのUID/GIDをファイルを作成して行い、その後もそれを利用します。これは時間が限られており、アプリケーションのプロセスを変更する必要のない時の迅速な以降に利用されます。
UDPを利用し続けている古いクライアントをチェックする必要があるかもしれません。NFS v4ではTCPのみが許可されています。UDPでの接続コントロールが無いため、クライアントはすぐにタイムアウトしてしまうため、NFS v4クライアントで接続し直す必要が出るかもしれません。
NFS v4はファイルとディレクトリにUTF-8を利用します。UTF-8は7ビットのASCIIエンコードと後方互換性があり、7ビットASCIIでの全ての名前は引き続き利用できます。8ビット文字を含む名前を以前利用していた場合にはNFS v4はUTF-8を利用しているため、エラーになる誤翻訳を起こすかもしれません。これについては国際言語を利用しているような場合に発生します。例えばé, Ã, ïというような文字が対象です。
AFSでNFS v4を最初から導入
クライアントの可用性とセキュリティがもっとも重要な事項では有りますが、AFSにとってはその機能関連のサポートも非常に重要です。AFSはワンクリック最適化と単一ネームスペース下のファイルを複数のコントローラーに分散する能力を備えています。単一ネームスペースのために、AFSはNFS v4の機能であるFS_LOCATIONSを利用できる機能を備えています。クライアントがあるFSVMにアクセスし、そのコントローラーがそのエクスポートを保持していなかった場合、NFS3ERR_MOVEDが発行されるため、クライアントはFS_LOCATIONSを利用して適切な場所を探し出します。データセットと接続数が膨らむにつれ、ファイルサーバーのコントローラーはスケールアップ、もしくはスケールアウトしながらも、物理的なデータ移行をせずに済ませて、日々の運用をシンプルにし続けるのです。
新しいワークロードや継続的な統合のパイプラインがAFS上に展開されたとしても、必要に応じて単一のマウントポイントに対してファイルサーバコントローラーを追加することでその負荷に対応することができます。精密なメタデータの取り回しにおいてもAFSはNFS v4の幅広い助けを借りることで、一貫したエクスペリエンスの提供を継続できるのです。
NFS v4はセキュリティのゴールデンスタンダートと運用の一元化を提供します。NFS v4はAFSに今後お客様が知り、そして大好きになるワンクリックの素晴らしさを提供しているのです。
Forward-Looking Statements Disclaimer
This blog includes forward-looking statements, including but not limited to statements concerning our plans and expectations relating to product features and technology that are under development or in process and capabilities of such product features and technology. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs. The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; delays in or lack of customer or market acceptance of our new product features or technology; the failure of our software to interoperate on different hardware platforms; failure to form, or delays in the formation of, new strategic partnerships and the possibility that we may not receive anticipated results from forming such strategic partnerships; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our Form 10-Q for the fiscal quarter ended October 31, 2017, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this presentation and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.
(c) 2018 Nutanix, Inc. All rights reserved. Nutanix, the Enterprise Cloud Platform, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).
記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX)
NFS v4のとAFSの記事ですが、この記事を読むことでAFSがNFS v4を徹底的に活用するアーキテクチャになっているということがわかります。スケールアウトによるリダイレクトや様々なNutanixとして必要な機能はNFS v4由来であるということがわかるのはとてもおもしろいですね。
こうした複雑な動きをしながら、利用者･管理者にとってはシンプル、利用しない手はありません!
