オンプレミスのSQLServerインスタンスをAzure仮想マシン（VM）に移行することは、Azureに移行するための一般的な方法です。 ITプロフェッショナルは、vCPU、メモリ、およびストレージ容量に関してVMのサイズを調整することに精通しています。 Microsoftは、組織のニーズに合わせて複数のVMタイプとサイズを提供しています。 Familyとして参照されているタイプが表示されます VMのサイズを変更するときにAzureポータルで。
VMのタイプとサイズ
Microsoftは、複数の種類の仮想マシンを作成することにより、物事を簡素化するのに役立ってきました。タイプは、目的によってマシンを定義することを目的としています。さまざまなタイプは次のとおりです。
- 汎用–バランスの取れたCPUとメモリの比率、中小規模のデータベース
- コンピューティングの最適化– CPUとメモリの比率が高く、トラフィックが中程度のWebサーバーとアプリケーションサーバー
- メモリの最適化–メモリとCPUの比率が高く、リレーショナルデータベースサーバー、中規模から大規模のキャッシュ、およびメモリ内分析
- ストレージの最適化–高いディスクスループットとIO
- GPU –重いグラフィックレンダリングとビデオ編集
- ハイパフォーマンスコンピューティング–最速かつ最も強力なCPU仮想マシン
各タイプ/ファミリー内には、選択できるサイズが多数あります。サイズは、vCPU、RAM、およびデータディスクの数のオプションを提供します。データディスクの数によって最大IOPS（IOPSは1秒あたりの入出力操作を表します）が決まり、全体のサイズによって利用可能な一時ストレージの量が決まります。特定のサイズはプレミアムストレージもサポートします。これは、運用SQLServerの要件である必要があります。
VMイメージオプション
SQL Serverのイメージを選択する場合、いくつかのオプションがあります。 LinuxやWindowsなどのOSのみを選択するか、OSとSQLServerが既にインストールされているイメージを選択するかを選択できます。現在、SQL Serverをインストールして好きなように構成できるように、OSだけでイメージを選択することを好みます。 SQL Serverがプリインストールされたギャラリーイメージを選択すると、そのバージョンのISOに含まれているすべてのコンポーネントがインストールされ、IntegrationServicesまたはAnalysisServicesが常にインストールされている必要はありません。
VMのサイズに関する考慮事項
Azure VMの選択は、vCPUの数、メモリ、およびデータベースを保持するのに十分なストレージに基づいてサイズを選択することで簡単に思えるかもしれませんが、ストレージに関連するパフォーマンスの問題を抱えているお客様がいます。一般的な傾向は、現在のIOとスループットの要件をベンチマークせずに、vCPU、メモリ、およびストレージ容量のみに基づいてVMを選択することです。 AzureポータルでAzureVMを作成する場合、以下に基づいてオプションをフィルター処理できます。
- サイズ
- 世代
- 家族
- RAM/メモリ
- プレミアムストレージのサポート
- vCPUの数
- エフェメラルOSディスク
フィルタオプションを選択すると、使用可能なサーバーのリストが表示されます。リストには、VMサイズ、オファリング、ファミリ、vCPU、RAM、サポートされているデータディスクの数、最大IOPS、一時ストレージ（D :)、プレミアムディスクがサポートされている場合、および推定コストが表示されます。サポートされているプレミアムディスクで、メモリを最適化するために文字Eで始まるサイズで以下をフィルタリングしました。
ただし、表示されないのは、VMごとに許可されるスループットの量です。スループットは、ストレージメディアとの間のデータ転送速度をメガバイト/秒で測定します。
スループットは、次の式を使用して計算できます
MB / s =IOPS*IOあたりのKB/1,024
この式を使用すると、IOあたりのKBがブロックサイズになります。データとログドライブを64kでフォーマットしている場合、3,200、6,400、および12,800IOPSのE2s_v3、E4-2s_v3、およびE8-2s_v3VMの式は次のようになります。
MB / s =3,200 * 64/1,024または200MB/ s
MB / s =6,400 * 64/1,024または400MB/ s
MB / s =12,800 * 64/1,024または800MB/ s
ブロックサイズが64kの各VMのIOPSに基づくスループットの計算は、それほど悪くはありません。これらの数値は、RAIDの書き込みペナルティを考慮していません。これらの各VMをCrystalDiskMarkを使用してテストしました。スループットについて私が得た数値は、計算が推定したものとはほど遠いものでした。
ベンチマークテスト
同じファミリの3つの仮想マシンをプロビジョニングしましたが、サイズは異なり、それぞれに2つのvCPUがあります。仮想マシンの仕様は次のとおりです。
- E2s_v3 – 2 vCPU – 16GB RAM – 3,200 IOPS –最大4つのデータディスクをサポート
- E4-2s_v3 – 2 vCPU – 32GB RAM – 6,400 IOPS –最大8つのデータディスクをサポート
- E8-2s_v3 – 2 vCPU – 64GB RAM – 12,800 IOPS –最大16個のデータディスクをサポート
- P60データディスク–プレミアムSSD – 16,000 IOPS
各VMで、8TBの容量でP60プレミアムディスクをプロビジョニングしました。このディスクは16,000IOPSをアドバタイズし、64kブロックサイズで1,000 MBpsのスループットをサポートできますが、Azureのドキュメントには、ディスクが500MBpsのスループットを提供すると記載されています。
CrystalDiskMarkは、Windows用のオープンソースディスクドライブベンチマークツールであり、MicrosoftのDiskspdツールに基づいています。このツールは、読み取りと書き込みの順次およびランダムなパフォーマンスを測定します。
ツールの上部には、いくつかのドロップダウンがあります。数値5は、実行されるテストの反復回数です。次は1GiBで、これはテストファイルのサイズです。実際の本番テストでは、これはキャッシュへのヒットを回避するのに十分な大きさである必要があります。バージョン7.0は、最大64GiBのファイルをサポートします。最後は、テストを実行するドライブです。
選択したら、[すべて]をクリックして一連のテストを開始できます。テストは、さまざまな順次およびランダムな読み取り/書き込み操作をループします。実際の実稼働サーバーのベンチマークを計画している場合は注意が必要です。このテストはディスクに負荷をかけ、実稼働ワークロードに大きな影響を与える可能性があります。営業時間外またはメンテナンス期間中が望ましいでしょう。
ドライブE：であるP60ディスク上の32GiBファイルを使用してテストを5回実行することを選択しました。
E2s_v3VMの最大速度は50MBps未満で、計算した200MBよりもはるかに少ないです。
E4-2s_v3 VMは、400MBpsではなく100MBps未満で最大になりました。
E8-2s_v3 VMは、推定800MBpsではなく200MBps未満で最大になりました。
スループットが低下する理由
以前の計算に基づくと、64kブロックサイズで3,200IOPSは200MBのスループットを生成するはずですが、最大12,800IOPSをサポートするVMに16,000IOPSディスクが存在するまで、それに近い数値は見られませんでした。その理由は、各VMサイズにはスループットの制限があるためです。メモリ最適化VMファミリのドキュメントを見ると、E2の最大アンキャッシュディスクスループットは3,200 IOPS / 48 MBps、E4の最大アンキャッシュディスクスループットは6,400 IOPS / 96 MBps、E8の最大アンキャッシュディスクであることがわかります。スループットは12,800IOPS/192MBpsです。これらの数値は、CrystalDiskMarkを使用して得た結果と一致しています。
十分なIOPSを持ち、高いスループット数をサポートする非常に大きなディスクを割り当てることができますが、VMサイズがスループットを制限している可能性があります。
SQL ServerのワークロードをAzureに移行する前に、現在のスループットのニーズをベンチマークすることを最優先する必要があります。
結論
IOPSは、ディスクメーカーとストレージベンダーが提供する測定単位であり、問題ないことを理解しています。ただし、ストレージのテストに関しては、スループットの数値に重点を置く傾向があります。これは単なる数学の問題ですが、ストレージのベンチマークを行い、ブロックサイズに基づいてIOPSからスループットまでの計算を行う場合を除いて、混乱を招く可能性があります。
私が困っているのは、VMサイズを選択したときにスループットの制限が明確になっていないという事実です。ストレージIOの測定単位はIOPSです。 64kブロックサイズで3,200IOPSの場合、約200 MBpsになる可能性がありますが、VMは48MBpsに制限されていました。多くのITプロフェッショナルは、ディスクパフォーマンスの問題があることを発見し、ストレージをより大きく、より高速なディスク（より多くのIOPS）に拡張して、パフォーマンスの向上を期待していますが、問題が解決しなかったことがわかりました。問題は、VMのサイズがスループットを制限していたことです。より大きなサイズのVMにスケールアップすると問題は解決しますが、それにはコストがかかります。私の例では、E4はE2の2倍のコストでしたが、同じvCPUを維持しながら、メモリとスループットを2倍にしました。 E8はE4の2倍のコストであり、同じvCPUを維持しながら、スループットとメモリを2倍にしました。同じvCPU数を維持するということは、コアSQLServerライセンスコストが増加しないことを意味します。
最終的には、現在のスループット要件をベンチマークし、AzureVMまたは任意のVMのサイズをニーズに合わせて適切に設定する必要があります。ローカルストレージのベンチマークだけに注目するのではなく、それに応じてワークロードに必要なものとサイズを分析します。