Posted inNetwork

Keepalived 設定ガイド: Linux 上で Virtual IP と高可用性を構築する

Network tutorial - IT technology blog
Network tutorial - IT technology blog

サーバー上の重要なサービスが突然停止したとき、不安を感じたことはありませんか？何千人ものユーザーがアクセスするウェブサイトが突然500エラーを返し、取引を処理中の決済システムが中断されるような状況を想像してみてください。

現代のデジタルビジネスにおいて、システムが数分間「ダウン」するだけでも、収益と評判に大きな損害を与えます。私もこの問題についてはこれまで多くの悩みを抱えてきました。特に24時間年中無休の稼働が必要なサービスにおいてはそうです。どのような問題が発生しても、サービスが常に利用可能であることをどのように保証すればよいのでしょうか？

現実の問題：重要なサービスが突然停止したらどうなる？

次のように想像してみてください。あなたは会社にとって非常に重要なEコマースサイトまたは社内アプリケーションを管理しています。すべてが順調に稼働していましたが、ある日突然、サーバーに問題が発生しました。ハードウェア、ソフトウェア、あるいは単なるネットワークエラーが原因かもしれません。顧客はアクセスできなくなり、従業員は仕事ができず、上司からのプレッシャーは増すばかり。そのときの気持ちは、決して快適なものではないでしょう？

高可用性（High Availability – HA）を必要とするシステムでは、ダウンタイムを最小限に抑えることが目標です。単一のサーバーは常に、単一障害点（Single Point of Failure – SPoF）となるリスクを内包しています。もしそのサーバーに問題が発生すれば、サービス全体が停止してしまいます。これは私を含め、多くのITエンジニアが避けたいシナリオです。

原因分析：なぜ単一サーバーがリスクを伴うのか？

単独のサーバーは、どれほど強力であっても、システム全体の「アキレス腱」となる可能性があります。サーバーが停止する一般的な原因には以下が含まれます。

  • ハードウェア障害: ハードディスクの故障、RAMのエラー、CPUの過熱、あるいはネットワークカードの「死」など。これらの障害は、予告なくいつでも発生する可能性があります。
  • ソフトウェア/OSエラー: 互換性のないアップデート、アプリケーションのバグ、または予期せぬOSの問題により、サーバーが動作しなくなる可能性があります。
  • ネットワーク障害: 回線の切断、ルーター/スイッチの問題、または誤ったネットワーク設定により、サーバーが外部からアクセスできなくなる可能性があります。
  • 人的ミス: 時には、管理者のわずかな設定ミスがシステム全体を「ダウン」させるのに十分なことがあります。

メインサーバーで障害が発生すると、サービスへのアクセスを意図していたすべてのトラフィックがブロックされます。顧客はウェブサイトにアクセスできないか、アプリケーションが応答しないことに気づくでしょう。

解決策：サービスを常に「生きている」状態に保つには？

単一障害点に対抗するための基本的な考え方は、冗長性（redundancy）を持つことです。これを実現するためのアプローチはいくつかあります。

  • ロードバランシング (Load Balancing): 複数のサーバー間でトラフィックを分散し、パフォーマンスを最適化し、耐障害性を向上させます。1つのサーバーが「ダウン」しても、残りのサーバーが要求を処理できます。ただし、HAとして設計されていないロードバランシングソリューション自体がSPoFになる可能性もあります。
  • クラスター (Clustering): 複数のサーバーを連携させて、論理的な単一ユニットとして機能させます。クラスターソリューションはより複雑で、通常、データ共有と状態管理が含まれます。
  • Virtual IP (VIP) の使用: これは非常に効果的で、多くの人に採用されている方法です。各サーバーに個別のIPを割り当てる代わりに、サービスを代表する「仮想」IPアドレス (Virtual IP) を使用します。このVIPは常にアクティブサーバーに属し、アクティブサーバーに問題が発生した場合、自動的にスタンバイサーバーに切り替わります。顧客はどの物理サーバーが要求を処理しているかを知る必要なく、常にVIPにアクセスします。

