ストレージ: Azure VM 上の SQL Server のパフォーマンスに関するベスト プラクティス

適用対象: Azure VM 上の SQL Server

この記事では、Azure 仮想マシン (VM) 上の SQL Server のパフォーマンスを最適化するための、ストレージのベスト プラクティスおよびガイドラインについて説明します。

通常、コストの最適化とパフォーマンスの最適化はトレードオフの関係になっています。 このパフォーマンスに関するベスト プラクティス シリーズでは、Azure VM の SQL Server で "最善の" パフォーマンスを得ることに重点を置いています。 ワークロードの要求が厳しくない場合は、推奨される最適化がすべて必要になるわけではありません。 各推奨事項を評価するときに、パフォーマンスのニーズ、コスト、およびワークロードのパターンを考慮してください。

詳しくは、このシリーズ記事 (チェックリスト、VM のサイズ、セキュリティ、HADR の構成、ベースラインの収集) の他の記事をご覧ください。

チェック リスト

次のチェックリストを参照して、この記事の残りの部分で詳しく説明されているストレージのベスト プラクティスの概要を確認してください。

• ディスクの種類を選択する前に、アプリケーションを監視し、SQL Server のデータ、ログ、および tempdb の各ファイルのストレージ帯域幅と待機時間の要件を判断します。
• 使用可能な場合は、D: ローカル SSD ボリュームで tempdb データとログ ファイルを構成します。 SQL IaaS Agent 拡張機能は、再プロビジョニング時に必要なフォルダーとアクセス許可を処理します。
• ストレージのパフォーマンスを最適化するには、キャッシュ不使用時の使用可能な最大の IOPS を計画し、データ読み取りのパフォーマンス機能としてデータ キャッシュを使用する一方で、仮想マシンとディスクの上限を回避します。
• Ebdsv5 または Ebsv5 シリーズの SQL Server VM を使用する場合は、最適な価格パフォーマンスをプレミアム SSD v2 を使用します。 AZURE portal (現在プレビュー段階) を使用して、プレミアム SSD v2 を使用して SQL Server VM を配置できます。
• 別々のドライブにデータ、ログ、および tempdb の各ファイルを配置します。
  • データ ドライブには、Premium P30 と P40 あるいはそれより小さいディスクを使用して、キャッシュ サポートの可用性を確保します。 Ebdsv5 VM シリーズを使用する場合は、高い IOPS と I/O スループットを必要とするワークロードの価格パフォーマンスを向上させる Premium SSD v2 を使用します。
  • ログ ドライブについては、Premium SSD v2 または Premium SSD P30 - P80 ディスクのどちらかを評価しながら、容量を計画し、コスト パフォーマンスをテストします
    • ミリ秒未満のストレージ待機時間が求められる場合は、トランザクション ログに Premium SSD v2 または Azure Ultra Disks を使用します。
    • M シリーズの仮想マシンを展開するには、Azure Ultra ディスクを使用するよりも、書き込みアクセラレータを検討してください。
  • 最適な VM サイズを選択した後、フェールオーバー クラスター インスタンス (FCI) の一部ではないほとんどの SQL Server ワークロード用の一時ディスク (一時ディスクはエフェメラルで、既定では D:\) に tempdb を配置します。
    • ローカル ドライブの容量が tempdb に対して十分でない場合は、VM のサイズを増やすことを検討します。 詳細については、「データ ファイルのキャッシュ ポリシー」を参照してください。
  • フェールオーバー クラスター インスタンス (FCI) の場合は、tempdb共有ストレージ上に配置されます。
    • FCI ワークロードが tempdb ディスクのパフォーマンスに大きく依存する場合、高度な構成として、FCI ストレージに属さないローカル エフェメラル SSD (既定は D:\) ドライブに tempdb を配置します。 ローカル エフェメラル SSD (既定は D:\) ドライブで障害が発生しても、FCI からアクションはトリガーされないため、この構成では、このドライブを常時確実に使用できるようにするためのカスタムの監視とアクションが必要になります。
• 記憶域スペースを使用して複数の Azure データ ディスクをストライピングし、ターゲット仮想マシンの IOPS およびスループットの上限まで I/O 帯域幅を増やします。
• データ ファイル ディスクの場合は、[ホスト キャッシュ] を [読み取り専用] に設定します。
• ログ ファイル ディスクの場合は、[ホスト キャッシュ] を [なし] に設定します。
  • SQL Server のデータまたはログ ファイルが含まれているディスクでは、読み取り/書き込みキャッシュを有効にしないでください。
  • ディスクのキャッシュ設定を変更する前に、必ず SQL Server サービスを停止してください。
• 複数の異なるワークロードをクラウドに移行する場合、 Azure Elastic SAN はコスト効率の高い統合ストレージ ソリューションになります。 ただし、Azure Elastic SAN を使用する場合、SQL Server ワークロードで必要な IOPS/スループットを実現するには、多くの場合、容量のオーバープロビジョニングが必要になります。 通常、単一の SQL Server ワークロードには適していませんが、低パフォーマンスのワークロードと SQL Server を組み合わせると、コスト効率の高いソリューションを実現できます。
• 開発とテストのワークロード、および長期的なバックアップのアーカイブでは、Standard Storageの使用を検討してください。 運用環境のワークロードには Standard HDD または SSD を使わないことをお勧めします。
• クレジットベースのディスク バースト (P1 から P20) は、小規模な開発またはテストのワークロードおよび部門別システムでのみ検討してください。
• ストレージのパフォーマンスを最適化するには、使用可能な最大の未キャッシュ IOPS を計画し、データの読み取りのパフォーマンス機能としてデータ キャッシュを使用しながら、仮想マシンとディスクの上限や調整を回避します。
• ドライブに配置されるすべてのデータ ファイルに 64 KB アロケーション ユニット サイズを使用するように、データ ディスクをフォーマットします。ただし、一時 D:\ ドライブ (既定値は 4 KB) 以外が対象です。 Azure Marketplace を通じてデプロイされた SQL Server VM には、アロケーション ユニット サイズでフォーマットされたデータ ディスクが付属しており、64 KB に設定された記憶域プールに対してインターリーブします。
• ストレージ アカウントは、SQL Server VM と同じリージョンに構成します。
• ストレージ アカウントで Azure geo 冗長ストレージ (geo レプリケーション) を無効にし、LRS (ローカル冗長ストレージ) を使用します。
• SQL ベスト プラクティス評価を有効にして、考えられるパフォーマンスの問題を特定し、ベスト プラクティスに従って SQL Server VM が構成されていることを評価します。
• ストレージ IO 使用率メトリックを使用して、ディスクと VM の制限を確認および監視します。
• ウイルス対策ソフトウェアのスキャンから、データ ファイル、ログ ファイル、バックアップ ファイル などの SQL Server ファイルを除外します。

このストレージのチェックリストを他のベスト プラクティスと比較するには、総合的なパフォーマンスのベスト プラクティスのチェックリストをご覧ください。

概要

Azure VM での SQL Server ワークロードの最も効果的な構成を見つけるには、まずビジネス アプリケーションのストレージ パフォーマンスを測定します。 ストレージの要件がわかったら、必要な IOPS とスループットを適切なメモリ対仮想コアの比率でサポートする仮想マシンを選択します。

ワークロードに必要なストレージのスケーラビリティを備えた VM サイズと、実際のビジネスの容量とパフォーマンスの要件を満たすディスクの組み合わせ (通常は 1 つのストレージ プールに属する) を選択します。

ディスクの種類は、ディスクでホストされているファイルの種類と、ピーク時のパフォーマンス要件によって異なります。

ヒント

Azure portal を通じて SQL Server VM をプロビジョニングすると、ストレージ構成プロセスに従って、データとログ ファイル用に個別の記憶域プールを作成したり、tempdb を D:\ ドライブに配置したり、最適なキャッシュ ポリシーを有効にしたりするなど、ストレージのほとんどのベスト プラクティスを実装できます。 ストレージのプロビジョニングと構成の詳細については、SQL VM ストレージの構成に関する記事を参照してください。

VM ディスクの種類

ディスクのパフォーマンス レベルを選択できます。 基になるストレージとして使用できるマネージド ディスクの種類は (パフォーマンス向上能力が低いものから高いものの順に) Standard ハード ディスク ドライブ (HDD)、Standard ソリッドステート ドライブ (SSD)、Premium SSD、Premium SSD v2、および Ultra Disks です。

Standard HDD、Standard SSD、Premium SSD では、ディスクのパフォーマンスが、ディスクのサイズに従って増加します。これは、4 GiB の容量と 120 の IOPS を持つ P1 から、32 TiB のストレージと 20,000 の IOSP を持つ P80 まで、Premium ディスク ラベルでグループ分けされます。 Premium Storage では、一部のワークロードの読み取りと書き込みのパフォーマンスを向上させるストレージ キャッシュがサポートされています。 詳細については、マネージド ディスクの概要に関する記事を参照してください。

Premium SSD v2 と Ultra Disks のパフォーマンスは、ディスクのサイズとは無関係に変更できます。詳細については、「Ultra ディスクのパフォーマンス」と「Premium SSD v2 のパフォーマンス」を参照してください。

Azure VM 上の SQL Server として考慮すべき主なディスクのロールとして、OS ディスク、一時ディスク、データ ディスクの 3 種類があります。 オペレーティング システム ドライブと(C:\)エフェメラル一時ドライブに格納される内容を慎重に選択してください(D:\)。

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

オペレーティング システム ディスクは、実行中のバージョンのオペレーティング システムとして起動およびマウントできる VHD であり、C:\ ドライブとしてラベル付けされます。 Azure VM を作成すると、プラットフォームによって、少なくとも 1 つのディスクがオペレーティング システム ディスク用に VM に接続されます。 C:\ ドライブは、アプリケーションのインストールとファイルの構成の既定の場所です。

