Как настроить проверку tcp с помощью keepalived?

Пытаюсь настроить HA сервера бастиона. Обход отказа, балансировка нагрузки не нужна. Два сервера под управлением debian. bastion01 и bastion02. 192.168.0.10 и 192.168.0.11. Плавающий IP - 192.168.0.12.

Я начал с этих конфигураций:

bastion01:

global_defs {
   notification_email {
    dev@null.com
   }   
   notification_email_from lb1@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 101 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   
}

bastion02:

global_defs {
   notification_email {
     dev@null.com 
   }   
   notification_email_from lb2@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 100 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   
}

Это работает абсолютно замечательно. Подтверждено, что плавающий IP будет переходить при отключении любого из серверов.

Однако, это не работает в случае, когда ssh остановлен, но сам сервер все еще работает.

Для этого мне нужно добавить проверку TCP.

Похоже, что в документации keepalived есть пример:

http://www.keepalived.org/LVS-NAT-Keepalived-HOWTO.html

Однако их пример включает в себя балансировку нагрузки, что просто добавляет еще один уровень сложности, который меня не интересует.

Похоже, что речь идет о следующем блоке:

TCP_CHECK { connect_timeout 3 connect_port 22 }

Я попытался использовать свое лучшее предположение о том, как настроить это:

bastion01:

global_defs {
   notification_email {
     dev@null.com 
   }   
   notification_email_from lb1@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 101 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   
}

real_server 192.168.0.10 22 {
    weight 1
    TCP_CHECK {
        connect_timeout 3
        connect_port 22
    }   
} 

real_server 192.168.0.11 22 {
    weight 1
    TCP_CHECK {
        connect_timeout 3
        connect_port 22
    }
}

bastion02:

global_defs {
   notification_email {
     dev@null.com 
   }   
   notification_email_from lb2@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 100 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   
}

real_server 192.168.0.10 22 {
    weight 1
    TCP_CHECK {
        connect_timeout 3
        connect_port 22
    }   
} 

real_server 192.168.0.11 22 {
    weight 1
    TCP_CHECK {
        connect_timeout 3
        connect_port 22
    }
}

Но это не сработало, он не понял блоки real_server. Хорошо, возможно, я не могу обойтись только обходом отказа, возможно, проверка tcp является частью lb компонента keepalived, поэтому я должен использовать балансировку нагрузки здесь. Это нормально, не повредит. Итак... конфиги теперь стали (взяты прямо из http://www.keepalived.org/LVS-NAT-Keepalived-HOWTO.html ):

bastion01:

global_defs {
   notification_email {
    dev@null.com
   }   
   notification_email_from lb1@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 101 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   

}

virtual_server 192.168.1.11 22 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT 
    nat_mask 255.255.255.0

    protocol TCP 

    real_server 192.168.0.10 22 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            connect_port 22
        }
    }   

    real_server 192.168.0.11 22 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            connect_port 22
        }
    }   
} 

bastion02:

global_defs {
   notification_email {
    dev@null.com
   }   
   notification_email_from lb2@mydomain.com
   smtp_server localhost
   smtp_connect_timeout 30
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 101 
    priority 100 
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }   
    virtual_ipaddress {
        192.168.0.12
    }   

}

virtual_server 192.168.1.11 22 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT 
    nat_mask 255.255.255.0

    protocol TCP 

    real_server 192.168.0.10 22 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            connect_port 22
        }
    }   

    real_server 192.168.0.11 22 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            connect_port 22
        }
    }   
} 

Это просто прямо не работает.

Когда я останавливаю ssh на bastion01 и пытаюсь ssh на плавающий ip, я получаю отказ в подключении, ip не переходит на bastion02.

В логах на bastion01:

bastion01 Keepalived_healthcheckers[11613]: Check on service [192.168.0.10]:22 failed after 1 retry.
bastion01 Keepalived_healthcheckers[11613]: Removing service [192.168.0.10]:22 from VS [192.168.1.11]:22

Как убедить keepalived действительно переключать плавающий ip в случае сбоя проверки работоспособности TCP?

0
задан 8 August 2018 в 01:40
1 ответ

Если вам не нужна балансировка нагрузки, сценарии отслеживания предлагают аварийное переключение на основе проверок, выполняемых для вашей службы.

Сначала добавьте блок vrrp_script перед вашим vrrp_instance :

global_defs {
    enable_script_security
}

vrrp_script chk_sshd {
    script "/usr/bin/pgrep sshd" # or "nc -zv localhost 22"
    interval 5                   # default: 1s
}

Затем добавьте track_script в свой vrrp_instance ссылается на vrrp_script :

 vrrp_instance VI_1 {
    ... other stuff ...

    track_script {
        chk_sshd
    }
}

Хотя это и не является строго обязательным, enable_script_security и полное доменное имя исполняемого файла обеспечивают некоторые гарантии против злонамеренной активности и подавляют предупреждения в журналах. См. страницу руководства Keepalived для получения дополнительной информации.

3
ответ дан 14 January 2020 в 18:34

Теги

Похожие вопросы