web-dev-qa-db-ja.com

LinuxにAzureファイル共有をマウントするとパフォーマンスが低下するVM

複数のVMで同時にマウントできるネットワークファイルシステムの形式として Azure File Service を実験しました。これは、通常のAzure仮想ハードディスクでは不可能なことです。 Azure VHDは、一度に1つのVMにのみ接続できます。

ただし、SMBプロトコルを介してAzureファイル共有をマウントすると、書き込みパフォーマンスが非常に低くなります。

セットアップは次のとおりです。Canonical:UbuntuServer:16.04-LTS:latest VMでStandard_DS2 VMを開始しました。

ブートプロセスが完了したら、 公式の説明 に従って、SMB経由でAzure File Shareをマウントします。

Sudo apt-get install cifs-utils
Sudo mkdir -p /mnt/Azure
Sudo mount -t cifs //<storageaccount>.file.core.windows.net/<file-share-name> /mnt/Azure/ -o vers=3.0,username=<storageaccount>,password=<base64-encoded>,dir_mode=0777,file_mode=0777,serverino

次に、この単純な書き込みパフォーマンステストを実行します。

time for i in $(seq 1 500); do echo "hello!" > /mnt/Azure/hello.txt; done

real    0m20.673s
user    0m0.032s
sys     0m0.124s

ご覧のとおり、完了するまでに20秒以上かかります。比較として、ローカルマシン（SSDドライブを使用）で同じテストを実行すると、次の数値が表示されます。

time for i in $(seq 1 500); do echo "hello!" > hello.txt; done

real    0m0.031s
user    0m0.004s
sys     0m0.024s

つまり、約30milli秒で完了します。したがって、Azure File Shareに対して実行する場合、パフォーマンスペナルティ係数はほぼ1000になります。

そのようなパフォーマンスの数値は期待されているのでしょうか、それとも何かが足りないのでしょうか？

performanceazurefilesystems
3
hal

はい。

ローカルディスクとAzureファイルは基本的にネットワークストレージですが、後者はハードウェアに直接アクセスする代わりにI/OAPIを使用することに注意してください。レイテンシーはずっと高くなります。簡単な数学を試してみましょう：

500件のリクエストを行っており、接続を開いたり閉じたりするたびに、次のようになります。

500リクエスト/20.673.sec = 24.18 Req/sec

24.18/1000 = 0,02418sで各リクエストを完了します。これは素晴らしいことです。

少数または多数のファイルに対するパフォーマンスが必要な場合、Azure File Storageはユースケースに適していません。理論的には、1000 IOPSと60MB /秒を達成できます。

また、SMB/CIFSは小さなファイルの処理に非常に時間がかかります。

1
Bruno Faria

これが大きな違いのように見えるので、これが問題の全体であるかどうかはわかりませんが、覚えておいてください。

  1. Azure File Storageは標準のストレージであり、プレミアムではないため、すべて回転ディスクであり、SSDはありません。SSDよりも常に低速になります。
  2. あなたは今ネットワークを横切って走っています、それは同様にいくらかの時間を追加します。サイズの異なるVMには制限が異なり、D2は約1.5Gb/sに制限されます。
1
Sam Cogan