運用環境の SQL Server 環境では、データ ファイル、ログ ファイル、エラー ログにオペレーティング システム ディスクを使用しないでください。

一時ディスク

Azure VM には、一時ディスクと呼ばれる別の種類のディスク (D:\ ドライブとしてラベル付けされる) が含まれています。 VM のシリーズとサイズにより、このディスクの容量は異なります。 一時ディスクは一過性のものです。つまり、VM が再起動されたり、(サービス復旧などの目的で) 別のホストに移動されたりすると、ディスク ストレージは再作成されます (割り当てが解除され、再度割り当てられる)。

一時ストレージ ドライブはリモート ストレージに保存されないため、ユーザー データベース ファイル、トランザクション ログ ファイル、および保存する必要があるものはここに保存しないでください。 たとえば、バッファー プール拡張機能、ページ ファイル、tempdb に使用できます。

ローカル キャッシュの使用に懸念がある場合を除き、tempdb は、SQL Server ワークロード用のローカル一時 SSD の D:\ ドライブに配置してください。 一時ディスクがない VM を使用している場合は、キャッシュを読み取り専用に設定して、独自の分離ディスクまたはストレージ プールに tempdb を配置することをお勧めします。 詳細については、「tempdb データ キャッシュ ポリシー」を参照してください。

データ ディスク

データ ディスクはリモート ストレージ ディスクであり、多くの場合、1 つのディスクが VM に提供できる容量とパフォーマンスを拡大するために、ストレージ プールに作成されます。

ワークロードの IOPS、スループット、および容量の要件を満たす最小ディスク数を接続します。 サイズ変更する予定の最小の VM のデータ ディスクの最大数を超えないようにしてください。

データ ファイルとログ ファイルは、パフォーマンス要件に最も適した形でプロビジョニングされたデータ ディスクに配置してください。

ドライブに配置されるすべてのデータ ファイルに 64 KB アロケーション ユニット サイズを使用するように、データ ディスクをフォーマットします。ただし、一時 D:\ ドライブ (既定値は 4 KB) 以外が対象です。 Azure Marketplace を通じてデプロイされた SQL Server VM には、アロケーション ユニット サイズでフォーマットされたデータ ディスクが付属しており、64 KB に設定された記憶域プールに対してインターリーブします。

Note

Azure Blob Storage 上、または Azure Premium ファイル共有などの SMB ストレージ上で直接 SQL Server データベース ファイルをホストすることもできますが、最適なパフォーマンス、信頼性、機能の可用性を実現するためには、Azure マネージド ディスクを使用することをお勧めします。

Premium SSD v2

現在の制限が環境に適している場合は、サポートされているリージョンで SQL Server ワークロードを実行するときにPremium SSD v2 ディスクを使用する必要があります。 構成によっては、Premium SSD v2 は Premium SSD よりも低コストになり、パフォーマンスも向上します。 Premium SSD v2 では、ディスクのサイズとは別にスループットまたは IOPS を個別に調整できます。 パフォーマンス オプションを個別に調整できるため、コストを大幅に削減でき、予想されるまたは既知の必要な期間中にパフォーマンス要件を満たすように変更をスクリプト化できます。

Ebdsv5 VM シリーズまたはEbsv5 仮想マシンを使用する場合は、Premium SSD v2 を使用することをお勧めします。このような高い I/O スループットのマシンでは、コスト効率の高いソリューションになるためです。

AZURE portal (現在プレビュー段階) を使用して、プレミアム SSD v2を使用してSQL Server VM を配置できます。

Azure portal を使用して SQL Server VM をデプロイし、SSD v2 プレミアム使用する場合、現在は Ebdsv5 または Ebsv5 シリーズの仮想マシンに制限されています。 しかし、Premium SSD v2ストレージを使用してVMを手動で作成し、そのVMにSQL Serverを手動でインストールする場合、Premium SSD v2をサポートする任意のVMシリーズを使用することができます。 拡張機能によって提供されるすべての利点を利用できるように、SQL Server VM を SQL IaaS Agent 拡張機能に登録してください。

Azure Elastic SAN

Azure Elastic SAN は、ストレージの統合によってコストを削減することのできる、柔軟でスケーラブルなソリューションを顧客に提供する、ネットワーク接続ストレージ オファリングです。 Azure Elastic SAN は、iSCSI プロトコル経由でさまざまな Azure コンピューティング サービスに接続する、コスト効率が高く、高パフォーマンスで信頼性の高いブロック ストレージ ソリューションを提供します。 Elastic SAN を使用すると、顧客のアプリケーション アーキテクチャをリファクタリングすることなく、既存の SAN ストレージ資産からクラウドにシームレスに移行できます。

このソリューションでは、数百万単位の IOPS へのスケールアップ、数十 GB/秒単位のスループット、1 桁ミリ秒の短い待機時間を実現でき、ダウンタイムを最小化するための回復性が組み込まれています。 ストレージを統合したり、複数のコンピューティング サービスを操作したりする必要がある場合や、ネットワーク帯域幅経由でストレージを駆動するときに高いスループット レベルを必要とするワークロードがある場合は、Azure Elastic SAN を使用してください。 ただし、SQL Server ワークロードで必要な IOPS/スループットを実現するには、多くの場合、オーバープロビジョニング容量が必要になるため、一般に、単一の SQL Server ワークロードには適していません。 最もコスト効率の高いソリューションを実現するには、他の低パフォーマンスワークロードと SQL Server の組み合わせが必要になる場合があります。

Azure Elastic SAN の VM のサイズ設定とパフォーマンスを検討するときは、ストレージ通信がネットワーク経由で行われることを理解することが重要です。 たとえば、VM サイズ E4d_v5 は Azure Premium Storage をサポートしていませんが、Azure Elastic SAN では最大 12,500 Mbps のネットワーク スループットをサポートするため、適切に機能します。 この VM サイズで Azure Elastic SAN を使用する場合は、ワークロードのネットワークとストレージのスループット要件が 12,500 Mbps のネットワーク スループット制限を満たすことを確認する必要があります。

Azure Elastic SAN を使用して SQL Server VM をデプロイする前にネットワークとストレージの要件を決定し、ネットワークとストレージの使用率を慎重に監視して、選択した VM がワークロードに対応できることを確認します。 詳細については、「Elastic SAN での VM のパフォーマンス」および「Elastic SAN のメトリック」をご覧ください。

注意事項

• Elastic SAN を使用した VM のサイズ設定では、ストレージ スループットおよび、本番環境 (VM から VM) のネットワーク スループット要件に対応する必要があります。 Elastic SAN を使用する場合、IO スループットを最適化する VM サイズは、ネットワーク帯域幅を最適化する VM サイズに比べると、コスト効率が高くない場合があります。

コスト効率の向上のため、SQL Server ワークロードを Elastic SAN に配置することを検討してください。その理由は以下の通りです:

• ストレージの統合と動的なパフォーマンス共有: 通常、Azure VM ワークロード上の SQL Server の場合、ディスク ストレージは、容量とその VM のピーク パフォーマンス要件に基づいて VM ごとにプロビジョニングされます。 このオーバープロビジョニングされたパフォーマンスは、必要に応じて使用できますが、使用されていないパフォーマンスを他の VM 上のワークロードと共有することはできません。 オンプレミス SAN と同様に、Elastic SAN を使用すると、複数の SQL ワークロードと SQL 以外のワークロードのストレージ ニーズを統合して、コスト効率を向上させることができます。また、入出力の要求に基づいて、これらの異なるワークロードにプロビジョニングされた個別のボリューム間で利用可能なパフォーマンスを動的に共有できます。 たとえば、米国東部リージョンで、それぞれ 2 TiB の容量と 10,000 IOPS を必要とするワークロードが 10 個ありますが、いかなる時点でも合計 60,000 IOPS 以上は必要ない場合を考えてみます。 この場合、Elastic SAN は、12 の基本ユニット (1 基本ユニット = GiB/月あたり 0.08 ドル) で構成し、12 TiB の容量と必要な 60,000 IOPS、および 8 個の容量専用ユニット (1 容量専用ユニット = GiB/月あたり $0.06) を使用して、残りの8 TiB の容量を低価格で利用できます。 この最適なストレージ構成により、各ワークロードに必要なパフォーマンス (10,000 IOPS) を提供しながら、コスト効率を向上させることができます。 Elastic SAN 基本および容量専用プロビジョニング ユニットの詳細については、「Azure Elastic SAN の計画」を参照してください。価格については、「Azure Elastic SAN - 価格」をご覧ください。
• より高いストレージ スループットを実現するには: Azure VM 上の SQL Server のデプロイでは、その VM のディスク スループット制限のために VM のオーバープロビジョニングが必要な場合があります。 しかし Elastic SAN であれば、iSCSI プロトコルを使用してコンピューティング ネットワーク帯域幅全体で高いストレージ スループットを実現するため、オーバープロビジョニングを回避できます。 たとえば、Standard_E32ds_v5 VM の上限は 51,200 IOPS、ディスク/ストレージ スループットは 865 MBps ですが、最大 2,000 MBps のネットワーク スループットを実現できます。 Elastic SAN であれば最大 2,000 MBps をサポートできるため、ワークロードのストレージ スループット要件が 865 MBps を超えても VM をより高い SKU にアップグレードする必要はありません。

Premium SSD

運用 SQL Server ワークロードのデータ ファイルとログ ファイルには、Premium SSD を使用します。 Premium SSD の IOPS と帯域幅は、ディスクのサイズと種類によって異なります。

