ネットワーク NSX Advanced Load Balancer NSX Data Center

VMware がお届けする、伸び縮みするロードバランサーとは？

2025年までには楽になろう…

VMwareがお届けする、伸び縮みするロードバランサーとは？

無駄を削減してきた歴史

若い時分の連れがコンビニでバイトをしていて、そこの休憩所がちょっとしたたまり場になっていた時期があります。表から見るコンビニの仕事とは別の目線で裏側を見せていただくと（当時は）日々大量の品が賞味期限切れで廃棄されており、飽食日本の病巣を垣間見た感じがしたものです。そのときのトラウマからか、未だにスーパーで見切り品のかごを見つけると、あまり欲しくない品でもつい購入してしまいます。当時と比べると流石に少しは薄給度合いが改善してるにも関わらず、結局は貧乏性が抜けないと嫁から哀れな目で蔑まれております…
さて、私の貧乏性はさておき、おそらくIT産業において最も徹底的に無駄を削減し、Green ITやカーボンニュートラルに貢献してきたのが、我々 VMware です。vSphere によるサーバーの仮想化、vSAN を元にした HCI、NSX によるネットワークの仮想化、どれも導入に関わる CAPEX だけでなく、運用にまつわる OPEX の削減効果も相当なものです。ここでいう OPEX とは管理者の方々が如何に日々楽に安全に作業ができるかというベクトルも当然ありますが、加えて電力や空力といった部分も馬鹿になりません。今回はこの無駄の削減を更に推し進めるべく、究極の節約志向カンパニーである VMware がお届けする、NSX Advanced Load Balancer の”Elasticity”＝伸縮性の仕組みについてご紹介します。

※ NSX Advanced Load Balancer とは中央集中管理を行う Controller から分散配備された Service Engine と呼ばれるロードバランサーの実態を管理することによりマルチクラウド環境におけるアプリケーションデリバリーを効率的に行える次世代のロードバランサーソリューションです。もしまだご存知無いという方は、こちらでも紹介しているのでぜひご参照ください。
https://juku-jp.vmware.com/solutions/nsx-advanced-load-balancer/


ロードバランサーにおける無駄

ロードバランサーの主な仕事は、一言で表現するとアプリケーションの拡張性と耐障害性を担うことです。アプリケーションの耐障害性を担っているネットワークデバイスであるロードバランサー自体に耐障害性がないとお話になりませんので、世の商用環境においてはほぼ 100％、冗長化構成でデプロイされています。

ただしこのロードバランサーの冗長構成、ロードバランサーが「アプライアンス」として作られてきた長い歴史を反映しており、現在はそれがハードウェアアプライアンスのロードバランサーであろうと、仮想アプライアンスの仮想版ロードバランサーであろうと、Active/Standby という非常に無駄が多い前世代形のデザインで構成されることが一般的です。Standby デバイスとはその名の通り、Active 側のデバイスに障害が起きるまでは Idle で動作し、仕事を受け渡されるまでの間待機しています。また、Active 側もピークトラフィックを想定して通常状態では処理可能容量における 10−20％ くらいの力で動作するよう設計することが多いのではないでしょうか。つまりはこれ、10−20％ の通常運転に対して 200％ 分の投資をしていることを意味します。

また、多少の規模のシステムになってくると 1 ペアの Active/Standby のロードバランサーの冗長構成だけでシステム全体を担うよりも各サービスや管理ドメイン毎にこの Active/Standby のペアを複数配備することも一般的です。そこで想像してみてほしいのですが、複数あるロードバランサーの冗長ペアのうちの 1 セットが支えるサービスに急激なアクセス需要が起こり、システム的な負荷がかかったとします。その場合、システム内の多数の冗長ペアは引き続き 10−20％ という低い負荷で動いて余裕があるにも関わらず、その急激な負荷がかかっている特定のロードバランサーを救ってあげることが出来ません。できることといえば、その1ペアのフォークリフトアップグレードを重いメンテナンスコストを掛けて実施するプランをたてることくらいでしょうか…

このようにレガシーなアプライアンスを生まれの元とするロードバランサーの冗長構成にはとかく無駄がつきまといます。

 

スケールアウトとスケールインを実現する NSX Advanced Load Balancer の Elastic HA（Active/Active）構成

旧来のロードバランサーで一般的に行われている非効率的な冗長デザインを刷新すべく市場に投入されたのがVMwareが提供するNSX Advanced Load Balancerです。その最大の特徴はレガシーな Active/Standby の冗長構成を取れることはもちろん、より効率的な冗長手法として Elastic HA と呼ばれる Active/Active 構成をとることで、サービス稼働中にシステムに対してロードバランサーとしてのパワーをスケールアウト/スケールインできることにあります。

この機構を利用することで、システム拡張に対して必要に応じてロードバランサーのキャパシティをインサービスで拡張し、仮に拡張したリソースが必要なくなったならば、そのタイミングでキャパシティを縮退することも可能です。つまりこのロードバランサーの“伸び・縮み”によって、必要なキャパシティを必要なときに、必要な場所に必要な分だけ割り当てる、要らなくなったら回収する、という考えで無駄のないデザインを提供することができるようになります。

