通过Docker构建大数据平台(BigData on Docker)(文字版)

由 DSGBG · 发布日期 2016年4月13日 · 已更新 2016年4月19日

演讲者：星环科技首席架构师吕侣

文字整理：宋净超 TalkingData

本文是星环科技首席架构师吕侣在China HADOOP Summit 2016北京站上的演讲的文字版。

PPT下载请戳这里。

吕侣：我们星环科技从去年docker开始火起来的时候我们就开始关注如何在docker的环境下把我们星环科技的产品部署在上面，并且希望对大家做类似的事情有所启发。
   在做这件事的时候，我们就在想做这件事情要达到怎样的目标，有什么痛点。当时我们就总结有4个问题。首先，这个系统能够简化我们的部署流程，能够做到在一个地方开发完后，能够在非常多的地方部署到处运行。包括所有的公有云、私有云、包括裸机，甚至包括OpenStack里面的虚拟机。这些都不应该成为我们部署上面的瓶颈，以及部署上面的先决条件。不过在虚拟机上面也许有性能的问题，这是另外一个故事。
   其次我们应该同时支持大数据应用和普通应用。因为对于我们来说如果我们的平台只支持大数据应用的话，这个应用部署平台变成了大数据的专有平台，这样的专有平台对于后方的运维以及他们要上他们后来的应用就非常不方便。OK，不同应用也应该在我们的平台得到支持。第三，我们从非常多的客户里面发现，他们非常期望我们的平台里面有不止一个租户运行。他们希望各个部门都能启用它们的大数据分析平台。这些分析平台之间有环境和数据的隔离，也要有配额的隔离。比如说部门A运行一个大数据分析任务，不应该影响到部门B正在运行的大数据分析任务。第四，必须要支持大规模部署，因为我们是一个大数据公司。我们要有几百上千台机器的部署。除此以外，我们发现docker还有很多非常好的feature。我们希望我们的系统能够做到版本控制、灰度升级、配置管理以及消耗尽量少的性能就达到我们想要的feature。这么我们做这个系统当时定下来的目标。
   在做这件事情之前，我们先看下传统的Hadoop集群的部署。这是我们流行最广的cloudera和apache的方案。在这个方案里面每台机器都有个agent或ambari server会对这些机器进行环境的部署。对每一台host都会安装相应的程序并且进行相应的监控。但是在这样ambari server的环境下用户很难定制在里面跑到更新版本的程序。因为他们所有的程序都是安装在一个比较完成的根目录下面的。比如说两个程序互相依赖一些Hadoop扩展包，那么他们之间肯定是会打架的。然而不幸的是我们正好对Hadoop的一些底层的包进行修改，我们发现打架的概率是非常高的。
   这个是pivotal的方案。Pivotal引入了docker作为container 的解决。我们发现它是个很有意思的方案，它把每个container当成了刚才cloudera方案里面的物理机。然后每个container里面的内容通过phd进行配置，这样一来，每一个container里面的内容是一个相对隔离的内容。比如我要装两个不同的包，我可以起两个pdh进行不同的资源隔离和配置隔离。它最大缺点是它没有考虑到多机的情况，就是说它只能在一台机器上做开发的事情，没有说可以在一百台机器的集群上使用。
   接下来说下我们当时找到的方案。对于我们来说，我们想做这样一个平台，它具有能够同时运行大数据应用和普通应用的能力。那么我们对标了一下市场上拥有相同能力的程序，他们告诉我必须找到软件是一个IAAS、PAAS还是SAAS。然而我发现这些标准对于我们来说并不是那么适用，我想在我们这个系统里面我们事实上有不同的角色，而在PAAS里面只有两方，一方是平台的提供者，一方是平台的使用者。平台使用者不会有core第三方的知识或地方帮你做什么事情用这个服务。于是在这种情况下平台的使用者要么控制住所有数据和应用，于是有了控制权，他使用的所谓的PAAS服务。或者说我这个应用是由平台提供商提供的，我直接用这个程序提供的功能，比如我直接用数据库这个功能，所谓的database as a service也是SAAS的一种。然而在我们这样的环境里面我们发现，其实我们事实上没有办法让所有的软件都由我们来提供，所以有第三方的厂商在我们的平台上做各种各样的应用，而这些应用又要交付给最终的用户使用。对于最终用户来说SAAS是最为友好的，对于开发厂商来说他们要的是PAAS。在这样的情况下我们就想了一个办法，其实我们定义的是一个三方共建的生态圈，我吗提供一个应用部署平台，第三方软件提供商提供应用，最后最终用户使用这些软件。这就是我想说的第三方开发能够让最终用户使用软件的流程。由于最终使用者是最终用户的操作管理员，这些管理员需要对这些软件的启停以及运维指标进行监控和相应的处理，然而这些处理对于最终的用户是比较困难的，如果这是一个SAAS，只要你提供给我服务我就什么都不用管了。最终第三方的Operation Team事实上只能做开发者已经定义好的operation瓶平台，比如说我要对平台上的参数进行修改的话，是开发者在开发这个程序的时候就已经提供了接口，他才能对这个平台进行修改，否则他不知道怎么做。这样一来，我们发现开发人员对于最终用户的和平台之间的交互其实是docker build和docker registry这一层，在这层之后第三方运维人员可以用TOS启动相应的应用到达这个绿色的箭头。
   是不是说Docker机会万能的就解决了问题呢？我们曾经非常开心的以为是的，然而并不是这样的。有了容器的确非常好，我们所有的程序都可以封装在容器里面，对它进行一系列管理都非常方便，然而我们发现在一个集群里，如果这个集群都是我们自己管，自己开发自己运维的话，这件事情是非常好的。事实上我们开发以后要deliver给第三方用户，让他们去部署去运维的。这种情况下，事实上需要客户能够Ops能够非常简单的Reproduce我们在自己的容器环境里面做的任何事情，这不是件容易的事情，这需要对我们的系统架构有着非常深刻的了解才行。
   容器和容器之间的互相交流以及容器和容器之间暴露出来的服务他们互相的依赖。比如说节点的挂掉以及服务的发现，这些功能在我们的容器平台里面其实都没有完整的解决，于是我们第一个了叫做应用的概念。最底下的是我们星环的Operation System，它会做容器的隔离、CPU、内存、磁盘、网络上的调度、存储、编排以及服务的发现这些功能都是在系统这个级别完成的。应用需要定义的事情是我要起哪些容器每样容器起几个以及容器之间的关系。应用定义完了之后使用TOS相应的文本文件进行配置的更新然后它就有能力在其他的TOS上编排。最终客户只要用用TOS，他就能获得和当初开发者开发软件时一模一样的设施，他只要按一下button就可以启动系统。
   接下来我们看一个Demo。
   在这样一个平台里面我们有多租户的功能，在这里面我们首先建立一个租户，我们发现这个租户没有相应的容器配额，它不能做任何事情。接下来我们使用管理员账户帮它建立一个租户，建立相应的配合。这对应不同的部门同时使用集群，这个集群可以看到有3台机器，我们对刚才的用户建立相应的配额。现在配额建立完毕。除了对用户建立配额，我们还引入了用户组或者租户的概念。加入有一个服务需要两个人24小时去运维的话，如果只有创建的用户能够操作这个应用的话，就会发生一些问题。比如这个应用挂了需要进行修改的时候，必须把刚才那个用户打电话叫起来才能进行操作，有了用户组的话，只要在这个组里的用户都可以对这个应用进行操作。接下来我们建立一个最简单的zookeeper应用，对zookeeper消耗的资源预估并且创建。可以看到zookeeper已经创建完毕。现在的界面是安装HDFS的时候可以对HDFS进行修改，包括HDFS的replication个数，每个datande挂载的磁盘个数以及容量等，这些修改是我们在应用开发的时候就已经定义好的，ops可以修改它。在安装Hbase的时候需要依赖HDFS和zookeeper，我们可以选刚才已经好的HDFS作为依赖应用而不需要重新安装。应用依赖还有external service和internal service的概念，有时如果想创建一个HDFS应用，不希望把数据和应用暴露给其他客户，这种情况下就希望创建一个internal service，其他应用在Hbase下就不能依赖我这个应用。当然我们要运行一个公众服务时可以把这个internal service变成external service，这个service就可以被任何人使用。刚刚我们创建了一个external2应用，这个应用可以被所有人引用。
   在大规模集群部署下，监控是非常有必要的工具。我们创建了Heapster应用，该应用可以将所有容器的环境已经应用里暴露出来的指标统一收集到数据库中。我们也支持自定义的其它应用，包括MySQL这种需要持久化存储卷的应用，我们都可以随时启用。在MySQL应用中我们非常需要的功能是在容器重启和被杀掉数据是不会发生变化的，事实上容器重启它所有的数据可以保证正常运行。
   现在演示的是我们的终端功能，就是在容器运行过程中，进入容器内部查看某些内容。这是查看日志的功能，可以随时查看日志。这是我刚才说的容器指标收集，这里是CPU和内存指标。在应用运行到一半的时候我们能看到目前为止的性能指标和HDFS的特有指标都能在监控页面上查看。我们再重启看一下刚才的Hbase和mysql应用验证一下他们真的活的很好。这个IP可以暴露给其他集群外的机器访问。这里是我们创建的一张表，待会我们重启一下看看这张表是否还存在。事实上我们也可以同时更新image，我们可以更新mysql的版本，更新服务的时候数据还是保存在这里面。可以看到我们之前创建的那个表的确还是活着，演示就到这里。其实我们也允许对集群进行操作，包括添加删除节点和查看日志。
   刚提到多租户需要优先级以及配额，接下来我再讲下我们系统里面对优先级调度的定义以及是怎样实现的。对于优先级调度来说是非常有意义的追求，为了提高集群的使用效率，我们肯定需要对每个用户能够启动的应用的资源数进行限制。进行限制后很有可能有些用户用不了这些限制，那么他占用的配额就有可能被浪费掉。通过引入优先级概念，我们至少可以将集群资源分成两个等级，一个等级是保证最少我能有多少资源，就是说我要这些资源的时候一定要有，第二个等级是我可以通过某种形式借用到的资源去启动更多应用如果集群比较空闲的时候。我们举一个三个租户的例子，集群里一共有两个优先级，一个是保证优先，假设我们的集群是150个CPU，他的优先级一上大家都分配了50个CPU，不管什么时候优先级一上的资源都会首先被保障的。在优先级0如果其他用户没有使用那50个CPU的时候，我最多可以启动100个CPU在优先级0上。在集群有空间的时候，我最多可以使用剩余的那100个CPU。每个租户都是一样的。现在租户1运行了3个job1任务，它有3个replics，优先级为1的有1个，优先级为0的有2个，这个集群就在执行这3个任务。然而这个时候租户2要运行优先级为1的job2，他要占用50个CPU，这时优先级为0的租户1的其中一个job1就会被杀掉来保障租户2优先级为1的应用，租户3也同时启动一个job3的时候，租户1在优先级为0的两个应用全部被杀掉了。当租户2和租户3运行两个任务结束时，租户1的两个job1任务才有机会继续运行以达到最大化资源使用率。
   除了优先级管理以外我们对于容器在TOS上的应有进行了标准化的过程。对每个应用每个容器我把它分成四块。第一块是我们直接运行的二进制文件，就是当容器运行起来以后需要哪些程序以及依赖的library。第二个是它的log文件和临时存储空间。这些空间在容器两次重启之间都会被删除掉。第三部分是durable storage，刚才说的mysql的数据就会被存储在durable storage里面。这里面的所有数据及时是多次重启也不会被清空或者迁移到其他机器上如果这台机器空间不够的话。第四部分是配置。对于很多程序配置是需要经常需要修改的东西。现在我们提供环境变量和Git repo的方式对于container里面的配置文件进行修改。接下来我们以blogger的一个PHP应用举例讲解一下容器的durable storage的搬迁过程。可以看到在node1是一个普通磁盘，node2是SSD磁盘，PHP应用都会talk to redis container，redis container泡在spinning disk上面，在这种情况下它的性能有些影响，我们想把redis container运行到SSD磁盘以提高性能。于是我们搬迁container到node2上面。node2上的blogger应用数据进行迁移，PHP container自动的重新talk to新的redis container应用。这样数据就不会发生丢失。
   接下来是网络管理，在大数据应用里网络管理是相对简单的，暂时不需要对不同的大数据租户有不同的网络隔离。目前我们用的docker0就行分配。
   最后讲一下服务发现。在传统的云计算平台里面，这种都比较强travel factor applications，这种应用对于每个server都定义出比较general的interface，一摸一样的server哪怕是里面的under layer data不一样，也要提供一个一模一样的service，其他的应用调用的这个service的到的expose一模一样的回复。在大数据里面这件事情是不成立的。很显然，那件事情是在HDFS里面的datanode或者hbase里面的region server，对于不同的regionserver或者不同的datanode，和他们要不同的数据，如果数据是本地的话那么给你给你，不是本地的就会请求失败，这样的情况下就要对每一个这样的server进行服务发现，需要提供给他能够在集群里面找到他的DNS，他可以把DNS放到zookeeper里面提供给client，client就可以找到这一个server，而不是找到这一批来提供服务。
   经过上面的一些改动和变化，我们的到一个新的系统。这个系统同时支持大数据应用和普通应用。普通应用我们以mysql为例，大数据应用以hbase为例。我们建立了抢占式的优先级调度系统来提高我们的集群的使用效率。我们使用docker来完成环境隔离和镜像版本的控制，我们把数据放在durable storage以后，对于景象的更新不会造成数据的丢失，只要数据是兼容的后来升级就好。同时我们也支持云主机和物理机的一键部署，我并不关心下面是什么样的平台。最终我们通过kubernetes完成灰度升级和统一开发和部署的流程。测试时发现性能损耗是在3%以内，主要是因为我们引入新的DNS架构后需要DNS lookup过程导致的。
   这就是我给大家分享的内容，谢谢！