南来北往

栏目: 服务器 · 发布时间: 5年前

内容简介：今年的主题就是工作投入了，刚入职不久，很多流程不熟，有点手忙脚乱。咱们公司的im使用lync，这玩意最强大的功能就是远程协作以及电话会议，公司对lync的使用没有约束，所以也就有最大的缺点，那就是就突然来个lync电话，基本上当下的事情就做不了了。工作内容除了做需求外，就是维护neutron的稳定，处理一线的网上问题。既要熟悉neutron的业务逻辑，还要了解我厂sdn的实现。处理网上问题，最开始我是有点懵，以前还真没有这样被几个人盯着远程桌面守着定位问题的体验，通过定位问题读日志，逐渐把实现了解了个大概。

技能流水

今年的主题就是工作投入了，刚入职不久，很多流程不熟，有点手忙脚乱。咱们公司的im使用lync，这玩意最强大的功能就是远程协作以及电话会议，公司对lync的使用没有约束，所以也就有最大的缺点，那就是就突然来个lync电话，基本上当下的事情就做不了了。

工作内容除了做需求外，就是维护neutron的稳定，处理一线的网上问题。既要熟悉neutron的业务逻辑，还要了解我厂sdn的实现。处理网上问题，最开始我是有点懵，以前还真没有这样被几个人盯着远程桌面守着定位问题的体验，通过定位问题读日志，逐渐把实现了解了个大概。现在面对一些问题，透过现象能猜个七七八八，经验累积显得重要。对于这种开源项目，从问题日志中追本溯源，能更深入理解原理。

三月份左右公司架构调整，师傅去了其它部门，neutron就交给我负责了，包括接需求和讨论方案。与此同时部门成立了openstack组，集结了搞openstack的几个人。这时候有一个任务，是把barbican做进了项目里。barbican主要是存储密钥，到目前为止，已经为lb的ssl卸载和cinder加密提供支持。当前的使用是最简单的，如果把证书管理纳入云项目的话，我觉得后期应该要用到加密设备给做barbican后端存储。

lb早已经从neutron中独立出来octavia，不过实际也没多少厂商针对octavia开发插件，业界通用的仍然是lbv2。

fwaas的v2接口还未启用，可以支持端口级别的acl，对于解决东西向流量的问题很有用，当然也要相应插件的开发。

最近还研究了一下openstack与容器网络的集成，项目是kuryr。搭环境遇到很多坑，填坑之前需得了解k8s，还有network插件cni。后续的话会整理一下kuryr。

对接多厂商

今年有很多项目需要对接其它厂商。算是在这一年内熟悉了三家厂商的sdn，厂商都在社区开源了各自的neutron插件，不过都比较老，实际对接的时候，与社区代码版本差异很大。

年中的时候，接到了和hw对接的需求。社区的优势就体现出来了，当厂商之间无法对齐的时候，起码社区有一个明确的标准供大家来解决冲突统一方案。首要遇到的挑战是要同时支持层次化绑定和多出口，而最难的是协同两厂的sdn控制器实现同一个方案。在客户的数据中心，三方的人都有，当时的情形有点僵持不下谁都难以说服对方，细节就不阐述了，最终还是成功说服了客户采用我司方案。由于讨论超时，当天回成都的机票改签了一次退票一次，又正好赶上周五的上海交通，差点没赶到机场。

八月底出差帝都，现场对接apic，因为家里没环境也从没调试过。每天去客户那里上班，装环境和插件，定位异常。

下半年的工作中，还有对接过f5和a10的插件。过程也并不都是一帆风顺，社区方案有的已实现，有的提供了框架及可调用的接口，而具体的实现需要厂商结合自己设备进行开发。端口层次化绑定（Hierarchical Port Binding）就是今年云平台的方案之一，层次化解决的是vxlan在当前组网下的实现问题，目前很多方案实现都避不开端口层次化绑定。

部分厂商参与社区是很积极的，但是在具体方案实现的时候，反而非常谨慎，尤其是外企。他们之所以会表现如此「保守」，或许是尊重研发当前的实现，以及希望更加完备的社区方案。话说回来，有些扩展虽然能解决问题，但可能就会破坏社区的api和逻辑。