また、耐障害性の観点でも、Active/Standby 構成にて単一障害が発生すると二重障害を考慮して即座に復旧オペレーションを求められることになると思いますが、複数インスタンスを並列で Active/Active として利用できる Elastic HA では運用上余裕を持って対処することが可能となります。更にオーケストレータとの API 連携をセットしておけばセルフヒーリングによる自動復旧まで提供可能なので Elastic HA は旧来の Active/Standby 構成に比べて基本的にいい事づくめのお勧め構成となります。

ちなみにここでご紹介している”スケールアウト”、とは、仮想アプライアンスへのvCPUとメモリーの増強によって行う“スケールアップ”とは意味が異なります。仮想アプライアンスであれば一般的に実現可能なスケールアップは、NSX Advanced Load Balancer でも当然対応可能でその効果のほどはこちらを参考にしていただければと思いますが、

NSX Advanced Load Balancer Performance Datasheet
https://avinetworks.com/docs/21.1/nsx-alb-performance-datasheet/

本 Blog では、NSX Advanced Load Balancer だけが提供可能なユニーク機能である、スケールアウト構成にフォーカスして解説をさせていただきます。

 

NSX Advanced Load Balancer におけるスケールアウトの種類

先にお伝えしたとおり、ロードバランサーのキャパシティをインサービスで自由に変更することができる NSX NSX Advanced Load Balancer のスケールアウトアーキテクチャですが、その実現方法には主に以下の2つの手法があり、メリットとデメリットを正しく理解してどちらを利用するか判断する必要があります。

 

 

 

 

 

 

 

 

・L2スケールアウト（Native スケールアウト）
トランザクションを複数の Service Engine (SE) 間で分散処理するために、Primary SE がクライアントからのリクエストを他のメンバー SE へ L2 で転送してロードバランサーとしての負荷を分散させる方式。NSX Advanced Load Balancer だけで完結させることができる手法である一方、Primary SE のL2転送負荷の都合もあり 1 つの Virtual Service を大規模にスケールアウトしたい場合には向かない方式となります。

 

 

 

 

 

 

 

 

 

 

・L3スケールアウト（ ECMP スケールアウト）
トランザクションを複数の Service Engine 間で分散処理するために、Virtual Service への VIP（Virtual IP）を上位ルーターへ BGP を介して伝播させる方式。L2 スケールアウトと比較すると 1 つの Virtual Serivce を大規模にスケールアウトすることが可能ですが、SE を並列処理させるための分散は上位ルーターの Equal Cost Multi Path（ECMP）構成に依存するため外部ルーティングデバイスとの連携デザインが必要となります。

このようにどちらのスケールアウト方式にもそれぞれメリット、デメリットが存在しますので要件に応じて使い分けていただくことが大切です。それではそれぞれの方式をもう少し細かく解説します。

 

L2 スケールアウトの動作概要

SE をスケールアウトする際に L2 の転送方式を利用する L2 スケールアウトには、Virtual Service 毎に “Primary SE” が選定され、この Primary SE がリクエストをメンバー SE に L2 で転送する役割を担います。この Primary SE に処理を割り振られる側の SE メンバーのことを、“Secondary SE” といいます。Secondary という名前がついてはいますが、これは便宜上の名称で、2 台めの SE メンバーも、3台めの SE メンバーも Primary SE 以外は同じく Secondary SE という名称で呼ばれます。

Primary SE と Secondary SE の動作概要は以下ような形となります。

＃Standalone 構成の動作の場合
（わかりやすくするために以下は Elastic HA N+0 = 冗長なし、の構成から解説しています。）

1 台のロードバランサーが処理を行っています。

 

 

 

 

 

 

 

この状態から、スケールアウトを実行すると、、、

＃Primary SE の動作

 

 

 

 

 

 

 

 

①　Primary SE はロードバランサーとしての処理を行いつつ、一部のトランザクションを Secondary SE へと Dispach する役割としても稼働します。

②これにより一部のトランザクションは、送信先の Mac アドレスの書き換えが行われ、L2 で Secondary SE へと転送されます。

＃Secondary SE の動作

 

 

 

 

 

 

 

③Primary SE から L2 転送されたトランザクションを Secondary SE が受け付けます。このとき TCP ハンドシェイク、SSL オフロード、ロードバランシングアルゴリズムに則ったバランシングとフォワーディングなど、ロードバランサーとして必要とされる一通りの処理を Secondary SE が実施します。

④サーバーからのレスポンスは、Primary SE を介すことなく、Secondary SE が直接クライアント側に返答します。

上記①〜④の仕組みによりロードバランサーとしての処理負荷を並列処理することができ、これにより耐障害性と同時にスケーラビリティを向上した L2 スケールアウトが実現します。

L2 スケールアウトの場合は、Primary SE の Dispatcher 負荷を考慮し Virtual Service 毎に最大で 4つのService Engine まで、という拡張数を推奨値としています。つまり最大構成ではこのような形となります。

 

 

 

 

 

 

 

 

