SQL Server の Azure 仮想マシンへの移行に関する考慮事項

完了

SQL ワークロードの移行を行うときは、その方法と理由を時間を割いて検討してください。 理由には、移行後に見られる利点が含まれます。 方法には、移行に役立つツールと、作成する必要があるプランが含まれています。 計画の重要な要素として、組織で許容されるダウンタイムがあります。

チームの移行プロジェクトは、キックオフ ミーティングで開始されました。 プロジェクト マネージャーは、会社の SQL ワークロードを更新して Azure VM に移行することについて、あなたに意見を求めました。 ミーティングは、合意された移行計画と、必要な評価ツールについて理解することを目的としています。 また、プロジェクト マネージャーは、今後の SQL ライセンス コストへの影響を把握し、許容されるダウンタイムのレベルについての合意を得るためのアイデアも求めています。

このユニットでは、Azure VM に移行した後に、会社が得られる利点の一覧を収集します。 その後、移行計画に含める必要がある内容を検討します。 最後に、組織が現在の SQL Server の資産を検出して評価するのに役立つツールについて説明します。

移行の利点を把握する

おそらく、Hyper-V または他のベンダーの仮想マシンを使用して、独自のインフラストラクチャ上の仮想マシンを使用した経験があると思います。 そのため、このプラットフォームへの移行では、急な学習曲線が示されるわけではありません。

VM を使用すると、ホスト オペレーティング システムと SQL Server インスタンスを完全に管理できます。 オンプレミスのマシンの場合よりも簡単に、SQL Server の高可用性、ディザスター リカバリー、ファイルの部分置換を構成して管理することができます。 また、自動バックアップと更新プログラムを設定して、全体的な管理作業を容易にすることもできます。 これらの利点に加えて、VM 上で SQL を実行すると、次の SQL Server コンポーネントが完全にサポートされます。

  • SQL Server トランザクション レプリケーション
  • Always On 可用性グループ
  • Integration Services
  • Analysis Services
  • Reporting Services
  • ログ配布

SQL Server は、既存の SQL Server アプリケーションを Azure VM に移行するために最適化されており、最大 256 TB のストレージをサポートしています。 SQL Server のすべてのバージョンとエディションが使用可能であり、SQL Server のオンプレミス バージョンと 100% の互換性があります。

移行を計画する

会社が SQL Server ワークロードを Azure 仮想マシンに移行するときに考慮すべき領域があります。

ライセンス

Azure でホストされる SQL Server 仮想マシンに使用できるライセンス モデルには、次の 2 種類があります。 移行シナリオに最適なものがどちらか評価します。

  • 従量課金制 (PAYG) モデルでは、Azure VM を実行する秒単位のコストに SQL Server ライセンスのコストが含まれます。

  • ライセンス持ち込み (BYOL) モデルは Azure ハイブリッド特典 (AHB) とも呼ばれ、ユーザーは SQL Server を実行する VM で自分の SQL Server ライセンスを使用できます。 現在、VM の使用量に対してのみ課金されます。

ライセンスは、Azure portal、Azure CLI、または PowerShell のいずれかを使用して変更できます。

ネットワーク

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 仮想マシン イメージを選択します。 SQL Server 2008 R2 SP3 はサポートされている最も古いバージョンであり、CPU とメモリの数をワークロードに適したサイズに構成できます。

オンプレミスのワークロードに対して SQL Server が適切に動作するために使用するデータベース パフォーマンス チューニング オプションの多くは、Azure VM で実行されている SQL Server にも適用されます。 VM のサイズとディスクの構成を含め、注意する必要がある考慮事項がさらにあります。 Azure 仮想マシンで実行されている SQL Server に最適なパフォーマンスを設定するには、次のチェックリストをガイドとして使用してください。

パフォーマンス基準 最適化オプション
仮想マシン
  • SQL Server の Enterprise エディションで選択する必要がある仮想マシンの最小サイズは DS3_v2 以上です
  • Standard または Web エディションの場合は、最小サイズとして DS2_v2 を使用します
ストレージ
  • 運用環境のワークロードには Premium SSD を使用します
  • 開発/テスト環境では Standard ストレージ
  • ストレージが仮想マシンと 同じ場所 に併置されていることを確認します
