SE の雑記

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

Azure SQL Managed Instance の リンク機能 (MI Link) で SQL Server 2019 とデータ同期を実施してみる

leave a comment

SQLBits 2022 でアナウンスがありましたが、SQL Server から Azure SQL Managed Instance (MI) とデータ同期をするための機能となる、Azue Managed Instance のリンク機能 (Link feature for Azure SQL Managed Instance / Managed Instance Link) が Public Preview となりました。

SQL Server 2022 と同時にこの機能のアナウンスも行われていたのですが、当初は Limited Preview となり限定されたプレビューでの公開となりました。(アナウンス時の情報は、Managed Instance link – connecting SQL Server to Azure reimagined となります)

今回、Public Preview となり、任意の環境で検証ができるようになりましたので、情報をまとめておきたいと思います。

 

追記

Tech Community でもアナウンスが行われました。

Managed Instance link機能の情報

Managed Instance link の情報ですが、本投稿を書いている時点では、英語版の情報が最新となり、検証を行う際には次の情報を確認するとよいのではないでしょうか。

 

検証を行うための環境

検証を行うために必要となる環境については、Prepare environment for link feature – Azure SQL Managed Instance で情報が公開されています。

GUI 操作で検証を行うのであれば、SQL Server としては次の環境が必要となります。

  • SQL Server 2019 Enterprise or Developer Edition CU15 以降
  • SSMS 18.11.1 以降

Azure SQL News Update | Data Exposed Live @SQLBits 2022 で公開されている内容としては次のスライドの情報がありました。

image

今後のロードマップとしては、SQL Server 2016, 2017 ならびに Standard Edition のサポートが計画されているそうですが、現時点では、SQL Server 2019 でサポートされるエディション / 累積修正プログラムを使用する必要があります。

MI  は パブリック エンドポイントを有効化することで、パブリック IP 経由でアクセスすることもできますが、閉域環境で検証を行う場合は、MI と同一の VNET に参加 or 接続する必要があります。

SQL Server on Azure VM で検証をするのであれば、MI と同一の VNET に検証環境を作成すればよいですが、オンプレミスの環境で MI のパブリック IP を無効にした状態で、検証を行う場合は、SQL Server をインストールした環境を、ポイント対サイト (P2S) 接続の VPN で MI の VNET と接続をすることで検証を行うことができます。(P2S は接続をするたびに IP アドレスが変わると思いますので、P2S は検証目的以外での利用は厳しいかと)

本機能を検証する場合には、

  • サポートされる SQL Server
    • MI とネットワーク的に接続された環境とする
  • データ同期先の Managed Instance

を用意することができれば、検証を行うことができます。

Managed Instance link の設定方法

リンク機能の設定方法については Prepare environment for link feature – Azure SQL Managed Instance に記載されており、次のような作業を SQL Server に対して実施します。

SSMS 18.11.1 では、Managed Instance link の設定がサポートされており、データベースの操作メニューから設定を行うことができます。
image

このウィザードの中では前提条件として上述の内容が設定されているかがチェックされており、このタイミングで設定状況を確認することができます。

image

Managed Instance Link は AlwaysOn 可用性グループの分散型可用性グループのアーキテクチャが使用されており、設定を行うためには、SQL Server で AlwaysOn 可用性グループが有効化されている必要があります。

AlwaysOn 可用性グループを構成する必要はなく、機能として有効化されていれば設定することができますので、スタンドアロンの SQL Server でも使用することが可能です。

AlwaysOn 可用性グループを動作させるために必要となる設定については、ウィザードの中で実施されますので、明示的に設定を行わなくても、必要な設定が自動的に行われます。

image

セットアップについてはスクリプト化することもできますので、ウィザードでどのような設定が行われているかを確認したい場合は、スクリプト化して中身を見ておくとよいかと思います。

MI Link は証明書を使用してエンドポイント間の接続を実施していますが、「どのような証明書を使用しているか」「どのように証明書を MI にインポートしているか」はスクリプトから確認することができます。

また、エンドポイントの接続に使用するリスナー URL の定義についても、スクリプトから確認可能です。

 

正常に設定が行われると、分散型可用性グループとして、SQL Server と MI が設定された状態となり、SQL Server のデータベースが MI に同期されます。

image

 

TCP 5022 による接続のテスト

MI Link は、SQL Server と MI のデータ同期をデータベースミラーリングエンドポイントを使用して実施するため、TCP : 5022 間の通信 (デフォルト設定で使用するポートを利用した場合) が必要となります。

SQL Server と MI の両環境で、TCP : 5022 の通信が許可されていないと、同期を行うことができないので、セットアップを実施する間に絵は、Prepare environment for link feature – Azure SQL Managed Instance に記載されている、

  • SQL Server -> MI への TCP : 5022 の接続のテスト
    • TCP:5022 の通信については Windows Firewall で設定
  • MI -> SQL Server への TCP : 5022 の接続のテスト
    • TCP : 5022 の通信については NSG で設定
    • デフォルトの設定で、allow_geodr_inbound / allow_geodr_outbound というルールで、MI のサブネットと Virtual Network のサービスタグ間の 5022 の通信は許可されているので、このルールに該当するネットワーク内であれば、明示的に操作をしなくても MI 側の設定は完了しています

