FortiGate HA の設定と確認コマンド｜Active-Passive の冗長化とフェイルオーバー

URLをコピーしました！

はじめに

ネットワークダウンタイムは業務への影響が大きいため、冗長化による可用性確保が重要です。本記事では、FortiGate（FortiOS v7.4 / v7.6 対応）における High Availability（HA: 高可用性）の仕組みと、最も一般的な Active-Passive 構成の設定手順・確認コマンド・プライマリ選定ロジックまでを実務目線で解説します。

この記事でわかること

FortiGate HA（高可用性）の仕組みとメリット
Active-Active と Active-Passive の違いと選定基準
GUI と CLI による Active-Passive 構成の設定手順
セッション同期（session-pickup）の設定と制約
実運用で使える HA 確認コマンド 12 種
プライマリ選定ロジック（Monitor ポート・Age Time・Priority・Serial）
HA 構成の制約事項とトラブルシューティング

HA（High Availability）とは

機器の故障などの障害発生時に、自動的に予備機へ切り替えることで通信断を最小限に抑える仕組みです。FortiGate で HA を組む主なメリットは以下のとおりです。

HA の主なメリット

① ダウンタイムの最小化
障害発生時に自動でフェイルオーバーします。デフォルト設定での設計上のフェイルオーバー時間は 約 2 秒、実運用では 9〜15 秒程度で収束するのが一般的です。Subsecond failover を有効化することで 1 秒未満の切替も実現可能です。

② セッション同期（session-pickup）
session-pickup を有効化することで、TCP セッションの状態が Secondary 機に同期され、フェイルオーバー時の再接続を最小限に抑えられます。ただしデフォルトでは無効のため、必要に応じて明示的に有効化することを推奨します（後述の設定手順参照）

③ 一元管理
設定変更は Primary 機に対して行うだけで、Secondary 機へ自動同期されます（一部の機器固有設定を除く）

参考: Fortinet Community「HA session failover (session pickup)」
“If session pickup is not enabled, all sessions are briefly interrupted after a device or link failover, and must be re-established at the application level after the cluster renegotiates.”
（session-pickup が有効でない場合、デバイスまたはリンクのフェイルオーバー後、すべてのセッションは一時的に中断され、クラスタの再ネゴシエーション後にアプリケーションレベルで再確立される必要があります。）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-HA-session-failover-session-pickup/ta-p/191165

Active-Active と Active-Passive の違い

FortiGate の HA には 2 つのモードがありますが、一般的な用途では Active-Passive が推奨されます。両者の違いを以下の比較表で整理します。

項目	Active-Passive（推奨）	Active-Active
動作イメージ	1 台が稼働、もう 1 台は待機	2 台とも稼働
リソース使用効率	待機機のリソースは未使用	2 台のリソースを分散利用
設定・運用の複雑度	シンプル（トラブルが少ない）	複雑（セッション同期の負荷など考慮が必要）
UTM 処理	Primary のみ処理	両方で分散処理が可能
セッション同期	session-pickup で対応	必須（常時同期）
FortiCare / FortiGuard ライセンス	2 台分必要	2 台分必要
実運用での採用率	高い（大半の事例）	限定的（UTM 処理の負荷分散目的が中心）
トラブルシューティング	容易（挙動が明確）	難易度が高い

Active-Active は高性能に見えますが、トラブルシューティングの難易度が高く、UTM 機能を使わない場合は負荷分散の効果も限定的です。まずは Active-Passive 構成での設計が推奨されます。

HA 設定手順（Active-Passive）

FortiGate の HA は GUI と CLI のどちらからも設定可能です。以下、両方の手順を解説します。

構成イメージ

本記事の設定例は、以下の構成を前提としています。

Primary 機： Priority 200、Active として稼働
Secondary 機： Priority 100、Passive として待機
Heartbeat インターフェース： ha1ha2（冗長化）
Monitor 対象： internal1wan1
HA Reserved Management Interface： mgmt ポート

GUI での設定手順

FortiOS 7.4 / 7.6 では、System > HA から HA 設定を行えます。

