SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Azure のリソースのメトリックは、各リソースの「メトリック」で確認をすることや、 
メトリック エクスプローラー (すべてのサービスのメトリックまたは、Azure Monitor のブレードのメトリック) から確認することができます。 
Azure ではデフォルトで Azure Monitor による情報の取得が行われており、Azure Monitor で使用する監視データのソース にデータソースとして使用できる情報が記載されています。
パフォーマンス情報のようなメトリックについては「プラットフォーム メトリック」として、各リソースの診断設定を設定しなくても情報の取得が行われています。
このプラットフォームメトリックについての情報を確認する際には、どの情報を確認すればよいかをよく忘れてしまうので、まとめておきたいと思います。
Windows Server Azure Edition では、通常の Windows Server では提供されていない機能があり、機能差については次のドキュメントで公開されています。
Windows Server Azure Edition では、ホットパッチ機能 が提供されており、ホットパッチについては、最近、次のアナウンスがありました。
今までは、Windows Server Azure Edition で、Server Core でインストールした場合のみホットパッチの機能を使用することができたのですが、デスクトップエクスペリエンスが導入されている環境でも、プレビューとしてサポートされるようになりました。
ホットパtt期の機能は Windows Server Azure Edition でのみサポートされているため、Azure Edition の環境を展開する必要があります。Azure Edition 展開については、次のようなドキュメントが公開されています。
「1.」については、Marketplace から提供されている VM イメージで展開する方法となるのですが「2.」では、ISO を使用した展開について触れられています。
Azure Edition は ISO を使用した展開ができるんだなということで、今回調べてみました。
Log Analytics API について少し整理しておきたい内容がありましたので、調べた内容をメモとして残しておきたいと思います。
Microsoft Defender for Cloud を有効化する方法には「サブスクリプションレベル」「Log Analytics ワークスペースレベル」の 2 種類があります。
設定については、環境設定 から実施することができるのですが、このブレードでサブスクリプションを選択するか、Log Analytics ワークスペースを選択するかによって、どのレベルで設定するかが変わってきます。(既定のワークスペース については Microsoft Defender for Cloud の個別の設定を行うことができないようです)
Microsoft Defender for Cloud について問い合わせをしていて、サブスクリプションレベルと Log Analytics ワークスペースレベルの設定の違いを教えていただくことができましたので、情報をまとめておきたいと思います。
2022/6/20 時点の内容で、事象についてはフィードバックしてありますので、後日解消しているかもしれません
2020/7/13 時点で解消し、日本語環境で設定を変更せず導入ができるようになりました。(AdminCenter の拡張機能のバージョンが 0.0.0.169 は日本語版未対応でしたが、0.0.0.175 で対応されました)
Preview of Windows Admin Center for Azure Arc-enabled infrastructure でアナウンスがありましたが、Azure Arc 対応サーバー (Azure Arc Enabled Server) に、「Windows Admin Center (プレビュー)」が追加され、Azure Portal 上で、Admin Center による管理を行うことができるようになりました。
ドキュメントについては、Azure で Windows Admin Center を使用して Azure Arc 対応サーバーを管理する (プレビュー) で公開されています。
General availability: Azure Bastion IP based connection のアナウンスがあり、Bastion で IP ベースの接続の一般提供が開始されました。
設定方法 / 利用方法については Connect to a VM via specified private IP address through the portal で解説されていますが、今までこの機能を追ったことがなかったので試してみました。
先日、次のような投稿を書きました。
Azure の仮想マシン (Azure VM) で SQL Server を使用する際には、SQL Server IaaS Agent 拡張機能 (IaaS エージェント) (以下、IaaS Agent) という、Azure の仮想マシン上で実行している SQL Server の管理性を向上させる機能を無償で使うことができます。
IaaS Agent をインストールすると、仮想マシンにインストールしている SQL Server を「SQL 仮想マシン」というブレードで一元管理できるようになりますので、サブスクリプション内でどのような SQL Server を使用しているかもひと目で確認でき、管理面でもいろいろと便利です。
先日の投稿では、日本語環境の SQL Server として再インストールした場合の、IaaS Agent の再導入方法と、IaaS Agent の機能の一つである、自動バックアップについて触れましたが、IaaS Agent にはこれ以外の機能も豊富に含まれており、次のような機能を利用することができます。
投稿内にも記載していますが、サブスクリプション内の現在の VM および、今後展開する VM すべてを自動登録 のように、SQL Server がインストールされている仮想マシンが存在する場合には自動的に登録を行う機能もありますので、保持しているサブスクリプションでは、有効にしておけば、IaaS Agent の登録の抜けもないかと思います。
自動登録は、仮想マシンの再起動が不要な「軽量管理モード」での導入が基本となっていますので、稼働中の SQL Server に IaaS Agent がインストールされていない場合でも、再起動のリスクはなく、導入することができます。
軽量管理モードで利用可能な機能はライセンスモデル / エディション / バージョンの変更の機能のみとなりますが、SQL 仮想マシンのブレードによる一元管理は使用できますので、軽量管理モードでインストールするだけでも管理性は向上するかと。
Azure の仮想マシンで SQL Server を実行する場合、IaaS Agent を導入することで、適切なライセンスを使用していることの宣言にもつながりますので、SQL Server を Azure 仮想マシン上で実行する際には、自動登録の機能も活用しながら、原則導入するようにしておいた方がよいかと。
本投稿では、IaaS Agent でできることを一通り記載しましたが、運用 / 構築に関してのかなりの作業の容易性が向上するための機能を無償で使用することができます。
また、本投稿は、日本で SQL Server を利用する際には設定する機会が多いと思われる、SQL Server の日本語化を SQL Server on Azure VM (インストール済みイメージ) の日本語化 (2021/1 版) の手順で実施した環境で、確認をしていますので、IaaS Agent の各機能は日本語環境でも利用することが可能です。
SQL Server on Azure VM で実行している SQL Server では、SQL Server IaaS Agent 拡張機能 を使用することができます。
この拡張機能を使用することで、Azure VM (仮想マシン) 上で実行している SQL Server の運用の利便性を向上させることができ、今回、話題にする「自動バックアップ機能」につても、利便性を向上させることができる機能の一つとなっています。
この自動バックアップ機能について、少し調べる機会がありましたので、自動バックアップ機能の構成についてまとめておきたいと思います。
2021/1 時点では、プレビューの機能となりますが、Power BI データフロー で使用するストレージを、Power BI で提供される内部ストレージではなく、Azure Data Lake Storage Gen2 (ADL Gen2) を使用するという設定があります。
この設定により ADL Gen2 を使用した場合、どのようにデータが格納されるのかを確認したことが無かったので、一度試してみました。
DNN については、以前、Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs で、SQL Server 2019 CU2 を適用することで、Failover Cluster Instance のサポートが行われていました。
今回、Released: Support for Dynamic Network Names (DNN) Listeners for Always On Availability Groups でアナウンスがあり、SQL Server 2019 CU8 を適用することで、SQL Server on Azure VM で AlwaysOn 可用性グループを構築する際に、可用性グループのリスナーで DNN (Dynamic Network Names) Listeners がサポートされるようになりました。
これにより、AlwaysOn 可用性グループにアクセスする際にロードバランサーを使用することなくアクセスができるようになります。
関連情報は次のドキュメントとなります。(投稿を書いている時点では、英語版にのみ情報が公開されています)