運用環境のワークロードの場合は、SQL Server のデータ ファイルに P30 ディスクまたは P40 ディスクを使用してキャッシュのサポートを確保し、SQL Server トランザクション ログ ファイルには P30 から P80 を使用します。 総保有コストを最大限に高めるには、データ ファイルとログ ファイルには P30 (5000 IOPS/200 MBps) から開始し、VM のディスク数を制御する必要がある場合にのみ、より高い容量を選択します。 Dev/Test または小規模システムでは、キャッシュをサポートするため、P30 より小さいサイズを使用することを選択できますが、予約価格は提供されません。

OLTP ワークロードの場合は、ピーク時のワークロードと Disk Reads/sec + Disk Writes/sec パフォーマンス カウンターを使用して、ディスクあたりのターゲット IOPS (または記憶域プール) とパフォーマンス要件を一致させます。 データ ウェアハウスとレポートのワークロードでは、ピーク時と Disk Read Bytes/sec + Disk Write Bytes/sec のワークロードを使用してターゲットのスループットに適合させます。

記憶域スペースを使用して最適なパフォーマンスを達成し、2 つのプール (ログ ファイル用とデータ ファイル用にそれぞれ 1 つずつ) を構成します。 ディスク ストライピングを使用していない場合は、1 つのディスクにログ ファイルが含まれ、もう 1 つにデータが含まれた 2 つの Premium SSD ディスクを使用します。

記憶域プールの一部として使用される、ディスクあたりのプロビジョニングされた IOPS とスループット。 ディスクの総合的な IOPS とスループットの能力は、VM のスループット上限までの最大能力です。

ベスト プラクティスは、IOPS (およびスループット) と容量の最小要件を満たす一方で、できるだけ少ない数のディスクを使用することです。 ただし、価格とパフォーマンスのバランスは、小容量のディスクを多数使用した方が、大容量ディスクを少数使用した場合よりも、良くなる傾向があります。

Premium ディスクをスケーリングする

Premium SSD のサイズによって、ディスクの初期パフォーマンス レベルが決まります。 パフォーマンス レベルは、デプロイ時に指定するか、またはその後にディスクのサイズを変えずに変更できます。 需要が増えた場合、ビジネス ニーズに合わせてパフォーマンス レベルを上げることができます。

パフォーマンス レベルを変更すると、管理者は、ディスクのバースト機能を使用せずに、より高い需要に備え、対応することができます。

ストレージのパフォーマンス レベルを満たすように課金が設計されている場合には、必要な期間だけ、より高いパフォーマンス レベルを使用します。 容量を増やすことなく、パフォーマンス要件に合わせてレベルをアップグレードします。 パフォーマンス増加が不要になった場合は、元のレベルに戻します。

パフォーマンスに関するこのコスト効率の高い、一時的な拡張は、高いパフォーマンスが短期間だけ必要となる、ショッピング、パフォーマンス テスト、トレーニング イベント、その他の短期の対象イベントにとって強力なユースケースです。

詳細については、「マネージド ディスクのパフォーマンス レベル」を参照してください。

Azure Ultra ディスク

待機時間を短縮し、ミリ秒未満の応答時間が必要な場合は、SQL Server ログ ドライブに Azure Ultra Disk を使用するか、I/O 待機時間が非常に重要なアプリケーション用のデータ ドライブを使用することを検討してください。

容量と IOPS を個別にスケーリングできるように、Ultra Disk を構成できます。 Ultra Disk を使用すると、管理者は、アプリケーションのニーズに基づいて、容量、IOPS、スループットの要件を備えたディスクをプロビジョニングできます。

Ultra ディスクはすべての VM シリーズでサポートされているわけではなく、リージョンの可用性、冗長性、Azure Backup のサポートなど、その他の制限があります。 制限の一覧については、「Azure Ultra ディスクの使用」を参照してください。

Standard の HDD と SSD

Standard の HDD と SSD には、さまざまな待機時間や帯域幅があり、開発/テストのワークロードにのみ推奨されます。 運用環境のワークロードでは、Premium SSD v2 または Premium SSD を使用する必要があります。 Standard SSD (Dev/Test シナリオ) を使用している場合は、最良のパフォーマンスを得るために、ご使用の VM サイズでサポートされる最大数のデータ ディスクを追加し、ストレージ スペースでディスク ストライピングを使用することをお勧めします。

キャッシュ

Premium Storage キャッシュをサポートする VM では、Azure BlobCache またはホスト キャッシュと呼ばれる追加機能を利用して、VM の IOPS とスループットの機能を拡張することができます。 Premium Storage と Premium Storage キャッシュの両方に対応した VM では、これら 2 つの異なるストレージ帯域幅の制限があり、これらを組み合わせて使用することでストレージのパフォーマンスを向上できます。

キャッシュを使用しない IOPS と MBps のスループットは、VM のキャッシュ不使用時のディスク スループット上限に対して不利に作用します。 最大キャッシュ制限によって、読み取り用にもう 1 つのバッファーが提供され、増加や予想外のピークに対処できます。

