Upload
masayuki-ozawa
View
2.406
Download
1
Embed Size (px)
Citation preview
大阪#11
SQLTO 小澤 真之
AlwaysOn 可用性グループ
構築時のポイント
SQLWorld
自己紹介
2013/01/26SQLWorld★大阪#112
フリーランスエンジニアとして SQL Server を中心に案件に従事
コミュニティの勉強会やブログで SQL Server の情報を発信
勉強会:SQLTO
http://sqlto.net
ブログ : SE の雑記
http://engineermemo.wordpress.com
Agenda
2013/01/26SQLWorld★大阪#113
AlwaysOn とは
複数拠点を使用した構築
セカンダリレプリカへの接続
フェールオーバー
セカンダリレプリカを意識した運用
2013/01/26SQLWorld★大阪#114
AlwaysOn
2013/01/26SQLWorld★大阪#115
bing translator さんに聞いてみました
2013/01/26SQLWorld★大阪#116
基本コンセプト
2013/01/26SQLWorld★大阪#117
いつでも いつでも (常に起動している) 使用することができる
どこでも 場所を選ばない配置 (柔軟な配置) が可能
AlwaysOn とは
2013/01/26SQLWorld★大阪#118
2 種類の AlwaysOn
AlwaysOn フェールオーバークラスターインスタンス (FCI)AlwaysOn 可用性グループ (HADR)
SQL Server 2012 で追加された柔軟な構成の高可用性環境を構築するための機能群
新機能
フェールオーバークラスター インスタンス
2013/01/26SQLWorld★大阪#119
複数拠点でのクラスタリング
マルチサブネットフェールオーバークラスタリング
柔軟なフェールオーバーポリシー (6 種類のレベルで設定可能)
共有フォルダにデータベースを配置
ローカルディスクに tempdb を配置
可用性グループ
2013/01/26SQLWorld★大阪#1110
非同期コミットモード / 非同期コミットモードをサポート自動フェールオーバー最大 5 台で可用性グループを構成可能
複数のデータベースを同じ可用性グループで保護非同期コミットモード / 同期コミットモードをサポート同期コミット間の自動フェールオーバー (5 種類のレベルで設定可能)最大 5 台で可用性グループを構成可能
リスナーを経由して透過的に更新可能サーバーに接続
参照系処理にセカンダリレプリカを利用可能 (アクティブセカンダリ)
セカンダリレプリカを利用したバックアップ
可用性グループ
2013/01/26SQLWorld★大阪#1111
AlwaysOn 可用性グループ
リスナーアプリケーション プライマリ
セカンダリ
更新可能
読取専用
2013/01/26SQLWorld★大阪#1112
AlwaysOn 可用性グループの基本動作
基本動作 Demo
今回お話しする環境の想定
2013/01/26SQLWorld★大阪#1113
拠点 A (主拠点)(172.16.x.x/16)
拠点 B (DR 拠点)(192.168.110.x/24)
同期コミット非同期コミット
AlwaysOn 可用性グループ
FCI
可用性グループの設定
2013/01/26SQLWorld★大阪#1114
今回の環境は、以下のエディションで構築 (OS は WSFC が使用可能なエディションが必要)Windows Server 2012 Datacenter Edition- Windows Server 2012 は Standard Edition でも可SQL Server 2012 Enterprise Edition
2013/01/26SQLWorld★大阪#1115
AlwaysOn 可用性グループ 構築時のポイント
複数拠点 クラスター投票数の調整
拠点間で構成する場合のポイント
2013/01/26SQLWorld★大阪#1116
AlwaysOn はフェールオーバークラスター (WSFC) 必須クラスターを維持するためには過半数 + 1 の投票数が必要 ※1
どのノードを過半数の中に含めるのかを意識し投票数を調整
DNS に登録される A レコードと解決方法同期コミット/非同期コミットの特性を把握する
※1 Windows Server 2012 では Dynamic Quorum により投票数の維持方法が変更されており、動的に設定することが可能
WSFC のノードの状況
2013/01/26SQLWorld★大阪#1117
可用性レプリカのすべてサーバーがWSFC のノードになる
WSFC 構築直後の投票数
2013/01/26SQLWorld★大阪#1118
7 票のうち、投票をもつリソースの障害を 3 台まで許容することが可能- WSFC では全投票数の過半数を超える票数を確保する必要がある- 上記台数だと投票数は 4 票必要となる
拠点 A のサーバー
拠点 B のサーバー
クォーラム監視
投票数が不足する例
2013/01/26SQLWorld★大阪#1119
拠点 A (主拠点) 拠点 B (DR 拠点)
FCI
7 票の投票数のうち 4 票が稼働している必要がある- 3 票しか確保できていない → 必要な投票数が確保できないので WSFC 停止
→ 可用性データベースにアクセスできなくなる
投票数に含めるサーバー
投票数の調整
2013/01/26SQLWorld★大阪#1120
全票数を 5 票にし、投票をもつリソースの障害を 2 台まで許容できるよう調整[(Get-ClusterNode –Name <ノード名>).NodeWeight=0]
投票の対象から除外
調整後
2013/01/26SQLWorld★大阪#1121
拠点 A (主拠点) 拠点 B (DR 拠点)
FCI
5 票の投票数のうち 3 票が稼働している必要がある- 先ほどと同様の障害が発生しても必要な投票数 (3票) が確保できている
投票数に含めるサーバー
2013/01/26SQLWorld★大阪#1122
AlwaysOn 可用性グループ 構築時のポイント
複数拠点 リスナーの DNS レコード
可用性グループの接続の基本
2013/01/26SQLWorld★大阪#1123
拠点 A
拠点 B
AlwaysOn 可用性グループ
FCI
リスナーアプリケーション
可用性グループのプライマリ レプリカに接続
リスナーに対して通常の方法で接続または
ApplicationIntent=ReadWrite
リスナーの設定内容 (WSFC)
2013/01/26SQLWorld★大阪#1124
可用性グループリスナーは拠点間ごとのIP アドレスを持つマルチサブネット環境
SQL Server Availability Groupのクラスターリソース
(このリソースが可用性 DB をオンラインにする)
WSFC の停止が可用性グループにも影響を与える
マルチサブネット環境の DNS のレコード
2013/01/26SQLWorld★大阪#1125
マルチサブネット環境ではリスナーの A レコードが 2 種類登録されるためアプリケーションからどちらの IP アドレスにアクセスされるかわからない
(拠点 A 用 / 拠点 B 用)
そのまま接続しようとすると
2013/01/26SQLWorld★大阪#1126
DNS
リスナー(172.16.100.100)アプリケーション
リスナーの IP アドレス192.168.110.110172.16.100.100
拠点 A(172.16.x.x/16)
拠点 B(191.168.110.x/24)
AlwaysOn 可用性グループ
プライマリレプリカ
セカンダリレプリカ
接続要求の 50% がタイムアウトする可能性がある
①
192.168.110.110172.16.100.100どちらか に接続
②③
2 種類の解決方法
2013/01/26SQLWorld★大阪#1127
1
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
2013/01/26SQLWorld★大阪#1128
DNS
リスナー(172.16.100.100)アプリケーション
リスナーの IP アドレス192.168.110.110172.16.100.100
192.168.110.110172.16.100.100両方 に接続
拠点 A(172.16.x.x/16)
拠点 B(191.168.110.x/24)
AlwaysOn 可用性グループ
プライマリレプリカ
セカンダリレプリカ
両方の IP アドレスに接続を試行し応答があったほうに接続
①
②③
RegisterAllProvidersIP
2013/01/26SQLWorld★大阪#1129
DNS
リスナー(172.16.100.100)アプリケーション
リスナーの IP アドレス172.16.100.100
172.16.100.100 に接続
拠点 A(172.16.x.x/16)
拠点 B(191.168.110.x/24)
AlwaysOn 可用性グループ
プライマリレプリカ
セカンダリレプリカ
DNS にはオンラインのIP アドレスのみが登録される
①
②③
2013/01/26SQLWorld★大阪#1130
AlwaysOn 可用性グループ 構築時のポイント
複数拠点 同期コミット/非同期コミットの特性
処理性能への影響
2013/01/26SQLWorld★大阪#1131
同期コミット
非同期コミット
コミット時にセカンダリレプリカのコミット応答を待ち処理完了コミット応答に恒常的に遅延があると処理性能に影響- ネットワーク- ログの書き込み
セカンダリレプリカのデータ同期を待たずに処理完了恒常的に遅延があっても処理性能に影響しない遅延がある場合、損失するデータ量に影響する
非同期コミット
2013/01/26SQLWorld★大阪#1132
プライマリレプリカ
ログキャッシュ
ログファイル
コミット
ログフラッシュ
ログキャプチャ
データファイル
バッファキャッシュ
チェックポイント
ログ適用
ログキャッシュ
ログファイル
ログ再実行
データファイル
バッファキャッシュ
Redo スレッド
セカンダリレプリカ圧縮 圧縮解除
ログプール
同期コミット
2013/01/26SQLWorld★大阪#1133
プライマリレプリカ
ログキャッシュ
ログファイル
コミット
ログフラッシュ
ログキャプチャ
セカンダリレプリカ
データファイル
バッファキャッシュ
チェックポイント
ログ適用
ログキャッシュ
ログファイル
ログ再実行
データファイル
バッファキャッシュ
Redo スレッド
コミット応答
圧縮 圧縮解除
ログプール
同期コミットによるトランザクションの遅延
2013/01/26SQLWorld★大阪#1134
応答待ちによるトランザクション遅延状況 (Transaction Delay) を確認トランザクションの遅延は更新だけでなく参照にも影響する可能性がある- トランザクションが完了するまでロックが取得されている状態となるため、ブロッキング発生の可能性
トランザクション単位の遅延状況の取得
トランザクションに対してどれくらい遅延が発生しているかを確認
トランザクションの遅延により設定前後のバッチ実行数の差
設定有無によるバッチ実行数を確認し設定による影響を確認
非同期コミットのデータ損失状況の取得
2013/01/26SQLWorld★大阪#1135
セカンダリレプリカで送信キューの情報 (Log Send Queue) を取得することで損失する可能性のあるデータ量を把握
○バッチ実行終了でキューがなくなる×バッチ実行に合わせてキューが増加
バッチ終了後に緩やかに減少
2013/01/26SQLWorld★大阪#1136
AlwaysOn 可用性グループ 構築時のポイント
セカンダリ
レプリカリスナーを経由した透過的な接続
セカンダリレプリカへの接続方法
2013/01/26SQLWorld★大阪#1137
透過的
直接
読み取り専用ルーティングを設定リスナー経由で等価的に接続するための接続文字列を使用[ApplicationIntent=ReadOnly]- .NET Framework 4.02 以降- SQL Server Native Client 11.0- Microsoft SQL Server JDBC Driver 4.0 以降
セカンダリレプリカを直接指定して接続上記のバージョン以外を使用している場合の接続方法- どのサーバーがセカンダリレプリカなのは自分で判断する必要がある
セカンダリレプリカを使用できる設定
2013/01/26SQLWorld★大阪#1138
読み取り可能なセカンダリ 接続方法
いいえ 接続不可
読み取り目的のみ ApplicationIntent=ReadOnly
はい ApplicationIntent=ReadOnly直接接続
読み取り専用ルーティング
2013/01/26SQLWorld★大阪#1139
リスナーを経由して透過的にセカンダリレプリカに接続するための設定ルーティングは指定した接続の優先順に基づき実施される(負荷に応じたロードバランスではない)
[読み取り専用ルーティングURL (接続先)]ALTER AVAILABILITY GROUP HADRMODIFY 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) ))
透過的な接続
2013/01/26SQLWorld★大阪#1140
ApplicationIntent=ReadOnly を使用した場合の接続方法(可用性データベース名も明示的に指定する必要がある)
リスナーアプリケーション拠点 A
拠点 B
AlwaysOn 可用性グループ
プライマリレプリカ セカンダリレプリカ
①
DataSource=<リスナー>ApplicationIntent=ReadOnly;
MultiSubnetFailover=true;Database=<データベース>
②
最初はプライマリレプリカに接続され接続するセカンダリレプリカの情報を取得
(Tabular Data Stream : TDS)
③
読み取り専用ルーティングの設定に基づきセカンダリレプリカに接続をする
直接接続
2013/01/26SQLWorld★大阪#1141
ApplicationIntent が使用できない場合の接続方法
リスナーアプリケーション拠点 A
拠点 B
AlwaysOn 可用性グループ
プライマリレプリカ セカンダリレプリカ
①DataSource=<セカンダリレプリカ>
2013/01/26SQLWorld★大阪#1142
透過的なセカンダリレプリカへの接続
セカンダリ Demo
アクティブセカンダリの 14 バイト
2013/01/26SQLWorld★大阪#1143
セカンダリレプリカの読み取りはスナップショット分離トランザクションレベルを使用している。
アプリケーション プライマリレプリカ セカンダリレプリカ
更新
同期
アプリケーション参照
プライマリレプリカでの更新により参照がロック待ちにならないようにスナップショット分離トランザクションレベルが使用される
行バージョニングの 14 バイト
行バージョニングを使用した読み取り一貫性
2013/01/26SQLWorld★大阪#1144
セカンダリレプリカプライマリレプリカ
※スナップショット分離トランザクションレベル/READCOMMITTED スナップショット分離レベルは設定せず、可用性グループでアクティブセカンダリを設定した状態
2013/01/26SQLWorld★大阪#1145
AlwaysOn 可用性グループ 構築時のポイント
自動
フェール
オーバー
FCI を含める場合の自動フェールオーバー
フェールオーバーの種類
2013/01/26SQLWorld★大阪#1146
自動
手動
同期コミットの場合のみ使用可能2 台の可用性レプリカ間で障害発生時に自動フェールオーバーFCI は自動フェールオーバーを設定することができない- スタンドアロン SQL Server インスタンスのみ使用可能
同期コミット/非同期コミットで使用可能障害発生時のフェールオーバーは手動で実施FCIは手動フェールオーバーのみ設定可能
フェールオーバーの違い
2013/01/26SQLWorld★大阪#1147
同期コミット
非同期コミットFCI
スタンドアロンインスタンス(同期コミット)
スタンドアロンインスタンス(非同期コミット)
AlwaysOn で可用性データベースを自動フェールオーバーで切替可能
FCI の保護単位
インスタンス
可用性グループの保護単位
データベース
非同期コミットは手動フェーオーバーでのみ切替可能
同期コミットから非同期コミットは
手動フェーオーバー切替
フェールオーバークラスターインスタンス
FCI 内のノード内でインスタンスを自動フェールオーバー
FCI は同期コミットでも手動フェールオーバーで
切り替え
FCI の同期コミットで自動フェールオーバーを設定
2013/01/26SQLWorld★大阪#1148
AlwaysOn フェールオーバー クラスター インスタンス (SQL Server)http://msdn.microsoft.com/ja-jp/library/ms189134.aspx
2013/01/26SQLWorld★大阪#1149
AlwaysOn 可用性グループ 構築時のポイント
セカンダリ
レプリカセカンダリを意識した運用
セカンダリレプリカを使用したバックアップ
2013/01/26SQLWorld★大阪#1150
セカンダリレプリカを使用してバックアップを取得することができる。- 完全 バックアップ (コピー)- トランザクションログ バックアップ
プライマリレプリカ
セカンダリレプリカ
セカンダリレプリカ
バックアップ
完全バックアップ (コピー)
トランザクションログ バックアップ
トランザクションログはレプリカ内で一貫性をもって管理されるため、一つのレプリカでトランザクションログのバックアップを取得すると全レプリカで切り捨てられる。
バックアップのリストア
2013/01/26SQLWorld★大阪#1151
可用性データベースは設定を解除しないとリストアできないので注意が必要遠隔地に可用性レプリカを配置している場合は、バックアップファイルのコピーに時間がかかる可能性もある。- 遠隔拠点のリストアは後回しにする等を検討
セカンダリレプリカの判断
2013/01/26SQLWorld★大阪#1152
バックアップはセカンダリレプリカで実行できるが、インデックスの再構築や再構成はプライマリでしか実行することができない- プライマリを意識しない運用ではSQL Server Agent のジョブではセカンダリを判断
メンテナンスプランでは以下の関数が使用されている- sys.fn_hadr_backup_is_preferred_replica
以下の動的管理ビューとシステムテーブルを使用してプライマリかの判断が可能- sys.fn_hadr_backup_is_preferred_replica- sys.availability_groups
プライマリレプリカの場合処理を実行
2013/01/26SQLWorld★大阪#1153
USE <データベース名>SET NOCOUNT ONGODECLARE @primary_server_name sysnameSET @primary_server_name = (SELECT
primary_replicaFROM
sys.dm_hadr_availability_group_statesLEFT JOIN
sys.availability_groupsON
sys.availability_groups.group_id = sys.dm_hadr_availability_group_states.group_idWHERE
sys.availability_groups.name = ‘<可用性グループ名>')IF (@primary_server_name = @@SERVERNAME)BEGIN
PRINT 'Index Maintenance Start'ALTER INDEX <インデックス名> ON <テーブル名> REBUILDPRINT 'Index Maintenance End'
END
インデックス再構築時の注意
2013/01/26SQLWorld★大阪#1154
可用性データベースの復旧モデルは [完全] のみ使用可能そのため、インデックス再構築時の最小ログ記録を使用することができない- 最小ログ記録が可能な操作
http://msdn.microsoft.com/ja-jp/library/ms191244.aspx
再構築 (REBUILD) ではなく再構成 (REORGANIZE) による運用を検討- 再構築は一つのトランザクション内で新規ページにインデックスを作成するため、途中で
中断した場合は構築途中の状態も破棄されるが、再構成は既存のページを使用して並び替えを行い、途中で中断した場合でもそれまでの処理状態は保持される
- SQL に関する Q&A: 障害回復とデータベース ミラーリングhttp://technet.microsoft.com/ja-jp/magazine/jj259764.aspx
まとめ
2013/01/26SQLWorld★大阪#1155
SQL Server 2008 R2 のデータベースミラーリング相当の機能をWSFC と組み合わせ、柔軟な環境を構築することが可能となった 運用方法は従来までのミラーリングも参考になる WSFC の投票数の考え方を理解する Windows Server 2012
SMB 3.0
Dynamic Quorum (Dynamic Weight)
アクティブセカンダリを利用し処理を実行することが可能 どの方法を使用してセカンダリレプリカに接続できるか注意
(既存システムへの適用を考えている場合は特に) ジョブにより自動運用する場合はプライマリ/セカンダリのどちらの状態で実行
されるかを意識