作者：Maxwell Li
日期：2017/03/25
未经作者允许，禁止转载本文任何内容。如需转载请留言。
为了催熟 Compass4NFV 部署工具，促进 Compass4NFV 项目商业化，与 NFV 预集成开发部达成合作，为他们提供第三方 IaaS 部署工具，遂前往西安，支撑 NFV 预集成开发部实验室利用 Compass4NFV 部署环境，并进行能力输出。原本仅安排了三天的行程，但是由于 NFV 预集成开发部的网络结构远比想象中复杂，并且他们对 Compass4NFV 提出了不少需求，只能在西安进行现场开发，所以出差时间远超预期。附 NFV 预集成开发部网络结构：
西安组网图.jpeg
下面对出差中的主要工作进行简单的总结。
环境部署
到西安的第一个任务自然是搭建环境，出发前就知道黄区的网络肯定不像蓝区那么自由，特地提前下载好了 Newton 的镜像和代码带过来，但准备还是不够充分。主要问题如下：
- NFV 预集成开发部需要修改 OpenStack 各个组件配置文件，使其更加适合我司的 VNF。而如果修改 ansible 的 template 文件，要在下一次安装时生效，必然重新 build 镜像。如果每次 build 镜像都去我们的 Http Server 上下载包，速度太慢，不现实。我必须借用酒店网络将所有需要的包从 Http Server 上下载到 PC 端，然后拷贝到他们的环境上。
- 从上图可以看出，NFV 预集成开发部需要使用 Bond。他们有三台 2288V3 和一台 2288V2，V2 作为 JumpServer，对三台 V3 进行 1+2 部署。每台服务器有两个电口作为 PXE 口，四个光口作为业务口，需要两两组成 Bond。这里碰到了两个问题。一、光口的 mac 地址在 BMC 控制台上无法查询，只能够装完系统再通过 ifconfig 查到；二、Compass4NFV 暂时还不支持 Bond，需要开发。
- Compass4NFV 物理部署至少需要两个网口，一个用来进行 PXE 启动，另一个连接 JumpHost 的 br-external 网桥，访问外网，如下图所示。但是由于 NFV 预集成开发部给 PXE 口、Bond1、Bond2 配了不同的交换机，所以只能舍弃 br-external 网桥，需要现场开发。
物理部署组网图.jpg
整个环境搭建差不多花了一周时间。
OSP8 版本适配
前面提到我带了 Newton 的镜像和代码过来，结果 NFV 预集成开发部需要的是 Ubuntu 14.04 Mitaka 和 Ubuntu 16.04 Mitaka。好不容易把 Mitaka 环境搭起来，准备搭建 OSP9。然而由于当初开发 OSP9 时没有 Cpeh 的源，因此 OSP9 并不支持 Ceph。然而 Ceph 是他们的硬性需求，必须有，所以又找 OpenLab 要了 OSP9 的源。拷贝、传输、搭建 OSP9 源又花了两天时间。然而在一次需求对标的站会上，才发现他们根本没有 OSP9 的需求，需要的是 OSP8！那次站会也发现了很多问题：
- NFV 预集成开发部需要我们把环境搭建起来，但是没有一个检验的标准。之前的测试项目也是想到哪个测哪个。
- 需求传输不准确。Newton 变成了 Mitaka，OSP9 变成了 OSP8，这些问题完全是由沟通引起的，不光是他们内部的沟通，还有他们和我们的沟通。
针对第一个问题，NFV 预集成开发部提出了 14 个基础测试用例。张玉明测试发现问题后，主要由梁哥定为解决。目前主要在进行热迁移的优化，当然也有一些问题暂时无法解决，例如实例 reset 后无法自动重建，无法实现 HA。针对第二个问题，只能加速开发。好在 OSP8 版本适配还算顺利，在制作 OSP9 源的时候就顺便做了 OSP8 源。而且已 OSP9 的代码为基础部署 OSP8，没有出现特别棘手的问题。
收获
此次出差虽然辛苦，但也学到了不少东西，尤其是在网络方面，对 Bond、OpenStack 组网以及 Neutron 网络虚拟化都有了些了解，之后也会进行整理总结。另外，对 Compass4NFV 这个项目也有了更加深入的认识，与我司 FS 以及红帽 Dirctor 的对比也看到了我们的不足，需要优化的地方还有很多。优化一个产品，最好的方法就是让别人使用，使用得越多，暴露出来的问题就越多，一个一个解决，产品终会完善。
网友评论