はじめに

F5 BIG-IPのOS（TMOS）について、バージョンアップ・バージョンダウンの事前計画から実際の作業手順までを整理しました。

本記事では、BIG-IPをActive / Standbyの冗長構成で運用している環境を想定し、CLI（tmsh）を使用したアップグレード方法を解説します。

なお、OSのバージョンやハードウェアによって作業手順が異なる場合があります。実際の作業では、必ず対象バージョンの公式ドキュメントを確認してください。

本記事のコマンド例は、主にBIG-IP TMOS 17.x系までの従来型のアップグレード方式を対象としています。

バージョンアップ前に行うこと（机上）

BIG-IP TMOSとF5OSの違い

まず、BIG-IPのOS体系について整理しておきます。

BIG-IPで使用されるTMOS 17.5.xのEnd of Software Development（EoSD）およびEnd of Technical Support（EoTS）は、2029年1月1日とされています。

一方、2026年5月にはBIG-IP TMOS 21.1がリリースされており、TMOS 17.5.xが最終バージョンというわけではありません。

また、従来のiSeriesやVIPRIONではBIG-IP TMOS 21.xを利用できません。21.xを利用する場合は、rSeries、VELOS、対応するBIG-IP Virtual Edition（VE）などへの移行を検討する必要があります。

ここで注意したいのが、TMOSとF5OSの違いです。

TMOS： BIG-IPのトラフィック管理機能などを提供するOS
F5OS： rSeriesやVELOSなどで使用されるプラットフォーム用OS

例えば、rSeriesではF5OS上にBIG-IP TMOSのテナントを作成して運用します。

そのため、F5OSがTMOSを単純に置き換えるわけではありません。

詳しくは以下を参照してください。

バージョンの命名規則とサポート期間の把握

まずは、BIG-IPのバージョン体系やライフサイクルポリシーについて理解しましょう。

以下のドキュメントでは、リリースの種類やサポート期間について解説されています。

K5903：BIG-IP software support policy

特に確認しておきたいのは、以下の項目です。

メジャーリリース（Major Release）
長期安定版リリース（Long-Term Stability Release）
End of Software Development（EoSD）
End of Technical Support（EoTS）

長期安定版リリースは比較的長いサポート期間が設定されるため、本番環境で使用するOSの選定において重要な判断材料となります。

ただし、サポート期間はリリース系列によって異なります。

例えば、BIG-IP 21.1以降の新しい長期安定版リリースでは、ソフトウェアライフサイクルが原則3年間に変更されています。

従来のサポート期間を前提にせず、各リリースの最新情報を確認するようにしましょう。

現在使用しているバージョンのサポート期限の確認

現在使用しているOSについて、EoSDやEoTSを確認しましょう。

K11478：BIG-IPのソフトウェアライフサイクル情報

バージョンアップの計画を立てる際には、以下の観点で評価するとよいでしょう。

現行バージョンのサポート終了時期
アップグレード先のサポート終了時期
セキュリティ修正の提供状況
利用している機能の互換性
将来的なアップグレードの容易さ

また、可能であれば長期安定版リリースを優先的に検討することをおすすめします。

ただし、長期安定版であっても、すべてのハードウェアや機能との互換性が保証されるわけではありません。

アップグレードの概要確認

実際の計画を立てる前に、F5が公開しているアップグレードの概要を確認しましょう。

K84554955：Overview of BIG-IP system software upgrades

全体の作業フローや注意点を理解しておくことで、作業時のトラブルを減らすことができます。

ターゲットバージョンの選定

アップグレード先となるOSバージョンを選定します。

2026年10月時点では、BIG-IP TMOS 21.1系が公開されています。

ただし、最新バージョンが必ずしも最適な選択肢とは限りません。

実際の選定では、以下の項目を総合的に評価しましょう。

サポート期間
ハードウェアとの互換性
修正済みの不具合
既知の不具合
セキュリティ修正状況
使用している機能への影響
アップグレードパス

リリース一覧は以下のドキュメントから確認できます。

K9412：The BIG-IP release matrix

プラットフォームとの互換性の確認

OSのバージョンと、使用しているハードウェアの互換性を確認します。

K9476：The F5 hardware/software compatibility matrix

特に、旧世代のハードウェアを使用している場合は注意が必要です。

例えば、iSeriesやVIPRIONはBIG-IP TMOS 21.xに対応していないため、アップグレード先を17.x系に限定するか、ハードウェアの更改を検討する必要があります。

また、BIG-IP VEの場合は、仮想化基盤との互換性やライセンスによるバージョン制限も確認しておきましょう。

アップグレードパスの確認

現在使用しているOSとターゲットバージョンの組み合わせによっては、中間バージョンへのアップグレードが必要になります。

