Lsv2 シリーズの仮想マシン上でパフォーマンスを最適化するOptimize performance on the Lsv2-series virtual machines

Lsv2 シリーズの仮想マシンは、幅広いアプリケーションや業界において、ローカル ストレージに高い I/O とスループットを必要とするさまざまなワークロードをサポートしています。Lsv2-series virtual machines support a variety of workloads that need high I/O and throughput on local storage across a wide range of applications and industries. Lsv2 シリーズは、Cassandra、MongoDB、Cloudera、Redis などのビッグ データ、SQL、NoSQL データベース、データ ウェアハウス、大規模トランザクション データベースに最適です。The Lsv2-series is ideal for Big Data, SQL, NoSQL databases, data warehousing and large transactional databases, including Cassandra, MongoDB, Cloudera, and Redis.

Lsv2 シリーズの仮想マシン (VM) の設計は、AMD EPYC™ 7551 プロセッサを最大限活用し、プロセッサ、メモリ、NVMe デバイス、VM の間で最善のパフォーマンスを実現できるようになっています。The design of the Lsv2-series Virtual Machines (VMs) maximizes the AMD EPYC™ 7551 processor to provide the best performance between the processor, memory, NVMe devices, and the VMs. Linux のパートナーと協力することで、Lsv2 シリーズのパフォーマンス向けに最適化されたいくかつのビルドを Azure Marketplace で入手できます。現在、以下のものがあります。Working with partners in Linux, several builds are available Azure Marketplace that are optimized for Lsv2-series performance and currently include:

  • Ubuntu 18.04Ubuntu 18.04
  • Ubuntu 16.04Ubuntu 16.04
  • RHEL 8.0RHEL 8.0
  • Debian 9Debian 9
  • Debian 10Debian 10

この記事では、ワークロードとアプリケーションで VM の設計に応じた最大限のパフォーマンスを実現するためのヒントと推奨事項を紹介します。This article provides tips and suggestions to ensure your workloads and applications achieve the maximum performance designed into the VMs. このページに掲載した情報は、最適化済みの Lsv2 イメージが Azure Marketplace に追加されるのに応じて随時更新していく予定です。The information on this page will be continuously updated as more Lsv2 optimized images are added to the Azure Marketplace.

AMD EYPC™ チップセットのアーキテクチャAMD EYPC™ chipset architecture

Lsv2 シリーズの VM では、Zen マイクロアーキテクチャをベースとする AMD EYPC™ サーバー プロセッサを使用しています。Lsv2-series VMs use AMD EYPC™ server processors based on the Zen microarchitecture. AMD は、オンダイ、オンパッケージ、マルチパッケージの通信に利用が期待できる自らの NUMA モデルのスケーラブルなインターコネクトとして、Infinity Fabric (IF) for EYPC™ を開発しました。AMD developed Infinity Fabric (IF) for EYPC™ as scalable interconnect for its NUMA model that could be used for on-die, on-package, and multi-package communications. NUMA が多くダイが少ない AMD のアーキテクチャは、Intel の最新型モノリシックダイ プロセッサで採用されている QPI (Quick-Path Interconnect) と UPI (Ultra-Path Interconnect) に比べると、パフォーマンス面でメリットと課題のどちらももたらしうる可能性を秘めています。Compared with QPI (Quick-Path Interconnect) and UPI (Ultra-Path Interconnect) used on Intel modern monolithic-die processors, AMD’s many-NUMA small-die architecture may bring both performance benefits as well as challenges. メモリの帯域幅と待ち時間の制約の影響が実際にどれほどのものになるかは、実行するワークロードの種類に応じて異なります。The actual impact of memory bandwidth and latency constraints could vary depending on the type of workloads running.

