NICボンディング active-backupで冗長化体験

Linuxエンジニア養成講座 第21回｜全36回・フェーズ3「ネットワークとインフラ基盤」の6回目（6/12回目）です。
前回まで: 第16回でTCP/IPの基礎、第17回でnmcliによるIP設定と疎通確認、第18回でプロキシ・DNS・NTPのクライアント設定、第19回でパッケージ管理、第20回でfirewalldによる通信制御を学びました。
今回学ぶこと: 複数のNICを束ねて冗長化する「ボンディング」の仕組みを理解し、active-backupモードで構成・フェイルオーバーを体験します。

この回は発展トピックです。受講者のアサイン先によってはスキップ可能で、スキップしても第23回以降に支障はありません。

前回の予告で「複数のNICを束ねて冗長化する技術を学びます」とお伝えしました。今回はその NIC 冗長化技術であるボンディングを実際に構成し、障害時の自動切り替え（フェイルオーバー）を体験します。

この記事を読み終えると、以下のことができるようになります。

• NIC を冗長化する理由を説明できる
• ボンディングの仕組みと active-backup モードの動作を説明できる
• nmcli でボンディング（bond0）を構成できる
• フェイルオーバーと復旧を実際に体験し、動作を確認できる
• ボンディングを解除して元の状態に戻せる

なぜ NIC を冗長化するか

オンプレミス（自社やデータセンターに物理サーバーを設置する）環境では、サーバーの NIC が故障したり、LANケーブルが抜けたり、スイッチポートのSFP（光トランシーバ）を交換する間に通信断が発生することがあります。

1枚の NIC だけでサーバーを運用していると、その NIC に障害が起きた瞬間にサーバーへの通信が途絶します。Web サーバーであればサイトが閲覧不能になり、データベースサーバーであればアプリケーション全体が停止するかもしれません。

冗長化とは「予備を用意して自動で切り替える」仕組みです。NIC を2枚用意しておけば、1枚が故障しても残りの1枚で通信を継続できます。オンプレサーバーでは NIC 冗長化が標準構成であり、構築手順書に必ず含まれる作業の1つです。

ボンディングは物理サーバーで使う技術

ボンディングは主に物理サーバーで使われる技術です。仮想化基盤（VMware、Hyper-V、VirtualBox など）の環境では、ハイパーバイザー（仮想化ソフトウェア）が物理 NIC を束ねて冗長化を行っています。そのため、ゲスト VM の中でボンディングを構成する必要は通常ありません。

今回の演習は、物理サーバーでのボンディング構成を検証環境の VM 上で体験するものです。「仮想マシンの中でボンディングを組むのが標準」というわけではなく、あくまで仕組みとコマンドを学ぶための演習として理解してください。

ボンディングとは

ボンディング（bonding）は、Linux カーネルが提供する機能で、複数の物理NICを1つの論理インターフェース（例: bond0）に束ねる技術です。OS から見ると bond0 という1つの NIC があるように見えますが、実際にはその裏に複数の物理 NIC が存在しています。

ボンディングモード一覧

ボンディングには7つのモードがあります。今回は active-backup を使いますが、他のモードも一覧で紹介します。

モード番号	名前	概要
0	balance-rr	パケットをラウンドロビンで各NICに分配する
1	active-backup	1枚がアクティブ、他はスタンバイ。障害時に自動切替
2	balance-xor	送信元・送信先MACのXOR値で送信NICを決定する
3	broadcast	全NICに同じパケットを送信する
4	802.3ad（LACP）	対向スイッチとネゴシエーションし帯域を束ねる
5	balance-tlb	送信の負荷を分散する（受信は1枚）
6	balance-alb	送受信の負荷を分散する

mode=4（802.3ad / LACP）は対向のネットワークスイッチ側にも設定が必要です。今回の Hyper-V 仮想スイッチは LACP に対応していないため、mode=1（active-backup）を使用します。active-backup はスイッチ側の設定が不要で、最もシンプルに冗長化を実現できるモードです。実務でもよく使われます。

