虚拟化实践

引言

这里的虚拟化等于私有云。本文并不是虚拟化的科普文章，主要将咱们在私有云实践过程当中的一些思想和遇到的问题拿出来跟你们讨论分享。咱们虚拟化实践包含了传统的基于libvirt协议的KVM以及目前流行的docker。

为何要虚拟化

虚拟化的目的各家公司缘由应该都差很少，通常都是为了实现以下目标：

* 资源交付效率

传统物理机的时代，一个服务器交付要经历找资源，网络配置，idc安装，配置初始化等过程，效率很慢。在瞬息万变的互联网环境中，产品周期的变的愈来愈短，对开发和运维的要求愈来愈高，对于运维来讲，资源交付效率就相当重要。

虚拟化能够将物理机的初始化时间前置，应用上线使用机器时，虚拟机交付能够作到秒级交付，能够很大缩短上线时间。

* 资源利用率

有了现代多核、多处理器系统，单个服务器能够很容易地支持十几个或者更多的虚拟机，让更多的应用程序可以受益于高可用的硬件配置，榨干硬件的红利，下降公司硬件成本。

* 自动化运维

虚拟化更容易提供统一的抽象资源和抽象接口，有利于平台化运维。

目标

咱们虚拟化的目标主要是实现一个统一的资源管理和交付平台，在运维中的位置大体以下：

在技术上同时具有以下目标：

* 跨平台，支持libvirt虚拟机和docker容器

支持libvirt主要是为了支持传统的虚拟化技术，如kvm，xen；支持docker主要是为了使用容器的灵活性和高密度。

* 支持用户自助

申请和准备资源在运维的平常工做中占了至关大的一部分工做量，咱们很懒，咱们想将这个工做放给各个部分负责人或者开发人员。
自助的服务包括：自助增删改查、自助扩容、自助打镜像。

* 可运维性

一项技术再牛逼，如不可运维，那结果绝对是灾难性的。所以咱们但愿咱们的私有云是可控、稳定，同时兼顾数据的准确性。

* 弹性计算

实时监控各个虚拟机或者容器的性能指标，弹性的扩容和缩容，合理的分配利用资源。

* IAAS化

为了和当前的运维体系对接，咱们要求虚拟化平台统一对外提供IAAS服务，虚拟机均配置IP，可ssh。

设计

简单，可控，稳定是设计的基本原则.

关键点设计

咱们是分了以下7点来设计和规划咱们的vcloud平台。

1.虚拟化技术选择

容器最近很热，其确实也很灵活，可是大规模的使用时机还不成熟；因此咱们选择传统虚拟化技术KVM+docker，确保线上应用的稳定的同时，测试环境能够利用到docker的轻量，高性能和灵活。

但如何抽象管理docker和KVM呢，KVM支持的是libvirt，docker的是API，为此咱们本身开发了一个cloudagent，部署在各个宿主机上，对外提供统一的管理接口。

支持MQ为了进行复杂的调度算法和大规模部署，支持http能够方便调试。

2.网络选择

考虑到私有云无自建私有网和隔离的需求，咱们选择的网络解决方案是网桥，来简化网络的设计，全部VM网络都是联通的，若有跨环境隔离需求，统一使用网络ACL控制；虚拟机的IP统一在web平台指定（按规则生成），不使用libvirt或者docker自己的自动分配，防止DHCP带来的不可控问题。

3.存储选择

本地存储使用ssd的LVM，虚拟机跑在LVM上，让运行的虚拟机有很是好的IO性能。同时用ceph做为镜像管理中心和快照中心，提供一个大，但性能不是太好的附加存储。

PS：强烈建议你们私有云配置ssd，并且单盘裸盘足够，咱们前期使用过SAS和SATA盘，性能惨不忍睹，IOwait常常大于50。

4.镜像管理