パフォーマンス最大化のためのヒントTips to maximize performance

  • ワークロードのためにカスタムの Linux GuestOS をアップロードする場合には、高速ネットワークが既定でオフになっていることに注意してください。If you are uploading a custom Linux GuestOS for your workload, note that Accelerated Networking will be OFF by default. 高速ネットワークを有効にする場合は、VM の作成時に有効にすると、最善のパフォーマンスが得られます。If you intend to enable Accelerated Networking, enable it at the time of VM creation for best performance.

  • Lsv2 シリーズ VM が稼働するハードウェアでは、I/O キュー ペア (QP) を 8 組備えた NVMe デバイスを使用しています。The hardware that powers the Lsv2-series VMs utilizes NVMe devices with eight I/O Queue Pairs (QP)s. NVMe デバイスの I/O キューはいずれも、実際には送信キューと完了キューがペアになっています。Every NVMe device I/O queue is actually a pair: a submission queue and a completion queue. NVMe ドライバーは、ラウンド ロビン方式のスケジュールに基づいて I/O を分散させ、この 8 組の I/O QP の利用を最適化するように設定してあります。The NVMe driver is set up to optimize the utilization of these eight I/O QPs by distributing I/O’s in a round robin schedule. 最大限のパフォーマンスを実現するためには、デバイスごとに釣り合いの取れたジョブを 8 件実行するようにしてください。To gain max performance, run eight jobs per device to match.

  • アクティブなワークロードの最中に NVMe の管理者向けコマンド (NVMe の SMART 情報のクエリなど) と NVMe の I/O コマンドを混用することは避けてください。Avoid mixing NVMe admin commands (for example, NVMe SMART info query, etc.) with NVMe I/O commands during active workloads. Lsv2 NVMe デバイスは Hyper-V の NVMe Direct テクノロジを採用しており、NVMe の管理者向けコマンドが保留中の状態になると、"低速モード" に切り替わります。Lsv2 NVMe devices are backed by Hyper-V NVMe Direct technology, which switches into “slow mode” whenever any NVMe admin commands are pending. このような事態が発生した場合、NVMe の I/O パフォーマンスが大幅に低下することがあります。Lsv2 users could see a dramatic performance drop in NVMe I/O performance if that happens.

  • アプリの NUMA アフィニティを決めるにあたっては、データ ドライブ用 VM からのレポートに表示されるデバイスの NUMA 情報 (すべて 0) を信用しないようにしてください。Lsv2 users should not rely on device NUMA information (all 0) reported from within the VM for data drives to decide the NUMA affinity for their apps. パフォーマンス向上のために、可能であればワークロードを複数の CPU に分散させることをお勧めします。The recommended way for better performance is to spread workloads across CPUs if possible.

  • Lsv2 VM の NVMe デバイスの 1 組の I/O キュー ペアでサポートされるキューの深さは 1,024 です (Amazon i3 の QD の上限は 32 です)。The maximum supported queue depth per I/O queue pair for Lsv2 VM NVMe device is 1024 (vs. Amazon i3 QD 32 limit). キューがいっぱいになり、パフォーマンスが低下する事態を防ぐため、(合成) ベンチマークのワークロードにおけるキューの深さは 1,024 以下にしてください。Lsv2 users should limit their (synthetic) benchmarking workloads to queue depth 1024 or lower to avoid triggering queue full conditions, which can reduce performance.

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

Lsv2 VM にある 1.92 TB NVMe ディスク上のローカル ストレージは、エフェメラル ストレージです。Local storage on the 1.92 TB NVMe disk on all Lsv2 VMs is ephemeral. VM の標準的な再起動処理が正常に実行されている間は、ローカル NVMe ディスクにあるデータが保持されます。During a successful standard reboot of the VM, the data on the local NVMe disk will persist. VM の再デプロイ、割り当て解除、または削除を行った場合には、NVMe 上にデータが保持されません。The data will not persist on the NVMe if the VM is redeployed, de-allocated, or deleted. 他の問題が原因となって VM またはその VM が稼働しているハードウェアが正常な状態ではなくなった場合には、データが保持されません。Data will not persist if another issue causes the VM, or the hardware it is running on, to become unhealthy. このような事態が発生した場合には、以前のホストに存在するデータがすべて安全に消去されます。When this happens, any data on the old host is securely erased.

計画メンテナンス業務の間などには、VM を別のホスト マシンに移行することが必要になることもあります。There will also be cases when the VM needs to be moved to a different host machine, for example, during a planned maintenance operation. Scheduled Events では、計画メンテナンス業務の予定やハードウェア障害の見込みを確認できます。Planned maintenance operations and some hardware failures can be anticipated with Scheduled Events. Scheduled Events を使用して、メンテナンス業務や回復業務の予定の最新情報を確認するようにしてください。Scheduled Events should be used to stay updated on any predicted maintenance and recovery operations.

計画メンテナンス イベントの際に、空のローカル ディスクを備えた新しいホストに VM を作り直す必要が生じた場合には、データを同期し直す必要があります (繰り返しになりますが、以前のホストに存在するデータはすべて安全に消去されます)。In the case that a planned maintenance event requires the VM to be recreated on a new host with empty local disks, the data will need to be resynchronized (again, with any data on the old host being securely erased). これは、Lsv2 シリーズの VM が現在、ローカル NVMe ディスク上のライブ マイグレーションをサポートしていないことによるものです。This occurs because Lsv2-series VMs do not currently support live migration on the local NVMe disk.

計画メンテナンスには 2 つのモードがあります。There are two modes for planned maintenance.

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

  • 30 日の間に、VM が新しいホストに移行します。The VM is moved to an updated host during a 30-day window.
  • Lsv2 ローカル ストレージのデータが失われる可能性があるので、イベントの前にデータのバックアップを作成しておくことをお勧めします。Lsv2 local storage data could be lost, so backing-up data prior to the event is recommended.

自動メンテナンスAutomatic maintenance

  • お客様が顧客コントロール型メンテナンスを実施しなかったり、緊急処置が必要になったりした場合 (セキュリティに関するゼロデイ イベントなど) に発生します。Occurs if the customer does not execute customer-controlled maintenance, or in the event of emergency procedures such as a security zero-day event.
  • お客様のデータの保持を目的としたものですが、VM のフリーズや再起動が発生するリスクがわずかに存在します。Intended to preserve customer data, but there is a small risk of a VM freeze or reboot.
  • Lsv2 ローカル ストレージのデータが失われる可能性があるので、イベントの前にデータのバックアップを作成しておくことをお勧めします。Lsv2 local storage data could be lost, so backing-up data prior to the event is recommended.

サービス イベントが近づいてきたら、コントロール型のメンテナンス プロセスを使って更新に最も都合の良いタイミングを選択してください。For any upcoming service events, use the controlled maintenance process to select a time most convenient to you for the update. イベントの前には、Premium ストレージ内のデータをバックアップしておくのも良いでしょう。Prior to the event, you may back up your data in premium storage. メンテナンス イベントが完了した後は、新しい Lsv2 VM のローカル NVMe ストレージにデータを戻すことができます。After the maintenance event completes, you can return your data to the refreshed Lsv2 VMs local NVMe storage.

ローカルの NVMe ディスクにあるデータが保持されるシナリオは次のとおりです。Scenarios that maintain data on local NVMe disks include:

  • VM が正常な状態で稼働している。The VM is running and healthy.
  • VM が (お客様または Azure により) 再起動中になっている。The VM is rebooted in place (by you or Azure).
  • VM が一時停止している (割り当て解除せずに停止した)。The VM is paused (stopped without de-allocation).
  • 計画メンテナンス サービス業務の大多数。The majority of the planned maintenance servicing operations.

お客様の保護のためにデータが安全に消去されるシナリオは次のとおりです。Scenarios that securely erase data to protect the customer include:

  • (お客様が) VM を再デプロイ、停止 (割り当て解除)、または削除した。The VM is redeployed, stopped (de-allocated), or deleted (by you).
  • ハードウェアの問題が原因で VM が異常な状態になっており、別のノードに復旧させる必要がある。The VM becomes unhealthy and has to service heal to another node due to a hardware issue.
  • 保守作業のために VM を別のホストに割り当て直す必要がある少数の計画メンテナンス サービス業務。A small number of the planned maintenance servicing operations that requires the VM to be reallocated to another host for servicing.

データをローカル ストレージにバックアップする際のオプションの詳細については、「Azure IaaS ディスクのバックアップとディザスター リカバリー」を参照してください。To learn more about options for backing up data in local storage, see Backup and disaster recovery for Azure IaaS disks.

