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

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

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

F2231d064e658439a1f0b710b0c9ead0?s=128

Nobushiro Takahara

November 28, 2020
Tweet

Transcript

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

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

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

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

    Server および Active Directory を冗長化構成する Windows Server は、異なる可用性ゾーンにデプロイしたAzure仮想マシン 上にインストール
  5. 2. 考慮ポイント ポイント2 : WSFC のクォーラムをクラウド監視で構成 Windows Server 2016/2019 では、Windows

    Server Failover Clustering (WSFC)のクォーラムにOS標準機能として選択可能な クラウド監視 を選択
  6. 2. 考慮ポイント ポイント3 : WSFC のハートビート間隔設定を30秒(30000 ミリ秒)以上に設定 WSFC のハートビート間隔設定で SameSubnetDelay

    (単位:ミリ秒) * SameSubnetThreshold (単位:回数) の値が、30秒 (30000 ミリ秒) 以上に なるようにパラメータ値を変更
  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 値 も長く設定
  8. 2. 考慮ポイント ポイント5 : SQL Server AlwaysOn 可用性リスナーに紐づけるロードバランサー(ILB) のSKUをStandardおよびゾーン冗長に設定 SQL

    Server Always On 可用性グループに接続するロードバラン サーについても、 ロードバランサー(ILB) 作成時、種類:「内部」、 SKU :「Standard」、可用性ゾーン : 「ゾーン冗長」を選択して作成
  9. 2. 考慮ポイント ポイント6 : Azure上の高可用性のサービス(データベースなど)に接続するアプリ ケーションでは、リトライ処理を実装し、エラーハンドリングできる状態にする。 パブリッククラウドサービスのSLAは100%ではなく、高可用性を維持する ために、内部的にフェールオーバーなどが実施されています。 そのため、クラウドサービス(特にデータベースなど)へ接続するアプリ ケーションでは、フェールオーバーに伴い、実行中の処理が失敗したり、

    該当のサービスに接続できないなどの問題に対処するため、アプリケー ション側でエラーをハンドリングし、リトライ処理を実装することが推奨され ている。 ※ リトライ処理を実装する場合、リトライ間隔、リトライ回数も重要な要素 となり、リトライ間隔については、数秒 (5秒など) 以上に設定する。 Exponential back off (徐々にリトライ間隔を延ばしていくロジック) も有効。
  10. 2. 考慮ポイント ポイント7 : サーキット ブレーカーの実装を検討する。 ポイント6でリトライ処理の実装を推奨するという内容を記載しましたが、 即座に解決しない問題が発生した場合、複数のプロセスで同時に大量の リトライ処理が実行されることで、 急激なトラフィックの増加に伴い、障害

    範囲が拡大する可能性もあります。 そのため、リトライ処理を何回か実行したとしても現象が解消しない場合 においては、失敗を処理するロジックを追加するといった実装 サーキット ブレーカー パターン サーキット ブレーカー パターンを実装する
  11. 3. 最後に 今回紹介したゾーン冗長を考慮したAzure仮想マシン上にSQL Server Always On可用 性グループの構築については、以下のブログでも紹介しています。 Azure仮想マシン上にゾーン冗長を考慮したSQL Server AlwaysOn可用性グループを構築する場合の勘所について

    また、SQL Serverの 基本+α の内容についてもブログにまとめていますので、是非 ご 参照ください。 (現在 第1回から11回まで公開中) 【第1回】基本から始める SQL Server【システム データベース】
  12. 4. 参考情報 ゾーン冗長を考慮した WSFC クラスタークォーラム設定(クラウド監視) [Azure/WSFC] フェールオーバー クラスターのクラウド監視を展開する Azure 上でフェールオーバー

    クラスターを構築する際の留意事項について 再起動を必要としないメンテナンス リースのタイムアウト 正常性チェックの値 ゾーン冗長を考慮した SQL Server 可用性グループ + 可用性リスナー(内部)の構築 [Azure/WSFC/SQL Server]
  13. Q&A