7月25日，我在国家会议中心的“Openstack中国日”里，分享了“openstack在浙江电信的应用”。其实更确切的名字是“中国电信自研的Openstack在浙江电信的应用”。中国电信作为Openstack的黄金会员，从2013年开始研发自己的Openstack，到2015年开始部署商用，经过2年的实践和现网运营，建立起真正开放、立体的云计算架构。
中国电信OpenStack是在中国电信集团的牵头下，主要由中国电信系统集成公司研发 ，浙江公司等省公司参与的项目。
浙江电信从2011年以来的这六年一直在搭积木:
一块积木:2012年购买了商业的vmware和开源的kvm作为虚拟化的底层。经过现网实践，由于当时KVM确实还满足不了商用的需要，我们最终选择了vmware。
一块积木：2013年随着大量电信业务承载，业务都承载在一个篮子里，安全性和稳定性成为急迫的问题，我们通过网络建立远距离安全的双活资源池。
一块积木：2013年资源池内的网络是快速提供IT资源的瓶颈，引入了SDN。
一块积木：2014年存储是资源池供给资源的短板，引入了SDS。
。。。。。。
在搭积木的过程中我们逐步理解了云计算的本质，培养出一支能够独立系统架构、规划设计、独立配置、分析需求、故障排查的云计算团队。但是，虽然我们知道要选择什么样的积木是最合适，但是实际上是找不到完全符合的积木，会受到二个方面的限制:
1、资源池是以vmware计算虚拟化为核心的封闭架构，只有定制化单向适配vmware。
2、这些积木都是别人开发好的成品，我们只是去选择一个最接近需求的积木。
以前我们搭的积木不管是双活体系、安全体系、软件定义体系都是围绕着计算虚拟化而展开，虽然也已经实现了资源随选，但是整体架构还不是一个开放的体系，受制于商业软件。
我们迫切需要一个开放的云计算体系来满足我们的需求。虽然有很多基于Openstack开源的解决方案，但是过度的”优化“和太多的烙印变成了另外一种商业软件。所以想要建立自己真正的开放体系就必须让我们拥抱开源、拥抱Openstack，站在Openstack社区的肩膀上“生产”出自己的积木，建立起自己的框架。
2013年来，我们一直在努力，在实践，把原有以计算为核心的基础体系，改造成为以管理为核心的云计算开放体系作为我们的目标。有稳定的基础架构、有高效的管理体系和敏捷资源供给方式。2015年在浙江公司的资源池上部署商用了中国电信自研的开放体系，取得了很大成效。
蓝存是中国电信北京研究院和浙江公司等单位基于开源CEPH基础上自研的存储，运行2年，容量近20P。
中国电信构建了全集团统一的基于openstack的云管理系统，浙江公司的云计算资源池是中国电信云管平台下的一个省级资源池。在统一管理平台下，融合了原来以vmware为核心的双活、安全、软件定义的一朵云架构，并在共享硬件的基础上，构建出基于中国电信自己的KVM资源池。Vmware不在是云计算架构体系的核心和大脑，仅是资源池的手和脚，而自研体系的KVM体系是另外一只手和脚。
我们可以根据应用需求的不同，来选择不同的虚拟化平台，实现资源的合理利用。资源池内的所有计算、网络存储资源都被统一纳管，可以实现vmware和KVM中间的跨平台迁移，支持vmware资源池存量虚拟机、模板、快照、客户网络的自动发现，自动反向纳管等。
我们积累了多年的云计算运营经验，从“管理”、“维护”和“用户”的角度建立起了立体的云计算架构。从管理上可以实时掌握资源池的整体运营状况、使用情况等；从维护上可以通过管理系统的辅助快速发现故障、定位故障和解决故障，并可以自动完成一些日常运维需要完成的工作，比如自动巡检等，从用户角度，通过管理平台进一步降低使用门槛，屏蔽了很多专业术语，像傻瓜相机一样，让每个用户都能根据自己的应用拓扑来创建计算、网络和存储资源，并搭建自己的私有网络，这些过程都是全自动的，资源都实现秒级开通。采用基于可视化、拖拽式、租户自助的资源交付和自运维。从2015年以来浙江电信很多政企有好用户，就一直利用这个管理系统来管理、配置、运营自己的“私有云”。
我们利用openstack建立了有浙江电信特色的敏捷随选的服务链。通过openstack把用户——运营者——维护者联系起来，并将内部的监控系统、OA系统、计费系统也都串接起来，形成服务闭环。在这个开放的服务链体系中，我们还可以自由的选择和融合第三方基于openstack的产品和服务，来丰富和做强我们的能力。
通过根据需求，利用开源的KVM，定制自己的计算虚拟化软件，可以更好的服务于生产，进一步降低建设成本。
浙江电信的开放的资源池体系里已经运行了2100多台X86服务器、上万台的虚拟机、上千个业务系统。这些系统主要分为类似传统IT架构的系统和通信网元类系统。传统IT类业务部署在我们自研的KVM上已经成为常态。但是在作为通信网元承载的基础设施（NFVI）上是近期的热点和难点，传统虚拟化老大vmware也在这个领域也还在探索。和承载传统IT类业务不同，需要对虚拟化层做些特殊的修改、配置甚至底层的适配，自研的KVM恰好能更好的满足这些定制化要求。我选取了vBRAS试验的案例给大家分享：
我们通过在实验室搭建华三的vBRAS的模拟环境来对物理机、中国电信自研的KVM、华三CAS和vmware进行性能对比测试。服务器统采用Intel Xeon E5-2630 V3 2路8核，2.4GHz 内存128G网卡 2*10G ，测试用例是模拟同时有5000个宽带用户、10000个VOIP用户、3000个IPTV用户、下行流量：上行流量=1:9的情况下的实际测试。
中国电信openstack团队现场根据vbars转发类的特点，现场对配置进行了优化：
1、VCPU-to-PCPU：VCPU绑定物理CPU或硬件现成，避免VCPU的漂移和资源争抢，同时提高Cache命中率。
2、VCPU拓扑配置：VCPU具备拓扑结构，以便应用软件的感知和利用
VMNUMA亲和调度：VM的虚拟NUMA节点映射到物理主机的同一NUMA节点（含多虚拟NUMA节点分别映射多个物理NUMA节点，保持虚拟与物理的一致性），应同时考虑VCPU拓扑和与物理CPU的绑定策略。
3、HugePage：大页内存，提高转发效率。
4、网卡驱动适应性修改：宿主机升级支持VF的混杂模式，全vlan透传ePages支持：挂载、分配合理大小hugepage，预留合适的hugepage内存。
5、Pci直通：替换pci网卡驱动为vfio-pci或者pci-stub，支持虚机pci直通。
6、Sriov直通：虚拟化出VF，设置混杂模式和vlan透传。
最后的测试结果：
中国电信自研的KVM性能优良，我们还进行了极限压力下的稳定性测试，在连续3*24小时的0丢包最大压力测试中，表现十分稳定，性能还略优于同样基于KVM的CAS。我们KVM已经完全能胜任转发类的NVFI的承载，传统的IT业务更不在话下。
iphone赞赏：
