нужна помощь по keepalived с Ldap Высокая доступность mis c сценарий проверки - PullRequest
0 голосов
/ 08 мая 2020

Мне нужна помощь по keepalived с помощью Ldap High availability mis c сценарий проверки.

У нас возникла проблема с LDAP: внезапно пользователи не смогли войти в систему через приложения и su-ldapuser, это это происходило дважды.

В течение этого времени на первичных серверах LDAP установлено 600 подключений, а на вторичных серверах LDAP - 1000.

Все серверы приложений будут связываться с серверами поддержки активности (балансировщиком нагрузки) , в настоящее время у нас есть 2 фунтовых узла и 2 узла LDAP.

Дизайн LDAP активен и активен, если основной не работает, то запрашивает go второстепенному.

Итак, обнаруживаем причину root очень сложно, мы много пытались найти, поэтому мы хотели бы реализовать на уровне LB, если есть соединения с высоким, например, 600 или более, этот переключатель на вторичный сервер

Я обращаюсь сюда за предложениями по как реализовать в mis c проверить, является ли количество проверок соединений штрафом или любым другим параметром, который должен быть u sed для проверки содержимого, связанного с LDAP, для переключения на вторичный сервер. даже я не хочу делать s sh с lb для проверки содержимого ldap, мне нужен прямой logi c для проверки и переключения

В настоящее время , у нас есть как показано ниже для неправильного c скрипта проверки:

Скрипт мониторинга LB:

virtual_server 10.X.X.X 389 {
    protocol TCP
    !service_name ldap
    persistence_timeout 0
    sorry_server 10.X.X.X 389
    lb_kind DR
    real_server 10.X.X.X 389 {
        MISC_CHECK {
            misc_path "/monitor.sh 389 10.X.X.X"
            misc_timeout 6
        }
        weight 1
    }
    lb_algo rr
    delay_loop 15

Cat monitor. sh

#!/bin/bash
port=$1
ip=$2
timeout 1s /bin/bash -c "2>/dev/null >/dev/tcp/$ip/$port"
if [ $? -eq 0 ]
then
  echo "OK"
  RETURN_CODE=0
else
  echo "NOK"
  RETURN_CODE=1
fi

exit $RETURN_CODE

Спасибо, Субха sh Кумар.D

1 Ответ

0 голосов
/ 10 мая 2020

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

В зависимости от реализации вашего LDAP-сервера, ldapsearch для чего-то в rootDSE и проверка разумного ответа работает хорошо.

Я предполагаю, хотя вы и не раскрываете, что это некая «linux» настройка LDAP, которая генерирует журналы. Обычно эти журналы LDAP на стороне Linux предоставляют множество ответов.

Обычно в сценариях такого типа ios мы видим неправильную настройку разумного кэширования на стороне клиента Linux. Часто каждая команда, выполняемая на Linux, требует проверки авторизации и, следовательно, вызова LDAP. Даже "cd .."

...