OpenDaylight项目发布铍版本（ODL Be），这也是其发布的第四个版本，距离上次发布锂版本（SR3）仅仅只相隔了两个半月，相比较以前版本发布，时间较短，但是据官方宣称，这个发布与先前版本有着本质的区别，在使用铍版本前，需仔细阅读和理解OpenDaylight 铍版本。
ODL Be版本在性能、可扩展性、功能方面有了很大的改善，新的网络服务在集群和高可用性上提升不少，数据处理、消息传输方面也有很大的提高，提供更好的网络模型抽象，实现网络元素的管理并且对GUI进行了全新的改善，尤其是在复杂的大型网络中会有所体现。
OpenDaylight Beryllium铍版本依赖关系图
上图中所标识的Project Offsets，在wiki中了解到： 项目是被分为3个offsets： Offset 0：最后期限是规定的日期； Offset 1：最后期限是规定的日期 2周； Offset 2：最后期限是规定的日期 4周。
用过之前OpenDaylight版本的小伙伴们知道，OpenDaylight项目的坑真的是太多了，记得之前告诫大家研究OpenDaylight就是“生命不息，折腾不止”。太多的难点和复杂点在其中，比如说即使添加了新功能yang ui，但是yang ui功能太差，bug太多，还不如用POSTMAN来的实在；还比如说，用户文档难懂、不全面，模块开发复杂等等等等。那么OpenDaylight 自发布起已经经历了氢、氦、锂3个版本，Be（铍版本）也已发布，经历了四个版本的OpenDaylight是否满足大家的期待呢。
最近下载了铍版本试用了下，其实感觉坑还是有很多，但是相较于上几个版本，是好了很多，而且尤其是新添加或者完善的功能，都是用户可以直观的使用感受出来的。下面是我使用时遇到的坑和喜欢的地方，小伙伴们在使用时也可以注意下！（PS :代码层面还没有去了解，只是在使用上的体验） 首先获取代码安装使用： 从OpenDaylight官网下载：https://www.opendaylight.org/downloads。 下载后解压：
# unzip distribution-karaf-0.4.0-Beryllium.zip
#cd distribution-karaf-0.4.0-Beryllium/
运行：
# ./bin/karaf
注意：在运行之前进入/distribution-karaf-0.4.0-Beryllium/etc目录，修改org.apache.karaf.management.cfg文件的rmiRegistryHost和rmiServerHost为127.0.0.1，不然运行时会提示serviceUrl错误。 其他的正常安装即可，如下：
opendaylight-user@root>feature:install odl-restconf
opendaylight-user@root>feature:install odl-l2switch-switch
opendaylight-user@root>feature:install odl-openflowplugin-all
opendaylight-user@root>feature:install odl-dlux-all
opendaylight-user@root>feature:install odl-mdsal-all
值得一提的是：此版本完全清除了AD-SAL的冗余代码，没有odl-adsal-*的功能。但是之前的版本中的Node Connector、Container、Network、Flows都是由AD-SAL提供，铍版本官网中说明安装odl-l2switch-switch、odl-dlux-node 和odl-dlux-yangui将在dlux web界面中显示这些功能，但是在实验验证时，仍然没有显示，如下图所示：
修改OpenDaylight配置文件 custom.properties中的监听端口6633后，修改未生效；修改配置文件jetty.xml中的web服务端口8181后，修改生效。具体不清楚6633的监听端口怎么修改。
刚添加的odl-centinel-all功能有bug，安装后web全大写，交换机已成功连接到控制器，但是发现不了拓扑和数据，建议在版本修复稳定前慎用。
详细看了下OpenDaylight提供的文档，文档方面还是很不完善，可能这就是开源项目所特有的，安装文档和用户文档基本上一样，完全没有必要提供两份了；一直想要的API文档还未完善，只能寄希望于以后了。
还有一种可能出现异常的情况：OpenDaylight控制台关掉，并没有清楚data目录数据，且未使用./karaf clean命令，直接使用./karaf命令重启，重启后，通过feature:list -i查看，之前安装的组件仍存在，但是等待很长一段时间后，6633和8181端口仍未被监听到，需要清除或卸载组件后重新安装组件。
但是在使用YANG UI时，比上个版本好用很多，之前的版本在YANG UI部分BUG很多，导致用户更偏向于使用POSTMAN来做RESTAPI的调用和响应，铍版本上的YANG UI在功能上进行了修复，用户可根据自己的喜好来使用YANG UI或者POSTMAN。
除此之外，OpenDaylight Be版本在性能上有所提高，并且在UI设计上支持大型的复杂网络拓扑显示，增加了新的NeXt组件来支持复杂网络的可视化效果。
在铍版本上，仍然重视与OpenStack的集成与对接，但是这一方面我还没有使用，感兴趣的小伙伴可以验证看看。
另外Be版本中增加了很多新的应用程序，这将对SDN的发展过渡变得更加便捷、快速：
新添加项目功能组件： Centinel：为数据流的收集、汇总和分析提供了分布式的可靠性架构的一种流数据处理程序。这个框架结构启用SDN应用服务接收多个数据流来源的事件，如： Syslog、Thrift、Avro、AMQP、 Log4j、HTTP/REST等，并执行如网络配置、批处理、实时分析的操作，提供日志服务以便协助运行SDN生态系统的服务商。
Controller Shield：提供控制器安全信息给北向应用，包括从南向和东西向接口的攻击指标。提出创建一个统一安全插件（USecPlugin）的存储库，USecPlugin是一个通用插件，提供控制器到北向应用的安全信息，安全信息可以用于各种目的，如整理网络中南向插件、疑似控制器入侵或真实控制器上报的不同攻击源信息。插件收集的信息可用于网络配置防火墙和创建IP黑名单，大大提高了网络的安全性。
Fabric as a Service（FaaS）：创建一个物理层之上的常见抽象层，这样的话，北向APIs应用可以更容易的被映射到物理网络上。常见的抽象层模型模拟物理网络作为一个由抽象节点组成的拓扑构造，每个构造通常是在相同控制平面上由部分物理网络抽象出来，并使用想死的数据路径技术，如VXLAN或VLAN技术。每一个抽象构造根据用户的需求提供了一系列的统一服务以及原始结构来创建和管理逻辑网络的生命周期。用FaaS部署网络服务具有以下优点：（1）从供应商和技术规范实施中实现解耦用户网络服务，避免厂商锁定；（2）服务部署和控制自动化，大规模降低了OPEX和CAPEX；（3）提高服务部署的灵活性。除此之外，FaaS将随着底层技术（如系统调用被扩展为OS的发展）的发展而发展，FaaS将以一个向后兼容的方式发展，将具有相当大的潜力。
NetIDE：在单个网络中使用多控制器体系结构的客户端/服务器允许Ryu/Floodlight/Pyretic写成的应用通过启用可移植和协作性运行在OpenDaylight-managed架构中。在这种OpenDaylight实例中分离SDN控制器客户端中承载的各种SDN应用和单独SDN控制器服务器抽象和协作的实际物理网络访问。NetIDE中也包括一个IDE，允许应用程序开发人员开发和测试他们的应用程序，包括一个图形编辑器来指定网络拓扑、一个UI界面来部署配置、编辑指定网络仿真环境和支持配套工具套件（调试器、分析器、模型检测等）。
NEMO：一种基于事务的北向API，允许应用程序使用基于意图（intent-based）的策略，基于DSL（Domain Specific Language）接口来抽象网络模型和表现操作模式。其中北向接口（NBI），位于控制器和应用程序/服务之间，主要目的是启用应用创新和，通过抽象网络功能/信息和开放抽象/逻辑网络到应用中来优化SDN生态系统。若要实现一个新颖的NBI设计，可以从SQL成功案列在学习，从语言形式中将复杂的数据操作简化成统一直观的方式。应用不定义数据存储和数据操作的根本机制，只在数据存储和数据操作中描述预期然后得出结果。作为数据域的DSL，SQL简单而且直观，并且能够嵌入到程序中。NEMO语言是基于网络模型抽象和操作方式结论的一种DSL，在语言形式中提供NBI方法，代替很多抽象APIs，使网络用户/应用以直观的方式描述网络资源、服务、逻辑操作等需求，可以通过一种语言引擎执行。
NeXt：提供网络中心拓扑的UI组件，显示大的复杂网络拓扑，汇总网络节点、流量、路劲、tunnel、group等可视化效果，包括不同的布局算法、图像叠加以及用户友好的预设置交互，提高了性能并丰富了UI的功能，能够与DLUX共同构建ODL apps。
Messaging For Transport：OpenDaylight控制器是基于允许data、RPC和通知建模的MD-SAL构成。因为基于这个模式的基础上，给控制器增加新的北向绑定是简单的，且很容易的实现和集成，所以添加的Messaging Oriented Middleware (MOM)北向绑定除了将YANG规范映射到一个RESTful接口的现有RESTCONF接口，还包括高级消息队列协议（AMQP），以及可扩展消息处理存在协议（XMPP）。
UNI Manager：启用网络元素中用户网络接口（User Network Interface）功能以及网络元素间连通性的配置管理。UNI Manager PoC插件使用ODL OVSDB南向API来配置OVS实例并形成端口间的桥，仿真一个简单的User Network Interface (UNI)，形成一个GRE隧道，以此模拟一个简单的以太网虚拟连接（EVC），用于以太网专线（EPL）的点对点服务。Linux基金会OPNFV涉及的一个相关项目叫做Connectivity Services LSO (LSOAPI)，该项目制定了一套API，且这些APIs的以太网专线服务的实现提供简单的服务编排功能，并可以使用UNI Manager插件的北向REST接口来管理网络资源（OVS实例），配置UNI和EVC功能。因此，UNI Manager插件提供了资源层的功能和LSOAPI提供了以太网专线服务层的功能。
OF-CONFIG：实现了OF-CONFIG协议，启用OpenFlow逻辑交换机基本构件的配置，OpenFlow控制器能够通过OpenFlow协议对OpenFlow逻辑交换机进行通信和控制。OF-CONFIG在抽象层定义一个OpenFlow交换机叫做OpenFlow逻辑交换机。
