下記の続きです。
IBM Cloud Internet Services (CIS)の機能に、Global Load Balancerがあります。
手軽に、複数DCにウェブサーバーを立てられるクラウドと、相性の良い機能と思います。
手順としては、下記の手順となります。
https://console.bluemix.net/docs/infrastructure/cis/glb-setup.html#set-up-and-configure-your-load-balancers
メニューの、Reliabilityの下に、Global Load Balancerの設定画面があります。
下記3つの設定項目があります。設定する順序は、Health Checks -> Origin Pools -> Load Balancers です。
・Load Balancers
・Origin Pools
・Health Checks
Create health checkボタンを押した画面で、パス、プロトコル、間隔などを指定します。
Origin Poolsで、Load Balancerのバックエンドとなるサーバーを定義します。
今回は、東京DCのプールと、ソウルDCのプールを作ることにしました。
東京DCのプールは、本番を想定し、ウェブサーバー2台構成としています。
1つのOrigin Poolに、複数のOriginサーバーを設定します。「Healthy Origin Threshold」で指定した台数が生きていれば、そのPoolは生きていると見なされ、ロードバランサーからリクエストが割り振られます。
ソウルDCのプールは、東京が被災した時の縮退運転をイメージし、ウェブサーバーを1台だけ配置しました。
プールの定義が終わったら、最後に、Load Balancersの定義を行います。
作成したPoolを登録し、Priorityの順序づけをします。
東京のプールが本番想定なので、Priorityをソウルのプールより高くしました。
上記で定義したBalancerのHostnameを使って、Global Load Balancer経由でアクセスするためのFQDNが自動で生成されます。
$ nslookup glb01.tama0921.com
Server: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx#53
Non-authoritative answer:
Name: glb01.tama0921.com
Address: 104.20.30.221
Name: glb01.tama0921.com
Address: 104.20.29.221
$
設定完了後の画面です。今は、すべてグリーンのHealthyの状態です。
この状態で、Global Load BalancerのFQDNにアクセスすると、Priorityの高い東京のプールのウェブサーバーからコンテンツが返ります。
ここで、東京DCにある2台のウェブサーバーのうち、1台を停止します。
東京のプールの閾値（Healthy Origin Threshold）は1に設定していますので、東京DCの残りの1台が稼働している状態ですと、Global Load Balancerは東京のプールに割り振りを続けます。
続いて、東京の2台目のウェブサーバーも停止します。
東京のプールの2台ともが停止したので、Global Load Balancerのステータスが変化します。
PoolがCriticalになり、Load BalancerがDegradedになっています。
Global Load Balancerからソウルのプールに割り振られるようになります。（キャッシュが効いて東京のコンテンツが表示され続けたのでプライベートモードにしています）
東京のサーバーを1台立ち上げなおすと、ステータスがHealthyに戻ります。
ところで、Global Load Balancerに割り振られるFQDNは、下記のようにCloudflareのIPアドレスと紐づいていますが、これは、物理的に2台のロードバランサーという訳ではありません。
$ nslookup glb01.tama0921.com
Server: x.x.x.x
Address: x.x.x.x#53
Non-authoritative answer:
Name: glb01.tama0921.com
Address: 104.20.29.221
Name: glb01.tama0921.com
Address: 104.20.30.221
$
技術的にはanycastを使っており、世界中の様々な箇所からアクセスすると、その地点の最寄りのGlobal Load Balancerにルーティングされて応答が得られます。これにより、耐障害性とパフォーマンスが実現されています。
■東京DCからのping
[root@testsrv01 ~]# ping glb01.tama0921.com
PING glb01.tama0921.com (104.20.30.221) 56(84) bytes of data.
64 bytes from 104.20.30.221: icmp_seq=1 ttl=59 time=1.37 ms
64 bytes from 104.20.30.221: icmp_seq=2 ttl=59 time=1.25 ms
64 bytes from 104.20.30.221: icmp_seq=3 ttl=59 time=1.21 ms
64 bytes from 104.20.30.221: icmp_seq=4 ttl=59 time=1.34 ms
■パリDCからのping
[root@testsrv04 ~]# ping glb01.tama0921.com
PING glb01.tama0921.com (104.20.30.221) 56(84) bytes of data.
64 bytes from 104.20.30.221: icmp_seq=1 ttl=60 time=0.920 ms
64 bytes from 104.20.30.221: icmp_seq=2 ttl=60 time=0.742 ms
64 bytes from 104.20.30.221: icmp_seq=3 ttl=60 time=0.835 ms
64 bytes from 104.20.30.221: icmp_seq=4 ttl=60 time=0.677 ms
■サンパウロDCからのping
[root@testsrv07 ~]# ping glb01.tama0921.com
PING glb01.tama0921.com (104.20.30.221) 56(84) bytes of data.
64 bytes from 104.20.30.221: icmp_seq=1 ttl=60 time=1.71 ms
64 bytes from 104.20.30.221: icmp_seq=2 ttl=60 time=1.44 ms
64 bytes from 104.20.30.221: icmp_seq=3 ttl=60 time=1.49 ms
64 bytes from 104.20.30.221: icmp_seq=4 ttl=60 time=1.50 ms
このように、簡単にデータセンターまたぎの負荷分散が実現できました。
今回は2つですが、Poolは3つ以上作れますので、複数箇所に分散した耐障害性の高い構成も容易に実現できます。