次の方法で共有

NAS 構成および NFS ストレージ ターゲットに関する問題のトラブルシューティング

  • [アーティクル]

この記事では、Azure HPC Cache でストレージ ターゲットとして NFS ストレージ システムを追加することを妨げる可能性がある、いくつかの一般的な構成エラーとその他の問題について、解決策を提供します。

この記事では、ポートを確認する方法および NAS システムへの必要なアクセスを有効にする方法の詳細を説明します。 また、NFS ストレージ ターゲットの作成が失敗する原因となることがある、あまり一般的でない問題に関する詳細情報も含まれています。

ヒント

このガイドを使用する前に、NFS ストレージ ターゲットの前提条件に関するページを参照してください。

ご自分の問題に対する解決策がここに記載されていない場合は、サポート チケットを開いてください。そうすれば、Microsoft サービスおよびサポートがお客様と協力して問題を調査し、解決することができます。

十分な接続スレッドを提供する

大規模な HPC Cache システムは、ストレージ ターゲットに対して複数の接続要求を行います。 たとえば、ストレージ ターゲットで Ubuntu Linux の nfs-kernel-server モジュールを使用する場合、NFS デーモン スレッドの既定の数は 8 個と少なくなります。 スレッドの数を 128 または 256 に増やします。これは、中規模または大規模の HPC Cache をサポートするのにより妥当な数です。

Ubuntu でスレッド数を確認または設定するには、/etc/init.d/nfs-kernel-server の RPCNFSDCOUNT 値を使用します。

ポート設定を確認する

Azure HPC Cache では、バックエンド NAS ストレージ システム上のいくつかの UDP/TCP ポートに対して読み取り/書き込みアクセスが必要です。 NAS システム上でこれらのポートにアクセスできること、さらにストレージ システムとキャッシュ サブネット間のファイアウォールを経由したこれらのポートへのトラフィックが許可されていることを確認してください。 この構成を確認するために、データ センターのファイアウォール管理者およびネットワーク管理者と協力することが必要な場合があります。

これらのポートは、ベンダーが異なるストレージ システムではそれぞれ異なるため、ストレージ ターゲットを設定するときにご利用のシステムの要件を確認してください。

一般に、キャッシュには次のポートへのアクセスが必要です。

プロトコル [ポート] サービス
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 mountd
TCP/UDP 4047 status

ご利用のシステムに必要な特定のポートを調べるには、次の rpcinfo コマンドを使用します。 次のコマンドを使用すると、ポートが一覧表示され、表内の関連する結果が書式設定されます (<storage_IP> という表現の部分にはシステムの IP アドレスを使用してください)。

このコマンドは、NFS インフラストラクチャがインストールされている任意の Linux クライアントから発行できます。 クラスター サブネット内のクライアントを使用する場合は、サブネットとストレージ システム間の接続を検証するためにも役立ちます。

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

rpcinfo クエリによって返されるすべてのポートで、Azure HPC Cache のサブネットからの無制限のトラフィックが許可されていることを確認します。

これらの設定の確認は、NAS 自体においてだけでなく、ストレージ システムとキャッシュ サブネット間のファイアウォールでも行ってください。

ルート スカッシュ設定を確認する

ルート スカッシュ設定が不適切に構成されている場合、それらによってファイル アクセスが中断される可能性があります。 各ストレージ エクスポートと一致する HPC Cache クライアント アクセス ポリシーの設定が適切であることを確認する必要があります。

ルート スカッシュでは、クライアント上のローカル スーパーユーザー ルートによって送信された要求を、バックエンド ストレージ システムにルートとして送信されないようにします。 それにより、ルートからの要求が、"nobody" のような非特権ユーザー ID (UID) に再割り当てされます。

ヒント

以前のバージョンの Azure HPC Cache では、HPC Cache からのルート アクセスを許可するために NAS ストレージ システムが必要でした。 現在、HPC Cache クライアントにエクスポートへのルート アクセス権を与える必要がない限り、ストレージ ターゲットエクスポートに対するルート アクセスを許可する必要はありません。

ルート スカッシュは、次の場所の HPC Cache システムに構成できます。

  • Azure HPC Cache で - クライアント アクセス ポリシーを使用して、特定のフィルター規則に一致するクライアントのルート スカッシュを構成します。 クライアント アクセス ポリシーは、各 NFS ストレージ ターゲット名前空間パスの一部です。

    既定のクライアント アクセス ポリシーはルートをスカッシュしません。

  • ストレージ エクスポートで - ルートからの受信要求を非特権ユーザー ID (UID) に再割り当てするようにストレージ システムを構成できます。

ストレージ システムのエクスポートでルートをスカッシュする場合は、そのストレージ ターゲットの HPC Cache クライアント アクセス規則で、ルートもスカッシュするように更新する必要があります。 そうしない場合、HPC Cache を介してバックエンド ストレージ システムに対する読み取りまたは書き込みを試みると、アクセスの問題が発生する可能性があります。

次の表は、クライアント要求が UID 0 (ルート) として送信された場合のさまざまなルート スカッシュ シナリオの動作を示しています。 * でマークされたシナリオは、アクセスの問題を引き起こす可能性があるため 推奨されません。

設定 クライアントから送信された UID HPC Cache から送信された UID バックエンド ストレージで有効な UID
ルート スカッシュなし 0 (ルート) 0 (ルート) 0 (ルート)
HPC Cache のみでのルート スカッシュ 0 (ルート) 65534 (該当なし) 65534 (該当なし)
*NAS ストレージのみでのルート スカッシュ 0 (ルート) 0 (ルート) 65534 (該当なし)
HPC Cache と NAS でのルート スカッシュ 0 (ルート) 65534 (該当なし) 65534 (該当なし)

