ネットワーク ファイル システム (NFS) 3.0 プロトコルを使用して Blob Storage をマウントする
この記事では、Linux ベースの Azure 仮想マシン (VM) またはネットワーク ファイル システム (NFS) 3.0 プロトコルを使用してオンプレミスで実行される Linux システムから Azure Blob Storage にコンテナーをマウントする方法について説明します。 Blob Storage での NFS 3.0 プロトコル サポートの詳細については、「Azure Blob Storage でのネットワーク ファイル システム (NFS) 3.0 プロトコル サポート」を参照してください。
手順 1:Azure の仮想ネットワークを作成する
お使いのストレージ アカウントが、仮想ネットワーク内に含まれている必要があります。 仮想ネットワークにより、クライアントはストレージ アカウントに安全に接続できます。 Azure Virtual Network の詳細と、仮想ネットワークの作成方法については、「Virtual Network のドキュメント」を参照してください。
Note
同じ仮想ネットワーク内のクライアントは、アカウントにコンテナーをマウントできます。 オンプレミス ネットワークで実行されているクライアントからコンテナーをマウントすることもできますが、最初にオンプレミス ネットワークを仮想ネットワークに接続する必要があります。 詳細については「サポートされているネットワーク接続」を参照してください。
手順 2: ネットワーク セキュリティの構成
現在、ストレージ アカウントのデータをセキュリティで保護する唯一の方法は、仮想ネットワークと、その他のネットワーク セキュリティ設定を使用することです。 「BLOB ストレージのネットワーク セキュリティに関する推奨事項」を参照してください。
アカウント キーの認可、Microsoft Entra セキュリティ、アクセス制御リスト (ACL) など、データのセキュリティ保護に使用されるその他のツールは、NFS 3.0 要求の認可には使用できません。 実際、名前付きユーザーまたはグループのエントリを ACL、BLOB またはディレクトリに追加する場合、そのファイルは非ルート ユーザーのクライアントでアクセスできなくなります。 クライアント上の非ルート ユーザーのアクセスを復元するには、そのエントリを削除する必要があります。
重要
NFS 3.0 プロトコルでは、ポート 111 および 2048 が使用されます。 オンプレミスのネットワークから接続している場合は、クライアントがこれらのポートを介した発信を許可していることを確認します。 特定の VNet へのアクセスを許可している場合は、それらの VNet に関連付けられているネットワーク セキュリティ グループに、それらのポートを介した受信通信をブロックするセキュリティ規則が含まれていないことを確認します。
手順 3: ストレージ アカウントの作成と構成
NFS 3.0 を使用してコンテナーをマウントするには、ストレージ アカウントを作成する必要があります。 既存のアカウントを有効にすることはできません。
NFS 3.0 プロトコルは、Standard の汎用 v2 ストレージ アカウントと、Premium のブロック BLOB ストレージ アカウントでサポートされています。 これらのストレージ アカウントの種類について詳しくは、「ストレージ アカウントの概要」を参照してください。
アカウントを構成するには、以下の値を選択します。
| 設定 | Premium パフォーマンス | Standard パフォーマンス |
|---|---|---|
| 場所 | 利用可能なすべてのリージョン | 利用可能なすべてのリージョン |
| パフォーマンス | Premium | Standard |
| アカウントの種類 | BlockBlobStorage | 汎用 v2 |
| レプリケーション | ローカル冗長ストレージ (LRS)、ゾーン冗長ストレージ (ZRS) | ローカル冗長ストレージ (LRS)、ゾーン冗長ストレージ (ZRS) |
| 接続方法 | パブリック エンドポイント (選択されたネットワーク) またはプライベート エンドポイント | パブリック エンドポイント (選択されたネットワーク) またはプライベート エンドポイント |
| 階層型名前空間 | Enabled | Enabled |
| NFS V3 | Enabled | Enabled |
他のすべての設定については、既定値をそのまま使用できます。
手順 4: コンテナーを作成する
次のいずれかのツールまたは SDK を使用して、ストレージ アカウントにコンテナーを作成します。
| ツール | SDK |
|---|---|
| Azure Portal | .NET |
| AzCopy | Java |
| PowerShell | Python |
| Azure CLI | JavaScript |
| REST |
注意
既定では、新しいコンテナーのルート スカッシュ オプションは [ルート スカッシュなし] です。 しかし、[ルート スカッシュ] または [すべてのスカッシュ] に変更できます。 これらのスカッシュ オプションの詳細については、オペレーティング システムのドキュメントを参照してください。
次の図は、Azure portal で表示されるスカッシュ オプションを示しています。
手順 5: AZNFS マウント ヘルパー パッケージをインストールする
AZNFS マウント ヘルパー パッケージは、エンドポイントの IP アドレスが変更された場合でも、Linux NFS クライアントが Azure Blob NFS 共有に確実にアクセスするのに役立ちます。 このパッケージは、マウントされた共有のエンドポイント IP アドレスへの変更を監視する、aznfswatchdog と呼ばれるバックグラウンド ジョブを実行します。 変更が検出された場合、このバックグラウンド ジョブは宛先ネットワーク アドレス変換 (DNAT) ルールを更新します。 詳細については、「AZNFS マウント ヘルパー」を参照してください。
AZNFS マウント ヘルパー パッケージがクライアントにインストールされているかどうかを確認します。
systemctl is-active --quiet aznfswatchdog && echo -e "\nAZNFS mounthelper is installed! \n"パッケージがインストールされている場合は、メッセージ
AZNFS mounthelper is installed!が表示されます。パッケージがまだインストールされていない場合は、次のコマンドを使用してインストールします。
wget -O - -q https://github.com/Azure/AZNFS-mount/releases/latest/download/aznfs_install.sh | bashNote
AZNFS は、次の Linux ディストリビューションでサポートされています。
- Ubuntu (18.04 LTS、20.04 LTS、22.04 LTS)
- RedHat7、RedHat8、RedHat9
- Rocky8、Rocky9
- SUSE (SLES 15)
手順 6: コンテナーをマウントする
Linux システム上にディレクトリを作成してから、コンテナーをストレージ アカウントにマウントします。
Linux システム上にディレクトリを作成します。
mkdir -p /nfsdata次のいずれかの方法を使用して、コンテナーをマウントします。 どちらの方法でも、
<storage-account-name>プレースホルダーをストレージ アカウントの名前に置き換え、<container-name>をコンテナーの名前に置き換えます。再起動時に共有情報を自動的にマウントするには、次のようにします。
次の行を追加して、/etc/fstab ファイルにエントリを作成します。
<storage-account-name>.blob.core.windows.net:/<storage-account-name>/<container-name> /nfsdata aznfs defaults,sec=sys,vers=3,nolock,proto=tcp,nofail,_netdev 0 0次のコマンドを実行して、/etc/fstab エントリを直ちに処理し、前述のパスのマウントを試みます。
mount /nfsdata
再起動後に消される一時的なマウントを実行する場合は、次のコマンドを実行します。
mount -t aznfs -o sec=sys,vers=3,nolock,proto=tcp <storage-account-name>.blob.core.windows.net:/<storage-account-name>/<container-name> /nfsdataヒント
-t aznfsマウント オプションを使用すると、マウント後にエンドポイント IP が変更された場合でも、NFS クライアントは常にストレージ エンドポイントに正しく接続されたままになります。-t nfsマウント オプションを使用してマウントされた NFS 共有は、そのエンドポイントの IP アドレスが変更されると、ストレージ エンドポイントから切断される可能性があります。mount コマンドでは、その他の省略可能なパラメーターを使用できます。 これらのパラメーターは、主にクライアント側の動作に影響します。
sysは、secオプションで現在サポートされている唯一の値です。重要
nconnectマウント オプションは、Azure nconnect サポートがあるクライアントでのみ機能します。 サポートされていないクライアントでnconnectオプションを使用すると、スループットが低下し、コマンドがタイムアウトするか、正しく動作しません。 クライアントに Azure nconnect サポートがあることを確認する方法の詳細については、TCP 接続の数を増やす方法に関する記事を参照してください。
一般的なエラーを解決する
| エラー | 原因/解決方法 |
|---|---|
Access denied by server while mounting |
サポートされているサブネット内でクライアントが実行されていることを確認します。 サポートされているネットワークの場所に関するページを参照してください。 |
No such file or directory |
mount コマンドとそのパラメーターは、コピーと貼り付けではなく、直接ターミナルに入力するようにしてください。 別のアプリケーションからこのコマンドの一部をコピーしてターミナルに貼り付けると、貼り付けた情報の非表示の文字が原因でこのエラーが発生することがあります。 アカウントが NFS 3.0 に対応していない場合にも、このエラーが表示されることがあります。 |
Permission denied |
新しく作成される NFS 3.0 コンテナーの既定のモードは 0750 です。 ルート以外のユーザーはボリュームにアクセスできません。 ルート以外のユーザーからのアクセスが必要な場合は、ルート ユーザーがモードを 0755 に変更する必要があります。 サンプル コマンド: sudo chmod 0755 /nfsdata |
EINVAL ("Invalid argument") |
このエラーは、クライアントが次の操作を試みたときに発生する可能性があります。 |
EROFS ("Read-only file system") |
このエラーは、クライアントが次の操作を試みたときに発生する可能性があります。 |
NFS3ERR_IO/EIO ("Input/output error") |
このエラーは、クライアントがアーカイブ アクセス層に格納されている BLOB への読み取り、書き込み、または属性の設定を試みた場合に発生する可能性があります。 |
OperationNotSupportedOnSymLink エラー |
このエラーは、Blob Storage または Azure Data Lake Storage API を介した書き込み操作中に返される可能性があります。 これらの API を使用して、NFS 3.0 を使用して作成されたシンボリック リンクへの書き込みや削除を行うことはできません。 シンボリック リンクを操作する際は、必ず NFS 3.0 エンドポイントを使用してください。 |
mount: /nfsdata: bad option; |
sudo apt install nfs-common を使用して NFS ヘルパー プログラムをインストールします。 |
Connection Timed Out |
クライアントがポート 111 と 2048 経由の送信通信を許可していることを確認します。 NFS 3.0 プロトコルでは、これらのポートが使用されます。 Data Lake Storage エンドポイントではなく、必ず Blob service エンドポイントを使ってストレージ アカウントをマウントします。 |
AZNFS マウント ヘルパーの制限事項とトラブルシューティング
「AZNFS マウント ヘルパー」を参照してください。