FortiGate設定マニュアル - HA徹底入門
【第4回】HAの同期と切り替え

FortiGateの「HA(High Availability)」は、単に2台の機器で構成を組めば完成、というものではありません。機器間で設定やセッション情報が正しく同期されて、初めて障害発生時のスムーズな切り替えが実現します。本ブログでは、HAを安定運用させるために欠かせない「同期」と「切り替え」の仕組みから、セッション管理のノウハウまでを分かりやすく解説します。

2026年3月時点でのSCSKの推奨バージョンFortiOS v7.4系を前提としています。

FGCPで同期されないシステム情報

HAを構成すると、ほとんどのシステム情報がプライマリから同期されますが、全てが同期されるわけではなく、一部例外があります。同期されない情報は下記の通りです。これらの情報は同期されると運用上、支障が起きるため、同期の対象からは外されています。

同期されないシステム情報
  • FortiGateのホスト名
  • FortiGate内部に記録されるログ
  • ライセンス情報(ただし、機器に登録されているFortiTokenの情報は同期される)
  • WebGUIのダッシュボードとウィジェット
  • HAのオーバーライド設定
  • HAのデバイスの優先度(プライオリティ値)
  • バーチャルクラスタの優先度(プライオリティ値)
  • 「管理インターフェースの予約」のインターフェース
  • 「管理インターフェースの予約」のゲートウェイ
  • インバンドIPアドレス(トラフィック用のインターフェースに、HA用のIPを追加する方法)

チェックサムから分かる同期の完了

プライマリ機とセカンダリ機の両方でチェックサムを表示するコマンドを実行して、同期が正しく行われているか確認できます。チェックサムが全て一致していれば、同期は完了です。

【1号機】

FG70F_1st # diagnose sys ha checksum show
is_manage_primary()=1, is_root_primary()=1
debugzone
global: da f0 d5 14 99 20 e5 09 f5 00 2f 17 fc cf 96 65
root: 03 4d fa 77 78 8f a1 0d 3a 93 06 9d 05 8c 10 df
all: 3d 4c 9c 2d 65 cc 2c fd 79 23 e1 27 da 72 ce 3e

checksum
global: da f0 d5 14 99 20 e5 09 f5 00 2f 17 fc cf 96 65
root: 03 4d fa 77 78 8f a1 0d 3a 93 06 9d 05 8c 10 df
all: 3d 4c 9c 2d 65 cc 2c fd 79 23 e1 27 da 72 ce 3e

【2号機】

FG70F_2nd # diagnose sys ha checksum show
is_manage_primary()=0, is_root_primary()=0
debugzone
global: da f0 d5 14 99 20 e5 09 f5 00 2f 17 fc cf 96 65
root: 03 4d fa 77 78 8f a1 0d 3a 93 06 9d 05 8c 10 df
all: 3d 4c 9c 2d 65 cc 2c fd 79 23 e1 27 da 72 ce 3e

checksum
global: da f0 d5 14 99 20 e5 09 f5 00 2f 17 fc cf 96 65
root: 03 4d fa 77 78 8f a1 0d 3a 93 06 9d 05 8c 10 df
all: 3d 4c 9c 2d 65 cc 2c fd 79 23 e1 27 da 72 ce 3e

セカンダリ機から分かる同期の完了

同期が始まると、セカンダリ機のコンソール画面に次のようなメッセージが順番に表示されます。ここから同期の状況を確認できます。このメッセージが全て表示された時、同期は完了となります。

secondary's external files are not in sync with the primary's, sequence:0. (type CERT_LOCAL)
secondary's external files are not in sync with the primary's, sequence:1. (type CERT_LOCAL)
secondary's external files are not in sync with the primary's, sequence:2. (type CERT_LOCAL)
secondary's external files are not in sync with the primary's, sequence:3. (type CERT_LOCAL)
secondary's external files are not in sync with the primary's, sequence:4. (type CERT_LOCAL)
secondary succeeded to sync external files with primary
secondary's configuration is not in sync with the primary's, sequence:0
secondary's configuration is not in sync with the primary's, sequence:1
secondary's configuration is not in sync with the primary's, sequence:2
secondary's configuration is not in sync with the primary's, sequence:3
secondary's configuration is not in sync with the primary's, sequence:4
secondary starts to sync with primary

同期失敗時のトラブルシューティング

チェックサムが一致せず、同期に失敗する場合は、セカンダリ機から下記のコマンドを実行して強制同期を行います。同期が始まると、セカンダリ機のコンソール画面に同期のメッセージが表示されます。

# execute ha synchronize start<<HA同期の強制実行

同期が完了したら、プライマリとセカンダリの両方で下記のコマンドを実行し、チェックサムの再計算を行ってください。

# diagnose sys ha checksum recalculate<< チェックサムの再計算
# diagnose sys ha checksum show<< チェックサムの表示

強制同期を行ってもチェックサムが一致しない場合は、デバッグログを取得することで原因を分析できます。プライマリとセカンダリの両方で下記のコマンドを実行してください。デバッグログ取得中に強制同期を実行して、その挙動を見るイメージです。このコマンドを実行する場合は、必ずSSHでログインして行ってください。コンソールでは表示が遅く、デバッグログの取得には向きません。

# execute ha synchronize stop<< HA同期の強制停止
# diagnose debug console timestamp enable<< デバッグのタイムスタンプを有効
# diagnose debug application hatalk -1<< HAプロトコルのデーモン
# diagnose debug application hasync -1<< HA同期のデーモン
# diagnose debug enable<< デバッグ開始
# execute ha synchronize start<< HA同期の強制実行
<< デバッグログの取得終了後 >>
# diagnose debug disable<< デバッグ停止
# diagnose debug reset<< デバッグ設定リセット

フェイルオーバー発生の条件

プライマリ機が故障したり、インターフェースの異常を検知したりした際に、セカンダリ機が自動的にその役割を引き継ぐプロセスのことを「フェイルオーバー」と呼びます。フェイルオーバーが発生すると、プライマリとセカンダリが瞬時に切り替わります。フェイルオーバー発生の条件は下記の通りです。

フェイルオーバー発生の条件
  • モニターしているポートのどれかが不通になった時。
    - LAGで冗長化している場合、1本のみの不通では切り替わりません。
  • ハートビートが全て不通になった時(デフォルトは200ミリ秒間隔で計6回受信に失敗した時)。
    - ハートビートが2本ある場合、1本のみの不通では切り替わりません。
  • プライマリがダウンまたは再起動した時。
  • プライマリに過度な負荷がかかってネットワークが不通になった時。
  • リンクモニターのPingが応答しなくなった時。

ステータスが切り替わると、新しいプライマリ機器側からGARPが送信されます。切り替わり後、プライマリとセカンダリは切り替わったまま稼働を続けます。デフォルトでは原則、セカンダリに降格した1号機が自動的に復帰することはありません。降格した1号機はセカンダリのまま稼働し続けます。復旧した1号機を強制的にプライマリに昇格させたい場合は、オーバーライドの設定を有効にする必要があります。

フェイルオーバー発生の条件

著者

著者イメージ
浦 弘平
ネットワークセキュリティ事業本部 カスタマーサポート部
誰もが知っているようで意外と知らない。今さら人に聞けない。
そんなかゆいところに手が届く情報や現場で役立つ豆知識を紹介していきます。

お問い合わせ

Fortinet製品に関する
問い合わせはこちらから

お役立ち資料

各種お役立ち資料も
取り揃えております

関連ブログ