DRDB и NFS: время простоя NFS при восстановлении после сбоя
Я довольно новичок в DRBD и NFS, и я нахожусь в процессе тестирования DRDB-сервера с биением, которое будет использоваться для общего ресурса NFS нашей компании.
Вся установка работает нормально, с каталогом состояния NFS, работающим на общем ресурсе DRDB вместе с фактическим общим ресурсом.
У меня проблема из-за сценария отработки отказа, который я тестирую. В сценарии отработки отказа я создаю проблему, в которой отключаю сетевое соединение (ifconfig eth0 down) на узле 1. Аварийное переключение работает потрясающе и выполняет свою работу примерно за 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
}
}
2 ответа
Включает ли ваша группа ресурсов пульса логический IP для вашей NFS-службы?
Это должен быть ваш последний ресурс, который выходит "вверх" и первый, который идет "вниз". Ваши клиенты должны использовать этот IP для доступа к NFS-сервису.
Если у вас есть определенный IP-адрес, вы можете попробовать использовать другой тип ресурса для IPAddr (насколько я помню, IPAddr2). Это ведет себя немного по-другому на IP-стеке.
Как правило, оба типа должны отправлять arp-широковещательную рассылку после появления IP-адреса - чтобы убедиться, что подключенные маршрутизаторы и коммутаторы переучивают свои mac-таблицы, чтобы они знали, куда направлять пакеты после аварийного переключения.
В некоторых реализациях NFS вы также должны явно подключать уже подключенных клиентов. Для этого вам необходимо отразить данные подключенного клиента на вашем резервном узле.
Во время разработки высокодоступного NFS-сервера с поддержкой drbd для моей компании я обнаружил, что для клиентов было несколько минут (до 10) времени простоя, когда кластерный IP-адрес возвращался на исходный узел после теста. В этой ситуации новое соединение было принято и обслужено немедленно, но у уже подключенного клиента произошли простои в эти минуты.
Изучив сетевой трафик с помощью tcpdump, я обнаружил, что проблема заключается в том, что TCP-соединения не синхронизированы с порядковыми номерами и требуют сброса.
Я бы посоветовал вам использовать Pacemaker вместо просто Heartbeat для управления кластером. Если вы это сделаете, в реальных жизненных ситуациях Pacemaker сможет выдавать запросы STONITH (Shoot The Other Node In The Head), которые предотвратят возникновение этой ситуации. В основном это перезагрузило бы другой узел, и это определенно решило бы эту проблему TCP.
Также Pacemaker намного лучше, чем Heartbeat при мониторинге. Посмотрите на эти сайты: