「Keepalived」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
57行目: 57行目:
 
この state は、サービスが開始され、マスターの役割を引き継ぐ最も高い優先度を持つホストを決定する前に、ホストの初期役割を設定します。この設定により、より高い優先度を持つホスト A が VIP(仮想 IP アドレス)を管理し、ホスト A が応答しなくなった場合にのみ、ホスト B が VIP を引き継ぎます。デフォルトの切り替えまでの時間は 1 秒です。
 
この state は、サービスが開始され、マスターの役割を引き継ぐ最も高い優先度を持つホストを決定する前に、ホストの初期役割を設定します。この設定により、より高い優先度を持つホスト A が VIP(仮想 IP アドレス)を管理し、ホスト A が応答しなくなった場合にのみ、ホスト B が VIP を引き継ぎます。デフォルトの切り替えまでの時間は 1 秒です。
   
  +
=== モニタリング付きのフェイルオーバーセットアップ ===
=== Failover setup with monitoring ===
 
   
  +
以下は、keepalived と同じホストで動作するサービス(sshd)のフェイルオーバークラスターを提供します。
The following provides a failover cluster for service (sshd) running on the same hosts as keepalived.
 
   
  +
ホスト A で:
On host A:
 
   
 
{{hc|/etc/keepalived/keepalived.conf|<nowiki>
 
{{hc|/etc/keepalived/keepalived.conf|<nowiki>
100行目: 100行目:
 
</nowiki>}}
 
</nowiki>}}
   
  +
ホスト B で:
On host B:
 
   
 
{{hc|/etc/keepalived/keepalived.conf|<nowiki>
 
{{hc|/etc/keepalived/keepalived.conf|<nowiki>
139行目: 139行目:
 
</nowiki>}}
 
</nowiki>}}
   
  +
このセットアップは、フェイルオーバーホスト自体で動作する sshd サービスに対して、より動的なクラスターを提供します。両方のサーバーはバックアップ状態で開始し、nopreempt オプションにより、優先度が高いサーバーが障害後に戻ってきた場合でも、優先度が低いサーバーがマスターの役割を保持することができます。これにより、以前のマスターサーバーが再び動作を開始した際に VIP への接続が中断されるのを防ぎます。この設定には、ターゲットサービスがクラッシュした場合にサーバーの優先度を下げるプロセスの追跡も含まれています。
This setup provides a more dynamic cluster for the sshd service running on the failover host itself. Both servers start in the backup state and the nopreempt option allows the server with the lower priority to keep the master role even when the server with the higher priority returns after a failure. This prevents the interruption of connections to the VIP when the former master server comes back alive. The configuration also includes process tracking to reduce the priority of a server when the target service crashes.
 
   
 
=== Failover with load-balancing ===
 
=== Failover with load-balancing ===

2023年9月3日 (日) 20:44時点における版

Keepalived は、Virtual Router Redundancy Protocol(VRRP)を使用して高可用性機能とロードバランシングを提供する、Linux 仮想サーバー(LVS)クラスター用のフェイルオーバーおよび監視デーモンです。

インストール

keepalived パッケージを インストール してください。

keepalived.service有効化 してください。

設定

このサービスは /etc/keepalived/keepalived.conf で設定されます。

マスターとバックアップのフェイルオーバー設定

以下は、仮想 IP アドレスを共有する 2 つのサーバー/ルーターで高可用性クラスターを設定する基本的な設定を提供します。両方とも keepalived を実行している必要があります。

ホスト A で:

/etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101
    priority 20
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pass1234 
    }
    virtual_ipaddress {
        172.16.0.100
    }
}

ホスト B で:

/etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 101
    priority 15
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass pass1234
    }
    virtual_ipaddress {
        172.16.0.100
    }
}

この state は、サービスが開始され、マスターの役割を引き継ぐ最も高い優先度を持つホストを決定する前に、ホストの初期役割を設定します。この設定により、より高い優先度を持つホスト A が VIP(仮想 IP アドレス)を管理し、ホスト A が応答しなくなった場合にのみ、ホスト B が VIP を引き継ぎます。デフォルトの切り替えまでの時間は 1 秒です。

モニタリング付きのフェイルオーバーセットアップ

以下は、keepalived と同じホストで動作するサービス(sshd)のフェイルオーバークラスターを提供します。

ホスト A で:

/etc/keepalived/keepalived.conf
global_defs {
   notification_email {
     admin@example.net
   }
   notification_email_from lb1@example.net
   smtp_server mail.example.net
   smtp_connect_timeout 30
}

# enter failed state when the sshd process is down
vrrp_track_process track_sshd {
    process sshd
    delay 1
}

vrrp_instance VI_1 {
    state BACKUP
    nopreempt
    interface eth0
    virtual_router_id 101
    priority 20
    advert_int 1
    authentication {
        auth_type AH
        auth_pass key12345
    }
    virtual_ipaddress {
        172.16.0.100
    }
    track_process {
        track_sshd
    }
    smtp_alert
}

ホスト B で:

/etc/keepalived/keepalived.conf
global_defs {
   notification_email {
     admin@example.net
   }
   notification_email_from lb2@example.net
   smtp_server mail.example.net
   smtp_connect_timeout 30
}

# enter failed state when the sshd process is down
vrrp_track_process track_sshd {
    process sshd
    delay 1
}

vrrp_instance VI_1 {
    state BACKUP
    nopreempt
    interface eth0
    virtual_router_id 101
    priority 15
    advert_int 1
    authentication {
        auth_type AH
        auth_pass key12345
    }
    virtual_ipaddress {
        172.16.0.100
    }
    track_process {
        track_sshd
    }
    smtp_alert
}

このセットアップは、フェイルオーバーホスト自体で動作する sshd サービスに対して、より動的なクラスターを提供します。両方のサーバーはバックアップ状態で開始し、nopreempt オプションにより、優先度が高いサーバーが障害後に戻ってきた場合でも、優先度が低いサーバーがマスターの役割を保持することができます。これにより、以前のマスターサーバーが再び動作を開始した際に VIP への接続が中断されるのを防ぎます。この設定には、ターゲットサービスがクラッシュした場合にサーバーの優先度を下げるプロセスの追跡も含まれています。

Failover with load-balancing

Keepalived also provides load balancing with a number of possible algorithms (see keepalived.conf(5)).

This would be a simple example for HTTP load balancing that can be added to the above configuration:

/etc/keepalived/keepalived.conf
virtual_server 172.16.0.100 80 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    protocol TCP

    real_server 172.16.1.20 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 172.16.1.21 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 172.16.1.22 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
    real_server 172.16.1.23 80 {
        TCP_CHECK {
                connect_timeout 10
        }
    }
}

Alternatively, keepalived can also be used for failover with HAproxy acting as the loadbalancer.

Security considerations

The VRRP protocol used by keepalived does not provide significant security against attackers who are already on the same subnet. The main benefit of using authentication in this service is to protect against accidentally adding servers that disrupt an existing cluster. When using auth_type PASS, the password is sent in plaintext over the local subnet with every multicast packet. Using auth_type AH (IP Authentication Header) will provide slightly better resilience against attacks but basic disruption and attacks such as ARP spoofing are still possible. Use network restrictions to protect the VRRP traffic if security is a high priority for you, e.g. use an isolated subnet for the cluster and block VRRP traffic from other networks in your firewall.

See also