现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

吴德新:用OpenStack部署企业私有云

2016-02-03 14:24 工业·编程 ⁄ 共 5262字 ⁄ 字号 暂无评论

     1. 各位InfoQ的网友大家好,现在我们在ArchSummit的北京现场,做客我们专访间的是AWcloud海云的研发总监吴德新先生,第一个问题想请您简单介绍一下AWcloud海云以及您目前所负责的工作。

吴德新:InfoQ的朋友大家好!首先我来介绍一下海云,简单地说海云是一家专注于OpenStack的创业公司,海云成立于2010年,从2012年开始专注于OpenStack的产品研发和服务,主要面向企业客户,目前我们的经营业务包括软硬件一体的一体机服务,OpenStack的产品和部署服务,以及咨询、运维和托管等服务。我目前的工作是负责海云的研发管理,研发方向,产品功能规划以及一些大规模项目的部署架构和一些问题的解决。

    2. 在企业私有云部署的过程中,您这边遇到的最多的问题是什么?

吴德新:OpenStack大家知道是按照AWS这样一个公有云的模型开始设计的,所以在企业里面落地的时候,按照每个企业现网的环境可能会有一些冲突,实现上会有一些现实的问题,这些问题大部分都是可以解决的,但是会影响产品部署的自动化程度。举例来说,比如网络方面,企业现存的网络模型可能是比较简单的,但是OpenStack的网络模型是比较复杂的,这样的话可能会有冲突,所以需要一些手动的部署去解决这样的问题。还有一些现存的网络里面,比如说地址可能已经分配到其他的一些存储设备或者服务器来使用,那么给我们的地址池,包括外网地址池都不是连续地址,这个在部署的时候就会有一些小麻烦,但是这些问题也都是可以解决的。包括一些迁移的问题,也是类似的情况,会有很多涉及到手动去从物理机迁移到虚拟机的案例。这些问题最终通过第三方工具都是可以解决,但是迁移的过程是比较耗时耗力的,自动化程度比较低。我们也会梳理这些,从客户的实际需求里面提取一些公共需求,来把它集成到我们的自动化部署方案里面。有些问题可能需要从代码层面解决,这部分我们会反馈到社区里面。

从我们碰到的问题也可以看出,OpenStack大家抱怨它的痛点主要是部署比较困难,其实和它的一些理念是有关系的,它把很多管理层面的工作放到了部署过程当中实现。没有一个面向管理员的,在生命周期运行当中的很好的管理工具。这部分工作我们在以后的研发工作当中也会进一步加强。

    3. 企业部署私有云的过程中,比如说网络方面有很多开源的sdn解决方案,我们企业用户在部署私有云过程中对SDN解决方案的选择会有什么样的标准?

吴德新:是这样的,首先我们对SDN的态度是我们不能为了SDN而SDN,我刚才提到,有些企业的网络是比较简单的,就是传统的VLAN的网络模型,当我们引入SDN的时候,可能会引入很多的复杂度,甚至把他的云网络和现网孤立开,引入其他的像VXLAN网关才可以打通,包括现网的一些网络安全设备都可能没办法直接复用。这样的话对客户是增加了方案的复杂度,包括运维成本,同时设备利用性又非常差,不利于保护资产。所以我们会根据客户的需求,很多情况会简单采用网络虚拟化的方案,在三层会使用现有的核心交换机、路由器来解决三层的问题。

但是对于一些大客户,他确实是有真正的SDN的需求,他的技术规划会比较前沿一些,所以我们也会评估现有的一些SDN方案,包括像Calico,OVN等等这些项目我们也都在评估,每个项目都有自己的特点和优势,但是也都有一些问题。举例来说,像Calico这个方案,它是通过用BGP进行三层转发的,数据层面是比较简单、稳定、可靠的,但是它有一个比较大的问题是不能支持ip的overlap,这对于客户来说会有一些限制。作为一些大的私有云企业来说如果我们把IP地址规划好,这个使用是没有问题的,但是作为一个厂商的解决方案来说这是有瑕疵的。但是Calico现在也可以支持容器网络,作为docker的网络,这个方案在公有云上面是比较容易实现的,因为通常公有云是用SDN的底层方案,比如说像docker的libnetwork这样的网络解决方案,要引用另外一层的tunnel,和底层的SDN方案可能会有一些性能上面,或者在多播广播这样的二层上面有一些冲突,但是三层转发会比较简单,所以Calico方案对容器网络是比较合适的。

