Introducing Change Data Capture for Azure SQL Databases (Public Preview) でアナウンスがありましたが、S3 以上の SQL Database ではプレビュー機能として CDC (Change Data Capture : 変更データキャプチャ) が使用できるようになりました。
CDC について結構忘れていたので、この機会にまとめておきたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
Introducing Change Data Capture for Azure SQL Databases (Public Preview) でアナウンスがありましたが、S3 以上の SQL Database ではプレビュー機能として CDC (Change Data Capture : 変更データキャプチャ) が使用できるようになりました。
CDC について結構忘れていたので、この機会にまとめておきたいと思います。
SQL Server 2012 SP1 CU2 から、Backup to URL という機能がサポートされ、SQL Server のバックアップを Azure BLOB ストレージ上に直接取得することができるようになりました。
SQL Server 2012 / 2014 での実装では、ページ BLOB に対しての取得であり、制限事項 に記載されているようにストライピングでの取得ができないため、バックアップファイルの最大サイズは 1TB までとなります。
SQL Server 2012 ではバックアップの取得は次のようなクエリとなります。
CREATE CREDENTIAL azurestorage WITH IDENTITY = '<ストレージアカウント名>' , SECRET = '<アクセスキー>' ; BACKUP DATABASE AdventureWorks2012 TO URL = 'https://xxxxx.blob.core.windows.net/backup/adventureworks2012.bak' WITH CREDENTIAL='azurestorage',STATS=10
今回、Windows Server 2008 + SQL Server 2012 SP4 の環境を使用していたのですが、デフォルトの状態では、次のエラーが発生して、バックアップを取得できませんでした。
メッセージ 3271、レベル 16、状態 1、行 4 A nonrecoverable I/O error occurred on file "https://xxxxxx.blob.core.windows.net/backup/adventureworks2012.bak:" Backup to URL received an exception from the remote endpoint. Exception Message: リモート サーバーがエラーを返しました: (400) 要求が不適切です. メッセージ 3013、レベル 16、状態 1、行 4 BACKUP DATABASE is terminating abnormally.
Synapse Analytics の Dedicated SQL Pool (専用 SQL プール) に対して、データローディングを行う際には、いくつかのポイントがあり、特性を意識したデータローディングを実施しないと、パフォーマンスが大幅に低下する恐れがあります。
本投稿ではどのようなアプローチを行えばよいのかについてまとめておきたいと思います。
Build 2021 後にアップデートの発表が続いているので、Build 前後で発表された内容を後で見るようにメモ。
Windows Admin Center をワークグループ環境で使用する際のメモを。
検証用環境だと、Windows Admin Center をインストールした環境と、管理対象をワークグループにしてしまっていることが多いので…。
接続の対象は Windows Server 2019 を想定したものとなります。
Azure Kubernetes Service (AKS) on Azure Stack HCI の一般提供が開始されたことで、Windows Server 上に Kubernetes (k8s) の環境をサポートを受けられる状態で構築することができました。
AKS on Azure Stack HCI を稼働させるホスト環境の要件については、Azure Kubernetes Service ホストの設定 に、次のように記載されています。
Kubernetes クラスターを作成する前に行う必要がある最後の手順が 1 つあります。 Kubernetes クラスターのデプロイ先となるシステム上に、Azure Kubernetes Service ホストを設定する必要があります。 このシステムには、Windows Server 2019 Datacenter クラスター、単一ノードの Windows Server 2019 Datacenter、または 2-4 ノード Azure Stack HCI クラスターを指定できます。
「単一ノードの Windows Server 2019 Datacenter」が利用可能なホストとして記載されており、Windows Server 2019 の環境が 1 台あれば、AKS on Azure Stack HCI を検証することが可能です。
シングルノードの検証環境については、コンピューティングの要件 にも記載されていますね。
Azure Kubernetes Service は、技術的には単一ノードの Windows Server 2019 Datacenter で実行できますが、そうすることは推奨されません。 ただし、評価目的のために、単一ノードの Windows Server 2019 Datacenter 上で Azure Kubernetes Service を実行できます。
AKS on Azure Stack HCI は 60 日間、無償で試用することができますので、コストを抑えて検証することができます。
また、クイック スタート:Windows Admin Center を使用して、Azure Stack HCI 上に Azure Kubernetes Service を設定する に手順が記載されており、この手順で簡単に AKS on Azure Stack HCI の構築までは完了するので、本手順では、AKS on Azure Stack HCI の構築については省略していますが、Windows Admin Center に登録したサーバーについては、GUI から、AKS on Azure Stack HCI を簡単に構築することができます。
構築された k8s は、VHDX を使用したストレージや、ロードバランサーが組み込まれていますので、k8s の基本的な検証にも活用することができるのではないでしょうか。
本投稿では、1 ノードの Windows Server 2019 上に構築された AKS on Azure Stack HCI を使用して、App Service on Arcを動作させる際に必要な作業を見ていきたいと思います。
今回使用している NUC は NUC5I5MYHE で古めの NUC ですが、これに 32GB のメモリを搭載して検証環境としています。(CPU が 4 コア / メモリが 8 GB 以上無いと Azure Kubernetes サービスが追加できません。コントロールプレーンと Linux ノードを追加することを考えると、CPU 4 コア / メモリ 32GB は最低限必要です)
今回紹介していないドキュメントもいくつかありますが、App Service on Azure Arc (Azure application services on kubernetes) の検証時に確認をしておきたいドキュメント で関連するドキュメントをまとめてみましたので、深掘りしたい箇所はこれらのドキュメントから確認すると良いのではないでしょうか。
現状、Azure については、East US, West Europe でのみサポートされていますので、検証時に使用できるリージョンにも制限があります。(今回は East Us に作成しています)
Build 2021 でアナウンスされた、Build cloud-native applications that run anywhere により、Azure application service を Kubernetes 上で動作させることができるようになりました。
検証をするに際してどのようなドキュメントを確認すればよいのかをまとめておきたいと思います。(備忘録)
Build 2021 の Build consistent hybrid and multicloud applications with Azure Arc も実機でのデモがありますので、どのような機能かについては、こちらの動画も参考になるかと。
最近、Azure CLI の通信内容を Fiddler でキャプチャ (トレース) する機会があったのですが、Fiddler で HTTPS のキャプチャを有効化しても取得でき内容でしたので、対応方法のメモを。
と言っても、キャプチャする際に参考にさせていただいたサイトの紹介ですが…。
基本的な作業としては次のサイトで紹介されている方法で対応できました。
公式のドキュメントとして Work behind a proxy の内容になるのでしょうね。
Fiddler は Proxy として、HTTP の通信をキャプチャしていますので、Fiddler のルート証明書を PEM 形式に変換して、Azure CLI を実行する前に環境変数の「REQUESTS_CA_BUNDLE」に cer を変換した pem ファイルのフルパスを指定しておけば、Azure CLI の通信内容を Fiddler でキャプチャできるようになります。
Build 2021 の SQL Server ベースの環境の発表については、Build 2021 のタイミングで発表された SQL Server / SQL Database のアップデート に Synapse も含めて書いてみましたが、Synapse 単体でもいくつかのドキュメントの更新が行われていますので、Synapse Analytics のみで、一度アップデートの内容を把握しておきたいと思います。
Build 2021 で SQL Database の新機能として Ledger (台帳) がプレビュー機能として発表されました。
Ledger の初出は PASS Summit 2020 の Day2 Keynote になるのではと思いますが、実機でこの機能を検証することができるようになりましたので、試してみたいと思います。
公式ドキュメントは次の内容となるかと。
最終的にはすべての地域でプレビュー機能が利用できるようですが、投稿を書いている時点では「米国中西部」の論理サーバーでのみ利用することが可能です。(SLO は Basic でも使用できたので、従量課金で検証する場合も、基本機能検証であればコストは抑えられると思います)
そのため、Ledger データベース / CREATE TABLE の LEDGER=ON を実行するためには、米国中西部の論理サーバーに作成したデータベースで検証を行う必要があります。
学習の最初のステップとして Azure SQL Database ledger の内容を見ながら、Ledger がどのようなものなのかを学習したいと思います。
Ledger 全体の構成はこのようになります。