Lsv3、Lasv3、Lsv2 シリーズの Linux VM 上でパフォーマンスを最適化する

  • [アーティクル]

注意

この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。

適用対象: ✔️ Linux VM ✔️ 均一スケール セット

Lsv3、Lasv3、Lsv2 シリーズの Azure 仮想マシン (Azure VM) は、幅広いアプリケーションや業界において、ローカル ストレージに高い I/O とスループットを必要とするさまざまなワークロードをサポートしています。 L シリーズは、Cassandra、MongoDB、Cloudera、Redis などのビッグ データ、SQL、NoSQL データベース、データ ウェアハウス、大規模トランザクション データベースに最適です。

Linux でのパートナーとの連携により、Azure Marketplace でさまざまなビルドが提供されています。 これらのビルドは、Lsv3、Lasv3、Lsv2 シリーズのパフォーマンス向けに最適化されています。 提供されているビルドには、次のバージョンとそれ以降が含まれています。

  • Ubuntu 16.04
  • RHEL 8.0 とクローン (CentOS、Rocky Linux、Alma Linux を含む)
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

この記事では、ワークロードとアプリケーションで VM の設計に応じた最大限のパフォーマンスを実現するためのヒントと推奨事項を紹介します。

AMD EPYC™ チップセットのアーキテクチャ

Lasv3 および Lsv2 シリーズの VM では、Zen マイクロアーキテクチャをベースとする AMD EPYC™ サーバー プロセッサを使用しています。 AMD は、オンダイ、オンパッケージ、マルチパッケージの通信に利用が期待できる自らの NUMA モデルのスケーラブルなインターコネクトとして、Infinity Fabric (IF) for EPYC™ を開発しました。 NUMA が多くダイが少ない AMD のアーキテクチャは、Intel の最新型モノリシックダイ プロセッサで採用されている QPI (Quick-Path Interconnect) と UPI (Ultra-Path Interconnect) に比べると、パフォーマンス面でメリットと課題のどちらももたらしうる可能性を秘めています。 メモリの帯域幅と待ち時間の制約の影響が実際にどれほどのものになるかは、実行中のワークロードの種類に応じて異なります。

パフォーマンス最大化のためのヒント

  • ワークロードのためにカスタムの Linux GuestOS をアップロードする場合には、高速ネットワークが既定でオフになります。 高速ネットワークを有効にする場合は、VM の作成時に有効にすると、最善のパフォーマンスが得られます。
  • パフォーマンスを最大限に高めるには、デバイスごとにディープ キューの深さを持つ複数のジョブを実行します。
  • アクティブなワークロードの最中に NVMe の管理者向けコマンド (NVMe の SMART 情報のクエリなど) と NVMe の I/O コマンドを混用することは避けてください。 Lsv3、Lasv3、Lsv2 NVMe デバイスは Hyper-V の NVMe Direct テクノロジを採用しており、NVMe の管理者向けコマンドが保留中の状態になると、"低速モード" に切り替わります。 そうなると、Lsv3、Lasv3、Lsv2 ユーザーに、NVMe の I/O パフォーマンスの大幅な低下が見られることがあります。
  • Lsv2 ユーザーには、アプリの NUMA アフィニティを決めるにあたり、データ ドライブ用 VM からのレポートに表示されるデバイスの NUMA 情報 (すべて 0) を信用しないことをお勧めします。 パフォーマンス向上のために、可能であればワークロードを複数の CPU に分散させることをお勧めします。
  • Lsv3、Lasv3、Lsv2 VM の NVMe デバイスの 1 組の I/O キュー ペアでサポートされるキューの深さは 1,024 です。 キューがいっぱいになり、パフォーマンスが低下する事態を防ぐため、Lsv3、Lasv3、Lsv2 ユーザーには (合成) ベンチマークのワークロードにおけるキューの深さを 1,024 以下にすることをお勧めします。
  • 最善のパフォーマンスが得られるのは、未加工 (パーティション分割をしておらず、ファイル システムがなく、RAID を構成していないなど) の各 NVMe デバイスに対して直接 I/O を実行したときであるという点にご注意ください。テスト セッションを開始する前に、それぞれの NVMe デバイスで blkdiscard を実行し、構成が既知のフレッシュまたはクリーンな状態になっていることを確認してください。 ベンチマーク中に最も安定したパフォーマンスを得るには、SNIA Solid State Storage Enterprise Performance Test Specification で定義されているように、テスト前に NVMe デバイスのすべてのLBA にランダム書き込みを 2 回発行して、NVMe デバイスを事前調整することを推奨します。

ローカルの NVMe ストレージを使用する

Lsv3、Lasv3、Lsv2 VM にある 1.92 TB NVMe ディスク上のローカル ストレージは、エフェメラル ストレージです。 VM の標準的な再起動処理が正常に実行されている間は、ローカル NVMe ディスクにあるデータが保持されます。 VM の再デプロイ、割り当て解除、または削除を行った場合には、NVMe 上にデータが保持されません。 他の問題が原因となって VM またはその VM が稼働しているハードウェアが正常な状態ではなくなった場合には、データが保持されません。 そのような場合は、以前のホストに存在するデータがすべて安全に消去されます。

計画メンテナンス業務の間などには、VM を別のホスト マシンに移行することが必要になることもあります。 Scheduled Events では、計画メンテナンス業務の予定やハードウェア障害の見込みを確認できます。 Scheduled Events を使用して、メンテナンス業務や回復業務の予定の最新情報を確認するようにしてください。

計画メンテナンス イベントの際に、空のローカル ディスクを備えた新しいホストに VM を作り直す必要が生じた場合には、データを同期し直す必要があります (繰り返しになりますが、以前のホストに存在するデータはすべて安全に消去されます)。 このシナリオは、Lsv3、Lasv3、Lsv2 シリーズの VM が現在、ローカル NVMe ディスク上のライブ マイグレーションをサポートしていないことによるものです。

計画メンテナンスには 2 つのモードがあります。

Standard VM の顧客コントロール型メンテナンス

  • 30 日の間に、VM が新しいホストに移行します。
  • Lsv3、Lasv3、Lsv2 ローカル ストレージのデータが失われる可能性があるので、イベントの前にデータのバックアップを作成しておくことをお勧めします。

自動メンテナンス

  • お客様が顧客コントロール型メンテナンスを実施しなかった場合や、緊急処置 (セキュリティに関するゼロデイ イベントなど) が原因となって発生します。
  • お客様のデータの保持を目的としたものですが、VM のフリーズや再起動が発生するリスクがわずかに存在します。
  • Lsv3、Lasv3、Lsv2 ローカル ストレージのデータが失われる可能性があるので、イベントの前にデータのバックアップを作成しておくことをお勧めします。

サービス イベントが近づいてきたら、コントロール型のメンテナンス プロセスを使って更新に最も都合の良いタイミングを選択してください。 イベントの前には、Premium ストレージ内のデータをバックアップしておいてください。 メンテナンス イベントが完了した後は、新しい Lsv3、Lasv3、および Lsv2 VM のローカル NVMe ストレージにデータを戻すことができます。

ローカルの NVMe ディスクにあるデータが保持されるシナリオは次のとおりです。

  • VM が正常な状態で稼働している。
  • VM が (お客様または Azure により) 再起動中になっている。
  • VM が一時停止している (割り当て解除せずに停止した)。
  • ほとんどの計画メンテナンス サービス操作。

お客様の保護のためにデータが安全に消去されるシナリオは次のとおりです。

  • (お客様が) VM を再デプロイ、停止 (割り当て解除)、または削除した。
  • ハードウェアの問題が原因で VM が異常な状態になっており、別のノードに復旧させる必要がある。
  • 保守作業のために VM を別のホストに割り当て直す必要がある少数の計画メンテナンス サービス業務。

よく寄せられる質問

これらのシリーズに関してよく寄せられる質問は、次のとおりです。

L シリーズの VM のデプロイを始めるにはどうすればよいでしょうか?

他の VM と同じく、ポータル、Azure CLI、PowerShell のいずれかを使って VM を作成します。

1 つの NVMe ディスクに障害が発生すると、そのホストにある VM すべてに障害が起こるのでしょうか?

ハードウェア ノードでディスクの障害が検出された場合には、ハードウェアの状態が障害の存在を示すものに変わります。 このような問題が発生すると、そのノードにある VM はいずれも割り当てが自動的に解除され、別の正常なノードに移行します。 Lsv3、Lasv3、Lsv2 シリーズの VM の場合、この問題は、障害が発生したノード上のお客様のデータも安全に消去されることを意味します。 お客様は、新しいノードでデータを再作成する必要があります。

blk_mq の設定には変更が必要ですか?

NVMe デバイスの場合、RHEL/CentOS 7.x により自動的に blk-mq が使用されます。 構成の変更や設定は必要ありません。

次のステップ

Azure 上でストレージのパフォーマンスを高めるために最適化されたすべての VM の仕様を確認してください。