搜狐云景Container经验谈

背景

近几年,Container相关技术不断得到架构师、研发人员、运维人员等的持续关注,而且也不断涌出了不少Container的实现方案,比如:Cloud Foundry的Warden、Google的Imctfy等,随着云计算在国内的逐步壮大、成熟,相信未来会有越来越多的平台会采用类Container技术,我们也希望能把我们的一些经验、教训分享给大家,和大家一起共同推进Container技术的发展。

搜狐云景为什么会选择LXC

在使用Container技术之前,搜狐私有云PaaS平台使用了沙盒模式,利用JVM虚拟机对用户的进程进行隔离和安全控制,这种方式的优势是可以侵入到JVM内部对用户的代码进行拦截,方便的实施白名单机制,进而保证平台的安全性。但随着接入应用数量的逐渐增多,更多的需求接踵而来,比如:需要多语言的支持,应用希望有更大的灵活性,不希望平台有过多的限制等。

新版PaaS平台设计之初,我们也考虑了多种方案,首选的方案就是继续采用沙盒模式,为每种语言去实现一个沙盒,这种方案的代价比较大,而且仍然无法满足应用的灵活性需求。

第二种方案就是采用虚拟化技术进行隔离,传统的半虚或全虚的虚拟化技术如:KVM、Xen等,由于是完整的模拟OS,因此带来的Overhead会比较大,而且一台物理机上能生成的虚拟机数量也非常有限,这样的虚拟化技术并不适合应用在PaaS平台上。而基于内核的虚拟化方案Container则很好的满足了我们的需求,宿主上的所有Container都共享同一个内核,共享同一个OS,它足够的轻量,它的provisioning时间在秒级,一个宿主上甚至可以运行上千个Container,可以极大地提升资源利用率,因此,我们最终就选用了Container方案。

Container在不同的平台下也有不同的方案,比如:Solaris Zones,FreeBSD Jails,Linux平台下的LXC,OpenVZ,Linux VServer等。搜狐一直以来就是Linux平台,因此也就只能在该平台下去选择相应的技术。其实就技术的成熟度来讲,OpenVZ发展的比较早,有很多特性,相对也比较稳定,国内外有很多VPS就是使用的OpenVZ,但OpenVZ和VServer是单独的一个内核分支,没有进入upstream中,而LXC则从2.6.29就进入到了主内核中,我们还是希望跟着主内核走,因此最后就采用了LXC。

搜狐云景基于容器的架构

搜狐云景的整个弹性运行环境就是基于容器构建的,这些容器都运行在物理服务器上,总体上分为以下几层:

  1. Node OS:即物理服务器的操作系统层,所有的Container都共享此OS和系统内核。
  2. Node Agent:对Container的生命周期进行管控,它和云景平台的其它模块通信,进行容器的创建、销毁、更新等操作,并负责对Containers进行监控。
  3. LXC Scripts:在LXC的基本命令行基础上,抽象出一层对Container的管理功能。
  4. Containers:即真正的容器,它是由Node Agent发出调度指令,通过LXC Scripts创建出来的容器。

    搜狐云景目前使用的内核版本为2.6.32,此系列的内核版本对Container的支持还不太完善,我们前期在测试和使用过程中,也遇到了不少的问题,其中不乏一些严重的Bug。因此,搜狐内部专门成立了一个系统研发团队,负责对Kernel和LXC进行研究,在标准的内核基础上做了大量的工作,修复了若干Bug,同时也将一些新特性移植到了内核中,从而形成了我们自己的内核。

Linux Kernel 2.6.32优化工作

下面简单介绍一下我们做的一些主要工作:

  1. 将AUFS和OverlayFS移植到内核中,通过这种UnionFS技术,我们为每个Container挂载一个基础的只读RootFS和一个可读写的文件系统,从而可以实现一个Node上所有容器共享同一个RootFS,大大缩减了空间的占用,而且可以共享一些基础的动态链接库以及Page Cache。
  2. 在2.6的标准内核中引入了setfs系统调用,从而实现了对lxc-attach的支持,搜狐云景的Node Agent上有不少操作需要通过此命令去实现对Container的管理。
  3. 修复了一些可能导致Kernel Crash的Bug,比如:系统Driver的Bug,AUFS操作的Bug。这类的Bug影响非常大,直接可造成内核崩溃,Node自动重启,从而造成上面的所有Container全部消失,极大的影响整个平台的稳定性。
  4. 修复了一些Container的安全性问题:比如:在Container内部可以直接mount cgroup,从而修改cgroup对该容器的管控配额信息。禁止容器对系统敏感文件的读写操作,防止容器内部对Node的一些危险操作。
  5. 修改了容器内系统信息显示的问题,比如:top/free等命令显示不准确。

