OpenStack部署尚存的问题-TechTarget中国.PDFVIP

OpenStack 部署尚存的问题 OpenStack 部署尚存的问题 对于宜家家居，大家都很熟悉。它具有很高的性价比，而用户可以自己组装家具。宜家家居给用户提供了 个性化的选择。但是，如果出了问题，谁该为此负责呢？是该责怪宜家的组装太复杂 ，还是归咎于用户的组装 方法不正确？ OpenStack 平台也存在着相同的问题。这一开源平台具有大量的组件，有人称之为这是未来的云模型。事 实上，只因为市场上用户有只这一个开源平台可以选择。虽然 OpenStack 独占鳌头，但用户也不能过渡迷恋 于它 ，毕竟它还尚存一些问题需要解决。  缺乏自动化：OpenStack 自动化发展进行时  管理有挑战：克服 OpenStack 管理挑战的五个窍门  更新是问题：OpenStack 更新最小化风险和停机时间  混合集成问题：如何克服 OpenStack 混合云集成问题  可扩展性问题：OpenStack 可扩展性挑战 IT 人员的耐性 2 / 15 OpenStack 自动化发展进行时 虽然像 Heat 和 Graffiti 这样的 OpenStack 工具可以帮助 IT 专业人士实现该开源平台的自动化，但 2016 年仍然有一些工作需要完成。 许多企业正在转向 OpenStack 作为他们的下一代云计算平台。尽管不少公司已经作了前期试验性安装， 但从一个试验阶段过渡到大规模的 OpenStack 部署对一些公司来说并非易事。在某种程度上，这是由于 OpenStack 的快速采纳；OpenStack 是一个流行的私有云方案，但 OpenStack 的技能和培训并没有跟上需 求的增长。 让这一切变得更加复杂的一个事实是，OpenStack 就像是一个移动的目标，因其一直在进化以及 围绕 OpenStack 出现的一系列竞争的软件生态系统。并且 OpenStack 的技术支持一直很难寻求，这也让一般 的 IT 专业人士望而却步。 解决这些复杂性的方法之一是 OpenStack 自动化，这也是 OpenStack 的项目如 Heat 和 Graffiti 所围绕 的。Heat 是一个业务流程编排工具，有一个与亚马逊 Web 服务的 CloudFormation 模板兼容的模板设计，用 以推进和公有云的整合。Heat 还提供自动扩展的服务，而 Graffiti 旨在提高跨服务的资源元数据协作。 但即使这些工具也没有让 OpenStack 的部署和控制变成一套完整的解决方案。更何况，符合任何可靠性 标准或服务水平协议对于大多数的 OpenStack 部署来说仍有一条很长的路要走。许多厂商提供自动化工具来 帮助解决其中的一些问题，但这些工具的选项数量庞大，再加上彼此之间并不都能交互的事实，使得 OpenStack 向外扩展的过程危机重重。 服务器和虚拟实例的业务编排是 Heat 的重要组成部分，但那些服务器厂商如惠普 企业、戴尔和 IBM ，都有意得到OpenStack 的领导地位，提供集成服务和支持，以及他们自己的 OpenStack 云秘方。这些参与者带来的一大负面影响是潜在的厂商锁定问题。 在这个领域里的另一个厂商是 Red Hat。今年，Red Hat 收购了自动化厂商 Ansible ，它允许用户以一个 易于使用的格式创建配置 “剧本”。Red Hat 也是 Ceph 存储的领导者，因其对 Inktank 的收购。这些工具让 用户更容易创建模板，将重复性的工作编纂成代码，并减少人为的错误。 SDN 在 OpenStack 自动化中的角色 网络的一个发展趋势是软件定义网络（SDN ）。在云端的虚拟网络 管理可能会很困难，因为性能、安全性和用户体验仍处于早期阶段。软件定义之举看起来是想要通过虚拟网络 服务和使用裸机交换机来简化这个问题。 3 / 15 诸如 Big Switch Networks、Nuage Networks 和 Juniper Networks 这样的公司都坚决采用 SDN 的做 法，初创公司如 CPLANE Networks 则利用交换节点的开放公共 A