Premium キャッシュは追加コストなしでデータ ドライブに対する読み取りのパフォーマンスを大幅に向上させるため、このオプションがサポートされている場合には常に有効にしてください。

Azure BlobCache (キャッシュ使用時の IOPS とスループット) の読み取りと書き込みは、VM のキャッシュ不使用時の IOPS とスループットの上限に対して不利に作用しません。

Note

4 TiB 以上のディスク (P50 以上) では、ディスク キャッシュはサポートされていません。 複数のディスクが VM に接続されている場合、4 TiB 未満の各ディスクでは、キャッシュがサポートされます。 詳細については、「ディスク キャッシュ」を参照してください。

キャッシュ不使用時のスループット

キャッシュ不使用時のディスクの最大の IOPS とスループットは、VM が処理できるリモート ストレージの上限になります。 この上限は VM で定義されており、基になるディスク ストレージの上限ではありません。 この上限は、VM にリモート接続されたデータ ドライブに対する I/O のみに適用され、一時ドライブ (D:\ ドライブ) や OS ドライブに対するローカル I/O には適用されません。

VM で使用できるキャッシュ不使用時の IOPS とスループットの量は、お使いの VM のドキュメントで確認できます。

たとえば、M シリーズのドキュメントでは、Standard_M8ms VM のキャッシュ不使用時の最大スループットについては IOPS が 5,000、キャッシュ不使用時のディスク スループットが 125 MBps であることが示されています。

同様に、Standard_M32ts は、キャッシュ不使用時のディスク IOPS として 20,000、キャッシュ不使用時のディスク スループットとして 500 MBps をサポートしていることがわかります。 この制限は、基になる Premium ディスク ストレージに関係なく、VM レベルで管理されます。

詳細については、キャッシュ不使用時とキャッシュ使用時の上限に関する記事を参照してください。

キャッシュが有効な場合の一時ストレージのスループット

キャッシュが有効な場合の一時ストレージの最大スループットの上限は、VM のキャッシュ不使用時のスループットの上限とは別です。 Azure BlobCache は、VM ホストのランダムアクセス メモリとローカルに接続された SSD の組み合わせで構成されます。 VM 内の一時ドライブ (D:\ ドライブ) も、このローカル SSD でホストされています。

キャッシュが有効な場合の一時ストレージの最大スループット上限は、ホストキャッシュが有効になっている場合にのみ、ローカル一時ドライブ (D:\ ドライブ) と Azure BlobCache e に対する I/O を制御します。

Premium Storage でキャッシュを有効にすると、VM は、リモート ストレージのキャッシュ不使用時の VM の IOPS とスループットの上限を超えて拡張できます。

特定の VM のみが、Premium Storage と Premium Storage キャッシュの両方をサポートしています (仮想マシンのドキュメントで確認する必要があります)。 たとえば、M シリーズのドキュメントには、Premium Storage と Premium Storage キャッシュの両方がサポートされていることが示されています。

キャッシュの上限は、VM のサイズによって異なります。 たとえば、Standard_M8ms VM では、キャッシュが有効な場合のディスク IOPS として 10000、キャッシュが有効な場合のディスク スループットとして 1000 MBps がサポートされ、合計キャッシュサイズは 793 GiB です。 同様に、Standard_M32ts VM では、キャッシュが有効な場合のディスク IOPS として 40000、キャッシュが有効な場合のディスク スループットとして 400 MBps がサポートされ、合計キャッシュサイズは 3,174 GiB です。

既存の VM でホスト キャッシュを手動で有効にすることができます。 VM のキャッシュ ポリシーに変更を加える前に、すべてのアプリケーション ワークロードと SQL Server サービスを停止してください。 VM のキャッシュ設定を変更すると、ターゲット ディスクがデタッチされ、設定が適用された後に再アタッチされます。

データ ファイルのキャッシュ ポリシー

ストレージ キャッシュ ポリシーは、ドライブでホストされている SQL Server データ ファイルの種類によって異なります。

次の表は、SQL Server データの種類に基づいて推奨されるキャッシュ ポリシーの概要を示しています。