上記のソリューションの中で、Virtual IPは、特に複雑な状態共有を必要としないサービスにとって、高可用性を達成するためのシンプルでありながら非常に強力な方法として際立っています。そしてKeepalivedは、Linux上でVIPを簡単にデプロイするのに役立つ優れたツールです。

Keepalived：サービスを保護するための最適なソリューション

Webサーバー、データベース（レプリケーションを伴う）、プロキシサーバーなどのサービス向けに、軽量で信頼性の高いHAソリューションが必要な場合、Keepalivedは常に私の最優先の選択肢です。KeepalivedはVirtual IPを自動的にデプロイするのに役立ち、サービスがほとんど中断されないことを保証します。

Keepalived とは？

KeepalivedはLinux向けのオープンソースソフトウェアで、高可用性とロードバランシング機能を提供するように設計されています。しかし、その最も目立つ、そして最も広く使用されている機能は、VRRP (Virtual Router Redundancy Protocol) を実装してVirtual IPを作成することです。さらに、Keepalivedはサーバー上のサービスやアプリケーションの状態を監視することもできます。特定のサービスが停止した場合、Keepalivedは自動的にVIPをバックアップサーバーに切り替えることができます。

VRRP はどのように機能する？

VRRPは、ルーターまたはサーバーのグループが仮想IPアドレス（Virtual IP）を共有できるようにする標準プロトコルです。このグループ内には、マスターとして選出されるサーバーが1台と、残りのサーバーがバックアップとして存在します。基本的な動作原理は次のとおりです。

  • マスター: マスターサーバーはVirtual IPを保持し、VIPに送信されるすべてのパケットの処理を担当します。また、マスターは定期的に「アドバタイズメント」パケットをバックアップサーバーに送信し、自分がまだ稼働していることを通知します。
  • バックアップ: バックアップサーバーはマスターからのアドバタイズメントパケットをリッスンします。特定の間隔（通常は数秒）内にアドバタイズメントが受信されない場合、バックアップサーバーは自動的にマスターになり、Virtual IPを取得する権利を持ちます。
  • 切り替え (Failover): マスターに障害が発生すると、VIPは自動的にバックアップサーバーに切り替わります。このプロセスは非常に迅速で、通常は数秒で完了し、エンドユーザーにはほとんど透過的です。元のマスターが復旧した際、設定によってはVIPを取り戻す（プリエンプション）ことも、バックアップのままになることもあります。

このメカニズムにより、アプリケーションやDNSレコードをVirtual IPにポイントするだけで済みます。マスターまたはバックアップのどちらが稼働しているかに関わらず、サービスは常に同じIPアドレスを介してアクセスされます。

Keepalived のデプロイ：詳細ガイド

システム準備

Linuxサーバー2台にKeepalivedをデプロイする方法を説明します。ここではUbuntu Serverを使用しますが、CentOSなどの他のディストリビューションでも手順は同様です。

  • サーバー 1 (マスター): IP 192.168.1.10
  • サーバー 2 (バックアップ): IP 192.168.1.11
  • 仮想 IP: 192.168.1.100 (これはサービスが使用するIPです)

両方のサーバーが互いにping可能で、同じサブネットに属していることを確認してください。ネットワーク範囲、ブロードキャスト、使用可能なホスト数をすばやく計算する必要がある場合は、私がよく使用するtoolcraft.app/ja/tools/developer/ip-subnet-calculatorが便利です。CIDRを入力するだけで、必要な情報がすべて表示され、非常に便利です。

サーバーの現在のIP構成を確認します。

ip a show eth0 # またはネットワークカードの名前
# 出力例:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
#     link/ether 00:0c:29:ab:cd:ef brd ff:ff:ff:ff:ff:ff
#     inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
#        valid_lft forever preferred_lft forever

Keepalived のインストール

Keepalivedのインストールは非常に簡単です。オペレーティングシステムのパッケージマネージャーを使用するだけです。

Ubuntu/Debianの場合:

sudo apt update
sudo apt install keepalived -y

CentOS/RHEL/Fedoraの場合:

sudo yum install epel-release -y # 古いCentOS/RHELにはEPELリポジトリが必要です
sudo yum install keepalived -y

Keepalived の設定

Keepalivedのメイン設定ファイルは/etc/keepalived/keepalived.confにあります。マスターサーバーとバックアップサーバーで異なる2つの設定ファイルを作成します。

サーバー 1 (マスター) の設定

/etc/keepalived/keepalived.confファイルを開き、以下の内容を貼り付けます。ネットワークインターフェース名（eth0）、仮想IP（192.168.1.100）、認証パスワードなど、調整が必要な箇所に注意してください。

global_defs {
    router_id LVS_DEVEL # このルーターに一意のIDを設定します
    # LVS_DEVELはサーバーのホスト名に置き換えることができます。
}

vrrp_instance VI_1 {
    state MASTER             # 初期状態はMASTERです
    interface eth0           # VIPがバインドされるネットワークインターフェース名
    virtual_router_id 51     # VRRPクラスターの一意のID (1-255の間)。マスターとバックアップの両方で同じである必要があります。
    priority 101             # マスターの優先度 (バックアップよりも高い)
    advert_int 1             # アドバタイズメント送信間隔 (秒)
    authentication {
        auth_type PASS       # 認証タイプ
        auth_pass 1111       # 認証パスワード (両方のサーバーで同じである必要があります)
    }
    virtual_ipaddress {
        192.168.1.100/24     # あなたのVirtual IPアドレス
    }

    # サービス状態の監視 (オプション)
    # vrrp_script chk_httpd {
    #     script "killall -0 httpd" # httpdプロセスが実行中か確認します
    #     interval 2 # スクリプトを2秒ごとに実行します
    #     weight -20 # スクリプトが失敗した場合、優先度を20減少させます
    # }
    # track_script {
    #     chk_httpd
    # }
}
サーバー 2 (バックアップ) の設定

サーバー2の/etc/keepalived/keepalived.confファイルを開き、以下の内容を貼り付けます。主な違いは、stateがBACKUPであり、priorityがマスターよりも低いことです。

global_defs {
    router_id LVS_BACKUP # このルーターに一意のIDを設定します
}

vrrp_instance VI_1 {
    state BACKUP             # 初期状態はBACKUPです
    interface eth0           # ネットワークインターフェース名
    virtual_router_id 51     # VRRPクラスターの一意のID (マスターと同じである必要があります)
    priority 100             # バックアップの優先度 (マスターよりも低い)
    advert_int 1             # アドバタイズメント送信間隔 (秒)
    authentication {
        auth_type PASS       # 認証タイプ
        auth_pass 1111       # 認証パスワード (マスターと同じである必要があります)
    }
    virtual_ipaddress {
        192.168.1.100/24     # あなたのVirtual IPアドレス
    }

    # サービス状態の監視 (オプション)
    # vrrp_script chk_httpd {
    #     script "killall -0 httpd" # httpdプロセスが実行中か確認します
    #     interval 2 # スクリプトを2秒ごとに実行します
    #     weight -20 # スクリプトが失敗した場合、優先度を20減少させます
    # }
    # track_script {
    #     chk_httpd
    # }
}

重要事項: KeepalivedがVirtual IPをメインIPではないインターフェースに割り当てるには、ip_nonlocal_bindを有効にする必要があります。また、サーバーがパケットを転送できるようにするため、ip_forwardを有効にすることが必要ですが、VIPのみの場合には常に必須というわけではありません。

両方のサーバーで以下のコマンドを実行します。

sudo sysctl net.ipv4.ip_nonlocal_bind=1
sudo sysctl net.ipv4.ip_forward=1
# これらの変更を再起動後も保持するには:
echo "net.ipv4.ip_nonlocal_bind = 1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p # sysctl.confからの変更をすぐに適用します

起動と確認

両方のサーバーで設定が完了したら、Keepalivedを起動して状態を確認します。

両方のサーバーで:

sudo systemctl start keepalived
sudo systemctl enable keepalived # Keepalivedがシステム起動時に自動的に起動するように設定します
sudo systemctl status keepalived # サービスの状態を確認します

これで、Virtual IPがマスターサーバーのネットワークインターフェースに割り当てられているかを確認します。マスターのeth0インターフェースに192.168.1.100が表示されるはずです。