ディスク
  • 少なくとも 2 つの P30 ディスク (ログ ファイル用に 1 つとデータ ファイル用に 1 つ (TempDB を含む)) を使用します
  • 50,000 の IOPS を必要とするワークロードには、Ultra SSD の使用を検討してください
  • データベース ストレージまたはログに、オペレーティング システム ディスクまたは一時ディスクを使用することは避けます
  • データ ファイルと TempDB データ ファイルをホストするディスクで 読み取りキャッシュを有効にします
  • ログ ファイルをホストするディスクでは、キャッシュを有効にしないでください
  • 複数の Azure データ ディスクを ストライプ して、IO スループットを向上させます
  • ドキュメントに記載されている割り当てサイズで フォーマット します
  • ミッション クリティカルな SQL Server ワークロードのために (適切な VM サイズを選択した後) TempDB をローカル SSD に 配置します
I/O
  • データベース ページの圧縮を有効にします
  • データ ファイルの 瞬時初期化を有効にします
  • データベースの 自動拡張を制限します
  • データベースの 自動圧縮を無効にします
  • システム データベースも含め、すべてのデータベースをデータ ディスクに移動します
  • SQL Server エラー ログとトレース ファイル のディレクトリをデータ ディスクに移動します
  • 既定のバックアップデータベース ファイル の場所を設定します
  • ロックされたページを有効にします
  • SQL Server パフォーマンス修正プログラムを適用します

ワークロードに固有の特定のパフォーマンス設定を適用したい場合があるかもしれません。 移行前に、設定がテスト環境でテストされていることを確認します。

移行をサポートするためのツール

検出、計画、および評価の各ステージでは、次のツールを使用する必要があります。

  • Microsoft Assessment and Planning ツールキット このツールを検出ステージで使用して、ソースの環境を確認します。 このツールを使用は、ソース SQL Server の構成、インストールされているインスタンスの数、およびそれぞれで実行されているコンポーネントを理解するために役立ちます。 ツールを使用して、実行されている Windows Server のバージョンと構成を確認することもできます。

  • Database Experimentation Assistant パフォーマンスに懸念がある場合に、対象サーバーでワークロードを処理できるかどうかを評価するには、Database Experimentation Assistant を使用します。 分析メトリックを使用して比較データを取得すると、移行後に対象のバージョンでより良いエクスペリエンスを提供できるかどうかを判断できます。

  • Data Migration Assistant (DMA) 移行プロジェクトの計画および評価ステージで Data Migration Assistant を使用して、データベース機能に影響する可能性のある互換性の問題がないかどうかを確認します。 また、移行を実行する前に、ターゲット環境のパフォーマンスと信頼性の向上を確認して、計画に組み込めるように使用する必要もあります。 その後、DMA を使用して移行プロジェクトを作成し、移行を完了することができます。

移行方法を定義する

移行に関連するビジネス ダウンタイムの要件を考慮することが重要です。 移行先が仮想マシン内の SQL Server または Azure SQL Database のどちらであろうとです。 ダウンタイムによって、特定の期間に実行する移行の種類が決まります。 時間に基づくと、移行には次の 3 種類があります。

  • ダウンタイムなしの移行
  • メンテナンス期間の短い移行
  • メンテナンス期間の長い移行

ダウンタイムなしの移行

ダウンタイムなしの移行は、通常、ミッション クリティカルなワークロードで必要になります。 SQL Server のトランザクション レプリケーションまたは Always On 可用性グループを使用して、SQL Server データベースからクラウドベースのデータベースにデータをレプリケートできます。

メンテナンス期間の短い移行

短いメンテナンス期間は、多くの場合数分単位です。 Azure Data Migration Service (DMS) または Data Migration Assistant (DMA) を使用して、オンプレミスの SQL Server データベースから Azure SQL Database にデータをレプリケートおよび移行します。

メンテナンス期間の長い移行

長いメンテナンス期間は、多くの場合数時間または数日単位であり、まれに変更されるアプリケーション データベースやワークロードがビジネス クリティカルではない場合に適しています。 SQL Server Management Studio BACPAC のエクスポートとインポート ファイルを使用、またはバックアップと復元の方法を使用、またはデータベースをデタッチしてからアタッチするなど、いくつかの選択肢があります。