active-backup の仕組み

active-backup モードでは、束ねた NIC のうち1枚が「アクティブ」として通信を担当し、残りの NIC は「スタンバイ」として待機します。アクティブな NIC に障害が発生すると、miimon の監視で障害を検知し、スタンバイの NIC が自動的にアクティブに昇格します。この切り替えをフェイルオーバーと呼びます。切り替え中（数百ミリ秒〜数秒）の通信は失われますが、TCP 通信であれば再送によって自動的に復旧します。

miimon（MII Monitoring Interval）というパラメータで、NIC のリンク状態を監視する間隔（ミリ秒）を指定します。今回は miimon=100（100ミリ秒ごとに監視）を設定します。

チーミング（teamd）について

RHEL/AlmaLinux には「チーミング（teamd）」という類似機能もありますが、RHEL 9 では teamd は非推奨となり、bonding の使用が推奨されています。今回は bonding のみを扱います。

ボンディングの詳細なパラメータは modinfo bonding で確認できます。nmcli のボンディング関連オプションは man nmcli や nmcli connection add type bond --help で調べられます。

検証環境の準備（Hyper-V 固有の設定）

ボンディングの構成に入る前に、検証環境（Hyper-V）固有の設定が1つ必要です。物理サーバーでは不要な手順ですが、Hyper-V 上の VM でボンディングを体験するために必要になります。

active-backup モードでは、bond インターフェースが全スレーブ NIC に同一の MAC アドレスを付与します。しかし Hyper-V はデフォルトで各仮想 NIC の MAC アドレスを厳密にチェックしており、割り当てられた MAC と異なるアドレスからの通信をブロックします。

この制限を解除するために、ホストPC側で「MAC アドレススプーフィング」を有効化します。繰り返しますが、これは Hyper-V で検証するためだけの手順であり、物理サーバーでは不要です。

ホストPCで実行（PowerShell を管理者権限で起動）:

実行コマンド:

PS> Get-VMNetworkAdapter -VMName 'alma-main' | Where-Object { $_.SwitchName -eq 'Internal Switch' } | Set-VMNetworkAdapter -MacAddressSpoofing On

出力はありません。エラーが表示されなければ成功です。このコマンドは alma-main の Internal Switch に接続されている全仮想NICに対して MAC アドレススプーフィングを許可します。

物理サーバーではこの設定は不要です。Hyper-V（および一部の仮想化基盤）固有の手順です。

現在の NIC 構成を確認する

ボンディングを構成する前に、現在の NIC 構成を把握しておきます。今回ボンディングに使用するのは eth1 と eth2 です。

alma-mainで実行します。

実行コマンド:

$ ip -br link show

実行結果:

lo               UNKNOWN        00:00:00:00:00:00 
eth0             UP             00:15:5d:01:63:34 
eth1             UP             00:15:5d:01:63:35 
eth2             UP             00:15:5d:01:63:36 
eth3             UP             00:15:5d:01:63:3d  

eth1（MAC: 00:15:5d:01:63:35）と eth2（MAC: 00:15:5d:01:63:36）が UP 状態であることを確認できます。この2枚を bond0 に束ねます。

実行コマンド:

$ nmcli connection show

実行結果:

NAME         UUID                                  TYPE      DEVICE
eth0         e83ac41c-9aa7-36ed-8125-43cbb43ab33e  ethernet  eth0
internal1    05e00f04-ccab-4c08-814e-f3ad2f9b4338  ethernet  eth1
internal2    d2ec4710-bda7-4f01-a994-7e02f5394629  ethernet  eth2
intersystem  79194ae0-4736-4e72-993e-f2f682c476fb  ethernet  eth3
lo           d8877e57-6090-4541-bf25-38d7708562b4  loopback  lo
eth1         94ce9502-db04-3b23-b701-9fbe510608c0  ethernet  --
eth2         738b16d4-0020-3f16-a1b0-e95af7badc4c  ethernet  --
eth3         a594a6c6-edcd-4eda-b248-eb8a3787b987  ethernet  --     