STEP

HA 設定画面へ移動

GUI ログイン後、左メニューから 「System（システム）」 > 「HA」 を選択します。

STEP

Primary 機の基本設定

以下の項目を入力します。

項目	推奨設定	備考
Mode	Active-Passive
Device priority	200	Primary 側は高い値
Group name	`fw-ha`	両機で同一
Password	任意のパスワード	両機で同一。HA グループの識別に利用
Heartbeat interfaces	`ha1ha2`	2 本以上の冗長化を推奨
Monitor interfaces	`internal1wan1`	リンクダウン監視対象
Management Interface Reservation	有効	Secondary への直接アクセス経路を確保
Management interface	`mgmt`

STEP

設定の保存

「OK」 をクリックして設定を保存します。設定反映時に、FortiGate はクラスタ形成のためインターフェースの MAC アドレスを変更するため、一時的に GUI 接続が切断される場合があります。

STEP

Secondary 機の設定

Secondary 機を工場出荷状態にリセットした後、STEP 1〜3 を繰り返します。ただし、Device priority は 100 など低い値を設定します。その他の設定（Mode、Group name、Password、Heartbeat interfaces 等）はPrimary と同一の値にする必要があります。

CLI での設定手順

CLI で設定する場合、Primary 機と Secondary 機それぞれに以下のコマンドを投入します。

Primary 機（Active）

config system ha
    set group-name "fw-ha"
    set group-id 1
    set mode a-p
    set password ENC **********       ! HA グループ識別用パスワード（両機で同一）
    set hbdev "ha1" 10 "ha2" 20       ! Heartbeat インターフェース（冗長化）
    set override disable              ! プリエンプト無効（安定重視）
    set priority 200                  ! Primary 側は高い値
    set monitor "internal1" "wan1"    ! リンクダウン監視対象
    set session-pickup enable         ! TCP セッション同期を有効化
    set session-pickup-connectionless enable   ! UDP / ICMP セッション同期
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt"
            set gateway 192.168.100.1
        next
    end
end

Secondary 機（Passive）

config system ha
    set group-name "fw-ha"
    set group-id 1
    set mode a-p
    set password ENC **********       ! Primary と同一の値
    set hbdev "ha1" 10 "ha2" 20       ! Primary と同一
    set override disable
    set priority 100                  ! Secondary 側は低い値
    set monitor "internal1" "wan1"    ! Primary と同一
    set session-pickup enable
    set session-pickup-connectionless enable
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt"
            set gateway 192.168.100.1
        next
    end
end

参考: Fortinet 公式「HA active-passive cluster setup」（FortiOS 7.6.6 Administration Guide）
“Except for the device priority, these settings must be the same on all FortiGates in the cluster.”
（デバイスプライオリティを除き、これらの設定はクラスタ内のすべての FortiGate で同一である必要があります。）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/900885/ha-active-passive-cluster-setup

パラメータの解説

set group-name
HA グループの名前です。両機で同一の値を設定する必要があります。

set group-id
HA グループ ID（数値）です。同一 L2 セグメントに複数の HA クラスタが存在する場合、異なる ID を割り当てる必要があります。

set mode a-p
動作モードを指定します（a-p = Active-Passive、a-a = Active-Active）

set password
HA グループ識別用のパスワードです。両機で同一の値を設定します。異なる HA グループとの誤接続を防ぎます。

set hbdev
HA の Heartbeat をやり取りするインターフェースを指定します。2 本以上の冗長化を推奨します。末尾の数値は優先度（値が大きいほど優先）です。

set override disable
自動切り戻し（プリエンプト）の設定です。

disable（推奨）： 障害復旧しても自動的に Active へ復帰しません（安定重視）
enable： Priority が高い機器が復旧すると、即座に Active としての動作に復帰します。

set priority
優先度です。数字が大きいほうが Active になります（例：主 = 200、副 = 100）

set monitor
リンクダウンを監視するポートです。監視対象のポートが切れるとフェイルオーバーが発動します。

