vTM を使うとアッという間に LB 環境が作れる

Virtual Traffic Manager (以下、vTM)。 ご存知の方もいらっしゃると思いますが、旧称は SteelApp Traffic Manager です。

vTM は、過去から今に至るまで、色んな会社に買収されていることからベンダー名については、あえて記載していません。

ロードバランサと言えば、F5 ネットワークスの BIG-IP が有名ですが、他社が提供する仮想ロードバランサがあると知り、使い勝手を試して見ましたので、その概要についてご紹介したいと思います。

vTM 1台 = LB 1台 という認識で大丈夫です。

機能制限なし・トラフィック制限付きのデベロッパー版がダウンロードできるので、VMware の仮想環境にデプロイして使い勝手を試して見たのですが、操作性も良かったし、これ位ならライセンス購入して使っても良いんじゃないかと思いました。

特に、全ての操作を Admin UI という管理ウェブページ上で操作するだけで済むので、OS 内の設定を意識しなくても良いところもメリットの一つです。

vTM に特定サービス専用のネットワークを追加したければ、仮想マシンに NIC を追加すると vTM 側で自動的に認識してくれるので、後は GUI 上で IP を入れてポチッとクリックするだけで良いです。

複数台の vTM でクラスタを組んだり、FT (Fault Tolerance) 構成にしたり、Virtual Server 追加だって、たった数回クリックするだけで LB 環境が出来上がります。

特に複数の Virtual Server のトラフィック管理・制御がとっても簡単で、この IP グループ (TIP : 複数の IP でグループを組むことが可能) へ接続がきた場合には、この Virtual Server (Web Pool / DNS Pool 等) へトラフィックを流す ようなことも簡単に出来てしまうので、製品としては良く出来てるなと思いました。

OSS LB と Appliance LB どっちを使うか悩ましい

brocade 仮想ロードバランサ vTM 概要

一通り試して見て vTM の良さを実感したところで、もう ほしくなりましたと。

しかし、こういう製品は サブスクリプションだったり、買いきりだったり、ライセンス費用がかかるため、大体の企業はやっぱり コストかけたくないよねーオープンソースの OSS LB 試して見たいよねー無料で使えるならそれにしたいねー ってなるわけです。

その流れで、まずは一番需要がありそうな Web サーバと DNS 用のロードバランサーをサポートする OSS LB を検証する必要があり、そのための OSS LB の必須条件としては、冗長構成 かつ、 TCP と UDP を両方サポート することでした。

そして、色々検討した末にたどり着いた良さげな組み合わせが以下の二つ。

  • Keepalived + HAProxy
  • Keepalived + LVS (IPVS)

しかし、HAProxy は、UDP をサポートしないため、即アウト。

LVS (IPVS) は、TCP と UDP 両方サポートするし、負荷分散方式だって NATDSR (Direct Server Return)TUN (Tunnel) 3種類あるので、サービスの種類によって使い分け出来そうだったので、LVS に力を入れることにしたわけです。

  • Keepalived + HAProxy
  • Keepalived + LVS (IPVS)

それで、1ヶ月くらい時間かけて、Web と DNS に対してそれぞれ NATDSRTUN 方式を 同ネットワーク/異ネットワーク 全ての 12パターン試して、一応、使えることは確認しましたと。

仮想環境の商用サービスで使う目的で、LVS 全パターン検証してみて、感じたこと・分かったことがこれです。 (個人的な感想です)

  • 2台で冗長化可能 : Active / Standby 構成
  • 負荷分散方式によってハマり要素満載
  • ネットワーク構成によっては負荷分散できないパターンが出てくる
  • LB の外側と内側が同一ネットワークだと DSR がシンプルで良い外側 : クライアントからの接続を待ち受けする側のネットワーク内側 : LB と リアルサーバ間のネットワーク
  • LB の外側と内側のネットワークを分ける構成だと DSR が一番ややこしい
  • LB の外側と内側のネットワークを分ける構成だと NAT と TUN がやりやすい
  • パフォーマンスチューニングが必要特に、本番環境で使うならカーネル再構築は必須
  • 仮想 LB のテンプレート化が難しい出来上がった LB をテンプレート化したとしても、使う人がネットワーク構成に合わせてコンフィグを設定しないと行けない (皆が設定のコツを分かってるわけではない)
  • OSS なので、疑問点・トラブル発生時には自ら解決するしかない
  • 実績と運用ノウハウが足りないので不安

特に、いつでもデプロイして使えるように、構築済みの LB 仮想マシンをテンプレート化したものの、DSR と TUN の場合には、Real Server (Backend) 側にループバックインターフェース とか トンネルインターフェース を付けないと行けなかったり、NAT だとデフォルトゲートウェイを LB 内側の VIP に向ける必要があったりするので、既にサービス提供中の本番環境の仮想マシンを負荷分散させようとすると非常にやり難い感があります。

また、皆が LVS の設定方法を分かってるわけではないので、結局、使う人が学習・検証しなければならないため、こういう OSS LB のテンプレート化は非常に難しいと感じています。