を事前に実施しておくと、設定時に同期に必要な通信が阻害されていないかを確認しておくことができます。

SQL Server  / MI のどちらの方向の接続についても、Test-NetConnection という PowerShell のコマンドレットを使用しています。

MI の OS には直接ログインをすることはできませんが、SQL Server エージェントジョブで PowerShell を実行することができるため、ドキュメントではエージェントジョブを使用した MI -> SQL Server の通信の確認をしているのは面白い方法だと思います。

 

P2S VPN を使用した場合の IP アドレスの指定

P2S の VPN で MI の VNET と接続する場合、SQL Server IP アドレスの設定については、P2S の VPN のアドレスプールから割り当てられている IP アドレスを設定します。

image

 

同期可能なデータベース数の上限

通常の分散型可用性グループであれば、「1 可用性グループに複数データベースを配置」することができますが、MI Link では「1 可用性グループ=1 データベース」となり、How it works に記載されているように、最大で 100 個のリンク = 100 データベース同期を設定することができます。

There could exist up to 100 links from the same, or various SQL Server sources to a single SQL Managed Instance.

複数のサーバーの DB を同期することも可能ですが、同期可能なデータベース数については上限がありますので、大量のデータベースを同期する場合は上限数は意識しておく必要が出てきます。

フェールオーバーの実行

MI は非同期レプリカの読み取り専用サーバーとして設定が行われており、MI を更新可能なプライマリとして設定したい場合には、SSMS からフェールオーバーを実施することができます。

image

現状、フェールオーバーについては、SQL Server -> MI への一方通行のみ可能となっており、MI -> SQL Server へのフェールオーバーは実施することはできません。

MI -> SQL Server への DB 移行については、現時点では SQL Server 2022 の MI から SQL Server へのデータベースリストアの機能まで待つ必要があるのではないでしょうか。

 

TDE を有効にしたデータベースとのデータ同期

SQL Server 上で、TDE を有効にしたデータベースを MI と同期する場合には、追加で作業が必要となります。

TDE が有効になっている DB を MI と同期をしようとして、何も追加の設定を行っていない場合、データベースの同期に失敗します。

MI に TDE で保護されている SQL Server のデータベースをリストアするための技術情報として、次の情報があります。

TDE で保護されているデータベースの同期については、上記の TDE で保護されているデータベースをリストアするための準備と同一の作業を行う必要があります。

TDE で保護されているデータベースについては、暗号化に使用されている証明書のバックアップ (cer / pvk) を pfx に変換する必要があります。これには、Pvk2Pfx が必要となり、このコマンドラインを使用するためには、Enterprise Windows Driver Kit をインストールして入手する必要があります。

PFX ファイルが作成出来たら、「Add-AzSqlManagedInstanceTransparentDataEncryptionCertificate」を使用して、TDE で使用する証明書を MI にインポートしておくことで、SQL Server 上で TDE が使用されている DB を同期することができます。

 

トラブルシューティング

MI Link は分散型可用性グループのテクノロジーを使用しているので、トラブルシューティングについては

の二つの機能の運用方法をベースに問題を解決することになります。

MI 側については、確認できる情報が限定的なものとなっているため、セットアップ時のトラブルシューティングについては、

  • ERRORLOG (SQL Server ログ)
  • Managed Instance の管理用コマンド

を使用することになります。

MI Link が正常に設定できない場合、MI 側の調査としては、ERRORLOG を確認します。

image

コマンドについては「*-AzSqlInstanceServerTrustCertificate」「*-AzSqlInstanceLink」を使用することになるようですが、本投稿を書いている時点ではコマンドレットがまだ提供されていないので、管理用コマンドの提供は少し待つ必要があるかもしれませんね。(REST API についても同様の状況)

 

現状の制限事項

現時点の制限事項については、Limitations に記載されています。

  • ユーザーデータベースのみでシステムデータベースは同期できない
  • MI でサポートされていない機能を使用している場合は同期をできない
  • AG リスナーを使用できないため、フェールオーバー後はクライアントの接続の変更が必要
  • 同期している DB は MI の自動バックアッププロセスの一部にならなない

というようなことが書かれています。

Best practices with link feature for Azure SQL Managed Instance (preview) に詳細が書かれているバックアップの考慮は抑えておく必要があります。

MI Link で同期されている DB については、制限に次の記載があります。

  • Replicated databases aren’t part of auto-backup process on SQL Managed Instance.

 

同期している DB については MI の自動バックアップに含まれていないという記載があるため、SQL Server 側でデータベースのバックアップを実施する必要があります。

AlwaysOn 可用性グループの管理下の DB は、完全復旧モデルのため、トランザクションログのバックアップを定期的に取得する必要があるので、MI Link で同期している DB については、トランザクションログの定期的なバックアップは SQL Server 側で定期的に実施しないと、トランザクションログが肥大化していきます。

 

まとめ

MI Link を使用することで、SQL Server 2019 のデータベースを容易に同期することができるようになります。

これにより、

  • MI を読み取り専用ワークロードとして使用する
  • MI を DR サイトとして使用する

というような用途で、MI を使用することができるようになるのではないでしょうか。

Written by Masayuki.Ozawa

3月 12th, 2022 at 10:17 pm

Leave a Reply

Share via
Copy link
Powered by Social Snap