KVM和docker若是使用两套镜像管理，带来的管理成本过高，为此咱们kvm使用tgz镜像，docker使用官方的registry v2，这样kvm和docker的镜像能够相互转换，能够作到镜像内容统一。

PS：因为最新的docker registery v2不支持ceph的S3，咱们本身写了一个模块来支持。

5.管理平台选择

是开源仍是本身开发？目前功能最全的openstack，大而全，特别是在网络和存储这块，不少公司都用openstack开发本身的私有云和公有云。但对于咱们来讲，openstack不少功能用不到，特别是它最复杂的网络；并且openstack维护复杂，须要有专门的commiter来跟进和修改，以知足自动化运维的须要。
考虑到工做量和后期开发维护成本，咱们选择本身开发一个简单灵活的管理平台，主要具有以下功能：

• 用户管理

• 虚拟机管理

• ip地址池管理

• 监控管理

• 镜像管理

• API

6.集群调度

咱们没有使用swarm或者kubernetes，主要缘由有两个：第一，咱们须要的功能很简单，实现起来并不复杂；第二，swarm和kubernetes版本更新太快，会增长运维成本。

咱们的使用知足单机之间没有交互，每个单机均可以独立运行，互不影响；全部的调度都在平台上控制，保持架构简单、稳定、高效、可控。

调度算法很简单：

1. 管理员人工指定物理机，这个优先级最高。

2. 在不指定的状况下（普通用户不能人工指定），秉持最少使用（CPU and 内存）和同一应用尽可能分散的原则选择物理机。

PS：kubernetes是一个好东西，特别是他的pods理念很好，很值得借鉴。

7.监控

监控很关键，是调度，弹性管理和故障迁移的前提，这个的要求是不入侵虚拟机，监控数据采集统一在宿主机上经过cloudagent采集。

传统虚拟机能够经过libvirt接口，docker能够经过cgroup+docker API，来计算虚拟机的CPU利用率，内存使用率，磁盘IOPS，磁盘吞吐量和网络速率。

平台设计

以下是咱们vloud平台的架构图：

* zone集群

zone是一个最小集群管理单元，迁移，扩容，批量建立都是一个zone里操做。
一个zone必须在一个网段，一个zone对应的IP池，IP由一个统一算法分配，也能够管理员手工指定。
一个zone内的物理机不相互通讯，全部的动做都在平台上控制，由cloudagent接收指令并执行。

* IP地址池

IP地址池归属于一个zone，IP地址池须要人工配置；按期检查IP地址池未分配IP地址的连通性，防止IP地址冲突。

* 镜像管理

docker的镜像管理使用docker registry v2，kvm使用http的tgz，docker的镜像和kvm的tgz镜像，咱们按须要进行相互转换。

* cloudagent

这个是咱们本身开发的统一的管理agent，部署在各个物理机器上，封装了libvirt的API、docker API。对外抽象出统一的接口，含建立、删除、扩容、暂停、监控等。

* 性能监控

使用不入侵容器和虚拟机的方式，经过cgroup统一抓取cpu、mem、iops、网络；监控数据做为扩容和缩容的一个依据。

* 建立一台虚拟机

咱们拿建立虚拟机这个工做，简单看一下咱们的内部调用流程：

docker关键技术

因为kvm这块比较成熟，网上说的也比较多，本文不作太多的阐述，这里简单介绍一下咱们是如何使用docker。

docker的技术清单以下：

项目	参数
docker版本	1.10.1
存储	本地ssd devicemapper
网络	网桥，–net=none，pipwork种IP
image管理	docker registry V2
物理机配置	32核 128G内存 800Gssd
密度	4核4G容器 单台 60个
管理方式	Cloudagent+docker API

咱们如今最高的密度已经达到了单台50个，服务器运行毫无压力，应用无异常，估计能够跑到100个。

* CPU限制

CPU限制，为了管理方便，只用cpuset来限制CPU。在选取绑定的CPU时，按照最少使用原则，同时须要考虑不要跨NUMA。

node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31