UUID は環境によって異なります。ここで注目するのは、eth1 が接続名「internal1」、eth2 が接続名「internal2」で接続されている点です。ボンディング構成後、これらの旧接続を停止する必要があります。

実行コマンド:

$ nmcli device status

実行結果:

DEVICE  TYPE      STATE            CONNECTION
eth0    ethernet  接続済み         eth0
eth1    ethernet  接続済み         internal1
eth2    ethernet  接続済み         internal2
eth3    ethernet  接続済み         intersystem
lo      loopback  接続済み (外部)  lo          

eth1 と eth2 の MAC アドレスを個別に確認しておきます。

実行コマンド:

$ cat /sys/class/net/eth1/address

実行結果:

00:15:5d:01:63:35

実行コマンド:

$ cat /sys/class/net/eth2/address

実行結果:

00:15:5d:01:63:36

最後に、ボンディング前の疎通を確認しておきます。

実行コマンド:

$ ping -c 2 10.0.1.3

実行結果:

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.3: icmp_seq=1 ttl=64 時間=0.617ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=2 ttl=64 時間=0.484ミリ秒

--- 10.0.1.3 ping 統計 ---
送信パケット数 2, 受信パケット数 2, 0% packet loss, time 1064ms
rtt min/avg/max/mdev = 0.484/0.550/0.617/0.066 ms

alma-sub（10.0.1.3）への疎通が取れています。この状態を基準に、ボンディングを構成します。

ボンディングを構成する

ここからが本題です。nmcli を使って active-backup モードのボンディングを構成します。手順は6ステップです。

ステップ1: bond0 接続を作成する

alma-mainで実行します。

実行コマンド:

$ sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options 'mode=active-backup,miimon=100'

実行結果:

接続 'bond0' (d8910bc9-3a60-4883-b02f-6b2b210462c9) が正常に追加されました。

UUID は環境によって異なります。このコマンドで bond0 という名前のボンディング接続が作成されました。bond.options で active-backup モードと miimon=100（100ミリ秒間隔の監視）を指定しています。

ステップ2: ポート（スレーブ）を追加する

bond0 に eth1 と eth2 をポートとして追加します。

実行コマンド:

$ sudo nmcli connection add type ethernet con-name bond0-port1 ifname eth1 controller bond0

実行結果:

接続 'bond0-port1' (65a29b6e-fae6-4297-a9fe-142681816720) が正常に追加されました。

実行コマンド:

$ sudo nmcli connection add type ethernet con-name bond0-port2 ifname eth2 controller bond0

実行結果:

接続 'bond0-port2' (79b9aa90-c361-40de-b342-cc7db213551a) が正常に追加されました。

controller は「このポートがどの bond に属するか」を指定するキーワードです。古いドキュメントでは master と書かれていることもあります。どちらでも動作しますが、NetworkManager の新しいバージョンでは controller が推奨されています。

ステップ3: bond0 に IP アドレスを設定する

実行コマンド:

$ sudo nmcli connection modify bond0 ipv4.addresses 10.0.1.1/24 ipv4.method manual

出力はありません。これで bond0 に IP アドレス 10.0.1.1/24 が設定されました。元々 eth1（internal1）が持っていた IP を bond0 に移す形です。

ステップ4: 旧接続を停止する

eth1 と eth2 は現在 internal1、internal2 という接続で使われています。bond0 のポートとして使うには、まず旧接続を停止する必要があります。

実行コマンド:

$ sudo nmcli connection down internal1

実行結果:

接続 'internal1' が正常に非アクティブ化されました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/9)

実行コマンド:

$ sudo nmcli connection down internal2

実行結果:

接続 'internal2' が正常に非アクティブ化されました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/7)

D-Bus アクティブパスの番号は環境によって異なります。

ステップ5: bond0 とポートを起動する