ip a show eth0
# マスターでの出力例:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
#     link/ether 00:0c:29:ab:cd:ef brd ff:ff:ff:ff:ff:ff
#     inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
#        valid_lft forever preferred_lft forever
#     inet 192.168.1.100/24 scope global secondary eth0 # <-- これがVIPです！
#        valid_lft forever preferred_lft forever

バックアップマシンでは、マスターに障害が発生するまでこのVIPは表示されません。Keepalivedのログを監視してその動作を確認できます。

sudo journalctl -u keepalived -f # リアルタイムでログを表示します
# または
sudo tail -f /var/log/syslog # 一部のシステムの場合

同じネットワーク内の別のマシンから、Virtual IP 192.168.1.100にpingを試してみてください。応答があるはずです。

ping 192.168.1.100

フェイルオーバー機能のテスト

これはHAシステムをテストするための最も重要なステップです。マスターサーバーの障害をシミュレートします。

sudo systemctl stop keepalived # Keepalivedサービスを停止します

直ちに、サーバー2（バックアップ）はマスターがアドバタイズしなくなったことを検出し、自動的にマスターに昇格してVirtual IPを引き継ぎます。サーバー2でip a show eth0を再度確認すると、192.168.1.100が表示されているはずです。

同時に、クライアントマシンからの192.168.1.100へのpingコマンドは、切り替え中にいくつかのパケット（通常は1～3パケット）を失う可能性がありますが、その後は正常に応答し続けるでしょう。

サーバー1（マスター）でKeepalivedを再起動すると、マスターの状態に戻り、VIPを取り戻します（優先度が高いため、これはプリエンプションと呼ばれます）。

sudo systemctl start keepalived # マスターを再起動します

サービスへのヘルスチェックの統合

Keepalivedは自身の状態を監視するだけでなく、サーバー上の他のサービス（例：Nginx、Apache、データベース）を監視することもできます。もしそのサービスが停止した場合、Keepalivedは自動的にサーバーの優先度を下げ、VIPをバックアップサーバーに切り替えることを強制できます。

たとえば、Nginxサービスの状態を確認するには、小さなスクリプトを作成できます。

sudo nano /etc/keepalived/check_nginx.sh

以下の内容をファイルに貼り付けます。

#!/bin/bash
if systemctl is-active --quiet nginx; then
    exit 0 # Nginxが実行中、スクリプト成功
else
    exit 1 # Nginxが実行中でない、スクリプト失敗
fi

スクリプトに実行権限を付与します。

sudo chmod +x /etc/keepalived/check_nginx.sh

その後、両方のサーバーの/etc/keepalived/keepalived.conf設定ファイルにvrrp_scriptとtrack_scriptセクションを追加します。

vrrp_instance VI_1 {
    # ... 他の設定 ...

    track_script {
        chk_nginx # 定義されたスクリプトの名前
    }
}

vrrp_script chk_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2 # スクリプトを2秒ごとに実行します
    weight -20 # スクリプトがエラー (exit 1) を返した場合、優先度を20ポイント減少させます
    # 例: マスターの優先度が101でNginxがダウンした場合 -> 優先度は81になります。
    # 優先度100のバックアップがマスターの権限を獲得します。
}

ファイルを保存し、両方のサーバーでKeepalivedを再起動します: sudo systemctl restart keepalived。これで、マスター上でNginxが停止した場合、VIPは自動的にバックアップに切り替わります。これは柔軟なメカニズムであり、物理サーバーだけでなくアプリケーションの高可用性も保証します。

まとめ

高可用性システムの構築は、ほとんどのオンラインサービスにとって、もはや選択肢ではなく必須要件となっています。Keepalivedは、Linux上でVirtual IPとHAをデプロイするためのシンプルで効率的かつ信頼性の高いソリューションを提供します。Keepalivedを使用することで、サービスの中断時間を大幅に削減し、評判を保護し、ユーザーにシームレスなエクスペリエンスを保証できます。このガイドの後、あなたは自分のサービスを安定性の新たなレベルに引き上げるための十分な知識と自信を持っていると信じています。

Share:
Tags: