SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先人の知恵を借りて自宅に Azure の S2S VPN の検証環境を固定 IPで作成してみる で投稿しましたが、検証目的で Azure と VPN 接続をできるように TP-Link の ER605 を持っています。(過去からの TP-Link の機器についての批評はいろいろありますが、ファームを最新化して、常時起動の機器としてではなく、ネットワーク系の検証を行う場合だけ取り出して使用しています)
これを使用して Azure にハブネットワークを VNET ベースで作成し、Azure / オンプレミスをスポークとして接続した際に調べた内容をメモとして。
投稿時点では、Ebdsv5 / Ebdsv5 シリーズのインスタンスを使用した Azure VM では、ディスクとの接続インタフェースとして NVMe を使用することができます。
Ebdsv5 シリーズは VM サイズ: Azure VM 上の SQL Server のパフォーマンスに関するベスト プラクティス で記載されているように、幅広い SQL Server のワークロードを動作させるために推奨される VM となっています。
今後、Azure VM で SQL Server を動作させる際に最適なパフォーマンスを発揮するためには NVMe の利用を検討するシーンも出てくるかと思い検証をして得られた知見をまとめておきたいと思います。
先日 Azure Database Migration Service を使用した SQL Server から SQL Server on Azure VM への移行で今後期待したい改善 として、Azure DMS についての投稿を書きました。
2023/1/28 時点では、DMS のデフォルトの動作では、移行先のデータベースとして可用性グループに参加させるデータベースを想定して作業を実施した場合、いくつかのポイントがあります。
本投稿では、DMS を使用して移行先のデータベースを可用性グループにする場合のポイントをまとめておきたいと思います。
Optional settings for database migration for Always On availability group でフィードバックをしてみたのですが、Azure Database Migration Service (DMS) を使用して、SQL Server から SQL Server on Azure VM に移行をする場合に、今後改善してもらえるとよい点について情報を残しておきたいと思います。
以前投稿した 複数サブネット構成を使用した SQL Server on Azure VM の可用性構成について に近いものとなりますが、改めて特徴を把握しておきたいと思います。
Azure Policy では、ゲスト構成機能 (Guest Configuration: GC) により、環境内のマシンの状態を管理することができます。
ゲスト構成は、次のいずれかの環境に対して使用することができます。
Azure だけでなく、Azure Arc 対応サーバーをインストールしている環境についても Azure Policy のゲスト構成機能を活用することができます。(Azure の仮想マシンについては追加コストは発生しませんが、Azure Arc の環境については追加コストが発生します)
Azure Policy では組み込みポリシー定義が提供されており、Azure 仮想マシンならびに Azure Arc 向けのポリシーが提供されています。
これらのポリシーの中には、ゲスト構成機能を使用したルールも提供されており、本投稿はゲスト構成機能を使用したルールの監査状況の確認方法をポータルから実施する際の操作を調べたものとなります。
ゲスト構成機能については冒頭に紹介したドキュメントも含めた、次の内容を確認しておくとよさそうです。
先人の知恵を借りて、自宅の検証環境に、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 エージェントをインストールすることでも同様のことは実現できます。
