SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

SQL Database Managed Instance に Database Migratoin Service を使用してデータベースの移行を実施する

leave a comment

本投稿は 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 接続を構成する

今回は、次のような仮想ネットワークの構成にしています。

image

MI は東日本に配置し、その仮想ネットワーク内に、移行元の SQL Server も配置しています。
DMS については米国西部の仮想ネットワーク配置し、この仮想ネットワーク間を仮想ネットワークゲートウェイ間で接続をした構成です。

この構成であれば、DMS が移行元の SQL Server と、移行先の MI に対して接続をすることが可能ですね。

DMS は、SQL Server 2005 以降に対応しているのですが、投稿を書いている時点で対応しているのは、SQL Server 2005 ~ SQL Server 2016 までとなっているようです。

SQL Server 2017 に接続を試みても次のエラーになって接続をすることができません。
image

今回は移行元として SQL Server 2016 を準備しています。

DMS でのプロジェクトの作成方法については割愛しますが、今回は次の画像のような、名前付きインスタンスとして作成された、SQL Server 2016 内のデータベース (WorldWideImporters-Standard) を MI に移行するためのプロジェクトを作成しています。

image

DMS は

  1. プロジェクトの作成  (どのサーバー間で移行をするかの設定)
  2. 移行用のアクティビティの作成 (実際の移行処理の設定)

という流れで、移行を実施しますので、プロジェクトの作成が終わったら、プロジェクト内にアクティビティを作成します。

image

アクティビティでは、次の画面の内容を設定する必要があります。

image

  • 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」の「完全バックアップ」として取得が行われているようです。
image

次に Azure BLOB ストレージにアップロードが行われます。

image

アップロードが終わったら、MI にリストアされ、最終的にバックアップファイルは削除されるようです。

この一連の流れを、サービスとして実行することができるのが DMS を使用した MI の移行になります。

移行の結果についてはポータルから確認することが可能です。image

現状、マイグレーションのアクティビティの再実行 (再利用) というのができないようですが、失敗時のリトライについての Feedback が上がっているようですので、リトライについても今後改善される可能性がありそうですね。

Written by masayuki.ozawa

4月 22nd, 2018 at 3:50 pm

Leave a Reply

*