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

5,429 views
5,201 views

Published on

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,429
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
90
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

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

  1. 1. db techshowcase AlwaysOn 可用性グループ 2012 構築時のポイントC34 小澤 真之 Microsoft MVP for SQL Server
  2. 2. 自己紹介 フリーランスエンジニアとして SQL Server を中心に案件に従事 2011/7 に Microsoft MVP for SQL Server を受賞 コミュニティの勉強会やブログで SQL Server の情報を発信  勉強会:SQLTO  http://sqlto.net  ブログ : SE の雑記  http://engineermemo.wordpress.com2 db tech showcase 2012 2012/10/19
  3. 3. Agenda AlwaysOn とは 複数拠点を使用した構築 セカンダリレプリカへの接続 フェールオーバー セカンダリレプリカを意識した運用3 db tech showcase 2012 2012/10/19
  4. 4. AlwaysOn とは新機能SQL Server 2012 で追加された柔軟な構成の高可用性環境を構築するための機能群2 種類の AlwaysOnAlwaysOn フェールオーバークラスターインスタンス (FCI)AlwaysOn 可用性グループ (HADR)4 db tech showcase 2012 2012/10/19
  5. 5. フェールオーバークラスター インスタンス 複数拠点でのクラスタリング マルチサブネットフェールオーバークラスタリング 柔軟なフェールオーバーポリシー (6 種類のレベルで設定可能) 共有フォルダにデータベースを配置 ローカルディスクに tempdb を配置5 db tech showcase 2012 2012/10/19
  6. 6. 可用性グループ 複数のデータベースを同じ可用性グループで保護 非同期コミットモード / 非同期コミットモードをサポート 非同期コミットモード / 同期コミットモードをサポート 自動フェールオーバー 同期コミット間の自動フェールオーバー (5 種類のレベルで設定可能) 最大 5 台で可用性グループを構成可能 最大 5 台で可用性グループを構成可能 リスナーを経由して透過的に更新可能サーバーに接続 参照系処理にセカンダリレプリカを利用可能 (アクティブセカンダリ) セカンダリレプリカを利用したバックアップ6 db tech showcase 2012 2012/10/19
  7. 7. 想定環境 AlwaysOn 可用性グループ 拠点 A (主拠点) 拠点 B (DR 拠点) (172.16.x.x/16) (192.168.110.x/24) 同期コミット 非同期コミット FCI7 db tech showcase 2012 2012/10/19
  8. 8. 可用性グループの設定今回の環境は、以下のエディションで構築 (OS は WSFC が使用可能なエディションが必要)Windows Server 2012 Datacenter EditionSQL Server 2012 Enterprise Edition- Windows Server 2012 は Standard Edition でも可8 db tech showcase 2012 2012/10/19
  9. 9. AlwaysOn 可用性グループ 構築時のポイント 複数拠点 クラスター投票数の調整9 db tech showcase 2012 2012/10/19
  10. 10. 拠点間で構成する場合のポイント AlwaysOn はフェールオーバークラスター (WSFC) 必須 クラスターを維持するためには過半数 + 1 の投票数が必要 どのノードを過半数の中に含めるのかを意識し投票数を調整 DNS に登録される A レコードと解決方法 同期コミット/非同期コミットの特性を把握する10 db tech showcase 2012 2012/10/19
  11. 11. WSFC のノードの状況 可用性レプリカのすべてサーバーが WSFC のノードになる11 db tech showcase 2012 2012/10/19
  12. 12. WSFC 構築直後の投票数7 票のうち、投票をもつリソースの障害を 3 台まで許容することが可能- WSFC では全投票数の過半数を超える票数を確保する必要がある- 上記台数だと投票数は 4 票必要となる 拠点 A のサーバー 拠点 B のサーバー クォーラム監視12 db tech showcase 2012 2012/10/19
  13. 13. 投票数が不足する例7 票の投票数のうち 4 票が稼働している必要がある- 3 票しか確保できていない → 必要な投票数が確保できないので WSFC 停止 → 可用性データベースにアクセスできなくなる 拠点 A (主拠点) 拠点 B (DR 拠点) FCI 投票数に含める サーバー13 db tech showcase 2012 2012/10/19
  14. 14. 投票数の調整全票数を 5 票にし、投票をもつリソースの障害を 2 台まで許容できるよう調整[(Get-ClusterNode –Name <ノード名>).NodeWeight=0] 投票の対象から除外14 db tech showcase 2012 2012/10/19
  15. 15. 調整後5 票の投票数のうち 3 票が稼働している必要がある- 先ほどと同様の障害が発生しても必要な投票数 (3票) が確保できている 拠点 A (主拠点) 拠点 B (DR 拠点) FCI 投票数に含める サーバー15 db tech showcase 2012 2012/10/19
  16. 16. AlwaysOn 可用性グループ 構築時のポイント 複数拠点 リスナーの DNS レコード16 db tech showcase 2012 2012/10/19
  17. 17. 可用性グループの接続の基本 AlwaysOn 可用性グループ リスナーに対して通常の方法で接続 拠点 A または ApplicationIntent=ReadWrite FCIアプリケーション リスナー 可用性グループの プライマリ レプリカに接続 拠点 B 17 db tech showcase 2012 2012/10/19
  18. 18. リスナーの設定内容 (WSFC) WSFC の停止が可用性 グループにも影響を与える 可用性グループリスナーは拠点間ごとの IP アドレスを持つマルチサブネット環境 SQL Server Availability Group のクラスターリソース(このリソースが可用性 DB をオンラインにする) 18 db tech showcase 2012 2012/10/19
  19. 19. マルチサブネット環境の DNS のレコード マルチサブネット環境ではリスナーの A レコードが 2 種類登録されるため アプリケーションからどちらの IP アドレスにアクセスされるかわからない (拠点 A 用 / 拠点 B 用)19 db tech showcase 2012 2012/10/19
  20. 20. そのまま接続しようとすると リスナーアプリケーション (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 セカンダリレプリカ20 db tech showcase 2012 2012/10/19
  21. 21. 2 種類の解決方法 高速フェールオーバーを可能にするための接続文字列を使用 1 [MultiSubnetFailover=true] - .NET Framework 4.02 以降 - SQL Server Native Client 11.0 - Microsoft SQL Server JDBC Driver 4.0 以降 クラスターリソースの設定を変更しオンラインのアドレスのみを登録 2 [RegisterAllProvidersIP 0] [HostRecordTTL 60] - 高速フェールオーバー用の接続文字列を使用できない場合に使用21 db tech showcase 2012 2012/10/19
  22. 22. MultiSubnetFailover リスナーアプリケーション (172.16.100.100) AlwaysOn 可用性グループ ② ③ 拠点 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 DNS セカンダリレプリカ22 db tech showcase 2012 2012/10/19
  23. 23. RegisterAllProvidersIP リスナーアプリケーション (172.16.100.100) AlwaysOn 可用性グループ ② ③ 拠点 A (172.16.x.x/16) 172.16.100.100 に接続① DNS にはオンラインの IP アドレスのみが登録される 拠点 B (191.168.110.x/24) リスナーの IP アドレス プライマリレプリカ 172.16.100.100 DNS セカンダリレプリカ23 db tech showcase 2012 2012/10/19
  24. 24. AlwaysOn 可用性グループ 構築時のポイント 複数拠点 同期コミット/非同期コミットの特性24 db tech showcase 2012 2012/10/19
  25. 25. 処理性能への影響 コミット時にセカンダリレプリカのコミット応答を待ち処理完了 同期 コミット応答に恒常的に遅延があると処理性能に影響コミット - ネットワーク - ログの書き込み非同期 セカンダリレプリカのデータ同期を待たずに処理完了 恒常的に遅延があっても処理性能に影響しないコミット 遅延がある場合、損失するデータ量に影響する25 db tech showcase 2012 2012/10/19
  26. 26. 非同期コミット プライマリレプリカ セカンダリレプリカ 圧縮 圧縮解除 ログキャプチャ ログ適用 コミット Redo スレッド ログプール ログキャッシュ ログキャッシュ バッファキャッシュ バッファキャッシュ ログ チェック ログフラッシュ ポイント 再実行 ログファイル データファイル ログファイル データファイル 26 db tech showcase 2012 2012/10/19
  27. 27. 同期コミット プライマリレプリカ セカンダリレプリカ 圧縮 圧縮解除 ログキャプチャ ログ適用 コミット Redo スレッド ログプール ログキャッシュ ログキャッシュ バッファキャッシュ バッファキャッシュ ログ チェック ログフラッシュ ポイント 再実行 ログファイル データファイル コミット ログファイル データファイル 応答 27 db tech showcase 2012 2012/10/19
  28. 28. 同期コミットによるトランザクションの遅延応答待ちによるトランザクション遅延状況 (Transaction Delay) を確認トランザクションの遅延は更新だけでなく参照にも影響する可能性がある- トランザクションが完了するまでロックが取得されている状態となるため、ブロッキング発生の可能性 トランザクション単位の トランザクションの遅延により 遅延状況の取得 設定前後のバッチ実行数の差 トランザクションに対してどれくらい 設定有無によるバッチ実行数を確認し 遅延が発生しているかを確認 設定による影響を確認28 db tech showcase 2012 2012/10/19
  29. 29. 非同期コミットのデータ損失状況の取得セカンダリレプリカで送信キューの情報 (Log Send Queue) を取得することで損失する可能性のあるデータ量を把握 ×バッチ実行に合わせてキューが増加○バッチ実行終了でキューがなくなる バッチ終了後に緩やかに減少 29 db tech showcase 2012 2012/10/19
  30. 30. AlwaysOn 可用性グループ 構築時のポイント セカンダリ リスナーを経由した透過的な接続 レプリカ30 db tech showcase 2012 2012/10/19
  31. 31. セカンダリレプリカへの接続方法 読み取り専用ルーティングを設定 リスナー経由で等価的に接続するための接続文字列を使用透過的 [ApplicationIntent=ReadOnly] - .NET Framework 4.02 以降 - SQL Server Native Client 11.0 - Microsoft SQL Server JDBC Driver 4.0 以降 セカンダリレプリカを直接指定して接続 直接 上記のバージョン以外を使用している場合の接続方法 - どのサーバーがセカンダリレプリカなのは自分で判断する必要がある31 db tech showcase 2012 2012/10/19
  32. 32. セカンダリレプリカを使用できる設定 読み取り可能なセカンダリ 接続方法 いいえ 接続不可 読み取り目的のみ ApplicationIntent=ReadOnly はい ApplicationIntent=ReadOnly 直接接続32 db tech showcase 2012 2012/10/19
  33. 33. 読み取り専用ルーティングリスナーを経由して透過的にセカンダリレプリカに接続するための設定ルーティングは指定した接続の優先順に基づき実施される(負荷に応じたロードバランスではない)[読み取り専用ルーティング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) ))33 db tech showcase 2012 2012/10/19
  34. 34. 透過的な接続ApplicationIntent=ReadOnly を使用した場合の接続方法(可用性データベース名も明示的に指定する必要がある) 最初はプライマリレプリカに接続され 接続するセカンダリレプリカの情報を取得 AlwaysOn 可用性グループ (Tabular Data Stream : TDS) 拠点 Aアプリケーション ① リスナー ② DataSource=<リスナー> ApplicationIntent=ReadOnly; MultiSubnetFailover=true; Database=<データベース> ③ 拠点 B 読み取り専用ルーティングの設定に基づき セカンダリレプリカに接続をする プライマリレプリカ セカンダリレプリカ34 db tech showcase 2012 2012/10/19
  35. 35. 直接接続ApplicationIntent が使用できない場合の接続方法 AlwaysOn 可用性グループ 拠点 Aアプリケーション リスナー ① 拠点 B DataSource=<セカンダリレプリカ> プライマリレプリカ セカンダリレプリカ35 db tech showcase 2012 2012/10/19
  36. 36. アクティブセカンダリの 14 バイト セカンダリレプリカの読み取りはスナップショット分離トランザクションレベルを使用し ている。アプリケーション セカンダリレプリカ アプリケーション プライマリレプリカ 参照 更新 同期 プライマリレプリカでの更新により参照が ロック待ちにならないようにスナップショット 分離トランザクションレベルが使用される 行バージョニングの 14 バイト 36 db tech showcase 2012 2012/10/19
  37. 37. 行バージョニングを使用した読み取り一貫性 プライマリレプリカ セカンダリレプリカ※スナップショット分離トランザクションレベル/READCOMMITTED スナップショット分離レベルは設定せず、 可用性グループでアクティブセカンダリを設定した状態 37 db tech showcase 2012 2012/10/19
  38. 38. AlwaysOn 可用性グループ 構築時のポイント 自動 フェール FCI を含める場合の自動フェールオーバー オーバー38 db tech showcase 2012 2012/10/19
  39. 39. フェールオーバーの種類 同期コミットの場合のみ使用可能自動 2 台の可用性レプリカ間で障害発生時に自動フェールオーバー FCI は自動フェールオーバーを設定することができない - スタンドアロン SQL Server インスタンスのみ使用可能 同期コミット/非同期コミットで使用可能手動 障害発生時のフェールオーバーは手動で実施 FCIは手動フェールオーバーのみ設定可能39 db tech showcase 2012 2012/10/19
  40. 40. フェールオーバーの違い FCI の保護単位 可用性グループの保護単位 インスタンス データベース 同期コミット FCI は同期コミットでも FCI 手動フェールオーバーで 非同期コミット 同期コミットから 切り替え 非同期コミットは 手動フェーオーバー切替 AlwaysOn で可用性データベースをFCI 内のノード内でインスタンスを 自動フェールオーバーで切替可能 自動フェールオーバー 非同期コミットは スタンドアロンインスタンス 手動フェーオーバーでのみ切替可能 フェールオーバークラスター スタンドアロンインスタンス インスタンス (同期コミット) (非同期コミット) 40 db tech showcase 2012 2012/10/19
  41. 41. FCI の同期コミットで自動フェールオーバーを設定AlwaysOn フェールオーバー クラスター インスタンス (SQL Server)http://msdn.microsoft.com/ja-jp/library/ms189134.aspx41 db tech showcase 2012 2012/10/19
  42. 42. AlwaysOn 可用性グループ 構築時のポイント セカンダリ セカンダリを意識した運用 レプリカ42 db tech showcase 2012 2012/10/19
  43. 43. セカンダリレプリカを使用したバックアップセカンダリレプリカを使用してバックアップを取得することができる。- 完全 バックアップ (コピー) トランザクションログはレプリカ内で一貫性をもって管理されるため、一つのレプリカで- トランザクションログ バックアップ トランザクションログのバックアップを取得すると全レプリカで切り捨てられる。プライマリレプリカ バックアップ 完全バックアップ (コピー) セカンダリレプリカ セカンダリレプリカ トランザクションログ バックアップ43 db tech showcase 2012 2012/10/19
  44. 44. バックアップのリストア可用性データベースは設定を解除しないとリストアできないので注意が必要遠隔地に可用性レプリカを配置している場合は、バックアップファイルのコピーに時間がかかる可能性もある。- 遠隔拠点のリストアは後回しにする等を検討44 db tech showcase 2012 2012/10/19
  45. 45. セカンダリレプリカの判断バックアップはセカンダリレプリカで実行できるが、インデックスの再構築や再構成はプライマリでしか実行することができない- プライマリを意識しない運用ではSQL Server Agent のジョブではセカンダリを判断メンテナンスプランでは以下の関数が使用されている- sys.fn_hadr_backup_is_preferred_replica以下の動的管理ビューとシステムテーブルを使用してプライマリかの判断が可能- sys.fn_hadr_backup_is_preferred_replica- sys.availability_groups45 db tech showcase 2012 2012/10/19
  46. 46. プライマリレプリカの場合処理を実行USE <データベース名>SET NOCOUNT ONGODECLARE @primary_server_name sysnameSET @primary_server_name = (SELECT primary_replicaFROM sys.dm_hadr_availability_group_states LEFT JOIN sys.availability_groups ON 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 <テーブル名> REBUILD PRINT Index Maintenance EndEND46 db tech showcase 2012 2012/10/19
  47. 47. インデックス再構築時の注意可用性データベースの復旧モデルは [完全] のみ使用可能そのため、インデックス再構築時の最小ログ記録を使用することができない- 最小ログ記録が可能な操作 http://msdn.microsoft.com/ja-jp/library/ms191244.aspx再構築 (REBUILD) ではなく再構成 (REORGANIZE) による運用を検討- 再構築は一つのトランザクション内で新規ページにインデックスを作成するため、途中で 中断した場合は構築途中の状態も破棄されるが、再構成は既存のページを使用し て並び替えを行い、途中で中断した場合でもそれまでの処理状態は保持される- SQL に関する Q&A: 障害回復とデータベース ミラーリング http://technet.microsoft.com/ja-jp/magazine/jj259764.aspx47 db tech showcase 2012 2012/10/19
  48. 48. まとめ SQL Server 2008 R2 のデータベースミラーリング相当の機能を WSFC と組み合わせ、柔軟な環境を構築することが可能となった  運用方法は従来までのミラーリングも参考になる  WSFC の投票数の考え方を理解する  Windows Server 2012  SMB 3.0  Dynamic Quorum (Dynamic Weight) アクティブセカンダリを利用し処理を実行することが可能  どの方法を使用してセカンダリレプリカに接続できるか注意 (既存システムへの適用を考えている場合は特に)  ジョブにより自動運用する場合はプライマリ/セカンダリのどちらの状態で実行 されるかを意識 48 db tech showcase 2012 2012/10/19

×