OCI Load Balancer と Oracle Linux 9 でロードバランシングを体験 その４ Load Blanacer作成・設定

# 【お知らせ】この記事はこちらの記事と連動しております。

## **OCI Full Stack Disaster Recovery (FSDR) が Load Balancer 対応になったので試してみた**
https://qiita.com/Assemble_EX-80/items/92262c337290d57b670c

[こちらの記事](https://qiita.com/Assemble_EX-80/items/92262c337290d57b670c)を試すための [事前準備](https://qiita.com/Assemble_EX-80/items/92262c337290d57b670c#%E4%BA%8B%E5%89%8D%E6%BA%96%E5%82%99) の方法をステップバイステップで記述したものであり、こちらで利用している**Load Balancerと、Oracle Linux 9の構成を最速で構成する手順** です。

この**一連の記事に沿ってリソースを作成するだけ**でも、OCIで **Load Balancer** と **Oracle Linux 9** の**Webサーバを構築**して、**ロードバランシングを体験**することができます。

この記事は、**[その４ Load Blancer 作成・設定](https://qiita.com/Assemble_EX-80/items/20de1daabfb1f0857fc5)** です。

この手順を完了すれば、OCI上に簡単なネットワークをつくり、コンピュートのVMインスタンスを作成し、そのインスタンスに外部（インターネット）からSSHでアクセスできるようになります。

OCI の ObLoad Balancer に関しては以下のスライド資料とマニュアルページを参照してください。

■資料


# 目次
**[その１ はじめに](https://qiita.com/Assemble_EX-80/items/09d552f69e8b60e6f804)**
**[その２ ネットワーク(VCN)とVM 作成](https://qiita.com/Assemble_EX-80/items/5d941b67a73703b20f9c)**
**[その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定 ](https://qiita.com/Assemble_EX-80/items/d89ddb7b78c84373c49a)**
**[その４ Load Blancer 作成・設定](https://qiita.com/Assemble_EX-80/items/20de1daabfb1f0857fc5)**
**[その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定](https://qiita.com/Assemble_EX-80/items/b846a3ac8aa8de71301a)**
<!--
**[その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定 ](https://qiita.com/Assemble_EX-80/items/d89ddb7b78c84373c49a)**
**[その４ Load Blancer 作成・設定 ](https://qiita.com/Assemble_EX-80/items/20de1daabfb1f0857fc5)**
**[その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定 ](https://qiita.com/Assemble_EX-80/private/b846a3ac8aa8de71301a)**
-->

の構成でお届けしています。


# Load Balancer 作成前準備


## **周辺構成図**
図のようなLoad Balancerを利用するシステムを作っていきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/e34e7871-84c0-1f2f-dae7-f049dd9b51c6.png)

## **構成情報**
**Tokyo Region**

```
Load Balancer
 名前: lb_01
 バックエンド・セット: bs_lb_01
 バックエンド: instance-01, instance-02
```
```
 可視性タイプの選択：パブリック
 リスナー名：Listener_lb_01
 トラフィックタイプ：HTTP
```
<!--
パブリックIPアドレスの割当て：エフェメラルIPアドレス （デフォルト）
 シェイプ：フレキシブルシェイプ （デフォルト）
 帯域幅： 10 Mbps （デフォルト）
-->

FSDRを試す場合はスタンバイ側（この場合は Seoul Region）にも Load Balancer を用意しておく必要があります。

**Seoul Region**
```
Load Balancer
 名前: lb_01
 VCN: vcn01_icn
 バックエンド・セット: bs_lb_01_icn
```

**仮想クラウドネットワーク** **(VCN)** と、**コンピュートVM** はすでに下記のようなリソースが作られている前提です。

まだ作成されてない場合は **[その２ ネットワーク(VCN)とVM 作成](https://qiita.com/Assemble_EX-80/items/5d941b67a73703b20f9c)** を参考に準備します。

**Tokyo Region**
```
VCN
名前: vcn01
 IPv4 CIDRブロック: 10.0.0.0/16
public_subnet
 IPv4 CIDRブロック: 10.0.0.0/24
private_subnet
 IPv4 CIDRブロック: 10.0.1.0/24
セキュリティーリスト
 イングレスルール 追加
  ソースCIDR: 0.0.0.0/0
  宛先ポート範囲: Port 80,433
インターネット・ゲートウェイ
 internet_gw01
デフォルトルート
 internet_gw01
```
```
VM
 instance-01
  Private IP: 10.0.0.101  
 instance-02
  Private IP: 10.0.0.102
```

**Seoul Region**
```
VCN
名前: vcn01_icn
 IPv4 CIDRブロック: 192.168.0.0/16
public_subnet
 IPv4 CIDRブロック: 192.168.0.0/24
private_subnet
 IPv4 CIDRブロック: 192.168.1.0/24
セキュリティーリスト
　イングレスルール 追加
　　ソースCIDR: 0.0.0.0/0
　　宛先ポート範囲: Port 80,433
インターネット・ゲートウェイ
 internet_gw01_icn
デフォルトルート
 internet_gw01
```

コンピュートVM を移動インスタンスとして、FSDRにメンバー登録する場合はスタンバイ側のリージョンにあらかじめ VM を用意しておく必要はありません。

<!--
```
VM
 instance-03
  Private IP: 10.0.0.203 
 instance-04
  Private IP: 10.0.0.204
```
-->

# Load Balancer 作成

### ロード・バランサーの作成ボタンを押す
「ロード・バランサーの作成」ボタンを押します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/53d9aa26-217c-3e12-885c-7278a042dbd9.png)

### 詳細の追加
### ロードバランサ名を付ける
ロードバランサ名を付けます。
この場合 **lb_01** です。
可視性タイプの選択は **パブリック** とします（デフォルトなのでそのまま）

※ 可視性をパブリックにしないとインターネット側からは直接アクセスできません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/a7bef235-2ffe-4522-8512-dd747c002fa6.png)

### 帯域幅の選択（オプション）
帯域幅を選ぶことができます。
フレキシブルシェイプは最小帯域幅と最大帯域幅をあらかじめ設定しておくことが可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/454f8aa6-39a0-5b65-a860-7c6c8bd939a1.png)

利用する帯域幅によって費用が変わってきます。
こちらのページでLoad Balancerの数と、帯域幅を入力すると概算費用を見積もることが可能です。

**Flexible Load Balancingの価格**
https://www.oracle.com/jp/cloud/networking/load-balancing/pricing/

ここでは、そのまま 最小帯域幅、最大帯域幅とも 10Mbpsで作成を進めます。



### VNCとサブネット選択
仮想クラウドネットワーク（VCN）とLoad Balancerを配置するサブネットを選択します。

ここでは
　仮想クラウドネットワーク： **VCN01**
　サブネット：**public_subnet**
を選択します。
 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/a0ba8fe8-cafd-afcf-7df3-0c5eb92b257c.png)

作成していない場合は、**[こちらの記事](https://qiita.com/Assemble_EX-80/items/5d941b67a73703b20f9c)** を参考にあらかじめVCNとサブネットを作成しておきましょう。

### バックエンドの選択

ロード・バランシング・ポリシーの指定： **重みづけラウンドロビン** (デフォルト)
としておき

**バックエンドの追加** ボタンを押します。

ロード・バランシング・ポリシー の種類と動作に関しては **ロード・バランサ・ポリシー**
https://docs.oracle.com/ja-jp/iaas/Content/Balance/Reference/lbpolicies.htm 等を参考にしてください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/0f92aba4-8c85-99df-8f8d-f96747aa84ee.png)

追加するバックエンドサーバーを選択します。
この場合
 　**instance-01**
 　**instance-02**
 を選択します。
 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/d50e935e-524a-6f12-2357-ea3db0d3f034.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/62aa225d-e11d-ed3d-2ec3-6d90e4f26475.png)

バックエンドの追加が完了したら **「次」** のボタンを押して**リスナーの構成** 画面に行きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/6db5d7a0-c657-0f58-90ee-bbfde4534feb.png)

### リスナーの構成

 リスナー名：**Listener_lb_01**
 リスナーで処理するトラフィックタイプ：**HTTP**

とします。

**「次」** を押しロギングの管理画面に進みます。

 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/927d8108-c3c4-cf68-d21f-7bb9ea6f6b57.png)

### ロギングの管理

エラーログのみ記録する場合

エラー・ログ：**有効**
デフォルト・ログ・グループの自動作成： **◉** （ロググループが存在しない場合）
ログ名： **lb_01_error**
アクセス・ログ：**有効化されていません**（デフォルト）

等とします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/f6c5d086-7d2c-4923-80b7-7360baaeb60f.png)


すでに、ロググループが存在している場合、**既存のロググループの中からロググループを選択**します。
アクセスログも記録したい場合は、**アクセス・ログ**を**有効化**してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/4c079d63-147e-689f-e1c0-ca23f1702bca.png)

### Load Balancer の作成開始

ここまでで設定に問題がないようであれば **「送信」** をクリックし、Load Balancerの作成を開始します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/63cbf88d-6b92-775c-aec5-511deba86a3c.png)

### Load Balancer 作成完了
Load Balancer の作成が問題なく終了し、バックエンドの状態も問題ない場合は下のような画面になります。

Load Balancerのパブリック IPアドレスの値が 
 
 **IPアドレス： xxx.xxx.xxx.xxx （パブリック)**
 
 のように表示されているはずですので、コピーしてひかえておきます。
 後ほどこのIPにブラウザから接続して動作を確認します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/c2eba5cc-99b6-79cd-2316-2639466c9d88.png)



