Azure で Linux VM を最適化する

2016-09-06

Linux 仮想マシン (VM) の作成は、コマンドラインまたはポータルから簡単に行うことができます。このチュートリアルでは、Microsoft Azure プラットフォームでのパフォーマンスを最適化するように設定する方法について説明します。このトピックでは Ubuntu Server VM を使用しますが、独自のイメージをテンプレートとして使用して Linux 仮想マシンを作成することもできます。

[前提条件]

このトピックでは、既に動作している Azure サブスクリプション (無料試用版サインアップ) があり、VM を Azure サブスクリプションに既にプロビジョニングしていることを前提としています。 VM を作成する前に、az login を使用して最新の Azure CLI がインストールされ、Azure サブスクリプションにログインしていることを確認してください。

Azure OS ディスク

Azure で Linux VM を作成すると、2 つのディスクが関連付けられます。 /dev/sda は OS ディスク、 /dev/sdb は一時ディスクです。オペレーティングシステムを除くすべてのメイン OS ディスク (/dev/sda) は、VM の高速起動時間に最適化されており、ワークロードに対して優れたパフォーマンスを提供しないため、使用しないでください。 1 つ以上のディスクを VM に接続して、データの永続的で最適化されたストレージを取得する必要があります。

サイズとパフォーマンスのターゲット用のディスクの追加

VM のサイズに基づいて、A シリーズに最大 16 個の追加ディスク、D シリーズの 32 個のディスク、G シリーズマシン上の 64 個のディスク (それぞれ最大 32 TB のサイズ) を接続できます。容量と IOps の要件に応じて、必要に応じてディスクを追加します。各ディスクのパフォーマンス目標は、Standard Storage の場合は 500 IOps、Premium Storage の場合はディスクあたり最大 20,000 IOps です。

キャッシュ設定が ReadOnly または None に設定されている Premium Storage ディスクで最高の IOps を実現するには、Linux でファイルシステムをマウントするときに バリア を無効にする必要があります。 Premium Storage でサポートされるディスクへの書き込みはこれらのキャッシュ設定に対して永続的であるため、バリアは必要ありません。

reiserFS を使用する場合は、マウントオプション barrier=noneを使用してバリアを無効にします (バリアを有効にするには、barrier=flushを使用します)。
ext3/ext4 を使用する場合は、マウントオプション barrier=0を使用してバリアを無効にします (バリアを有効にするには、barrier=1を使用します)。
XFS を使用する場合は、マウントオプション nobarrierを使用してバリアを無効にします (バリアを有効にするには、オプション barrierを使用します)。

アンマネージドストレージアカウントに関する考慮事項

Azure CLI を使用して VM を作成する場合の既定のアクションは、Azure Managed Disks を使用することです。これらのディスクは Azure プラットフォームによって処理され、ディスクを格納するための準備や場所は必要ありません。非管理対象ディスクにはストレージアカウントが必要であり、パフォーマンスに関する追加の考慮事項があります。マネージドディスクの詳細については、「Azure Managed Disks の概要」をご覧ください。次のセクションでは、非管理対象ディスクを使用する場合にのみ、パフォーマンスに関する考慮事項について説明します。ここでも、既定で推奨されるストレージソリューションは、マネージドディスクを使用することです。

非管理対象ディスクを含む VM を作成する場合は、VM と同じリージョンに存在するストレージアカウントからディスクをアタッチして、近接性を確保し、ネットワーク待機時間を最小限に抑えてください。各 Standard ストレージアカウントには、最大 20,000 個の IOps と 500 TB のサイズ容量があります。この制限は、OS ディスクと作成するデータディスクの両方を含め、頻繁に使用されるディスクがおよそ40個に相当します。 Premium Storage アカウントの場合、最大 IOps 制限はありませんが、サイズ制限は 32 TB です。

