1. はじめに

IBM CloudのVPCにて、Private GLB(Global Load Balancer)が利用可能になったので、試してみた。

• 公式ドキュメントはこちら
• 価格情報はこちら

今回は、以下の構成を設定してみる。

• Tokyo1 ZoneのVSIは、Tokyo1にあるWeb Server(Origin Server: 10.0.0.7/10.0.0.8)を優先的に利用
• Tokyo2 ZoneのVSIは、Tokyo2にあるWeb Server(Origin Server: 10.1.0.6/10.0.0.7)を優先的に利用
• 他の拠点（Tokyo3や別リージョン）にあるVSIは特に区別はしないので、Tokyo1/Tokyo2のどちらのWeb Server(Origin Server)も利用。

2. 機能および制約

詳細は公式ドキュメントを見てもらった方がいいが、特に気になった箇所を以下に抜粋。

2.1 機能（抜粋）

• Origin PoolへのHealt Checkの設定は必ずしも必須ではないが、Health Checkを設定しないと、障害のあるOriginへの名前解決を行ってしまう可能性がある。
• Health1 CheckはHTTP/HTTPS/TCPから選択可能。
• Location policyが選択可能。これにより、「Tokyo1のサーバーは優先的にxxxというorigin poolを利用するが、Tokyo2のサーバーは優先的にyyyというorigin poolを利用する」といった使い方が可能。
• 名前解決の順番は、ここにも書かれているように、以下の優先順位に従う。Location policyに設定したorigin poolが全部死んでいても、直ちにFallback policyのorigin poolが利用される訳ではなく、次はDefault policyを利用することに注意。
  1. Location policy
  2. Default policy
  3. Fallback policy

The location policy (if one is defined in the AZ), has the highest priority and is used first. If every origin pool in the location policy is down, then the DNS resolver uses origin pools from default policy. If all of the origin pools in the default policy are also down, then the DNS resolver goes to the origin pool designated in the fallback policy.

2.2 制約（抜粋）

ドキュメントには

• Each origin pool can have up to 5 origins
• Each origin pool can use no more than 2 subnets for health monitoring

と書かれている。また、「Permitted networks内のVPC上のVSIからしかDNSが引けない」ということは、「「Permitted networks内のVPC上のVSIからしかGLBも利用できない」ということになる。

3. Private GLBの構成

3.1. DNSサービスの購入および対象VPCをPermitted Networksに追加

private GLBはprivate DNSの拡張機能なので、DNS Serviceを最初に購入する必要がある。

• DNS Serviceの注文方法
• DNS ServiceでのZoneの作成方法
• 上記Zoneを利用するVPCを登録する方法（Permitted networkへの追加)
• DNSを利用するサーバーでの構成変更（/etc/dhcp/dhclient.confの変更と反映）

については、IBM Cloud: VPC からのプライベートな名前解決にDNS Services を使う(GUI編）を参照のこと。複数のVPCから利用できるように、以下のようにPermitted Networksに追加されているものとする。

3.2 Health Checkの設定

• Create health checkを押下。
  
• HTTP/HTTPS/TCPが選択可能であり、HTTPヘッダもオプションで指定できる。
  
• 確認
  

3.3 Origin Poolの作成

• Create origin poolを押下。
  
• Originの登録
  
• Health Monitoringの登録。どのsubnetからhealth checkを行うかを指定する。
  
• 同様にtokyo2pool(Tokyo2のOriginを登録）およびsharedpool（Tokyo1およびTokyo2のOriginを登録）を作成して確認。
  
• なお、上記でOrigin Pool名を押下すると詳細のステータスを確認可能。
  

3.4 Global Load Balancerの作成

• Create load balancerを押下
  
• 名称とTTL:
  • TTLは必須項目。60/120/300/600/900/1800/3600/7200/18000/43200秒から選択可能
    
• default policy:
  • 必須項目。
  • 複数のorigin poolが選択可能だが優先順位を付ける必要がある。
  • 今回のケースでは、tokyo1やtokyo2はlocation based policyに従い、それぞれtokyo1poolおよびtokyo2poolを優先的に利用するが、tokyo3や海外拠点のregionはどちらのregionを利用してもいいのでsharedpoolを利用する。
    
• fallback policy:
  • 必須項目:
  • １つのorigin poolのみ選択可能
  • 今回のケースでは、sharedpoolを利用する。
    
• location policies
  • 今回のケースでは、Tokyo1のサーバーは優先的にtokyo1poolを利用し、Tokyo2のサーバーは優先的にtokyo2poolを利用する。
    
• 最終的には以下のようになる。
  

4. テスト

# dig A +noall +answer  privateglb.roksvpc.internal
privateglb.roksvpc.internal. 9  IN  A   10.0.0.7
privateglb.roksvpc.internal. 9  IN  A   10.0.0.8

# dig A +noall +answer  privateglb.roksvpc.internal
privateglb.roksvpc.internal. 42 IN  A   10.1.0.6
privateglb.roksvpc.internal. 42 IN  A   10.1.0.7

# dig A +noall +answer  privateglb.roksvpc.internal
privateglb.roksvpc.internal. 60 IN  A   10.1.0.7
privateglb.roksvpc.internal. 60 IN  A   10.0.0.8
privateglb.roksvpc.internal. 60 IN  A   10.1.0.6
privateglb.roksvpc.internal. 60 IN  A   10.0.0.7