Log Analytics API について少し整理しておきたい内容がありましたので、調べた内容をメモとして残しておきたいと思います。
Archive for the ‘Microsoft Azure’ tag
Microsoft Defender for Cloud のサブスクリプションレベルと Log Analytics ワークスペースレベルの違い
Microsoft Defender for Cloud を有効化する方法には「サブスクリプションレベル」「Log Analytics ワークスペースレベル」の 2 種類があります。
設定については、環境設定 から実施することができるのですが、このブレードでサブスクリプションを選択するか、Log Analytics ワークスペースを選択するかによって、どのレベルで設定するかが変わってきます。(既定のワークスペース については Microsoft Defender for Cloud の個別の設定を行うことができないようです)
Microsoft Defender for Cloud について問い合わせをしていて、サブスクリプションレベルと Log Analytics ワークスペースレベルの設定の違いを教えていただくことができましたので、情報をまとめておきたいと思います。
Azure Arc を使用した Admin Center の管理を日本語環境で実施する場合の注意点 (2022/6/20 時点)
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 対応サーバーを管理する (プレビュー) で公開されています。
Bastion の IP ベースの接続が GA したのでオンプレミスサーバーに接続してみる
General availability: Azure Bastion IP based connection のアナウンスがあり、Bastion で IP ベースの接続の一般提供が開始されました。
設定方法 / 利用方法については Connect to a VM via specified private IP address through the portal で解説されていますが、今までこの機能を追ったことがなかったので試してみました。
SQL Server IaaS Agent 拡張機能を使用して SQL Server on Azure VM の管理性を向上させる (2021/2 最新情報)
先日、次のような投稿を書きました。
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 にはこれ以外の機能も豊富に含まれており、次のような機能を利用することができます。
- BYOL / AHUB (AHB) / SA の DR 特典のライセンスモデルをVM の再構築をすることなく変更が可能
- エディション / バージョン変更をした場合の VM の課金の変更
- SQL Server に適したストレージの設定
- ポータルからストレージを拡張
- OS / SQL Server の重要なパッチについて、スケジューリングして適用が可能
- SQL Server の暗号化機能の暗号化キーを Key Vault に格納し、管理性を向上
- インスタンス内の全データベース (今後、作成されるデータベースを含む) を自動的にバックアップ
- 高可用性環境の構築をポータルから実施可能
投稿内にも記載していますが、サブスクリプション内の現在の 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 IaaS Agent 拡張機能の自動バックアップ機能について
SQL Server on Azure VM で実行している SQL Server では、SQL Server IaaS Agent 拡張機能 を使用することができます。
この拡張機能を使用することで、Azure VM (仮想マシン) 上で実行している SQL Server の運用の利便性を向上させることができ、今回、話題にする「自動バックアップ機能」につても、利便性を向上させることができる機能の一つとなっています。
この自動バックアップ機能について、少し調べる機会がありましたので、自動バックアップ機能の構成についてまとめておきたいと思います。
Power BI データフローで使用するストレージに ADL Gen2 を利用する
2021/1 時点では、プレビューの機能となりますが、Power BI データフロー で使用するストレージを、Power BI で提供される内部ストレージではなく、Azure Data Lake Storage Gen2 (ADL Gen2) を使用するという設定があります。
この設定により ADL Gen2 を使用した場合、どのようにデータが格納されるのかを確認したことが無かったので、一度試してみました。
SQL Server on Azure VM の AlwaysOn 可用性グループで DNN がサポートされました
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 可用性グループにアクセスする際にロードバランサーを使用することなくアクセスができるようになります。
関連情報は次のドキュメントとなります。(投稿を書いている時点では、英語版にのみ情報が公開されています)
Azure Functions で PowerShell 7.0 が使用できるようになりました
アナウンスされていたのかがわかっていないのですが、以前から manually specify powershell version (e.g. 7) という Issue があり、Azure Functions の PowerShell 7.0 のサポートについてディスカッションが行われていました。
The rough ETA for official GA (including portal and tools support) is the beginning of July.
正式な GA は 7 月上旬ということになっていたので、ポータルを確認してみたところ、7.0 を選択できるようになっていました。 
Windows 上で動作している PowerShell 7.0.0 として認識されていますね。
PowerShell 7.0 になると、ForEach-Object に追加された並列実行 が使用できるようになるのがうれしいですね。
(Foreach の Parallel については Example 11: Run slow script in parallel batches 以降の情報も参考になります)
Azure Functions の PowerShell のランタイムスタックですが、昔は関数のテンプレートは HTTP / Timger Trigger 程度だったと思っていたのですが、今は使用できるテンプレートが増えており、各種トリガーや Preview で Durable Functions のテンプレートも選択できるようになっています。 
まだドキュメントは読めていないのですが、Durable Functions Support for PowerShell で Issue が上がっており、Github 上で、How to try Durable PowerShell functions として、チュートリアルが公開されています。
SQL Database 関連の関数を Timer トリガーで作ることは結構あるのですが、それ以外のトリガーは使っていなかったので、色々なトリガーを触ってみないとですね。
Visual Studio Code を使用した PowerShell の関数開発でも、PowerShell 7.0 を使用することができるようです。
PowerShell 7.0 を使用するためには、ランタイムバージョンは 3.0 を使用するようにして、次のような設定を行う必要があるようです。
1. Azure Functions Core Tool 3.x をインストールする
npm install -g azure-functions-core-tools@3
2. 「.vscode\settings.json」 の「azureFunctions.projectRuntime」を「~3」に変更
(Core Tool 3.x が入っていれば、デフォルトで ~3 になっていると思います)
3. 「local.settings.json」に「"FUNCTIONS_WORKER_RUNTIME_VERSION": "~7"」を追加
これで、VS Code で PowerShell Functions の開発を行った際の PowerShell のバージョンを 7.0 にすることができます。
PowerShell で Azure REST API にアクセスする際の覚書
PowerShell で Azure の REST API を実行しようと思った際に、良く忘れてしまうのでメモとして。