K13845：Overview of supported BIG-IP upgrade paths

特にメジャーバージョンを大きく変更する場合は、中間アップグレードの必要性を必ず確認してください。

アップグレードパスに制約がある場合、直接アップグレードしようとすると設定の移行に失敗する可能性があります。

K11734122：BIG-IP Upgrades of more than 2 Major Versions are not supported

ターゲットバージョンのリリースノートの確認

ターゲットバージョンが決定したら、リリースノートを確認します。

特に重要なのは、以下の項目です。

追加された新機能
修正された不具合
既知の不具合
仕様変更・廃止された機能
アップグレード時の注意事項

これらをExcelなどで一覧化し、既存環境への影響を評価するとよいでしょう。

例えば、iRulesやSSL/TLS関連の機能などは、バージョンアップに伴う仕様変更の影響を受ける可能性があります。

以下はBIG-IP 17.1.2.1のリリースノートです。

BIG-IP 17.1.2.1 Release Notes

バージョンアップ前に行うこと（実機）

現在の稼働状況の確認

アップグレード前に、現在のBIG-IPが正常に稼働していることを確認します。

主な確認項目は以下のとおりです。

Active / Standbyの状態
HAの正常性
ConfigSyncの状態
Virtual Serverの状態
PoolおよびPool Memberの状態
各インターフェースの状態
CPU・メモリ・ディスクの使用状況
システムログに異常がないこと

アップグレード前の状態を記録しておくことで、アップグレード後の正常性確認が容易になります。

コンフィグのバックアップ

アップグレード作業前には、必ず設定情報をバックアップします。

BIG-IPでは、UCS（User Configuration Set）形式で設定情報を保存できます。

例えば、以下のコマンドを実行します。

tmsh save sys ucs /var/local/ucs/pre_upgrade.ucs

UCSには設定情報や証明書などが含まれるため、適切に保護する必要があります。

取得したUCSファイルは、必ずBIG-IP本体とは別の安全な場所にも保存してください。

また、冗長構成の場合は両方の機器からバックアップを取得しておくと安心です。

ターゲットOSの取得

F5のダウンロードサイトから、ターゲットバージョンのOSイメージファイル（ISO）を入手します。

K000090258：F5ソフトウェアのダウンロードに関する情報

ダウンロード後は、ファイルの整合性を確認しておきましょう。

OSイメージのアップロード

取得したISOファイルを、BIG-IPの以下のディレクトリへアップロードします。

/shared/images

SCPやSFTPなどを使用して転送できます。

アップロード後は、ファイルが正常に配置されていることを確認しましょう。

ls -lh /shared/images

冗長構成の場合は、1号機・2号機の両方にアップロードしておきます。

ライセンスの再アクティベートの準備

アップグレード前には、ライセンスの再アクティベートが必要か確認します。

特に、ライセンスのService Check Dateがターゲットバージョンのリリース日に対応しているかを確認してください。

tmsh show sys license

ライセンスの再アクティベートは、以下の方法で実施できます。

Automatic：F5のライセンスサーバーへ接続して自動的にアクティベート
Manual：Dossier情報を使用して手動でアクティベート

インターネット接続が制限されている環境では、Manualによるアクティベートが必要になる場合があります。

事前に作業方法を確認し、必要な情報を準備しておきましょう。

なお、ライセンスの再アクティベートでは設定の再読み込みが発生する場合があり、通信に影響する可能性があります。

冗長構成の場合は、原則としてトラフィックを処理していない機器で実施します。

K7727：License activation may be required before a software upgrade for BIG-IP

冗長構成と同期状態の確認

アップグレード作業前に、1号機と2号機の設定が正常に同期されていることを確認しましょう。

確認コマンドは以下のとおりです。

tmsh show cm sync-status

また、HAの状態も確認します。

tmsh show cm failover-status

今回の作業では、以下の状態を想定しています。

機器	ステータス
1号機	Active
2号機	Standby

なお、Auto Failbackが有効になっている環境では、アップグレード中に意図しない切り戻りが発生する可能性があります。

必要に応じて、一時的に無効化しておきましょう。

作業後は元の設定に戻すことも忘れないようにしてください。

Device Service Clustering：Failoverの管理

また、Connection MirroringやAuto Syncなどを使用している場合も、対象バージョンのアップグレードガイドに従って取り扱いを確認してください。

バージョンアップ方法

ここからは、実際のバージョンアップ手順について解説します。

今回は、以下のようなActive / Standby構成を想定しています。

機器	アップグレード前	アップグレード後
1号機	Active	Active
2号機	Standby	Standby

大まかな作業フローは以下のとおりです。

事前準備
2号機（Standby）のアップグレード
2号機の正常性確認
1号機から2号機へのフェイルオーバー
1号機のアップグレード
1号機の正常性確認
Active / Standbyの切り戻し
最終確認

