 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
SDN应用及北向接口技术研究
下载积分：600
内容提示：SDN应用及北向接口技术研究,—总结 计划 方案 汇报 党建 思想 合同 协议 报告 规划 行政 商业 营销 毕业论文 大学论文 资料 文档 英文 求职 免费阅读 免费分享如需请下载！
文档格式：PDF|
浏览次数：1|
上传日期： 13:00:45|
文档星级：
该用户还上传了这些文档
下载文档:SDN应用及北向接口技术研究.PDF
官方公共微信&&OpenStack 相关文章
网络频道OpenStack相关文章
选择其他频道
我还想看其他领域的文章
2014年，软件定义网络的发展趋势很大程度上可以定义为从理论到行动的转变。具体而言，供应商将技术产品化，工程师找到了实现软件定义网络(SDN)的技能，为改变做好准备。
即将过去的一年，对SDN行业来说是疯狂的一年，众多的玩家都制定了有关SDN的战略和战术计划，但立场则无非两种：要么就站在发展的前沿，要么就试图抵消SDN所带来的冲击。
近日，戴尔持续扩展旗下的开放网络计划，并与网络虚拟化（NV）公司Midokura结成合作伙伴。根据合作伙伴协议，Midokura的MidoNet软件将成为戴尔的开放网络参考架构的一部分，两家厂商将根据全球分销协议进行营销方面的合作。
博科近期宣布成为经过认证的Mirantis技术合作伙伴。双方将携手为云运营商提供新的基于OpenStack，且按需扩容的数据中心交钥匙解决方案。Mirantis和博科的客户现在只需花费数天而非数月，就可以利用OpenStack来安装和扩展云运营商网络。
中国的网络硬件企业已经开始迈出新的脚步，意欲踏向世界范围内的开放领域。具体而言，中兴公司已经加入到Open Platform for NFV（简称OPNFV）项目当中。
Akanda是从云提供商DreamHost分拆出来的公司，它将提供面向OpenStack云的开源3-7层虚拟网络功能平台。这家公司将它的技术称为第一个为生产环境准备的开源网络功能虚拟化(NFV)项目。
超大规模数据中心的发展、Intel最新Grantley平台以及企业对OpenStack的应用等都在很大程度上影响了企业对网络的要求，Emulex将顺应这个新形势，更新自身的产品。
华为以金牌会员顶级赞助商身份闪亮参展巴黎的OpenStack全球技术大会（“OpenStack Summit2014”），与60多个国家的4000多名全球大会来宾共同探讨OpenStack的发展创新以及云计算产业链建设。
OpenDaylight宣称这套结合了软件定义网络与网络功能虚拟化（简称NFV）机制的平台能够构建Apache Karaf容器，并宣称其拥有更理想的OpenStack环境集成能力且包含有Open vSwitch数据库集成项目。
Mellanox瞄向云计算，为了充分降低IT的成本，释放云计算的性能，推出了CloudX云计算基础平台的推荐架构。CloudX并不是自己在销售软件，也不是在销售方案，而是向业界推出一个最高效、最高性能、最具可扩展性的云计算基础架构。
想在现有网络中集成OpenStack你需要对OpenStack网络有所了解。现在让我们了解一下部署一个私人OpenStack到现有的网络中所涉及到的一些基本概念。首先，先简单介绍一下。
下午好！IT女主播来和大家一起欢乐地看新闻啦！今天的新闻都与OpenStack有关，惠普和红帽都将利用OpenStack展开新天地！让我们来欢乐地看一看――吐槽高科技，谁说不可以！
OpenStack 集成表明 F5 一直致力于在不影响应用交付的情况下,帮助客户部署其所选的云平台。
Neutron是OpenStack项目中的“网络即服务”技术，它的作用在于帮助管理员创建、配置并管理软件定义网络体系。惠普公司已经坦言OpenStack项目中的网络组件仍存有不足，因此整个技术社区都需要认真反思如何在未来的工作中推动其发展完善。
一个月前，思科公布了一个用OpFlex协议定义网络策略的新方法。4月2号，OpFlex控制协议以Internet Engineer Task Force (IETF)草案的方式提交。
博科近日宣布MATT LOLON担任博科亚太区首席技术官正式履新，并计划在三个领域进行突破，一是以太网矩阵，二是软件定义网络（SDN）和网络功能虚拟化（NFV）。三是支持OpenStack和OpenDaylight项目。
日至21日，“2014全球SDN技术大会”将在北京召开。本届峰会亮点颇多，ONF PlugFest首次移师中国、众多SDN国际组织首次集体对话、全球SDN权威专家共同开课等等。
在不断变化的混合云领域，IT面临的一个关键挑战是看清楚到底在发生什么事！所幸的是，有一些工具可以帮助IT服务交付人员在快速扩张的混合云基础设施边界建立新的观察位置。
近日，戴尔公司为OpenStack云带来了一系列大型交换机设备，并且戴尔在其最新推出的交换机控制器设备上明确标注了两大热门用途，即软件定义网络（简称SDN）以及大型数据中心交换环境。
戴尔今天宣布推出新的网络解决方案，帮助客户在横向扩展和云环境中更快速地取得成果、最大限度提高效率，并实现运营的变革和现代化。新产品包括戴尔网络 Z9500，这是目前市面上密度最高、按需付费的高能效，高密度/机架单元，10/40 GbE数据中心核心交换机。
12345678910
今天，博科专家将通过线上视频的方式开讲"SDN驱动的下一代云服务"，为您揭开软件及开放网络的奥秘，并通过线上讨论的方式同广大网友共同探讨SDN驱动下的云服务话题。
&&&&&&&&&&&&&&&
& CBS Interactive. All rights reserved.
北京智德典康电子商务有限公司（至顶网）版权所有.
京ICP证010391号 京ICP备号-159
京公网安备：
CBSi中国媒体Openstack应用实战解析及开发入门 - 开源力量丨向IT技术大牛们学习！ - 大数据丨云计算丨移动开发丨软件开发测试丨 全球前沿技术抢先学！！ - Powered by EDUSOHO
——这是开源力量精心打造，在全网首次推出的OpenStack网络培训课程。通过学习该课程，您将会使用OpenStack手工和自动化安装、配置和维护云计算环境，并能区分其差异，还能帮助您对openstack源码进行修改定制，更重要的是，您还能获得一线专家在每日管理上万个实例的大规模运维经验，这将使您的IT技术得到极大的提升。
今天在所有有关云计算的开源项目中，OpenStack已经成为耀眼的明星，被众多厂商和技术人士所关注与推崇。但快速发展中的OpenStack, 也引来了一些问题与困惑？ OpenStack的可支持能力是否值得信赖？企业在部署OpenStack时硬件兼容性如何保证？所部署的OpenStack的生命周期是否要求对基础架构平台进行频繁的升级？openstack版本源码不断升级，如何平滑升级与定制......通过该课程，您可以看到一线企业如何使用OpenStack，他的经验和课程将解决你的所有疑难杂症。
视频滚动学习，终身有效
老师指导实战练习辅导
24小时讨论区回答
每周视频坐班直播互动答疑
期末结业考试
QQ同学会交流
更详细说明见这里： （六维学习法）
——本课程收获，您可以:
深刻理解：OpenStack的设计原理，体系构架和关键技术，构建一个OpenStack环境所需的核心组件以及核心组件间的联系；
全面掌握：如何通过不同的部署工具比如packstack，部署OpenStack环境；如何通过单独部署OpenStack核心组件逐渐搭建出OpenStack环境；
定制研发：在学习openstack源码级深度解析培训后，你能了解openstack源码的体系结构，并能根据需要进行定制开发，满足您在实际生产环境中OpenStack的各种疑问和不满足的功能。
熟悉基本的linux命令
具备基本的网络知识
掌握一门编程语言
同学会QQ群：
课程咨询QQ（开源力量-刘老师）：
OpenStack的设计原理，体系构架和关键技术，构建一个OpenStack环境所需的核心组件以及核心组件间的联系；
如何通过不同的部署工具比如packstack，部署OpenStack环境；如何通过单独部署OpenStack核心组件逐渐搭建出OpenStack环境；
在学习openstack源码级深度解析培训后，你能了解openstack源码的体系结构，并能根据需要进行定制开发，满足您在实际生产环境中OpenStack的各种疑问和不满足的功能。
第 1 章：　OpenStack介绍、安装与部署
第 1 节： 第一周：OpenStack概论及自动安装
第 2 章：　Keystone、Glance组件分析
第 1 节： 第二周：Keystone
第 2 节： 第二周 学习内容：Glance
第 3 节： 课后练习
第 3 章：　Nova、Neutron组件分析
第 1 节： 第三周：Nova
第 2 节： 第四周：Neutron
第 3 节： 第四周：Neutron SDN
第 4 章：　Cinder、Swift 组件分析
第 1 节： Cinder
第 2 节： Swift
第 5 章：　OpenStack Dashboard 使用
第 6 章：　OpenStack HA部署，日志和性能调优
第 7 章：　Openstack源码修改及开发入门 - Nova 篇
第 1 节： 初始环境搭建
第 2 节： Nova 源码解析
第 3 节： Nova 功能扩展
第 8 章：　Openstack源码修改及开发入门 - Horizon 篇
第 1 节： Django 快速入门
第 2 节： Horizon 定制化页面扩展
第 9 章：　OpenStack 项目实战入门及经验介绍
第 10 章：　结业考试
正在载入课程评价数据...
开源软件爱好者。目前任职某知名世界500强电信公司，从事云计算相关产品研发工作，多年云计算IaaS、PaaS、SaaS相关产品开发运维经验，尤其擅长基于IaaS的持续交付系统设计与开发，目前所在团队管理着日部署上万个Instance的OpenStack集群，支持每天上百次产品部署发布，对开源云平台OpenStack开发和运维都有较深入的研究。
服务时间： 9:00 - 21:00
刘老师： 021-
微信公众号：开源力量SDN 200G流量的考验
专家与用户的区别&&写在前面的话
&&一帮骨灰级的，不愿被网络产品厂商技术绑架，自行研究出的用软件控制网络流量转发技术，目前正得到多方面的关注与追捧。此情此景，不由让我想起十多年前刚工作不久，有幸进入一家国内知名杀毒软件公司做一个小小的技术支持人员。那时泛滥，每到4.26被CIH病毒破坏的硬盘成堆的摆放在我们面前。为了缓解这种情况，我们和&王老师&的公司推出了两种相同又不同的解决办法：&王老师&公司是告之用户如何用他们的软盘启动电脑后通过类似DEBUG的工具编辑硬盘分区表，并进行改写，从而将被病毒破坏的引导头信息恢复。我们是告诉用户软盘启动后，如何在菜单选项中选择自动修复硬盘。我当时的领导形象的将这两种解决方案称为一种是将用户培养成为数据修复专家，一种是为用户提供解决方案。事实证明，最终我们成功了。而现在的SDN给我的感觉和以前一样&&我们应该用什么方法帮用户修理&硬盘&?
大二层的兼容与异构&&对SDN观点的转变
由于初期对SDN技术没有深入了解，使我产生一种SDN是一帮技术高富帅玩的东西，与我等潘亢廖薰氐墓鄣恪５蔽叶SDN进行一番挖苦之后，思博伦SDN测试技术资深专家罗fF的一翻话，使我对SDN的观点有了根本性的改变。&SDN并非不堪重用，不但在国外大型数据中心中已经有很多成功应用，即便在国内电信行业中，也正在试验利用SDN解决传输网数据通讯问题。& 传输网也在试用SDN?这段话让我开始对SDN技术进行重新审视。不由得回想起多年以前参加某企业网络系统验收时的一个情景：该企业网络系统规模庞大，部门间采用三层OSPF交换设备进行连接，为保障数据传输的可靠性，采用的是的形式部署。测试网络切换时间时发现，由于需要重新汇聚，即便是在简单测式环境中，统计单位也是以分钟来计算，每次倒换的时长基本在十几分钟以上。也就是说一但出现故障就会有长时间网络瘫痪的情况出现。当问及为什么采用时，承办方给我看了一张企业内部有着密密麻麻网络设备节点的，并问了我一个问题，不用OSPF我怎么把这么多网络设备连起来?!一句话问的我哑口无言。再回头看现如今的传输网，同样的问题再次出现，三层网络路由倒换时间漫长，大二层技术各厂商自行其事，而这一张大网又绝对不可能由一个厂商的产品进行部署，用什么办法才能将这张网高效率的连起来?看来不是通信企业主动选择SDN，而是SDN所具备的先天技术优势逼迫厂商不得不进行选择。
理想与现实的差距&&实际测试中的问题
理想是美好的，但现实是骨感的。这句话用在现在的SDN上可能会非常的合适。为了考查SDN交换机的实用性，《网络世界》评测实验室也试着组织了一次以验证SDN交换机实用性为目的的架顶式交换机SDN功能公开比较测试活动。
活动初期，各交换机厂商对此有着积极的响应。得益于、、和这几家厂商在前期的交换机SDN功能调查中的及时回复，使我们初步了解了目前SDN交换产品在生产厂商中的技术发展情况，使得SDN交换产品测试的初步测试方案可以顺利制定。在随后《网络世界》组织的SDN交换产品测试方法研讨会上，Avaya、博科、思科、瞻博等厂商也积极参与了测试方法的讨论。然而实际测试时的情况刚好相反，仅有一家新兴的SDN交换设备厂商xNet(网锐)公司提供产品进行测试。
为什么会出现这种情况?从与各厂商研讨测试方案的过程中，可见一些端倪：与ONF组织的PlugFest测试不同，既然要进行SDN交换产品实用性测试，除了一些数据中心的组网及用户管理功能外，必然要对SDN交换机的网络转发处理性能进行测试。得益于思博伦通信对本次测试的大力支持，我们可以用思博伦TestCenter测试仪表产生一个很大的测试流量，并且可以构造出一个很大的流量表，来测试SDN控制器对大流量的处理能力。而这个测试项也是在测试方法研讨中，各厂商讨论最集中，顾虑最多的一项。原计划在测试中，采用20个万兆接口，每个接口设置200个IP地址，所有IP地址成网状连接并进行转发。这样设计，预计可以构造出一个1600万条以上的巨大流表。之所以这样设计，是考虑到在目前的现网环境中，一个万兆接口肯定不会只有一个接入IP，单个万兆端口200个接入IP已算是一个相当保守的设计了，而全网状转发这个测试项，对于传统二、三层交换设备来讲，也不是一件困难的事情。然而参与研讨的厂商纷纷遗憾的说，目前万兆TOR交换设备在SDN功能上支持不了这么大的表项。目前比较理想状态下，万兆TOR的交换机表项也就在4000条左右(这够干什么的??)。于是改为在产品所支持最大表项下进行流量转发性能测试。即便如此，那些表示将要参与的厂商也都再未出现，还好有xNet的积极参与，才使本次测试活动可以顺利进行了下去。
功能测试&&SDN不负所望
虽然参与厂商仅剩下了一家，但正是因为xNet的大力协助，使我们的测试活动还是可以继续进行了下去。在功能测试中，我们对在中呼声最高的环网连接、数据流路径切换和用户权限管理这三项功能进行了测试。
环网连接，这可以算得上是大二层云计算网络的标志性功能了。环网连接无风暴，根据路径智能选路，这些全新的网络应用功能在SDN交换网络中是否可以实现，下面，我们就实际的验证了一下。
在这项测试中，我们采用了两台48口千兆(具备4个万兆上联接口)X1-48T和一台48口万兆(4个40G上联接口)的X10-48S型号的xNet 白盒SDN交换机进行了组网测试。测试中，我们将三台交换机的6个万兆接口两两互连，通过第三方Floodlight控制器组成一环形网络。(网络拓扑及实际测试环境参见下图)
Floodlight自动生成网络拓扑
环网实际测试环境
在随后利用两台PC接入环网进行测试发现，三台SDN交换机通过Floodlight控制器组成的环网中，未出现广播风暴现象，两台PC可以互相Ping通，数据传输正常。由此可知，在现阶段SDN交换设备在设备组网功能方面，还是可以满足大二层组网的应用需求的。
顶一下(1) 踩一下(0)
热门标签：酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
【编者按】David Laube，充满热情的互联网基础设施构建者，工作涉及托管服务、基础设施自动化和可扩展平台的部署。目前担任packet.net主管平台系统的副总裁。OpenStack是一个开源的IaaS实现，目前在企业得到越来越多的应用，本文分享了packet.net利用 OpenStack开发的一套云计算管理平台的实战经验，以及在开发、运营、维护过程中遇到的问题和经验分享。
以下为原文：
去年初夏，我的同事，也是公司的CEO，向我求助如何构建一个现代化且任何东西都不安装的云托管平台。我回想自己以往的主要从业经历，包括构建，支持和使用可扩展的基础设施的经历，不禁犯起了嘀咕。我问自己，真的需要这样做吗？不是有很多不错的基础设施即服务（InfrastructureasaService，IaaS）可以拿来用吗？
随着沟通的深入，我最终意识到现在很多云服务不是用户友好型的，使用起来存在很大的困难。另外，我是Docker的早期用户，Docker是应用容器引擎，这种容器支持的部署方案会使高质量的物理裸机在运维工作方面更加给力。但某些公有云的虚拟化情况，还有一些托管服务商存在的问题，都没能与复杂多变的物理硬件发展的需求相匹配。于是我觉得需要为此做一些工作。接下来咱们随着packet.net的部署旅程一起过把瘾吧！
开始安装之旅
我一头扎进了部署packet.net的工作。还同时忙着关注部署策略和云自动化的相关动态，从头到尾地检查特定安装程序，还有所有的开源云平台，以及我们已经安装的那些服务。
Voxel是被Internap收购的一款云主机托管平台，我们在使用的时候部署了很多自己的程序，在这过程中既看到了带来的好处，又体验了自己拥有软件平台的感觉。服务器的安装工作看起来似乎特别容易，好像一旦完成，一劳永逸，对吧？但这是绝对的错觉！因为安装完成后会出现数不清的网络问题，还有随时发生的硬件调整，以及各种操作系统存在的差异。在这样的情况下为用户提供不折不扣的自动化服务，安装并管理数千台服务器，并确保这些服务器正常工作，在五分钟之内还能响应Zac做出的决定。这对我来说可不是件轻松的事情。
为了使packet.net到达预期的目标，数千台服务器7x24小时不断地安装和启动，并要在数月后上线。我开始关注在互联网基础设施方面的独特之处，它可以被当作我们构建服务的手段。这包括联网业务的自动化，IP地址的管理，安装过程的监控，以及硬件的调换和安装。如果我能依靠OpenStack这些核心项目完成工作的话，那么我的团队就可以更加专注于能给用户带来更多价值的事情，像硬件分析，还有对容器机制的应用引擎提供技术支持。
别人提醒过我OpenStack存在的一些隐患，但我还是自己花了数周时间去阅读近期的版本记录，混迹于好几个维基的IRC官方聊天频道，并且玩了一下OpenStack的安装脚本。我开始对OpenStack的核心项目不再那么陌生。在过去的两年中，DevStack已经发展得非常成熟，而且所逢时机也刚刚好。全球领先的托管服务器及云计算提供商Rackspace最近发布了OnMetal物理裸机服务器部署方案，并公开撰写博客指出如何在其物理机上使用进行部署。而美国时间日，OpenStack的一个重要的版本，Juno版也正式发布了。
所以我觉得应该使用OpenStack来为公司的物理服务器进行部署。
部署的过程
我知道学习OpenStack的过程不会平坦，并且明白这需要拼命努力学习其中的每一个项目，而不只是安装。我细致深入地研究OpenStack每一个项目，尽力去了解Nova的动态，还有Ironic的驱动程序，特别是Neutron。我们不仅要在物理服务器上安装Ironic，还要支持packet.net托管服务的网络模型，特别是要用Layer3取代Layer2和VLAN层主机的功能。
这个时候你可能说：&喂，要阅读和学习的文档那么多啊&！在过去的一个月里，我明显能感觉到我们所接触到的文档不是过时的就是有错误的。这让我不得不去从以前优质的文档中去删选内容，比如从维基上的文章，IRC（一种聊天工具）的日志，还有版本提交记录，从这些地方去寻找最新的正确信息。这些基础工作完成后，我要用python去做大量的调试工作，去验证各种与文档描述不一致的功能。比如这个是否工作，那个是否正确，这是很漫长的过程。
值得一提的是，存在着那么一群人和公司，他们依靠OpenStack生存，组成一个很大的共生系统，特别是OpenStack的Nova和标准的Neutron项目相关的部分。尽管从规模上这个群体可以与其他开源项目进行匹敌，但其实对于Ironic来说，他们很难有人能够达到产品级的使用水平。我就碰到过这样的情况，我向其核心开发人员咨询了一些实施的问题，他们居然答不上来。并且我从Google搜索这些问题，也仅能得屈指可数的几条与问题有关的信息。
经验一：OpenStack规模不小，新兴并发展迅速，但要了解一些过去的基本信息，会感到相关的文档良莠不齐。
我把Neutron部分交给了我的同事去处理，而自己又深入地了解了Ironic。但实际的情况是，我们需要OpenStack每个部分特定的开发人员，让他们帮助我们去理解代码库，才能跟上OpenStack每个项目更新的脚步。那我们又怎么去恰如其分地满足自己的需要呢？于是我就通过IRC和来自Rackspace的OnMetal团队成员接触，还通过邮件联系。去逛OpenStack开发者论坛。我敢打保票，自己阅读了每一个相关文档，还有论坛里的每个帖子，而且还通过Google搜索出的相关信息去调试Ironic，这些我都做到了!
尽管对于先前那种Ironic项目来说OpenStackNova版的物理服务器部署方案取得了突破性进展，但是OpenStack还是以虚拟化技术为核心进行设计的。仍然存在很多功能和文档的修改还介于Nova的物理机部署方案和带有驱动的Ironic部署方案之间。我把这种情况反馈给了力量有限的Ironic技术支持部门，却硬被要求使用与虚拟技术相关的openvswitch和linuxbridge。我们的网络模型与此存在严重的冲突。于是我发现，OpenStack的Neutron项目不仅缺乏针对特定网络产品厂商的技术支持，也缺乏对不同网络模型的扩展能力。
对OpenStack的核心代码有更深了解的大用户（最典型的就是Rackspace公司），依靠将OpenStack的那些项目高度定制化后，使之能够在实际的物理网络上部署物理机。其中有几个补丁是已经发布了的，但很多重要的补丁都没有公开，需要用户自己重新编写，同时还要对以后新发布的版本进行维护。
经验二：OpenStack是基于虚拟化技术的平台，如果你用的不是虚拟技术，那就要再考虑了！
到了这份儿上，我已经对使用OpenStack部署公司服务产生了严重的怀疑。这么多需要了解的东西，还有要做与每个项目保持同步的工作，这样的情况令人望而生畏。并且，我开始认识到要对Nova和Ironic所做的定制化工作并不是小事一桩，这会抵消掉OpenStack在开源方面所带给我们的好处。
但我还是觉得完全了解Neutron的细节非常重要，这是我目前唯一的念想儿。
对于物理交换机和服务器来说，安装部署服务器并不太困难，而且解决方案十分成熟可靠。而自动化工作却需要很多工具配合工作才能完成。从我的经历来看，大多数基础设置部署工作最容易出错的部分就是网络部分的自动化。你看，物理交换机的操作系统还存在很多不足之处。对当前的自动化工作和API的交互的支持显得捉襟见肘。其实，我用过的另外一款网络自动化工具的蹩脚表现是让我考虑使用OpenStack的主要原因。Neutron项目有非常令人振奋的使命：可以按照需求提供可扩展，不受制于任意一项技术的服务，包括相关的库。我也希望是这样呀！
但现实并不像所承诺的那样。根据软件定义网络（SDN，SoftwareDefinedNetworking）的说法，大多数在基于虚拟机监视器（hypervisor）的虚拟网络下工作的项目并不是真实的交换机。不仅是因为对于交换机厂商来说严重过时的Neutron驱动，而且OpenStack最新的Juno版本的支持工作也力量有限。另外，Neutron使用了自身并不完善的IP地址管理器（IPAM），根本没有任何自己分配外部访问方式的概念，也没有提供关于IP地址管理方面的书面说法和权限。牺牲用户体验来适应Neutron这些不足，这是不能接受的。
经验三：OpenStack的Neutron项目支持工作并不那么完备、系统。使用之前要先看看自己的交换机能否适应。
这样一来，我们要如何应对？
长话短说。在圣诞节的前一周，我们丢掉了OpenStack，然后又花了三周的时间开发了一套定制化的自动化部署平台。在十二月初搭建好自己的IP管理系统后，团队就卯足了劲要将系统搭建自己定制工具上。而每个新项目都会有自身的使命。作为一家公司，我们的愿景是不断进取，并且我们觉得，在调查和部署OpenStack的过程中，解决了存在的大部分问题：构建了一个灵活且能提供服务功能的IPAM系统（我们管它叫MagnumIP）。在设施管理平台和物理基础设施之间，我们还建立了用户和权限模型。
有时现存的东西并不一定是最好的，也不一定能满足自己的需要。我们使用OpenStack部署packet.net的过程就完全说明了这个道理。同时，我们也会努力发布自己的Neutron插件，与OpenStack项目的发展相适应，我们现在正在做。
之后的一周时间，我们最终完成了CoreOS系统的安装（这也是在考察了Ubuntu，Debian和CentOS后做出的决定）。工作精益高效，对变化反应迅速，对系统记录详尽，这样我们可以做一些高级功能和高可用性工作，而又不会影响到用户体验，这让我感到激动不已。我能说自己工作学习两不误吗？
& 相关主题：