#### Load Balancer 作成失敗（トラブルシュート）

万一 Load Balancer の作成に失敗した場合は、**作業リクエスト** のところにエラーが出ていないかなどを確認して原因を特定します。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/a54f547e-aaad-df57-2c13-cdb073b6291f.png)

#### バックエンドの状態確認
バックエンドの状態を確認すると**クリティカル**となっている場合があります。
これは、例えばバックエンドセットに登録されているコンピュートVMが起動されていない場合、ヘルスチェックによって**クリティカル**の状態となります。

またバックエンド・セットが複数存在している場合、どれか1つのバックエンド・セットがクリティカルな状態であれば、**全体的なヘルス**はやはり**クリティカル**となるようです。

**バックエンド・セットの状態確認**をしましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/cdf274f2-b2a4-e4fe-1138-36c1a71a09a6.png)

##### バックエンド・セットの状態確認

バックエンド・セットのバックエンド・サーバーにコンピュートVMが登録されてないと、**不完全-バックエンドなし** などというヘルス・ステータスになっている場合があります。
画面左のリソースメニューにも**バックエンド(0)** と**ゼロ0**が表示されている場合があります。

**バックエンド(0)の場合**
もし、これまでのステップで、バックエンドに、コンピュートVMのサーバを追加し忘れていたりした場合は、バックエンドにVMを追加しましょう(笑）

**バックエンドの追加**でバックエンド・サーバーのセットに含めるコンピュートVMインスタンスを指定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/39aa2ccc-b29c-367f-e77b-77512b853328.png)

