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

大阪#11

SQLTO 小澤真之

AlwaysOn 可用性グループ

構築時のポイント

SQLWorld

自己紹介

2013/01/26SQLWorld★大阪#112

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

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

勉強会：SQLTO

http://sqlto.net

ブログ : SE の雑記

http://engineermemo.wordpress.com

Agenda


AlwaysOn とは

複数拠点を使用した構築

セカンダリレプリカへの接続

フェールオーバー

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


AlwaysOn

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


基本コンセプト


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

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

AlwaysOn とは


2 種類の AlwaysOn

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

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

新機能

フェールオーバークラスターインスタンス


複数拠点でのクラスタリング

マルチサブネットフェールオーバークラスタリング

柔軟なフェールオーバーポリシー (6 種類のレベルで設定可能)

共有フォルダにデータベースを配置

ローカルディスクに tempdb を配置

可用性グループ

2013/01/26SQLWorld★大阪#1110

非同期コミットモード / 非同期コミットモードをサポート自動フェールオーバー最大 5 台で可用性グループを構成可能

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

リスナーを経由して透過的に更新可能サーバーに接続

参照系処理にセカンダリレプリカを利用可能 (アクティブセカンダリ)

セカンダリレプリカを利用したバックアップ

可用性グループ

2013/01/26SQLWorld★大阪#1111


リスナーアプリケーションプライマリ

セカンダリ

更新可能

読取専用

2013/01/26SQLWorld★大阪#1112

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

基本動作 Demo

今回お話しする環境の想定

2013/01/26SQLWorld★大阪#1113

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

拠点 B (DR 拠点)(192.168.110.x/24)

同期コミット非同期コミット


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


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

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

2013/01/26SQLWorld★大阪#1123

拠点 A

拠点 B


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)


プライマリレプリカ

セカンダリレプリカ

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

①

192.168.110.110172.16.100.100どちらかに接続

②③

2 種類の解決方法

2013/01/26SQLWorld★大阪#1127

１

２

高速フェールオーバーを可能にするための接続文字列を使用[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


リスナーの 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)




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

①

②③

RegisterAllProvidersIP

2013/01/26SQLWorld★大阪#1129

DNS


リスナーの IP アドレス172.16.100.100

172.16.100.100 に接続

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

拠点 B(191.168.110.x/24)




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

①

②③

2013/01/26SQLWorld★大阪#1130


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

処理性能への影響

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


セカンダリ

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

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

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


プライマリレプリカセカンダリレプリカ

①

DataSource=<リスナー>ApplicationIntent=ReadOnly;

MultiSubnetFailover=true;Database=<データベース>

②

最初はプライマリレプリカに接続され接続するセカンダリレプリカの情報を取得

(Tabular Data Stream : TDS)

③

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

直接接続

2013/01/26SQLWorld★大阪#1141

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

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

拠点 B


プライマリレプリカセカンダリレプリカ

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

2013/01/26SQLWorld★大阪#1142

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

セカンダリ Demo

アクティブセカンダリの 14 バイト

2013/01/26SQLWorld★大阪#1143

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

アプリケーションプライマリレプリカセカンダリレプリカ

更新

同期

アプリケーション参照

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

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

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

2013/01/26SQLWorld★大阪#1144

セカンダリレプリカプライマリレプリカ

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

2013/01/26SQLWorld★大阪#1145


自動

フェール

オーバー

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

http://msdn.microsoft.com/ja-jp/library/ms189134.aspx

2013/01/26SQLWorld★大阪#1149


セカンダリ

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

セカンダリレプリカを使用したバックアップ

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

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


再構築 (REBUILD) ではなく再構成 (REORGANIZE) による運用を検討- 再構築は一つのトランザクション内で新規ページにインデックスを作成するため、途中で

中断した場合は構築途中の状態も破棄されるが、再構成は既存のページを使用して並び替えを行い、途中で中断した場合でもそれまでの処理状態は保持される

- SQL に関する Q&A: 障害回復とデータベースミラーリングhttp://technet.microsoft.com/ja-jp/magazine/jj259764.aspx


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)

アクティブセカンダリを利用し処理を実行することが可能どの方法を使用してセカンダリレプリカに接続できるか注意

(既存システムへの適用を考えている場合は特に) ジョブにより自動運用する場合はプライマリ/セカンダリのどちらの状態で実行

されるかを意識

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

Documents

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

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

Documents

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

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

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