SQL Server 仮想マシン用に Azure Storage を最適化する方法について説明する
データベース エンジンのような I/O 負荷の高いアプリケーションにとって、ストレージ パフォーマンスは重要な要素です。 Azure は、ストレージに関して幅広い選択肢を提供しています。それどころか、実際のワークロード要件に合ったストレージ ソリューションを構築することが可能です。
Azure Storage は、さまざまなアプリケーションの多様なニーズを満たすように設計された堅牢で安全なプラットフォームです。 さまざまなスケーラブルなソリューションを提供し、あらゆる種類のストレージが保存時の暗号化をサポートします。 ユーザーは、セキュリティを強化するために、Microsoft が管理する暗号化キーまたはユーザー定義の暗号化キーを選択できます。
Blob Storage - いわゆるオブジェクトベースのストレージであり、コールド、ホット、およびアーカイブ ストレージ層が含まれます。 SQL Server 環境では、Blob Storage が主にデータベースのバックアップに使用されます。その際、SQL Server の URL へのバックアップ機能が使用されます。
File Storage - 実質的にはファイル共有です。ハードウェアを一切セットアップしなくても仮想マシン内でマウントすることができます。 SQL Server では、フェールオーバー クラスター インスタンスのストレージ ターゲットとして File Storage を使用できます。
Disk Storage - Azure Managed Disks では、仮想マシンから見えるブロック記憶域が提供されます。 これらのディスクは、仮想化されている点を除き、オンプレミス サーバーの物理ディスクと同様に管理されます。 マネージド ディスク内には、ワークロードに応じていくつかのパフォーマンス レベルが存在します。 SQL Server のデータ ファイルとトランザクション ログ ファイルには、このタイプのストレージが最もよく使用されます。
Azure Managed Disks
Azure Managed Disks は、Azure Virtual Machines から見えるブロックレベルのストレージ ボリュームです。 ブロック レベルのストレージとは、個別のハード ドライブとして作成、操作できる生ボリュームの記憶域を指します。 これらのブロック デバイスはオペレーティング システム内で管理でき、ストレージ層はディスクの内容を認識しません。 ブロック記憶域に代わるものとしてオブジェクト ストレージがあります。オブジェクト ストレージでは、ファイルとそのメタデータが、基になるストレージ システムに格納されます。 オブジェクト ストレージ モデルの例として、Azure Blob Storage があります。 オブジェクト ストレージは多くの最新の開発ソリューションに適していますが、仮想マシンで実行されているほとんどのワークロードではブロック ストレージが使用されます。
SQL Server ワークロードのパフォーマンスには、マネージド ディスクの構成が重要となります。 オンプレミス環境から移行する場合は、前に詳しく説明したように、 平均ディスク秒/読み取り、 パフォーマンス モニターからの 平均ディスク秒数/書き込み などのメトリックをキャプチャすることが重要です。 キャプチャすべきもう 1 つのメトリックは、1 秒あたりの I/O 数です。これは、SQL Server がそのピーク時に処理する IOPS を示す SQL Server: Resource Pool Stats Disk Read and Write IO/sec カウンターを使用してキャプチャできます。 ワークロードを理解することが重要です。 大量の待機時間を発生させずに、これらのワークロードピークのニーズを満たすようにストレージと仮想マシンを設計する必要があります。 Azure 仮想マシンの種類ごとに、IOPS に制限があります。
Azure Managed Disks には 4 つの種類があります。
Ultra Disk - IO 負荷の高いミッション クリティカルなデータベースのワークロードを低遅延でサポートします。
Premium SSD - 高スループットと低遅延を特徴とし、クラウドで実行されるほとんどのデータベース ワークロードのニーズを満たします。
Standard SSD - 実行される IO 数が少なく、待ち時間が予測可能であることが求められる Web サーバーや軽い負荷で使用される Dev/Test ワークロード向けに設計されています。
Standard HDD - アクセス頻度の低いバックアップやファイル ストレージに適しています。
通常、実稼働 SQL Server ワークロードでは、Ultra ディスクまたは Premium SSD、または 2 つの組み合わせを使用します。 Ultra ディスクは通常、応答時間でミリ秒未満の待機時間を探している場合に使用されます。 Premium SSD は通常、応答時間が 10 ミリ秒未満となりますが、コストは低くなり、設計上の柔軟性は高くなります。 Premium SSD では、読み取りキャッシュもサポートされます。ディスクとのトリップ数が減るため、読み取り負荷の高いデータベース ワークロードでそのメリットが発揮されます。 読み取りキャッシュは、ローカル SSD (Windows では D:\ ドライブ、Linux では /dev/sdb1/) に格納され、実ディスクとのラウンド トリップ数を低減する効果があります。
ディスクのストライピングによるスループットの最大化
Azure ディスクのパフォーマンスを高め、ボリュームを増やす方法の 1 つは、データを複数のディスクにストライピングすることです。 1 つのディスクで IOPS、スループット、最大サイズを個別にスケーリングできるため、この手法は Ultra ディスクには適用されません。 一方、Premium SSD では、IOPS とストレージ ボリュームの両方をスケーリングすることで良い効果が得られる場合があります。 Windows でディスクをストライプするには、VM に必要なディスクの数を追加し、Windows の記憶域スペースを使用してプールを作成します。 プールの冗長性は構成しないでください (パフォーマンスが制限される可能性があります)。冗長性は Azure フレームワークによって提供され、ディスクの障害から保護するために、すべてのディスクのコピーが同期レプリケーションで 3 つ確保されます。 作成したプールの IOPS およびボリュームは、そのプールに存在するすべてのディスクの合計となります。 たとえば、各 1 TB の 10 個の P30 ディスクを使用し、ディスクあたり 5,000 IOPS がある場合、50,000 IOPS を使用できる 10 TB のボリュームがあります。
SQL Server ストレージ構成のベスト プラクティス
Azure VM 上の SQL Server とそのストレージ構成に関して、ベスト プラクティスを目指すための推奨事項がいくつかあります。
- データ ファイル用とトランザクション ログ ファイル用に別々のボリュームを作成する
- データ ファイル ボリュームの読み取りキャッシュを有効にする
- ログ ファイル ボリュームでキャッシュを有効にしない
- ワークロードのピークを処理するために VM のストレージを構築するときに、追加の 20% の IOP とスループットを計画する
- TempDB はサーバーの再起動時に再作成されるため、データ損失のリスクがないため、TempDB ファイルに D: ドライブ (ローカルに接続されている SSD) を使用します
- ファイル拡張アクティビティの影響を小さくするためにファイルの瞬時初期化を有効にする。
- トレース ファイルとエラー ログのディレクトリをデータ ディスクに移動する
- ストレージ待機時間が 1 ミリ秒未満のワークロードの場合は、Premium SSD 経由の Ultra ディスクの使用を検討してください。
Azure 仮想マシンのリソース プロバイダー
Azure 仮想マシンでの SQL Server のストレージ構築の複雑さを軽減する 1 つの方法は、Azure Marketplace で SQL Server テンプレートを使用することです。これにより、デプロイの一部としてストレージを構成できます。 必要に応じて IOPS を構成でき、テンプレートは Windows 内に記憶域スペース プールを作成する作業を実行します。
TempDB をローカル SSD ドライブに追加する作業も、このリソース プロバイダーで行うことができます。その場合、起動時にフォルダーを作成するためのスケジュールされたタスクが作成されます。