set session-pickup enable（追加推奨）
デフォルトでは無効。有効化することで、TCP セッションの状態が Secondary 機に同期されます。フェイルオーバー時の再接続を最小限に抑えられます。

set session-pickup-connectionless enable（追加推奨）
UDP / ICMP のような コネクションレス通信のセッション同期を有効化します。session-pickup enable が前提です。

set ha-mgmt-status enable / config ha-mgmt-interfaces
HA Reserved Management Interface（予約管理インターフェース）の設定です。有効化することで Secondary 機にも個別の管理 IP が割り当てられ、GUI / SSH で直接アクセスできます。

確認コマンド

設定投入後、以下のコマンドで HA の稼働状態と同期状況を確認します。実務で頻繁に使う 12 種を整理します。

① 基本ステータス確認

get system ha status

HA の全体的なステータスを確認します。最もよく使う基本コマンドです。

FGT # get system ha status
HA Health Status: OK
Model: FortiGate-xxx
Mode: HA A-P
Group Name: fw-ha
Group ID: 1
Debug: 0
Cluster Uptime: 10 days 2:34:56
...
Master      :xxx.xxx.xxx.xxx, FGT-PRIMARY, cluster index = 0
Slave       :yyy.yyy.yyy.yyy, FGT-SECONDARY, cluster index = 1

get system ha

現在の HA 設定内容を確認します。ステータスではなく「どう設定されているか」を見るコマンドです。

FGT # get system ha
group-id            : 1
group-name          : fw-ha
mode                : a-p
...

② 詳細ステータス・選定理由の確認

diagnose sys ha status

クラスタの詳細な状態と、どの機器が Master に選ばれた理由を確認できます。トラブルシューティング時に有用です。

FGT # diagnose sys ha status
HA information
Statistics
    traffic.local = s:0 p:0 b:0
    traffic.total = s:0 p:0 b:0
...
HA group member information: is_manage_master=1.
FGTxxxxx: Master, serialno_prio=0, usr_priority=200, hostname=FGT-PRIMARY
FGTyyyyy: Slave, serialno_prio=1, usr_priority=100, hostname=FGT-SECONDARY
<xxxx/xx/xx xx:xx:xx> FGTxxxxx is selected as the master because it has the largest value of override priority.

③ 設定同期状態の確認（チェックサム）

diagnose sys ha checksum cluster

クラスタ全体の設定チェックサムを確認します。両機で値が一致していれば同期されている状態です。

FGT # diagnose sys ha checksum cluster
================== FGTxxxxx ==================
is_manage_master()=1, is_root_master()=1
debugzone
global: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
root: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
all: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
...
================== FGTyyyyy ==================
（同じチェックサムが表示されれば同期済み）

diagnose sys ha checksum show global

グローバル設定の詳細チェックサムを確認します。クラスタ間で不一致が疑われる場合の詳細調査に使います。

diagnose sys ha checksum show <vdom>

VDOM 単位のチェックサムを確認します。VDOM 構成時の同期状態確認に使います。

FGT # diagnose sys ha checksum show root

diagnose sys ha showcsum

設定の詳細な項目単位でチェックサムを確認できます。不一致箇所を特定する際の最終手段として利用します。

参考: Fortinet Community「Troubleshooting a checksum mismatch in a FortiGate HA cluster」
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Troubleshooting-a-checksum-mismatch-in-a/ta-p/193061

④ クラスタ操作コマンド

execute ha manage <id> <admin>

Primary 機の CLI から Secondary 機の CLI へ切替ログインします。Secondary 機に個別アクセスして設定確認・バックアップを行う際に使います。

FGT-PRIMARY # execute ha manage ?
<id>     please input peer box index.
  0.     Subsidary unit FGTyyyyy

FGT-PRIMARY # execute ha manage 0 admin

Secondary 機での個別バックアップ手順については、詳細は関連記事『FortiGate 設定ファイルのバックアップとリストアの手順と HA 構成の注意点』を参照

execute ha synchronize start

