写点什么

搜狐云景 Container 经验谈

2014 年 6 月 23 日

背景

近几年,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 的未来值得我们期待!


感谢刘宇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2014 年 6 月 23 日 00:441971

评论

发布
暂无评论
发现更多内容

LeetCode题解:232. 用栈实现队列,使用两个栈 入队 - O(1),出队 - 摊还复杂度 O(1),JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

服了,十年运维架构专家的MySQL运维经验,除了实战还是实战

周老师

Java 编程 程序员 架构 面试

基于Goc的Golang代码VSCode实时染色方案

大卡尔

go 测试覆盖率 精准测试

week11--作业

Geek_165f3d

记一种spring框架的想当然但错误的用法

小明同学

源码分析 最佳实践 Spring Framework bug

oeasy教您玩转linux 010211 牛说 cowsay

o

[翻译]Scalable Go Scheduler Design Doc[Go可扩展调度设计文档]

卓丁

golang golang scheduler Go scheduler

LeetCode题解:232. 用栈实现队列,使用两个栈 入队 - O(n), 出队 - O(1),JavaScript,详细注释

Lee Chen

前端进阶训练营

阿里培训官给新入职程序员的25条建议

Java架构师迁哥

架构师训练营第十四周

Melo

澳门金沙玩赢了钱提现不了异常注单未更新有什么办法处理?

丛林里的余光

异常检测 澳门金沙 提现不了

面试必问亿级流量优化策略之JVM调优,文档视频面试,还不收藏

小Q

Java 程序员 架构 JVM jvm调优

不草率,你只管下载资料,剩下的交给「哇哦」

小Q

Java 学习 架构 面试 分布式

甲方日常 13

句子

工作 随笔杂谈 日常

一文解开java中字符串编码的小秘密

程序那些事

java安全编码 java编码指南 UTF编码

Dubbo-go应用维度注册模型

apache/dubbo-go

dubbo dubbo-go dubbogo

藏在Java数组的背后,你可能忽略的知识点

Java架构师迁哥

从外卖员到拼多多30K+程序员,我付出了三年的青春

小Q

Java 学习 程序员 架构 面试

【高并发】Redis如何助力高并发秒杀系统,看完这篇我彻底懂了!!

冰河

redis 多线程 高并发 秒杀 电商超卖

宅家三个月玩转算法,再战字节跳动,字节跳动面试官朝我比了个“ok”

云流

编程 字节跳动 算法 Java 面试

区块链赋能市场监管 浙江上线“黑科技”清除取证固证难题

CECBC区块链专委会

区块链 市场监管 取证难题

TOGAF认证课由2天变化为5天的思考

周金根

企业架构 TOGAF

区块链技术发展的十大趋势

CECBC区块链专委会

区块链 金融 安全问题

央行数研所推出贸易金融区块链平台

CECBC区块链专委会

区块链 金融

一点 Go Web 编程实践经验

Garfield

go Go web

架构师课作业 - 第十三周

Tulane

Java四种引用类型:强引用、软引用、弱引用、虚引用

简爱W

JavaScript引擎的事件循环机制是怎样工作的?

Walker

Java 前端 运行时栈帧 事件循环

.NET委托,事件和Lambda表达式

AI代笔

从新浪数字化转型,窥见互联网的“懂行”新十年

脑极体

业务架构学习内容有哪些?

周金根

BIZBOK 业务架构

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

搜狐云景Container经验谈-InfoQ