Azure StorageでNFS 3.0の利用がプレビューになったのでお試しした

2020-08-10

azure

はじめに

2020年7月末にAzure StorageでNFS 3.0がプレビューで利用可能になったので試しました。

https://azure.microsoft.com/ja-jp/blog/nfs-30-support-for-azure-blob-storage-is-now-in-preview/

日本語の案内は以下。

https://docs.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support

手順としては以下のURLにあるとおりでやればOKなのですが、まあ自分メモも兼ねてエントリします。

https://docs.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support-how-to

プレビュー利用登録

Cloud Shell(PowerShell)から、以下のコマンドでプレビュー登録します。念の為Microsoft.Storageのリソースプロバイダも。

PS C:\> Register-AzProviderFeature -FeatureName AllowNFSV3 -ProviderNamespace Microsoft.Storage PS C:\> Register-AzProviderFeature -FeatureName PremiumHns -ProviderNamespace Microsoft.Storage PS C:\> Register-AzResourceProvider -ProviderNamespace Microsoft.Storage

私の場合は30分ほどでしょうか、待つとRegisterredになりました。

PS C:\> Get-AzProviderFeature -ProviderNamespace Microsoft.Storage -FeatureName AllowNFSV3

FeatureName ProviderName RegistrationState ———– ———— —————– AllowNFSV3 Microsoft.Storage Registered

PS C:\> Get-AzProviderFeature -ProviderNamespace Microsoft.Storage -FeatureName PremiumHns

FeatureName ProviderName RegistrationState ———– ———— —————– PremiumHns Microsoft.Storage Registered

リソースグループと仮想ネットワーク、仮想マシンの作成

NFS 3.0のプレビューの利用は、米国東部、米国中部、カナダ中部のリージョンのみとなりますので、今回は米国東部で確認しました。

リソースグループ

適当な名称で作成します。

仮想ネットワーク

適当な名称で作成します。リージョンは米国東部を選択。

仮想マシン

先に作成した仮想ネットワークのdefaultサブネットにUbuntuをデプロイしました。

ストレージアカウントの作成

基本タブではリージョンに「米国東部」、パフォーマンスはPremiumで、アカウントの種類には「BlockBlobStorage」を選択します。

ネットワークタブでは、NFS 3.0を利用する場合には必ずパブリックエンドポイントか、プライベートエンドポイントを選択する必要があります。今回はパブリックエンドポイントで、事前に作成した仮想ネットワークのサブネットを選択します。

データ保護タブはデフォルトのままでとりあえずはOKでしょう。

詳細タブで、「階層構造の名前空間」を有効にして、「NFS v3」も有効にします。

この設定はNFSのPreview登録が済んでいないと選択出来ないので注意です。(あとリージョンが誤っているとか)

最後に作成します。

NFSマウントポイント用のコンテナ作成

作成されたストレージアカウントは実はData Lake Storageと言われているものですね。こちらのコンテナーメニュから新しいコンテナーを作成します。この名前がこのあと仮想マシンからマウントするときの共有名になります。今回は「nfstest」という名前で作成しました。

Linuxからマウント

今回はUbuntu 18.04を使ったのですが、nfsクライアントが入っていなかったので、aptでサクッと導入して以下のコマンドイメージでマウントを確認しました。

XXXXXの部分は先に作成したストレージアカウント名となります。

$ sudo apt -y install nfs-common $ sudo mkdir /mnt/nfstest $ sudo mount -o sec=sys,vers=3,nolock,proto=tcp XXXXXX.blob.core.windows.net:/XXXXXX/nfstest /mnt/nfstest

dfコマンドで確認すると、ちゃんとマウントされていますね。空き容量が200T以上もあるなんて胸熱です。

$ df -h Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 391M 664K 391M 1% /run /dev/sdb1 29G 1.4G 28G 5% / tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup /dev/sdb15 105M 3.6M 101M 4% /boot/efi /dev/sda1 16G 45M 15G 1% /mnt tmpfs 391M 0 391M 0% /run/user/1000 XXXXXX.blob.core.windows.net:/XXXXXX/nfstest 256T 0 256T 0% /mnt/nfstest

linux側からファイルを書き込むと、ちゃんとAzureポータル上にも反映されます。

$ touch /mnt/nfstest/hoe

オンプレミスからインターネット越しにマウントできないか？

NFS 3.0はユーザ認証なしにマウントできてしまうため、興味本位でStorage AccountのFirewallルールの口を開けて、オンプレ環境のRaspberry Piからマウントできないか試しました。

設定としては、Storage Accountのファイアウォール規則にオンプレのWAN側IPアドレスを指定する。

では、自宅のRaspberry Piから接続してみましょう。

mount -o sec=sys,vers=3,nolock,proto=tcp XXXXXX.blob.core.windows.net:/XXXXXX/nf stest /mnt/nfstest mount.nfs: Connection reset by peer

はい、ダメですね。相手(Azure)側から拒否されたもようです。
通信経路の暗号化もされていないので、仮に繋げられたとしても怖くて使えないですよね。

おわりに

オンプレミスとの間をVPNやExpressRoute経由にすれば、ちゃんと利用できるみたいですので、こちらは今後試してみます。

とりあえず、ストレージ共有の仕組みが従来のAzure Filesの他、Azure Shared Disks、Azure NFSと選択肢が増えているのは良いことですね。

それぞれの特性や性能、価格を見ながらベストな選択をしていく必要があると感じます。