Azure Virtual Machines 上の SQL Server のパフォーマンスに関するガイドラインPerformance guidelines for SQL Server on Azure Virtual Machines

適用対象: Azure VM 上の SQL Server

この記事では、Microsoft Azure Virtual Machines での SQL Server のパフォーマンスを最適化するためのガイダンスを紹介します。This article provides guidance for optimizing SQL Server performance in Microsoft Azure Virtual Machines.

概要Overview

Azure Virtual Machines 上の SQL Server を実行するときは、オンプレミスのサーバー環境で SQL Server に適用されるデータベース パフォーマンス チューニング オプションと同じものを引き続き使用することをお勧めします。While running SQL Server on Azure Virtual Machines, we recommend that you continue using the same database performance tuning options that are applicable to SQL Server in on-premises server environments. ただし、パブリック クラウド内のリレーショナル データベースのパフォーマンスは、仮想マシンのサイズやデータ ディスクの構成などのさまざまな要素に左右されます。However, the performance of a relational database in a public cloud depends on many factors such as the size of a virtual machine, and the configuration of the data disks.

Azure Portal でプロビジョニングされる SQL Server イメージは、一般的なストレージ構成のベスト プラクティスに従います。SQL Server images provisioned in the Azure portal follow general storage configuration best practices. プロビジョニングした後で、この記事で説明するその他の最適化を適用することを検討します。After provisioning, consider applying other optimizations discussed in this article. ワークロードに関する選択を基準に、テストを通して検証します。Base your choices on your workload and verify through testing.

ヒント

通常、コストの最適化とパフォーマンスの最適化はトレードオフの関係になっています。There is typically a trade-off between optimizing for costs and optimizing for performance. この記事では、Azure Virtual Machines 上の SQL Server の "最大の" パフォーマンスを得ることに重点を置いています。This article is focused on getting the best performance for SQL Server on Azure Virtual Machines. ワークロードの要求が厳しくない場合は、以下に示す最適化がすべて必要になるわけではありません。If your workload is less demanding, you might not require every optimization listed below. 各推奨事項を評価するときに、パフォーマンスのニーズ、コスト、およびワークロードのパターンを考慮してください。Consider your performance needs, costs, and workload patterns as you evaluate these recommendations.

クイック チェックリストQuick checklist

Azure Virtual Machines 上の SQL Server の最適なパフォーマンスを実現するためのクイック チェックリストを次に示します。The following is a quick checklist for optimal performance of SQL Server on Azure Virtual Machines:

領域Area 最適化Optimizations
VM サイズVM size - Standard_M8-4msE4ds_v4、または DS12_v2 以上などの vCPU が 4 個以上の VM サイズを使用します。- Use VM sizes with 4 or more vCPU like the Standard_M8-4ms, the E4ds_v4, or the DS12_v2 or higher.

- SQL Server ワークロードの最適なパフォーマンスを得るために、メモリ最適化済み仮想マシン サイズを使用します。- Use memory optimized virtual machine sizes for the best performance of SQL Server workloads.

- DSv2 11-15Edsv4 シリーズ、M-Mv2- シリーズでは、OLTP ワークロードに必要な、最適なメモリと仮想コアの比率を提供します。- The DSv2 11-15, Edsv4 series, the M-, and the Mv2- series offer the optimal memory-to-vCore ratio required for OLTP workloads. M シリーズの VM はどちらも、ミッション クリティカルなワークロードに必要な、最も高いメモリと仮想コアの比率を提供し、データ ウェアハウスのワークロードにも最適です。Both M series VMs offer the highest memory-to-vCore ratio required for mission critical workloads and is also ideal for data warehouse workloads.

- ミッション クリティカルおよびデータ ウェアハウスのワークロードには、より高いメモリと仮想コアの比率が必要になる場合があります。- A higher memory-to-vCore ratio may be required for mission critical and data warehouse workloads.

- SQL Server のパフォーマンスが最適になるように SQL Server の設定とストレージ オプションが構成されているため、Azure 仮想マシンのマーケットプレース イメージを活用します。- Leverage the Azure Virtual Machine marketplace images as the SQL Server settings and storage options are configured for optimal SQL Server performance.

- ターゲット ワークロードのパフォーマンス特性を収集し、それらを使用してお客様のビジネスに適した VM サイズを決定します。- Collect the target workload's performance characteristics and use them to determine the appropriate VM size for your business.
StorageStorage - TPC-E および TPC_C ベンチマークによる Azure Virtual Machines 上の SQL Server のパフォーマンスの詳細なテストについては、OLTP のパフォーマンスの最適化に関するブログを参照してください。- For detailed testing of SQL Server performance on Azure Virtual Machines with TPC-E and TPC_C benchmarks, refer to the blog Optimize OLTP performance.

- 最適な価格/パフォーマンス比の利点を得るために Premium SSD を使用します。- Use premium SSDs for the best price/performance advantages. データ ファイルに対しては読み取り専用キャッシュを、ログ ファイルに対してはキャッシュなしを構成します。Configure Read only cache for data files and no cache for the log file.

- ワークロードで 1 ミリ秒未満のストレージ待機時間が必要な場合は、Ultra ディスクを使用します。- Use Ultra Disks if less than 1-ms storage latencies are required by the workload. 詳細については、Ultra Disk への移行に関するページを参照してください。See migrate to ultra disk to learn more.

- ディスクの種類を選択する前に、アプリケーションを監視することによって、SQL Server データ、ログ、および Temp DB ファイルのストレージ待機時間の要件を収集します。- Collect the storage latency requirements for SQL Server data, log, and Temp DB files by monitoring the application before choosing the disk type. 1 ミリ秒未満のストレージ待機時間が必要な場合は Ultra ディスクを使用し、それ以外の場合は Premium SSD を使用します。If < 1-ms storage latencies are required, then use Ultra Disks, otherwise use premium SSD. 短い待機時間がログ ファイルにのみ必要であり、データ ファイルには必要ない場合は、ログ ファイルに対してのみ、必要な IOPS とスループットのレベルで Ultra ディスクをプロビジョニングします。If low latencies are only required for the log file and not for data files, then provision the Ultra Disk at required IOPS and throughput levels only for the log File.

- 標準ストレージは、開発とテストの目的またはバックアップ ファイルにのみ推奨されます。運用ワークロードには使用しないでください。- Standard storage is only recommended for development and test purposes or for backup files and should not be used for production workloads.

- ストレージ アカウントと SQL Server VM を同じリージョンに保持します。- Keep the storage account and SQL Server VM in the same region.

- ストレージ アカウントで Azure geo 冗長ストレージ (geo レプリケーション) を無効にします。- Disable Azure geo-redundant storage (geo-replication) on the storage account.
ディスクDisks - 少なくとも 2 つの Premium SSD ディスク (ログ ファイル用に 1 つとデータ ファイル用に 1 つ) を使用します。- Use a minimum of 2 premium SSD disks (1 for log file and 1 for data files).

- 1 ミリ秒未満の IO 待機時間が必要なワークロードの場合は、M シリーズの書き込みアクセラレータを有効にし、Es および DS シリーズでの Ultra SSD ディスクの使用を考慮します。- For workloads requiring < 1-ms IO latencies, enable write accelerator for M series and consider using Ultra SSD disks for Es and DS series.

- データ ファイルをホストするディスクで読み取り専用キャッシュを有効にします。- Enable read only caching on the disk(s) hosting the data files.

- SQL Server データ、ログ、および TempDB ファイルのストレージを構成するときに、ワークロードに必要な追加の 20% Premium IOPS/スループット容量を追加します。- Add an additional 20% premium IOPS/throughput capacity than your workload requires when configuring storage for SQL Server data, log, and TempDB files

- データベース ストレージまたはログに、オペレーティング システム ディスクまたは一時ディスクを使用することは避けてください。- Avoid using operating system or temporary disks for database storage or logging.

- ログ ファイルをホストするディスクでは、キャッシュを有効にしないでください。- Do not enable caching on disk(s) hosting the log file. 重要:Azure Virtual Machines ディスクのキャッシュ設定を変更するときは、SQL Server サービスを停止してください。Important: Stop the SQL Server service when changing the cache settings for an Azure Virtual Machines disk.

- 複数の Azure データ ディスクをストライプして、ストレージ スループットを向上させます。- Stripe multiple Azure data disks to get increased storage throughput.

- ドキュメントに記載されている割り当てサイズでフォーマットします。- Format with documented allocation sizes.

