Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Nobushiro Takahara

November 28, 2020
Tweet

More Decks by Nobushiro Takahara

Other Decks in Design

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  7. 2. 考慮ポイント
    ポイント4 : 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide