SE の雑記

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 Server インストール済みイメージの仮想マシン
• Windows Server のイメージ対して SQL Server をセルフインストールした仮想マシン

というような環境については、SQL VM リソースプロバイダーはインストールされておらず、手動で SQL VM リソースプロバイダーの登録を行う必要がありました。

今回追加された自動登録機能は、「現在 SQL VM がインストールれていない仮想マシン」「今後、SQL Server をセルフインストールした仮想マシン」を自動的に SQL VM リソースプロバイダーに登録を行ってくれるという機能となります。

SQL VM リソースプロバイダーに登録することで、ライセンス管理 や SQL Server IaaS Agent 拡張機能による管理性の向上 というようなメリットがあるため、Azure の仮想マシンで SQL Server を実行する場合には、基本的に登録が行われるようにしておいた方が、様々なメリットを受けることができます。

機能が追加されていたことは知っていたのですが、まだ実際に動作を確認していなかったので自動登録の機能を確認してみました。

Read the rest of this entry »

Azure Functions が PowerShell 7.0 をサポートしたこで、PowerShell をランタイムとして使用した関数で、ForEach-Object の Parallel が使用できるようになり、スクリプトブロックを並列で実行することができるようになりました。

以前は Runspace を作成して、並列処理を自分で組む必要がありましたが、ForEach-Object でシンプルな記述で並列に実行できるようになったのはうれしいですね。

このような並列処理は、DB のメトリックを取得するときの収集処理で活用することができ、メトリック収集用のクエリを一つ順次実行するのではなく、いくつかのクエリを並列で実行することで、処理時間を短縮することができ、鮮度の良い情報の取得を行うことができます。

SQL Database では、標準でいくつかの方法で情報が取得されています。

• Azure SQL Database の Query Performance Insight
• Azure SQL Analytics (プレビュー) を使用した Azure SQL Database の監視
• Azure SQL Database と Azure SQL Managed Instance での監視とパフォーマンス チューニング

これらの標準機能を使用しても、情報の収集を行うことも、もちろん可能ですが、特定の状況かで必要となる情報が不足していることがあり、SQL Database の状態を確認するためは、追加でメトリックの収集を行う必要が出るケースがあります。

そのような場合、私は PowerShell で SQL Database に対してクエリ実行を行いメトリックの収集を行い、そのメトリックを Log Analytics に格納することで確認をしているのですが、情報を取得 / 可視化を毎回一から作るのも面倒ですので、ある程度まとまった仕組みを EZMonitor (Easy Monitor) として作成してみました。
(情報収取のクエリについては、ざっくりしたもののみ追加しているため、まだ修正の必要がありますが)

↓ GitHub のリポジトリからも、こちらのアイコンからもデプロイできます。

展開時に情報の取得を行う、SQL Database を指定することで、Log Analytics に取得を行ったデータを、次の画像のように可視化することができます。

標準では、5 秒間隔で 4 スレッドで情報を取得しており、Basic / S0 のような低い性能のサービスレベルでは、CPU の使用率を上昇させる要因になります。

CPU 使用率を上昇させた場合は、取得間隔や並列度数を調整してください。

Read the rest of this entry »

Synapse Workspace では、ワークスペースのリソースをデプロイする際に、Managed VNET に関連付けができます。(デプロイ時にのみ設定することができ、ワークスペースの作成後に設定を変更することはできません)

詳細については、Azure Synapse Analytics のマネージド仮想ネットワーク (プレビュー) に記載されているのですが、この辺の設定がいまいちわかっていなかったので、情報を整理しておこうかと。

Read the rest of this entry »

先日 Preview support for Azure Shared Disks for SQL Server failover cluster instance on Azure IaaS is now available というアナウンスがありました。

詳細なアナウンスについては Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs でも公開されています。

SQL Server 2019 CU2 以降+ Windows Server 2019 以降を使用することで Azure 上で、共有ディスク型の Failover Cluster Instance (フェールオーバー クラスター インスタンス : FCI) を構築できるようになりました。

軽く構築をしてみてみましたのでその際のメモを。

構築方法については、Create an FCI with Azure shared disks (SQL Server on Azure VMs) を参照してください。

Read the rest of this entry »

Azure 上で、PowerShell を実行する場合、Function App を使用して書いてしまうことが多いのですが、実行時間やスケジュール設定の GUI 視認性 (cron 形式ではないスケジューリングの設定) などで、Azure Automation の PowerShell Runbook を使用してスクリプトを実行するケースもあるかと思います。

どうやって使ったかというのを忘れることがしばしばあるので、この機会にまとめておこうかと。

Read the rest of this entry »

SQL Database の基本的な診断情報の取得について -2020/3/20 版 で触れた、リソース正常性の検出方法である、リソースヘルスアラート (Resource Health Alert) を実際に設定してみました。

