eBay大数据安全合规系列 - 系统篇

作者|姚科文

编辑|陈乐

供稿|DI Hadoop team

本文共5171字，预计阅读时间15分钟

更多干货请关注“eBay技术荟”公众号

前言

既要做功能优化，又要做安全合规，已经是目前绝大多数互联网公司技术开发人员的常态。而且随着时间的推移，可以预见安全合规会越来越被重视,这也就意味着技术开发人员在安全合规上投入的比重将会越来越大。eBay大数据组为了匹配整个公司在安全合规上的需求，分别从数据本身、数据应用开发相关流程，以及数据存储和计算所依赖的底层操作系统和硬件，这几个纬度都设计了与安全合规相关的需求，并且开展了对应的应用和产品研发工作。本文是ebay大数据组安全合规方面的第一篇文章，尽请期待后续。

背景

本人于2018年年初加入eBay大数据组（以下简称本组），之后一直专注于eBay大数据集群底层的开发和运维工作以及与之相关联的安全合规方面的需求。为了不断匹配整个公司对安全合规的需求，本人经历了三个阶段，目前在往达到第四个阶段的目标努力。

01

阶段一：

 eBay大数据集群还是直接部署在物理机上的背景下,实现了所有集群几万台物理机的操作系统从CentOS6升级到CentOS7。

02

阶段二：

实现了生产环境的所有大数据集群100%上云，从物理机迁移到了eBay TESS 架构之上（TESS 是 k8s 在 eBay的 内部实现[1])

03

阶段三：

实现了No Maintenance Window（无宕机时间窗口）前提下大数据集群几万个k8s Node的操作系统的季度性重启和补丁升级。

04

阶段四：

在阶段三的前提下，把重启和补丁升级从季度缩短到月度，除此之外，从只升级k8s Node操作系统补丁扩展到还要升级k8s Pod 用的docker image 的补丁。

在这个过程中本人经历了很多挑战也摸索出很多方法，写这个文章的时候正值上海疫情期间，居家隔离，正好有机会适当停下来花点时间把挑战和相关经验记录在本文中，即分享给大家又给自己过去4年做一个阶段性总结。

现状和挑战

     首先我从各个纬度详细分析一下我们eBay大数据组和大数据集群的现状。并基于此现状总结出为了达到阶段四所遇到的各种挑战。

1

现状一：

从应用功能角度，eBay大数据集群特点是数据存储量大，数据计算繁忙且用户复杂。eBay大数据集群存储远远超过PB接近EB级别，日常数据计算任务10万以上。而且由于历史原因eBay大数据集群不是单一的批处理跑报表的集群，而是支持了多种不同需求的客户群体，即有公用集群又有专用集群，既能支持批处理，又能支持近实时查询（Adhoc Query [2]），还有特殊集群专门服务eBay Kylin[3]，eBay CAL[4]和eBay搜索索引等各种特殊用户。

2

现状二：

从部署维护角度，eBay大数据集群部署是横跨3个数据中心，横跨多个k8s集群，维护了几万台k8s node。而且日常运维也十分繁忙，因为除了我们本身的运维需求之外，我们依赖的数据中心团队，硬件团队，网络团队也都有各自的安全合规需求，他们也要扩容机架，要维护大数据机器的固件硬件，或者升级交换机等等。

3

现状三：

从组织架构角度，eBay大数据组在过去几年已经基本实现了运维自动化，所以撤销了专门的运维团队，团队成员基本是开发角色[5]，日常是依赖Delos（eBay大数据运维自动化平台）来实现日常维护，偶尔需要人工介入的情况发生也是由开发团队充当值班角色来处理。

所以我们遇到的挑战也很明确，展开如下：

1

挑战一：

没有专门的运维团队资源，如何实现阶段四的目标？从方法论角度来看，再困难的事情只要投入足够的资源肯定能做到，比如为了完成这个月度目标，eBay大数据组又回到从前专门成立一个运维值班组，几个人轮流值班日以继夜地一直不停重启机器升级补丁，但这不是正确的事情，所以我们需要选择更困难的持续优化自动化平台来代替人力这条路。

2

挑战二：

如何协调阶段四目标和其他运维需求？基于上面现状分析我们知道，eBay大数据集群日常维护已经非常繁忙，如果我们以追求阶段四目标为最高优先级，拒绝其他一切维护需求，只有在本月完成这个目标之后，余下的时间才允许其他团队执行其他维护需求，这显然也是不可接受的。所以我们需要通过平台来协调各个运维需求，既保证可以同时进行，又不保证不能互相影响。

3

挑战三：

在重启和补丁升级过程中，保证集群整体可用性降低对用户的影响。因为不允许有宕机维护窗口时间，就预示着每时每刻集群都有机器在上线下线，而且eBay大数据集群用户复杂，存储和计算任务特点各不相同，如何做到对用户透明，不影响用户，本身就是最大的挑战。

4

挑战四：

