【问题标题】:Intermittent DynamoDB DAX errors: NoRouteException during cluster refresh间歇性 DynamoDB DAX 错误:集群刷新期间出现 NoRouteException
【发布时间】:2018-06-16 13:24:38
【问题描述】:

通过 CloudFormation,我有一个设置,包括 DynamoDB 表、DAX、VPC、Lambda(位于 VPC 中)、安全组(允许访问端口 8111)等等。

一切正常,除非它不起作用。

我可以在 99% 的时间从我的 VPC 的 Lambda 访问 DAX。除了偶尔他们得到 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 次访问完全没问题。我的 CIDR IP 范围很广,所以我认为这与 EIN 配置无关……但是还有什么?

我唯一的提示是初始错误,指出“在集群刷新期间捕获异常”。究竟什么是“集群刷新”?它是如何导致这些故障的?

【问题讨论】:

    标签: aws-lambda amazon-dynamodb amazon-cloudformation amazon-dynamodb-dax


    【解决方案1】:

    “集群刷新”是 DAX 客户端使用的后台进程,用于确保其对集群成员状态的了解在某种程度上符合现实,因为 DAX 客户端负责将请求路由到集群中的适当节点。

    通常刷新失败不是问题,因为集群状态很少更改(因此可以重用现有状态),但在启动时,客户端“阻塞”以获取初始成员列表。如果失败,客户端将无法继续,因为它不知道哪个节点可以处理哪些请求。

    在 Lambda 冷启动期间创建连接 VPC 的 ENI 可能会稍有延迟,这意味着客户端在初始化期间无法访问集群(因此,“没有到主机的路由”)。一个 Lambda 容器正在运行它应该不是问题(如果出现网络故障,您可能仍然会在日志中看到异常,但它不会影响任何事情)。

    如果它只发生在冷启动期间,稍微延迟后重试应该能够解决它。

    【讨论】:

    • 嗨@jeff-hardy:在这种情况下,“无路由”似乎与冷启动无关(我们会在函数的整个生命周期中间歇性地看到错误)。新 DAX 集群的最初几个小时通常不会出现错误;然后慢慢地构建到约 50% 的 DAX 调用,但“无路由”失败。经过 40 小时的开发时间后,我们将弃船。我们认为问题可能在于 Amazon 的 Node.js amazon-dax-client 中的套接字连接池管理不善,这可能无法正确地重用/清理连接。 (该代码中有很多待办事项和“损坏”的符号。)希望新版本即将推出?
    • 所以“无路由”错误的数量增加了,但它至少部分有效?您收到的是失败的请求还是日志中的消息?
    • 嗨@jeff-hardy:是的,它部分工作。正如我所提到的,当 CF 堆栈在新区域中新启动一个小时左右时,它将可靠地工作,然后错误开始增加,直到几个小时后它们达到约 50% 或更多。我们在日志中收到“无路由”错误(有时但不总是带有“集群刷新”注释);我们总是同时收到失败的请求。我们在 amazon-dax-client 中发出警告,并看到很多连接重试(没有日志错误)......有时它们最终成功,有时多次失败导致错误日志/失败的请求。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2023-03-11
    • 1970-01-01
    • 2021-05-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-12-09
    相关资源
    最近更新 更多