Я новичок в DRBD и NFS, и сейчас я тестирую сервер DRDB с тактом, чтобы использовать его для общего ресурса NFS нашей компании.
Вся установка работает нормально, с каталогом состояний NFS, работающим на общем ресурсе DRDB, вместе с фактическим общим ресурсом.
Проблема, с которой я столкнулся, связана с тестируемым мной сценарием аварийного переключения. В сценарии аварийного переключения я создаю проблему, когда отключаю сетевое соединение (ifconfig eth0 down) на node1. Аварийное переключение работает отлично и выполняет свою работу примерно за 5 секунд, но когда я возвращаю его обратно (ifconfig eth0 up и запуск пульса службы, если он остановлен), для его восстановления требуется 3-5 минут, в течение которых NFS доля недоступна.
В веб-среде эти 3-5 минут довольно значительны для простоя. Это нормально? Что я делаю не так?
Я вставил наш файл drbd.conf ниже.
resource r0 {
protocol C;
startup {
degr-wfc-timeout 60; # 1 minute.
}
disk {
on-io-error detach;
}
net {
}
syncer {
rate 10M;
al-extents 257;
}
on tsa-dev-nfstest1 { # ** EDIT ** the hostname of server 1 (un
device /dev/drbd0; #
disk /dev/sdc1; # ** EDIT ** data partition on server 1
address 10.61.2.176:7788; # ** EDIT ** IP address on server 1
meta-disk /dev/sdb1[0]; # ** EDIT ** 128MB partition for DRBD on serve
}
on tsa-dev-nfstest2 { # ** EDIT ** the hostname of server 2 (un
device /dev/drbd0; #
disk /dev/sdc1; # ** EDIT ** data partition on server 2
address 10.61.2.177:7788; # ** EDIT ** IP address on server 2
meta-disk /dev/sdb1[0]; # ** EDIT ** 128MB partition for DRBD on serve
}
}
Во время разработки высокодоступного сервера NFS, поддерживаемого drbd, для моей компании я обнаружил, что для клиентов было несколько минут (до 10) простоя, когда кластерный IP-адрес возвращался на исходный узел после теста. В этой ситуации новое соединение было принято и обслужено немедленно, но уже подключенный клиент испытал время простоя в эти минуты.
Изучив сетевой трафик с помощью tcpdump, я обнаружил, что проблема заключается в том, что TCP-соединения не синхронизируются с порядковыми номерами и нуждаются в сбросе.
Я предлагаю вам использовать Pacemaker вместо Heartbeat для управления кластером. Если вы это сделаете, в реальных жизненных ситуациях Pacemaker сможет отправлять запросы STONITH (Shoot The Other Node In The Head), которые предотвратят возникновение этой ситуации. Обычно это перезагружает другой узел, и это определенно решает проблему TCP.
Также Pacemaker намного лучше, чем Heartbeat при мониторинге. Взгляните на эти сайты:
Включает ли ваша группа ресурсов heartbeat логический IP-адрес для NFS-службы?
Это должен быть ваш последний ресурс, который «поднимается», и первый, который «падает». Ваши клиенты должны использовать этот IP-адрес для доступа к NFS-сервису.
Если у вас есть определенный IP-адрес, вы можете попробовать использовать другой тип ресурса для IPAddr (IPAddr2, насколько я помню). В IP-стеке этот ведет себя немного иначе.
По сути, оба типа должны выполнять arp-трансляцию после появления IP-адреса, чтобы убедиться, что подключенные маршрутизаторы и коммутаторы переучивают свои мак-таблицы, чтобы они знали, куда пересылать пакеты после аварийного переключения.
В некоторых реализациях NFS вам также следует явно указать arp для уже подключенных клиентов. Для этого вы также должны отразить данные подключенного клиента на своем резервном узле.