手動で HA 同期を開始します。チェックサム不一致が発生した場合の復旧手段として利用されます。

execute ha synchronize stop

実行中の同期処理を停止します。

execute ha failover enable | disable

手動でフェイルオーバーを制御します。計画メンテナンス時に Primary / Secondary を意図的に入れ替える際に利用します。

⑤ Heartbeat 通信の確認

diagnose sys ha dump-by all-vcluster

全 vcluster の詳細状態を dump します。Heartbeat 疎通を含めた深堀調査に利用します。

確認コマンドの優先順位（実務目線）

トラブル発生時は以下の順で確認することを推奨します。

get system ha status で全体状態を把握
diagnose sys ha status で Master 選定理由を確認
diagnose sys ha checksum cluster で同期状態を確認
不一致があれば diagnose sys ha checksum show <vdom> で詳細化
必要に応じて diagnose sys ha showcsum で不一致項目を特定

どちらが Active になるか（プライマリ選定ロジック）

FortiGate が Active 機（Master）を決定する優先順位は以下のとおりです。override disable（デフォルト）の場合の挙動として整理します。

STEP

Monitor ポートの Up 数

最優先の判定条件です。set monitor で監視しているポートの Up 数が多いほうが Active となります。

例：Primary 機で WAN ケーブルが抜けると、Monitor ポートの Up 数が Secondary 機を下回り、Secondary が Active に昇格します

STEP

HA 稼働時間（Age Time）

Monitor ポートの Up 数が同じ場合、HA としての稼働時間が長いほうが優先されます。

デフォルトでは「5 分以上」の差がないとこの判定はスキップされます（フラッピング防止のため）
set ha-uptime-diff-margin コマンドで閾値を変更可能

STEP

Priority（優先度設定）

Age Time の差が閾値未満の場合、設定した set priority の値が比較されます。値が大きいほうが Active となります。

例：Primary = 200、Secondary = 100 → Primary が Active

STEP

シリアルナンバー（タイブレーカー）

すべての判定条件で差がない場合（初期構築時など）、シリアルナンバーの文字列が大きいほうが Active となります。実運用でこの判定条件まで到達することは稀ですが、最終的な判定条件として用意されています。

`override enable` 時の注意点

set override enable を設定すると、上記の STEP 2（Age Time）の判定が無視されます。復旧した機器の Priority が高ければ、稼働時間に関係なく即座に Active としての動作に復帰します（切り戻りが発生）。

通信断のリスクがあるため、意図的な設計でない限りは override disable（無効）が推奨されます。

Heartbeat タイマーとフェイルオーバー所要時間

HA のフェイルオーバー動作を理解する上で、Heartbeat の挙動とタイマーの把握は重要です。

Heartbeat の仕組み

HA クラスタの全メンバーは、Heartbeat 用インターフェース（hbdev で指定）を介して定期的に Heartbeat パケットを送受信しています。この通信が一定時間途絶えると、対向機がダウンしたと判定され、フェイルオーバーが発動します。

Heartbeat 通信プロトコル： TCP/703 および UDP/703
Ethernet Type： 0x8890、0x8891、0x8893
推奨構成： Heartbeat インターフェースはスイッチを介さず直結することを推奨（スイッチを経由する場合は専用 VLAN を推奨）

デフォルトタイマー値

FortiGate の Heartbeat タイマーのデフォルト値は以下のとおりです。

パラメータ	デフォルト値	説明
`hb-interval`	200 ms（2 デシ秒）	Heartbeat 送信間隔
`hb-lost-threshold`	6 回	Heartbeat ロスト閾値
障害検出時間（計算値）	約 1.2 秒（200ms × 6）	Heartbeat が届かなくなってから障害と判定されるまでの時間

フェイルオーバー所要時間の目安

公式情報に基づくフェイルオーバー所要時間の設計値と実運用値は以下のとおりです。

