Always on 可用性グループ構築時のポイント

SQL
World

AlwaysOn 可用性グループ
構築時のポイント

大阪
#11

SQLTO 小澤真之

自己紹介


フリーランスエンジニアとして SQL Server を中心に案件に従事



コミュニティの勉強会やブログで SQL Server の情報を発信


勉強会：SQLTO




ブログ : SE の雑記


2

http://sqlto.net
http://engineermemo.wordpress.com

SQLWorld★大阪#11

2013/01/26

Agenda







3

AlwaysOn とは
複数拠点を使用した構築
セカンダリレプリカへの接続
フェールオーバー
セカンダリレプリカを意識した運用


2013/01/26

AlwaysOn
4


2013/01/26

5


2013/01/26

bing translator さんに聞いてみました

6


2013/01/26

基本コンセプト

 いつでも


いつでも (常に起動している) 使用することができる

 どこでも


7

場所を選ばない配置 (柔軟な配置) が可能


2013/01/26

AlwaysOn とは
新機能
SQL Server 2012 で追加された柔軟な構成の高可用性環境を
構築するための機能群

2 種類の AlwaysOn
AlwaysOn フェールオーバークラスターインスタンス (FCI)
AlwaysOn 可用性グループ (HADR)
8


2013/01/26

フェールオーバークラスターインスタンス
複数拠点でのクラスタリング
マルチサブネットフェールオーバークラスタリング
柔軟なフェールオーバーポリシー (6 種類のレベルで設定可能)

共有フォルダにデータベースを配置
ローカルディスクに tempdb を配置

9


2013/01/26

可用性グループ
複数のデータベースを同じ可用性グループで保護
非同期コミットモード / 非同期コミットモードをサポート
非同期コミットモード / 同期コミットモードをサポート
自動フェールオーバー
同期コミット間の自動フェールオーバー (5 種類のレベルで設定可能)
最大 5 台で可用性グループを構成可能
最大 5 台で可用性グループを構成可能

リスナーを経由して透過的に更新可能サーバーに接続
参照系処理にセカンダリレプリカを利用可能 (アクティブセカンダリ)
セカンダリレプリカを利用したバックアップ
10


2013/01/26

可用性グループ
セカンダリ
アプリケーション

リスナー

更新可能

プライマリ

読取専用

11


2013/01/26

AlwaysOn 可用性グループの基本動作

基本動作

12

Demo

2013/01/26

今回お話しする環境の想定
拠点 A (主拠点)

拠点 B (DR 拠点)

(172.16.x.x/16)

(192.168.110.x/24)

同期コミット

非同期コミット

FCI

13


2013/01/26

可用性グループの設定
今回の環境は、以下のエディションで構築 (OS は WSFC が使用可能なエディションが必要)
Windows Server 2012 Datacenter Edition
- Windows Server 2012 は Standard Edition でも可
SQL Server 2012 Enterprise Edition

14


2013/01/26

AlwaysOn 可用性グループ構築時のポイント

複数拠点

15

クラスター投票数の調整


2013/01/26

拠点間で構成する場合のポイント
AlwaysOn はフェールオーバークラスター (WSFC) 必須
クラスターを維持するためには過半数 + 1 の投票数が必要 ※1
どのノードを過半数の中に含めるのかを意識し投票数を調整
※1 Windows Server 2012 では Dynamic Quorum により投票数の維持方法が変更されており、動的に設定することが可能

DNS に登録される A レコードと解決方法
同期コミット/非同期コミットの特性を把握する

16


2013/01/26

WSFC のノードの状況

可用性レプリカのすべてサーバーが
WSFC のノードになる
17


2013/01/26

WSFC 構築直後の投票数
7 票のうち、投票をもつリソースの障害を 3 台まで許容することが可能
- WSFC では全投票数の過半数を超える票数を確保する必要がある
- 上記台数だと投票数は 4 票必要となる

拠点 A のサーバー

拠点 B のサーバー
クォーラム監視

18


2013/01/26

投票数が不足する例
7 票の投票数のうち 4 票が稼働している必要がある
-

3 票しか確保できていない → 必要な投票数が確保できないので WSFC 停止
→ 可用性データベースにアクセスできなくなる


FCI

投票数に含める
サーバー

19


2013/01/26

投票数の調整
全票数を 5 票にし、投票をもつリソースの障害を 2 台まで許容できるよう調整
[(Get-ClusterNode –Name <ノード名>).NodeWeight=0]