- ミッション クリティカルな SQL Server ワークロードのために、TempDB をローカル SSD の D:\ ドライブに配置します (適切な VM サイズを選択した後に行います)。- Place TempDB on the local SSD D:\ drive for mission critical SQL Server workloads (after choosing correct VM size). Azure portal または Azure クイックスタート テンプレートから VM を作成し、ローカル ディスクに Temp DB を配置する場合は、それ以上のアクションは必要ありません。その他のすべての場合は、再起動後の障害を防止するために、SSD を使用した TempDB の格納のブログにある手順に従ってください。If you create the VM from the Azure portal or Azure quickstart templates and place Temp DB on the Local Disk, then you do not need any further action; for all other cases follow the steps in the blog for Using SSDs to store TempDB to prevent failures after restarts. ローカル ドライブの容量が Temp DB サイズに対して十分でない場合は、読み取り専用キャッシュを備えた Premium SSD ディスク上のストライプされたストレージ プールに Temp DB を配置します。If the capacity of the local drive is not enough for your Temp DB size, then place Temp DB on a storage pool striped on premium SSD disks with read-only caching.
I/OI/O - データベース ページの圧縮を有効にします。- Enable database page compression.

- データ ファイルの瞬時初期化を有効にします。- Enable instant file initialization for data files.

- データベースの自動拡張を制限します。- Limit autogrowth of the database.

- データベースの自動圧縮を無効にします。- Disable autoshrink of the database.

- システム データベースも含め、すべてのデータベースをデータ ディスクに移動します。- Move all databases to data disks, including system databases.

- SQL Server エラー ログとトレース ファイルのディレクトリをデータ ディスクに移動します。- Move SQL Server error log and trace file directories to data disks.

- 既定のバックアップとデータベース ファイルの場所を構成します。- Configure default backup and database file locations.

- メモリ内のロックされたページを有効にします- Enable locked pages in memory.

- インストールされている SQL Server バージョンの最新の累積的な更新プログラムを評価して適用します。- Evaluate and apply the latest cumulative updates for the installed version of SQL Server.
機能固有Feature-specific - Azure Blob Storage に直接バックアップします。- Back up directly to Azure Blob storage.

- 12 TB を超えるデータベースにはファイル スナップショットのバックアップを使用します。- Use file snapshot backups for databases larger than 12 TB.

- 複数の Temp DB ファイル (コアあたり 1 ファイル、最大 8 ファイル) を使用します。- Use multiple Temp DB files, 1 file per core, up to 8 files.

- 最大サーバー メモリを 90% で設定するか、またはオペレーティング システムに最大 50 GB を残します。- Set max server memory at 90% or up to 50 GB left for the Operating System.

- ソフト NUMA を有効にします。- Enable soft NUMA.

これらの最適化を行う *方法* と *理由* については、以下のセクションに記載されている詳細とガイダンスをご確認ください。For more information on *how* and *why* to make these optimizations, please review the details and guidance provided in the following sections.

作業の開始Getting started

Azure VM 上に新しい SQL Server を作成し、現在のソース システムを移行しない場合は、ベンダーの要件に基づいて新しい SQL Server VM を作成します。If you are creating a new SQL Server on Azure VM and are not migrating a current source system, create your new SQL Server VM based on your vendor requirements. SQL Server VM のベンダー要件は、オンプレミスで展開するものと同じです。The vendor requirements for a SQL Server VM are the same as what you would deploy on-premises.

クラウド用に構築された新しいアプリケーションを使用して新しい SQL Server VM を作成する場合は、データや使用量の要件が変化したときに、それに合わせて SQL Server VM のサイズを簡単に変更できます。If you are creating a new SQL Server VM with a new application built for the cloud, you can easily size your SQL Server VM as your data and usage requirements evolve. 下位レベルの D シリーズ、B シリーズ、または Av2 シリーズで開発環境を開始し、時間の経過とともに環境を拡張します。Start the development environments with the lower-tier D-Series, B-Series, or Av2-series and grow your environment over time.

OLTP 運用環境で推奨される最小構成は、4 仮想コア、32 GB のメモリ、メモリと仮想コアの比率 8 です。The recommended minimum for a production OLTP environment is 4 vCore, 32 GB of memory, and a memory-to-vCore ratio of 8. 新しい環境では、4 個の仮想コアを搭載したマシンから始め、データとコンピューティングの要件が変化したときに、8、16、32 個以上の仮想コアに拡張します。For new environments, start with 4 vCore machines and scale to 8, 16, 32 vCores or more when your data and compute requirements change. OLTP のスループットについては、仮想コアあたり 5000 IOPS の SQL Server VM をターゲットとします。For OLTP throughput, target SQL Server VMs that have 5000 IOPS for every vCore.

ポータルでのストレージ構成で SQL Server VM のマーケットプレース イメージを使用します。Use the SQL Server VM marketplace images with the storage configuration in the portal. これにより、お客様のワークロードに必要なサイズ、IOPS、スループットを確保するために必要な記憶域プールの適切な作成が容易になります。This will make it easier to properly create the storage pools necessary to get the size, IOPS, and throughput necessary for your workloads. Premium Storage と Premium Storage キャッシュをサポートしている SQL Server VM を選択することが重要です。It is important to choose SQL Server VMs that support premium storage and premium storage caching. 詳細については、ストレージに関するセクションをご覧ください。See the storage section to learn more.

SQL Server のデータ ウェアハウスおよびミッション クリティカルな環境では多くの場合、メモリと仮想コアの比率を 8 よりも大きくする必要があります。SQL Server data warehouse and mission critical environments will often need to scale beyond the 8 memory-to-vCore ratio. 中規模の環境では、コアとメモリの比率 16 を選択し、より大規模なデータ ウェアハウス環境では、コアとメモリの比率 32 を選択することをお勧めします。For medium environments, you may want to choose a 16 core-to-memory ratio, and a 32 core-to-memory ratio for larger data warehouse environments.

SQL Server のデータ ウェアハウス環境では多くの場合、サイズの大きなマシンの並列処理が有効です。SQL Server data warehouse environments often benefit from the parallel processing of larger machines. このため、M シリーズと Mv2 シリーズは、大規模なデータ ウェアハウス環境に最適なオプションです。For this reason, the M-series and the Mv2-series are strong options for larger data warehouse environments.

VM サイズのガイダンスVM size guidance

現在のオンプレミス SQL Server データベースを Azure VM 上の SQL Server に移行するためのベースラインとして、ソース マシンの vCPU とメモリ構成を使用します。Use the vCPU and memory configuration from your source machine as a baseline for migrating a current on-premises SQL Server database to SQL Server on Azure VMs. お客様のコア ライセンスを Azure に導入すると、Azure ハイブリッド特典を利用して、SQL Server のライセンス コストを節約できます。Bring your core license to Azure to take advantage of the Azure Hybrid Benefit and save on SQL Server licensing costs.

Microsoft では、運用環境の SQL Server ワークロードの開始点として、メモリと仮想コアの比率を 8 にすることをお勧めします。Microsoft recommends a memory-to-vCore ratio of 8 as a starting point for production SQL Server workloads. 非運用環境のワークロードでは、より小さい比率を使用できます。Smaller ratios are acceptable for non-production workloads.

ワークロード (OLTP またはデータ ウェアハウス) に基づいて SQL Server のパフォーマンスに最適なメモリ最適化済み汎用ストレージ最適化済み、または制約付き仮想コアの仮想マシン サイズを選択します。Choose a memory optimized, general purpose, storage optimized, or constrained vCore virtual machine size that is most optimal for SQL Server performance based on your workload (OLTP or data warehouse).

メモリ最適化Memory optimized

メモリ最適化済み仮想マシン サイズは、SQL Server VM のプライマリ ターゲットであり、Microsoft が推奨する選択肢です。The memory optimized virtual machine sizes are a primary target for SQL Server VMs and the recommended choice by Microsoft. メモリ最適化済み仮想マシンでは、メモリと CPU のより高い比率および中規模から大規模のキャッシュ オプションを提供します。The memory optimized virtual machines offer stronger memory-to-CPU ratios and medium-to-large cache options.

M および Mv2 シリーズM and Mv2 series

M シリーズは、一部の最大の SQL Server ワークロードに適した仮想コア数とメモリを提供します。The M-series offers vCore counts and memory for some of the largest SQL Server workloads.

Mv2 シリーズは、最大の仮想コア数とメモリを備えており、ミッション クリティカルおよびデータ ウェアハウス ワークロードに推奨されています。The Mv2-series has the highest vCore counts and memory and is recommended for mission critical and data warehouse workloads. Mv2 シリーズ インスタンスはメモリ最適化済み VM サイズで、非常に優れたコンピューティング性能によって大規模なメモリ内データベースとワークロードをサポートし、リレーショナル データベース サーバー、大規模キャッシュ、インメモリ分析に最適な、メモリと CPU の高い比率を提供します。Mv2-series instances are memory optimized VM sizes providing unparalleled computational performance to support large in-memory databases and workloads with a high memory-to-CPU ratio that is perfect for relational database servers, large caches, and in-memory analytics.

たとえば、Standard_M64ms のメモリと仮想コアの比率は 28 です。The Standard_M64ms has a 28 memory-to-vCore ratio for example.

