Периодические ошибки DynamoDB DAX: NoRouteException во время обновления кластера

Через CloudFormation у меня есть настройка, включающая таблицы DynamoDB, DAX, VPC, Lambdas (живущие в VPC), группы безопасности (разрешающие доступ к порту 8111) и так далее.

Все работает, за исключением случаев, когда это не так.

Я могу получить доступ к DAX из своего VPC Lambdas в 99% случаев. За исключением того, что иногда они получают ошибки NoRouteException... по-видимому, случайным образом. Вот выходные данные CloudWatch для одной функции Lambda, каждый раз выполняющей одно и то же (получение DAX). Обратите внимание, как это работает, терпит неудачу, а затем снова работает:

/aws/lambda/BigOnion_accountGet START RequestId: 2b732899-f380-11e7-a650-cbfe0f7dfb3d Version: $LATEST
/aws/lambda/BigOnion_accountGet END RequestId: 2b732899-f380-11e7-a650-cbfe0f7dfb3d
/aws/lambda/BigOnion_accountGet REPORT RequestId: 2b732899-f380-11e7-a650-cbfe0f7dfb3d  Duration: 58.24 ms  Billed Duration: 100 ms     Memory Size: 768 MB Max Memory Used: 48 MB
/aws/lambda/BigOnion_accountGet START RequestId: 3b63a928-f380-11e7-a116-5bb37bb69bee Version: $LATEST
/aws/lambda/BigOnion_accountGet END RequestId: 3b63a928-f380-11e7-a116-5bb37bb69bee
/aws/lambda/BigOnion_accountGet REPORT RequestId: 3b63a928-f380-11e7-a116-5bb37bb69bee  Duration: 35.01 ms  Billed Duration: 100 ms     Memory Size: 768 MB Max Memory Used: 48 MB
/aws/lambda/BigOnion_accountGet START RequestId: 4b7fa7f2-f380-11e7-a0c8-513a66a11e7a Version: $LATEST
/aws/lambda/BigOnion_accountGet 2018-01-07T07:56:40.643Z    3b63a928-f380-11e7-a116-5bb37bb69bee    caught exception during cluster refresh: { Error: NoRouteException: not able to resolve address
    at DaxClientError (/var/task/index.js:545:5)
    at AutoconfSource._resolveAddr (/var/task/index.js:18400:23)
    at _pull (/var/task/index.js:18421:20)
    at _pullFrom.then.catch (/var/task/index.js:18462:18)
  time: 1515311800643,
  code: 'NoRouteException',
  retryable: true,
  requestId: null,
  statusCode: -1,
  _tubeInvalid: false,
  waitForRecoveryBeforeRetrying: false }
/aws/lambda/BigOnion_accountGet 2018-01-07T07:56:40.682Z    3b63a928-f380-11e7-a116-5bb37bb69bee    Error: NoRouteException: not able to resolve address
    at DaxClientError (/var/task/index.js:545:5)
    at AutoconfSource._resolveAddr (/var/task/index.js:18400:23)
    at _pull (/var/task/index.js:18421:20)
    at _pullFrom.then.catch (/var/task/index.js:18462:18)
/aws/lambda/BigOnion_accountGet END RequestId: 4b7fa7f2-f380-11e7-a0c8-513a66a11e7a
/aws/lambda/BigOnion_accountGet REPORT RequestId: 4b7fa7f2-f380-11e7-a0c8-513a66a11e7a  Duration: 121.24 ms Billed Duration: 200 ms     Memory Size: 768 MB Max Memory Used: 48 MB
/aws/lambda/BigOnion_accountGet START RequestId: 5b951673-f380-11e7-9818-f1effc29edd5 Version: $LATEST
/aws/lambda/BigOnion_accountGet END RequestId: 5b951673-f380-11e7-9818-f1effc29edd5
/aws/lambda/BigOnion_accountGet REPORT RequestId: 5b951673-f380-11e7-9818-f1effc29edd5  Duration: 39.42 ms  Billed Duration: 100 ms     Memory Size: 768 MB Max Memory Used: 48 MB
/aws/lambda/BigOnion_siteCreate START RequestId: 0ec60080-f380-11e7-afea-a95d25c6e53f Version: $LATEST
/aws/lambda/BigOnion_siteCreate END RequestId: 0ec60080-f380-11e7-afea-a95d25c6e53f
/aws/lambda/BigOnion_siteCreate REPORT RequestId: 0ec60080-f380-11e7-afea-a95d25c6e53f  Duration: 3.48 ms   Billed Duration: 100 ms     Memory Size: 768 MB Max Memory Used: 48 MB

