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

Попытка настроить бастионные серверы HA. Аварийное переключение, балансировка нагрузки не требуется. Два сервера, на которых запущен Debian. бастион01 и бастион02. 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.

В логах на бастионе01:

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 ответов

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

Сначала добавьте 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 для получения дополнительной информации.

Источник
Другие вопросы по тегам