_初級_中級者向け__ゾーン冗長を考慮したAzure仮想マシン上にSQL_Server_Always_On可用性グループの構築について.pdf

Transcript

1. 【初級・中級者向け】
   ゾーン冗長を考慮したAzure仮想マシン上にSQL
   Server Always On可用性グループの構築について
   

   View Slide

2. 1. ゾーン冗長を考慮したSQL Server 可用性グループ 構成図 (例)
   2. 考慮ポイント
   3. 最後に
   4. 参考情報
   5. Q/A
   

   View Slide

3. 1. ゾーン冗長を考慮したSQL Server 可用性グループ 構成図 (例)
   ポイント 5
   SQL Server 可用性リスナー用
   ロードバランサーのゾーン冗長
   ポイント 1
   Azure仮想マシンのゾーン冗長
   ポイント 2
   WSFCのクォーラムをクラウド監視で構成
   ポイント 3
   WSFCのハートビート間隔を
   チューニング
   ポイント 4
   SQL Server 可用性グループ リソースの Lease Timeout
   および HealthCheckTimeout をチューニング
   ポイント 6
   リトライロジックの実装
   ポイント 7
   サーキット ブレーカーの実装
   

   View Slide

4. 2. 考慮ポイント
   ポイント１ : ゾーン冗長を考慮したAzure仮想マシンのデプロイ
   SQL Server AlwaysOn 可用性グループを構成する Windows
   Server および Active Directory を冗長化構成する Windows
   Server は、異なる可用性ゾーンにデプロイしたAzure仮想マシン
   上にインストール
   

   View Slide

5. 2. 考慮ポイント
   ポイント２ : WSFC のクォーラムをクラウド監視で構成
   Windows Server 2016/2019 では、Windows Server Failover
   Clustering (WSFC)のクォーラムにOS標準機能として選択可能な
   クラウド監視 を選択
   

   View Slide

6. 2. 考慮ポイント
   ポイント３ : WSFC のハートビート間隔設定を30秒(30000 ミリ秒)以上に設定
   WSFC のハートビート間隔設定で SameSubnetDelay (単位：ミリ秒) *
   SameSubnetThreshold (単位：回数) の値が、30秒 (30000 ミリ秒) 以上に
   なるようにパラメータ値を変更
   

   View Slide

7. 2. 考慮ポイント
   ポイント４ : SQL Server AlwaysOn 可用性グループ リソースの Lease Timeout および
   HealthCheckTimeout の値を30秒(30000 ミリ秒)以上に設定
   1) Lease Timeout 値を 30秒 (30000ミリ秒) 以上に設定する。(既定値:
   20秒 : 20000ミリ秒)
   Lease Timeout * 1/2 の値は、WSFCのハートビート間隔
   (SameSubnetDelay (単位：ミリ秒) * SameSubnetThreshold (単位：回数) )
   の値よりも小さい必要がある
   2) HealthCheckTimeout 値をLease Timeout 値に指定した値よりも長く設
   定する。(既定値: 30秒 : 30000ミリ秒)
   HealthCheckTimeout 値は、Lease Timeout 値よりも長く設定する必要が
   あるため、Lease Timeout 値を変更した場合は、HealthCheckTimeout 値
   も長く設定
   

   View Slide

8. 2. 考慮ポイント
   ポイント５ : SQL Server AlwaysOn 可用性リスナーに紐づけるロードバランサー(ILB)
   のSKUをStandardおよびゾーン冗長に設定
   SQL Server Always On 可用性グループに接続するロードバラン
   サーについても、 ロードバランサー(ILB) 作成時、種類：「内部」、
   SKU :「Standard」､可用性ゾーン : 「ゾーン冗長」を選択して作成
   

   View Slide

9. 2. 考慮ポイント
   ポイント６ : Azure上の高可用性のサービス(データベースなど)に接続するアプリ
   ケーションでは、リトライ処理を実装し、エラーハンドリングできる状態にする。
   パブリッククラウドサービスのSLAは100%ではなく、高可用性を維持する
   ために、内部的にフェールオーバーなどが実施されています。
   そのため、クラウドサービス(特にデータベースなど)へ接続するアプリ
   ケーションでは、フェールオーバーに伴い、実行中の処理が失敗したり、
   該当のサービスに接続できないなどの問題に対処するため、アプリケー
   ション側でエラーをハンドリングし、リトライ処理を実装することが推奨され
   ている。
   ※ リトライ処理を実装する場合、リトライ間隔、リトライ回数も重要な要素
   となり、リトライ間隔については、数秒 (5秒など) 以上に設定する。
   Exponential back off (徐々にリトライ間隔を延ばしていくロジック) も有効。
   

   View Slide

10. 2. 考慮ポイント
    ポイント７ : サーキット ブレーカーの実装を検討する。
    ポイント６でリトライ処理の実装を推奨するという内容を記載しましたが、
    即座に解決しない問題が発生した場合、複数のプロセスで同時に大量の
    リトライ処理が実行されることで、 急激なトラフィックの増加に伴い、障害
    範囲が拡大する可能性もあります。
    そのため、リトライ処理を何回か実行したとしても現象が解消しない場合
    においては、失敗を処理するロジックを追加するといった実装
    サーキット ブレーカー パターン
    サーキット ブレーカー パターンを実装する
    

    View Slide

11. 3. 最後に
    今回紹介したゾーン冗長を考慮したAzure仮想マシン上にSQL Server Always On可用
    性グループの構築については、以下のブログでも紹介しています。
    Azure仮想マシン上にゾーン冗長を考慮したSQL Server AlwaysOn可用性グループを構築する場合の勘所について
    また、SQL Serverの 基本＋α の内容についてもブログにまとめていますので、是非 ご
    参照ください。 (現在 第１回から１１回まで公開中)
    【第1回】基本から始める SQL Server【システム データベース】
    

    View Slide

12. 4. 参考情報
    ゾーン冗長を考慮した WSFC クラスタークォーラム設定(クラウド監視) [Azure/WSFC]
    フェールオーバー クラスターのクラウド監視を展開する
    Azure 上でフェールオーバー クラスターを構築する際の留意事項について
    再起動を必要としないメンテナンス
    リースのタイムアウト
    正常性チェックの値
    ゾーン冗長を考慮した SQL Server 可用性グループ + 可用性リスナー(内部)の構築 [Azure/WSFC/SQL Server]
    

    View Slide

13. Q＆A
    

    View Slide