(UID 65534 は例です。クライアント アクセス ポリシーでルート スカッシュを有効にすると、UID をカスタマイズできます。)

ディレクトリ パスへのアクセスを確認する

階層ディレクトリをエクスポートする NAS システムの場合は、Azure HPC Cache に、使用しているファイルのパス内の各エクスポート レベルへの適切なアクセス権があることを確認します。

たとえば、次のような 3 つのエクスポートがシステムによって表示されるとします。

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

エクスポート /ifs/accounting/payroll は /ifs/accounting の子であり、/ifs/accounting 自体は /ifs の子です。

payroll エクスポートを HPC キャッシュ ストレージ ターゲットとして追加した場合、キャッシュでは実際には /ifs/ がマウントされ、そこから payroll ディレクトリへのアクセスが行われます。 そのため、Azure HPC Cache では、/ifs/accounting/payroll エクスポートにアクセスするために、/ifs への十分なアクセス権が必要です。

この要件は、ストレージ システムから提供されるファイル ハンドルを使用して、キャッシュでファイルにインデックスを付け、ファイルの競合を回避する方法に関連しています。

階層化されたエクスポートを含む NAS システムでは、同じファイルが別のエクスポートから取得された場合、そのファイルに対して異なるファイル ハンドルが与えられます。 たとえば、クライアントでは /ifs/accounting がマウントされ、ファイル payroll/2011.txtへのアクセスが行われるとします。 別のクライアントでは /ifs/accounting/payroll がマウントされ、ファイル 2011.txtへのアクセスが行われます。 ストレージ システムによるファイル ハンドルの割り当て方法に応じて、この 2 つのクライアントでは、異なるファイル ハンドル (<mount2>/payroll/2011.txt 用と <mount3>/2011.txt 用) を持つ同じファイルを受信する可能性があります。

バックエンド ストレージ システムでは、ファイル ハンドル用の内部エイリアスが保持されますが、Azure HPC Cache では、インデックス内のどのファイル ハンドルが同じ項目を参照しているを判断することはできません。 そのため、キャッシュでは、同じファイルであることが認識されないために、同じファイルに対して異なる書き込みがキャッシュされ、変更が誤って適用される可能性があります。

複数のエクスポートでのファイルについて考えられるこのようなファイルの競合を回避するために、Azure HPC Cache ではパス内の使用可能な最も浅いエクスポートが自動的にマウントされ (例では /ifs)、そのエクスポートから与えられたファイル ハンドルが使用されます。 複数のエクスポートで同じベース パスが使用される場合、Azure HPC Cache ではそのパスへのアクセスが必要です。

VPN パケット サイズの制限を調整する

キャッシュとご利用の NAS デバイスとの間に VPN がある場合、その VPN によって、フルサイズの 1500 バイト イーサネット パケットがブロックされる可能性があります。 NAS と Azure HPC Cache インスタンスの間で大規模なやりとりはが完了しないが、より小さな更新プログラムは想定どおりに動作する場合、この問題が発生する可能性があります。

VPN 構成の詳細がわからなければ、ご利用のシステムにこの問題があるかどうかを簡単に判断する方法はありません。 この問題があるかどうかを確認するのに役立ついくつかの方法を次に示します。

  • VPN の両側でパケット スニッファを使用して、正常に転送されるパケットを検出します。

  • ご利用の VPN で ping コマンドが許可されている場合は、フルサイズのパケットの送信をテストできます。

    これらのオプションを使用して、VPN 経由で NAS に対して ping コマンドを実行します (<storage_IP> 値の部分にはご利用のストレージ システムの IP アドレスを使用します)。

    ping -M do -s 1472 -c 1 <storage_IP>

    コマンドのオプションは次のとおりです。

    • -M do - フラグメントしない
    • -c 1 - パケットを 1 個だけ送信する
    • -s 1472 - ペイロードのサイズを 1472 バイトに設定する。 これは、イーサネット オーバーヘッドを考慮した後の 1500 バイト パケットの最大サイズのペイロードです。

    成功した応答は次のようになります:

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    ping が 1472 バイトで失敗した場合、パケット サイズに問題がある可能性があります。

この問題を修正するには、リモート システムで最大フレーム サイズが正しく検出されるように、VPN に MSS クランプを構成することが必要になる場合があります。 詳細については、VPN Gateway IPsec/IKE パラメーターのドキュメントを参照してください。

場合によっては、Azure HPC Cache の MTU 設定を 1400 に変更すると役立つことがあります。 ただし、キャッシュの MTU を制限する場合は、キャッシュと対話するクライアントとバックエンド ストレージ システムの MTU 設定も制限する必要があります。 詳細については、「Azure HPC Cache の追加設定を構成する」を参照してください。

ACL セキュリティス タイルを確認する

一部の NAS システムでは、アクセス制御リスト (ACL) と従来の POSIX または UNIX セキュリティを組み合わせたハイブリッド セキュリティ スタイルが使用されます。

ご利用のシステムから、そのセキュリティ スタイルが頭字語 "ACL" を含まない UNIX または POSIX としてレポートされた場合、この問題はお客様に影響ありません。

ACL が使用されたシステムの場合、Azure HPC Cache では、ファイル アクセスを制御するために、追加のユーザー固有の値を追跡する必要があります。 これを行うには、アクセス キャッシュを有効にします。 アクセス キャッシュを有効にするユーザー向けのコントロールはありませんが、サポート チケットを開いて、ご利用のキャッシュ システム上で影響を受けるストレージ ターゲットに対してそれを有効にするように要求することができます。

次のステップ

この記事で説明されていない問題が発生した場合は、サポートに問い合わせ、専門家の支援を受けてください。