先月の Azure のアップデートで SQL Server 2014 の AlwaysOn 可用性グループの環境がポータルからテンプレート展開できるようになりました。
Microsoft Azure ポータルのギャラリーで SQL Server AlwaysOn テンプレートを提供開始
SQL Server AlwaysOn Offering in Microsoft Azure Portal Gallery
テンプレート展開の流れを軽く見てみたいと思います。
SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿
先月の Azure のアップデートで SQL Server 2014 の AlwaysOn 可用性グループの環境がポータルからテンプレート展開できるようになりました。
Microsoft Azure ポータルのギャラリーで SQL Server AlwaysOn テンプレートを提供開始
SQL Server AlwaysOn Offering in Microsoft Azure Portal Gallery
テンプレート展開の流れを軽く見てみたいと思います。
データベースの I/O 性能の検証をする際には、検証前に一度データのキャッシュをクリアして、初期のデータ読み込みからディスク I/O を発生させるというケースがあるかと思います。
通常の SQL Server の場合は、DBCC DROPCLEANBUFFERS を実行してキャッシュをクリアすることができます。
しかし、SQL Database の場合はこの DBCC コマンドを利用することができません。
しかし、工夫すると SQL Database でもキャッシュをクリアする方法があったので少しまとめてみたいと思います。
Azure の仮想マシンの非永続化領域 (D ドライブ) にSSD が接続されたインスタンスである、D シリーズが追加されたようです。
New D-Series of Azure VMs with 60% Faster CPUs, More Memory and Local SSD Disks
New D-Series Virtual Machine Sizes
Virtual Machine Pricing
ということで、軽くディスク性能を試してみました。
SQL Database の プレミアムではアクティブジオレプリケーションを利用することが可能です。
Azure SQL データベースの継続性
今まで設定したことがなかったので少し情報をまとめておきたいと思います。
アクティブジオレプリケーションについての情報は以下のドキュメントから追えるかと。
Geo-Replicaton in Azure SQL Database
Azure SQL データベースのアクティブ ジオレプリケーション
SSMS でデータコレクションの管理データウェアハウスを右クリックすると [レポート] に管理データウェアハウス用のレポートが表示されます。
SSMS が管理データウェアハウスかどうかをどのように判断しているかを小ネタとして。
SQL Server 2008 以降はデータコレクションの機能が追加され、サーバーの各種情報をレポートとして表示することができます。
データコレクション用データベースサイズやキャッシュされるデータ分のメモリが意外と無視できないので、運用環境に設定する場合には、データコレクション用のインスタンスを用意して使用した方がよかったりします。
データコレクションを他のインスタンスで一元管理するときに接続のユーザーで少し考慮点がありますのでメモとして。
詳細については、以下の技術文書が参考になります。
データ コレクタのアーキテクチャと処理
データ コレクタの使用
Azure界の抱かれたい男No.1 から、Azure SQL Database introduces new near real-time performance metrics の情報を教えてもらいましたので、ちょっと見てみたいと思います。
Azure SQL Database introduces new near real-time performance metrics http://t.co/lAvN6vCAYf @Masayuki_Ozawa ムッシュ先生、出番です!
— こすもす.えび (@kamebuchi) 2014, 9月 11
先日、AlwaysOn 可用性グループを Azure の仮想マシンとしてテンプレート展開ができるようになりました。
Microsoft Azure ポータルのギャラリーで SQL Server AlwaysOn テンプレートを提供開始
このテンプレートを展開することで、
の 5 台の仮想マシンが構築され、可用性グループが設定された状態となります。
この展開ですが、カスタムスクリプト + DSC が使用されて実施されているようです。
今回の投稿では 1 台目のドメインコントローラーを例にして、展開方法を確認してみたいと思います。
カスタムスクリプトについては、
が参考になります。
さすが世界を散歩する、僕らの TaaS です。既にいろいろと検証をされていたようです。
英語はしゃべれないですが、今度、かばん持ちとして雇ってもらいたいと思います。
AlwaysOn 可用性グループのダッシュボードでは、列を追加することで、プライマリレプリカとセカンダリレプリカ間のデータ損失の推定時間を取得することができます。
同期モードでプライマリ/セカンダリが起動している場合には、データ損失時間は原則として発生しませんが、非同期コミットモードを使用している / メンテナンスのためセカンダリレプリカが停止している場合などは、サーバー間でデータの更新状況に差が発生し、データ損失の可能性が出てきます。
この情報をクエリで取得するための方法をメモとして。