高い IOps ワークロードを処理し、ディスクに Standard Storage を選択した場合は、Standard Storage アカウントの 20,000 IOps の制限に達していないことを確認するために、複数のストレージアカウントにディスクを分割する必要がある場合があります。 VM には、最適な構成を実現するために、さまざまなストレージアカウントとストレージアカウントの種類間のディスクの組み合わせを含めることができます。

VM の一時ドライブ

既定では、VM を作成すると、Azure によって OS ディスク (/dev/sda) と一時ディスク (/dev/sdb) が提供されます。追加するすべてのディスクは 、/dev/sdc、 /dev/sdd、 /dev/sde などとして表示されます。一時ディスク (/dev/sdb) 上のすべてのデータは永続的ではなく、VM のサイズ変更、再デプロイ、メンテナンスなどの特定のイベントによって VM の再起動が強制されると失われる可能性があります。一時ディスクのサイズと種類は、デプロイ時に選択した VM サイズに関連します。一時ドライブのすべての Premium サイズ VM (DS、G、および DS_V2 シリーズ) は、最大 48,000 個の IOps のパフォーマンスを向上させるために、ローカル SSD によってサポートされます。

Linux スワップパーティション

Azure VM が Ubuntu または CoreOS イメージからの場合は、CustomData を使用して cloud-config を cloud-init に送信できます。 cloud-init を使用するカスタム Linux イメージをアップロードした場合は、cloud-init を使用してスワップパーティションも構成します。

/etc/waagent.conf ファイルを使用して、cloud-init によってプロビジョニングおよびサポートされているすべてのイメージのスワップを管理することはできません。イメージの完全な一覧については、「 cloud-init の使用」を参照してください。

これらのイメージのスワップを管理する最も簡単な方法は、次の手順を完了することです。

/var/lib/cloud/scripts/per-boot フォルダーに、create_swapfile.shという名前のファイルを作成します。

$ sudo touch /var/lib/cloud/scripts/per-boot/create_swapfile.sh
次の行をファイルに追加します。

$ sudo vi /var/lib/cloud/scripts/per-boot/create_swapfile.sh
```
#!/bin/sh
if [ ! -f '/mnt/swapfile' ]; then
fallocate --length 2GiB /mnt/swapfile
chmod 600 /mnt/swapfile
mkswap /mnt/swapfile
swapon /mnt/swapfile
swapon -a ; fi
```
注

必要に応じて、リソースディスク内の使用可能な領域に基づいて値を変更できます。これは、使用されている VM サイズによって異なります。
ファイルを実行可能にする:

$ sudo chmod +x /var/lib/cloud/scripts/per-boot/create_swapfile.sh
スワップファイルを作成するには、最後の手順の直後にスクリプトを実行します。

$ sudo /var/lib/cloud/scripts/per-boot/./create_swapfile.sh

cloud-init がサポートされていないイメージの場合、Azure Marketplace からデプロイされた VM イメージには、VM Linux エージェントが OS と統合されています。このエージェントを使用すると、VM はさまざまな Azure サービスと対話できます。 Azure Marketplace から標準イメージをデプロイした場合、Linux スワップファイルの設定を正しく構成するには、次の操作を行う必要があります。

/etc/waagent.conf ファイル内の 2 つのエントリを見つけて変更します。専用スワップファイルの存在とスワップファイルのサイズを制御します。確認する必要があるパラメーターは ResourceDisk.EnableSwap と ResourceDisk.SwapSizeMB です。

適切に有効になっているディスクとマウントされたスワップファイルを有効にするには、パラメーターに次の設定があることを確認します。

ResourceDisk.EnableSwap=Y
ResourceDisk.SwapSizeMB={必要に応じたMBサイズ}

変更を行ったら、waagent を再起動するか、Linux VM を再起動してそれらの変更を反映する必要があります。 free コマンドを使用して空き領域を表示すると、変更が実装され、スワップファイルが作成されたことがわかっています。次の例では、 waagent.conf ファイルを変更した結果、512 MB のスワップファイルが作成されています。

azuseruser@myVM:~$ free
            total       used       free     shared    buffers     cached
