Мы запускаем приложение Java, распределенное по ряду серверов, часть из которых включает запись и чтение общих файлов. Эта сторона приложения в настоящее время объединяется с помощью набора заданий rsync cron, поэтому вариант замены ее монтированием EFS NFS, который решает проблему высокой доступности, был очень привлекательным.
Файлы записываются и обслуживаются серверами Tomcat и не являются критически важными, но иногда мы обслуживаем тысячи таких запросов каждую минуту. Наша инфраструктура локальная, поэтому EFS монтируется через VPN. Учитывая возможность возникновения проблем с сетью и неосновной характер файлов, мы решили, что мы скорее предпочтем работать без сбоев и ошибок, чем рискуем исчерпать пул потоков Tomcat, ожидающий недоступного ввода-вывода.
Для этого я посмотрел на время и ретрансляция параметры монтировать , чтобы установить эти значения на достаточно низком уровне, чтобы любые сетевые проблемы просто вызывали кучу ошибок ввода-вывода (с которыми приложение может справиться), а не кучу зависающих потоков. Я знаю, что AWS рекомендует не отказываться от время параметр ниже 150 (15 с), но следующее было сделано исключительно для проверки поведения параметров.
Я смонтировал общий ресурс с помощью следующей команды,
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,soft,timeo=50,retrans=1 MOUNT_IP:/ efs-test
перед тем, как отозвать доступ к fs с помощью AWS Security Group, и проверил, сколько времени прошло до возникновения ошибки ввода-вывода при попытке ls смонтированный фс. Глядя на монтировать На странице руководства и документации AWS я ожидаю, что доступ к монтированию завершится с ошибкой через 10 секунд - 5-секундный тайм-аут с одной повторной попыткой.
Таймауты для команды ls были следующими: 15 с, 17 с, 15 с, 10 с, 15 с, 20 с, 109 с, 15 с. ls: cannot access efs-test/: Input/output error
Тестирование монтирования с разными таймаутами и попытками повтора дало еще более непредсказуемые результаты. Я попытался воспроизвести это, установив локальный общий ресурс NFS, и не могу воспроизвести его непредсказуемый характер. Мы не можем запустить это в производство, пока есть вероятность двухминутного зависания потока даже из-за сетевой проблемы.
Кто-нибудь еще сталкивался с этой проблемой или может увидеть, где я ошибаюсь? Я не понимаю, почему эта проблема возникает только при монтировании из AWS, поскольку я ожидал, что тайм-аут ввода-вывода будет применен на стороне клиента.