搜狐云景实现了对哪些资源的隔离和管控

Container技术主要是通过Namespace机制对不同实例的资源进行隔离,包括网络隔离、进程隔离、文件系统隔离等,保证运行在一个容器的应用,不会影响到其它容器的应用。通过Cgroup机制对每个实例的资源进行管控,主要实现了对以下资源的限制,防止实例滥用系统资源:

  1. 内存:设置每个容器所能使用的最大物理内存,当容器内的进程使用内存超限后,则Cgroup会自动将相应的进程Kill掉。
  2. CPU:通过为不同的容器指定不同的CPU核,去限制其只能使用特定的核,并为每个容器设置不同的CPU shares,另外还控制每个容器对CPU资源的最长连续使用时间,防止某个容器过度使用CPU资源。
  3. 磁盘:LXC目前对磁盘配额的支持不够,搜狐云景通过LVM卷去限制单个容器的配额,并可以方便的对磁盘进行扩容。

    在网络隔离方面,我们也使用了Iptables、TC、SDN等技术方案,对实例的网络流、流量进行管控,最终可以细化到实例可访问哪些网络资源,不能访问哪些网络资源。针对一些静态的访问策略,比如:容器无法访问某台服务器,搜狐云景在设备上做ACL或者在服务器上通过Iptables去实现。在搜狐云景上也会有一些动态的策略,比如:某个应用绑定了Cache服务,则需要动态将该应用的所有实例开通到Cache服务器的网络连接权限,这些动态策略主要是通过SDN去完成的。通过TC,我们去限制每个容器的流入流出流量,防止发生由于某个容器的异常流量,造成云景内部网络带宽跑满,从而影响到其它应用的正常运行。

搜狐私有PaaS平台在内部的应用情况

搜狐云景在对外发布公测之前,其私有PaaS平台其实已经在搜狐内部经历了近3年的磨练,也经历了2次版本的迭代过程,从V1版本的沙盒模式到V2版本的Container,一路走下来,虽然踩了很多的坑,但也收获了很多。在Container使用初期,整个平台表现不太稳定,Node或者Container总会时不时的出现问题,甚至崩溃,经过我们的优化和改进后,平台日趋成熟,并已经处于稳定运行阶段,现在,Node或Container几乎没有出现Crash的情况。目前我们私有PaaS平台的可用性可达到99.99%。

现在搜狐内部已有多个业务线将其应用迁移到了私有PaaS平台上,比如:搜狐焦点,搜狐汽车,企业网盘,通行证等,部分业务线几乎做到了服务器“零采购”和”零运维“。这些应用的每个实例均运行在不同的Container中。内部应用对资源的需求相对比较大,因此,我们的单台物理机上目前运行30-50个左右的容器,而对搜狐云景来说,我们提供了更多不同配置的容器,最小容器配置为256M内存,这样单台物理机上可运行上百个不同类型的容器,可满足不同应用的需求。

Container总结和前瞻

虽然Container技术已经被众多的互联网企业所接受和采用,并大量地应用在企业内部的云平台上,但不可否认的是,现在Container相关的技术仍然还不太完善,还有不少的问题,它在CPU、IO等隔离性方面还比较薄弱。尤其是将Container技术应用在公有云平台上,会面临不小的挑战,如何保证公有云平台上应用和环境的安全性,是需要大家持续研究和跟进的。而且,现在也有了一些方案,比如:OpenShift将SELinux和Container进行结合,而Ubuntu则通过Apparmor去加强Container的安全性。相信随着云计算在业界的不断蓬勃发展,Container相关技术也会得到持续的改进和完善,并被大量地应用在企业的云平台上。

目前,大家所能看到的是Container被广泛地使用在了PaaS平台,其实在大部分企业内部的IaaS平台上,Container也是一个很不错的选择方案。由于其更轻量、性能更好,我认为在不少场景中,Container可能可以完全替代现有的虚拟化技术,如:Xen、KVM等,而且相信未来支持Container的IaaS管理平台也会不断地涌现出来,Container的未来值得我们期待!

你可能感兴趣的:(搜狐云景Container经验谈)