Edited at

IBM Cloud Internet Services (CIS) のグローバル・ロード・バランサーで地理的経路(Geo routes)を設定する

More than 1 year has passed since last update.


地理的経路(Geo routes)について

IBM Cloud Internet Services (CIS) のグローバル・ロード・バランサーには、クライアントに近いオリジンサーバーにルーティングしてくれる、地理的経路(Geo routes)というオプション機能があります。(オプションと言っても、特に追加料金は発生しません!)

例えば、この記事で今から説明するように、日本にあるクライアントは東京DCのオリジンサーバーに行き、ワシントンにあるクライアントはダラスDCのオリジンサーバーに行き、パリにあるクライアントはフランクフルトDCのオリジンサーバーに行く、という設定が可能です。

このオプションを使わない場合は、シンプルに優先順位の設定に従って、例えば普段は優先順位の最も高い東京DCのオリジン、東京がダウンしたら次の優先順位のダラスDCのオリジン、というように切り替わります。


環境の準備

・オリジンサーバーとして、東京DC、ダラスDC、フランクフルトDCに1台ずつウェブサーバーを作成。

どのオリジンからの配信か分かるように、テストページの記載はそれぞれ変えています。

image.png

・GLBのヘルス・チェックは index.html に対して実施。間隔やタイムアウトはデフォルト値。

image.png

・GLBの起点プールを3つ作成し、それぞれのプールに1台ずつオリジンサーバーを配置。

 ・pool-apに東京DCのサーバー

 ・pool-usにダラスDCのサーバー

 ・Pool-euにフランクフルトDCのサーバー

image.png

(この画面、日本語表示だと正常なのに赤で違和感がありますが、英語表示にすると、きちんとグリーンになっています...)

image.png

pool-apの設定は下記です。他のpoolにも同様に、各エリアのオリジンを1台ずつ配置します。

image.png

・GLB配下に3つのプールを配置。優先順位は pool-ap > pool-eu > pool-us の順

地理的経路(Geo routes)の設定箇所もこの画面にありますが、まだ設定はしていません。

image.png

GLBの設定方法は、下記もご参照ください。

https://console.bluemix.net/docs/infrastructure/cis/glb-setup.html#set-up-and-configure-your-load-balancers

https://qiita.com/y_tama/items/7e1ddd5dc94990835311

今の設定内容の場合、クライアントの地理的な位置に関わらず、シンプルに優先順位の設定に従って、普段は優先順位の最も高い東京DCのオリジン、東京がダウンしたら次の優先順位のフランクフルトDCのオリジン、というように切り替わります。


地理的経路(Geo routes)の設定

グローバル・ロード・バランサーの設定画面で、地理的経路の設定を行います。初期は、何も設定されていません。

image.png

経路の追加で、「北アメリカ東部」を選択し、「追加」ボタンを押下します。

image.png

image.png

上記の「プールの追加」から、「起点プールの追加」のポップアップを開き、pool-usを追加します。

image.png

image.png

同様に、「西ヨーロッパ」の地理的経路を追加し、その中に「pool-eu」を追加します。

同様に、「北東アジア」の地理的経路を追加し、その中に「pool-ap」を追加します。

(地理的経路の作成の順番は、特に動作には影響ありません)

image.png

上記の例では各経路に1つのpoolですが、もしその1つがダウンすると、他のpoolに割り振られるのではなく、エラーとなります。各経路内で可用性を高める場合は、各経路の中にプールを追加します。例えば下記では、日本からのアクセスは通常はpool-ap(東京DC)のオリジンに行き、それがダウンした場合、pool-us(ダラスDC)のオリジンに行きます。

image.png


動作確認

下記のように、クライアントに近いオリジンにルーティングされている事が分かります。

【ワシントンの環境からアクセス】→ ダラスのオリジンにルーティングされた。

image.png

【パリの環境からアクセス】→ フランクフルトのオリジンにルーティングされた。

image.png

【東京の環境からアクセス】→ 東京のオリジンにルーティングされた。

image.png

なお、GLBのFQDN(今回はlb01.tama0921.com)を名前解決した際の実IPアドレスは、いずれの環境で名前解決しても同一のIPアドレスとなり、pingの応答も大変早いです。グローバル・ロード・バランサーへのアクセスも、anycast が使われている事が分かります。

>nslookup lb01.tama0921.com

Server: UnKnown
Address: 10.0.80.11

Non-authoritative answer:
Name: lb01.tama0921.com
Addresses: 2400:cb00:2048:1::6814:9b3
2400:cb00:2048:1::6814:ab3
104.20.10.179
104.20.9.179
>ping lb01.tama0921.com

Pinging lb01.tama0921.com [104.20.10.179] with 32 bytes of data:
Reply from 104.20.10.179: bytes=32 time=1ms TTL=60
Reply from 104.20.10.179: bytes=32 time=1ms TTL=60
Reply from 104.20.10.179: bytes=32 time<1ms TTL=60
Reply from 104.20.10.179: bytes=32 time<1ms TTL=60

Ping statistics for 104.20.10.179:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

CISとanycastについては、下記もご参照ください。

https://qiita.com/y_tama/items/11615687eaa24cd1d67b

このように、グローバル・ロード・バランサーの地理的経路(Geo routes)の機能を使って、クライアントに近いオリジンサーバーにルーティングすることで、ウェブサイトの応答速度を向上させたり、エリアごとにコンテンツを変えるといった事も可能になります。