移行戦略とツールを確認する
SQL Server の移行では、移行を成功させるために慎重な計画が不可欠です。 この計画には、移行の方法と理由の両方の側面への対処が含まれます。
- その理由を理解するには、移行完了後の利点を認識する必要があります。
- その方法には、適切な移行ツールの選択と包括的な移行計画の作成が含まれます。
- このプロセスの重要な要素は、組織が許容できるダウンタイムの長さを評価することです。 移行プロセス中のダウンタイムを最小限に抑えることは、運用の効率と継続性を維持するために重要です。
この移行プロジェクトでは、チームはキックオフ会議からプロセスを開始しました。 あなたの役割は、いくつかの SQL Server を移行するためのツールを調べて、将来の SQL ライセンス コストへの潜在的な影響についての分析情報を提供することです。 さらに、許容できるダウンタイム レベルについて合意に達する必要があります。 また、プロジェクト マネージャーはテスト フェーズを組み込む必要があります。そのフェーズの間にいくつかのサーバーがテスト用に移行され、その後で完全な移行が実行されます。
移行の利点を把握する
おそらく、Hyper-V または他のベンダーの仮想マシンを使用して、独自のインフラストラクチャ上の仮想マシンを使用した経験があると思います。 そのため、このプラットフォームへの移行では、急な学習曲線が示されるわけではありません。
仮想マシン (VM) を使用すると、ホスト オペレーティング システムと SQL Server インスタンスを完全に管理できます。 オンプレミスのマシンの場合よりも簡単に、SQL Server の高可用性、ディザスター リカバリー、ファイルの部分置換を構成して管理することができます。 また、自動バックアップと更新プログラムを設定して、全体的な管理作業を容易にすることもできます。 Azure 仮想マシンで SQL Server を実行した場合、次の SQL Server コンポーネントが完全にサポートされます。
- SQL Server トランザクション レプリケーション
- Always On 可用性グループ
- Integration Services
- Analysis Services
- Reporting Services
- ログ配布
SQL Server は、既存の SQL Server アプリケーションを Azure 仮想マシンに移行するために最適化されており、最大 256 TB のストレージをサポートしています。 SQL Server のすべてのバージョンとエディションが使用可能であり、SQL Server のオンプレミス バージョンと 100% の互換性があります。
ライセンス
Azure でホストされる SQL Server 仮想マシンに使用できるライセンス モデルには、次の 3 種類があります。 移行シナリオに最適なものがどちらか評価します。
従量課金制 (PAYG) モデルでは、Azure VM を実行する秒単位のコストに SQL Server ライセンスのコストが含まれます。
ライセンス持ち込み (BYOL) モデルは Azure ハイブリッド特典 (AHB) とも呼ばれ、ユーザーは SQL Server を実行する VM で自分の SQL Server ライセンスを使用することができ、VM に使用量に対してのみ支払います。 このオプションは、マイクロソフト エンタープライズ契約を結んでいるお客様のみが利用できます。
高可用性/ディザスター リカバリー (HA/DR) ライセンス モデルは、Azure の無料の HA/DR レプリカに使用されます。 ソフトウェア アシュアランスを所有している場合は、パッシブ ディザスター リカバリー インスタンスの追加のライセンス コストを発生させることなく、SQL Server でハイブリッド ディザスター リカバリー プランを実装できます。
ヒント
Azure で SQL 仮想マシンのライセンス モデルを変更する方法については、「Azure で SQL 仮想マシンのライセンス モデルを変更する」を参照してください。
ネットワーク
Azure portal で SQL Server VM をプロビジョニングする場合、SQL 接続の種類を指定するオプションが用意されており、次が含まれます。
- パブリック: インターネット経由で SQL Server に接続します。
- プライベート: 同一仮想ネットワーク内の SQL Server に接続します。
- ローカル: 同一仮想マシン内の SQL Server にローカルに接続します。
インターネットから SQL Server データベース エンジンに接続する場合は、パブリックを選択します。 ポータルは自動的に次の手順を実行します。
- SQL Server の TCP/IP プロトコルを確立します。
- SQL Server の TCP ポート (既定は 1433) を開くファイアウォール規則を構成します。
- パブリック アクセスに必要な SQL Server 認証を有効にします。
- SQL Server ポート上のすべての TCP トラフィックに VM のネットワーク セキュリティ グループを構成します。
ポータルで [SQL 接続] の種類に [プライベート] を選択した場合、Azure では [パブリック] とほぼ同一の設定を構成します。 違いは、SQL Server ポート (既定では 1433) で外部トラフィックを許可するネットワーク セキュリティ グループの規則がないことです。 Azure portal で、SQL 仮想マシンの接続設定を変更できます。
キー管理
SQL Server には、暗号化キーの管理と保存が必要となる暗号化機能が用意されています。 Azure Key Vault (AKV) サービスは、セキュリティを強化し、安全かつ可用性の高い場所で鍵を管理できるように設計されています。 SQL Server コネクタ を利用すると、SQL Server で Azure Key Vault にある鍵を利用できるようになります。
AKV 統合機能を使用して時間を節約することができます。 この機能を有効にすると、SQL Server コネクタが自動的にインストールされます。 この機能は、AKV にアクセスする拡張キー管理 (EKM) プロバイダーを構成し、資格情報を作成してコンテナーにアクセスできるようにします。
仮想マシンのサイズ設定
開始するには、必要なバージョン、エディション、およびオペレーティング システムを備えた、SQL Server 仮想マシン イメージを選択します。 CPU とメモリの数を、ワークロードに適したサイズに構成することもできます。
オンプレミスのワークロードに対して SQL Server が適切に動作するために使用するデータベース パフォーマンス チューニング オプションの多くは、Azure VM で実行されている SQL Server にも適用されます。 VM のサイズとディスクの構成を含め、その他にも注意する必要がある考慮事項があります。 Azure 仮想マシンで実行されている SQL Server に最適なパフォーマンスを設定するには、次のチェックリストをガイドとして使用してください。
| パフォーマンス基準 | 最適化オプション |
|---|---|
| 仮想マシン |
|
| ストレージ |
|
| ディスク |
|
| I/O |
|
ワークロードに固有の特定のパフォーマンス設定を適用したい場合があるかもしれません。 移行前に、設定がテスト環境でテストされていることを確認します。
移行をサポートするためのツールと機能
Azure 仮想マシンに SQL Server を移行するには、多くの方法があります。 プロセスの最初の手順では、SQL Server がインストールされている Azure VM をプロビジョニングします。
圧縮されたバックアップ ファイルを使用して、データベース ファイルを Azure VM に移行すると、データ転送の最高のパフォーマンスを実現できます。
データベース移行プロセス中のダウンタイムを最小限に抑えるには、Always On オプションまたはトランザクション レプリケーション オプションのいずれかを使用します。 上記のいずれの方法も使用できない場合でも、データベースを手動で移行できます。
これらは、SQL Server データベースをサポートし、Azure 仮想マシンで実行されている SQL Server に移行するための主要なツールと機能です。
Azure Data Studio 用の Azure SQL 移行拡張機能 – 最新の Azure Database Migration Service が搭載されており、Azure SQL 移行拡張機能は、移行の準備状況の評価、Azure リソースへの適切な SKU のレコメンデーションの提供、Azure への SQL Server データベースの移行の簡略化に役立ちます。また、小規模から中規模のデータベースに最適です。 最新バージョンのデータ移行サービスを利用しており、Azure SQL への移行の準備が完了している SQL Server データベースを評価する高度な評価機能も用意されています。
Azure Blob Storage を使用したバックアップと復元 – Azure Blob Storage から Azure 仮想マシンで実行されている SQL Server にデータベースを復元できます。
URL からのデタッチとアタッチ – データベースとログ ファイルをデタッチし、それらを Azure Storage アカウントに転送します。 次に、Azure 仮想マシンの BLOB URL からデータベースをアタッチします。
ログ配布 – ログ配布は、SQL Server データベースを Azure VM に移行する方法です。 この方法では、ソース サーバーからのトランザクション ログ バックアップを使用して、宛先サーバー上のデータベースのセカンダリ コピーを継続的に同期します。 準備ができたら、最終的なログ バックアップが Azure VM に適用され、最小限のダウンタイムでシームレスな移行が可能になります。
Azure Migrate – Azure Migrate は、SQL Server 移行など、幅広い移行シナリオをサポートする包括的な移行サービスです。 Azure Migrate には、オンプレミスのサーバー、インフラストラクチャ、アプリケーション、データを、Azure への移行を目的として、大規模に評価して移行するために設計された一連のツールが用意されてします。
Database Experimentation Assistant (DEA) – パフォーマンスに懸念がある場合に、対象サーバーでワークロードを処理できるかどうかを評価するために使用します。 分析メトリックを使用して比較データを取得すると、移行後に対象のバージョンでより良いエクスペリエンスを提供できるかどうかを判断できます。
Data Migration Assistant (DMA) – データベース スキーマ、データ、ユーザー、サーバー ロール、SQL Server、および Windows ログインを、オンプレミスの SQL Server から Azure 仮想マシン上の SQL Server に移行するために使用します。 ツールでは、互換性の問題に対処するように求める評価が最初に実行されます。 その後、同じツールを使用して、評価されたデータベース スキーマとデータを Azure に移行できます。
Note
Database Migration Assistant は使用可能で便利なツールですが、大規模な移行や全体的なエクスペリエンスの向上には、Azure Database Migration Service を使用することをお勧めします。
ヒント
オンプレミスの SQL Server インスタンスを評価して Azure SQL に移行する方法と、アップグレード後にデータベースにとっての利点となり得るターゲット SQL Server プラットフォームの新機能を見つける方法については、SQL Server データベースの Azure SQL モジュールへの移行の評価に関する記事を参照してください。
移行方法を定義する
移行に関連するビジネス ダウンタイムの要件を考慮することが重要です。 移行先が仮想マシン内の SQL Server または Azure SQL Database のどちらであろうとです。
データベースを移行するために選択するメソッドは、通常、SQL Server データベースをオフラインにできる時間によって異なります。 また決定する上での他の要素として、手動に対してどの程度自動化して移行するかが挙げられるかもしれません。 ダウンタイムに基づいて、移行には次の 3 種類があります。
- ダウンタイムなしの移行
- メンテナンス期間の短い移行
- メンテナンス期間の長い移行
ダウンタイムなしの移行
ダウンタイムなしの移行は、通常、ミッション クリティカルなワークロードで必要になります。 Always On 可用性グループを使用して、SQL Server データベースから Azure 仮想マシン上の SQL Server にデータをレプリケートできます。
メンテナンス期間の短い移行
短いメンテナンス期間は、多くの場合数分単位です。 Azure Database Migration Service を使用して、オンプレミスの SQL Server データベースから Azure 仮想マシン上で実行されている SQL Server にデータをレプリケートおよび移行します。
Note
アプリケーション全体を移行するには、Azure Site Recoveryを使用することを検討します。
メンテナンス期間の長い移行
長いメンテナンス期間は、多くの場合数時間または数日単位であり、まれに変更されるアプリケーション データベースやワークロードがビジネス クリティカルではない場合に適しています。 SQL Server Management Studio BACPAC のエクスポートとインポート ファイルを使用する、バックアップと復元の方法を使用する、またはデータベースをデタッチしてからアタッチするなど、いくつかの選択肢があります。