まず bond0 本体を起動します。

実行コマンド:

$ sudo nmcli connection up bond0

実行結果:

接続が正常にアクティベートされました (controller waiting for ports) (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/14)

「controller waiting for ports」と表示されています。bond0 はポートの接続を待っている状態です。続けてポートを起動します。

実行コマンド:

$ sudo nmcli connection up bond0-port1

実行結果:

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/17)

実行コマンド:

$ sudo nmcli connection up bond0-port2

実行結果:

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/18)

bond0 を起動しただけではポートは自動的に起動しません。ポートも個別に起動する必要があります。この手順を忘れると bond0 にポートが紐づかず、通信ができません。

ステップ6: 状態を確認する

ボンディングの状態は /proc/net/bonding/bond0 で確認できます。

実行コマンド:

$ cat /proc/net/bonding/bond0

実行結果:

Ethernet Channel Bonding Driver: v5.14.0-570.12.1.el9_6.x86_64

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Slave Interface: eth1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:15:5d:01:63:35
Slave queue ID: 0

Slave Interface: eth2
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:15:5d:01:63:36
Slave queue ID: 0

確認すべきポイントを整理します。

• Bonding Mode: fault-tolerance (active-backup) — 指定したモードになっている
• Currently Active Slave: eth1 — eth1 がアクティブ（通信担当）
• MII Status: up — bond 全体のリンク状態が正常
• MII Polling Interval (ms): 100 — 監視間隔が 100ms
• Slave Interface: eth1 / eth2 — 両方の MII Status が up

IP アドレスの割り当てを確認します。

実行コマンド:

$ ip addr show bond0

実行結果:

6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:15:5d:01:63:35 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.1/24 brd 10.0.1.255 scope global noprefixroute bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::7952:3cdd:d2cb:fc6c/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

bond0 に 10.0.1.1/24 が割り当てられています。MAC アドレスは 00:15:5d:01:63:35（eth1 の MAC）になっています。active-backup モードでは、アクティブな NIC の MAC が bond の MAC として使われます。

最後に、nmcli でデバイスの状態を確認します。

実行コマンド:

$ nmcli device status

実行結果:

DEVICE  TYPE      STATE            CONNECTION
eth0    ethernet  接続済み         eth0
bond0   bond      接続済み         bond0
eth3    ethernet  接続済み         intersystem
eth1    ethernet  接続済み         bond0-port1
eth2    ethernet  接続済み         bond0-port2
lo      loopback  接続済み (外部)  lo          

eth1 と eth2 の CONNECTION 列が internal1 / internal2 から bond0-port1 / bond0-port2 に変わっています。bond0 が接続済みとして表示されており、ボンディングの構成は完了です。

フェイルオーバーを体験する

ボンディングの最大の意義は、NIC 障害時に自動で通信が切り替わることです。ここでは意図的に NIC を切断してフェイルオーバーを体験します。

まず、bond0 経由で alma-sub への疎通を確認します。

alma-mainで実行します。

実行コマンド:

$ ping -c 2 10.0.1.3

実行結果（0% packet loss を確認）:

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.3: icmp_seq=1 ttl=64 時間=0.202ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=2 ttl=64 時間=0.305ミリ秒

--- 10.0.1.3 ping 統計 ---
送信パケット数 2, 受信パケット数 2, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.202/0.253/0.305/0.051 ms

正常に通信できています。現在アクティブな NIC を確認します。

実行コマンド:

$ grep 'Currently Active' /proc/net/bonding/bond0

実行結果:

Currently Active Slave: eth1

eth1 がアクティブです。ここで eth1 を切断し、フェイルオーバーを発生させます。

実行コマンド:

$ sudo nmcli device disconnect eth1

実行結果:

デバイス 'eth1' が正常に切断されました。

アクティブな NIC が切り替わったか確認します。

実行コマンド:

$ grep 'Currently Active' /proc/net/bonding/bond0

実行結果:

Currently Active Slave: eth2