よく誤解されるのですが、この最大 4 Service Engine までというのはあくまで ”Virtual Service 毎” という点にご留意ください。Service Engine Group としては最大 1000 まで拡張することができますので、現実的にはこのような形でシステムワイドの拡張性を期待していただくことが可能です。

 

L3 スケールアウトの動作概要

L2 構成内で気軽にスケールアウトできるメリットの反面、Virtual Service 毎のスケールアウトにはある程度の上限があるのが前述の L2 スケールアウトとなります。一方、多少の構成調整を前提として大規模にVirtual Service を拡張することができるのが L3 スケールアウト構成のメリットです。

L3 スケールアウトを行う場合は、ロードバランサーの上位にあるルーターとBGPによるルート交換を行う設定を実施していただくことが前提のデザインになります。

＃L3 スケールアウトの構成概念

L3 スケールアウトを構成するには、上位のルーティングデバイスと Service Engine の間で BGP のコネクションをセットアップします。BGP によるルート交換ができるようになると、Service Eingine は Virtual Service を構成する Virtual IP を上位ルーターに伝播します。図にある通り上位ルーターは、Virtual IP（この例では 10.0.0.1 ）に対するネクストホップを Service Engine の IP 宛としてクライアントからのトランザクションを転送します。

＃L3 スケールアウト時の動作

この状態で Virtual Service をスケールアウトしたとします。すると上位ルーターのルーティングテーブルはこのようになります。Virtual IP である 10.0.0.1 へのネクストホップがスケールアウトされた Service Engine への BGP Neighbor 数だけ増えることになります。上位ルーターは一般的にハッシュに基づいたネクストホップへの転送バランシングを行いますのでこの仕組を利用して Virtual Service の拡張がActive/Active の Service Engine により構成されます。

L3 スケールアウトでは、1 つの Virtual Service 毎に最大 64 までの Service Engine 拡張をサポートしているので（ ECMP の最大値が 64 以上サポートされている上位ルーティングデバイスであることが前提）、L2 スケールアウトよりも大規模な構成で使っていただけるデザインの選択肢となります。

 

L3 スケールアウトの派生系、NSX-T連携

ここまで読んで頂いた方の中にはもしかしたら、L3 スケールアウトのメリットを外部ルーティングデバイスとの BGP 連携なしに手に入れられないものか？と思われる読者もおられるかもしれません。そんな方におすすめしたいのが、NSX-T 連携構成となります。こちらはその名の通り、NSX-T DataCenter をご利用頂いていることが条件にはなりますが、より気軽に L3 スケールアウトを構成することが可能となっています。

こちらは BGP ではなく、Static Route を利用した ECMP による L3 スケールアウトとなっており、連携に必要とされるすべての設定事項は NSX Advanced Load Balancer と NSX-T の API 連携により自動化されているため、感覚としては L2 スケールアウトと同様に小難しい事前調整を必要とすることなく気軽にスケールアウト・スケールインのメリットを享受してもらうことが可能です。

NSX-T と NSX Advanced Load Balancer の連携構成については過去 Blog でも記載しておりますのでこちらもご参照ください。

 

まとめ

アプリケーションをデリバリーするに際して、その可用性と拡張性を担うロードバランサーの役割は日に日に大きくなっており、さらに昨今ではマルチクラウド化への対応が求められています。NSX-T Data Center にも仮想ロードバランサー機能は存在していましたが、ロードバランサーへの期待値の高まりから VMware は新しく NSX Advanced Load Balancer をラインナップに加えることとなりました。今回はその NSX Advanced Load Balancer の最大の特徴の一つである伸縮性 = Elastic HA にスポットライトを当ててご紹介させていただきました。

お客さまとお話をしていると、スケールアップとスケールアウト、どちらの方向性にも伸縮が可能な NSX Advanced Load Balancer において、システムの拡張を検討する際にまずはどちらを検討するのが良いのか？という議論になることがあります。

私個人的には、システムのキャパシティをある程度専有することを前提としたスケールアップよりも、まずはスケールアウトを検討いただき、その上限に至って更に拡張が必要であればその段でスケールアップをご検討頂いてはいかがですか？とガイドしておりましたが、この度、弊社販売パートナーであるネットワンシステムズ様にご協力いただき、そのあたりを実証して確認することを目的とした検証を行っていただき、そのレポートをベースに Blog 化して共有いただきました。

ナレッジセンター | Net One BLOG
VMware NSX Advanced Load Balancerのパフォーマンス計測を実施してみた結果と得られた知見

外資ベンダーのしがない一支店でしかない VMware ジャパンでは到底買い揃えることが出来ない高価なL7負荷装置によりがっちりとした検証を行っていただいた末の見解は必見です。
多大なるご協力を頂いたネットワンシステムズ新林様にはこの場を持ちまして改めて感謝の意を表明させていただきます。ありがとうございました。

ということで、今回はロードバランサーの伸縮性ということで NSX Advanced Load Balancer のロードバランサー機能のスケールアウトについてのご紹介をさせていただきました。アプリケーションの伸縮性という意味では、NSX Advanced Load Balancer には実はもう一つのベクトル、バックエンドサーバ−の伸縮性、という機能も有しています。この辺はまた別途機会があれば解説させていただきますのでお楽しみに。

関連記事