投票の対象から除外

20


2013/01/26

調整後
5 票の投票数のうち 3 票が稼働している必要がある
- 先ほどと同様の障害が発生しても必要な投票数 (3票) が確保できている


FCI

投票数に含める
サーバー

21


2013/01/26


複数拠点

22

リスナーの DNS レコード


2013/01/26

可用性グループの接続の基本
拠点 A

リスナーに対して通常の方法で接続
または
ApplicationIntent=ReadWrite


FCI

リスナー

可用性グループの
プライマリレプリカに接続

23


拠点 B

2013/01/26

リスナーの設定内容 (WSFC)

WSFC の停止が可用性
グループにも影響を与える

可用性グループリスナーは拠点間ごとの
IP アドレスを持つマルチサブネット環境

SQL Server Availability Group
のクラスターリソース
(このリソースが可用性 DB をオンラインにする)

24


2013/01/26

マルチサブネット環境の DNS のレコード

マルチサブネット環境ではリスナーの A レコードが 2 種類登録されるため
アプリケーションからどちらの IP アドレスにアクセスされるかわからない
(拠点 A 用 / 拠点 B 用)
25


2013/01/26

そのまま接続しようとすると

リスナー

②


(172.16.100.100)

③

拠点 A
(172.16.x.x/16)

192.168.110.110
172.16.100.100
どちらかに接続

①

接続要求の 50% が
タイムアウトする可能性がある

拠点 B
(191.168.110.x/24)

リスナーの IP アドレス
192.168.110.110
172.16.100.100

DNS
26

プライマリレプリカ

セカンダリレプリカ


2013/01/26

2 種類の解決方法

１
２

高速フェールオーバーを可能にするための接続文字列を使用
[MultiSubnetFailover=true]
- .NET Framework 4.02 以降
- SQL Server Native Client 11.0
- Microsoft SQL Server JDBC Driver 4.0 以降

クラスターリソースの設定を変更しオンラインのアドレスのみを登録
[RegisterAllProvidersIP 0]
[HostRecordTTL 60]
- 高速フェールオーバー用の接続文字列を使用できない場合に使用

27


2013/01/26

MultiSubnetFailover

リスナー

②


(172.16.100.100)

③

拠点 A
(172.16.x.x/16)

192.168.110.110
172.16.100.100
両方に接続

①

両方の IP アドレスに接続を
試行し応答があったほうに接続

拠点 B
(191.168.110.x/24)

192.168.110.110
172.16.100.100

DNS
28




2013/01/26

RegisterAllProvidersIP

リスナー

②


(172.16.100.100)

③

拠点 A
(172.16.x.x/16)

172.16.100.100 に接続

①

DNS にはオンラインの
IP アドレスのみが登録される

拠点 B
(191.168.110.x/24)

172.16.100.100

DNS
29




2013/01/26


複数拠点

30

同期コミット/非同期コミットの特性


2013/01/26

処理性能への影響
同期
コミット

コミット時にセカンダリレプリカのコミット応答を待ち処理完了
コミット応答に恒常的に遅延があると処理性能に影響

非同期
コミット

セカンダリレプリカのデータ同期を待たずに処理完了
恒常的に遅延があっても処理性能に影響しない
遅延がある場合、損失するデータ量に影響する

31

- ネットワーク
- ログの書き込み


2013/01/26


圧縮

圧縮解除

ログキャプチャ

ログ適用
Redo スレッド

コミット

ログプール

ログキャッシュ
ログ
フラッシュ

バッファキャッシュ
ログ
再実行

チェック
ポイント

ログファイル

32



データファイル

ログファイル



2013/01/26

同期コミット

圧縮

圧縮解除

ログキャプチャ

ログ適用
Redo スレッド

コミット

ログプール

ログ
フラッシュ


ログ
再実行

チェック
ポイント

ログファイル

33



コミット
応答


ログファイル


2013/01/26

同期コミットによるトランザクションの遅延
応答待ちによるトランザクション遅延状況 (Transaction Delay) を確認
トランザクションの遅延は更新だけでなく参照にも影響する可能性がある
- トランザクションが完了するまでロックが取得されている状態となるため、ブロッキング発生の可能性

トランザクション単位の
遅延状況の取得

トランザクションの遅延により
設定前後のバッチ実行数の差

トランザクションに対してどれくらい
遅延が発生しているかを確認

34


設定有無によるバッチ実行数を確認し
設定による影響を確認

2013/01/26

非同期コミットのデータ損失状況の取得
セカンダリレプリカで送信キューの情報 (Log Send Queue) を取得することで
損失する可能性のあるデータ量を把握
○バッチ実行終了でキューがなくなる

35

×バッチ実行に合わせてキューが増加
バッチ終了後に緩やかに減少


2013/01/26


セカンダリ
レプリカ
36

リスナーを経由した透過的な接続


2013/01/26

セカンダリレプリカへの接続方法
透過的

直接
37

読み取り専用ルーティングを設定
リスナー経由で等価的に接続するための接続文字列を使用
[ApplicationIntent=ReadOnly]
- .NET Framework 4.02 以降
- SQL Server Native Client 11.0
- Microsoft SQL Server JDBC Driver 4.0 以降

セカンダリレプリカを直接指定して接続
上記のバージョン以外を使用している場合の接続方法
- どのサーバーがセカンダリレプリカなのは自分で判断する必要がある


2013/01/26

セカンダリレプリカを使用できる設定

読み取り可能なセカンダリ

いいえ

接続不可

読み取り目的のみ

ApplicationIntent=ReadOnly

はい
38

接続方法

ApplicationIntent=ReadOnly
直接接続

2013/01/26

