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

OCI Full Stack Disaster Recovery (FSDR) が Load Balancer 対応になったので試してみた

こちらの記事を試すための事前準備の方法をステップバイステップで記述したものであり、こちらで利用しているLoad Balancerと、Oracle Linux 9の構成を最速で構成する手順 です。

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

この記事は、その４ Load Blancer 作成・設定 です。

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

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

■資料

目次

その１はじめに
その２ネットワーク(VCN)とVM 作成
その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定
その４ Load Blancer 作成・設定
その５オブジェクト・ストレージ、ブロック・ボリューム作成・設定

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

Load Balancer 作成前準備

周辺構成図

図のようなLoad Balancerを利用するシステムを作っていきます。

構成情報

Tokyo Region

Load Balancer
 名前: lb_01
 バックエンド・セット: bs_lb_01
 バックエンド: instance-01, instance-02

 可視性タイプの選択：パブリック
 リスナー名：Listener_lb_01
 トラフィックタイプ：HTTP

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

Seoul Region

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

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

まだ作成されてない場合は その２ネットワーク(VCN)とVM 作成 を参考に準備します。

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 を用意しておく必要はありません。

Load Balancer 作成

ロード・バランサーの作成ボタンを押す

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

詳細の追加

ロードバランサ名を付ける

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

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

帯域幅の選択（オプション）

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

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

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

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

VNCとサブネット選択

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

ここでは
　仮想クラウドネットワーク： VCN01
　サブネット：public_subnet
を選択します。

作成していない場合は、こちらの記事 を参考にあらかじめVCNとサブネットを作成しておきましょう。

バックエンドの選択

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

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

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

追加するバックエンドサーバーを選択します。
この場合
　instance-01
　instance-02
を選択します。

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

リスナーの構成

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

とします。

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

ロギングの管理

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

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

等とします。

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

Load Balancer の作成開始

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

Load Balancer 作成完了

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

Load Balancerのパブリック IPアドレスの値が

IPアドレス： xxx.xxx.xxx.xxx （パブリック)

のように表示されているはずですので、コピーしてひかえておきます。
後ほどこのIPにブラウザから接続して動作を確認します。

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

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

バックエンドの状態確認

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

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

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

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

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

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

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

バックエンド・サーバ（コンピュートVM）の状態確認

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

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

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

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

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

今回の記事のように、コンピュートVMにApacheとPhpをインストール、起動した程度でこのヘルスチェック・ポリシーを変更する必要に迫られることは、まずありえません。
それ故深追いはしませんが、参考までに 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インストール、設定 にてVMにWebサーバ（apache+php等）を設定してあります。

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

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

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

次の記事

その５オブジェクト・ストレージ、ブロック・ボリューム作成・設定になります。

前の記事

その３ VM上の Oracle Linux 9 に apache、PHPインストール、設定

連動記事

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