C34 Always On 可用性グループ構築時のポイント by 小澤真之

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

C34 小澤真之
Microsoft MVP for SQL Server

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

 2011/7 に Microsoft MVP for SQL Server を受賞

 コミュニティの勉強会やブログで SQL Server の情報を発信
 勉強会：SQLTO
 http://sqlto.net
 ブログ : SE の雑記
 http://engineermemo.wordpress.com

2 db tech showcase 2012 2012/10/19

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


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

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

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

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


可用性グループ

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

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


想定環境
拠点 A (主拠点) 拠点 B (DR 拠点)
(172.16.x.x/16) (192.168.110.x/24)
同期コミット
非同期コミット
FCI


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


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

複数拠点クラスター投票数の調整


拠点間で構成する場合のポイント

AlwaysOn はフェールオーバークラスター (WSFC) 必須
クラスターを維持するためには過半数 + 1 の投票数が必要
どのノードを過半数の中に含めるのかを意識し投票数を調整

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


WSFC のノードの状況

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

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

拠点 A のサーバー

拠点 B のサーバー

クォーラム監視


投票数が不足する例
7 票の投票数のうち 4 票が稼働している必要がある
- 3 票しか確保できていない → 必要な投票数が確保できないので WSFC 停止
→ 可用性データベースにアクセスできなくなる

FCI

投票数に含める
サーバー


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

投票の対象から除外


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

FCI

投票数に含める
サーバー



複数拠点リスナーの DNS レコード


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

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

アプリケーションリスナー

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


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

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

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

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


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

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


そのまま接続しようとすると
リスナー
アプリケーション (172.16.100.100) AlwaysOn 可用性グループ
②
③ 拠点 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 セカンダリレプリカ


2 種類の解決方法
高速フェールオーバーを可能にするための接続文字列を使用

１ [MultiSubnetFailover=true]
- .NET Framework 4.02 以降
- SQL Server Native Client 11.0
- Microsoft SQL Server JDBC Driver 4.0 以降

クラスターリソースの設定を変更しオンラインのアドレスのみを登録

２ [RegisterAllProvidersIP 0]
[HostRecordTTL 60]
- 高速フェールオーバー用の接続文字列を使用できない場合に使用


MultiSubnetFailover
リスナー
②
③ 拠点 A
(172.16.x.x/16)
192.168.110.110
172.16.100.100
両方に接続

① 両方の IP アドレスに接続を
試行し応答があったほうに接続
拠点 B
(191.168.110.x/24)
リスナーの IP アドレス
192.168.110.110 プライマリレプリカ
172.16.100.100



RegisterAllProvidersIP
リスナー
②
③ 拠点 A
(172.16.x.x/16)
172.16.100.100 に接続

① DNS にはオンラインの
IP アドレスのみが登録される
拠点 B
(191.168.110.x/24)

リスナーの IP アドレスプライマリレプリカ
172.16.100.100




複数拠点同期コミット/非同期コミットの特性


処理性能への影響
コミット時にセカンダリレプリカのコミット応答を待ち処理完了
同期コミット応答に恒常的に遅延があると処理性能に影響
コミット - ネットワーク
- ログの書き込み

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


プライマリレプリカセカンダリレプリカ
圧縮圧縮解除

ログキャプチャログ適用

コミット Redo スレッド

ログプール

ログキャッシュログキャッシュバッファキャッシュ
バッファキャッシュ

ログチェックログ
フラッシュポイント再実行

ログファイルデータファイルログファイルデータファイル


同期コミット
圧縮圧縮解除

ログキャプチャログ適用

コミット Redo スレッド

ログプール

ログキャッシュログキャッシュバッファキャッシュ
バッファキャッシュ

ログチェックログ
フラッシュポイント再実行

ログファイルデータファイルコミットログファイルデータファイル
応答


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

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

トランザクションに対してどれくらい設定有無によるバッチ実行数を確認し
遅延が発生しているかを確認設定による影響を確認


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



セカンダリ
リスナーを経由した透過的な接続
レプリカ


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

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


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

読み取り可能なセカンダリ接続方法
いいえ接続不可
読み取り目的のみ ApplicationIntent=ReadOnly
はい ApplicationIntent=ReadOnly
直接接続


読み取り専用ルーティング
リスナーを経由して透過的にセカンダリレプリカに接続するための設定
ルーティングは指定した接続の優先順に基づき実施される
(負荷に応じたロードバランスではない)
[読み取り専用ルーティング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) ))


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

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

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



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

拠点 A
アプリケーションリスナー

①
拠点 B
DataSource=<セカンダリレプリカ>



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

アプリケーションセカンダリレプリカアプリケーション
プライマリレプリカ参照
更新

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

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


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

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



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


フェールオーバーの種類
同期コミットの場合のみ使用可能

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

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


フェールオーバーの違い
FCI の保護単位可用性グループの保護単位
インスタンスデータベース

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

AlwaysOn で可用性データベースを
FCI 内のノード内でインスタンスを自動フェールオーバーで切替可能
自動フェールオーバー
非同期コミットは
スタンドアロンインスタンス手動フェーオーバーでのみ切替可能
フェールオーバークラスタースタンドアロンインスタンス
インスタンス (同期コミット) (非同期コミット)


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

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



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


セカンダリレプリカを使用したバックアップ
セカンダリレプリカを使用してバックアップを取得することができる。
- 完全バックアップ (コピー)
トランザクションログはレプリカ内で一貫性をもって管理されるため、一つのレプリカで
- トランザクションログバックアップトランザクションログのバックアップを取得すると全レプリカで切り捨てられる。

プライマリレプリカ
バックアップ
完全バックアップ (コピー)
セカンダリレプリカ

セカンダリレプリカトランザクションログバックアップ


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


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

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

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


プライマリレプリカの場合処理を実行
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


インデックス再構築時の注意
可用性データベースの復旧モデルは [完全] のみ使用可能
そのため、インデックス再構築時の最小ログ記録を使用することができない
- 最小ログ記録が可能な操作
http://msdn.microsoft.com/ja-jp/library/ms191244.aspx

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


まとめ
 SQL Server 2008 R2 のデータベースミラーリング相当の機能を
WSFC と組み合わせ、柔軟な環境を構築することが可能となった
 運用方法は従来までのミラーリングも参考になる
 WSFC の投票数の考え方を理解する
 Windows Server 2012
 SMB 3.0
 Dynamic Quorum (Dynamic Weight)

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


C34 Always On 可用性グループ構築時のポイント by 小澤真之

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie C34 Always On 可用性グループ構築時のポイント by 小澤真之

Ähnlich wie C34 Always On 可用性グループ構築時のポイント by 小澤真之 (20)

Mehr von Insight Technology, Inc.

Mehr von Insight Technology, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)