SQL Server のパフォーマンスにとって魅力的な M および Mv2 シリーズの機能の一部には、Premium StoragePremium Storage キャッシュのサポート、Ultra ディスクのサポート、書き込みアクセラレータなどがあります。Some of the features of the M and Mv2-series attractive for SQL Server performance include premium storage and premium storage caching support, ultra-disk support, and write acceleration.

Edsv4 シリーズEdsv4-series

Edsv4 シリーズは、メモリを集中的に使用するアプリケーション向けに設計されています。The Edsv4-series is designed for memory-intensive applications. これらの VM には、大容量のローカル SSD ストレージ、強力なローカル ディスク IOPS、最大 504 GiB の RAM が搭載されており、Gen2 VM での以前の Ev3 および Esv3 サイズと比べてコンピューティング機能が向上しています。These VMs have a large local storage SSD capacity, strong local disk IOPS, up to 504 GiB of RAM, and improved compute compared to the previous Ev3/Esv3 sizes with Gen2 VMs. これらの仮想マシンではメモリと仮想コアの比率がほぼ一貫して 8 であり、これは標準の SQL Server ワークロードに最適です。There is a nearly consistent memory-to-vCore ratio of 8 across these virtual machines, which is ideal for standard SQL Server workloads.

この VM シリーズは、メモリを集中的に使用するエンタープライズ アプリケーションや、低待機時間で高速のローカル ストレージを利用するアプリケーションに最適です。This VM series is ideal for memory-intensive enterprise applications and applications that benefit from low latency, high-speed local storage.

Edsv4 シリーズの仮想マシンでは、Premium StoragePremium Storage キャッシュがサポートされています。The Edsv4-series virtual machines support premium storage, and premium storage caching.

DSv2 シリーズ 11 - 15DSv2-series 11-15

DSv2 シリーズ 11 - 15 のメモリおよびディスク構成は以前の D シリーズと同じです。The DSv2-series 11-15 has the same memory and disk configurations as the previous D-series. このシリーズでは、すべての仮想マシンでメモリと CPU の比率が一貫して 7 になっています。This series has a consistent memory-to-CPU ratio of 7 across all virtual machines.

DSv2 シリーズ 11 - 15 では Premium StoragePremium Storage キャッシュがサポートされており、最適なパフォーマンスを得るためには、これを強くお勧めします。The DSv2-series 11-15 supports premium storage and premium storage caching, which is strongly recommended for optimal performance.

General PurposeGeneral Purpose

汎用仮想マシン サイズは、開発とテスト、Web サーバー、小規模なデータベース サーバーのようなエントリ レベルの小さなワークロードに対して、メモリと仮想コアのバランスの取れた比率を提供するように設計されています。The general purpose virtual machine sizes are designed to provide balanced memory-to-vCore ratios for smaller entry level workloads such as development and test, web servers, and smaller database servers.

汎用仮想マシンでのメモリと仮想コアの比率が小さいため、メモリベースのパフォーマンス カウンターを注意深く監視して、SQL Server が必要なバッファー キャッシュ メモリを確実に取得できるようにすることが重要です。Because of the smaller memory-to-vCore ratios with the general purpose virtual machines, it is important to carefully monitor memory-based performance counters to ensure SQL Server is able to get the buffer cache memory it needs. 詳細については、メモリのパフォーマンス ベースラインをご覧ください。See memory performance baseline for more information.

運用環境のワークロードの開始時に推奨されるメモリと仮想コアの比率は 8 であるため、SQL Server が動作している汎用 VM の推奨される最小構成は、4 vCPU および 32 GB のメモリです。Since the starting recommendation for production workloads is a memory-to-vCore ratio of 8, the minimum recommended configuration for a general purpose VM running SQL Server is 4 vCPU and 32 GB of memory.

Ddsv4 シリーズDdsv4 series

Ddsv4 シリーズでは、vCPU、メモリ、一時ディスクの適正な組み合わせを提供しますが、サポートされている、メモリと仮想コアの比率は小さくなっています。The Ddsv4-series offers a fair combination of vCPU, memory, and temporary disk but with smaller memory-to-vCore support.

Ddsv4 VM には、低待機時間で高速のローカル ストレージが含まれています。The Ddsv4 VMs include lower latency and higher-speed local storage.

これらのマシンは、一時ストレージと部門別リレーショナル データベースへの高速アクセスを必要とする SQL やアプリの並列デプロイに最適です。These machines are ideal for side-by-side SQL and app deployments that require fast access to temp storage and departmental relational databases. このシリーズのすべての仮想マシンでは、メモリと仮想コアの標準比率が 4 になっています。There is a standard memory-to-vCore ratio of 4 across all of the virtual machines in this series.

このため、このシリーズのスターター仮想マシンとして D8ds_v4 を利用することをお勧めします。これには、8 個の仮想コアと 32 GB のメモリが搭載されています。For this reason, it is recommended to leverage the D8ds_v4 as the starter virtual machine in this series, which has 8 vCores and 32 GBs of memory. 最大のマシンは、64 個の仮想コアと 256 GB のメモリが搭載された D64ds_v4 です。The largest machine is the D64ds_v4, which has 64 vCores and 256 GBs of memory.

Ddsv4 シリーズの仮想マシンでは、Premium StoragePremium Storage キャッシュがサポートされています。The Ddsv4-series virtual machines support premium storage and premium storage caching.

注意

Ddsv4 シリーズでは、メモリと仮想コアの比率が、SQL Server のワークロードに推奨される 8 ではありません。The Ddsv4-series does not have the memory-to-vCore ratio of 8 that is recommended for SQL Server workloads. そのため、小規模なアプリケーションおよび開発ワークロードにのみ、これらの仮想マシンを使用することを検討してください。As such, considering using these virtual machines for smaller application and development workloads only.

B シリーズB-series

負荷の急増に対応できる B シリーズの仮想マシン サイズは、概念実証や、非常に小さなアプリケーションおよび開発サーバーなど、一貫したパフォーマンスを必要としないワークロードに最適です。The burstable B-series virtual machine sizes are ideal for workloads that do not need consistent performance such as proof of concept and very small application and development servers.

負荷の急増に対応できる B シリーズの仮想マシン サイズのメモリと仮想コアの比率は 4 です。Most of the burstable B-series virtual machine sizes have a memory-to-vCore ratio of 4. これらのマシンの最大構成は、20 個の仮想コアと 80 GB のメモリを搭載した Standard_B20ms です。The largest of these machines is the Standard_B20ms with 20 vCores and 80 GB of memory.

このシリーズの特徴は、マシン サイズに応じて変化するバースト可能なクレジットを使用して業務時間中にアプリで バースト できることです。This series is unique as the apps have the ability to burst during business hours with burstable credits varying based on machine size.

クレジットを使い切ると、VM がマシンのベースライン パフォーマンスに戻ります。When the credits are exhausted, the VM returns to the baseline machine performance.

B シリーズの利点は、特に 1 日を通して処理能力をそれほど必要としない場合、他のシリーズの他の VM サイズに比べて、コンピューティングの節約を実現しやすいことです。The benefit of the B-series is the compute savings you could achieve compared to the other VM sizes in other series especially if you need the processing power sparingly throughout the day.

このシリーズでは、Premium Storage がサポートされていますが、Premium Storage キャッシュサポートされていませんThis series supports premium storage, but does not support premium storage caching.

注意

負荷の急増に対応できる B シリーズでは、メモリと仮想コアの比率が、SQL Server のワークロードに推奨される 8 ではありません。The burstable B-series does not have the memory-to-vCore ratio of 8 that is recommended for SQL Server workloads. そのため、小規模なアプリケーション、Web サーバー、開発ワークロードにのみ、これらの仮想マシンを使用することを検討してください。As such, consider using these virtual machines for smaller applications, web servers, and development workloads only.

Av2 シリーズAv2-series

Av2 シリーズの VM は、開発とテスト、低トラフィックの Web サーバー、小規模から中規模アプリのデータベース、概念実証のようなエントリ レベルのワークロードに最適です。The Av2-series VMs are best suited for entry-level workloads like development and test, low traffic web servers, small to medium app databases, and proof-of-concepts.

Standard_A2m_v2 (2 個の仮想コアと 16 GB のメモリ)、Standard_A4m_v2 (4 個の仮想コアと 32 GB のメモリ)、Standard_A8m_v2 (8 個の仮想コアと 64 GB のメモリ) のみ、メモリと仮想コアの比率がこれらの上位 3 つの仮想マシンに最適な 8 になっています。Only the Standard_A2m_v2 (2 vCores and 16GBs of memory), Standard_A4m_v2 (4 vCores and 32GBs of memory), and the Standard_A8m_v2 (8 vCores and 64GBs of memory) have a good memory-to-vCore ratio of 8 for these top three virtual machines.

これらの仮想マシンはどれも、小規模な開発およびテスト用の SQL Server マシンに適したオプションです。These virtual machines are both good options for smaller development and test SQL Server machines.

