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

OCI技術資料 : ロード・バランサ 概要
https://speakerdeck.com/ocise/ociji-shu-zi-liao-rodobaransa-gai-yao
P.9 の**バックアップ制御**が気になったので動作テストをしてみました。 
![image-20200903090931521.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/b9a33663-aafe-de55-bbc2-40f33a93ce28.png)
ロード・バランサのバックエンドサーバー毎に次の制御ができるようですが、今回は**バックアップ**を試します。

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

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

## テスト環境

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

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

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

  ![image-20200903100841659.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/04ca690c-ec79-9db9-ef0a-7c2b6f78384a.png)
### 通常時／異常時の自動切換え
#### 1. 初期動作

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

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

![image-20200903105442121.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/751fbf72-3260-e211-f716-42bffd87888d.png)

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

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

![image-20200903111217407.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/04f18555-890f-ac29-3353-6a3b37ba8dc5.png)
バックエンド・セットに含まれる２台のインスタンスが表示されています。
osaka01 : 192.168.0.8
osaka02 : 192.168.0.9

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

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

![image-20200903112238537.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/b51ed8b0-6896-6cc1-5392-649445bda664.png)


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

バックエンドのインスタンス osaka02 の**バックアップ設定**を **True** とし有効化します。
インスタンス osaka02 を選択し、[アクション] から **”バックアップ状態の編集"** を選択し、下記画面で **True** 有効化に変更します。
![image-20200903114519388.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/e5b0ff2c-3434-643d-8832-8dfad2ac757f.png)
osaka02 バックアップが**True**に変更されました。
![image-20200903114117726.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/d75c1a2f-f081-4df6-52c5-67da24c876b9.png)
変更後、ブラウザからロード・バランサに何度かリクエストすると、osaka01 のみが表示されます。ロード・バランサのバックアップ有効化制御により、osaka02 へはトラフィックが転送されなくなりました。
![image-20200907103845052.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/0d5af122-1309-cb7d-b62f-cbfc0f73d0fe.png)
osaka01 が通常時のバックエンドとして稼働し、osaka02 はバックアップとして機能していることが確認できました。

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

通常時のバックエンドのインスタンス osaka01 を停止します。ナビゲーションメニューから[コンピュート] - [インスタンス] を選択後、osaka01 インスタンスを選択し右ボタンから"停止"をクリックします。停止直後 ヘルスチェックは**"不明"**と表示されますが、
![image-20200904093322100.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/1647df7e-1cbe-ebbb-0615-d326e2318e3c.png)
しばらくするとヘルスチェックでインスタンスの停止が検知され、通常時のバックエンド osaka01 のヘルスは**”クリティカル”**へ変更されました。

![image-20200904093750852.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/90b471f7-a404-775a-9d5c-c39f17e61d8e.png)

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

![image-20200907103953727.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/967771dd-f963-880f-4269-8e115842478e.png)

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

### 3台構成での動作確認

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

#### 想定動作

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

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

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

##### 

#### 1. バックエンドに osaka03 を追加
![image-20200904161140558.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/30ec25b8-c9ca-c75d-77c8-fd6e2bfe7fe7.png)
![image-20200904161157674.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/8aeeb7ba-a427-b834-81ba-b342fed6e4f5.png)

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

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

![image-20200904161405535.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/908c8021-6db4-b82d-b221-088b5455425f.png)
この状態で、ブラウザからロード・バランサに何度かリクエストすると、osaka01とosaka03 で交互に処理されることが確認できました。
![image-20200904162601773.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/aafa03b0-e3b6-2298-f2d4-83c52b89b0f1.png)

続いて、osaka01（192.168.0.8） を停止
![image-20200904162908006.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/e78593bd-6119-91da-cc54-70c2b9ff3313.png)

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


![image-20200904163218732.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/4d1a4d15-9505-d431-57e4-2deb0a978c8a.png)

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

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

![image-20200904163705930.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/c4cf705e-f364-6cc2-856b-3e626592fc9b.png)

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

![image-20200907104149929.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/496842/18966d36-7f99-2ae6-4c65-c5b471e61dc8.png)

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