SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

AlwaysOn 可用性グループをテンプレート展開した場合とチュートリアルを参考に構築した場合の相違点

one comment

AlwaysOn 可用性グループを構築する場合、

  • Preview ポータルからテンプレートで展開
  • チュートリアルを参考に手動で展開

の 2 種類の構築方法が考えられます。

チュートリアルについては Azure の仮想マシン内の SQL Server の高可用性と災害復旧 の一連のドキュメントから確認することができ、初めて構築する場合には以下の GUI ベースのチュートリアルを確認するとよいかと思います。

  1. チュートリアル:Azure AlwaysOn 可用性グループ (GUI)
    # 可用性グループのリスナーを除いた環境を構築することができます。
  2. チュートリアル:AlwaysOn 可用性グループのリスナー構成
    # 可用性グループのリスナー並びに、Azure の負荷分散エンドポイント (Azure (Public) Load Balancer / Internal Load Balanser) を作成することができます。

テンプレート展開された環境とチュートリアルを参考にした環境ではいくつか相違点があるので少しまとめてみたいと思います。


■仮想ネットワークのサブネット


テンプレート展開された環境の Azure の仮想ネットワークのサブネットは、

  • SQL Server 用サブネット
  • ドメインコントローラー用サブネット

の 2 つで構成が行われています。

チュートリアルの情報では、

  • フロント
  • バック
    # チュートリアルでは「戻る」って訳されてしまっていますが…。

の 2 つで構成されており、ドメインコントローラーは「バック」 (SQL Server と同一のサブネット) で構築されています。

  • SQL Server 用サブネット
  • ドメインコントローラー用サブネット
  • フロントサーバー (AP サーバー) 用サブネット

の 3 種類で構成すると用途ごとにサブネットが分かれてよいかもしれないですね。

 

■ドメインコントローラー


■ドメインコントローラーの台数

テンプレート展開された環境は SPOF をなくすため、基本的に冗長化が行われています。
そのため、ドメインコントローラーは 2 台で構築されています。
チュートリアルの情報ではドメインコントローラーが 1 台で構成されていますので、台数の違いを意識しておく必要があります。

冗長構成された環境を作成する場合には、

  • 最低でも 2 台のドメインコントローラー

が必要になりますので。

 

■ディスク構成

NTDS / SYSVOL の配置先についてもテンプレート展開とチュートリアルでは異なっています。

テンプレート展開された環境では、

  • F ドライブに NTDS / SYSVOL が格納される
  • F ドライブで使用している仮想ディスクのホストキャッシュは「なし」になっている

チュートリアルを参考にした環境では、

  • C ドライブに NTDS / SYSVOL が格納される
  • C ドライブで使用している仮想ディスクのホストキャッシュは「読み取り/書き込み」になっている

となっています。

ドメインコントローラーのユーザー管理やグループポリシー管理で NTDS / SYSVOL を使用しますが、これらのフォルダが格納されているディスクについてはディスク書き込み時のデータ整合性を担保するため、ホストキャッシュは「なし」にすることが推奨されています。
Azure の仮想マシンでの Windows Server Active Directory のデプロイ ガイドライン

Windows Server AD DS データベースと SYSVOL の配置

データ ディスク ドライブは既定で書き込みデータをキャッシュしません。VM に接続されたデータ ディスク ドライブはライト スルー キャッシュを使用します。ライト スルー キャッシュでは、VM のオペレーティング システムの観点からトランザクションが完了するに、持続的な Azure Storage に書き込みデータがコミットされます。これにより、書き込みが若干遅くなるものの、持続性が得られます。

この動作は Windows Server AD DS に重要です。後書きディスク キャッシュでは DC による推測データが無効になるためです。Windows Server AD DS は書き込みキャッシュを無効にしようとしますが、その無効化を許可するかどうかはディスク IO システムによります。書き込みキャッシュを無効にできない場合は、特定の状況下で USN ロールバックが行われて、結果的に残留オブジェクトやその他の問題につながります。

仮想 DC に関するベスト プラクティスとして、以下を行ってください。

  • Azure データ ディスクの [ホスト キャッシュ設定] を [なし] に設定します。そうすれば、AD DS 操作の際に書き込みキャッシュに関する問題が発生しません。
  • データベース、ログ、SYSVOL をすべて同じデータ ディスクに保存するか、別々のデータ ディスクに保存します。これは通常、オペレーティング システム自体に使用されるディスクとは別のディスクです。重要なのは、Windows Server AD DS のデータベースと SYSVOL を Azure オペレーティング システム ディスクに保存しないということです。既定では、AD DS のインストール プロセスによりこれらのコンポーネントは %systemroot% フォルダーにインストールされますが、Azure にはお勧めしません。

