首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >将AWS函数放入VPC,然后"IOException:由对等方重置连接“开始发生,但只是偶尔发生

将AWS函数放入VPC,然后"IOException:由对等方重置连接“开始发生,但只是偶尔发生
EN

Stack Overflow用户
提问于 2020-08-24 01:52:56
回答 1查看 782关注 0票数 4

我有一个函数,通过API网关充当API。在过去的几个月里,它一直在全天候运行,以前从未出现过这样的错误。

今天,我做了一个更新,添加了Elasticache,这要求我将Lambda放入与弹奏which相同的VPC中。在此之前,Lambda没有分配给任何VPC,只是正常运行。

经过大量的配置调整后,我似乎终于让它起作用了-- Lambda JAR现在能够连接到Elasticache,同时仍然可以连接到它所需要的其他东西。

但是,在部署之后的几分钟,我开始从一个算法调用中得到这个错误:

代码语言:javascript
复制
java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer
at org.apache.http.concurrent.BasicFuture.getResult(BasicFuture.java:71)
at org.apache.http.concurrent.BasicFuture.get(BasicFuture.java:102)
at com.algorithmia.algo.FutureAlgoResponse.get(FutureAlgoResponse.java:41)
at <place that we invoke it>

发生错误的调用代码非常简单:

代码语言:javascript
复制
        FutureAlgoResponse futureAlgoResponse = algo.pipeAsync(<stuff>);
        AlgoResponse result = futureAlgoResponse.get(3L, TimeUnit.SECONDS);

更重要的是,它已经投入生产了近一年,从来没有这个错误。

所以我想这肯定和VPC有关!但是,它大部分时间都起作用。我们每隔几秒钟运行一次这段代码,它每隔几分钟就会失败一次。当它失败时,它通常会在一列1-3个请求中失败.

我们的Lambda被设置为15 s超时,失败的请求在~1之后响应,并且重申,直到我们今天将Lambda移动到VPC之前,我们从未见过此错误。

Lambda配置感觉相当混乱和复杂,所以我肯定我在某个地方搞砸了一些东西。但是,它每隔几分钟只发生几次,这使我很难用有限的AWS知识进行调试。我希望有人能分享一些可能的原因!

下面是我是如何完成设置的:

gateway.

  • Enable
  • 在VPC中创建一个新的VPC
  • 创建两个子网(和相应的路由表),一个公共和一个私有
  • 为VPC创建一个因特网网关,一个NAT网关用于公共子网。
  • 为该安全组分配一个弹性IP给NAT
  • (可能不需要传入)

<代码>H 113在该VPCh 214/code>H 115/code>中划分一个弹码缓存--特别是私有子网+上述安全组H 216。

老实说,我一点也不知道如何进一步研究这个问题,所以我真的希望有人知道“哦,是的,连接可以在VPC中超时,因为_____”。或者,希望有任何关于如何更好地调试这一点的提示。

编辑:一些更多的搜索表明,它可能与NAT设置有关?基本上,我只是做了一个默认的“创建NAT网关”,并把它扔到私有子网上。

EN

回答 1

Stack Overflow用户

发布于 2020-08-24 16:26:26

亚马逊的支持提供了诊断和解决方案!

是的,暂停是问题所在。建议的解决方法是实现TCP保持活动,使350秒空闲超时没有达到(或者只是有更多的通信量,这对我们并不有效)。

我们最终所做的只是摆脱了Elasticache。这是我们需要将Lambda放在VPC中的唯一原因,在考虑了这一点之后,我们决定还需要一段时间才能使我们的流量达到我们真正能感受到的Elasticache的好处(而不是一个简单的EC2托管的Redis实例)。所以现在我们的缓存只是一个运行在EC2上的普通Redis实例。

以下是完整的答复:

“.然而,在过去的两天里,我确实看到了一些NAT网关空闲超时,您怀疑这可能是问题所在。请参阅下面的NAT网关指标。

这样,IdleTimeoutCount度量就可以计算从活动状态转换到空闲状态的连接数量。如果活动连接没有优雅地关闭,并且在最后350秒内没有活动,则转换为空闲。大于零的值表示存在已移动到空闲状态的连接。如果IdleTimeoutCount的值增加,它可能表明NAT网关后面的客户端正在重用陈旧的连接。

正如故障排除文档中提到的,为了防止连接被删除,您可以在连接上启动更多的通信量。或者,如果可能的话,还可以在实例上启用值小于350秒的TCP保持活力。在固定的时间间隔发送保活探测将确保通过NAT网关和远程终端服务器之间的连接存在一些通信量。保活数据包将重置350秒空闲超时计数器,从而使连接在应用程序需要时保持正常运行。

回答你的问题:“这到底是怎么回事?”

答:在验证了从VPC的角度来看,所有事情都是为了Lambda函数(SG、NACL、路由表),NAT网关空闲超时在这里是绝对可能的。以上提供的IdleTimeoutCount度量也证实了这一点,表明由于不活动,连接正在超时。“

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/63553768

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档