読み取り専用ルーティング
リスナーを経由して透過的にセカンダリレプリカに接続するための設定
ルーティングは指定した接続の優先順に基づき実施される
(負荷に応じたロードバランスではない)
[読み取り専用ルーティングURL (接続先)]
ALTER AVAILABILITY GROUP HADR
MODIFY REPLICA ON N’CLS-SQL-FCI′
WITH ( SECONDARY_ROLE(READ_ONLY_ROUTING_URL=N’TCP://CLS-SQL-FCI.domain.local:1433′) )

[読み取り専用ルーティングリスト (接続の優先順)]
ALTER AVAILABILITY GROUP [AlwaysOn_Group]
MODIFY REPLICA ON N’CLS-SQL-FCI′
WITH ( PRIMARY_ROLE(READ_ONLY_ROUTING_LIST=(N’CLS-SQL-03′, N’CLS-SQL-04’ N’CLS-SQL-05) ))

39


2013/01/26

透過的な接続
ApplicationIntent=ReadOnly を使用した場合の接続方法
(可用性データベース名も明示的に指定する必要がある)
最初はプライマリレプリカに接続され
接続するセカンダリレプリカの情報を取得
(Tabular Data Stream : TDS)


②

リスナー

①

DataSource=<リスナー>
ApplicationIntent=ReadOnly;
MultiSubnetFailover=true;
Database=<データベース>

③

拠点 A

拠点 B

読み取り専用ルーティングの設定に基づき
セカンダリレプリカに接続をする

40



2013/01/26

直接接続
ApplicationIntent が使用できない場合の接続方法

リスナー

①

拠点 B

DataSource=<セカンダリレプリカ>


41

拠点 A



2013/01/26

透過的なセカンダリレプリカへの接続

セカンダリ

42

Demo

2013/01/26

アクティブセカンダリの 14 バイト
セカンダリレプリカの読み取りはスナップショット分離トランザクションレベルを使用し
ている。

更新



参照


同期
プライマリレプリカでの更新により参照が
ロック待ちにならないようにスナップショット
分離トランザクションレベルが使用される

行バージョニングの 14 バイト
43


2013/01/26

行バージョニングを使用した読み取り一貫性


※スナップショット分離トランザクションレベル/READCOMMITTED スナップショット分離レベルは設定せず、
可用性グループでアクティブセカンダリを設定した状態
44


2013/01/26

自動
フェール
オーバー
45

FCI を含める場合の自動フェールオーバー


2013/01/26

フェールオーバーの種類

自動

同期コミットの場合のみ使用可能
2 台の可用性レプリカ間で障害発生時に自動フェールオーバー
FCI は自動フェールオーバーを設定することができない
- スタンドアロン SQL Server インスタンスのみ使用可能

手動
46

同期コミット/非同期コミットで使用可能
障害発生時のフェールオーバーは手動で実施
FCIは手動フェールオーバーのみ設定可能


2013/01/26

フェールオーバーの違い
FCI の保護単位
インスタンス

可用性グループの保護単位
データベース

同期コミット
FCI

FCI 内のノード内でインスタンスを
自動フェールオーバー
フェールオーバークラスター
インスタンス

47

FCI は同期コミットでも
手動フェールオーバーで
切り替え

同期コミットから
非同期コミットは
手動フェーオーバー切替


AlwaysOn で可用性データベースを
自動フェールオーバーで切替可能

スタンドアロンインスタンス
(同期コミット)

スタンドアロンインスタンス
(非同期コミット)


非同期コミットは
手動フェーオーバーでのみ切替可能

2013/01/26

FCI の同期コミットで自動フェールオーバーを設定

AlwaysOn フェールオーバークラスターインスタンス (SQL Server)
http://msdn.microsoft.com/ja-jp/library/ms189134.aspx
48


2013/01/26


セカンダリ
レプリカ
49

セカンダリを意識した運用


2013/01/26

セカンダリレプリカを使用したバックアップ
セカンダリレプリカを使用してバックアップを取得することができる。
-

完全バックアップ (コピー)
トランザクションログバックアップ

トランザクションログはレプリカ内で一貫性をもって管理されるため、一つのレプリカで
トランザクションログのバックアップを取得すると全レプリカで切り捨てられる。


バックアップ
完全バックアップ (コピー)



50


トランザクションログバックアップ

2013/01/26

バックアップのリストア
可用性データベースは設定を解除しないとリストアできないので注意が必要
遠隔地に可用性レプリカを配置している場合は、バックアップファイルのコピーに時
間がかかる可能性もある。
- 遠隔拠点のリストアは後回しにする等を検討

51


2013/01/26

セカンダリレプリカの判断
バックアップはセカンダリレプリカで実行できるが、インデックスの再構築や再構成は
プライマリでしか実行することができない
- プライマリを意識しない運用ではSQL Server Agent のジョブではセカンダリを判断

メンテナンスプランでは以下の関数が使用されている
- sys.fn_hadr_backup_is_preferred_replica

以下の動的管理ビューとシステムテーブルを使用してプライマリかの判断が可能
- sys.fn_hadr_backup_is_preferred_replica
- sys.availability_groups

52


2013/01/26

プライマリレプリカの場合処理を実行
USE <データベース名>
SET NOCOUNT ON
GO
DECLARE @primary_server_name sysname
SET @primary_server_name = (
SELECT
primary_replica
FROM
sys.dm_hadr_availability_group_states
LEFT JOIN
sys.availability_groups
ON
sys.availability_groups.group_id = sys.dm_hadr_availability_group_states.group_id
WHERE
sys.availability_groups.name = ‘<可用性グループ名>')
IF (@primary_server_name = @@SERVERNAME)
BEGIN
PRINT 'Index Maintenance Start'
ALTER INDEX <インデックス名> ON <テーブル名> REBUILD
PRINT 'Index Maintenance End'
END

53


2013/01/26

インデックス再構築時の注意
可用性データベースの復旧モデルは [完全] のみ使用可能
そのため、インデックス再構築時の最小ログ記録を使用することができない
-

最小ログ記録が可能な操作
http://msdn.microsoft.com/ja-jp/library/ms191244.aspx

再構築 (REBUILD) ではなく再構成 (REORGANIZE) による運用を検討
-

-

再構築は一つのトランザクション内で新規ページにインデックスを作成するため、途中で
中断した場合は構築途中の状態も破棄されるが、再構成は既存のページを使用し
て並び替えを行い、途中で中断した場合でもそれまでの処理状態は保持される
SQL に関する Q&A: 障害回復とデータベースミラーリング
http://technet.microsoft.com/ja-jp/magazine/jj259764.aspx

54


2013/01/26

まとめ


SQL Server 2008 R2 のデータベースミラーリング相当の機能を
WSFC と組み合わせ、柔軟な環境を構築することが可能となった


運用方法は従来までのミラーリングも参考になる
WSFC の投票数の考え方を理解する



Windows Server 2012








SMB 3.0
Dynamic Quorum (Dynamic Weight)

アクティブセカンダリを利用し処理を実行することが可能



55

どの方法を使用してセカンダリレプリカに接続できるか注意
(既存システムへの適用を考えている場合は特に)
ジョブにより自動運用する場合はプライマリ/セカンダリのどちらの状態で実行
されるかを意識

2013/01/26

Always on 可用性グループ 構築時のポイント

More Related Content

What's hot

Viewers also liked

Similar to Always on 可用性グループ 構築時のポイント

More from Masayuki Ozawa