インストール後に SYSVOL の場所を変更しようとするのは面倒なので再構築したほうがいいかと。
SYSVOL の手動での移動
SYSVOL パス情報の収集
ドメイン内の SYSVOL ツリーとその内容を再構築する方法

■静的 IP アドレス

テンプレート展開された環境では、IP アドレスを静的 IP アドレスとして設定しています。
実際には IP アドレスの設定は以下のようになり、ドメインコントローラーの IP のみが静的 IP アドレスとして設定されています。
image

チュートリアルでは静的 IP アドレスにしていないようでした。

  • ドメインコントローラーの IP アドレスは静的 IP アドレスを指定する
  • 指定した静的 IP アドレスを仮想ネットワークの DNS に設定する

が基本となりますので、これも抑えておく必要があるかと。

 

■SQL Server


今回、テンプレート展開したのは SQL Server の構成をきちんと確認したかったからというのが大きいです。

■WSFC (Windows Server Failover Clustering)

テンプレート / チュートリアルともにファイル共有監視を使用したクラスターが構築されていますが、

  • クラスターコアリソースに割り当てる IP アドレス

の設定が異なっています。

まずは、チュートリアル:Azure AlwaysOn 可用性グループ (GUI) の内容を確認してみたいと思います。

クラスターの IP アドレスを、未使用の IP アドレス (10.10.2.101) に変更

[サーバー マネージャー] で、[フェールオーバー クラスター マネージャー] を展開し、[Cluster1.corp.contoso.com] をクリックし、中央のペインで下へスクロールし、[クラスター コア リソース] を展開します。[名前][IP アドレス] 両方のリソースが [失敗] 状態にあることが表示されます。クラスターに対してコンピューター自体と同じ IP アドレスが割り当てられ、重複アドレスになっているため、IP アドレス リソースをオンラインにすることはできません。次のように、失敗の状態にある [IP アドレス] リソースを右クリックし、[プロパティ] をクリックします。

次のように、[静的 IP アドレス] を選択し、[アドレス] ボックスで「10.10.2.101」を指定します。[OK] をクリックします。

チュートリアルでは自分のサブネット内の未使用の IP アドレスを使用するように記載されています。

それでは、テンプレート展開された環境を見てみたいと思います。

image
image

テンプレート展開された環境では、自分のサブネット内の IP ではなく「169.254.1.1」という APIPA のアドレスが割り当てられています。

サブネット内の IP から適当なものを割り当てた場合、「その IP は DHCP からのリース対象となっている」というところを気を付けておく必要があります。
クラスター名オブジェクト (CNO) に手動で割り当てた IP と仮想マシンに DHCP により割り当てられた IP が重複した場合、IP 重複のエラーは発生しませんでしたが、あまり気持ちのいいものではないかと思います。
DNS のレコード不整合については発生するかと思いますし。
# ネットワークのプロパティで固定 IP にした場合、通信がうまくできないケースがあったはずですので、それと似たような感じで CNO の IP が外部通信ができないため、重複が検知されないのかなとは思うのですが。

CNO に割り当てる IP アドレスとしては、

  • サブネットの IP を割り当てる場合は、DHCP により割り当てられる IP の末尾に近いものを設定する
    # 基本は若い者から順番にリースされていくため、末尾に近いものであれば利用される可能性が低い
  • CNO にアクセスするケースはほとんどないため APIPA の IP アドレスを設定する

が考えられるかと。

初期に公開されていた AlwaysOn の構築手順だと、CNO の IP 削除するような手順になっていたはずなのですが、この辺の手順変わったみたいですね。

 

■SQL Server

チュートリアルで作成している環境はシンプルなものなので、

  • 仮想ディスクは OS 用のみ (ホストキャッシュは「読み取り/書き込み」)

となっています。

テンプレート展開された環境では、

  • OS 用のディスク (ホストキャッシュは「読み取り/書き込み」)
  • データファイル (mdf/ldf) 用のディスク (ホストキャッシュは「なし」)
  • ログファイル (ldf) 用のディスク (ホストキャッシュは「なし」)

で構成されています。

Azure Virtual Machines における SQL Server のパフォーマンスに関するベスト プラクティス の内容ですが、SQL Server のデータベースを配置するディスクについては書き込みの整合性を担保するため、ディスクキャッシュは「なし」が推奨されています。

テンプレート展開された環境ではデフォルトのデータベース配置場所が以下のようになっています。

image