像OVN方案我们也在关注和跟进,它目前是在OpenvSwitch社区里面相当于一个子项目,从设计角度来说,我们觉得设计的是非常优雅的,它是依赖了OpenvSwitch OVSDB本身的一些特性,我们对它一个比较大的担心是OVSDB本身的扩展性和可用性,这一部分问题可能社区后面也会解决。OVN这个项目目前像IBM、redhat,VMWare这些大公司都在积极参与,而且它是用C语言开发的,所以在控制平面的性能方面,至少在语言这个层面不会成为它的瓶颈,所以我觉得这也是一个值得重点关注的项目。

另外像MidoNet也是我们接触比较多的开源的SDN项目,MidoNet的好处是它的架构设计之初就充分考虑、利用了一些比较好的分布式解决方案,像zookeeper和Cassandra来存储网源的静态配置信息和运行时的规划信息,这样的话它的高可用和性能是没有单点的,所以这方面它的架构设计是非常值得借鉴的。但是它的问题对我们来说主要是目前社区主要由Midokura一家公司来控制,而且从语言方面来说它是用Scala写的,开发难度来说门槛是比较高的,比较小众。特别是对于网络工程师来说是不太习惯的。但是从产品化程度来说,MidoNet是产品化程度最高的,包括流表跟踪,网络包排错的分析,这些它有相应的工具,所以这是值得我们学习的一个方案。其他的像Dragonflow这些新兴的项目我们也都在评估和考察,但是目前还是处在跟进的状态当中。

    4. 也就是说实际上这些网络的问题、存储的问题以及迁移的问题是部署方面的,而不是说单纯是某一个层面的问题?

吴德新:是的,这些都可以解决。

    5. 现在国内有一些我知道的华为、腾讯他们在用OpenDayLight,这也是一个解决方案,从您的角度来讲大家选择SDN解决方案的时候,尤其是开源项目,是从技术的复杂度、易用性、可用性方面来考虑,有没有从部署方面考虑?比如说华为为什么用OpenDayLight?

吴德新:其实这和每个公司的情况是有关系的,因为华为可能要面向很多电信运营商的客户,而OpenDayLight除了网络虚拟化还解决了SDN的问题,它是一个完整的SDN解决方案。我刚提到的解决方案里面很多还是解决了云网络的虚拟化的二层三层问题,并没有解决像服务链的编排,并不是一个真正的SDN解决方案,海云更多是一个OpenStack的公司,所以在SDN这个方向不会走得特别远,也不会选择特别重的方案。

    6. SDN方面,Intel正在比较重的推DPDK跟OVS,它的做法和其他方案相比,是把网络通讯协议栈往上层迁移,您觉得这种方案有哪些优势或劣势?

吴德新:从我们看来,DPDK和OVS这个技术的走向成熟确实能够使软硬件解耦,这样可以打破传统的私有硬件厂商的垄断,能够促进更多的网络领域的创新。从控制平面来说,软件能够更加灵活,从数据平面,更能发挥硬件性能的优势。举例来说像OVS的成熟也给我们带来更多的可能,比如说像之前OVS增加了对连接跟踪的支持,这个功能的增加使得我们可以在neutron里面的网络用OVS代替iptables来做安全组的功能。同时也可以基于这个更容易更简单的实现NAT的功能。甚至我们在社区里面也看到说基于OVS实现七层防火墙的功能,所以就是带来更多的创新。从DPDK的角度来说确实提升了网络虚拟化的性能,如果没有DPDK的话,虚拟网络是没有办法支持像电信行业这样对网络性能要求比较苛刻的负载。同时在数据中心里面我们现在看到对网络服务链的编排也成为一个趋势,如果从性能角度没有强有力支持的话,这些虚拟网络单元的性能也没有办法能够完成它的功能。所以DPDK相当于能够支撑这些SDN技术的持续发展。这些技术使 Linux,或者网络技术更加开放,包括 Linux内核在4.0里面推出了switchdev这样一个驱动,相当于把交换芯片当成一种网络设备像网卡一样驱动,这个的意义是能把Linux操作系统变成像交换机操作系统一样,更容易实现一个白牌交换机,能实现像cumulus这样的方案,把交换交给芯片来做,用户态的网络配置管理包括转发表的管理都是通过Linux操作系统来做。所以整体看网络这个领域是发展的越来越开放,越来越有意思,当然这些技术还都是在成熟的过程当中。

    7. 也就是说它的优势在于实现网络功能变得更容易,跟硬件解耦更成为可能,劣势就是目前还在成熟完善的过程中?

