Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

考慮すべき要因

共同作成者
PDF

VM パフォーマンス

パブリッククラウドのリレーショナルデータベースのパフォーマンスを最適化するには、適切な VM サイズを選択することが重要です。Microsoft では、オンプレミスサーバ環境の SQL Server と同じデータベースパフォーマンス調整オプションを引き続き使用することを推奨しています。使用 "メモリの最適化" SQL Server ワークロードのパフォーマンスを最適化するための VM サイズ。既存の導入環境のパフォーマンスデータを収集し、適切なインスタンスを選択しながら RAM と CPU の利用率を確認します。ほとんどの導入環境では、 D 、 E 、または M シリーズのいずれかを選択できます。

  • 注： *

  • SQL Server ワークロードのパフォーマンスを最大限に高めるには、メモリに最適化された VM サイズを使用します。

  • ネットアップと Microsoft は、適切なメモリと VCORE の比率に基づいてインスタンスタイプを選択する前に、ストレージのパフォーマンス要件を特定することを推奨しています。これは、適切なネットワーク帯域幅を備えた低いインスタンスタイプを選択して、 VM のストレージスループットの制限に克服するのにも役立ちます。

VM の冗長性

冗長性と高可用性を高めるには、 SQL Server VM を同じにする必要があります "可用性セット" または別のものです "可用性ゾーン"。Azure VM を作成する場合は、アベイラビリティセットとアベイラビリティゾーンのどちらかを設定する必要があります。 Azure VM を両方に含めることはできません。

高可用性

高可用性を実現するには、 SQL Server AOAG または Always On フェイルオーバークラスタインスタンス（ FCI ）を構成することを推奨します。AOAG の場合、これには仮想ネットワーク内の Azure Virtual Machine 上の SQL Server の複数のインスタンスが含まれます。データベースレベルで高可用性が必要な場合は、 SQL Server 可用性グループを設定することを検討してください。

ストレージ構成

Microsoft SQL Server では、ストレージオプションとして SMB ファイル共有を導入できます。SQL Server 2012 以降、システムデータベース（マスター、モデル、 msdb 、または tempdb ）、 およびユーザデータベースは、ストレージオプションとして Server Message Block （ SMB ；サーバメッセージブロック）ファイルサーバとともにインストールできます。この環境は、 SQL Server のスタンドアロンと SQL Server FCI の両方に対応しています。

メモ SQL Server データベース用のファイル共有ストレージでは、継続的可用性がサポートされている必要があります。これにより、ファイル共有データに中断なくアクセスできます。

Azure NetApp Files は、あらゆる要求の厳しいワークロードに対応できる高性能なファイルストレージを提供し、ブロックストレージソリューションに比べて SQL Server の TCO を削減します。ブロックストレージでは、 VM の I/O およびディスク処理の帯域幅に制限があり、ネットワーク帯域幅の制限だけが Azure NetApp Files に適用されます。つまり、 Azure NetApp Files には VM レベルの I/O 制限は適用されません。これらの I/O 制限がない場合、 Azure NetApp Files に接続された小規模な VM で SQL Server を実行することも、はるかに大規模な VM で SQL Server を実行することもできます。Azure NetApp Files は、コンピューティングとソフトウェアのライセンスコストを削減することで、 SQL Server の導入コストを削減します。Azure NetApp Files for SQL Server 環境を使用することによるコスト分析とパフォーマンス上のメリットの詳細については、を参照してください "Azure NetApp Files for SQL Server の導入のメリット"。

利点

Azure NetApp Files for SQL Server を使用する利点は次のとおりです。

  • Azure NetApp Files を使用すると、インスタンスを小さくしてコンピューティングコストを削減できます。

  • また、 Azure NetApp Files はソフトウェアライセンスコストを削減し、全体的な TCO を削減します。

  • ボリュームを再構築して動的なサービスレベル機能を利用すると、安定状態のワークロードのサイジングを行い、オーバープロビジョニングを回避することでコストを最適化できます。

  • 注： *

  • 冗長性と高可用性を高めるには、 SQL Server VM を同じにする必要があります "可用性セット" または違う "可用性ゾーン"。ユーザ定義のデータファイルが必要な場合は、ファイルパスの要件を考慮してください。その場合は、 SQL FCI over SQL AOAG を選択します。

  • 次の UNC パスがサポートされます。 "\\ANFSMB-b4ca.anf.test\sqldb および \\ANFSMB-b4ca.anf.test\sqldb\"。

  • ループバック UNC パスはサポートされていません。

  • サイジングには、オンプレミス環境の履歴データを使用します。OLTP ワークロードの場合は、ワークロードの平均時間とピーク時間、ディスク読み取り回数 / 秒、ディスク書き込み回数 / 秒のパフォーマンスカウンタを使用して、ターゲット IOPS とパフォーマンス要件を一致させます。Data Warehouse および Reporting のワークロードの場合は、ワークロードの平均時間とピーク時間、およびディスクの読み取りバイト数 / 秒とディスクの書き込みバイト数 / 秒を使用して、ターゲットのスループットを調整します平均値は、ボリュームの形状変更機能と組み合わせて使用できます。

継続的可用性を備えた共有を作成