その反面、vTM を使うと以下のようなことが出来ます。

  • 2台以上の構成で冗長化可能 : Active / Active 構成
  • 柔軟性が高く、Hyper-V、VMware、Xen、QEMU/KVM、Amazon EC2、Azure、Google Cloud Platform など、様々な環境で動く
  • 全ての操作は、管理ウェブページ上で行う・一括管理する (ポチッとすれば、OS に自動的に設定が入る)
  • 管理者が vTM OS (Ubuntu) 内の設定をあまり意識する必要がない
  • クラスタ追加、サービス追加など、用途別 Wizard が多数用意されている
  • NAT、ルーティング設定も自由に出来る
  • 複数台の vTM をクラスタ化することによって、vTM 設定とセッションデータが同期される
  • TIP グループを構成することによって、複数台の vTM 間の冗長性を保つ (TIP の Failover・Failback によってリクエストを引き継ぐ)
  • 高速な SSL 処理を実現するために、SSL の暗号・復号処理を vTM が代理で行う SSL Accelerator も使える
  • L4 ~ L7 ロードバランシングが可能 (Round Robin、Weighted Round Robin、Perceptive、Least Connections、Weighted Least Connections、Fastest Response Time、Random Node)
  • Session Persistence (セッションパーシステンス) 機能有り
  • GSLB (Global Server Load Balancing : 広域負荷分散) 可能 (ライセンスによる)

各 Platform、Hyper-Visor 用の OVF テンプレートファイルだったり、イメージファイルが用意されているので、様々な環境で動かせます。

基本的に L4 ~ L7 までサポートするし、各 Virtual Server ごとに負荷分散方式は自由に設定できます。

それに加えて、セッションパーシステンス機能が付いているので、負荷分散しながらも、クライアントの送信元 IP、ノード名等によって、クライアントからのリクエストを特定サーバに送ることができます。

特に、vTM には、TIP (Traffice IP : トラフィックを管理するための IP) という概念があって、TIP でグループを作成することができます。

そうすることによって、TIPs-1 は、Virtual Server 1 (Web) へ、TIPs-2 は、Virtual Server 2 (DNS) へトラフィックを流すことができます。

vTM でクラスタを組んだ状態で、1台の vTM が落ちると TIP は、他の vTM へ Failover します。

特に、vTM は 2台だけでなく、複数台の vTM でクラスタを組むことが可能で、さらに、各 vTM は、Active / Standby ではなく、Active / Active で動くので、複数台の vTM でクラスタを組んだ上で、サービスの種類に合わせて TIPs を設定すると安定的に LB サービスを提供することが出来ます。

また、一つの管理ページ上で、数々の Virtual Server を一括管理できることとトラフィック制御も簡単にできるところもメリットかなと思います。

デメリット言えば、今のところ特にありませんが、本当に簡単に LB 環境の操作・制御・管理が出来てしまうので、オペレーション中に手が滑って一瞬クリックを間違えたりするとヒューマンエラーにつながりやすいとは思いました。

ちなみに、GSLB はサポートしてますが、使うためには、Enterprise License が必要です。

終わりに

需要があまりなさそう、かつ自分たちでコントロール・管理する自身があったら LVS でも良いかなーとは思いますが、LVS をあれだけ頑張ったのに、LVS にかけた努力と時間を考えるとなんとも言えないというか。

特に、vTM は、10Mbps200Mbps1Gbps2Gbps5Gbps10Gbps20Gbps無制限版 のように、帯域ライセンスによってスループットに制限が設けられています。 (ライセンス体系は変更される可能性があります)

なので、もし vTM を検討している段階であれば、どういうサービスで使うか、その目的を決めた上で、事前にトラフィック量を把握しておくと良いです。

以下は、無償評価版 (機能無制限・帯域 1Mbps 制限) で試した時の ライセンス帯域を超える前と超えた後を比較 したグラフです。

vTM Bandwidth Graph

vTM Admin UI : ライセンス帯域を越えると制限がかかる

DNS だったり、Radius のように、割とリクエストが多く、TCP に比べてパケット量が小さい UDP サービス用としては、Mbps ライセンスでも良いかなと思います。

将来的に間違いなく LB の需要が増えそうだったら Gbps ライセンスを検討してください。 (特に、コンテンツ配信サービス)

学習は必要ですが、基本的にはポチポチやるだけなので、本当に楽でした。

プチ情報として、この vTM が色んな会社に買収されたり、製品名もコロコロ変わったりしています。

1995年に設立された Zeus Technology が 2004年にリリースしたロードバランサ製品 Zeus Traffic Manager (2006年には、Zeus Traffic Manager VA リリース) を 2011年に Riverbed Technology 社が買収し、さらに 2015年に Brocade が Riverbed 社の SteelApp 事業を買収するなど。

  • 1995年 Zeus 社 設立
  • 2004年 Zeus 社 : Zeus Traffic Manager リリース
  • 2006年 Zeus 社 : Zeus Traffic Manager Virtual Appliance リリース
  • 2011年 Riverbed 社 : Zeus 社を買収Stingray Traffic Manager から SteelApp Traffic Manager へ名称変更
  • 2015年 Brocade 社 : Riverbed 社の SteelApp 事業を買収Virtual Traffic Manager へ名称変更
  • 2017年 Pulse Secure 社 : Brocade 社の仮想 ADC 事業を買収Virtual Traffic Manager そのまま
  • 等々

以上、仮想ロードバランサ Virtual Traffic Manager とは でした。