本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
今までの投稿では、手動で SQL Database Managed Instance (MI) に、データベースの移行を実施していました。
Azure には、データベースの移行を実施するためのサービスとして、Azure Database Migration Service (DMS) というサービスが、投稿を書いている時点ではプレビューの状態ではありますが利用することができるようになっています。
現状、対応しているパターンとしては、次の 2 パターンとなっており、MI についても、DMS を使用してマイグレーションできるようになっています。
- SQL Server -> Azure SQL Database
- SQL Server -> Azure SQL Database Managed Instance
本投稿では、Azure のサービスを使用した Migration について見ていきたいと思います。
DMS を使用した移行については SQL Server を Azure SQL Database マネージ インスタンスに移行する に記載されています。
現状の DMS については、次のリージョンで使用することができるようになっています。
- 米国西部, 米国中南部, 米国東部
- 西ヨーロッパ, 北ヨーロッパ
- ブラジル南部
これ以外のリージョンについては、DMS を配置することができませんので、DMS が利用可能なリージョンについては注意しておく必要があります。
DMS も MI と同様に「仮想ネットワークに完全に統合されたサービス」となっています。
そのため、データの移行については「DMS が配置されている仮想ネットワークからアクセス可能な場所」に限定されることになります。
ネットワーク構成としては、次の環境が相互に接続できている必要があります。
- 移行元の SQL Server
- DMS
- 移行先の MI
DMS をサポートしているリージョン内に MI を作成していた場合は、MI の仮想ネットワークに DMS 用のサブネットを作成して、そこに DMS をデプロイするということができるのですが、今回は MI を東日本に作成しているため、DMS を MI と同一の仮想ネットワークにデプロイすることができません。
リージョンを跨いだ VNET 接続である、グローバル VNET ピアリングについても現状対応しているのは、次のリージョンになるかと思います。
- 韓国南部
- 英国南部 / 英国西部
- カナダ東部 / カナダ中部
- インド南部 / インド中部 / インド西部
- 米国中南部 / 米国西部2
東日本に MI を作成した場合、現状、DMS と接続をするためには、それぞれの VNET に仮想ネットワークゲートウェイを作成し、VNET 間の接続を行う方法になるのではないでしょうか。
Azure Portal を使用した VNet 間 VPN Gateway 接続を構成する
今回は、次のような仮想ネットワークの構成にしています。
MI は東日本に配置し、その仮想ネットワーク内に、移行元の SQL Server も配置しています。
DMS については米国西部の仮想ネットワーク配置し、この仮想ネットワーク間を仮想ネットワークゲートウェイ間で接続をした構成です。
この構成であれば、DMS が移行元の SQL Server と、移行先の MI に対して接続をすることが可能ですね。
DMS は、SQL Server 2005 以降に対応しているのですが、投稿を書いている時点で対応しているのは、SQL Server 2005 ～ SQL Server 2016 までとなっているようです。
SQL Server 2017 に接続を試みても次のエラーになって接続をすることができません。
今回は移行元として SQL Server 2016 を準備しています。
DMS でのプロジェクトの作成方法については割愛しますが、今回は次の画像のような、名前付きインスタンスとして作成された、SQL Server 2016 内のデータベース (WorldWideImporters-Standard) を MI に移行するためのプロジェクトを作成しています。
DMS は
- プロジェクトの作成? (どのサーバー間で移行をするかの設定)
- 移行用のアクティビティの作成 (実際の移行処理の設定)
という流れで、移行を実施しますので、プロジェクトの作成が終わったら、プロジェクト内にアクティビティを作成します。
アクティビティでは、次の画面の内容を設定する必要があります。
- Server Backup Location
- 移行元の SQL Server のバックアップの取得先の共有ディレクトリ
- 移行元の SQL Server のサービスアカウントが指定した共有ディレクトリに対して、バックアップを出力できる権限を有している必要がある。
- User Name / Password
- DMS が、SQL Server のバックアップが取得された、共有ディレクトリにアクセスを行うために使用する資格情報
- 共有フォルダがドメイン環境でない場合「IP アドレス\ユーザー名」で指定しておく
(ユーザー名だけでは、アクティビティ作成時のバリデーションでエラーとなる)
- Storage SAS URL
- DMS が MI にリストアを行うために、バックアップをアップロードする Azure BLOB ストレージの「コンテナー」にアクセスをするための SAS の URI
- MI が BLOB にアクセスする際の資格情報としても使用される
これらをアクティビティとして設定することで、DMS による移行を実施することができます。
SAS については、バックアップをアップロードするコンテナーの SAS を指定する必要がありますので、Azure Storage Explorer を使うとよいかと。
必要に応じて、リストア後のデータベース名や、DB 単位でバックアップ先を変えるということもできるようですね。
アクティビティを実行すると、指定した共有ディレクトリにバックアップが取得されます。
複数ファイルに分割して取得しているようですね。
この際のバックアップについては「COPY_ONLY」の「完全バックアップ」として取得が行われているようです。
次に Azure BLOB ストレージにアップロードが行われます。
アップロードが終わったら、MI にリストアされ、最終的にバックアップファイルは削除されるようです。
この一連の流れを、サービスとして実行することができるのが DMS を使用した MI の移行になります。
移行の結果についてはポータルから確認することが可能です。
現状、マイグレーションのアクティビティの再実行 (再利用) というのができないようですが、失敗時のリトライについての Feedback が上がっているようですので、リトライについても今後改善される可能性がありそうですね。