設定方法については、Resource Manager テンプレートを使用して Resource Health アラートを構成する の内容そのままですね。

どのような正常性チェックが使用できるかについては、Azure Resource Health で利用できるリソースの種類と正常性チェック に記載されています。

リソースヘルスアラートについては、ポータルからは設定することができず、ARM テンプレートベースのデプロイで設定を行う必要があります。

設定については、次の 2 ステップで作業を実施します。

1. アクショングループの設定
2. リソース ヘルス アラートの ARM テンプレートを作成

Read the rest of this entry »

Azure Front Door—March 2020 updates でアナウンスがありましたが、Front Door のアイドルタイムアウトの設定が変更できるようになりました。

Configurable idle timeout—Customize the idle timeout when Front Door waits on the first packet of request/response.

Azure Front Door Service の制限 にも記載されていますが、Front Door からバックエンドへの応答については次のような制限があります。

Front Door からアプリケーション バックエンド

• 応答がチャンク応答の場合、先頭のチャンクを受信したときに 200 が返されます。
• HTTP 要求がバック エンドに転送された後に、Front Door はバック エンドからの最初のパケットを 30 秒間待機します。 それからこれはクライアントに 503 エラーを返します。
• バックエンドからの最初のパケットを受信した後、Front Door はアイドル タイムアウトの 30 秒間を待ちます。 それからこれはクライアントに 503 エラーを返します。
• Front Door からバックエンド TCP セッションへのタイムアウトは、30 分です。

デフォルトの設定では、バックエンドから 30 秒応答がない場合は 503 エラーが返されることになります。
この設定が変更できるようになりました。

Read the rest of this entry »

SQL Database の認証には、Azure のリソースのマネージド ID (MSI) を使用することができるようになっています。

• チュートリアル:マネージド ID を使用した App Service からの Azure SQL Database 接続のセキュリティ保護

• チュートリアル:Windows VM のシステム割り当てマネージド ID を使用して Azure SQL にアクセスする

• Azure Logic Apps でマネージド ID を使用して Azure リソースへのアクセスを認証する

• Data Factory のマネージド ID

• Azure Container Instances でマネージド ID を使用する方法

• Azure リソースの Azure AD マネージド ID のドキュメント

マネージド ID をサポートしているサービスについては  Azure リソースのマネージド ID をサポートするサービス に記載されていますが、これらのサービスが接続をする際にはマネージド ID による接続ができる可能性があります。

Read the rest of this entry »

以前から、イベントハブに送信された Azure の診断ログを SQL Databae に取り込むということができていたかと思います。

• Azure SQL Database への Azure Stream Analytics の出力

昨年末ぐらいに、Azure SQL Database Stream Analytics 統合という機能がプレビューとして提供され、SQL Database のブレードからも Stream Analytics によるデータ取り込みの設定を行うことができるようになりました。

• Azure SQL Database Stream Analytics 統合を使用してデータをストリーム配信する (プレビュー)

ブログのログをイベントハブに送信しながら、Stream Analytics から SQL Database のテーブルにデータ取り込みを実施してみたのでその時の覚書を。

今回はブログのフロントに配置している Front Door の診断ログ (アクセスログ) をイベントハブに送信し、それをテーブルに受け取るような設定を使っています。
(1 か月回していると、それなりの金額になりそうですので、今は BLOB に出力されている JSON を Data Factory 経由で取り込みを行うようにしています。)

Read the rest of this entry »

本ブログですが、今まではレンタルサーバー上で稼働させていたのですが、結構な頻度で 500 エラーが発生していたと思います。
ということで、ブログを Web Apps 上にお引越ししてみたところ、500 エラーの発生状況は改善したようでした。
(低いサービスレベルで動作させているからか、安定性がいまいちで、まだまだ対応が必要なことが多いですが…。)

左がレンタルサーバー上で実行していた時のステータスコードの比率なのですが、1 日のアクセス数の中で 18% 近くが 500 エラーとなっていたんですね…。

個人サイトですので、SLA は必要がないのでひとまず、F1 で動作させているのですが、Free や Standard というようなサービスプランでは、1 日の中で CPU が使用できる時間が決まっています。

次の画像は料金表の内容となります。

F1 で 60 分 / D1 で 240 分の CPU 時間を使用することができるのですが、私のサイトの場合、F1 では確実に CPU 時間が不足し、D1 では平日にいろいろと作業をした場合に CPU 時間が不足する可能性があるのですよね。

ということで Azure Automation を使用して、クォータのリミットに近づいているかを取得しながら、スケールアップをするスクリプトが組めるかどうかを試してみました。

今回の処理は実行時間が長いわけではないので、Azure Automation ではなく、Azure Functions で実行した方が手っ取り早いのですが、今の Automation がどのようになっているのかを知りたくて、Automation を使っています。

Read the rest of this entry »