在追求速度的同时，控制风险。虽然是月度重启但是我们需要考虑预留最后buffer和准备阶段以及处理应对最后10%-5%的重启失败补丁失败的长尾机器，所以我们估算下来，真正的重启过程只有2周到2周半的时间。在2周到2周半时间内要做到全部重启一遍几万台机器，速度就成为我们实现目标的最大瓶颈，我们的挑战是需要做到无人值守情况下全天候随时随地在重启，需要解决更多更快的重启机器同时保证集群不丢数据，集群的capactiy有富余和集群不会发生事故。

解决方法

关于以上不同挑战，既需要我们从平台上设计整体的解决方案来解决运维冲突，实现低人力成本高度自动化和最后控制风险，又要深入到各个具体应用来优化相关应用启动和停止的代码，实现单个机器优雅的重启才能做到对用户透明，不影响用户。我们开发了大数据集群升级系统并配合各个应用层面相关的优化来解决以上所有挑战。接下来从系统总体设计和各个应用的具体优化来两个方面来做详细描述。

1.系统总体设计

首先先介绍本系统基于两大依赖Delos (eBay Hadoop 大数据集群运维平台)和 PDB（k8s Pod Disruption Budget [6]）

Delos 是eBay 管理Hadoop 集群的平台，目前基本上几乎所有的集群运维操作都是通过Delos 界面或者 Delos 自动化程序来执行。比如集群管理员可以通过Delos界面灰度更新配置，升级源代码包，扩容集群和下线机器，又比如Delos本身就会自动化监控集群中磁盘的指标并把有坏磁盘的节点下线送往数据中心修坏盘，同时又会自动化的把坏盘已经修好的机器加回集群。

PDB是Kubernetes的概念，指的是由用户或者管理员主动发起的，在k8s集群中的应用受到底层Infrastructure发起的可控的中断（disruption）。举个例子，部署在Kubernetes的每个App都可以创建一个对应PDB Object，用来限制中断时最大可以down的副本数或者最少应该保持Available的副本数，以此来保证应用的高可用。

接着介绍我们的系统，上图是系统模块图，最底部紫色是我们大数据集群，为了兼顾增加速度和控制风险，我们采用混合PDB设计原则，大集群以Rack（机架）为最小粒度建PDB，小集群以POD（节点）为最小粒度建PDB。中间就是我们设计的升级系统，包含三个核心模块，其中PDB Notification API 和 TESS Master 交互用来接受通知。预处理和恢复引擎负责和Delos交互来负责重启前优雅下线工作和重启后恢复流量工作。监控引擎像一个第三方一直独立进行各个纬度的审计工作，一旦发现问题就中断流程或者发出报警让值班介入。Delos 负责和各个应用下线和上线工作，TESS Master负责具体K8s Node重启和补丁升级工作。

上图是主要流程图，具体流程是TESS（eBay K8s 云平台）发布完这个月补丁的镜像，然后开启所有Hadoop集群所在K8s集群的升级通知。TESS Master发现当前无正在升级的节点，就基于PDB Notification API，通知预处理和恢复引擎，该引擎根据相应的编排可以知道决定开启哪些PDB。开启之后通过Delos交互执行各个应用下线操作，完成下线操作才真正打开PDB，让TESS Master升级补丁和重启机器。重启和补丁完成，TESS Master通过PDB Notification API 通知预处理和恢复引擎，来关闭PDB并恢复流量，同时为迎接下一次通知做准备。如此循环，来达到全天候无人值守的自动化升级目标。下面是一些额外内部实现细节。

一、编排标准

1. 每个集群可以至少打开一个PDB升级

2. 如果这个集群有计算和存储不同节点，那么计算可以打开1-2个PDB，存储节点可以打开1个PDB

3. 如果有两个集群分别在不同数据中心属于互为灾备，那么这两个集群同属于一个虚拟集群，按照标准1，可以防止互为灾备的集群被同时升级。

4. 排除正在被Delos执行其他运维操作的rack所属的PDB

5. 在剩余一堆可选的PDB中，随机挑选一个。

二、监控设计

三 终端界面设计

1. 展示目前有哪些Rack或者Node正在被升级，哪些已经完成升级。

2. 针对已完成升级或者未升级的rack或者node 可以执行操作。

3. 针对正在升级的rack或者node，允许提交操作指令进队列，等升级完成之后再真正执行操作。

2.各个应用的具体优化

eBay大数据集群目前部署的应用有HDFS、YARN、HBase以及Long-Running的Spark Driver[2]。我们已经解决了的问题如下，本文由于篇幅接下来会简单描述一下每个应用的优化案例，具体更加详细的内容请期待即将发表的后续文章。

• HDFS因为重启丢数据的问题。

• 重启导致HDFS NameNode 压力过大的问题。

• 重要的Spark Job，MapReduce Job以及Adhoc SQL因为重启而失败的问题。

• HBase Region读写超时以及因为重启导致Region分布不均衡的问题。

2.1 HDFS三副本多Rack部署

在升级过程中集群持续处于机器重启的过程，对于存储集群的影响无疑是巨大的。尽管说HDFS本身已经采用了三副本的模式来保证数据的高可用性，但是在我们的升级场景内，它的三副本部署模式对于数据的保护作用远远不够。