Azure ポータルまたは Azure CLI を使用して、継続的可用性を備えた共有を作成する。ポータルで、 [ 継続的な可用性を有効にする ] プロパティオプションを選択します。Azure CLI では、「 azz netappfiles volume create with the sm-continuously-available - AVL 」オプションを「 $True 」に設定して、共有を継続的可用性を備えた共有として指定します。継続的可用性を有効にした新しいボリュームの作成の詳細については、を参照してください "継続的可用性を備えた共有を作成しています"。

  • 注： *

  • 次の図に示すように、 SMB ボリュームの継続的可用性を有効にします。

  • 管理者以外のドメインアカウントを使用する場合は、そのアカウントに必要なセキュリティ権限が割り当てられていることを確認してください。

  • 共有レベルで適切な権限を設定し、適切なファイルレベルの権限を設定します。

  • 既存の SMB ボリュームでは継続的可用性プロパティを有効にできません。既存のボリュームを変換して継続的な可用性が確保された共有を使用するには、 NetApp Snapshot テクノロジを使用します。詳細については、を参照してください "既存の SMB ボリュームを継続的可用性を使用するように変換します"。

エラー：グラフィックイメージがありません

パフォーマンス

Azure NetApp Files は、 Standard （テラバイトあたり 16mbps ）、 Premium （テラバイトあたり 64MBps ）、 Ultra （テラバイトあたり 128MBps ）の 3 つのサービスレベルをサポートします。データベースワークロードのパフォーマンスを最適化するには、適切なボリュームサイズをプロビジョニングすることが重要です。Azure NetApp Files では、ボリュームのパフォーマンスとスループット制限は次の要素の組み合わせに基づいて決まります。

  • ボリュームが属する容量プールのサービスレベル

  • ボリュームに割り当てられているクォータ

  • 容量プールのサービス品質（ QoS ）タイプ（ auto または manual ）

詳細については、を参照してください "Azure NetApp Files のサービスレベル"。

エラー：グラフィックイメージがありません

パフォーマンスの検証

あらゆる導入同様、 VM とストレージをテストすることが重要です。ストレージの検証には、 HammerDB 、 Apploader 、などのツールを使用します "SQL Server Storage Benchmark （ SB ）ツール"、または適切な読み取り / 書き込み混在の任意のカスタムスクリプトまたは fio を使用する必要があります。ただし、 SQL Server のワークロードのほとんどは、ビジー状態の OLTP ワークロードでも、読み取りが 80~90% 、書き込みが 10~20% 近くになることに注意してください。

パフォーマンスを確認するために、 Premium サービスレベルを使用してボリュームに対してクイックテストを実行しました。このテストでは、ボリュームサイズを 100GB から 2TB にオンザフライで拡張しました。アプリケーションへのアクセスを中断することなく、データの移行もゼロでした。

エラー：グラフィックイメージがありません

ここでは、 HammerDB を使用して導入した、リアルタイムのパフォーマンステストの別の例を示します。このテストでは、 vCPU 8 個、 500GB Premium SSD 、 500GB SMB Azure NetApp Files ボリュームを含む小規模インスタンスを使用しました。HammerDB は、 80 のウェアハウスと 8 人のユーザで構成されています。

次のグラフから、 Azure NetApp Files では、 1 分あたりのトランザクション数が 2.6x で、同等のサイズのボリューム（ 500GB ）を使用した場合のレイテンシが 4 分の 1 に削減されたことがわかります。

さらに、 vCPU が 32 個、 Azure NetApp Files が 16TB の大容量インスタンスへのサイズ変更によって、テストを実施しました。1 分あたりのトランザクション数は大幅に増加し、レイテンシは常に 1 ミリ秒に抑えられました。HammerDB は、このテストで 80 個のウェアハウスと 64 人のユーザで構成されました。

エラー：グラフィックイメージがありません

コストの最適化

Azure NetApp Files を使用すると、ボリュームのサイズを透過的に無停止で変更でき、ダウンタイムやアプリケーションへの影響なしでサービスレベルを変更できます。これは、動的なコスト管理が可能な独自の機能で、ピーク時の指標を使用してデータベースのサイジングを行う必要を回避できます。安定した状態のワークロードを利用できるため、初期投資が不要になります。ボリュームの形状変更とサービスレベルの動的変更を使用すると、データアクセスを維持しながら、 I/O を一時停止することなく、 Azure NetApp Files ボリュームの帯域幅とサービスレベルをほぼ瞬時にオンデマンドで調整できます。

LogicApp や関数などの Azure PaaS ソリューションを使用すると、特定の webhook または alert ルールトリガーに基づいてボリュームのサイズを簡単に変更し、ワークロードの要件を満たしながらコストを動的に処理できます。

たとえば、安定した動作に 250Mbps のデータを必要とするデータベースがありますが、 400Mbps のピークスループットも必要とします。この場合、安定したパフォーマンスの要件を満たすために、 Premium サービスレベルに 4TB ボリュームを追加して導入する必要があります。ピーク時のワークロードに対処するには、 Azure の機能を使用して特定の期間でボリュームサイズを 7TB に増やしてから、導入コストを抑えるためにボリュームのサイズを縮小します。この構成では、ストレージのオーバープロビジョニングを回避できます。