なお、今回の手順では以下を例として使用します。

ターゲットバージョン：17.1.2.1
ISOファイル：BIGIP-17.1.2.1-0.0.2.iso
インストール先のブートボリューム：HD1.2

環境に合わせて適宜読み替えてください。

2号機のアップグレード

1. OFFLINE状態へ遷移

まずは2号機をForced Offline状態へ遷移させます。

tmsh run sys failover offline

正常にOFFLINE状態へ遷移したことを確認します。

tmsh show cm failover-status

1号機がActiveの状態を維持していることも確認しておきましょう。

2. ライセンスの再アクティベート

必要に応じて、ライセンスの再アクティベートを実施します。

事前に準備した情報を使用し、GUIの以下の画面から操作できます。

System > License > Re-activate

再アクティベート後はライセンス情報を確認しましょう。

tmsh show sys license

ライセンスの再アクティベートに伴い、設定の再読み込みが発生する場合があります。

今回は2号機をForced Offlineにしているため、通常の冗長構成であれば1号機が引き続きトラフィックを処理します。

ただし、これだけで通信断が発生しないことを保証できるわけではありません。Active側の稼働状況も確認してください。

3. ブートボリュームの確認

BIG-IPでは、複数のブートボリュームに異なるOSバージョンをインストールできます。

例えば、以下のような構成です。

HD1.1：現在使用しているOS
HD1.2：アップグレード先のOS
HD1.3：別バージョンのOS

実際のボリューム構成は、ハードウェアや仮想アプライアンスの構成によって異なります。

以下のコマンドで確認できます。

tmsh show sys software status

現在使用しているブートボリュームと、インストール先として利用可能なボリュームを確認してください。

アップグレード前のブートボリュームは、ロールバックのために残しておくことをおすすめします。

4. 新しいOSのインストール

次に、ターゲットバージョンのOSをインストールします。

今回は、HD1.2にBIG-IP 17.1.2.1をインストールします。

tmsh install sys software image BIGIP-17.1.2.1-0.0.2.iso create-volume volume HD1.2

create-volumeは、新しいブートボリュームを作成するためのオプションです。

既存のボリュームにインストールする場合は、必要に応じてcreate-volumeを省略します。

tmsh install sys software image BIGIP-17.1.2.1-0.0.2.iso volume HD1.2

ただし、インストール先の既存データが置き換えられる可能性があるため、使用中のボリュームやロールバック用のボリュームを誤って指定しないように注意してください。

5. インストール状況の確認

以下のコマンドで進捗を確認します。

tmsh show sys software status

インストールが完了し、対象ボリュームのステータスがcompleteになっていることを確認します。

エラーが発生している場合は、必要に応じて以下のログなども確認しましょう。

/var/log/liveinstall.log

6. 現在のブートボリュームの確認

以下のコマンドで、現在使用しているブートボリュームを確認します。

switchboot -l

実行結果には、現在のブートボリュームやデフォルトのブートボリュームなどが表示されます。

7. ブートボリュームの変更

新しいOSをインストールしたボリュームを、次回起動時のブート先として指定します。

switchboot -b HD1.2

8. ブートボリュームの変更確認

設定が正しく反映されていることを確認します。

switchboot -l

Default boot imageがHD1.2に変更されていることを確認してください。

9. 再起動

次のコマンドでBIG-IPを再起動します。

reboot

再起動後は、指定したブートボリュームから新しいOSが起動します。

再起動には時間がかかる場合があります。

ファームウェアの更新などが実行されることもあるため、起動に時間がかかっている場合でも、安易に電源を切らないようにしてください。

10. アップグレード後の確認

再起動が完了したら、OSのバージョンを確認します。

tmsh show sys version

あわせて、現在使用しているブートボリュームも確認します。

switchboot -l

OSのバージョンがターゲットバージョンになっていることを確認しましょう。

さらに、以下の項目も確認します。

コンフィグが正常に読み込まれていること
ライセンスが正常であること
必要なモジュールが起動していること
Virtual ServerやPoolの設定が維持されていること
HA関連の設定に異常がないこと
システムログに重大なエラーがないこと

11. ONLINE状態へ復帰

正常性の確認が完了したら、2号機をONLINE状態に戻します。

tmsh run sys failover online

12. Standby状態の確認

以下のコマンドでステータスを確認します。

tmsh show cm failover-status

2号機がStandby状態になっていることを確認してください。

また、1号機が引き続きActiveとして動作していることも確認します。

これで2号機のアップグレードは完了です。

1号機のアップグレード

続いて、1号機をアップグレードします。

基本的な操作は2号機と同じですが、1号機は現在Activeとしてトラフィックを処理しているため、フェイルオーバーが発生する点に注意が必要です。