データファイルについてはデータファイル用のディスク、ログファイルについてはログファイル用のディスクに分散して配置する設定となっています。
# tempdb については C ドライブに配置されてしまっているので、これについては移動の考慮が必要ですが。

テンプレート展開された環境のほうが I/O 効率を考慮して設定されていますね。
テンプレート展開された環境の記憶域スペースの情報がうまく取れなかったのですが、F/Gドライブは記憶域スペースではなく、通常のディスクマウントのディスクを使っている可能性もありそうです。
この場合、ディスクを追加したあとのスケールが難しい (データファイルはできるがログファイルはできない) ので、I/O のスケールを考慮すると記憶域スペースで作成したほうがよさそうですね。

 

■可用性グループ

可用性グループのリスナーですがチュートリアルは Azure (Public) Load Balancer / Internal Load Balancer のどちらかを使用する手順となっています。

テンプレートで展開した場合は、Azure Load Balancer を使用する設定となっており、以下の設定が行われています。

  • リスナーの設定
    • Azure Load Balancer を使用するため、リスナーの IP にはパブリック IP を設定
      # ILB の場合はサブネットの内部 IP を静的 IP として設定することになる。
  • リスナー向けの Azure Load Balanser の設定
    • Probe ポートとして 59999 を使用した負荷分散セットを作成
  • 各ノードの F/W 設定
    • Probe ポート用の TCP : 59999 の受信許可 (SQL Server Availability Group Listener (TCP-In))
    • SQL Server 用の  TCP : 1433 の受信許可 (SQL Server Database Engine (TCP-In))
    • AlwaysOn 可用性グループのエンドポイント用の 5022 の受信許可 (SQL Server Database Mirroring (TCP-In))

 

image
image

 

リスナーについては別の機会にきちんとまとめたいと思います。

 

■まとめ



■仮想ネットワーク

  • サブネットは設計に応じて決定すればよいが、以下のようなパターンが考えられる
    • パターン 1
      • フロント
        • AP / Web サーバー
      • バック
        • ドメインコントローラー × 2 台
        • SQL Server × 2 台
        • ファイル共有監視用サーバー
    • パターン 2
      • フロント
        • AP / Web サーバー
      • ドメインコントローラー
        • ドメインコントローラー × 2 台
      • SQL
        • SQL Server × 2 台
        • ファイル共有監視用サーバー

■ドメインコントローラー

  • 仮想ディスクは OS 用 / データ用 (NTDS/SYSVOL を配置) の 2 ディスクの構成とする
  • OS 用の仮想ディスクのホストキャッシュの設定は「読み取り / 書き込み」 (デフォルト) にする
  • データ用の仮想ディスクのホストキャッシュの設定は「なし」にする
  • AD DS インストール時に NTDS  / SYSVOL はデータ用のディスクのドライブを選択する
  • ドメインコントローラーの IP アドレスは静的 IP アドレスにする
  • 仮想ネットワークの DNS は静的に設定したドメインコントローラーの IP アドレスを指定する

 

■SQL Server

  • WSFC
    • サブネットの IP を割り当てる場合は、DHCP により割り当てられる IP の末尾に近いものを設定する
    • CNO にアクセスするケースはほとんどないため APIPA の IP アドレスを設定する
  • SQL Server
    • データファイル用 / ログファイル用のディスクの検討
    • I/O をスケールできるようにするため、記憶域スペースの利用検討
  • 可用性グループ
    • リスナーの IP
      • Azure Load Balancer を使用する場合 : パブリック IP
      • Internal Load Balancer を使用する場合 : 内部 IP  (静的 IP)
    • リスナー向けの Azure (Internal) Load Balanser の設定
    • ノードの F/W 設定
      • Probe ポート用の TCP : 59999 の受信許可 (SQL Server Availability Group Listener (TCP-In))
      • SQL Server 用の  TCP : 1433 の受信許可 (SQL Server Database Engine (TCP-In))
      • AlwaysOn 可用性グループのエンドポイント用の 5022 の受信許可 (SQL Server Database Mirroring (TCP-In))
    • 読み取り専用ルーティングについては構成されていないため、可用性グループの読み取りアクセスをする場合には明示的に設定を行う
      可用性グループの読み取り専用ルーティングの構成 (SQL Server)

Written by masayuki.ozawa

12月 28th, 2014 at 12:53 pm

One Response to 'AlwaysOn 可用性グループをテンプレート展開した場合とチュートリアルを参考に構築した場合の相違点'

Subscribe to comments with RSS or TrackBack to 'AlwaysOn 可用性グループをテンプレート展開した場合とチュートリアルを参考に構築した場合の相違点'.

  1. […] […]

Leave a Reply

*