先人の知恵を借りて、自宅の検証環境に、Azure のサイト対サイト (S2S) の VPN の検証環境を固定 IP で作成してみた際のメモを。
固定 IP については、Azure愛が強すぎて自宅にAzure専用固定IPプロバイダを契約しマルチセッションにした話 を参考にさせていただき、S2S VPN については、8800円の格安VPNルータで家とAzure間をサイト対サイトVPN(IPSec)で接続する を参考にさせていただいています。ありがたや、ありがたや。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先人の知恵を借りて、自宅の検証環境に、Azure のサイト対サイト (S2S) の VPN の検証環境を固定 IP で作成してみた際のメモを。
固定 IP については、Azure愛が強すぎて自宅にAzure専用固定IPプロバイダを契約しマルチセッションにした話 を参考にさせていただき、S2S VPN については、8800円の格安VPNルータで家とAzure間をサイト対サイトVPN(IPSec)で接続する を参考にさせていただいています。ありがたや、ありがたや。
発表されてからかなり日が経っているのですが、Azure VM で SQL Server の可用性構成を構築する場合に、複数サブネット (マルチサブネット) 構成を使用することで、従来の構成と比較して構成の簡略化が行うことができるようになっています。
アナウンスとしては次の内容となり、
技術情報としては次の内容となります。
基本構成としては下図のようになり、複数のサブネットに VM を配置し、ロードバランサーは不要で、可用性グループにアクセスを行うことができる構成を Azure 上に展開することができます。
FCI についても、複数サブネットを使用して同様の構成を行うことができ、単体のチュートリアルは提供されていないのですが、https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/failover-cluster-instance-prepare-vm?view=azuresql&tabs=multi-subnet#subnets で情報が公開されています。
本投稿ではこの複数サブネット構成について触れたいと思います。
なお、今回の投稿のメインとなる内容は Windows の SQL Server を使用した Always On 可用性グループについてとなります。
最近、Azure CLI の通信内容を Fiddler でキャプチャ (トレース) する機会があったのですが、Fiddler で HTTPS のキャプチャを有効化しても取得でき内容でしたので、対応方法のメモを。
と言っても、キャプチャする際に参考にさせていただいたサイトの紹介ですが…。
基本的な作業としては次のサイトで紹介されている方法で対応できました。
公式のドキュメントとして Work behind a proxy の内容になるのでしょうね。
Fiddler は Proxy として、HTTP の通信をキャプチャしていますので、Fiddler のルート証明書を PEM 形式に変換して、Azure CLI を実行する前に環境変数の「REQUESTS_CA_BUNDLE」に cer を変換した pem ファイルのフルパスを指定しておけば、Azure CLI の通信内容を Fiddler でキャプチャできるようになります。
Azure Arc enabled SQL Server (Azure Arc 対応 SQL Server) をインストールすることで、Azure 以外で稼働している SQL Server を Azure 上で管理 / Azure の一部の機能の管理性を提供することができるようになります。
インストールしただけの状態でも、いくつかの管理機能を使用することができますが、「SQL Server の運用」を考慮した場合、ちょい足しすると便利になる箇所がありますので、本投稿では、そのちょい足しの一例を紹介したいと思います。
今回は Azure Arc enabled SQL Server の環境で実施していますが、enabled SQL Server ではなく、SQL Server がインストールされている環境に、Log Analytis エージェントをインストールすることでも同様のことは実現できます。
SQL Server on Azure VM で実行している SQL Server では、SQL Server IaaS Agent 拡張機能 を使用することができます。
この拡張機能を使用することで、Azure VM (仮想マシン) 上で実行している SQL Server の運用の利便性を向上させることができ、今回、話題にする「自動バックアップ機能」につても、利便性を向上させることができる機能の一つとなっています。
この自動バックアップ機能について、少し調べる機会がありましたので、自動バックアップ機能の構成についてまとめておきたいと思います。
Azure の Marketplace で公開されている SQL Server on Azure VM のイメージは、英語版の環境で構築されているため、日本語環境相当で利用するためには、いくつかの設定が必要となります。
MS ブログでも次の情報として公開が行われています。
基本的な作業については、上記の内容となるのですが、SQL Server on Azure VM も上記の情報の公開後から、いくつかの機能が追加されていますので「Marketplace のインストール済みイメージの展開相当の状態」にするには、上記のドキュメントの他に、いくつかのポイントがあります。
必要となる作業とポイントについては、本投稿でまとめていますが、そもそもとして「本当に日本語版の SQL Server を使用する必要があるのか?」は意識しておいた方がよいかと思います。
インスタンスレベルの照合順序を日本語版の SQL Server の照合順序 (Japanese_CI_AS や Japanese_xxxxx 系) にする必要があり、英語版の SQL Server を使用しても問題ないのであれば、VM 展開直後に サーバーの照合順序の設定または変更 でインスタンスレベルの照合順序を変更したほうが楽です。
本投稿では「SQL Server 2019 on Windows Server 2019」の「SQL Server 2019 Enterprise on Windows Server 2019 Databas Engine Only」の Marketplace のイメージを日本語化するシナリオで記載しています。
2020/10 に Register Your Azure SQL Virtual Machines with SQL Server IaaS Agent extension today でアナウンスがありましたが、SQL Server IaaS Agent 拡張機能を自動的に登録する機能が Azure に実装されました。
ドキュメントとしては、SQL IaaS Agent 拡張機能への自動登録 で公開されている機能となります。
「SQL 仮想マシン」のブレードに「SQL Server VM の自動登録」というメニューが追加されており、サブスクリプション全体に対して SQL Server VM の自動登録を有効にすることができます。
2019/7 以降に Azure Marketplace の SQL Server インストール済みイメージから展開した場合は、「SQL VM リソースプロバイダー」が有効になっているため、SQL IaaS Agent 拡張機能についても登録が行われた状態となっています。
というような環境については、SQL VM リソースプロバイダーはインストールされておらず、手動で SQL VM リソースプロバイダーの登録を行う必要がありました。
今回追加された自動登録機能は、「現在 SQL VM がインストールれていない仮想マシン」「今後、SQL Server をセルフインストールした仮想マシン」を自動的に SQL VM リソースプロバイダーに登録を行ってくれるという機能となります。
SQL VM リソースプロバイダーに登録することで、ライセンス管理 や SQL Server IaaS Agent 拡張機能による管理性の向上 というようなメリットがあるため、Azure の仮想マシンで SQL Server を実行する場合には、基本的に登録が行われるようにしておいた方が、様々なメリットを受けることができます。
機能が追加されていたことは知っていたのですが、まだ実際に動作を確認していなかったので自動登録の機能を確認してみました。