"CpusetCpus": "14,15,12,13",

* 内存限制

咱们选择了3个参数来控制内存，Memory限定最大可用物理机内存，MemorySwap限定物理内存+物理机内存总大小，OomKillDisable标记内存超过限定是否KILL容器。
原则上是Memory=MemorySwap，即不使用swap，由于咱们但愿容器内存溢出时能够被直接kill掉，不要影响其余容器。

"Memory": 4294967296,
"MemoryReservation": 0,
"MemorySwap": 4294967296,
"MemorySwappiness": 1,
"OomKillDisable": false,

* 网络

网络使用网桥，--bridge=docker0，且和物理机共享一个vlan，简化网络架构。
因为docker目前还不支持指定IP，因此这里使用了pipwork来为容器指定咱们需求的IP。

/root/cloudagent/script/pipework docker0 -i eth0 idc01-dev-devgroup-101104 1.1.1.1/24@1.1.1.254 02:42:c0:01:65:68

* docker registry V2

后端存储使用ceph，可以提供几乎无限大的存储，方便用户自定义作快照和镜像。
因为是在内网，registry 没有使用验证。

* docker 本地存储

咱们用的是devicemapper + direct-lvm，LVM用的是一个800G ssd裸盘。

--storage-opt dm.basesize=40G --storage-driver=devicemapper --storage-opt=dm.thinpooldev=/dev/mapper/docker-thinpool --storage-opt dm.use_deferred_removal=true

成果展现

通过半年的开发和使用，目前vcloud1.0已经的在微店内部使用，虚拟化也所有推开。

* 普通用户管理视图

* 用户权限管理

用户按zone受权，资源控制到CPU，内存和总个数。

* 监控数据

咱们的监控数据统一由cloudagent抓取，而且计算的都是每一个VM实际使用的。

QA

* 为何不提供PAAS？

这个看如何理解PAAS和IAAS，在私有云里PAAS应该理解为应用是否能够自动化上下线。建立一个容器提供出一个nginx服务，在私有云里叫不上PAAS，通常都还须要SRE将这个nginx服务暴漏出去，因此咱们将咱们的Vcloud叫作IAAS平台；当自动化上线实现了其实才是真正的PAAS。

* 用什么语言开发，考虑开源吗？

咱们平台用的是java，后端cloudagent用的是python；暂时还不考虑开源，主要是没有时间整理咱们的代码，等后续平台稳定和功能完善后，会抽出空来整理咱们的代码和规范，开源给你们参考一下。

* 如何实现KVM和docker的统一管理？

咱们之因此能够作到统一管理，主要缘由有两个，第一：cloudagent，由其来抽象libvirt API及docker API；第二就是KVM使用tgz的模板装机，tgz的模板能够和docker的image相互转换，这点特别重要。要否则须要管理两套的image，那就谈不来统一管理了。

* 物理机挂了或者load太高怎么办？

这里解释一下咱们这边的迁移功能（从新建立功能）：将以前的节点销毁，而后在zone里从新找一台机器来建立,若是以前有快照，能够选择以前的快照。

当物理机挂了，咱们只要将物理机从zone中剔除，而后逐个迁移，而后从新发布（无快照状况）；因为IP等信息不变，无需修改CMDB 和LB配置。

* 为何不所有使用docker？

相比KVM比较成熟的虚拟化技术，容器目前还有不少不完善的地方，除了集群管理、网络和存储，最重要的仍是稳定性。容器的隔离性不是很好，当一个容器出现问题，极可能影响到整个物理机。

* 后续还有什么规划？

后续咱们将重点围绕docker经行更多功能的开发，编排，jenkins对接，自动上下线和分布式附加存储。

最后

咱们的虚拟化（私有云）之路还刚起步，后面vcloud2.0 vcloud3.0还有不少事情要去作和完善，欢迎有兴趣的同窗加入微店，加入咱们，简历请邮件taoshoukun@weidian.com。