BIG-IP VE の Active/Standby 構成 – ConfigSync、Failover、Traffic Group の役割

BIG-IP Virtual Edition（BIG-IP VE）を 2 台構成にすると、Active/Standby の冗長構成を作ることができます。ただし、BIG-IP の HA は「2 台を並べれば片方が壊れても自動で動く」という単純なものではありません。

ConfigSync、Failover Network、Mirroring、Device Trust、Device Group、Traffic Group、Floating IP がそれぞれ別の役割を持っています。ここを分けて理解しないと、設定は入っているのに同期されない、Failover しない、Floating IP が移動しない、セッションが引き継がれない、といった切り分けが難しくなります。

この記事では、BIG-IP VE の Active/Standby 構成を、手順そのものよりも「何を冗長化しているのか」「どの機能が何を担当しているのか」という観点で整理します。tmsh のコマンド例は検証用の例であり、実環境では管理 IP、Self IP、VLAN、証明書、通信許可、ライセンス条件を自分の設計に合わせて読み替えてください。

Active/Standby は何を冗長化する構成なのか

BIG-IP の Active/Standby 構成では、2 台の BIG-IP が同じ設定を持ち、通常時は片方が Traffic Group を保持します。障害時には Standby 側が Traffic Group を引き継ぎ、Floating IP などの共有リソースを保持する側が切り替わります。

ここで重要なのは、冗長化されるものと、冗長化されないものを分けることです。設定は ConfigSync で同期できますが、すべての実行状態が自動的に同じになるわけではありません。Traffic Group に属する Floating IP は移動しますが、個別の管理 IP やローカルな状態は各デバイスに残ります。

ConfigSync と Failover を混同しない

BIG-IP HA でまず分けるべきなのは、ConfigSync と Failover です。ConfigSync は設定を同期する仕組みです。一方で Failover は、Active 側で障害が起きた時に Standby 側へ Traffic Group を移す仕組みです。

この 2 つは関連しますが、同じではありません。設定が In Sync になっていても、Failover Network の通信や監視条件が正しくなければ、期待通りに切り替わりません。逆に、Failover の通信が成立していても、設定が同期されていなければ、切り替わった後のサービス構成が一致しません。

HA 用 Self IP を設計する

BIG-IP VE では、管理 IP、データ通信用 Self IP、HA 用 Self IP を分けて考えた方が安全です。管理 IP は GUI や SSH の管理に使います。データ通信用 Self IP は VLAN 上の BIG-IP 自身のアドレスです。HA 用 Self IP は、ConfigSync、Failover Network、Mirroring など、BIG-IP 間通信に使うアドレスです。

検証環境では 1 つのネットワークに寄せても動くことがあります。しかし、設計としては、どの通信がどのインターフェースと VLAN を通るのかを明確にしておくべきです。特にクラウド上の BIG-IP VE や仮想化基盤上の BIG-IP VE では、NSG、セキュリティグループ、分散ファイアウォール、仮想スイッチの制約も関係します。

基本的な tmsh 設定例

以下は検証環境で流れを確認するための例です。IP アドレス、デバイス名、VLAN 名、パスワードは環境に合わせて変更します。実運用では変更前に UCS バックアップや設定差分の確認を行ってください。

tmsh

まず、Device Trust や Device Group で識別しやすいように、デバイス名を整えます。

mv cm device bigip1 bigip-1.example.com
show cm device

mv cm device bigip1 bigip-2.example.com
show cm device

次に、ConfigSync、Failover Network、Mirroring に使う IP を設定します。ここでは HA 用 Self IP を使う前提です。

modify cm device bigip-1.example.com configsync-ip 10.0.36.112
modify cm device bigip-1.example.com unicast-address { { ip 10.0.36.112 } }
modify cm device bigip-1.example.com mirror-ip 10.0.36.112
show cm device

modify cm device bigip-2.example.com configsync-ip 10.0.36.113
modify cm device bigip-2.example.com unicast-address { { ip 10.0.36.113 } }
modify cm device bigip-2.example.com mirror-ip 10.0.36.113
show cm device

Device Trust と Device Group を作る

BIG-IP 同士を HA 構成に入れるには、Device Trust が必要です。Device Trust は、BIG-IP 同士が証明書ベースで信頼関係を持つための前提です。

検証では専用ユーザーを作って使うことがありますが、実運用では権限、パスワード管理、監査ログ、作業後の扱いを決めておく必要があります。記事や構成管理の公開領域に実パスワードを残してはいけません。

