別途、投稿は書こうかと思いますが、ひとまず覚書として。
「まいど」から「以上ヾ(‘ω’)ﾉ゛」まで、Azure Stack を見つめる某氏に環境をお借りして、検証した内容をちょっとずつ書いていきたいと思います。
Azure Stack TP3 の時には、SQL Server リソースプロバイダーが AlwaysOn 可用性グループに対応していなかったのですが、今の Azure Stack 向けのリソースプロバイダーでは、AlwaysOn 可用性グループに SQL Server リソースプロバイダーが対応しています。
Azure Stack 上の VM で AlwaysOn 可用性グループを構築して、ここで登録すればよいかと、簡単に考えていたのですが、いくつかポイントとなることがありそうです。
Azure Stack 上の VM で AlwaysOn 可用性グループを組む時の基本的な流れですが、Azure VM での AlwaysOn 可用性グループの手動構成 とほぼ同じです。
Azure Stack も Azure のロードバランサー相当のリソースがありますので、
- AlwaysOn 可用性グループのリスナーは LB の PIP の IP で設定する
- WSFC のコンピューター名のリソースには、Probe ポート (よく使われるのは 59999) を設定
- LB では、 AlwaysOn 可用性グループの VM の可用性セットをバックエンドプールとして指定する
というようなおなじみの構成を設定することで、LB 経由でプライマリに接続することができるようになります。
Azure Stack 特有の考慮点としては、
- LB の PIP の DNS 名には、AlwaysOn 可用性グループのリスナーと同じ名称を設定する
- AlwaysOn 可用性グループを構成するノードについては、包含データベースを有効にする
あたりがありそうでした。
DNS 名については、まだ、ドキュメントには細かくまとまっていないようで、手探りで検証していて、確認した内容とはなるのですが、SQL Always On 可用性グループを使用して高可用性を提供する には、次の記載があります。
SQL Server インスタンスの接続詳細をフォームに入力します。 Always On リスナーの FQDN アドレス (および必要に応じてポート番号) を使用していることを確認します。sysadmin 特権で構成したアカウントの情報を提供します。
AzS – SQL Resource provider – Off Stack host HA SKU – create database error でも記載されているのですが、AlwaysOn 可用性グループの環境を Azure Stack の Hosting Server として追加する場合、IP アドレスでの指定や、リスナー名以外の DNS 名では追加時にエラーとなる事象に遭遇しました。
私が成功した環境では、リスナーについては次のような「AG-LN」という名称で設定しています。
この場合、LB の Public IP のDNS 名については、次のように「ag-ln.local.cloudapp.azurestack.external」となるように設定をしました。
この設定を行った状態で Hosting Server として追加する際に「ag-ln.local.cloudapp.azurestack.external」として、設定を行うことで、可用性グループの環境を追加することができました。
二つ目の考慮点の包含データベースですがこちらについては、英語版のドキュメントの Provide high availability using SQL Always On Availability Groups には記載されています。
(日本語のドキュメントについては、投稿を書いている時点では記載されていません)
AlwaysOn 可用性グループの Hosting Server については、可用性グループを構成する複数のノードで同一のログインを複製させるため、SQL Login については、通常のログインではなく、DB 内で完結される「SQL user with password」のログインとして作成がされます。
そのため、インスタンスレベルで包含データベースが有効化されていないと、DB を作成する際にエラーとなります。
Azure Stack を前回触ったのがちょうど 1 年ぐらい前だったのですが、今の SQL Server リソースプロバイダー、TP3 の時とは別物のレベルで改善が進んでいますね。
SQL IaaS Extension を利用した自動的な運用 / SQL Login のリソースが追加されたことによる、ログインによる利用可能な DB の分離 / AlwaysOn 可用性グループを利用可能にしたことによる DB の冗長構成のサポートというような、SQL DB に近づけるための改善がかなり行われていると感じました。
まだ、基本的な環境の構築までしかできていないのですが、徐々に作成される DB の特徴なども見ていきたいと思います。