今日ほどビジネスにおいて、アプリケーションの重要性が高まったことはありません。アプリケーションがいつでも快適に、そして安全に使えるように、陰で支えているのがロードバランサーです。ロードバランサーを運用しているとき、最も面倒で、できれば避けたいのがアップグレード（バージョンアップ）作業ではないでしょうか。従来のアップグレードの問題点をあぶり出し、VMware が提供するNSX Advanced Load Balancer の驚くほど簡単にアップグレードできる仕組みを紹介したいと思います。
ロードバランサーのアップグレードが必要な背景
そもそもなぜロードバランサーのアップグレードが必要なのでしょうか。主な理由としては、脆弱性やバグに伴うソフトウェアの改修、新機能の利用、EoSL 対応などが挙げられます。ユーザとアプリケーションの間に位置するロードバランサーは、常に安定稼働が求められます。ソフトウェアの不具合によって、サービスが停止するような事態は決して許されません。そのためにも、ソフトウェアを適切なバージョンにアップグレードすることは、避けて通れないのではないでしょうか。
ここで一つ海外の事例を紹介したいと思います。ソフトウェアの不具合に対処するため、数百台のロードバランサーをアップグレードするプロジェクトが走っていました。メンテナンスウィンドウを設けながら、数か月にわたって、少しずつアップグレード作業を実施していたようです。あと少しでプロジェクトが終わろうとしていた矢先に、今度はソフトウェアの脆弱性の問題が発覚し、再度数百台のアップグレードが必要になったという、本当に笑えない話が現実的に起きています。この事例から分かるように、ロードバランサーのアップグレード作業は、運用担当者の時間と労力を浪費します。いかにアップグレード作業を効率化し、上手に付き合っていく方法を見出せるかが、運用チームの生産性に大きく影響します。
従来のアップグレード方法の問題点
では従来のアップグレード方法の問題点について考えてみましょう。
・運用者が手動で行う操作が多いため、時間がかかり、作業ミスも起きやすい
Active-Standby構成を基本とする従来のロードバランサーでは、①Standby機をアップグレード、②切り替え、③旧Active機をアップグレード、④切り戻し、のような手順を踏んでいたと思います。一連の作業の中で、機器の各種ステータスを確認しながら、慎重に行う必要がありました。このような手順では、運用者の負担が大きく、作業ミスも起きやすいといえます。
・複数のロードバランサーを運用している場合、１台ずつ作業するのは時間と労力がいる
ロードバランサーが複数のシステムで運用されていることも珍しくありません。さらに、オンプレミスだけでなく、パブリッククラウドで運用されていることも増えてきました。管理対象のロードバランサーの数が増えれば、当然アップグレード作業に要する時間と労力も増えます。
・アップグレード作業中はサービス影響を伴う
アップグレード作業中は、Active/Standbyの機器の切り替えが発生します。その際、既存セッションが切断されるため、サービス影響は避けられません。アプリケーションやLOB の担当者と、作業日時を事前に調整する必要があります。
以上のとおり、従来のアップグレード方法にはさまざまな課題があり、運用担当者の悩みの種でした。
NSX Advanced Load Balancer の革新的アップグレード
VMware が提供するNSX Advanced Load Balancer では、革新的な方法でアップグレード作業を効率化し、運用担当者の時間と労力を節約します。具体的には、以下のように従来のアップグレード方法の課題を解決します。
・アップグレード作業の大部分を自動化
・複数のロードバランサーを一括でアップグレード
・アップグレード中のサービス影響を極力排除
このようなアップグレードを実現できる秘密は、ロードバランサーのアーキテクチャにあります。NSX Advanced Load Balancer は、マルチクラウド対応の完全ソフトウェア型ロードバランサーであり、コントロールプレーンとデータプレーンが分離されています。コントロールプレーン（Controller）は、統合管理・分析可視化・オーケストレータとしての役割を担います。データプレーン（Service Engine）は、ロードバランサーの実体として、サーバ負荷分散やGSLB、WAF などの機能を提供します。このアーキテクチャのメリットとしては、単一のコントローラからすべてのロードバランサーを集中制御できることが挙げられます。また、ロードバランサーを柔軟にスケールアウト・スケールインできるため、トラフィックを適切に制御し、アップグレード中のサービス影響を極力排除することができます。
NSX Advanced Load Balancer のアップグレード方法
それではNSX Advanced Load Balancer のアップグレード方法について、順を追って説明します。今回は分かりやすいように、GUI を使った方法を紹介します。もちろん、CLI やAPI を使っても、同様のことが行えます。
【Version 20.1.2 → 20.1.3へアップグレード】
①コントローラにイメージファイルをアップロード
コントローラにログイン後、[Administration] – [Controller] – [Software] に移動し、[Upload From Computer] をクリックしてイメージファイルをアップロードします。
イメージファイルをアップロードできたことを確認します。
②アップグレードを実行
アップグレードの対象範囲をきめ細かく指定することもできます。たとえば、コントローラのみ、あるいは特定のテナントやシステムのロードバランサー群（Service Engine Group）のみをアップグレードすることも可能です。こちらの例では、システム全体（コントローラとすべてのService Engine Group）をアップグレードしたいと思います。
[Administration] – [Controller] – [System Update] に移動し、イメージファイルを選択してから[UPGRADE] をクリックします。
必要に応じて、アップグレードするService Engine Group の指定やアップグレードが失敗した場合の振る舞いを変更することができます。今回はデフォルトの設定で実施します。[Continue] をクリックします。
まずはコントローラのアップグレードが開始させます。コントローラのアップグレード中は設定変更を行えませんが、ロードバランサーのサービスに影響はありません。
コントローラのアップグレードが完了すると、いよいよロードバランサーの実体であるService Engine のアップグレードが開始されます。Service Engine Group 単位でローリングアップデート方式のアップグレードが実行されます。たとえば、同じService Engine Group に2つのService Engine が稼働している場合、１つずつ順番にアップグレードしていきます。アップグレード中のService Engine はサービスを停止しますが、もう片方のService Engine はサービスを継続します。
アップグレード中の状況を確認するため、管理PCで以下のコマンドを実行
- Service Engine1 (172.16.130.131) に対してping を実行
- Service Engine2 (172.16.130.132) に対してping を実行
- HTTP Virtual Service (VIP: 172.16.130.104) に対してhttping を実行
しばらくすると…
すべてのService Engine のアップグレードが完了した時点で、HTTP Virtual ServiceのVIP に対するhttping が失敗した数はゼロでした。
コントローラのアップグレードが正常に完了していることを確認します。
Service Engine Group のアップグレードも正常に完了していることを確認します。
以上、NSX Advanced Load Balancer のアップグレード方法の紹介でした。
【補足1】ロールバックの方法について
アップグレード完了後、何か問題が発生した場合は、元のバージョンへ速やかにロールバックすることも可能です。ロールバックの対象範囲をきめ細かく指定することもできます。たとえば、特定のサービスのみで不具合が見つかった場合、そのService Engine Group のみをロールバックするようなイメージです。
【補足2】長時間存続するセッションの扱いについて
今回はhttping を利用して、1秒ごとにGET リクエストを送信する方法で、アップグレード時のサービス影響を検証しました。WEB サービスによっては、大容量ファイルをダウンロードするような通信もあるかもしれません。いわゆる長時間存続するセッションを救済するためには、「アップグレード中のサービスを極力排除」のスライドに説明があるように、既存セッションが終わるのを待たせるためにタイマを設定してアップグレードする方法が有効です。具体的には、Service Engine Group の 「vs_scalein_timeout_for_upgrade」 設定をデフォルトの30秒から任意の値に変更します。たとえば3,600秒に変更した場合、Service Engine は60分間待機してからアップグレードを実行します。その間にすべてのセッションが終了することを期待します。60分経過後は、セッションが残っている場合でも、アップグレードは強行されます。
vs_scalein_timeout_for_upgrade (optional)
Integer During SE upgrade, Time to wait for the scaled-in SE to drain existing flows before marking the scalein done. format: int32
https://avinetworks.com/docs/20.1/api-guide/ServiceEngineGroup/index.html
一見すると便利なパラメータですが、アップグレードに要する時間が増えるため注意が必要です。たとえば、２つのService Engine が稼働している構成でタイマを60分に設定した場合、両方のアップグレードが完了するまで120分＋αの時間が必要になります。
まとめ
NSX Advanced Load Balancer のアップグレード方法はいかがでしたか。仮に複数のデータセンターやパブリッククラウドにわたってロードバランサーが数百台規模で展開されている場合でも、「①コントローラにイメージファイルをアップロード」、「②アップグレードを実行」の２ステップだけで、すべてのアップグレード作業が自動化されます。暴論かもしれませんが、日中の時間帯にサクッとアップグレードできるかもしれませんね。ロードバランサーの運用を圧倒的に効率化できる次世代ロードバランサーをぜひお試しください。
〜お知らせ〜
※VMwareでは、各種製品をクラウド上でご評価いただくHands-on Labs（HOL） という仕組みを無償でご提供しています。
今回ご紹介した各種ソリューションへの最初の一歩の入り口としてぜひご活用ください。
おすすめのHOLメニューはこちらから
- VMware NSX Advanced Load Balancer (Avi Networks) – Getting Started (HOL-2237-01-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) – Global Server Load Balancing (HOL-2237-02-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) Web Application Security (HOL-2237-03-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) with Kubernetes (HOL-2237-04-NET)
- VMware NSX Advanced Load Balancer (Avi Networks) Lightning Lab (HOL-2237-91-ISM)
