c34 always on 可用性グループ構築時のポイント by 小澤真之

C34 小澤真之Microsoft MVP for SQL Server

AlwaysOn 可用性グループ

構築時のポイント

db tech showcase

2012

自己紹介

2012/10/19db tech showcase 20122

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

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

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

勉強会：SQLTO

http://sqlto.net

ブログ : SE の雑記

http://engineermemo.wordpress.com

Agenda


AlwaysOn とは

複数拠点を使用した構築

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

フェールオーバー

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

AlwaysOn とは


2 種類の AlwaysOn

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

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

新機能

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


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

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

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

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

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

可用性グループ


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

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

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

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

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

想定環境


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

拠点 B (DR 拠点)(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 のサーバー

クォーラム監視

投票数が不足する例


拠点 A (主拠点) 拠点 B (DR 拠点)

FCI

7 票の投票数のうち 4 票が稼働している必要がある- 3 票しか確保できていない → 必要な投票数が確保できないので WSFC 停止

→ 可用性データベースにアクセスできなくなる

投票数に含めるサーバー

投票数の調整


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

投票の対象から除外

調整後


拠点 A (主拠点) 拠点 B (DR 拠点)

FCI

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

投票数に含めるサーバー



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

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


拠点 A

拠点 B


FCI

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

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

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

ApplicationIntent=ReadWrite

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


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

SQL Server Availability Groupのクラスターリソース

(このリソースが可用性 DB をオンラインにする)

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

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


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

(拠点 A 用 / 拠点 B 用)

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


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 種類の解決方法


１

２

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

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

MultiSubnetFailover


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


DNS


リスナーの IP アドレス172.16.100.100

172.16.100.100 に接続

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

拠点 B(191.168.110.x/24)




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

①

②③



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

処理性能への影響


同期コミット

非同期コミット

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

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

非同期コミット



ログキャッシュ

ログファイル

コミット

ログフラッシュ

ログキャプチャ

データファイル

バッファキャッシュ

チェックポイント

ログ適用


ログファイル

ログ再実行



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 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) ))

透過的な接続


ApplicationIntent=ReadOnly を使用した場合の接続方法(可用性データベース名も明示的に指定する必要がある)

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

拠点 B


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

①

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

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

②

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

(Tabular Data Stream : TDS)

③

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

直接接続


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

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

拠点 B


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

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

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


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

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

更新

同期

アプリケーション参照

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

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

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


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

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



自動

フェール

オーバー

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

フェールオーバーの種類


自動

手動

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

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

フェールオーバーの違い


同期コミット

非同期コミットFCI

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

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

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

FCI の保護単位

インスタンス

可用性グループの保護単位

データベース

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

同期コミットから非同期コミットは

手動フェーオーバー切替

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

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

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

切り替え

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


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

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 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

インデックス再構築時の注意


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


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

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

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


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 小澤真之

Technology

c34 always on 可用性グループ構築時のポイント by 小澤真之