また、8 仮想コアの Standard_A8m_v2 は、小規模なアプリケーションおよび Web サーバーにも適したオプションです。The 8 vCore Standard_A8m_v2 may also be a good option for small application and web servers.

注意

Av2 シリーズでは Premium Storage がサポートされていないため、メモリと仮想コアの比率が 8 の仮想マシンであっても、運用環境の SQL Server ワークロードにはお勧めしません。The Av2 series does not support premium storage and as such, is not recommended for production SQL Server workloads even with the virtual machines that have a memory-to-vCore ratio of 8.

ストレージ最適化Storage optimized

ストレージ最適化済み VM サイズは、特定のユース ケースに適しています。The storage optimized VM sizes are for specific use cases. これらの仮想マシンは、最適化されたディスク スループットおよび IO を考慮して特別に設計されたものです。These virtual machines are specifically designed with optimized disk throughput and IO. この仮想マシン シリーズは、ビッグ データ シナリオ、データ ウェアハウス、大規模なトランザクション データベースなどを対象としています。This virtual machine series is intended for big data scenarios, data warehousing, and large transactional databases.

Lsv2 シリーズLsv2-series

Lsv2 シリーズは、高スループットで低遅延のローカル NVMe ストレージを特長としています。The Lsv2-series features high throughput, low latency, and local NVMe storage. Lsv2 シリーズの VM は、持続性のあるデータ ディスクを使用する代わりに、VM に直接接続されているノード上のローカル ディスクを使用するように最適化されています。The Lsv2-series VMs are optimized to use the local disk on the node attached directly to the VM rather than using durable data disks.

これらの仮想マシンは、ビッグ データ、データ ウェアハウス、レポート、ETL などのワークロードに最適なオプションです。These virtual machines are strong options for big data, data warehouse, reporting, and ETL workloads. ローカル NVMe ストレージの高いスループットと IOPS は、データベースに読み込まれるファイルを処理する場合や、ソース システムまたはその他のリポジトリ (Azure Blob ストレージや Azure Data Lake など) からソース データを再作成できるその他のシナリオにおける優れたユース ケースです。The high throughput and IOPs of the local NVMe storage is a good use case for processing files that will be loaded into your database and other scenarios where the source data can be recreated from the source system or other repositories such as Azure Blob storage or Azure Data Lake. また、Lsv2 シリーズの VM では、一度に最大 30 分間、ディスク パフォーマンスをバーストすることもできます。Lsv2-series VMs can also burst their disk performance for up to 30 minutes at a time.

これらの仮想マシンのサイズは 8 - 80 vCPU で、vCPU あたり 8 GiB のメモリを搭載し、8 vCPU ごとに 1.92 TB の NVMe SSD があります。These virtual machines size from 8 to 80 vCPU with 8 GiB of memory per vCPU and for every 8 vCPUs there is 1.92 TB of NVMe SSD. つまり、このシリーズの最大の VM である L80s_v2 では、80 vCPU、640 BiB のメモリ、10 x 1.92 TB の NVMe ストレージが搭載されています。This means for the largest VM of this series, the L80s_v2, there is 80 vCPU and 640 BiB of memory with 10x1.92TB of NVMe storage. これらのすべての仮想マシンでは、メモリと仮想コアの比率が一貫して 8 になっています。There is a consistent memory-to-vCore ratio of 8 across all of these virtual machines.

NVMe ストレージはエフェメラルであり、お使いの仮想マシンを再起動すると、これらのディスク上のデータは失われます。The NVMe storage is ephemeral meaning that data will be lost on these disks if you restart your virtual machine.

Lsv2 および Ls シリーズでは、Premium Storage がサポートされていますが、Premium Storage キャッシュはサポートされていません。The Lsv2 and Ls series support premium storage, but not premium storage caching. IOPS を増やすためのローカル キャッシュの作成はサポートされていません。The creation of a local cache to increase IOPs is not supported.

警告

エフェメラルな NVMe ストレージにデータ ファイルを格納すると、VM の割り当てが解除されたときにデータが失われる可能性があります。Storing your data files on the ephemeral NVMe storage could result in data loss when the VM is deallocated.

制約付き仮想コアConstrained vCores

SQL Server の高パフォーマンス ワークロードでは、仮想コアの数は増やさずに、大量のメモリ、IO、スループットが必要になる場合がよくあります。High performing SQL Server workloads often need larger amounts of memory, IO, and throughput without the higher vCore counts.

ほとんどの OLTP ワークロードは、多数の小さなトランザクションによって駆動されるアプリケーション データベースです。Most OLTP workloads are application databases driven by large numbers of smaller transactions. OLTP ワークロードでは、少量のデータが読み取られるか変更されるだけですが、ユーザーの数に基づいて駆動されるトランザクションの量は非常に大きくなります。With OLTP workloads, only a small amount of the data is read or modified, but the volumes of transactions driven by user counts are much higher. SQL Server のメモリを使用して、プランをキャッシュし、パフォーマンスのために最近アクセスしたデータを格納し、物理読み取りをメモリにすばやく読み込むことができるようにすることが重要です。It is important to have the SQL Server memory available to cache plans, store recently accessed data for performance, and ensure physical reads can be read into memory quickly.

これらの OLTP 環境では、より多くのメモリ、高速ストレージ、そして最適な実行に必要な I/O 帯域幅が必要です。These OLTP environments need higher amounts of memory, fast storage, and the I/O bandwidth necessary to perform optimally.

SQL Server のライセンス コストを上げずにこのレベルのパフォーマンスを維持するため、Azure ではvCPU の数が制限された VM サイズを提供しています。In order to maintain this level of performance without the higher SQL Server licensing costs, Azure offers VM sizes with constrained vCPU counts.

これにより、親仮想マシンのメモリ、ストレージ、I/O 帯域幅を維持しながら、使用可能な仮想コア数を減らすことで、ライセンス コストを抑えることができます。This helps control licensing costs by reducing the available vCores while maintaining the same memory, storage, and I/O bandwidth of the parent virtual machine.

vCPU の数を、元の VM サイズの半分または 4 分の 1 に制限することができます。The vCPU count can be constrained to one-half to one-quarter of the original VM size. 仮想マシンで使用可能な仮想コア数を減らすと、メモリと仮想コアの比率が高くなります。Reducing the vCores available to the virtual machine, will achieve higher memory-to-vCore ratios.

これらの新しい VM サイズでは、識別しやすいように、アクティブな vCPU の数を指定するサフィックスが付加されています。These new VM sizes have a suffix that specifies the number of active vCPUs to make them easier to identify.

たとえば、M64-32ms には 32 個の SQL Server 仮想コアと、M64ms のメモリ、IO、スループットのライセンスが必要であり、M64-16ms には 16 個の仮想コアのみのライセンスが必要です。For example, the M64-32ms requires licensing only 32 SQL Server vCores with the memory, IO, and throughput of the M64ms and the M64-16ms requires licensing only 16 vCores. しかし、M64-16ms では、SQL Server のライセンス コストは M64ms の 4 分の 1 になりますが、仮想マシンのコンピューティング コストは同じです。Though while the M64-16ms has a quarter of the SQL Server licensing cost of the M64ms, the compute cost of the virtual machine will be the same.

注意

  • それでも中規模から大規模のデータ ウェアハウスのワークロードでは制約付き仮想コア VM が有効である可能性がありますが、データ ウェアハウスのワークロードは一般に、並列で実行されるクエリ プランによって少ない数のユーザーとプロセスで大量のデータを処理するという特徴があります。Medium to large data warehouse workloads may still benefit from constrained vCore VMs, but data warehouse workloads are commonly characterized by fewer users and processes addressing larger amounts of data through query plans that run in parallel.
  • コンピューティング コスト (オペレーティング システムのライセンスを含む) は、親仮想マシンと同じままです。The compute cost, which includes operating system licensing, will remain the same as the parent virtual machine.

ストレージのガイダンスStorage guidance

TP C-E および TPC-C ベンチマークによる Azure Virtual Machines 上の SQL Server のパフォーマンスの詳細なテストについては、OLTP のパフォーマンスの最適化に関するブログをご覧ください。For detailed testing of SQL Server performance on Azure Virtual Machines with TPC-E and TPC-C benchmarks, refer to the blog Optimize OLTP performance.

Premium SSD を使用した Azure BLOB キャッシュは、すべての運用ワークロードに推奨されます。Azure blob cache with premium SSDs is recommended for all production workloads.

警告

Standard HDD と SSD には、さまざまな待機時間や帯域幅があり、開発/テスト ワークロードにのみ推奨されます。Standard HDDs and SSDs have varying latencies and bandwidth and are only recommended for dev/test workloads. 運用環境のワークロードでは、Premium SSD を使用する必要があります。Production workloads should use premium SSDs.