SQL Server ディスク	推奨
データ ディスク	SQL Server データ ファイルをホストするディスクの Read-only キャッシュを有効にします。 キャッシュからの読み取りは、データ ディスクからのキャッシュ不使用時の読み取りよりも高速です。 キャッシュ不使用時の IOPS とスループットに加え、キャッシュが有効な場合の IOPS とスループットによって、VM の制限内で、VM から利用可能なパフォーマンスの合計が得られますが、実際のパフォーマンスは、ワークロードのキャッシュ使用能力 (キャッシュ ヒット率) によって異なります。
トランザクション ログ ディスク	トランザクション ログをホストするディスクのキャッシュ ポリシーを None に設定します。 トランザクション ログ ディスクのキャッシュを有効にしてもパフォーマンス上の利点はありません。それだけではなく、ログ ドライブで Read-only または Read/Write のキャッシュを有効にすると、ドライブに対する書き込みのパフォーマンスが低下し、データ ドライブの読み取りに使用できるキャッシュの量が減少することがあります。
OS ディスクの運用	OS ドライブの既定のキャッシュ ポリシーは Read/write です。 OS ドライブのキャッシュ レベルは変更しないことをお勧めします。
tempdb	容量の理由により、tempdb を一時ドライブ D:\ に配置できない場合、VM のサイズを変更して、より大きな一時ドライブを取得するか、Read-only キャッシュが構成された別のデータドライブに tempdb を配置します。 VM のキャッシュと一時ドライブはどちらもローカル SSD を使用します。そのため、サイズ変更する際には、一時ドライブでホストされると、tempdb の I/O が、キャッシュが有効な IOPS とスループットの VM 上限に対して不利に作用することに注意してください。

重要

Azure ディスクのキャッシュ設定を変更すると、対象となるディスクをデタッチして再アタッチします。 SQL Server のデータ、ログ、またはアプリケーション ファイルがホストされているディスクのキャッシュ設定を変更するときは、データが破損しないように、SQL Server サービスと共に他の関連サービスを停止してください。

詳細については、「ディスク キャッシュ」を参照してください。

ディスク ストライピング

ログ ファイルと tempdb を含む、SQL Server データ ファイルに必要なスループットと帯域幅を分析し、データ ディスクの数を判断します。 スループットと帯域幅の制限は、VM のサイズによって異なります。 詳しくは、VM サイズをご覧ください。

データ ディスクをさらに追加し、ディスク ストライピングを使用してスループットを向上させてください。 たとえば、12,000 IOPS と 180 MB/秒のスループットを必要とするアプリケーションでは、ストライピングされた 3 つの P30 ディスクを使用して 15000 IOPS と 600 MB/秒のスループットを提供できます。

ディスク ストライピングを構成するには、「ディスク ストライピング」を参照してください。

ディスクの上限

ディスクと VM の両方のレベルでスループットの上限があります。 IOPS の上限は、VM あたりとディスクあたりで異なり、互いに独立しています。

これらの上限を超えるリソースを消費するアプリケーションは、調整されます (制限とも呼ばれます)。 アプリケーション要件を満たし、上限に達しない、ディスク ストライプの VM とディスク サイズを選択します。 上限に対処するには、キャッシュを使用するか、アプリケーションを調整して必要なスループットを低下させます。

たとえば、12000 IOPS と 180 MB/秒を必要とするアプリケーションでは、次のことが可能です。

• キャッシュ不使用時の最大ディスク スループットが 20,000 IOPS と 500 MBps の Standard_M32ms を使用します。
• 15000 IOPS と 600 MB/秒のスループットを実現するために、3 つの P30 ディスクをストライピングします。
• Standard_M16ms の VM を使用し、ホスト キャッシュを使用して、スループットの消費にローカル キャッシュを利用します。

高使用率の時間帯にスケール アップするように構成された VM では、最大 VM サイズをサポートするために十分な IOPS とスループットを備えたストレージをプロビジョニングすると同時に、全体的なディスク数を、使用対象の最小の VM SKU でサポートされている最大数以下に維持する必要があります。

ディスクの上限とキャッシュを使用して上限の回避する方法の詳細については、ディスク IO の上限に関する記事を参照してください。

Note

ディスクの上限によっては、ユーザーにとって満足できるパフォーマンスが得られる場合があります。より大きな VM にサイズ変更するのではなく、ワークロードを調整して維持し、ビジネスのコストとパフォーマンスの管理を調整してください。

書き込みアクセラレータ

書き込みアクセラレータは、M シリーズの VM でのみ使用できるディスク機能です。 書き込みアクセラレータの目的は、大量のミッション クリティカルな OLTP ワークロードまたはデータウェアハウス環境によって、一桁の I/O 待機時間が必要な場合に、Azure Premium Storage に対する書き込みの I/O 待機時間を向上させることです。

ログ ファイルをホストしているドライブへの書き込みの待機時間を短縮するには、書き込みアクセラレータを使用します。 SQL Server データ ファイルには書き込みアクセラレータを使用しないでください。

書き込みアクセラレータ ディスクは VM あたりの同じ IOPS 制限を共有します。 アタッチされているディスクは、VM の書き込みアクセラレータの IOPS 上限を超えることはできません。

次の表に、VM ごとにサポートされるデータ ディスクの数と IOPS を示します。

VM の SKU	書き込みアクセラレータ ディスクの数	VM あたりの書き込みアクセラレータ ディスクの IOPS
M416ms_v2、M416s_v2	16	20000
M128ms、M128s	16	20000
M208ms_v2、M208s_v2	8	10000
M64ms、M64ls、M64s	8	10000
M32ms、M32ls、M32ts、M32s	4	5000
M16ms、M16s	2	2500
M8ms、M8s	1	1250