吴德新:对。

    8. 在私有云里面,您接触很多案例肯定也知道,异构存储是个比较麻烦的问题,它同时对灾备的挑战也很大,OpenStack目前有没有一个比较好的解决方案?或者说Ceph在应对异构存储方面它的优势、能力怎么样?

吴德新:您刚才说的异构存储是说同一个数据中心有不同的像光纤,像iscsi这样的存储设备,是这个意思吧?

    9. 对,大概差不多。因为有的企业用户之前有一些老的存储设备和系统,现在又上了一些新的。

吴德新:明白,首先从cinder的角度来说它是支持多个存储后端的,可以针对不同的存储配置不同的后端,在前端调度时候,可以根据后端存储的容量、特性,调度到不同的存储池里面,这样可以根据业务需求灵活的创建存储,这也是符合软件定义存储的趋势。从后端驱动角度来说,确实有些旧的设备是没有驱动的,这种情况一般会有两个解决方案,第一个比如像光纤存储,我们通过LVM这样一个逻辑卷的技术解决,相当于还是在cinder volume一个节点上创造这个卷,负责LVM原数据的修改,这时候不需要分布式锁的支持,因为还是在一个结点上面。在数据层面还是使用光纤的协议来传输数据,性能有保证,不需要通过iSCSI再导出一层,这样性能会有损失。如果要实现卷的一些高级功能,这时候底层存储本来是支持的,那就没有办法,这样可以通过device mapper的其他的东西来实现。这是一个方案。

另外一个方案可以通过比较简单的,你用Ceph Over FC-SAN方案,把Ceph加在光纤存储上,当然不是一个好的方案,但是更简单更容易实施。Ceph本身它在异构存储方面,并不是它的一个初衷或者说它主要解决的问题。

    10. 刚才您有提到容器,我想问一下今年openstack官方宣布了一个容器的白皮书,您怎么看待OpenStack与容器技术融合这个趋势?

吴德新:首先大家都认可容器技术的优势,比如说轻量、便捷,对软件分发会产生很大的好处,有些可能甚至是革命性的。可能在互联网行业里面接受度会比较高,但是对于一些企业客户来说,特别是对于一些业务部门,他一开始的接受度未必有那么高,但是对于IAAS来说,一般企业都已经接受了,比如使用一个虚拟机和使用物理机的方式是差不多,但使用容器和使用虚拟机的方式是不太一样的,所以在IaaS层面快速的能把容器创建起来,能把一些新的业务通过容器的方式来部署,我觉得这个使用场景是有意义的。

另外一点,把容器运行在OpenStack创建的虚拟机里面,由IaaS负责底层的计算存储网络资源的编排,容器对底层资源的管理就不用有太多的负担,它可以发挥它的优势,因为它是比较轻量的,我们可以利用容器本身的编排调度功能,实现在不同的云上面做混合云,甚至加上像服务发现等等一些技术能够在混合云层面做得更加深入。另外一点在OpenStack上面集成容器可能比在其他的公共云里面集成容器会有更多的优势,这是因为OpenStack本身并不是完全定位在IaaS层面,它是定位成一个数据中心的集成引擎。它可以集成ironic这样的物理机管理服务,像马尼拉这样的文件系统的服务,因为容器对于存储来说,可能运行在文件系统上比运行在块设备上更合适,相当于能把你有状态的一些数据保存在web的分布式文件系统里面,这个在容器调度起来会更容易更灵活。从网络层面来说,OpenStack社区有一个项目叫做criu它可以解决容器运行在虚拟机里面,会有一个两层的tunnel问题,criu是可以里面通过tag方案外面通过tunnel方案对网络性能有一些提升。所以OpenStack可以更好的发挥它的集成和编排的优势。

    11. 还有一个问题,容器可能本身在安全上有一些缺陷,私有云在部署的时候主要的安全问题有哪些特点比较突出?另外针对这些安全问题,用户应该怎么做一些防御策略?

吴德新:我们在和客户接触过程中,首先我们会告诉客户怎么做云平台本身的一些访问控制安全策略这些。但是安全这个问题,每个行业每个客户的要求是不一样的。所以,我们在这方面更多的会遵循客户本来的行业的一些安全的做法,主要是通过像网络方面,我们能让他和原有的安全设备打通,保证原有的安全措施、安全策略能够持续在云业务里面继续生效,这是我们主要的建议。

给我留言

留言无头像?