1. 2号機の正常性を再確認

1号機の作業を開始する前に、アップグレード済みの2号機が正常に稼働していることを確認します。

特に、2号機がActiveに昇格した場合に、必要なトラフィックを処理できる状態であることを確認しておきましょう。

2. 1号機をOFFLINE状態へ遷移

1号機で以下のコマンドを実行します。

tmsh run sys failover offline

通常は、この操作によって2号機がActiveへ昇格します。

ここでフェイルオーバーが発生するため、通信への影響が生じる可能性があります。

通信断の時間は、Connection Mirroringの設定やトラフィックの種類、ネットワーク構成などによって異なります。

したがって、一律に1秒未満で切り替わるとは限りません。

可能であれば、事前に検証環境でフェイルオーバー時の通信影響を測定しておくことをおすすめします。

3. フェイルオーバー後の正常性確認

2号機がActiveとなり、正常にトラフィックを処理できていることを確認します。

tmsh show cm failover-status

この段階で、実際のアプリケーション通信が正常に行えることも確認してください。

4. 1号機のアップグレード

フェイルオーバー後の正常性が確認できたら、1号機でも2号機と同様のアップグレード作業を実施します。

実施内容は以下のとおりです。

必要に応じたライセンスの再アクティベート
ブートボリュームの確認
新しいOSのインストール
インストール完了確認
ブートボリュームの変更
再起動
OSバージョンと各種設定の確認
ONLINE状態への復帰

作業が完了すると、通常は以下の状態となります。

機器	ステータス
1号機	Standby
2号機	Active

この時点で両方の機器がターゲットバージョンになっていることを確認してください。

Active / Standbyの切り戻し

1号機のアップグレード完了直後は、2号機がActive、1号機がStandbyの状態になっていることを想定しています。

アップグレード前と同じ構成に戻すため、Active / Standbyを切り戻します。

2号機をOFFLINEへ遷移

現在Activeとなっている2号機で、以下のコマンドを実行します。

tmsh run sys failover offline

これにより、通常は1号機がActiveへ昇格します。

1号機が正常にトラフィックを処理していることを確認してください。

2号機をONLINEへ復帰

1号機の正常性確認が完了したら、2号機をONLINE状態に戻します。

tmsh run sys failover online

ステータス確認

以下のコマンドで、Active / Standbyの状態を確認します。

tmsh show cm failover-status

最終的に以下の状態となっていることを確認してください。

機器	ステータス
1号機	Active
2号機	Standby

これでActive / Standbyの切り戻しは完了です。

バージョンアップ後の最終確認

両方の機器のアップグレードが完了したら、最終確認を実施します。

主な確認項目は以下のとおりです。

確認項目	確認内容
OSバージョン	両機器がターゲットバージョンになっていること
ブートボリューム	意図したボリュームで起動していること
HA	Active / Standbyが正常であること
ConfigSync	設定が正常に同期されていること
ライセンス	有効なライセンスが適用されていること
Virtual Server	正常に動作していること
Pool / Pool Member	ヘルスモニターが正常であること
アプリケーション	実際の通信に問題がないこと
システムログ	重大なエラーが発生していないこと

ConfigSyncの状態は以下のコマンドで確認できます。

tmsh show cm sync-status

同期が必要な場合は、設定差分や同期方向を確認したうえで実施してください。

特に、アップグレードの前後では設定情報の世代が異なる可能性があるため、意図しないコンフィグの上書きに注意が必要です。

また、事前に無効化したAuto Failbackなどの設定があれば、必要に応じて元に戻しておきましょう。

バージョンダウン（ロールバック）方法

BIG-IPでは、アップグレード前のOSがインストールされたブートボリュームを残しておくことで、比較的容易に旧バージョンへ戻すことができます。

例えば、以下の構成を想定します。

HD1.1：旧バージョン
HD1.2：新バージョン

まず、ブートボリュームを確認します。

switchboot -l

次に、旧バージョンがインストールされているHD1.1を指定します。

switchboot -b HD1.1

ブート先の設定を確認します。

switchboot -l

問題がなければ再起動します。

reboot

再起動後、以下のコマンドでOSバージョンを確認します。

tmsh show sys version

ただし、ブートボリュームを切り替えるだけで、すべての設定がアップグレード前の状態に戻るわけではありません。

アップグレード後に設定変更を行っている場合や、バージョン間で設定形式が変更されている場合は、UCSからの設定復元などが必要になる可能性があります。

また、冗長構成では、旧バージョンに戻した機器と新バージョンのままの機器の間で、HAやConfigSyncの互換性に問題が生じる可能性もあります。

そのため、本番環境でのロールバックは、フェイルオーバーや設定復元も含めた手順を事前に計画しておきましょう。

参考資料