はじめに
オンプレミスのSQL Serverを、Azure仮想マシン上のSQL Serverに移行するプロジェクトの経験をもとに、考慮事項、アプローチおよびベストプラクティスをまとめてみた。これらはすべて公式ドキュメントに記載されている事項だけど、その中でも重要と思われるものをピックアップしている。
構成などに関する考慮事項
仮想マシンのサイジング
- できるだけ、I/O スループット、メモリ、仮想コア比率の良いものを選択することでコストパフォーマンスを高める
- 事前に DMA などのアセスメントを実行して、推奨の SKU を取得し、それをベースラインとして検討を開始する
- SKUのストレージスループットや IOPS の上限、ローカル SSD 有無などの差異があることを確認する
- VMデプロイ時に高速ネットワークを有効化する
- VM サイズをベストプラクティスに従って決定する - パフォーマンスのベスト プラクティスおよびガイドライン - SQL Server on Azure VMs
ストレージ
- パフォーマンスカウンタを使用してストレージの要件を事前に見積もる - Azure Premium Storage: 高パフォーマンス用の設計
- OS ディスク - データベースのデータファイル、ログファイルを OS ディスクに置かない
- Data – Premium 以上推奨 (読み取り専用ホストキャッシュ)
- Log – Premium 以上推奨 (ホストキャッシュ無し)
- tempdb – FCI 以外の場合は Local SSD D:, FCI の場合は 共有ストレージ内に配置 – ただしパフォーマンス注意)
- ローカル SSD 上のデータは VM 再起動などにより再作成されるため、永続データを置かないように注意
- tempdbに高いI/O要件が求められる場合はPremium diskやUltra diskを使用しても不足する場合があるので、ローカルSSD性能の高いVM SKUを選択
- 必要なパフォーマンスに応じて、記憶域プールを使用して ディスクをストライピング して IOPS やスループットを増やす。VMごとに上限があるため要確認
- Azure NetApp Filesを使用することで仮想マシンに課せられるI/O制限を受けずに高パフォーマンスなディスクI/Oを実現可能。ディスクI/O性能のために大きなSKUを選択しなければならない場合、ストレージをAzure NetApp Filesを使用することで仮想マシンSKUを小さいものに変更できる可能性があり、それによってコストを削減できる可能性がある。詳細な性能テスト情報は SQL Server のデプロイに Azure NetApp Files を使用する利点 を参照
高可用性
- クラスター内のVMには近接配置グループを使用し、高速ネットワークを使用する
- 特にAlwaysOn AGのデータの同期の遅延を最小限に抑える
- AlwaysOn AG
- 単一サブネット内で構成する場合は Azure Load Balancer を使用する
- 複数のサブネットで構成し可用性グループリスナーを使用する場合は Azure Load Balancer が不要
-
AlwaysOn FCI
Azure上で共有ディスク部を実現させるための複数のストレージオプションがあるため以下ポイントを考慮して決定する。-
記憶域スペースダイレクト
- 可用性ゾーンがサポートされない
- ネットワーク帯域幅が必要
- ディスクを2つのVMに積むためコスト増になる可能性がある
- Windows 2016 以降で使用可能
-
Premium ファイル共有
- Windows 2012 以降で使用可能
- FileStream はサポートされない
-
Azure 共有ディスク
- ディスクキャッシュや使用できるディスクに制限がある
- Third Party Tool (DataKeeper, etc)
-
記憶域スペースダイレクト
tempdbをローカルSSDに配置する場合は、FCIからは監視されないため、ローカルSSDのドライブで障害が発生した場合のカスタムの監視とアクションを実装する必要がある。tempdbのディスクパフォーマンスが問題にならない場合は、共有ストレージにtempdbを配置する。
Failover Cluster Instance を使用している場合はSQL IaaS Agent機能に制限がある - フェールオーバー クラスター インスタンス
Monitoring
- Azure Monitor を使用してSQL Serverのテレメトリーデータを収集して分析する
- VM Insights でインフラ面の問題を特定する
SQL IaaS Agent
- SQL IaaS Agent を有効化してAzure Portal上での管理強化、バックアップおよびリストアを自動化、パッチ適用、ベストプラクティス評価などのメリットを得る
- ライセンスモデルの変更もIaaS Agentのインストールが必須
- 仮想マシンイメージからデプロイした場合はすでにインストールされているが、セルフインストールのSQL Serverにはインストールされていない
- Defender for SQL を使用して疑わしいデータベース アクティビティを検出し、セキュリティを強化する
アセスメント
-
Data Migration Assistant (DMA) - DMAを使用すると、新しいバージョンの SQL Server にアップグレードする際や、Azure SQL Databaseへ移行する際に、データベース機能に影響するおそれがある互換性の問題が検出される。また、 DMA は、ターゲット環境のパフォーマンスと信頼性を高めるための推奨事項を提案する。
- 移行を妨げる問題 – 互換性の問題を検出して推奨事項を提供
- 限定的またはサポート対象外の機能の利用有無 – 推奨事項、代替案の提供
- アップグレードに影響する問題の検出 (重大な変更、動作の変更、非推奨の機能)
- パフォーマンスメトリックを取得して移行先の推奨 SKU を取得
- DMA実行のための推奨事項
- DMAをSQL Serverが稼働しているサーバーに直接インストールしない
- 運用用データベースの評価は、ピーク時以外の時間帯に実行する
- 評価期間を短縮するために、互換性の問題と新機能の推奨事項の評価を別々に実行する
Azure Landing Zone
- Azure Landing Zoneの主要な設計原則を参照し、移行先のAzure環境をスケーラブルかつモジュール式な形で様々なデプロイニーズを満たすように設計
- Azure ランディング ゾーンとは - Cloud Adoption Framework
ライセンス
- SQL Server をホストする Azure VM には、従量課金制、Azure ハイブリッド特典 (AHB)、および高可用性/ディザスター リカバリー (HA/DR) の 3 種類のライセンス モデルを利用可能
- 従量課金モデル
- Azure VM を実行する秒単位のコストに、SQL Server ライセンスのコストが含まれる
- SQL Serverの仮想マシンイメージを使用して従量課金制の仮想マシンをデプロイ
- Azureハイブリッド特典 (AHB)
- SQL Server を実行する VM に対して独自の SQL Server ライセンスを使用
- AHBの対象となるのはSA (Software Assurance) またはサブスクリプションライセンス付きのSQL Serverコアベースライセンスのみ
- AHBを使用するには以下の方法がある
- SQL Serverの仮想マシンイメージを使用して従量課金制の仮想マシンをデプロイし、Azureハイブリッド特典をアクティブにする (ライセンスモデルを変更する)
- Azure Marketplace からのライセンス持ち込み SQL Server イメージを使用して、仮想マシンをプロビジョニング (エンタープライズ契約を結んでいる場合のみ)
- Azure VM に SQL Server をセルフインストールし、手動で SQL IaaS Agent 拡張機能に登録 して、Azure ハイブリッド特典を有効化
- 高可用性/ディザスター リカバリー (HA/DR)
- Azure での無料 HA/DR レプリカに使用可能
- 従量課金モデル
SQL Serverバージョン
- サポートが終了したSQL Serverのバージョンを使用している場合の対応
- SQL Serverのバージョンをアップグレード
- サポートされるアップグレードpath、アップグレードプロセスおよび互換性レベル変更の影響などを確認する - SQL Server をアップグレードする
- 最新のSQL Server 2022では最も下位の互換性レベルが100のため、100以下のバージョンを使用している場合は互換性レベルが自動的に100にアップグレードされる。
- アップグレード移行の場合の影響についてはDMAを使用して確認することができるが、DMAがサポートしていない古いSQL Serverバージョンを使用している場合は、サポートされているバージョンへのアップグレードを事前に実施 (最低でもDMAがサポートするSQL Server 2005以上) し、入念なテストをすること
- Azure SQL DatabaseやManaged InstanceなどのPaaSへの移行
- 延長セキュリティ更新プログラム (ESU) を適用
- ESUが提供されるバージョンに関しては、Azure仮想マシンに移行して無料で3年間ESUを受け取ることが可能。Azure仮想マシン以外の環境の場合は、Azure ArcのSQL Server拡張機能で接続して、ESUをサブスクライブする
- SQL Serverのバージョンをアップグレード
- 製品のライフサイクルを理解して、サポート終了への対応を計画する
その他コンポーネントの移行に関して考慮する
- SQL Server Reporting Services
- SQL Server Analysis Services
- SQL Server Integration Services
移行アプローチに関する考慮事項
互換性問題の修正
- DMAを使用した互換性や推奨事項のアセスメント結果を分析し、必要な修正適用を調査
- DMAや移行ツールがサポートしていない古いバージョンのSQL Serverの場合は、サポートされているバージョンへのアップグレードを事前に実施 (最低でもDMAがサポートするSQL Server 2005以上)
- 修正の適用の動作を最終的な移行先の環境でテスト
移行方式の選択
- 移行方式とそれに対応する移行パス、シナリオを理解しておき、移行計画を立てることに役立てる
| 方法 | 移行元 | 移行先 | シナリオ | 補足 |
|---|---|---|---|---|
| バックアップ / リストア (File / URL) | SQL Server 2008 SP4 ~ | SQL Server 2012 SP4 ~ | オフライン | 移行対象が少なく、ツール導入のオーバーヘッドを避けて単純化したい場合 |
| Azure Data Studio - Azure SQL Migration extention | SQL Server 2008 ~ | SQL Server 2012 ~ | オンライン / オフライン | ウィザードベースで移行をサポート。オンライン/オフライン移行をサポート。ツールを使用した容易な移行環境を整えたい場合 |
| Data Migration Assistant (DMA) | SQL Server 2005 ~ | SQL Server 2012 ~ | オフライン | ウィザードベースで移行をサポート。ログインやSSISの移行も対応 |
| Azure Migrate | SQL Server 2008 SP4 ~ | SQL Server 2012 SP4 ~ | オンライン / オフライン | VMごとイメージを移行したい場合 |
| AlwaysOn AG – 分散型可用性グループ | SQL Server 2016 ~ | SQL Server 2016 ~ | オンライン | SQL ServerのAlwaysOnテクノロジーを使用してより短いダウンタイム要件がある場合 |
| ログ配布 | SQL Server 2012 SP4 ~ | SQL Server 2012 SP4 ~ | オンライン | ログ配布機能を使用したオンライン移行SQL Server 2016以前のバージョンでより短いダウンタイム要件がある場合 |
移行前の準備と移行後のテスト
実際の移行の前に準備として以下を考慮しておく。
- 移行先のSKUで性能要件を満たすか
- 互換性問題の修正の適用が正常に動作するか
- 選択した移行方式で正常に移行できるか
- 本番移行のすべての作業を手順化
- 可能な限りスクリプトなどを使用して自動化
- 移行後のテストシナリオの確立
- 以下のテストを正しく実行することができるようにテスト項目やスクリプトなどを事前に準備すること
- すべての必要なテーブルなどのオブジェクトが正常に移行されていること
- アプリケーションやすべての依存するサービスの動作確認
- 以下のテストを正しく実行することができるようにテスト項目やスクリプトなどを事前に準備すること
- 移行後のカットオーバーの判断基準を策定
- 問題が発生した場合の切り戻し計画
- 移行後のタスクを定義しておく（以下は例）
- アプリケーションの接続文字列の変更など
- 統計の更新
- データベースの互換性レベルを調節する
- クラウド上のセキュリティ、自動バックアップ等の高度な機能の有効化
- Azure Monitor等によるモニタリングの構成