目前HDFS是按照三副本在2个rack的部署模式分布的。在我们的升级场景里，每次操作的粒度是一个rack，这就意味着每次会有block的2个副本无法访问，这就极大地增加了block missing的风险。于是，我们对block的副本部署模式（placement）进行了新的实现，实现了三副本三rack的部署效果。

对于历史数据的placement迁移，我们采用了在现有Fsck工具的基础上，扩展实现了部分新特性，最终达到了block placement平滑迁移的效果。总结来说，我们通过副本新部署模式结合Fsck的数据placement迁移，迁移过程持续2个多月，迁移近20亿个block，达到了最终集群所有数据三副本三rack的部署效果，从而极大地提高了集群数据的可用性，进而保证了我们集群升级的速度。

2.2 HDFS Maintenance模式

上面提到的HDFS多rack部署模式已经解决了升级过程中数据可用性的问题，不过我们在实际升级场景里还遇到了另外一个潜在问题。当DataNode因为升级处于out of service状态后，      NameNode这边发现了以后会对其上的副本进行replication操作，使其副本数重新达到期望副本数。但是升级的DataNode数往往很多，在最坏情况下会产生近千万规模的block副本复制。如此大批量的副本replication会对NameNode本身的正常处理造成一定影响。基于这一点，我们借鉴了社区HDFS Maintenance State[7]的原型设计实现了一种新的适用于我们升级场景的Maintenance模式。Maintenance模式里面一个重要的特性是它能够忽略maintenance状态节点的副本复制。在我们的升级过程里，我们只要将待升级的节点置为maintenance状态并且设置对应过期时间，在此时间内将不会进行任何与此节点相关的副本复制操作。

另外，为了增强此功能的实际实用性，我们实现了专门的dfsadmin命令来灵活控制DataNode的maintenance状态设置和切换。相较于社区强依赖于修改外部文件的方式来控制节点maintenance状态而言，命令行的方式能够达到更加方便灵活的使用效果。

2.3 HBase RegionServer 优雅下线和Region重新平衡

由于历史原因，Delos 之于 region server stop 操作非常粗暴，直接通过系统kill 命令，所以导致升级刚开始就严重影响了eBay hbase用户。所以，首先应用侧通过优化源码，提供了gracefully stop 脚本，gracefully stop 脚本会首先把region server 加入黑名单防止新流量进入，接着会把该节点上所有region 记录下来，并转移到其他节点。Delos 通过调用新脚本避免了hbase用户受影响，但是我们又发现了新的潜在风险，当升级完成，重新start regionserver之后 基于hbase master自身的balancer 逻辑需要很久才能实现region balance。造成当一个hbase集群完成升级，流量不均匀，有的rack 超负荷工作，有的rack 流量却少的可怜这样的风险。虽然HbaseMaster自身有重新均衡Region的功能，但是速度上达不到要求。所以应用侧又通过优化源码提供了post start 脚本，Delos 通过调研新脚步，在regionserver起来之后再把之前移走的region 重新带回来，实现快速balance，流量快速均匀来避免这个风险。

2.4 Node Manager 和 Long Running Spark Driver 优雅下线

优化运维操作，先动态设置Node Manager cpu 和 memory为0，不让Yarn调度新的job进来，然后等待目前正在跑的job结束。同时设置最大等待时长，防止job一直跑影响升级速度。

eBay为了替换teredata ，在提供adhoc sql 集群上优化了spark 执行引擎[2]，存在long running spark driver，针对此类应用，我们也优化了运维操作，会先通过call 接口，来停止job进入，同时等待现有job结束，才会stop node manager 和相关spark 进程。

未来工作

1.如何持续降低人力成本来处理长尾？

在运维和硬件角度，我们感受最深的就是老是有最后百分比的机器行为异常，比如重启失败，配置不是预期，补丁打不上等等，所以在这个自动化系统上线之后，最大人力投入就是处理这批人工，这是运维侧一个比较大的话题，我们今后工作重点也是需要一直摸索优化找到一个可行办法在处理长尾方面持续减少人力成本投入。

2 如何更直观地观察升级对用户侧的影响？

另外是系统的可观测性，我们目前的监控重点仅仅还是观察服务器端的各种核心指标来从侧面验证升级对用户的影响，但是如果从可观测性出发，我们今后需要更加深入到客户端的各种指标，通过集成模拟客户的黑盒测试结果到搜集统计真正客户侧job 成功率来验证和评估升级对用户侧的真实影响。

参考

[1]https://mp.weixin.qq.com/s/rR2k_t7I27WhaOte8za2Rg

[2]https://mp.weixin.qq.com/s/tZZAnfaVJOIIopB0iNIUEw

[3]https://mp.weixin.qq.com/s/U9Gem4RNvAP-AFQb9IrB7w

[4]https://mp.weixin.qq.com/s/vUrp6Nyj06lsq8mZGR2n8g

[5]https://mp.weixin.qq.com/s/hxNObPA1SsnI2wt0oAZ2qw

[6]https://kubernetes.io/docs/concepts/workloads/pods/disruptions

[7]https://issues.apache.org/jira/browse/HDFS-7877

往期推荐

点击“阅读原文”， 一键投递

              eBay大量优质职位虚席以待

                我们的身边，还缺一个你