さらに、転送遅延を低減するために、SQL Server 仮想マシンと同じデータ センターで Azure ストレージ アカウントを作成することをお勧めします。In addition, we recommend that you create your Azure storage account in the same data center as your SQL Server virtual machines to reduce transfer delays. ストレージ アカウントの作成時に、geo レプリケーションを無効にします。複数のディスクでの一貫性のある書き込み順序が保証されないためです。When creating a storage account, disable geo-replication as consistent write order across multiple disks is not guaranteed. 代わりに、2 つの Azure データ センター間で SQL Server ディザスター リカバリー テクノロジを構成することを検討します。Instead, consider configuring a SQL Server disaster recovery technology between two Azure data centers. 詳細については、「 Azure Virtual Machines における SQL Server の高可用性と障害復旧」を参照してください。For more information, see High Availability and Disaster Recovery for SQL Server on Azure Virtual Machines.

ディスクのガイダンスDisks guidance

Azure 仮想マシンには、3 種類のメイン ディスクがあります。There are three main disk types on Azure virtual machines:

  • OS ディスク:Azure 仮想マシンを作成すると、プラットフォームによって、オペレーティング システム ディスク用に少なくとも 1 つのディスク (C ドライブとしてラベル付けされます) が VM に接続されます。OS disk: When you create an Azure virtual machine, the platform will attach at least one disk (labeled as the C drive) to the VM for your operating system disk. このディスクは、ページ BLOB としてストレージに格納されている VHD です。This disk is a VHD stored as a page blob in storage.
  • 一時ディスク:Azure Virtual Machines には、一時ディスクと呼ばれる別のディスク (D: ドライブとしてラベル付けされる) が含まれています。Temporary disk: Azure virtual machines contain another disk called the temporary disk (labeled as the D: drive). これは、スクラッチ領域に使用できるノード上のディスクです。This is a disk on the node that can be used for scratch space.
  • データ ディスク:追加のディスクをデータ ディスクとして仮想マシンに接続することもできます。これらのディスクは、ページ BLOB としてストレージに格納されます。Data disks: You can also attach additional disks to your virtual machine as data disks, and these will be stored in storage as page blobs.

次のセクションでは、これらの異なるディスクの使用に関する推奨事項について説明します。The following sections describe recommendations for using these different disks.

オペレーティング システム ディスクOperating system disk

オペレーティング システム ディスクは、実行中のバージョンのオペレーティング システムとして起動およびマウントできる VHD であり、C ドライブとしてラベル付けされます。An operating system disk is a VHD that you can boot and mount as a running version of an operating system and is labeled as the C drive.

オペレーティング システム ディスクの既定のキャッシュ ポリシーは、 読み取り/書き込み です。Default caching policy on the operating system disk is Read/Write. パフォーマンス重視のアプリケーションでは、オペレーティング システム ディスクではなく、データ ディスクを使用することをお勧めします。For performance sensitive applications, we recommend that you use data disks instead of the operating system disk. 下記のデータ ディスクに関するセクションをご覧ください。See the section on Data Disks below.

一時ディスクTemporary disk

D ドライブのラベルが付いた一時ストレージ ドライブは、Azure Blob Storage に保持されません。The temporary storage drive, labeled as the D drive, is not persisted to Azure Blob storage. ユーザー データベース ファイルやユーザー トランザクション ログ ファイルを D: ドライブに保存しないでください。Do not store your user database files or user transaction log files on the D: drive.

ミッション クリティカルな SQL Server ワークロードのために (適切な VM サイズを選択した後) TempDB をローカル SSD の D:\ ドライブに配置します。Place TempDB on the local SSD D:\ drive for mission critical SQL Server workloads (after choosing correct VM size). Azure portal または Azure クイックスタート テンプレートから VM を作成し、ローカル ディスクに Temp DB を配置する場合は、それ以上のアクションは必要ありません。その他のすべての場合は、再起動後の障害を防止するために、SSD を使用した TempDB の格納のブログにある手順に従ってください。If you create the VM from the Azure portal or Azure quickstart templates and place Temp DB on the Local Disk, then you do not need any further action; for all other cases follow the steps in the blog for Using SSDs to store TempDB to prevent failures after restarts. ローカル ドライブの容量が Temp DB サイズに対して十分でない場合は、読み取り専用キャッシュを備えた Premium SSD ディスク上のストライプされたストレージ プールに Temp DB を配置します。If the capacity of the local drive is not enough for your Temp DB size, then place Temp DB on a storage pool striped on premium SSD disks with read-only caching.

Premium SSD をサポートする VM の場合は、読み取りキャッシュが有効になっている Premium SSD をサポートするディスクに TempDB を格納することもできます。For VMs that support premium SSDs, you can also store TempDB on a disk that supports premium SSDs with read caching enabled.