書き込みアクセラレータの使用には、いくつかの制限があります。 詳細については、「書き込みアクセラレータを使用するときの制限事項」を参照してください。

Azure Ultra Disk との比較

書き込みアクセラレータと Azure Ultra Disks の最大の違いは、書き込みアクセラレータは M シリーズのみで使用できる VM 機能であり、Azure Ultra Disks はストレージのオプションであるということです。 書き込みアクセラレータは、書き込み用に最適化されたキャッシュであり、VM のサイズに基づいて独自の制限があります。 Azure Ultra Disks は、Azure VM 用の、待機時間が低いディスク ストレージのオプションです。

可能であれば、トランザクション ログ ディスクには、Ultra Disks ではなく、書き込みアクセラレータを使用してください。 書き込みアクセラレータをサポートしておらず、トランザクション ログの待機時間を短くする必要がある VM の場合は、Azure Ultra Disks を使用します。

ストレージのパフォーマンスの監視

ストレージのニーズを評価し、ストレージのパフォーマンスを判断するには、測定対象とその指標の意味を理解する必要があります。

IOPS (1 秒あたりの入力/出力) は、アプリケーションがストレージに対して 1 秒あたりに行う要求の数です。 パフォーマンス モニター カウンター Disk Reads/sec と Disk Writes/sec を使用して IOPS を測定します。 OLTP (オンライン トランザクション処理) アプリケーションでは、最適なパフォーマンスを実現するために、IOPS を上げる必要があります。 支払い処理システム、オンライン ショッピング、販売時点管理システムなどのアプリケーションは、すべて OLTP アプリケーションの例です。

スループットとは、基になるストレージに送信されるデータの量です。多くの場合、1 秒あたりのメガバイト数で測定されます。 パフォーマンス モニター カウンターDisk Read Bytes/sec および Disk Write Bytes/sec を使用して、スループットを測定します。 データ ウェアハウスは、IOPS よりもスループットを最大化することによって最適化されています。 分析、レポート、ETL ワークストリーム、およびその他のビジネス インテリジェンス ターゲットのデータ ストアなどのアプリケーションは、すべてデータ ウェアハウス アプリケーションの例です。

I/O ユニットサイズは IOPS とスループットの能力に影響を及ぼします。これは、I/O サイズが小さいほど IOPS が高くなり、I/O サイズが大きいほどスループットが高くなるためです。 SQL Server では、最適な I/O サイズが自動的に選択されます。 詳細については、アプリケーションの IOPS、スループット、待機時間の最適化に関する記事を参照してください。

VM とディスク レベルでの上限の検出、および AzureBlob キャッシュの使用量と正常性の検出に非常に重要な特定の Azure Monitor メトリックがあります。 監視ソリューションと Azure portal ダッシュボードに追加する主要なカウンターを判断するには、ストレージ使用率のメトリックに関する記事を参照してください。

Note

Azure Monitor では現在、一時ドライブ (D:\) のディスクレベル メトリックが提供されていません。 VM のキャッシュが有効な場合の IOPS 使用率と VM のキャッシュが有効な場合の帯域幅使用率は、エフェメラル一時ドライブ (D:\) とホスト キャッシュの両方からの IOPS とスループットを反映します。

トランザクション ログのサイズ増加を監視する

トランザクション ログがいっぱいになると、パフォーマンスの問題や停止につながる可能性があるため、トランザクション ログ内の空き領域と、トランザクション ログを保持するドライブの使用済みディスク領域を監視することが重要です。 トランザクション ログがワークロードに影響を与える前に、ログの問題に対処します。

ログがいっぱいになった場合は、「トランザクション ログがいっぱいになった場合のトラブルシューティング」を参照してください。

ディスクを拡張する必要がある場合は、Azure Marketplace から SQL Server イメージをデプロイした場合は、SQL 仮想マシン リソースの [ストレージ] ウィンドウ、それ以外の場合は Azure 仮想マシンとセルフインストール SQL Server の [ディスク] ウィンドウで行うことができます。

次のステップ

詳細については、このベスト プラクティス シリーズにある他の記事を参照してください。

• クイック チェックリスト

• VM サイズ

• Security

• HADR の設定

• ベースラインの収集

• セキュリティのベスト プラクティスについては、「Azure Virtual Machines 上の SQL Server のセキュリティに関する考慮事項」をご覧ください。

• TPC-E および TPC_C ベンチマークによる Azure VM 上の SQL Server のパフォーマンスの詳細なテストについては、OLTP のパフォーマンスの最適化に関するブログを参照してください。

• SQL Server Virtual Machines に関する他の記事については、Azure Virtual Machines 上の SQL Server の概要に関するページをご覧ください。 SQL Server の仮想マシンに関するご質問については、よくあるご質問に関するページをご覧ください。