条件	所要時間の目安	備考
デバイスフェイルオーバー（設計値）	約 2 秒	2 台クラスタ、理想的なネットワーク条件
デバイスフェイルオーバー（実運用の一般値)	9〜15 秒	ネットワーク構成・スイッチの挙動により変動
Subsecond failover 有効時	1 秒未満	Hello 100 ms、Lost threshold 5 回の設定が推奨

参考: Fortinet 公式「Failover performance」
“By design FGCP device failover time is 2 seconds for a two-member cluster with ideal network and traffic conditions. If subsecond failover is enabled the failover time can drop below 1 second.”
（設計上、FGCP のデバイスフェイルオーバー時間は 2 台クラスタかつ理想的なネットワーク条件下で 2 秒です。Subsecond failover が有効な場合、フェイルオーバー時間は 1 秒未満に短縮できます。）
https://www.fortinetguru.com/2016/10/failover-performance/

タイマー変更のコマンド例

フェイルオーバー時間をさらに短縮したい場合、以下のコマンドでタイマーを調整できます。

config system ha
    set hb-interval 1                 ! 100 ms（単位は deciseconds、1 = 100ms）
    set hb-lost-threshold 5           ! 5 回
end

タイマーチューニングの注意点

タイマーを短くしすぎると、ネットワークの瞬断や遅延を障害と誤検知し、意図しないフェイルオーバーが発生する可能性があります。実運用ではデフォルト値のまま運用し、明確な要件がある場合のみ調整することを推奨します。

制約事項と注意点

FortiGate HA を構成する際に留意すべき主要な制約を整理します。

制約

session-pickup の対象外セッション

session-pickup を有効化しても、以下のセッションはフェイルオーバー時に引き継がれず、再接続が必要です。

IPsec VPN
SSL VPN
明示的プロキシ（Explicit Proxy）セッション
クラスタ自身が終端するセッション： GUI（HTTPS）、SSH、SNMP、syslog 等の管理系通信
proxy-based セキュリティプロファイルで検査されるセッション

flow-based セキュリティプロファイルで検査されるセッションは session-pickup の対象ですが、フェイルオーバー後は検査処理が継続されない制約があります。

制約

ハードウェア・ファームウェアの同一性要件

HA を組む両機体は、原則として以下がすべて一致している必要があります。

同一モデル（例：FortiGate 60F × 2 台）
同一ハードウェアリビジョン
同一 FortiOS バージョン

ISSU（In-Service Software Upgrade）による一時的なバージョン混在は許容されますが、長期運用では揃えることが推奨されます。

制約

FortiCare / FortiGuard サブスクリプション

HA クラスタ内の全機体にそれぞれ FortiCare / FortiGuard サブスクリプションが必要です。Active-Passive 構成であっても、Passive 側機体の契約を省略することはできません。ライセンス費用の試算時には 2 台分を前提とする必要があります。

制約

MAC アドレスの変更

HA クラスタ形成時、FGCP（FortiGate Clustering Protocol）は仮想 MAC アドレスをインターフェースに割り当てます。このため、HA 有効化の瞬間に上流・下流のスイッチの MAC テーブルが更新されるまで、一時的に通信断が発生する可能性があります。

制約

機器固有情報は同期されない

詳細は関連記事『FortiGate 設定ファイルのバックアップとリストアの手順と HA 構成の注意点』を参照いただきたいですが、以下の項目は HA 間で同期されないため、機体ごとに個別設定が必要です。

ホスト名（hostname）
HA プライオリティ
HA Override 設定
HA Reserved Management Interface の IP

制約

同一 L2 セグメント要件（FGCP の場合）

FGCP（通常の HA）では、クラスタメンバーが同一 L2 セグメント上に配置されている必要があります。地理的に離れた拠点間で HA を組む場合は、後述の FGSP の利用を検討することになります。

制約

ISSU 時の順序制約

ファームウェアアップグレード（ISSU）は一度に 1 台ずつ実施する必要があります。同時アップグレードはサポートされません。詳細は関連記事『FortiGate Upgrade Path Tool の使い方と HA 構成での所要時間』を参照

トラブルシューティング

HA 運用時に発生しやすい問題と、その切り分けフローを整理します。

