IBM Cloud：Private GLBによるサービス稼働系切り替えにあわせた自動ルーティング設定

# 概要
サービスを稼働する環境において、Active／Stanbyにて冗長化させる構成は多いかと思います。また、障害時にフェイルオーバーが発生すると、稼働系へのルーティングを切り替える必要があります。

本記事では、フェイルオーバークラスターを構成可能な[**SIOS Protection Suite for Linux**](https://docs.us.sios.com/spslinux/9.5.1/ja/topic/sios-protection-suite-for-linux-technical-documentation)を用いてActive/Standbyノードを構成し、**private GLB**を用いて、Active/Standbyノードに対してヘルスチェック・稼働系のサービスに通信を転送するようにします。


# 前提
本記事の環境は以下の手順書に則り、LifeKeeper/DataKeeperを用いて構成します。
pdf：[SIOS Protection Suite for Linux Step by Step Guide【IBM Cloud編】](https://ibm.box.com/v/ibmcloud-vpc-sioslifekeeper)

手順書内では、フェイルオーバー時のルーティング切り替えに**generic arkリソース**をLifeKeeper上に作成しました。generic arkリソースとは、ノードの起動時/停止時に自作のスクリプトを実行してくれるリソースです。上記手順書では起動時にスクリプトを実行するようにgeneric arkリソースで設定し、実行時にスクリプト内のibmcloud CLIを用いてルーティングテーブルを書き換えるよう設定していました。またクライアントは、IPアドレスリソースを用いてNICに付与された仮想IPアドレスに対して接続します。

本記事では、generic ark・仮想IPアドレスの設定は行わず、**LB Health Check Kit (LB Health Checkリソース)** を使用しています。LB Health Checkリソースは、GLBからのヘルスチェックに対して応答を行うリソースです。
(バージョン9.6.1以前は同等機能として「Generic ARK for Load Balancer probe reply（Gen LB）」と呼ばれていたものが提供されていました）
private GLBを使用してルーティング切り替えするため、上記手順書で作成したgeneric arkリソースを削除し、LB Health Checkリソースを追加した環境で構成していますのでご注意ください。

(参考) [[Linux]Generic ARK for Load Balancer probe reply の提供](https://lkdkuserportal.sios.jp/hc/ja/articles/900004703743--Linux-Generic-ARK-for-Load-Balancer-probe-reply-%E3%81%AE%E6%8F%90%E4%BE%9B)

## genLBリソース / LifeKeeperの設定
genLBリソースでは、以下のような設定をしました。
|項目  |値  |
|---|---|
|Switchback Type  |Intelligent|
|Server|[Active node名]|
|Reply daemon Port|12345|
|Reply  daemon message|[空欄]|	
|LB Health Check Resource Tag|lb-check|



genLBリソース作成後の階層構造を以下のように設定しています。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/3fb56093-a62e-d0b3-a31a-f93de2d9ab0d.png width=70%>


# 環境情報
構成は以下の通りです(上記手順書に従っています)。
nodeは仮想サーバと考えてください。この構成では、3つの仮想サーバがそれぞれ2つのNICを持っています。
- node1：active  ノード (通常、MySQL稼働)
- node2：standby ノード (通常、MySQL停止)
- node3：Witness ノード (Active/Standbyの死活監視)

図3-1 VPC構成図 (上記手順書より引用)
![genLB有り.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/e3724e41-80d8-9664-eb4c-2e7d2621fe42.png)

クライアントは、privateGLBでの名前解決によって、MySQLが稼働する仮想サーバのIPアドレスを取得して直接サーバと通信を行います。(※本構成のprivateGLBは、reverse proxyとして動作するわけではありません)

# private GLBの設定手順
## DNS Servicesの注文
本記事では省略します。

## zoneの作成
右上の「**ハンバーガーメニュー**」→「**リソースリスト**」より、作成しているDNSリソースを開きます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/d395e2c1-f094-76ab-b406-049981ae779f.png)

DNSリソースを開くと、左側にメニューがあるので、「**Zones**」→「**Create zone**」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/9a33e3fa-66d7-babd-545b-e2b1a357a9ef.png)
以下のように名前を入力し、「**Create zone**」をクリックすると作成されます。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/0e3972e5-8cc3-5f5e-03e8-126bb86e68a3.png width=50%>

## VPCからのアクセス許可
Zoneを作成すると、Statusが`Pending`になります。これは接続されているネットワークがないことが原因ですので接続します。
「**Permitted networks**」→「**Add network**」をクリックし、対象VPCのリージョンと対象VPCを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/24199a21-d3ec-1aa0-3739-d9e6bbea3657.png)

## Health Checksの作成
次にHealth Checksを作成します。Origin PoolへのHealth Checkの設定は必須です。
「**Global load balancer**」→「**Health checks**」→「**Create health check**」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/89c1907e-0c4c-a0d9-b64c-f75963b57005.png)