Есть идеи что это может быть?

Предположительно, это не VPC, а безопасный доступ, поскольку доступ в 9/10 раз — это нормально. У меня широкий диапазон IP-адресов CIDR, поэтому я не думаю, что это связано с предоставлением EIN... но что еще?

Единственный намек, который у меня есть, - это начальная ошибка, в которой говорится: «Поймано исключение во время обновления кластера». Что такое «обновление кластера» и как оно может привести к этим сбоям?


person pjb    schedule 07.01.2018    source источник


Ответы (1)


«Обновление кластера» — это фоновый процесс, используемый клиентом DAX, чтобы убедиться, что его знания о состоянии членства в кластере в некоторой степени соответствуют действительности, поскольку клиент DAX отвечает за маршрутизацию запросов к соответствующему узлу в кластере.

Обычно сбой при обновлении не является проблемой, потому что состояние кластера редко меняется (и, следовательно, существующее состояние можно использовать повторно), но при запуске клиент «блокирует» получение начального списка участников. Если это не удается, клиент не может продолжить работу, поскольку он не знает, какой узел может обрабатывать какие запросы.

Может возникнуть небольшая задержка при создании ENI, подключенного к VPC, во время холодного запуска Lambda, что означает, что клиент не может получить доступ к кластеру (отсюда «Нет маршрута к хосту») во время инициализации. Когда работает контейнер Lambda, это не должно быть проблемой (вы все равно можете получить исключение в журналах, если есть сбой в сети, но это не должно ни на что влиять).

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

person Jeff Hardy    schedule 08.01.2018
comment
Привет, @jeff-hardy: Ни один маршрут в этом случае не связан с холодным запуском (мы периодически видим ошибки на протяжении всей жизни функции). Ошибки обычно отсутствуют в течение первых нескольких часов работы нового кластера DAX; а затем медленно наращивайте до ~ 50% вызовов DAX без сбоев маршрута. После 40 часов совместной разработки мы покидаем корабль. Мы считаем, что проблема, вероятно, связана с плохим управлением пулом соединений сокетов в клиенте Amazon Node.js amazon-dax-client, который может неправильно повторно использовать/очищать соединения. (В этом коде много задач и неверных обозначений.) Надеюсь, скоро появится новая версия? - person pjb; 09.01.2018
comment
То есть количество ошибок No route увеличивается, но он хотя бы частично работает? Вы получаете неудачные запросы или просто сообщения в журналах? - person Jeff Hardy; 11.01.2018
comment
Привет, @jeff-hardy: да, это частично сработало. Как я уже упоминал, он будет надежно работать, когда стек CF заново запускается в новом регионе в течение часа или около того, а затем количество ошибок начинает увеличиваться, пока через несколько часов они не достигнут ~50% или более. Мы получаем в журнале ошибки отсутствия маршрута (иногда, но не всегда, с примечанием об обновлении кластера); и мы всегда получаем неудачные запросы одновременно. Мы помещаем предупреждения в amazon-dax-client и видим множество повторных попыток подключения (без ошибок в журнале)... иногда они в конечном итоге завершаются успехом, иногда множественные сбои, приводящие к регистрации ошибок/неудачному запросу. - person pjb; 12.01.2018