よく寄せられる質問Frequently asked questions

  • Lsv2 シリーズの VM のデプロイを始めるにはどうすればよいでしょうか?How do I start deploying Lsv2-series VMs?
    他の VM と同じく、ポータルAzure CLIPowerShell のいずれかを使って VM を作成します。Much like any other VM, use the Portal, Azure CLI, or PowerShell to create a VM.

  • 1 つの NVMe ディスクに障害が発生すると、そのホストにある VM すべてに障害が起こるのでしょうか?Will a single NVMe disk failure cause all VMs on the host to fail?
    ハードウェア ノードでディスクの障害が検出された場合には、ハードウェアの状態が障害の存在を示すものに変わります。If a disk failure is detected on the hardware node, the hardware is in a failed state. このような事態が発生すると、そのノードにある VM はいずれも割り当てが解除され、別の正常なノードに移行します。When this occurs, all VMs on the node are automatically de-allocated and moved to a healthy node. Lsv2 シリーズの VM の場合には、障害が発生したノードにあるお客様のデータも安全に消去されることになるので、新しいノードにお客様が自らデータを作り直す必要があります。For Lsv2-series VMs, this means that the customer’s data on the failing node is also securely erased and will need to be recreated by the customer on the new node. 既に述べたとおり、Lsv2 でライブ マイグレーションが利用できるようになるまでは、VM が別のノードに移行する際に、障害が発生しているノードにあるデータも一緒に移行されます。As noted, before live migration becomes available on Lsv2, the data on the failing node will be proactively moved with the VMs as they are transferred to another node.

  • パフォーマンス向上のために rq_affinity に何か調整を加える必要はありますか?Do I need to make any adjustments to rq_affinity for performance?
    rq_affinity の設定は、1 秒あたりの入出力処理件数 (IOPS) の絶対最大値を使用している場合には、小さな調整にとどまります。The rq_affinity setting is a minor adjustment when using the absolute maximum input/output operations per second (IOPS). 他のあらゆる点が正常に動作していることがわかったら、rq_affinity を 0 に設定してみて、何か変化があるかどうかを確認してください。Once everything else is working well, then try to set rq_affinity to 0 to see if it makes a difference.

  • blk_mq の設定には変更が必要ですか?Do I need to change the blk_mq settings?
    NVMe デバイスの場合、RHEL/CentOS 7.x により自動的に blk-mq が使用されます。RHEL/CentOS 7.x automatically uses blk-mq for the NVMe devices. 構成の変更や設定は必要ありません。No configuration changes or settings are necessary. scsi_mod.use_blk_mq の設定は SCSI 専用です。この設定は、Lsv2 のプレビュー期間中に NVMe デバイスがゲスト VM 内で SCSI デバイスとして表示されていたために使われていたものです。The scsi_mod.use_blk_mq setting is for SCSI only and was used during Lsv2 Preview because the NVMe devices were visible in the guest VMs as SCSI devices. 現在は NVMe デバイスが NVMe デバイスとして表示されるようになったため、SCSI の blk-mq の設定は関係がありません。Currently, the NVMe devices are visible as NVMe devices, so the SCSI blk-mq setting is irrelevant.

  • "fio" には変更が必要ですか?Do I need to change “fio”?
    L64v2 と L80v2 サイズの VM 内で "fio" のようなパフォーマンス計測ツールを使って IOPS の最大値を取得するには、各 NVMe デバイスの "rq_affinity" を 0 に設定します。To get maximum IOPS with a performance measuring tool like ‘fio’ in the L64v2 and L80v2 VM sizes, set “rq_affinity” to 0 on each NVMe device. たとえば、このコマンド ラインは、L80v2 VM 内の 10 台の NVMe デバイスすべてを対象に "rq_affinity" を 0 に設定するものです。For example, this command line will set “rq_affinity” to zero for all 10 NVMe devices in an L80v2 VM:

    for i in `seq 0 9`; do echo 0 >/sys/block/nvme${i}n1/queue/rq_affinity; done

    このほか、最善のパフォーマンスが得られるのは、未加工 (パーティション分割をしておらず、ファイル システムがなく、RAID 0 を構成していないなど) の各 NVMe デバイスに対して直接 I/O を実行したときであるという点にご注意ください。テスト セッションを開始する前に、それぞれの NVMe デバイスで blkdiscard を実行し、構成が既知のフレッシュまたはクリーンな状態になっていることを確認してください。Also note that the best performance is obtained when I/O is done directly to each of the raw NVMe devices with no partitioning, no file systems, no RAID 0 config, etc. Before starting a testing session, ensure the configuration is in a known fresh/clean state by running blkdiscard on each of the NVMe devices.

次の手順Next steps