##### バックエンド・サーバ（コンピュートVM）の状態確認
バックエンド・サーバーのセットにコンピュートVMインスタンスが追加されると、バックエンドのヘルスステータスは保留となり、サーバーのステータスを確認後、ステータスが更新されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/cf0e7c6c-9665-02f5-a6b9-5d19a613db0d.png)

バックエンドに追加した**VMが起動していない**と当然、**スタータスはクリティカル**になります。

万一、VMを起動し忘れていた場合は、VMを起動しましょう（笑）

VMが起動しているのに、いくら待ってもバックエンドのヘルスが**クリティカル**な場合は、VMが正常に起動しているか、VMの指定されたポートにアクセスできるか、前の記事 **[その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定](https://qiita.com/Assemble_EX-80/items/d89ddb7b78c84373c49a)** に戻って再度確認してみましょう。

##### Load Balancerのヘルスチェックポリシー確認

今回の記事のように、コンピュートVMにApacheとPhpをインストール、起動した程度でこのヘルスチェック・ポリシーを変更する必要に迫られることは、まずありえません。
それ故深追いはしませんが、参考までに Load Balancerのヘルスチェックポリシーについても見ておきましょう。

私が確認した時点では、ヘルスチェック・ポリシーのデフォルトは以下のようになっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/be88517b-bf5f-f121-47c4-04c5d3ea571a.png)


**バックエンド・セットの詳細** 画面で **「ヘルス・チェックの更新」** ボタンを押すとヘルス・チェックのポリシーを設定、編集することが可能になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/12000043-9ef0-b856-ca44-0868692a521a.png)

参照マニュアルページは以下になります。
[ロード・バランサのヘルス・チェック・ポリシーの編集](https://docs.oracle.com/ja-jp/iaas/Content/Balance/Tasks/editinghealthcheck_topic-Editing_Health_Check_Policies.htm)

<!---
設定が問題なく完了して、運用を開始後に、バックエンドのヘルスチェックが毎回失敗するようになったのであれば、サーバー側や、Load Balancerからサーバに至る経路に何らかの問題がある可能性もありますので一つ一つ切り分けて対処が必要になるかもしれませんね。サーバーの設定に問題がないとすれば、処理能力やレスポンス速度を改善検討が必要となるかもしれませんね。
-->

## VMの設定、Load Balancerの設定をテスト

ここまで全て問題なく設定できているようであれば、先ほど控えておいた Load BalancerのパブリックIPにWebブラウザで接続をしてみましょう。


トラフィック・分散ポリシーを 重み付けラウンド・ロビンにしているので、この例では、**ブラウザで Load Balancer パブリック IP 131.186.61.113（例） にアクセス**し、**リロード**すると **Server IP が 10.0.0.101**と、**10.0.0.102 と交互に表示**されトラフィック・分散ポリシーの設定通りバックエンドサーバにアクセスしていることがわかります。

バックエンドのコンピュートVMには、前の記事 **[その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定](https://qiita.com/Assemble_EX-80/items/d89ddb7b78c84373c49a)** にてVMにWebサーバ（apache+php等）を設定してあります。



![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3737461/0520c064-02bf-d183-cdc8-526abc7ed1ad.png)


交互に別のプライベートIPアドレスが表示されればテストOKです。

以上、DR構成のプライマリリージョンの東京リージョンに、ネットワーク、VM、Load Balancerを配置して、アクセスして接続をテストしてみました。

次は前準備の最終段階、**その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定**になります。

# 次の記事
## **[その５ オブジェクト・ストレージ、ブロック・ボリューム 作成・設定](https://qiita.com/Assemble_EX-80/items/b846a3ac8aa8de71301a)** になります。

# 前の記事
## **[その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定](https://qiita.com/Assemble_EX-80/items/d89ddb7b78c84373c49a)** 

# 連動記事
**OCI Full Stack Disaster Recovery (FSDR) が Load Balancer 対応になったので試してみた**
https://qiita.com/Assemble_EX-80/items/92262c337290d57b670c