eth2 に切り替わりました。通信を確認します。

実行コマンド:

$ ping -c 3 10.0.1.3

実行結果:

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.3: icmp_seq=1 ttl=64 時間=0.202ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=2 ttl=64 時間=0.305ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=3 ttl=64 時間=0.417ミリ秒
--- 10.0.1.3 ping 統計 ---
送信パケット数 3, 受信パケット数 3, 0% packet loss, time 2058ms

0% packet loss です。eth1 が切断された後、eth2 が自動的にアクティブに昇格し、通信が復旧しています。これがフェイルオーバーです。実際にはフェイルオーバーの瞬間に数百ミリ秒〜数秒の断が発生しますが、今回の ping 間隔（約1秒）ではパケットロスとして検出されませんでした。TCP 通信であれば再送で自動復旧するため、アプリケーション側への影響は最小限に抑えられます。

次に、切断した eth1 を復帰させます。

実行コマンド:

$ sudo nmcli connection up bond0-port1

実行結果:

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/19)

復帰後の状態を確認します。

実行コマンド:

$ grep 'Currently Active' /proc/net/bonding/bond0

実行結果:

Currently Active Slave: eth2

eth1 を復帰させても、Currently Active Slave は eth2 のままです。active-backup モードでは、障害復旧した NIC はスタンバイとして待機に戻ります。不要な切り替え（フラッピング）を防ぐための動作です。

現場では、サーバー管理者が気づかないうちにフェイルオーバーが起きていることがあります。ある日 /proc/net/bonding/bond0 を確認したら Link Failure Count が 0 でなくなっていた、というのが発見のきっかけになることもあります。定期的な監視の重要性がここにもあります（監視については第32回で学びます）。

やってみよう

ここまでの内容を、手順を見ずに一人でできるか試してみてください。

課題: ボンディングの構成・フェイルオーバー・解除を一人で完了する

1. まず次のセクション「ボンディングを解除する」の手順でクリーンアップし、ボンディング構成前の状態に戻す
2. 手順を見ずに bond0 を構成する（active-backup、miimon=100、IP: 10.0.1.1/24）
3. alma-sub（10.0.1.3）への疎通を確認する
4. アクティブな NIC を切断してフェイルオーバーさせ、通信が継続することを確認する
5. 切断した NIC を復帰させ、スタンバイとして待機していることを確認する
6. 最後にボンディングを解除し、元の状態に戻す

ヒント: 手順の順番を間違えると動作しません。特に「旧接続の停止」と「ポートの個別起動」を忘れないようにしてください。詰まった場合は、記事の手順に戻って確認してください。

ボンディングを解除する（クリーンアップ）

ボンディングの演習が終わったら、元の状態に戻します。第21回と次回の第22回は発展トピックであり、第23回以降ではボンディングが構成されていない状態が前提です。

alma-mainで実行します。

ボンディング関連の接続を削除します。

実行コマンド:

$ sudo nmcli connection delete bond0-port1

実行結果:

接続 'bond0-port1' (65a29b6e-fae6-4297-a9fe-142681816720) が正常に削除されました。

実行コマンド:

$ sudo nmcli connection delete bond0-port2

実行結果:

接続 'bond0-port2' (79b9aa90-c361-40de-b342-cc7db213551a) が正常に削除されました。

実行コマンド:

$ sudo nmcli connection delete bond0

実行結果:

接続 'bond0' (d8910bc9-3a60-4883-b02f-6b2b210462c9) が正常に削除されました。

UUID は環境によって異なります。ポートを先に削除してから bond0 本体を削除する順番で実行します。

元の接続を復旧します。

実行コマンド:

$ sudo nmcli connection up internal1

実行結果:

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/20)

実行コマンド:

$ sudo nmcli connection up internal2

実行結果:

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/21)

元の状態に戻ったか確認します。

実行コマンド:

$ nmcli device status

実行結果:

DEVICE  TYPE      STATE            CONNECTION
eth0    ethernet  接続済み         eth0
eth1    ethernet  接続済み         internal1
eth2    ethernet  接続済み         internal2
eth3    ethernet  接続済み         intersystem
lo      loopback  接続済み (外部)  lo          

eth1 が internal1、eth2 が internal2 に戻り、bond0 が消えていれば元通りです。

SP4 スナップショットへの復元

手動でのクリーンアップに加えて、第21回・第22回の演習が完了したら SP4_pre-bonding スナップショットに復元してください。これにより、ボンディングや VLAN の設定が残っていない状態で第23回に進むことができます。

ホストPCで実行（PowerShell を管理者権限で起動）:

実行コマンド:

PS> Stop-VM -Name 'alma-main' -Force
PS> Restore-VMSnapshot -VMName 'alma-main' -Name 'SP4_pre-bonding' -Confirm:$false
PS> Start-VM -Name 'alma-main'

復元後、SSH で alma-main に接続し、nmcli device status で bond0 が存在しないことを確認してから第22回（または第23回）に進んでください。

まとめと次回予告

今回のポイントを3つにまとめます。

• ボンディングは NIC 冗長化の基本技術 — 複数の物理 NIC を1つの論理インターフェース（bond0）に束ねることで、NIC 障害時に自動で切り替わりサービスを維持できる
• active-backup モードが最もシンプル — スイッチ側の設定が不要で、1枚がアクティブ、もう1枚がスタンバイとして待機する。障害時に自動で切り替わる（フェイルオーバー）
• 構成手順は順番が重要 — bond0 作成 → ポート追加 → IP設定 → 旧接続停止 → bond0 起動 → ポート起動。手順を飛ばすと通信できない

ボンディングの詳細なオプションは modinfo bonding で確認できます。ここで紹介しなかったパラメータ（updelay、downdelay など）もありますが、必要になったときに調べれば十分です。

次回の第22回「VLAN」も発展トピックです。1つの NIC 上に論理的にネットワークを分割する技術を学びます。第22回もスキップ可能で、第21回・第22回の演習がすべて完了したら SP4 に復元して第23回に進んでください。

理解度チェック

以下の文が正しければ「○」、誤りなら「×」と答えてください。

以下、解答です。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1回〜第3回）

• 第1回 エンジニアの仕事と学び方
• 第2回 作業記録と報連相
• 第3回 セキュリティ意識の基本

フェーズ2: Linux基礎（第4回〜第15回）

• 第4回 Linuxとは何か＋環境確認
• 第5回 SSH接続とターミナル操作
• 第6回 ファイルシステムとディレクトリ構造
• 第7回 基本コマンド（ファイル操作）
• 第8回 基本コマンド（テキスト処理・パイプとリダイレクト）
• 第9回 viエディタ
• 第10回 ユーザーとグループ管理
• 第11回 パーミッションと所有権
• 第12回 プロセス管理
• 第13回 systemd
• 第14回 シェルスクリプト入門
• 第15回 フェーズ2まとめ演習

フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）

• 第16回 ネットワーク基礎
• 第17回 ネットワーク設定と疎通確認
• 第18回 企業ネットワークの仕組み
• 第19回 パッケージ管理
• 第20回 ファイアウォール（firewalld）
• 第21回 ボンディング/チーミング（この記事）
• 第22回 VLAN
• 第23回 ログ管理
• 第24回 cron / systemd timer
• 第25回 ストレージ管理（LVM）
• 第26回 シェルスクリプト実践
• 第27回 SSH応用

フェーズ4: サーバー構築と運用（第28回〜第36回）

• 第28回 SELinux
• 第29回 Webサーバー構築（Apache/Nginx）
• 第30回 データベース基礎（MariaDB）
• 第31回 バックアップと復旧
• 第32回 監視入門
• 第33回 セキュリティ実践
• 第34回 Git基本操作
• 第35回 自動化と構成管理（Ansible）
• 第36回 トラブルシューティング（総合演習・最終回）