【BIG-IP】VMware Workstation Proでロードバランサーの検証環境を構築する Part 15：Virtual Serverの作成とHTTP負荷分散設定

Posted at 2026-11-12

はじめに

本記事では、VMware Workstation Pro上に構築したBIG-IP Virtual Edition（BIG-IP VE）を使用して、HTTPロードバランシングを実現する方法を解説します。

今回の目的は、以下の2点です。

VMware Workstation Pro上にBIG-IPのActive/Standby冗長構成を構築する。
BIG-IPを経由して複数のリアルサーバにアクセスし、負荷分散とセッション維持を実現する。

本記事では、ロードバランサーの中核機能となる**Virtual Server（仮想サーバ）**を作成します。

Virtual Serverの設定には、Node、Pool、Monitor、SNAT、各種Profileなど、多くのオブジェクトが関係します。

それぞれの役割と関係を整理しながら、GUIによる設定手順を解説します。

1. 検証環境の構成

1.1 構成図

今回の環境では、BIG-IPを経由して2台のZabbixサーバへHTTPアクセスを分散します。

BIG-IPにはRoute Domain ID 10を設定しており、対象のIPアドレスには %10 を付与します。

1.2 検証要件

項目	設定値
ロードバランサー	BIG-IP VE
冗長構成	Active/Standby
Route Domain ID	10
Virtual Server	192.168.1.1%10
サービスポート	TCP/80（HTTP）
Node 1	zabbix-01：172.16.4.81%10
Node 2	zabbix-02：172.16.4.82%10
負荷分散方式	Round Robin
HTTPヘルスチェック	使用
X-Forwarded-For	有効
Persistence	HTTP Cookie Insert
SNATアドレス	192.168.2.1%10
iRules	使用しない

本記事では、前回までの手順に従ってVLAN、Self IP、Route Domain、Routing、冗長化の設定が完了しているものとします。

なお、VIP、SNATアドレス、リアルサーバ間の通信には、それぞれ適切なルーティング設定が必要です。

1.3 BIG-IPの主要オブジェクト

BIG-IPによる負荷分散を理解するうえで、次のオブジェクトの役割を押さえておく必要があります。

オブジェクト	役割
Virtual Server	クライアントからの通信を受け付ける仮想サーバ
Node	負荷分散先となるリアルサーバ
Pool Member	Nodeとサービスポートを組み合わせたもの
Pool	複数のPool Memberをグループ化する
Monitor	NodeやPool Memberの稼働状態を監視する
SNAT Pool	送信元IPアドレスの変換先を定義する
TCP Profile	TCP通信の動作を制御する
HTTP Profile	HTTP通信の処理方法を制御する
Persistence Profile	同一クライアントの接続先を維持する

今回の構成では、以下のような流れで通信が処理されます。

クライアントがVirtual ServerのIPアドレスにアクセスする。
BIG-IPがVirtual Serverに設定されたPoolを参照する。
Poolの負荷分散方式に従って、利用可能なPool Memberを選択する。
BIG-IPが必要なIPアドレス変換を行い、選択したリアルサーバに通信を転送する。
リアルサーバからの応答をBIG-IPが処理し、クライアントへ返す。

また、Cookie Persistenceを利用することで、同一クライアントからの後続リクエストを、原則として同じPool Memberに転送します。

2. BIG-IPのGUI表示設定

まず、GUIの表示設定を変更します。

管理GUIにログインし、以下のメニューを開きます。

System > Preferences

次の項目を変更します。

設定項目	設定値	目的
Records Per Screen	1000	一度に表示するオブジェクト数を増やす
Idle Time Before Automatic Logout	86400	自動ログアウトまでの時間を延長する

Records Per Screenを変更すると、多数のオブジェクトを一覧で確認しやすくなります。

また、Idle Time Before Automatic Logoutは秒単位で指定します。

今回の設定値である86400秒は24時間です。

ただし、管理GUIのセッションを長時間維持することはセキュリティリスクにつながります。

本設定は検証環境向けです。本番環境では組織のセキュリティポリシーに従い、適切なタイムアウト値を設定してください。

3. HTTP Monitorの作成

最初に、リアルサーバの稼働状態を監視するHTTP Monitorを作成します。

3.1 Monitorとは

Monitorは、BIG-IPから監視対象に対して定期的に通信を行い、サービスが正常に稼働しているかを確認する機能です。

代表的なMonitorには、以下があります。

Monitor	監視内容
gateway_icmp	ICMPによるIP到達性
TCP	TCPポートへの接続可否
HTTP	HTTPリクエストに対する応答
HTTPS	HTTPSリクエストに対する応答

今回の環境ではHTTP Monitorを使用して、ZabbixのWebサービスを監視します。

3.2 Monitorの作成手順

以下のメニューを開きます。

Local Traffic > Monitors

画面右上のCreateをクリックします。

設定値は以下のとおりです。

項目	設定値
Name	monitor-http
Type	HTTP
Parent Monitor	http
Interval	5
Timeout	16
Alias Service Port	80

Parent Monitorには、標準で用意されているhttpを指定します。

Parent Monitorを指定すると、親Monitorの設定を継承できます。

3.3 HTTP Monitorの詳細設定

元の検証環境では、ZabbixのDashboardに対してHTTP GETリクエストを送信する設定としています。

項目	元記事の設定値
Send String	`GET /zabbix.php?action=dashboard.view&dashboardid=1\r\n`
Receive String	`200`
User Name	Admin
Password	zabbix（検証用）
Interval	5
Timeout	16
Alias Service Port	80

それぞれの項目の役割は以下のとおりです。

Interval

Monitorによるヘルスチェックを実行する間隔です。

今回は5秒ごとにHTTPリクエストを送信します。

Timeout

監視対象をDownと判定するまでのタイムアウト値です。

今回は16秒に設定します。

Send String

監視対象に送信するHTTPリクエストです。

Receive String

応答データ内で照合する文字列または正規表現です。

Alias Service Port

監視対象のサービスポートです。

今回はHTTPを使用するため、TCP/80を指定します。

3.4 HTTP Monitorの注意点

ここで注意したいのが、HTTPステータスコードの判定方法です。

元の設定ではReceive Stringに200を指定していますが、単に200を指定しただけでは、HTTPステータスコード200を厳密に判定しているとは限りません。

BIG-IPのHTTP Monitorは、Send StringにHTTPバージョンが指定されているかどうかによって、応答の評価方法が異なります。

例えば、HTTP/1.1で監視する場合は、次の形式を使用します。

GET /health HTTP/1.1\r\nHost: zabbix.example.local\r\nConnection: close\r\n\r\n

これは/healthというヘルスチェック用エンドポイントが存在する場合の例です。

HTTP/1.1ではHostヘッダと、ヘッダ終端を示す\r\n\r\nが必要です。

また、ZabbixのDashboardは、バージョンや認証設定によってログインを要求したり、別のページへリダイレクトしたりする場合があります。

HTTP MonitorのUser NameおよびPasswordによる認証設定も、ZabbixのWebログイン認証をそのまま代行できるとは限りません。

そのため、実運用では認証なしでHTTP 200を返す専用のヘルスチェックURLを用意することを推奨します。

今回は元の検証設定を掲載していますが、監視対象のHTTP応答を確認したうえで設定してください。

4. Nodeの作成

続いて、負荷分散先となるリアルサーバをNodeとして登録します。

4.1 Nodeとは

Nodeは、BIG-IPが管理するリアルサーバを表すオブジェクトです。

基本的にIPアドレス単位で管理します。

今回の構成では、以下の2台を登録します。

Node	IPアドレス
zabbix-01	172.16.4.81%10
zabbix-02	172.16.4.82%10

4.2 Nodeの作成手順

次のメニューを開きます。

Local Traffic > Nodes

画面右上のCreateをクリックします。

1台目の設定は以下のとおりです。

項目	設定値
Name	172.16.4.81%10
Description	zabbix-01
Address	172.16.4.81%10
Health Monitors	Node Specific
Select Monitors	gateway_icmp

今回はRoute Domain IDとして10を使用しています。

そのため、NodeのIPアドレスには%10を付与しています。

例えば、以下の表記です。

172.16.4.81%10

%10はRoute Domain IDを意味します。

BIG-IPのRoute Domainは、異なるルーティング空間を分離して管理するための機能です。

Ciscoなどのネットワーク機器で使用するVRFに近い概念ですが、実装や管理方式は異なります。

今回はNodeの疎通監視としてgateway_icmpを使用します。

これにより、Nodeに対するICMPの到達性を確認できます。

同様の手順で、2台目も作成します。

項目	設定値
Name	172.16.4.82%10
Description	zabbix-02
Address	172.16.4.82%10
Health Monitors	Node Specific
Select Monitors	gateway_icmp

4.3 Nodeの状態確認

Nodeを作成したら、一覧画面に2台が表示されていることを確認します。

Local Traffic > Nodes

両方のNodeでAvailabilityが正常であることを確認してください。

ただし、ICMPによる監視が成功しても、HTTPサービスが正常であるとは限りません。

そのため、次の手順でPool MemberにHTTP Monitorを適用します。

5. Poolの作成

5.1 Poolとは

Poolは、複数のPool Memberをグループ化し、負荷分散先として管理するためのオブジェクトです。

Pool Memberは、Nodeとサービスポートの組み合わせです。

今回の構成では、以下のPool Memberを登録します。

POOL
 ├── 172.16.4.81%10:80  (zabbix-01)
 └── 172.16.4.82%10:80  (zabbix-02)

いずれもTCP/80でWebサービスを提供します。

5.2 Poolの作成手順

次のメニューを開きます。

Local Traffic > Pools

右上のCreateをクリックします。

設定値は以下のとおりです。

項目	設定値
Name	POOL
Description	zabbix
Health Monitors	monitor-http
Load Balancing Method	Round Robin

Health Monitorsには、先ほど作成したmonitor-httpを指定します。

これにより、Pool Memberに対するHTTPヘルスチェックを実施できます。

5.3 Pool Memberの追加

New Membersでは、作成済みのNodeをPoolに追加します。

Node Listから対象のNodeを選択し、Service Portに80を指定します。

設定するPool Memberは以下の2つです。

Node	Service Port
172.16.4.81%10	80
172.16.4.82%10	80

それぞれAddをクリックして追加します。

5.4 負荷分散方式について

今回はRound Robinを使用します。

Round Robinは、新規接続をPool Memberに順番に割り当てる負荷分散方式です。

BIG-IPではほかにも、Least ConnectionsやRatioなど、さまざまなアルゴリズムを利用できます。

なお、後述するCookie Persistenceが有効な場合、同一クライアントの後続リクエストは原則として同じPool Memberに振り分けられるため、毎回Round Robinで振り分けられるわけではありません。

5.5 Poolの状態確認

Poolを作成したら、次の画面を開きます。

Local Traffic > Pools > POOL

Availabilityが正常であることを確認します。

Pool Memberが緑色の状態であれば、設定されたMonitorによって利用可能と判定されています。

もしDownになっている場合は、以下を確認します。

NodeへのIP到達性
HTTPサービスの稼働状態
TCP/80の待ち受け
HTTP MonitorのSend StringとReceive String
サーバ側の認証・リダイレクト設定
Route Domainおよびルーティング設定

6. SNAT Poolの作成

次に、送信元IPアドレスを変換するためのSNAT Poolを作成します。

6.1 SNATとは

SNAT（Secure Network Address Translation）は、BIG-IPが転送する通信の送信元IPアドレスを変換する機能です。

今回の構成では、リアルサーバに転送する通信の送信元IPアドレスを次のアドレスに変換します。

192.168.2.1%10

SNATを利用すると、リアルサーバからの応答をBIG-IP経由で戻す構成を実現できます。

ただし、SNATアドレスの到達性や経路設定が適切であることが前提です。

6.2 SNAT Poolの作成手順

以下のメニューを開きます。

Local Traffic > Address Translation > SNAT Pool List

右上のCreateをクリックします。

設定は以下のとおりです。

項目	設定値
Name	192.168.2.1%10
IP Address	192.168.2.1%10

IP Addressを入力したらAddをクリックします。

その後、SNAT Poolを作成します。

7. TCP Profileの確認

続いて、TCP Profileを確認します。

7.1 TCP Profileとは

TCP Profileは、BIG-IPが扱うTCP通信の動作を制御するための設定です。

次のメニューを開きます。

Local Traffic > Profiles > Protocol > TCP

今回は検証環境のため、標準のtcpプロファイルを使用します。

TCP Profileには、接続タイムアウト、輻輳制御、TCPオプションなど、多数の設定項目があります。

7.2 Idle Timeout

Idle Timeoutは、一定時間通信が発生しなかったTCP接続をアイドル状態とみなし、削除対象とするまでの時間です。

アプリケーションの仕様や通信特性によって、調整が必要になることがあります。

例えば、長時間接続を維持するアプリケーションでは、タイムアウト値が短すぎると意図しない切断が発生する可能性があります。

一方、値を大きくしすぎると不要な接続が長時間残り、リソースを消費する場合があります。

7.3 TCP Fast Open

TCP Fast Open（TFO）は、特定の条件下でTCP接続確立時の遅延を削減する技術です。

BIG-IPでは、バージョンやプロファイルによってTCP Fast Openに関する設定を確認できます。

ただし、有効・無効の初期値は製品バージョンやプロファイルに依存するため、実環境の設定を確認してください。

7.4 Delayed ACK

Delayed ACKは、TCP ACKの送信を短時間遅延させ、通信効率を改善するための仕組みです。

アプリケーションの通信パターンによっては、遅延特性に影響を与えることがあります。

ただし、性能向上を目的として一律に無効化することは推奨できません。

変更する場合は、通信特性やベンチマーク結果を踏まえて判断する必要があります。

7.5 Nagle's Algorithm

Nagle's Algorithmは、小さなTCPセグメントの送信を抑制し、ネットワーク利用効率を向上させる仕組みです。

小さなデータを頻繁に送受信するアプリケーションでは、遅延に影響する可能性があります。

ただし、無効化が常に性能改善につながるわけではありません。

7.6 Congestion Control

Congestion Controlでは、TCPの輻輳制御に関する設定を確認できます。

関連する技術には、以下があります。

Slow Start
Congestion Avoidance
Explicit Congestion Notification（ECN）

BIG-IPのバージョンやTCP Profileによって利用可能な機能が異なります。

今回の検証では、TCP Profileの設定変更は行いません。

8. HTTP Profileの設定

8.1 HTTP Profileとは

HTTP Profileは、BIG-IPがHTTP通信を解析・処理するための設定です。

次のメニューを開きます。

Local Traffic > Profiles > Services > HTTP

標準のhttpプロファイルを確認します。

今回は、クライアントのIPアドレスをリアルサーバに通知するため、X-Forwarded-Forを使用します。

8.2 X-Forwarded-Forとは

X-Forwarded-For（XFF）は、HTTPヘッダにクライアントのIPアドレス情報を付与するために使用されます。

BIG-IPでSNATを行う場合、リアルサーバから見るIPヘッダ上の送信元アドレスは、SNAT後のアドレスになります。

今回の構成では、以下のアドレスです。

192.168.2.1

この状態では、リアルサーバ側のアクセスログなどで元のクライアントIPアドレスを判別できなくなる場合があります。

X-Forwarded-Forを利用すると、HTTPヘッダを通じて元のクライアントIPアドレスを伝えることができます。

ただし、XFFはHTTPヘッダであり、クライアントによって偽装される可能性があります。

アプリケーションでXFFを信頼する場合は、信頼できるプロキシやBIG-IPから付与された情報だけを使用するよう設計してください。

8.3 X-Forwarded-Forの有効化

元の検証記事では、標準のhttpプロファイルを使用しています。

ただし、標準プロファイルを直接変更すると、同じプロファイルを利用する別のVirtual Serverにも設定が影響する可能性があります。

そのため、実際の構築では、標準のhttpを継承した専用プロファイルを作成する方法を推奨します。

Local Traffic > Profiles > Services > HTTP

Createをクリックし、以下のように設定します。

項目	設定値
Name	http-xff
Parent Profile	http
Insert X-Forwarded-For	Enabled

作成したhttp-xffを、後述するVirtual Serverに適用します。

8.4 その他のHTTP設定

HTTP Profileには、ほかにも以下の設定があります。

項目	内容
Enforcement	HTTPメッセージの処理・検査に関する設定
sFlow	トラフィック統計の収集
HTTP Strict Transport Security	HTTPSの利用をブラウザに指示するための設定

今回は基本的に標準設定を使用します。

なお、HTTP Strict Transport Security（HSTS）はHTTPSに関連するセキュリティ機能です。

今回のVirtual ServerはHTTP（TCP/80）を使用するため、HSTSの設定は行いません。

本番環境でHTTPSを使用する場合は、TLS証明書、HTTPSリダイレクト、HSTSポリシーなどを含めて設計する必要があります。

9. Persistence Profileの確認

9.1 Persistenceとは

Persistenceは、同一クライアントからの後続リクエストを、できる限り同じPool Memberに転送するための機能です。

Webアプリケーションでは、セッション情報を特定のサーバが保持している構成があります。

この場合、リクエストごとに接続先が変わると、ログイン状態やセッション情報を維持できなくなる可能性があります。

Persistenceを使用すると、このような問題を軽減できます。

9.2 Cookie Persistence

今回は、HTTP Cookie Insert方式を使用します。

次のメニューを開きます。

Local Traffic > Profiles > Persistence

標準のcookieプロファイルを確認します。

項目	設定値
Profile	cookie
Cookie Method	HTTP Cookie Insert

HTTP Cookie Insert方式では、BIG-IPがCookieを発行し、接続先のPool Memberを識別するために利用します。

基本的な動作は以下のとおりです。

クライアントが初めてVirtual Serverへアクセスする。
BIG-IPが負荷分散アルゴリズムに従いPool Memberを選択する。
BIG-IPがレスポンスにPersistence用のCookieを挿入する。
クライアントが次回アクセスする際にCookieを送信する。
BIG-IPがCookieを参照し、対応するPool Memberへ通信を転送する。

これにより、同一クライアントの通信を継続的に同じサーバへ割り当てられます。

ただし、Pool MemberがDownした場合などは、別のサーバへ振り分けられる場合があります。

9.3 Cookieのセキュリティ属性

Cookieには、代表的なセキュリティ属性として以下があります。

属性	概要
HttpOnly	JavaScriptなどからのCookieアクセスを制限する
Secure	原則としてHTTPS通信でのみCookieを送信する
SameSite	クロスサイトリクエスト時のCookie送信を制御する

これらの設定は、アプリケーションのセキュリティに関係します。

今回の検証環境はHTTP通信を使用しているため、Secure属性を付与すると、ブラウザがPersistence用CookieをHTTPで送信せず、セッション維持が機能しない可能性があります。

Cookieの各属性は、使用するBIG-IPのバージョン、Persistence Profileの設定、HTTP/HTTPS構成を踏まえて確認してください。

なお、今回の検証では、専用のPersistence Profileは作成せず、標準のcookieを使用します。

10. Virtual Serverの作成

これまでに作成・確認したオブジェクトを組み合わせて、Virtual Serverを作成します。

10.1 Virtual Serverとは

Virtual Serverは、BIG-IPがクライアントからの通信を受け付ける論理的なサーバです。

一般的に、Virtual Serverには以下の設定を関連付けます。

Virtual IPアドレスとサービスポート
Pool
TCP Profile
HTTP Profile
Persistence Profile
SNAT
VLANおよびTunnel

今回作成するVirtual Serverは、次のアドレスでHTTP通信を受け付けます。

192.168.1.1%10:80

10.2 Virtual Serverの基本設定

以下のメニューを開きます。

Local Traffic > Virtual Servers

右上のCreateをクリックします。

設定値は以下のとおりです。

項目	設定値
Name	Virtual-Server
Description	zabbix
Source Address	0.0.0.0%10/0
Destination Address/Mask	192.168.1.1%10
Service Port	80
Protocol	TCP

Source Addressの0.0.0.0%10/0は、Route Domain ID 10におけるIPv4送信元アドレスを制限しない設定です。

Destination Address/Maskには、Virtual ServerのIPアドレスである192.168.1.1%10を指定します。

※元記事のスクリーンショットにはDestination Addressの誤記がありますが、本稿では正しい設定値を記載しています。

10.3 TCP・HTTP Profileの設定

次に、Protocol Profileを指定します。

項目	設定値
Protocol	TCP
TCP Profile（Client/Server）	tcp
HTTP Profile（Client）	http-xff

今回、TCP Profileには標準のtcpを使用します。

HTTP Profileには、先ほど作成したhttp-xffを指定します。

元記事の設定をそのまま再現する場合は、標準のhttpプロファイルでXFFを有効にしていることを確認し、httpを選択します。

10.4 SSL Profileについて

BIG-IPには、主に以下のSSL Profileがあります。

Profile	役割
Client SSL	クライアントとBIG-IP間のTLS通信
Server SSL	BIG-IPとリアルサーバ間のTLS通信

例えば、以下の構成が考えられます。

SSL Offloading

Client --- HTTPS ---> BIG-IP --- HTTP ---> Server

BIG-IPでTLS通信を終端し、リアルサーバとはHTTPで通信する構成です。

SSL Bridging

Client --- HTTPS ---> BIG-IP --- HTTPS ---> Server

BIG-IPでクライアント側のTLS通信を終端し、リアルサーバ側に新たなTLS接続を確立する構成です。

今回の検証ではHTTP通信のみを使用するため、Client SSL ProfileおよびServer SSL Profileは指定しません。

10.5 VLAN and Tunnel Trafficの設定

次に、Virtual Serverが通信を受け付けるVLANを設定します。

項目	設定値
VLAN and Tunnel Traffic	Enabled on
VLANs and Tunnels	External、Internal

今回の構成では、ExternalとInternalを選択します。

元の検証環境では、これらのVLANに以下のネットワークを割り当てています。

VLAN	ネットワーク
External	172.16.2.0/24
Internal	172.16.3.0/24

Enabled onは、選択したVLANまたはTunnelからVirtual Serverへの着信を許可する設定です。

設定したVLANが、そのままリアルサーバへの転送経路を決定するわけではありません。

また、Virtual ServerのIPアドレスがVLANのネットワークアドレス範囲外にある場合でも、適切なルーティングやARPなどの設定があれば、通信を実現できる構成があります。

本番環境では、不必要なVLANからVirtual Serverにアクセスできないよう、受信を許可するVLANを適切に制限してください。

10.6 SNATの設定

次に、Source Address Translationを設定します。

項目	設定値
Source Address Translation	SNAT
SNAT Pool	192.168.2.1%10

先ほど作成したSNAT Poolを指定します。

これにより、BIG-IPからPool Memberに転送される通信の送信元IPアドレスが、指定したSNATアドレスに変換されます。

10.7 Resourceの設定

最後に、Virtual ServerのResourceを設定します。

項目	設定値
Default Pool	POOL
Default Persistence Profile	cookie

Default Poolには、作成したPOOLを指定します。

Default Persistence Profileには、標準のcookieを指定します。

これにより、Virtual Serverにアクセスしたクライアントの通信は、Poolに登録された2台のZabbixサーバへ分散されます。

また、Cookie Persistenceが適用されることで、同一クライアントからの後続リクエストを同じPool Memberに転送できます。

今回は検証用途のため、以下の追加設定は行いません。

iRules
Local Traffic Policies
Fallback Persistence Profile

設定が完了したら、Finishedをクリックします。

11. Virtual Serverの状態確認

Virtual Serverの作成後、次のメニューを開きます。

Local Traffic > Virtual Servers

作成したVirtual-Serverを確認します。

Availabilityが緑色の正常状態であることを確認してください。

ただし、Virtual Serverが正常であっても、クライアントからの通信が必ず成功するとは限りません。

以下の観点でも確認する必要があります。

確認対象	確認内容
Virtual Server	正常状態か
Pool	有効なPool Memberが存在するか
Node	IP到達性が確保されているか
HTTP Monitor	HTTP応答が想定どおりか
Routing	クライアント・サーバ双方の経路が成立しているか
SNAT	送信元アドレス変換が正しく行われているか
Persistence	Cookieが発行・送信されているか

特に、Virtual ServerのAvailabilityが正常でも、ルーティングの問題でアクセスできないケースがあります。

GUI上のステータスだけでなく、実際のHTTP通信による確認が必要です。

12. Active/Standby構成への設定反映

今回のBIG-IPは、Active/Standby構成です。

Device Groupが正しく構成されている場合、ConfigSyncによって設定をもう一方のBIG-IPに反映できます。

ただし、自動同期が有効かどうかはDevice Groupの設定に依存します。

そのため、設定完了後は以下を確認してください。

BIG-IPの冗長構成が正常であること。
ConfigSyncの状態が正常であること。
必要に応じて設定同期を実行すること。
Standby側にもVirtual Server、Poolなどの設定が反映されていること。
Virtual AddressやSNATのTraffic Groupが適切に設定されていること。

設定が同期されているだけでは、フェイルオーバー後の通信継続が保証されるわけではありません。

最終的には、Active/Standbyの切り替えを含めた通信試験を行う必要があります。

13. まとめ

今回は、BIG-IP LTMでHTTPロードバランシングを実現するために、以下の設定を行いました。

設定対象	オブジェクト
HTTP Monitor	monitor-http
Node 1	zabbix-01
Node 2	zabbix-02
Pool	POOL
SNAT Pool	192.168.2.1%10
TCP Profile	tcp
HTTP Profile	http-xff
Persistence Profile	cookie
Virtual Server	Virtual-Server

今回の構成では、Round Robinによる負荷分散、HTTP Monitorによるヘルスチェック、X-Forwarded-ForによるクライアントIPアドレスの通知、Cookie Persistenceによるセッション維持、SNATによる送信元IPアドレス変換を組み合わせています。

これらは、BIG-IP LTMによる負荷分散を理解するうえで基本となる機能です。

次回は、検証用端末を準備してVirtual Server経由のHTTP通信を確認します。

また、実際にPool Memberへの振り分けやCookie Persistenceがどのように動作するのかを確認します。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up