先日、Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作) という投稿を書きました。
廃止予定の機能のアナウンスは Azure updates で実施されていますが、他にどのような方法があるのかが気にかかりましたので調べてみました。
Azure の 既定の送信アクセス廃止後の KMS によるライセンス認証について (2024/06/19 時点の動作)
※2024/06 時点の情報 / 環境で確認をしているため、今後動作は変わっている可能性があります。
2023/09/29 に Default outbound access for VMs in Azure will be retired? transition to a new method of internet access というアナウンスがありました。(2023/10/19 に Default outbound access for VMs in Azure will be retired? updates and more information 追加情報のアナウンスが行われています)
現状は、既定の送信アクセス が有効となっているため、明示的なインターネット送信接続の設定が行われていない場合、「既定の送信パブリック IP アドレス」が割り当てられ、インターネットへの送信接続が可能となっています。
2025/09/30 以降に新しくデプロイされたリソースについてはこの既定の送信アクセスが廃止され、これ以降にデプロイした VM については、既定の送信アクセス以外の方法 (パブリック IP アドレスの付与 / NAT ゲートウェイをサブネットに割り当て / パブリック IP アドレスを持つロードバランサーに割り当て) でインターネット送信接続の経路を確保する必要があります。
(期限日以降に展開した VM と VNET のどちらが対象となるのかが判断できていないため「リソース」という記載をしています)
今まで既定の送信アクセスを使用して、Windows のライセンス認証のための KMS にアクセスしていた VM について、既定の送信アクセスが廃止された後はどのような挙動になるのかが気になり試してみました。
スタンドアロン環境の SQL Server インスタンスで診断ログ (SQLDIAG ログ) を取得する
FCI (フェールオーバークラスターインスタンス) 環境の SQL Server では、デフォルトの設定で診断ログが取得されています。
グディレクトリに SQLDIAG ログが拡張イベントのファイルとして出力されており、問題が発生した場合にはこのファイルの内容の解析を行うことがあります。
スタンドアロン環境の SQL Server インスタンス (非 FCI の単一サーバー環境) では診断ログは出力されていないのですが、設定を行うことでスタンドアロンインスタンスでも取得を行うことができます。
検証環境には FCI も構築している環境はあるのですが、スタンドアロンインスタンスのほうが検証を実施しやすい内容があるため、本投稿ではスタンドアロンインスタンスで診断ログを取得する方法についてまとめておきたいと思います。
パイプラインによるデータコピーで ADL Gen2 をステージングアカウントとして使用した場合にディレクトリが残る問題についての対応方法
Data Factory のコピーアクティビティーを使用したデータコピーでは、ステージングコピー を使用することができます。ステージングは、DWH に対してデータコピーを行う際に使用されるケースがあるのではないでしょうか。
ステージング コピーのしくみ には次の記載があります。
コピー アクティビティの実行後に一時データをクリーンアップできるように、ステージング ストレージ内の Azure Data Factory に削除アクセス許可を付与する必要があります。
コピーアクティビティにより格納されたステージングデータですがアクティビティ内のクリーンアップで自動的に削除が行われます。
しかし、Azure BLOB ストレージを使用している場合は問題ないのですが、ADL Gen2 をステージングアカウントとして使用した場合、コピーアクティビティが実行されるたびに、指定したステージングデータを格納するコンテナー内にファイルは存在しないのですが、GUID のディレクトリが残った状態となるという事象が発生します。
本事象ですが、ADL Gen2 をステージングアカウントととして指定した場合に必ず発生するわけではなく、コピー先によって発生有無が変わってくるようです。今回は、Fabric の Data Warehouse に対してデータのコピーを実施する際に発生しましたが、Synapse DWH でも発生するはずです。
この動作は現時点では想定された動作となり (SR で確認済み) 、ディレクトリの削除をパイプライン内で実行するためには本投稿のような対応を検討する必要がありますので、対応方法を残しておきたいと思います。
SQL Database の JSON データ型のデータ格納効率を確認してみる
Build 2024 のタイミングで次のアナウンスがありました。
Public Preview として、JSON データ型が発表されており、最近、実際に使用することができるようになりました。
データベース (データストア) 内での AI 関連の機能の利用について (2024/06 版)
データベース (データストア) 内で AI に関連する機能の利用が様々なデータベース時で実施することができるようになっています。
私が確認した範囲でのデータベース (またデータベースに関連するサービス) になりますが、どのように AI の機能を利用することができるのかをまとめておきたいと思います。
Minisforum MS-01 についてのメモ
最近気になる検証環境で利用したいハードウェアとして Minisforum MS-01 があるのですが、自分の用途で気になった内容をメモとして。
SQL Server on Azure VM の SQL Server 日本語化後の IaaS Agent の導入を Bicep で実施する
Azure では、Marketplace から SQL Server インストール済みの VM イメージが公開されており、Azure VM で SQL Server を使用する場合は、このイメージで展開して PAYG で利用するのが一般的かと思います。
イメージは英語版を使用して構築されているため、日本語化する場合には、当ブログで書いた SQL Server on Azure VM (インストール済みイメージ) の日本語化 (2021/1 版) の方法や、SQL Server Support Blog で公開されている次の記事の対応を行う必要があります。
基本的な作業としては、次の流れとなるのではないでしょうか。
- OS に日本語の言語パックをインストールし、各種言語設定を日本向けに設定
- 導入済みの英語版 SQL Server / SSMS をアンインストール
- SQL Server の日本語版評価版メディアをダウンロードして「C:\SQLServerFull」内のプロダクトキーでインストール
- 日本語版の SSMS をインストール
- SQL Server IaaS Agent 拡張機能を Remove-AzSqlVM 等で登録解除
- New-AzSqlVM で SQL Server IaaS Agent 拡張機能を登録
基本的な作業の流れとしてはこのようになりますが、この手順だけでは、VM の展開時に指定した SQL Server 構成の設定はクリアされた状態となってしまっています。
展開時に指定した内容と同等の設定で IaaS Agent を導入するためには、New-AzSqlVM で様々なオプションを指定して再導入をする必要があるのですが、オプションを一つ一つ設定するのは手間がかかるため、今回はその設定を Bicep で実施してしまおうというのが今回の趣旨となります。
JDBC で HikariCP を使用した SQL Server (SQL Database) への接続について調べてみる
JDBC で接続をする際のコネクションプールで使用するライブラリとして HikariCP があります。
HikariCP を使用して SQL Server に接続をする際の挙動について、いくつか調査する必要があったのでその時に確認した内容を残しておきたいと思います。
Build 2024 のタイミングで発表された SQL Database に関連するアップデート
Build 2024 が開催されています。
キーノートについては次の情報から確認できます。
- Build 2024 Book of News
- Microsoft May 2024 events
- Full Keynote: Satya Nadella at Microsoft Build 2024
SQL Server についてはアップデートはなかったのですが、Azure SQL Database についてはアップデートがアナウンスされていますのでまとめておきたいと思います。