Mem:       3525156     804168    2720988        408       8428     633192
-/+ buffers/cache:     162548    3362608
Swap:       524284          0     524284

Premium Storage の I/O スケジューリングアルゴリズム

2.6.18 Linux カーネルでは、既定の I/O スケジューリングアルゴリズムが Deadline から CFQ (完全に公平なキューアルゴリズム) に変更されました。ランダムアクセス I/O パターンの場合、CFQ と Deadline の間のパフォーマンスの違いはごくわずかです。ディスク I/O パターンが主にシーケンシャルである SSD ベースのディスクの場合、NOOP または Deadline アルゴリズムに切り替えると、I/O パフォーマンスが向上します。

現在の I/O スケジューラを表示する

次のコマンドを使用します。

cat /sys/block/sda/queue/scheduler

現在のスケジューラを示す次の出力が表示されます。

noop [deadline] cfq

I/O スケジューリングアルゴリズムの現在のデバイス (/dev/sda) を変更する

次のコマンドを使用します。

azureuser@myVM:~$ sudo su -
root@myVM:~# echo "noop" >/sys/block/sda/queue/scheduler
root@myVM:~# sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"/g' /etc/default/grub
root@myVM:~# update-grub

注

/dev/sda だけにこの設定を適用することは役に立ちません。シーケンシャル I/O が I/O パターンを支配するすべてのデータディスクに設定します。

grub.cfg が正常に再構築され、既定のスケジューラが NOOP に更新されたことを示す次の出力が表示されます。

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.13.0-34-generic
Found initrd image: /boot/initrd.img-3.13.0-34-generic
Found linux image: /boot/vmlinuz-3.13.0-32-generic
Found initrd image: /boot/initrd.img-3.13.0-32-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
done

Red Hat 配布ファミリの場合は、次のコマンドのみが必要です。

echo 'echo noop >/sys/block/sda/queue/scheduler' >> /etc/rc.local

Azure でチューニングされたカーネルを含む Ubuntu 18.04 では、マルチキュー I/O スケジューラが使用されます。そのシナリオでは、noopではなく、noneが適切な選択です。詳細については、「 Ubuntu I/O スケジューラ」を参照してください。

ソフトウェア RAID を使用してより高い I/Op を実現する

ワークロードで 1 つのディスクで提供できる数よりも多くの IOps が必要な場合は、複数のディスクのソフトウェア RAID 構成を使用する必要があります。 Azure は既にローカルファブリックレイヤーでディスクの回復性を実行しているため、RAID-0 ストライピング構成から最高レベルのパフォーマンスを実現します。ドライブのパーティション分割、フォーマット、マウントを行う前に、Azure 環境でディスクをプロビジョニングして作成し、Linux VM に接続します。 Azure の Linux VM でのソフトウェア RAID セットアップの構成の詳細については、 Linux でのソフトウェア RAID の構成に関する ドキュメントを参照してください。

従来の RAID 構成の代わりに、論理ボリュームマネージャー (LVM) をインストールして、多数の物理ディスクを 1 つのストライピングされた論理ストレージボリュームに構成することもできます。この構成では、読み取りと書き込みがボリュームグループに含まれる複数のディスク (RAID0 と同様) に分散されます。パフォーマンス上の理由から、接続されているすべてのデータディスクを読み取りと書き込みで利用できるように、論理ボリュームをストライピングすることが必要になる可能性があります。 Azure の Linux VM でストライプ論理ボリュームを構成する方法の詳細については、Azure での Linux VM での LVM の構成に関する ドキュメントを参照してください。

次のステップ

すべての最適化の説明と同様に、変更の影響を測定するには、各変更の前後にテストを実行する必要があります。最適化は、環境内の異なるマシン間で異なる結果を持つ段階的なプロセスです。 1 つの構成で機能するものは、他の構成では機能しない場合があります。

その他のリソースへの便利なリンクを次に示します。

次の方法で共有