Case

Out-of-sync（設定が同期されない）

症状： get system ha status で Sync: out of sync と表示される、または diagnose sys ha checksum cluster で両機のチェックサム値が異なる。

切り分けフロー：

! STEP 1：チェックサムを比較
FGT # diagnose sys ha checksum cluster

! STEP 2：不一致箇所を絞り込み（global / 各 VDOM のどこがズレているか）
FGT # diagnose sys ha checksum show global

! STEP 3：不一致項目の詳細を確認
FGT # diagnose sys ha showcsum

! STEP 4：手動での同期を試行
FGT # execute ha synchronize start

よくある原因：

管理者ユーザーのダッシュボード設定差分： 片方の管理者のみ追加ウィジェットを配置している等
証明書の不一致： 手動で証明書をインポートしたが片方にしか反映されていない
キャッシュオブジェクトの不整合： Secondary の再起動で解消するケースあり
バージョン差分： ISSU の途中など、一時的な混在

Case

意図しないフェイルオーバーの発生

症状： 監視していない時間帯に突然フェイルオーバーが発生し、Secondary が Active になっていた。

切り分けフロー：

! イベントログの確認
FGT # execute log filter category event
FGT # execute log display

! HA 関連ログの確認
FGT # diagnose log test
FGT # diagnose sys ha dump-by all-vcluster

よくある原因：

Monitor ポートのフラッピング： 上流スイッチ側のポート瞬断
Heartbeat の途絶： Heartbeat 用ケーブル・スイッチの障害
タイマー設定が短すぎる： hb-interval や hb-lost-threshold を調整しすぎている
override enable の設定ミス： 意図せずプリエンプトが発動

Case

Heartbeat が確立しない

症状： 両機を接続しても Master only と表示され、クラスタとして認識されない。

切り分けチェックリスト：

Heartbeat 用ケーブル・インターフェースの物理接続
両機で同一の group-name / group-id / password が設定されているか
同一モデル・同一 FortiOS バージョンか
hbdev で指定したインターフェースが両機で Up しているか
Heartbeat 用インターフェースに IP アドレスを設定していないか（HA 用 I/F は L2 レイヤのみで動作、IP 設定は不要）

Case

Secondary 機にアクセスできない

症状： Primary 機は操作可能だが、Secondary 機の状態確認や設定変更ができない。

対処方法：

execute ha manage <id> <admin> コマンドで Primary から Secondary へ切替ログイン
HA Reserved Management Interface を設定し、Secondary に個別の管理 IP を割り当てる（運用時の推奨）

Case

フェイルオーバー後に通信が復旧しない

症状： フェイルオーバーは発生したが、一部の通信が復旧しない。

よくある原因：

session-pickup 無効： TCP セッションが Secondary に同期されていない（前述の制約参照）
IPsec/SSL VPN の再接続待ち： これらは session-pickup 対象外のため、クライアント側での再接続が必要
Gratuitous ARP の到達失敗： 上流スイッチの MAC テーブル更新が遅延している
Monitor ポートの設定不足： 重要な通信経路が Monitor 対象になっていない

確認コマンドの再掲（トラブル時のクイックリファレンス）

! 全体状況の把握
get system ha status
diagnose sys ha status

! 同期状態の確認
diagnose sys ha checksum cluster
diagnose sys ha checksum show global

! 手動操作
execute ha manage <id> <admin>
execute ha synchronize start
execute ha failover enable | disable

FGCP と FGSP の使い分け

FortiGate の HA には、本記事で解説した FGCP（FortiGate Clustering Protocol） のほかに、FGSP（FortiGate Session Life Support Protocol） という別の冗長化方式もあります。両者の位置づけを整理すると、設計判断が容易になります。

FGCP が向いているケース（本記事の対象）

同一 L2 セグメントに 2 台の FortiGate を設置できる
同一データセンター内での冗長化
設定の自動同期を活用したい
シンプルな構成で運用したい

FGSP が向いているケース

地理冗長が必要（異なるデータセンター間での冗長化）
L3 経由で 2 台を接続する必要がある
同一 L2 セグメントでの配置が困難
設定の自動同期は不要で、セッション同期のみ必要

比較表

項目	FGCP（通常の HA）	FGSP
同期レイヤ	L2	L3（IP 経由）
機器配置	同一 L2 セグメント必須	任意の場所（L3 到達性のみ）
地理冗長	基本的に不向き	対応
設定の自動同期	あり	原則なし（手動管理）
セッション同期	session-pickup で対応	対応
クラスタ識別	Group Name / Group ID	Peer IP 指定
仮想 MAC	あり（FGCP が管理）	なし
運用の複雑度	低い	中〜高
推奨規模	小〜中規模、同一拠点	大規模、マルチサイト

FGSP の注意点

FGSP は強力な機能ですが、設定同期は手動または FortiManager 経由で行う必要があります。また、FGCP と FGSP を組み合わせる構成（拠点内は FGCP、拠点間は FGSP）も可能ですが、設計の複雑度が増すため、実装時は十分な検証を推奨します。

まとめ

本記事では、FortiGate（FortiOS 7.4 / 7.6）における HA の Active-Passive 構成と運用実務を解説しました。

HA は Active-Passive 構成が一般的に推奨され、設定もシンプルでトラブルシューティングも容易
session-pickup はデフォルト無効のため、TCP セッション同期が必要な場合は明示的に有効化することを推奨する。
設定は GUI / CLI のどちらからも可能で、Heartbeat インターフェースの冗長化と HA Reserved Management Interface の活用を推奨する。
プライマリ選定ロジックは Monitor ポート > Age Time > Priority > シリアルナンバー の順で判定される（override disable 時）
確認コマンド 12 種を覚えておくと、ステータス確認・同期状態の診断・トラブル切り分けを効率的に行える。
デバイスフェイルオーバー所要時間は設計値 2 秒・実運用 9〜15 秒が目安で、Subsecond failover で 1 秒未満も実現可能
地理冗長や L3 経由での冗長化が必要な場合は、FGSP の採用を検討することを推奨する。

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

とも

主にインフラを得意とするエンジニアです。日々の業務で得た実践的なノウハウや、最新の脆弱性ニュースなどを備忘録を兼ねて発信しています。
同じエンジニアの方々の課題解決のヒントになれば嬉しいです。

[ Certs ] CCIE Lifetime Emeritus / VCAP-DCA ✒️ [ Life ] 技術書・ビジネス書愛好家📖 / 小・中学校で卓球コーチ👟

FortiGate HA の設定と確認コマンド｜Active-Passive の冗長化とフェイルオーバー

はじめに

HA（High Availability）とは

HA の主なメリット

Active-Active と Active-Passive の違い

HA 設定手順（Active-Passive）

構成イメージ

GUI での設定手順

CLI での設定手順

パラメータの解説

確認コマンド

① 基本ステータス確認

② 詳細ステータス・選定理由の確認

③ 設定同期状態の確認（チェックサム）

④ クラスタ操作コマンド

⑤ Heartbeat 通信の確認

確認コマンドの優先順位（実務目線）

どちらが Active になるか（プライマリ選定ロジック）

override enable 時の注意点

Heartbeat タイマーとフェイルオーバー所要時間

Heartbeat の仕組み

デフォルトタイマー値

フェイルオーバー所要時間の目安

タイマー変更のコマンド例

タイマーチューニングの注意点

制約事項と注意点

session-pickup の対象外セッション

ハードウェア・ファームウェアの同一性要件

FortiCare / FortiGuard サブスクリプション

MAC アドレスの変更

機器固有情報は同期されない

同一 L2 セグメント要件（FGCP の場合）

ISSU 時の順序制約

トラブルシューティング

確認コマンドの再掲（トラブル時のクイックリファレンス）

FGCP と FGSP の使い分け

FGCP が向いているケース（本記事の対象）

FGSP が向いているケース

比較表

FGSP の注意点

まとめ

この記事を書いた人

`override enable` 時の注意点