TCP SACK漏洞修复的网络性能回归
2019年8月2日更新:添加到解释我们的内核补丁和我们发现的其他细节。
6月17日,三个弱点在Linux网络堆栈中发布。最严重的可能会让远程攻击者影响系统的可用性。我们相信能够为客户提供最安全的映像,因此我们迅速应用了内核补丁来解决这些问题。
自从应用内核补丁以来,我们观察到某些工作负载在Amazon Web Services (AWS)平台上经历了意外的、不确定的性能下降,表现为对S3的冗长或挂起写入。bob体育客户端下载我们在Microsoft Azure上没有观察到任何性能下降。尽管在不到0.2%的病例中可以观察到这些回归,但我们想与您分享到目前为止我们的发现和缓解策略。
症状
这种行为可以在任何Databricks Runtime / Apache Spark版本中体现出来。受影响的客户将看到在Databricks集群上运行的Spark作业变慢,可能会“挂起”15分钟,或者在写入Amazon S3时由于超时而完全失败。客户可能会在Databricks中看到类似的堆栈跟踪集群日志:
org.apache.spark.SparkException:...截断……导致:com.amazonaws.services.s3.model.AmazonS3Exception:您到服务器的套接字连接是不读从或写到超时时间内。空闲连接将被关闭。
客户还可以查看Spark web UI,发现一个或多个任务与同一阶段的大多数其他任务相比花费了异常长的时间。
由于安全补丁是在6月24日应用到Databricks平台上的,所以性能的任何变化都将恰好在这一天发生。bob体育客户端下载在6月24日(或之后)正常运行,后来经历了性能衰退的作业与此问题无关。
根本原因
TCP SACK DoS漏洞为披露2019年6月17日。它使远程攻击者能够在端口上接受流量的服务器上触发内核恐慌。
我们的基础设施安全团队立即对这个问题进行了分类,并决定在我们的常规安全发布列车上将补丁发送到这个CVE。我们以新的Amazon Machine Image (AMI)的形式发布了这个更新,它形成了操作系统的基本映像,我们在操作系统上运行包含Databricks Runtime的LXC容器。
在推出补丁后不久,我们在内部基准测试的一个非常小的子集和一些客户作业中发现了不确定性异常。例如,写入Amazon S3的短短5分钟的数据处理作业需要一个小时才能完成。
使用内部基准测试的再现,我们分析了Databricks集群和Amazon S3之间的网络流量。没有补丁的集群在写入Amazon S3时表现出预期的行为,始终在90秒内完成写入:
但是,在带有安全补丁的集群上运行的相同代码会经历短时间的数据传输到Amazon S3,然后长时间不活动。下面是一个花了15分钟完成的工作示例:
缓解策略
我们仍在积极调查该问题,以确定根本原因。修复这种不确定的性能回归可能需要另一个操作系统级别的补丁。同时,安全性是我们的默认,我们将继续发布我们所能提供的最安全的内核。我们会尽快向大家发布最新消息。
幸运的是,Spark和Databricks的平台从一开始就被设计用来缓bob体育客户端下载解这些类型的长尾分布式系统问题。客户可以在Apache Spark中通过设置“Spark . Spark”来开启任务推测。猜测”向“真实”转变集群配置为了缓解这个问题。这个功能最初是为了在机器减速的情况下减少掉队。当启动推测时,Spark将启动长时间运行的慢速任务的副本并重试它,副本任务极有可能在不影响性能回归的情况下快速完成。
对于不希望利用任务推测并可以接受不同安全威胁模型的客户,我们的支持团队可以与您合作,提供替代的缓解策略。请与您的客户经理或(电子邮件保护)如果您受到影响并需要帮助,请确定解决方案。
2019年8月2日更新
我们的ami使用未修改的Ubuntu 16.04映像用于操作系统,该映像由Linux 4.4.0内核支持。我们的套接字默认使用TCP SACKs (S3服务器也是如此),因此我们通过从更新来修补TCP SACKs漏洞4.4.0-1084-aws # 94 - ubuntu来4.4.0-1085-aws # 96 - ubuntu.随着我们继续追踪这个问题,我们了解到4.4.0-1087-aws # 98 - ubuntu包括三个更多的TCP sack相关补丁。其中一个补丁是为了修复SO_SNDBUF低的套接字的性能。虽然我们使用默认的16KB SO_SNDBUF,但我们应用了更新,但没有看到任何改进。一个额外的上游补丁于7月19日发布,以修复低SO_SNDBUF套接字的另一个极端情况。由于它还没有被整合到Ubuntu 16.04中,但我们用该补丁构建了一个自定义映像,它解决了网络性能问题。我们将跟进更详细的分析。