データ ディスクData disks

  • データ ファイルとログ ファイルに Premium SSD ディスクを使用する: ディスク ストライピングを使用していない場合は、1 つのディスクにログ ファイルが含まれ、もう一方のディスクにデータが含まれた 2 つの Premium SSD ディスクを使用します。Use premium SSD disks for data and log files: If you are not using disk striping, use two premium SSD disks where one disk contains the log file and the other contains the data. ディスクの種類の選択に関する記事に示されているように、各 Premium SSD は、そのサイズに応じた量の IOPS と帯域幅 (MB/秒) を提供します。Each premium SSD provides a number of IOPS and bandwidth (MB/s) depending on its size, as depicted in the article, Select a disk type. 記憶域スペースなどのディスク ストライピング技法を使用している場合は、最適なパフォーマンスを実現するには、2 つのプール (ログ ファイル用に 1 つとデータ ファイル用に 1 つ) を使用します。If you are using a disk striping technique, such as Storage Spaces, you achieve optimal performance by having two pools, one for the log file(s) and the other for the data files. ただし、SQL Server フェールオーバー クラスター インスタンス (FCI) を使用する予定がある場合は、1 つのプールを構成するか、または代わりに Premium ファイル共有を利用する必要があります。However, if you plan to use SQL Server failover cluster instances (FCI), you must configure one pool, or utilize premium file shares instead.

    ヒント

    注意

    SQL Server VM をポータルからプロビジョニングするとき、必要に応じてストレージの構成を編集することができます。When you provision a SQL Server VM in the portal, you have the option of editing your storage configuration. Azure では、実際の構成に応じて 1 つまたは複数のディスクが構成されます。Depending on your configuration, Azure configures one or more disks. 複数のディスクは、ストライピングを使用して 1 つの記憶域プールにまとめられます。Multiple disks are combined into a single storage pool with striping. この構成では、データ ファイルとログ ファイルが一緒に格納されます。Both the data and log files reside together in this configuration. 詳細については、「SQL Server VM のストレージの構成」を参照してください。For more information, see Storage configuration for SQL Server VMs.

  • ディスク ストライピング:スループットを向上させるために、データ ディスクをさらに追加し、ディスク ストライピングを使用できます。Disk striping: For more throughput, you can add additional data disks and use disk striping. データ ディスク数を決定するには、ログ ファイルおよびデータと TempDB ファイルのために必要な IOPS 数と帯域幅を分析する必要があります。To determine the number of data disks, you need to analyze the number of IOPS and bandwidth required for your log file(s), and for your data and TempDB file(s). VM サイズが異なると、サポートされる IOPS 数と帯域幅の制限も変わります。VM サイズごとの IOPS ついて表を参照してください。Notice that different VM sizes have different limits on the number of IOPs and bandwidth supported, see the tables on IOPS per VM size. 次のガイドラインに従ってください。Use the following guidelines:

    • Windows 8/Windows Server 2012 以降の場合は、次のガイドラインに従った記憶域スペースを使用します。For Windows 8/Windows Server 2012 or later, use Storage Spaces with the following guidelines:

      1. パーティションの不整合によるパフォーマンスへの影響を回避するために、OLTP ワークロードの場合はインタリーブ (ストライプ サイズ) を 64 KB (65,536 バイト) に、データ ウェアハウス ワークロードの場合は 256 KB (262,144 バイト) に設定します。Set the interleave (stripe size) to 64 KB (65,536 bytes) for OLTP workloads and 256 KB (262,144 bytes) for data warehousing workloads to avoid performance impact due to partition misalignment. これは、PowerShell を使って設定する必要があります。This must be set with PowerShell.
      2. カラム数 = 物理ディスク数を設定します。Set column count = number of physical disks. 8 つを超えるディスクを構成する場合は PowerShell を使用します (Server Manager の UI ではない)。Use PowerShell when configuring more than 8 disks (not Server Manager UI).

      たとえば、次の PowerShell では記憶域プールが新規作成され、インターリーブ サイズは 64 KB、カラム数はこの記憶域プール内の物理ディスクの容量と等しくなります。For example, the following PowerShell creates a new storage pool with the interleave size to 64 KB and the number of columns equal to the amount of physical disk in the storage pool:

      $PhysicalDisks = Get-PhysicalDisk | Where-Object {$_.FriendlyName -like "*2" -or $_.FriendlyName -like "*3"}
      
      New-StoragePool -FriendlyName "DataFiles" -StorageSubsystemFriendlyName "Storage Spaces*" `
          -PhysicalDisks $PhysicalDisks | New- VirtualDisk -FriendlyName "DataFiles" `
          -Interleave 65536 -NumberOfColumns $PhysicalDisks .Count -ResiliencySettingName simple `
          –UseMaximumSize |Initialize-Disk -PartitionStyle GPT -PassThru |New-Partition -AssignDriveLetter `
          -UseMaximumSize |Format-Volume -FileSystem NTFS -NewFileSystemLabel "DataDisks" `
          -AllocationUnitSize 65536 -Confirm:$false 
      
    • Windows 2008 R2 以前では、ダイナミック ディスク (OS ストライプ ボリューム) を使用できます。ストライプ サイズは常に 64 KB です。For Windows 2008 R2 or earlier, you can use dynamic disks (OS striped volumes) and the stripe size is always 64 KB. このオプションは、Windows 8/Windows Server 2012 の時点で非推奨となっています。This option is deprecated as of Windows 8/Windows Server 2012. 詳細については、Windows Storage Management API に移行しつつある仮想ディスク サービスに関するページでサポートに関する声明をご覧ください。For information, see the support statement at Virtual Disk Service is transitioning to Windows Storage Management API.

    • 記憶域スペース ダイレクト (S2D)SQL Server フェールオーバー クラスター インスタンスで使用している場合は、単一プールを構成する必要があります。If you are using Storage Spaces Direct (S2D) with SQL Server Failover Cluster Instances, you must configure a single pool. その単一プール上にはさまざまなボリュームを作成できますが、それらはすべて同じ特性 (たとえば、同じキャッシュ ポリシー) を共有します。Although different volumes can be created on that single pool, they will all share the same characteristics, such as the same caching policy.

    • 負荷予測に基づいて、ご使用の記憶域プールに関連付けるディスク数を決定します。Determine the number of disks associated with your storage pool based on your load expectations. 接続できるデータ ディスクの数は VM サイズによって異なることに注意してください。Keep in mind that different VM sizes allow different numbers of attached data disks. 詳細については、 仮想マシンのサイズに関するページをご覧ください。For more information, see Sizes for virtual machines.

    • Premium SSD (開発/テスト シナリオ) を使用しない場合は、ご使用の VM サイズでサポートされる最大数のデータ ディスクを追加し、ディスク ストライピングを使用することをお勧めします。If you are not using premium SSDs (dev/test scenarios), the recommendation is to add the maximum number of data disks supported by your VM size and use disk striping.

  • キャッシュ ポリシー:ストレージ構成に応じたキャッシュ ポリシーに対する次の推奨事項に注意してください。Caching policy: Note the following recommendations for caching policy depending on your storage configuration.

    • データとログ ファイル用に別個のディスクを使用する場合は、データ ファイルと TempDB データ ファイルをホストするデータ ディスクで読み取りキャッシュを有効にします。If you are using separate disks for data and log files, enable read caching on the data disks hosting your data files and TempDB data files. これにより、パフォーマンスが大幅に向上する可能性があります。This can result in a significant performance benefit. ログ ファイルを保持するディスクではキャッシュを有効にしないでください。これを行うと、パフォーマンスが多少低下します。Do not enable caching on the disk holding the log file as this causes a minor decrease in performance.

    • 単一ストレージ プールでディスク ストライピングを使用すると、ほとんどのワークロードで読み取りキャッシュのメリットが得られます。If you are using disk striping in a single storage pool, most workloads will benefit from read caching. ログ ファイルとデータ ファイルで異なるストレージ プールを使用している場合は、データ ファイル用のストレージ プールでのみ読み取りキャッシュを有効にします。If you have separate storage pools for the log and data files, enable read caching only on the storage pool for the data files. 書き込みが多いワークロードでは、キャッシュなしのほうがパフォーマンスが向上する場合があります。In certain heavy write workloads, better performance might be achieved with no caching. これは、テストを実行することでのみ判断できます。This can only be determined through testing.

    • これらの推奨事項は、Premium SSD ディスクに適用されます。The previous recommendations apply to premium SSDs. Premium SSD を使用していない場合は、どのデータ ディスクでもキャッシュを有効にしないでください。If you are not using premium SSDs, do not enable any caching on any data disks.

    • ディスク キャッシュの構成手順については、以下の記事をご覧ください。For instructions on configuring disk caching, see the following articles. クラシック (ASM) デプロイ モデルの場合:Set-AzureOSDiskSet-AzureDataDisk に関するページを参照してください。For the classic (ASM) deployment model see: Set-AzureOSDisk and Set-AzureDataDisk. Azure Resource Manager デプロイ モデルについては、Set-AzOSDiskSet-AzVMDataDisk に関するページを参照してください。For the Azure Resource Manager deployment model, see: Set-AzOSDisk and Set-AzVMDataDisk.

      警告

      データベースの破損の可能性を回避するために、Azure Virtual Machines ディスクのキャッシュ設定を変更するときは、SQL Server サービスを停止してください。Stop the SQL Server service when changing the cache setting of Azure Virtual Machines disks to avoid the possibility of any database corruption.

  • NTFS アロケーション ユニット サイズ:データ ディスクをフォーマットするときは、データ ファイルとログ ファイルに加えて TempDB にも 64 KB アロケーション ユニット サイズを使用することをお勧めします。NTFS allocation unit size: When formatting the data disk, it is recommended that you use a 64-KB allocation unit size for data and log files as well as TempDB. TempDB が一時ディスク (D:\ ドライブ) に配置されている場合、このドライブの利用で得られるパフォーマンスのメリットは、64 KB のアロケーション ユニット サイズの必要性を上回ります。If TempDB is placed on the temporary disk (D:\ drive) the performance gained by leveraging this drive outweighs the need for a 64-KB allocation unit size.

  • ディスク管理のベスト プラクティス:データ ディスクの削除またはキャッシュの種類の変更を行う場合、変更中は SQL Server サービスを停止します。Disk management best practices: When removing a data disk or changing its cache type, stop the SQL Server service during the change. OS ディスクでキャッシュ設定が変更されると、Azure は VM を停止し、キャッシュの種類を変更して、VM を再起動します。When the caching settings are changed on the OS disk, Azure stops the VM, changes the cache type, and restarts the VM. データ ディスクのキャッシュ設定が変更されても VM は停止されませんが、変更中、データ ディスクが VM から切断され、その後再接続されます。When the cache settings of a data disk are changed, the VM is not stopped, but the data disk is detached from the VM during the change and then reattached.

    警告

    これらの操作中に、SQL Server サービスの停止を怠ると、データベースが破損するおそれがあります。Failure to stop the SQL Server service during these operations can cause database corruption.

I/O のガイダンスI/O guidance

  • Premium SSD では、アプリケーションと要求の並列処理を実行するときに最良の結果が得られます。The best results with premium SSDs are achieved when you parallelize your application and requests. Premium SSD は、IO キューの深さが 1 より大きいシナリオ向けに設計されているので、シングル スレッド シリアル要求では (ストレージを集中的に使用する場合でも)、パフォーマンスの向上はほとんどまたはまったくありません。Premium SSDs are designed for scenarios where the IO queue depth is greater than 1, so you will see little or no performance gains for single-threaded serial requests (even if they are storage intensive). たとえば、これは、パフォーマンス分析ツール (SQLIO など) のシングル スレッド テストの結果に影響する可能性があります。For example, this could impact the single-threaded test results of performance analysis tools, such as SQLIO.

  • I/O 集中型ワークロードのパフォーマンスを向上させるために、 データベース ページの圧縮 を使用することを検討します。Consider using database page compression as it can help improve performance of I/O intensive workloads. ただし、データ圧縮を使用すると、データベース サーバーでの CPU 消費量が増加する場合があります。However, the data compression might increase the CPU consumption on the database server.

  • 初期ファイル割り当てに必要な時間を短縮するために、ファイルの瞬時初期化を有効にすることを検討します。Consider enabling instant file initialization to reduce the time that is required for initial file allocation. ファイルの瞬時初期化を利用するには、SQL Server (MSSQLSERVER) サービス アカウントに SE_MANAGE_VOLUME_NAME を付与し、 [ボリュームの保守タスクを実行] セキュリティ ポリシーにそのサービス アカウントを追加します。To take advantage of instant file initialization, you grant the SQL Server (MSSQLSERVER) service account with SE_MANAGE_VOLUME_NAME and add it to the Perform Volume Maintenance Tasks security policy. Azure の SQL Server プラットフォーム イメージを使用している場合、既定のサービス アカウント (NT Service\MSSQLSERVER) は、 [ボリュームの保守タスクを実行] セキュリティ ポリシーに追加されません。If you are using a SQL Server platform image for Azure, the default service account (NT Service\MSSQLSERVER) isn’t added to the Perform Volume Maintenance Tasks security policy. つまり、SQL Server Azure プラットフォーム イメージでは、ファイルの瞬時初期化は有効になりません。In other words, instant file initialization is not enabled in a SQL Server Azure platform image. [ボリュームの保守タスクを実行] セキュリティ ポリシーに SQL Server サービス アカウントを追加したら、SQL Server サービスを再起動します。After adding the SQL Server service account to the Perform Volume Maintenance Tasks security policy, restart the SQL Server service. この機能を使用する場合、セキュリティに関する考慮事項があります。There could be security considerations for using this feature. 詳細については、「 データベース ファイルの初期化」をご覧ください。For more information, see Database File Initialization.

  • 自動拡張 は、予想外の増加に付随するものと見なされることに注意してください。Be aware that autogrow is considered to be merely a contingency for unexpected growth. 自動拡張を使用して、データやログの増加に日常的に対処しないでください。Do not manage your data and log growth on a day-to-day basis with autogrow. 自動拡張を使用する場合は、Size スイッチを使用してファイルを事前に拡張します。If autogrow is used, pre-grow the file using the Size switch.

  • パフォーマンスに悪影響を及ぼすおそれのある不要なオーバーヘッドを回避するために、 自動圧縮 が無効になっていることを確認します。Make sure autoshrink is disabled to avoid unnecessary overhead that can negatively affect performance.

  • システム データベースも含め、すべてのデータベースをデータ ディスクに移動します。Move all databases to data disks, including system databases. 詳細については、「 システム データベースの移動」を参照してください。For more information, see Move System Databases.

  • SQL Server エラー ログとトレース ファイルのディレクトリをデータ ディスクに移動します。Move SQL Server error log and trace file directories to data disks. これは、SQL Server インスタンスを右クリックしてプロパティを選択することにより、SQL Server 構成マネージャーで実行できます。This can be done in SQL Server Configuration Manager by right-clicking your SQL Server instance and selecting properties. エラー ログとトレース ファイルの設定は、 [起動時のパラメーター] タブで変更できます。ダンプ ディレクトリは、 [詳細設定] タブで指定します。次のスクリーンショットでは、エラー ログの起動時のパラメーターを検索する場所を示します。The error log and trace file settings can be changed in the Startup Parameters tab. The Dump Directory is specified in the Advanced tab. The following screenshot shows where to look for the error log startup parameter.

    SQL ErrorLog のスクリーンショット

  • 既定のバックアップ ファイルとデータベース ファイルの場所を設定します。Set up default backup and database file locations. この記事では、推奨事項を使用し、[サーバーのプロパティ] ウィンドウで変更を行います。Use the recommendations in this article, and make the changes in the Server properties window. 手順については、「 データ ファイルとログ ファイルの既定の場所の表示または変更 (SQL Server Management Studio)」をご覧ください。For instructions, see View or Change the Default Locations for Data and Log Files (SQL Server Management Studio). 次のスクリーンショットでは、これらの変更を行う場所を示します。The following screenshot demonstrates where to make these changes.

    SQL データのログおよびバックアップ ファイル

  • ロックされたページを有効にして、IO とページング アクティビティを減らします。Enable locked pages to reduce IO and any paging activities. 詳細については、「 Lock Pages in Memory オプションの有効化 (Windows)」をご覧ください。For more information, see Enable the Lock Pages in Memory Option (Windows).

  • SQL Server 2012 を実行している場合は、Service Pack 1 Cumulative Update 10 をインストールします。If you are running SQL Server 2012, install Service Pack 1 Cumulative Update 10. この更新プログラムには、SQL Server 2012 で一時テーブルに対して SELECT INTO ステートメントを実行したときに I/O のパフォーマンスが低下する問題に対処するための修正プログラムが含まれています。This update contains the fix for poor performance on I/O when you execute select into temporary table statement in SQL Server 2012. 詳細については、この サポート技術情報の記事をご覧ください。For information, see this knowledge base article.

  • Azure との間での転送時にデータ ファイルを圧縮することを検討します。Consider compressing any data files when transferring in/out of Azure.

機能固有のガイダンスFeature-specific guidance

一部のデプロイでは、より高度な構成手法を使用することで、パフォーマンスがさらに向上する場合があります。Some deployments may achieve additional performance benefits using more advanced configuration techniques. パフォーマンスの向上を実現する際に役立つ SQL Server の機能を次に示します。The following list highlights some SQL Server features that can help you to achieve better performance:

Azure Storage にバックアップするBack up to Azure Storage

Azure Virtual Machines で実行される SQL Server のバックアップを実行する際は、URL への SQL Server のバックアップを使用できます。When performing backups for SQL Server running in Azure Virtual Machines, you can use SQL Server Backup to URL. SQL Server 2012 SP1 CU2 以降で使用できるこの機能は、接続されているデータ ディスクにバックアップする場合に推奨されます。This feature is available starting with SQL Server 2012 SP1 CU2 and recommended for backing up to the attached data disks. Azure Storage との間でバックアップと復元を行うときは、「SQL Server の URL へのバックアップに関するベスト プラクティスとトラブルシューティング」に記載されている推奨事項に従ってください。When you backup/restore to/from Azure Storage, follow the recommendations provided at SQL Server Backup to URL Best Practices and Troubleshooting and Restoring from Backups Stored in Azure Storage. Azure Virtual Machines 上の SQL Server の自動バックアップを使用して、これらのバックアップを自動化することもできます。You can also automate these backups using Automated Backup for SQL Server on Azure Virtual Machines.

SQL Server 2012 より前のバージョンでは、 SQL Server Backup to Azure Toolを使用できます。Prior to SQL Server 2012, you can use SQL Server Backup to Azure Tool. このツールでは、複数のバックアップ ストライプ ターゲットを使用することで、バックアップ スループットを向上させることができます。This tool can help to increase backup throughput using multiple backup stripe targets.

Azure 内の SQL Server データ ファイルSQL Server Data Files in Azure

Azure 内の SQL Server データ ファイルは、SQL Server 2014 以降で使用できる新機能です。This new feature, SQL Server Data Files in Azure, is available starting with SQL Server 2014. Azure 内のデータ ファイルを使用して SQL Server を実行すると、Azure データ ディスクを使用する場合と同等のパフォーマンス特性が得られます。Running SQL Server with data files in Azure demonstrates comparable performance characteristics as using Azure data disks.

フェールオーバー クラスター インスタンスと記憶域スペースFailover cluster instance and Storage Spaces

記憶域スペースを使用している場合は、 [確認] ページでクラスターにノードを追加するときに、 [使用可能な記憶域をすべてクラスターに追加する] チェック ボックスをオフにします。If you are using Storage Spaces, when adding nodes to the cluster on the Confirmation page, clear the check box labeled Add all eligible storage to the cluster.

使用可能な記憶域をオフにする

記憶域スペースを使っている場合に、 [使用可能な記憶域をすべてクラスターに追加する] をオフにしないと、Windows はクラスター作成処理中に仮想ディスクをデタッチします。If you are using Storage Spaces and do not uncheck Add all eligible storage to the cluster, Windows detaches the virtual disks during the clustering process. その結果、記憶域スペースがクラスターから削除され、PowerShell を使って再アタッチされるまで、仮想ディスクはディスク マネージャーやエクスプローラーに表示されなくなります。As a result, they do not appear in Disk Manager or Explorer until the storage spaces are removed from the cluster and reattached using PowerShell. 記憶域スペースは、複数のディスクを記憶域プールにグループ化します。Storage Spaces groups multiple disks in to storage pools. 詳細については、記憶域スペースに関するページを参照してください。For more information, see Storage Spaces.

複数インスタンスMultiple instances

1 つの仮想マシンに複数の SQL Server インスタンスをデプロイする場合は、次のベスト プラクティスを考慮してください。Consider the following best practices when deploying multiple SQL Server instances to a single virtual machine:

  • SQL Server インスタンスごとに最大サーバー メモリを設定して、オペレーティング システム用のメモリが残されるようにします。Set the max server memory for each SQL Server instance, ensuring there is memory left over for the operating system. 仮想マシンに割り当てるメモリの量を変更する場合は、必ず SQL Server インスタンスのメモリ制限を更新してください。Be sure to update the memory restrictions for the SQL Server instances if you change how much memory is allocated to the virtual machine.
  • データ、ログ、および TempDB にはそれぞれ異なるワークロード パターンがあり、互いに影響を与えないようにするため、それぞれに個別の LUN を用意します。Have separate LUNs for data, logs, and TempDB since they all have different workload patterns and you do not want them impacting each other.
  • アプリケーション SLA 内でピーク ワークロード容量を処理できることを確認するために、高負荷の実稼働環境と同様のワークロードを使用して環境を十分にテストします。Thoroughly test your environment under heavy production-like workloads to ensure it can handle peak workload capacity within your application SLAs.

過剰な負荷がかかっているシステムには、ワーカー スレッドの枯渇、応答の遅延、ディスパッチャー システム メモリの一時停止などの症状があります (ただし、これだけではありません)。Signs of overloaded systems can include, but are not limited to, worker thread exhaustion, slow response times, and/or stalled dispatcher system memory.

パフォーマンス ベースラインの収集Collect performance baseline

より規範的なアプローチとして、PerfMon や LogMan を使用してパフォーマンス カウンターを収集し、SQL Server の待機統計を取り込むと、ソース環境の一般的な負荷と潜在的なボトルネックについて理解を深めることができます。For a more prescriptive approach, gather performance counters using PerfMon/LogMan and capture SQL Server wait statistics to better understand general pressures and potential bottlenecks of the source environment.

まず、アプリケーションのパフォーマンス チェックリストに従って、ピーク時のソース ワークロードの CPU、メモリ、IOPSスループット待機時間などを収集します。Start by collecting the CPU, memory, IOPS, throughput, and latency of the source workload at peak times following the application performance checklist.

ピーク時間中のデータ (通常の営業日のワークロードなど) だけでなく、その他の負荷の高いプロセス (一日の終了時処理、週末の ETL ワークロードなど) も収集します。Gather data during peak hours such as workloads during your typical business day, but also other high load processes such as end-of-day processing, and weekend ETL workloads. 非常に負荷の高いワークロード (四半期の最終日処理など) に合わせてリソースをスケールアップすることを検討し、その後、ワークロードが完了したらスケールダウンします。Consider scaling up your resources for atypically heavily workloads, such as end-of-quarter processing, and then scale done once the workload completes.

パフォーマンス分析を使用して、ワークロードのパフォーマンス要件に合わせてスケール調整できる VM サイズを選択します。Use the performance analysis to select the VM Size that can scale to your workload's performance requirements.

IOPS とスループットIOPS and Throughput

SQL Server のパフォーマンスは、I/O サブシステムに大きく依存します。SQL Server performance depends heavily on the I/O subsystem. データベースが物理メモリに収まらない場合は、SQL Server によってデータベース ページが絶えずバッファー プールに取り込まれたり、バッファー プールから取り出されたりします。Unless your database fits into physical memory, SQL Server constantly brings database pages in and out of the buffer pool. SQL Server のデータ ファイルは、異なる方法で処理する必要があります。The data files for SQL Server should be treated differently. ログ ファイルへのアクセスは順次処理されますが、トランザクションをロールバックする必要がある場合は例外で、その場合はデータ ファイル (TempDB を含む) がランダムにアクセスされます。Access to log files is sequential except when a transaction needs to be rolled back where data files, including TempDB, are randomly accessed. 低速の I/O サブシステムを使用している場合、応答時間が遅い、タイムアウトが原因でタスクが完了しないなど、パフォーマンスの問題が発生する可能性があります。If you have a slow I/O subsystem, your users may experience performance issues such as slow response times and tasks that do not complete due to time-outs.

Azure Marketplace の仮想マシンでは既定で、データ ファイルとは別の物理ディスク上にログ ファイルが置かれています。The Azure Marketplace virtual machines have log files on a physical disk that is separate from the data files by default. TempDB データ ファイルの数とサイズはベスト プラクティスに従い、エフェメラルな D:/ ドライブに配置されます。The TempDB data files count and size meet best practices and are targeted to the ephemeral D:/ drive..

次の PerfMon カウンターは、SQL Server に必要な IO スループットを検証するのに役立ちます。The following PerfMon counters can help validate the IO throughput required by your SQL Server:

  • \LogicalDisk\Disk Reads/Sec (読み取りと書き込みの IOPS)\LogicalDisk\Disk Reads/Sec (read and write IOPS)
  • \LogicalDisk\Disk Writes/Sec (読み取りと書き込みの IOPS)\LogicalDisk\Disk Writes/Sec (read and write IOPS)
  • \LogicalDisk\Disk Bytes/Sec (データ、ログ、および TempDB ファイルのスループット要件)\LogicalDisk\Disk Bytes/Sec (throughput requirements for the data, log, and TempDB files)

ピーク時の IOPS とスループットの要件を使用して、測定値から得られた容量に対応する VM サイズを評価します。Using IOPS and throughput requirements at peak levels, evaluate VM sizes that match the capacity from your measurements.

ワークロードが 20 K の読み取り IOPS と 10K の書き込み IOPS を必要としている場合は、E16s_v3 (最大 32 K のキャッシュありと 25600 のキャッシュなし IOPS)、または記憶域スペースを使用してストライピングされた 2 つの P30 ディスクを備えた M16_s (最大 20 K のキャッシュありと 10K のキャッシュなし IOPS) のどちらかを選択できます。If your workload requires 20 K read IOPS and 10K write IOPS, you can either choose E16s_v3 (with up to 32 K cached and 25600 uncached IOPS) or M16_s (with up to 20 K cached and 10K uncached IOPS) with 2 P30 disks striped using Storage Spaces.

VM には IOPS とスループットに対して異なるスケールの制限があるため、ワークロードのスループットと IOPS の両方の要件を把握するようにしてください。Make sure to understand both throughput and IOPS requirements of the workload as VMs have different scale limits for IOPS and throughput.

メモリMemory

OS によって使用される外部メモリと、SQL Server によって内部的に使用されるメモリの両方を追跡します。Track both external memory used by the OS as well as the memory used internally by SQL Server. どちらかのコンポーネントの負荷を特定すると、仮想マシンのサイズを調整し、チューニングの機会を見極めることができます。Identifying pressure for either component will help size virtual machines and identify opportunities for tuning.

次の PerfMon カウンターは、SQL Server 仮想マシンのメモリの正常性を検証するのに役立ちます。The following PerfMon counters can help validate the memory health of a SQL Server virtual machine:

コンピューティングと処理Compute / Processing

Azure におけるコンピューティングは、オンプレミスとは異なる方法で管理されます。Compute in Azure is managed differently than on-premises. オンプレミスのサーバーは、管理のオーバーヘッドや新しいハードウェアを取得するためのコストが原因で、アップグレードしなくても数年間は持ちこたえるように作られています。On-premises servers are built to last several years without an upgrade due to the management overhead and cost of acquiring new hardware. 仮想化によってこうした問題の一部は緩和されますが、アプリケーションは基になるハードウェアを最大限に生かせるように最適化されます。つまり、リソース消費の大幅な変更には、物理環境全体の再調整が必要になります。Virtualization mitigates some of these issues but applications are optimized to take the most advantage of the underlying hardware, meaning any significant change to resource consumption requires rebalancing the entire physical environment.

さまざまなハードウェア シリーズ (異なるリージョンであっても) 上に新しい仮想マシンが配置されている Azure において、これは簡単に達成できる課題ではありません。This is not a challenge in Azure where a new virtual machine on a different series of hardware, and even in a different region, is easy to achieve.

Azure では、お客様は仮想マシンのリソースをできるだけ多く利用したいと考えているため、ワークロードに影響を与えることなく、平均 CPU を可能な限り高く保つように Azure 仮想マシンを構成する必要があります。In Azure, you want to take advantage of as much of the virtual machines resources as possible, therefore, Azure virtual machines should be configured to keep the average CPU as high as possible without impacting the workload.

次の PerfMon カウンターは、SQL Server 仮想マシンのコンピューティングの正常性を検証するのに役立ちます。The following PerfMon counters can help validate the compute health of a SQL Server virtual machine:

  • \Processor Information(_Total)% Processor Time\Processor Information(_Total)% Processor Time
  • \Process(sqlservr)% Processor Time\Process(sqlservr)% Processor Time

注意

コンピューティングの 80% の使用を目指し、ピーク時は一定期間にわたって 90% を超えても 100% には達しないようにするのが理想です。Ideally, try to aim for using 80% of your compute, with peaks above 90% but not reaching 100% for any sustained period of time. 基本的にお客様は、アプリケーションに必要なコンピューティングだけをプロビジョニングし、その後、ビジネスの要件に応じてスケールアップまたはスケールダウンしたいと考えています。Fundamentally, you only want to provision the compute the application needs and then plan to scale up or down as the business requires.

次のステップNext steps

セキュリティのベスト プラクティスについては、「Azure Virtual Machines 上の SQL Server のセキュリティに関する考慮事項」をご覧ください。For security best practices, see Security considerations for SQL Server on Azure Virtual Machines.

SQL Server Virtual Machines に関する他の記事については、Azure Virtual Machines 上の SQL Server の概要に関するページをご覧ください。Review other SQL Server Virtual Machine articles at SQL Server on Azure Virtual Machines Overview. SQL Server の仮想マシンに関するご質問については、よくあるご質問に関するページをご覧ください。If you have questions about SQL Server virtual machines, see the Frequently Asked Questions.