はじめに
オンプレミス環境からAzureへの移行プロジェクトをいくつか経験しましたが、WindowsServerの移行上の考慮ポイントや設計について備忘の為残しておきたいと思います。
前提
- オンプレミス環境からのリフト&シフトを想定
https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/compute-decision-tree - Windows Serverの移行を想定
仮想マシンのサイズ選定
仮想マシンには種類やサイズがありますが、この選択が最初の考慮事項でしょう。
特性に応じて最適な仮想マシンの種類を選択しましょう。
基本的には移行元サーバのリソースの使用率から、選定されると思いますが、SQL Serverはライセンス形態によっては、CPUコア数がコストにはねる場合もあります。その場合は「メモリの最適化」等を検討しましょう。
ディスク
ディスクについては、「構成面」と「性能面」に2つの考慮ポイントがあるでしょう。
1. 構成面
構成面での考慮事項としては、ローカル一時ディスクがまず挙げられるでしょう。一般的な仮想マシンは、Dドライブが、ローカル一時ディスクなっています。SSDが割れ当てられており、主にページングファイルの配置先になっています。
ただし、Dドライブにシステム上参照されるデータが多く存在する場合、ドライブレターの変更によりパスの書き換えが発生することになります。大規模なシステムで影響調査に労力を要する等ハレーションが大きい場合は、一時ディスクを持たない種類の仮想マシンが選択できるようになっていますので、そちらの利用を検討します。
2. 性能面
Azure Disk Storageは、Standard HDD、Standard SSD、Preminu SSD、 Ultra Disk等いくつかの選択肢があります。よほどの性能を求められない限り、Premium SSDで事足りるでしょうが、Premium SSD以上の性能を求められる場合は、Ultra Disk を使うか、Preminu SSDをストライピングして使うか、コスト面も含めて検討するのがよいでしょう。
また、キャッシュの有効化についても設計上のポイントになるでしょう。
キャッシュを有効にすれば、性能は出ますが、キャッシュを推奨しない構成もありますので、注意が必要です。
詳細についてはこちらのサイトを参照下さい。
IOPS
下記の図は公式サイトからの抜粋ですが、仮想マシンには 12,800IOPSを処理する性能があるにも関わらず、ディスク性能がそれぞれ 500IOPSしか処理できない為最終的に1,500IOPSしかアプリケーションに対して返せない構成を表しています。
逆に仮想マシンの種類とサイズがボトルネックになるケースもあり、高いI/O要件のあるアプリケーションの設計を行う場合は、仮想マシンとディスクを総合的に設計する必要があります。
詳しくは以下のサイトを参照下さい。
Standard_D8s_v3
キャッシュされない IOPS:12,800
E30 OS ディスク
IOPS:500
2 台の E30 データ ディスク × 2
IOPS:500
ネットワーク
プライベートIPアドレス
仮想マシンを作成すると、指定した範囲のプライベート IP アドレスが自動的に割り当てられます。 この IP アドレスは、VM がデプロイされているサブネットに基づいており、VM は VM が削除されるまでこのアドレスを保持します。
その為一度割り当てられたIPアドレスが意図せず変更されることはありませんが、特定のIPアドレスを静的に割り当てたい場合は、Azure Portalから設定します。
尚、Azure Portalから静的にIPアドレスを割り当てた場合でも、OSからは動的割り当てに見えます。
OS内からIPアドレスを変更することは非推奨なので注意しましょう。
高速ネットワーク
高速ネットワークは、シングルレート I/O仮想化(SR-IOV) [1]を有効化することで、ネットワークトラフィックを物理ホストの仮想スイッチを経由することなく直接転送することでネットワークを高速化できます。コストも発生しない為、OSやVMインスタンスが対応している場合は有効化を検討しましょう。
可用性
仮想マシンの冗長化の選択肢は、可用性セット(99.95% のSLA)、可用性ゾーン(99.99% のSLA)が選択できます。
可用性セットを使用する場合、月間のダウンタイムは約21分許容されるSLAになります。
上記のSLAは仮想マシンに対してのもので、OSやアプリケーションレベルで可用性を高めたい場合は、WSFC(Windows Server Failover Clunster)等の冗長化を検討することになります。
Azure環境上で、WSFCを構築する場合はこちらのサイトを参照下さい。
Azure環境でWSFCを運用する場合の考慮事項として、Azureのメンテナンスへの対応が上げられます。
フェイルオーバーが発生し、サポートに問い合わせしたところ原因は物理ホストのメンテナンスによるものだった。という経験ががり、その場合ハートビート間隔をチューニングする等の対応が必要になってきます。具体的なチューニングについては以下のサイトが参考になります。
最後に
オンプレミス環境からのサーバ移行は、最近は物理サーバはほとんどなくなり、Hyper-V等の仮想基盤上の仮想サーバを移行するケースがほとんどでしょう。
モダナイズの観点では、PaaS化を検討する等あるでしょうが、移行コストなどの諸々の理由でクラウドリフト(リホスト)を選択するケースが依然として多いという印象です。
本記事は、私の経験と記憶によるもので本来はもっと色々な検討要素があるかと思います。
Azure Migrate [2]のようにサイジングから移行迄を一気通貫で行えるようなサービスもありますので、今後色々試してみたいと思います。
Discussion