health check名、チェック対象のType/ポート番号を入力し「**Create**」をクリックします。
(TypeはHTTP/HTTPS/TCPが選択可能ですが、MySQLのポートアクセスをチェックしたいのでTCPを指定します)
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/27aee170-434f-5fb9-6209-60a805251dd5.png width=60%>



作成できました！
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/118c802c-1003-f551-f53d-0398387e00a7.png)

## pool作成
続いてpoolを作成します。「Health checks」タブの左にある「**Origin pools**」タブをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/3d3912fc-bddf-5e77-4a92-8429c58d9324.png)

「**Create origin pool**」をクリックします。
（同じpoolでも作成可能ですが、GLB登録時に明示的にpolicyを分けるために、今回は仮想サーバ1と2、それぞれでpoolを作成してみます）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/c3e6e85f-81f1-94fe-3410-ad114e73897a.png)

以下を登録します。
- pool名
- 登録するサーバ名（実際の仮想サーバー名と異なっても問題ないです）
- サーバにあるMySQLにアクセス可能なprivate IPアドレス (今回は10.1.1.4 / 10.2.1.4)

Health Monitoringの登録
- Health check：使用するHealth checkを選択
- region、VPC、subnet：どのregionのVPC/subnetに対してhealth checkを行うかを選択

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/3d8f122c-b127-00f6-eac5-9bf425d3564d.png)


仮想サーバ1と2それぞれで作成しました。
仮想サーバ2ではMySQLを停止しているので、TCP:12345に対するLB Health Checkリソースの応答が停止し、privateGLBからのhealth checkが失敗します。そのため、`mysqlpool2`は「**<font color="red">critical</font>**」になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/5e5c8797-44cf-8899-7444-6ddb5f6d6f89.png)


## GLB作成
「Origin pools」タブの左にある「**Load balancers**」タブをクリックし、`DNS zones`に作成したzoneを選択、「**Crate load balancer**」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/72a23b44-9c70-9a56-ddf5-78c90b8101c6.png)

balancer名を入力します。
次に、青文字の「<font color="blue">Add default policy</font>」をクリックします。
![Screen Shot 2022-07-08 at 1.23.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/5951663e-3713-b531-07a7-aee241fe23a8.png)

仮想サーバ１のpoolを選択します。
![Screen Shot 2022-07-08 at 1.24.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/b2617442-0ba5-efe6-68f8-289d29ef26ca.png)

同様に、青文字の「<font color="blue">Add fallback policy</font>」をクリックし、仮想サーバ2のpoolを選択します。
![Screen Shot 2022-07-08 at 1.24.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/f8eca1d5-af4a-eaca-1e79-fe970b629766.png)

以下のように入力したら「**Add**」をクリックします。
![Screen Shot 2022-07-08 at 1.24.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/8f581c26-a3ef-a06d-fd69-059eaea95856.png)
**以上で設定完了です！！**

# テスト
仮想サーバ1 / 2と同じVPC、かつ別AZにあるクライアントサーバからアクセスしてみます。
また、途中でサービス稼働系を切り替えた時、同じFQDN (`mysqldbtest.glbtest.local`)でアクセスし続けられるかテストします。

```
[root@vsi-client ~]#  dig mysqldbtest.glbtest.local +short
10.1.1.4  (仮想サーバ1のIPアドレス)
[root@vsi-client ~]# mysql -uroot -h mysqldbtest.glbtest.local -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 8.0.26 Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SHOW VARIABLES WHERE Variable_name = 'hostname';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| hostname      | vsi1      |
+---------------+-----------+
1 row in set (0.00 sec)

mysql> quit
Bye


------------------------------------------------------------------------------------
　　　　　　　　　　　サービス稼働系を仮想サーバ1から仮想サーバ2に切り替え
------------------------------------------------------------------------------------


[root@vsi-client ~]#  dig mysqldbtest.glbtest.local +short
10.2.1.4  (仮想サーバ2のIPアドレス)
[root@vsi-client ~]# mysql -uroot -h mysqldbtest.glbtest.local -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10
Server version: 8.0.26 Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SHOW VARIABLES WHERE Variable_name = 'hostname';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| hostname      | vsi2      |
+---------------+-----------+
1 row in set (0.01 sec)

mysql> quit
Bye
[root@vsi-client ~]#
```