【东京速递】OpenStack峰会一线快报:Keynotes 干货分享第一波
东京OpenStack Summit火热进行中,AWcloud海云一线战报,第二辑。大会见闻,干货着实不少!
Cloud in a box 里有AWcloud海云
Intel在Cloud-in-box提到了我们——AWcloud海云,哈哈哈,话不多说,我得意地笑……上图,上图,有图有真相!
API很重要
在Keynotes里,Yahoo日本OpenStack团队高级经理Takuya Ito介绍了OpenStack在Yahoo的应用,50000+虚机,20PB数据,20+OpenStack集群,并运行关键业务,也介绍了他们为什么选择OpenStack。
在他们看来,现代数据中心应该可以根据业务需要快速分配资源,
在紧急情况下可以保证正常工作,并且有统一的API来管理不同的环境,不管是虚拟化,包括KVM和VMware,还是容器或者是物理机。OpenStack的定位和他们的需求非常吻合。OpenStack正在成为软件定义数据中心的集成引擎(“Integration Engine”)。
Takuya Ito特别强调了为什么统一的API很重要:因为统一的API可以满足对数据中心的抽象,快速满足应用部署变更以及应急需求,同时可以减少对用户和运维人员的培训成本。
同时,Red Hat云架构师在其主题演讲《A Day in the Life of an Openstack & Cloud Architect》中也提到,传统的系统架构师和OpenStack架构师的区别就包括对API的考虑。
可见,统一的API具备可以保证云平台服务及应用间的互操作性,构建良好的生态应用,保护用户资产,减少人员培训成本等诸多好处,越来越多的用户也关注到这一点。在AWcloud海云接触和服务的客户中,很多客户已经把统一开放的API,作为自己构建云平台的重要原则。
当然,传统的商用虚拟化厂商也到看到了OpenStack在这方面的巨大价值,像VMware提供了VIO(VMware Integrated OpenStack)就是为了让VMware用户在使用原有VMware基础架构的基础上,同时可以获得基于OpenStack API的管理、编排和自动化运维能力。
在这次东京OpenStack Summit上,我们也看到在超融合领域处于领先地拉的Nutannix,也开始提供集成OpenStack的解决方案。它的架构如图。
简单的说,Nutanix通过为Nova, Cinder,Glance, Neutron增加驱动,处理从标准OpenStack控制节点发送过来的RPC请求,转化成Nutanix Acropolis的REST API请求。这样的方案和VMware对OpenStack的集成方案很相似,实现的效果都是用户可以使用到OpenStack的API, CLI和Dashboard,同时在虚拟机的数据平面仍然沿用原有的基础设施。Nutanix可以保持在存储方面的优势。
AWcloud海云也始终把保证OpenStack API的兼容性作为研发的原则,并且经过努力,目前也已经通过了OpenStack Powered程序测试。
(https://www.openstack.org/marketplace/distros/distribution/page-12/awcloud-openstack-distribution)
对容器和NFV支持增强
OpenStack更加强调对容器和NFV应用负载的支持,在Keynotes里,Lithium公司的云平台技术负责人Lachlan Evenson演示了他们在OpenStack上构建的基于Kubernetes的CI/CD系统,并且可以同时支持OpenStack私有云和AWS公有云,如图。
Lithium是一家美国提供社交化客户服务SaaS应用的公司,所以从他们的使用场景和业务需求来看,OpenStack+Kubernetes的方案可以很好地满足他们的需求,容器提高计算密码,简化运维操作,Kubernets负责容器集群的管理和应用的编排,同时可以实现跨IaaS平台的调度(也是通过OpenStack API集成),OpenStack可以负责计算、存储和网络资源的管理和分配。
当然,OpenStack运行容器还有一些需要增强的方面,比如网络。目前Neutron及其后端不同的SDN方案,解决了虚拟机的网络虚拟化问题,而Docker有自己的网络解决方案,比如Flannel, Wave,这样在把容器运行在虚拟机里就会面临两个问题,一是网络的复杂性,因为运维人员需要解决两套SDN方案的问题,另外一个就是两层封装带来的性能问题。
在28日Keynotes里Neutron的PTL Kyle Mestery介绍了OpenStack的新项目Kuryr会负责解决这个问题。在“Kuryr – Docker Networking in an OpenStack World”的演讲中,项目的主要贡献者Antoni和Gal给出了对这个项目的更详细的介绍。
Kuryr计划通过扩展Neutron和docker的网络管理,实现通过同一套SDN方案,同时为虚拟机和运行在虚拟机里的容器提供网络虚拟化,并且计划集成在Magnum和Kunbernetes等项目中。主要的实现想法就是把虚拟机里的容器端口也用Neutron管理,并对这样的”nested port“使用VLAN标记,来区分不同的容器网络,这样可以减少一层封装,这样的设计在OVN的原生设计中就已经考虑,所以Kuryr已经计划支持的驱动包括OVN, 目前其他计划支持的驱动还包括Midonet, Dragoflow和Calico。目前,这个项目还处于一个起步阶段,在Neutron方面还要增加port forwarding ,tags to resources和nested port的vlan trunk等工作,而docker方面,还要实现security group, subnet pools nat, QoS等功能。
对NFV方面,在28日的Keynotes中OpenStack COO Mark Collier介绍了NFV在CAPEX和OPEX方面的优势,可以看到很多大的电信运营商,如AT&T,Deutsche Telekom等都在参与基于OpenStack的NFV开发。在“Empower Your Cloud Through Neutron Service Function Chaining”中, 介绍了Neutron的网络服务链的实现,它定义了port-pair, port-pair-group, port-chain和flow-classifer这几个数据模型。port-pair就是每个VNF的虚拟机流量流入(ingress)和流出(egress)方向的两个虚拟网卡,port-pair-group是对单个port-pair的组合,flow-classifer是根据网络多元组定义的策略规则,port-chain就是关联了策略规则(flow-classifer)的port-pair-group的顺序组合,这样就实现了在同一个网络基础设施上,使网络流量根据不同的业务需求经过不同的网络服务链来处理,这些服务包括防火墙,负载均衡,入侵检测等。
容器和NFV目前并不是企业客户对私有云的主要需求,那么OpenStack对企业客户的需求有什么增强和改进,后面的文章会继续介绍AWcloud海云工程师在本次东京峰会上在这方面的见闻,敬请期待。