3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

OCI ロード・バランサ - バックエンドのバックアップ制御を試してみた

Last updated at Posted at 2020-09-08

OCI技術資料 : ロード・バランサ 概要
https://speakerdeck.com/ocise/ociji-shu-zi-liao-rodobaransa-gai-yao
P.9 のバックアップ制御が気になったので動作テストをしてみました。
image-20200903090931521.png
ロード・バランサのバックエンドサーバー毎に次の制御ができるようですが、今回はバックアップを試します。

  • バックアップ
  • ドレイン
  • オフライン

用途例としてはSorryサーバと記載されていますが、通常時/異常時のコンピュートインスタンスの自動切替などにも応用ができそうです。

テスト環境

  • OCI 大阪リージョンに複数のコンピュートインスタンス(osaka01, osaka02, osaka03)を作成。

  • 各インスタンスには簡単なWebアプリがデプロイされており、ロード・バランサからのリクエストを受けるとインスタンス名(osaka01, osaka02, osaka03)をブラウザに表示。

  • ロード・バランサの[負荷分散ポリシー]は 重みづけラウンドロビン(重み default値 1 ) とする。

    image-20200903100841659.png

通常時/異常時の自動切換え

1. 初期動作

ロード・バランサとバックエンド(osaka01, osaka02)の状況を確認します。

ナビゲーションメニューから、[ネットワーキング] - [ロード・バランサ]を選択し、テスト前の状態を確認します。

image-20200903105442121.png

[バックエンド・セットのヘルス] ヘルスチェックはOK

続いて、[ロード・バランサ] 画面左下の [バクエンド・セット] をクリックし、実際のバックエンドの構成を表示します。

image-20200903111217407.png
バックエンド・セットに含まれる2台のインスタンスが表示されています。
osaka01 : 192.168.0.8
osaka02 : 192.168.0.9

共にヘルスチェックは OK 正常動作しています。また各インスタンスで設定可能な ドレインオフラインバックアップはすべて False の初期状態となっています。

この状態で、ブラウザからロード・バランサに何度かリクエストをすると、ラウンドロビンのポリシーにそってバックエンドのインスタンス(osaka01, osaka02)に交互にリクエストが振り分けられていることが確認できます。

image-20200903112238537.png

2. バックアップ制御 有効化

バックエンドのインスタンス osaka02 のバックアップ設定True とし有効化します。
インスタンス osaka02 を選択し、[アクション] から ”バックアップ状態の編集" を選択し、下記画面で True 有効化に変更します。
image-20200903114519388.png
osaka02 バックアップがTrueに変更されました。
image-20200903114117726.png
変更後、ブラウザからロード・バランサに何度かリクエストすると、osaka01 のみが表示されます。ロード・バランサのバックアップ有効化制御により、osaka02 へはトラフィックが転送されなくなりました。
image-20200907103845052.png
osaka01 が通常時のバックエンドとして稼働し、osaka02 はバックアップとして機能していることが確認できました。

3. 通常時から異常時への切り替え

通常時のバックエンドのインスタンス osaka01 を停止します。ナビゲーションメニューから[コンピュート] - [インスタンス] を選択後、osaka01 インスタンスを選択し右ボタンから"停止"をクリックします。停止直後 ヘルスチェックは**"不明"と表示されますが、
image-20200904093322100.png
しばらくするとヘルスチェックでインスタンスの停止が検知され、通常時のバックエンド osaka01 のヘルスは
”クリティカル”**へ変更されました。

image-20200904093750852.png

この状態で、ブラウザからロード・バランサにリクエストすると、ロード・バランサがバックアップ有効化されている osaka02 へリクエストを転送していることが確認できます。
その後のリクエストはすべて osaka02 で処理され、異常時のバックアップとして機能していることが確認できました。

image-20200907103953727.png

osaka01 サーバを再起動して、ヘルスチェック "OK" になれば、osaka01 サーバが通常時として復活します。

3台構成での動作確認

ロード・バランサのバックアップ制御の動作について理解できたので、3台構成で想定どおりの動きになるかを試します。

想定動作

  1. バックエンドに osaka03 を追加し3台構成とする

  2. osaka02 のバックアップを有効化(True)
    通常時:osaka01, osaka03 サーバでラウンドロビンされる
        osaka01 サーバーを停止後は、osaka03でのみリクエスト処理される

  3. osaka03も停止(すべてのバックエンドがヘルスOKじゃなくなる)
    異常時:osaka02 がバックアップとして機能し、以後はosaka02 でリクエスト処理される

1. バックエンドに osaka03 を追加

image-20200904161140558.png
image-20200904161157674.png

2. osaka02 のバックアップを有効化(True)

osaka02 (192.168.0.9) のバックエンドを有効化

image-20200904161405535.png
この状態で、ブラウザからロード・バランサに何度かリクエストすると、osaka01とosaka03 で交互に処理されることが確認できました。
image-20200904162601773.png

続いて、osaka01(192.168.0.8) を停止
image-20200904162908006.png

この状態で、ブラウザからロード・バランサにリクエストすると、osaka03 のみで処理されることが確認できました。

image-20200904163218732.png

3. osaka03も停止(すべてのバックエンドがヘルスでなくなる)

バックアップ有効化の osaka02 を除き、osaka01, osaka03 の停止により、バックエンド全体のヘルスがクリティカルな状態となる。

image-20200904163705930.png

この状態で、ブラウザからロード・バランサにリクエストすると、ロード・バランサがバックアップ有効化されている osaka02 へリクエストを転送していることが確認できます。

image-20200907104149929.png

その後のリクエストはすべて osaka02 で処理され、バックアップ有効化の想定された動きになっていることが確認できました。

3
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?