create auth user ha password <HA_PASSWORD> partition-access add { all-partitions { role admin } }
list auth user ha

片方の BIG-IP から対向 BIG-IP を Device Trust に追加します。

modify cm trust-domain Root add-device { ca-device true device-ip 10.0.36.113 device-name bigip-2.example.com username ha password <HA_PASSWORD> }
show cm device

Device Trust が成立したら、Sync-Failover 用の Device Group を作成します。Device Group は、どの BIG-IP を同期と Failover の対象にするかを決める単位です。

create cm device-group device-group-1 devices add { bigip-1.example.com bigip-2.example.com } type sync-failover network-failover enabled
show cm device-group

初回同期と Traffic Group を確認する

Device Group を作ったら、Active 側から初回同期を行います。ここで In Sync になることを確認します。

run cm config-sync to-group device-group-1
show cm sync-status

Color green
Status In Sync

次に見るべきなのが Traffic Group です。Active/Standby で実際に移動するのは、Traffic Group に属するリソースです。Floating IP や Virtual Server など、どのリソースをどの Traffic Group に所属させるかが、Failover 時の動作を決めます。

show cm traffic-group

Floating IP は Active 側へ移動する共有 IP である

Floating IP は、Traffic Group に属し、Active 側の BIG-IP が保持する共有 IP アドレスです。Cisco の HSRP や VRRP の仮想 IP に近いものとして考えると理解しやすいですが、BIG-IP では Traffic Group との関係で見る必要があります。

個別 Self IP は各デバイスに残ります。一方で Floating IP は Traffic Group と一緒に Active 側へ移動します。サーバー側のデフォルトゲートウェイとして使う場合や、Virtual Server の周辺設計で使う場合は、どの IP が固定で、どの IP が移動するのかを明確にしておく必要があります。

create net self external-ipv4-fip address 10.0.34.114/24 vlan external traffic-group traffic-group-1
create net self internal-ipv4-fip address 10.0.35.114/24 vlan internal traffic-group traffic-group-1
run cm config-sync to-group device-group-1

Failover テストで見ること

設定が入ったら、単に In Sync で終わらせず、Failover 時に何が移動するかを確認します。ここで見るべきなのは、管理 IP へログインできるかではなく、Traffic Group、Floating IP、Virtual Server、接続中セッション、監視結果が設計通りに動くかです。

特に BIG-IP VE では、仮想化基盤やクラウド側のネットワーク仕様が Failover に影響します。Floating IP を持ち替えても、周辺の仮想ネットワークが MAC アドレスや ARP の変化をどう扱うかによって、期待通りに通信が戻らないことがあります。BIG-IP だけでなく、下位のネットワーク基盤も含めて確認する必要があります。

保存と運用上の注意

検証後は設定を保存します。変更前後の差分と UCS バックアップも残しておくと、切り戻しや再現確認がしやすくなります。

save sys config
quit

Active/Standby 構成は、作った時点で終わりではありません。証明書更新、ライセンス更新、Virtual Server 追加、Pool 変更、Monitor 変更、iRule 変更など、日常的な変更が HA 構成にどう影響するかを運用手順に含める必要があります。

まとめ

BIG-IP VE の Active/Standby 構成では、ConfigSync、Failover Network、Mirroring、Device Trust、Device Group、Traffic Group を分けて理解することが重要です。これらはすべて HA に関係しますが、同じ役割ではありません。

ConfigSync は設定同期、Failover Network は切り替え、Mirroring はセッション情報、Device Trust は信頼関係、Device Group は同期と Failover の対象、Traffic Group は移動するリソースの単位です。Floating IP は Traffic Group に属し、Active 側へ移動する共有 IP として扱います。

したがって、BIG-IP の冗長構成を確認するときは、単に 2 台が見えているか、In Sync かだけで判断しない方がよいです。どのリソースが同期され、どのリソースが移動し、どの通信が HA を支えているのかを分けて見ることで、障害時の挙動を設計として説明できるようになります。

参考情報

関連する記事

関連記事

BIG-IP Virtual Edition のネットワーク設定 – VLAN / Self IP / Route を構成する BIG-IP Virtual Edition 検証ガイド – F5 VE を構成する流れ BIG-IP Virtual Edition のライセンス認証 – F5 VE を検証環境で有効化する BIG-IP Virtual Edition の基本設定 – 管理 IP / ホスト名 / DNS / NTP を整える F5 BIG-IP iRule を使うべき場面 – 標準機能とコード責任の境界を考える BIG-IP Virtual Edition を KVM にデプロイする – QCOW2 と virt-install で検証環境を作る