NAS 構成と NFS ストレージ ターゲットの問題のトラブルシューティング

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

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

問題の解決策がここに含まれていない場合は、Microsoft サービスとサポートが問題を調査して解決できるように、 サポート チケットを開 いてください。

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

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

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

ポートの設定を確認する

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

ポートはベンダーによってストレージ システムによって異なります。そのため、ストレージ ターゲットを設定するときにシステムの要件を確認してください。

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

システムに必要な特定のポートを確認するには、次の 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 クライアント アクセス ポリシーの設定が適切であることを確認する必要があります。

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

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

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

  既定のクライアント アクセス ポリシーはルートを無効化しません。

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

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

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

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

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

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

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

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

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

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

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

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

バックエンド ストレージ システムはファイル ハンドルの内部エイリアスを保持しますが、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 では、ファイル アクセスを制御するために、追加のユーザー固有の値を追跡する必要があります。 これを行うには、アクセス キャッシュを有効にします。 アクセス キャッシュを有効にするユーザー向けコントロールはありませんが、サポート チケットを開いて、キャッシュ システム上の影響を受けるストレージ ターゲットに対して有効にするように要求できます。

次のステップ

この記事で対処されていない問題がある場合は、 サポートに問い合わせて 専門家のサポートを受けてください。