剑客
关注科技互联网

从0.25到1.0,中小企业Mesos网络和存储的填坑实践

看完海外大型企业的Mesos容器技术实践,让我们视线回到国内。今天是 数人云 容器三国演义Meetup嘉宾演讲实录第一弹。中小企业是如何解决Mesos使用过程中种种问题的?Acttao技术总监何威威来告诉你答案——

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 今天与大家分享的是中小企业的Mesos实践中遇到的网络和存储方面的具体问题。

概述

首先介绍一下Acttao的实践情况。Acttao现在主要运行两个Mesos集群,一个用于测试环境,另一个用于生产环境。测试环境部署在KVM虚拟机里面,生产环境在阿里云。之前还有一个OpenStack的测试环境,后来撤掉了。有了Mesos集群以后,我们在开发过程中引入了CI/CD,CI/CD要求开发人员能很方便的管理无状态的Web服务,一个有状态类似于MySQL、Redis等的服务,还要求Web服务能够方便的找到数据库服务,这是要解决这三个问题。

要解决这些问题,需要我们在Mesos的容器里面实现一容器一IP,对于有状态的容器需要跨主机的Volume服务,以及服务发现。

Mesos容器网络

说一下Mesos网络的方案。按照时间有三个阶段,第一个阶段在Mesos 0.25之前,在这之前Docker本身没有容器的扩展,第二个阶段是Mesos0.25到1.0之间,第三个阶段就是现在1.0版本之后。Mesos 0.25之前这个方案基本上是空白的,大部分都要手动运行脚本,以空网络起一个Docker容器,然后再运行一些比如创建网络设备、配置IP。那时有一个Powerstrip原型的工具,其原理是替代Docker API做一些扩展,使用这种工具给Mesos容器加IP基本不会有改动,通过Mesos的API就可以实现一容器一IP。

在Mesos0.25到1.0版本之间,这时Docker推出了网络扩展功能,Docker容器有了原生的网络扩展支持。典型的第三方插件有Weave、Calico等。我们通过MarathonAPI可以直接实现创建的容器有一个IP。

1.0之后Mesos原生支持了CNI网络,通过Unified Container,无论是Mesos的容器还是Docker的容器、AppC的容器,都很容易做到一个容器一个IP。

在Mesos支持CNI之前,为了实现IP per container,Acttao最后选择了Weave。没有使用Docker容器的扩展,而是选择Weave Proxy,类似于0.25之前的方案,因为它很容易集成。Weave的Proxy方式有DNS的服务发现,集成较简单,Weave起一个Router,然后Proxy起开,起开以后在Mesos的slave设置Docker socket走Weave Proxy的socket就可以了。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 当时没有选择Docker Libnetwork的扩展方式,因为那时需要为每一个Docker配一个外部存储,这也是刚才徐春明老师说他们现在SwarmKit里面不依赖于外部存储的原因。因为当时测试的Docker依赖于外部的存储,最后测试的性能问题比较严重。当时他们建议用etcd,而Acttao当时用的是Zookeeper,测试时起了网络有时候运行 docker network ls,Docker就会卡掉,基本上是挂掉的状态。

在使用Weave Proxy时有两个问题一直困扰着我们。一个是Weave网络升级,有新版本发布时,我们可能会选择使用新版本,但是升级比较麻烦;另一个问题是网络的隔离性不好。升级时Weave Proxy要重启,重启了之后Mesos认为Docker Engine挂掉了,会把任务进行重新调度,但实际上在宿主机上的容器并没有挂掉。这个问题对无状态服务影响不大,相当于有多个实例,但是对于数据库服务来说,就会导致原先数据库服务运行着,又调度了一个新的任务,在DNS自动发现里一个域名会返回两个IP,导致了一个服务是可用的,另一个服务不可用。

由于这个原因,升级之前我们把Mesos的Slave停掉,把所有Mesos管理的容器也停掉,让master重新进行任务调度,接着把Docker也停掉了,然后安装新版本的Weave,之后把Docker和slave启动。在升级的中途如果宿主机里面有数据库服务,会有一段时间服务不可用。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 Weave基于子网的网络隔离灵活度不是很好。在Mesos考虑多租户,一个租户子网分配的太小,可能马上就不够用,后续扩大子网的过程非常麻烦,如果一开始分配的子网特别大,又会造成浪费。

针对升级网络组件时遇到的问题可以使用CNI来解决。网络隔离的问题可以在CNI的基础上使用Calico解决,Calico 基于 iptable 做了防火墙的规则。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 在Mesos 1.0里配置CNI很简单。配置network CNI配置文件的目录以及CNI插件的目录, Mesos就可以启用CNI的功能。CNI对第三方的配置也很简单,这张图是Weave的配置,只要一个名称和一个type:weave-net。 Calico同样不复杂,基本上也是配置名称,支持CNI这个网络插件里面所需的配置。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 使用Marathon启用的时候比较简单,在APP的Json文件里面配上IP adress,配一个network的name,这个名称就是之前配CNI里面的名称。然后配一些label标签,它与防火墙有关,再配一个Discover的端口,主要用作服务发现。通过这种方式,基本上就解决了前面提到的两个问题。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 但是Acttao目前使用的仍然是Weave CNI,没有选择Calico方案的原因是它的安全策略现在必须得手动配置,不能自动地和Mesos集成。如果内部使用,自己配备也是可以的,但是后来考虑自己来写一个marathon-calico,根据Marathon中的APP自动创建网络安全方面的策略。

Mesos容器存储

存储方案也和刚才的容器一样是分三个阶段的,中间阶段均是原生支持了扩展,容器Volume的扩展以后有一个阶段,以及Mesos1.0以后,直接支持Docker存储插件。之前Acttao基于GlusterFS做了GlusterFS集群,在每一个S节点把集群挂载上去,容器通过Docker直接挂宿主机上面目录的功能来实现。

当Docker原生支持Volume插件以后,Acttao使用的是EMC的REX-Ray,这与其他Volume的插件功能类似,是我们目前了解到的插件中功能最全的,支持第三方存储,比如OpenStack和一些商业存储硬件,包括EMC。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 Mesos1.0以后原生提供了Docker Volume支持服务,通过EMC提供的 dvdcli 工具实现。最开始时EMC想利用这个功能为Mesos里面提供外部的存储,但是当时它基于Mesos的模块,只能支持Mesos容器,无法支持Docker容器。所以Mesos1.0以后直接把这个功能集成在Mesos核心。Mesos1.0以后,我们把它也配上了,提供Mesos原生支持。它的配置比较简单,在slave里面安装dvdcli,然后设置一个Volume的check_point,用作恢复,在隔离上面设置好system/linux和docker/volume,基本上就可以启用功能了。

从0.25到1.0,中小企业Mesos网络和存储的填坑实践 在Marathon里面使用第三方外部存储时,需要把external_volumes的feature 开启,真正使用时是在APP的json里面定义卷的时候,把volume里面的类型设置成外部的,provider设置成dvdi,因为目前只支持这一种方式,后面使用Docker Volume Plugin的名称,基本上就可以使用了。

当前最新版本的Marathon的外部卷不能使用绝对路径,这个BUG416估计短期内也不会得到解决。我们把它里面dvdi provider的校验规则改一下,基本上就可以使用了。前端的校验规则里面是Mesos的容器,原先设置的时候不能使用相对路径,把它改掉就可以。

我的分享就到这里,谢谢大家。

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址