Successfully reported this slideshow.
Your SlideShare is downloading. ×

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

More Related Content

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

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

×