Geekly articles weekly

OpenStack：关于“皇家”发布的全部真相

布尔加科夫（M. Bulgakov）的沃兰德（Woland）说：“毫无理由，一块砖永远不会落在任何人的头上。” 也许是这样，但是当他们在两年半前问我是否想了解OpenStack时，那是面纱非常好的砖（甚至不是砖，而是一开始的花岗岩板）。 在2016年，对我而言，这成为所谓的“不归路”，为开放世界概念的快速发展奠定了基础，并极大地影响了人们的心态，使我的未来生活成为假期。 “假期”，这永远伴随着我。



2016年至今


OpenStack一见钟情。 我部署用于测试的第一个版本是Kilo，很容易与“ sad”一词押韵。 已经存在了整整三个星期，希望他能被自由女神（Liberty）取代，他在一个诱人的包装下-发布说明-未能达到很高的期望。 Mitaka并没有带来太多新功能，因为它包含了许多更正和“补丁”，并且仍然（！）成功地在生产环境中使用。 实际上，牛顿是OpenStack历史的转折点，它提供了如此多的架构，逻辑和结果，因此配置更改永远阻碍了许多私有云从以前版本的升级路径。 但据分析师称 ，正是随着Ocata于2017年发布，OpenStack的“黄金时代”开始了，其中包括派克，皇后区，我衷心希望如此，处于起步阶段的Rocky将进入。


本文将重点关注基于Ubuntu 16.04 LTS发行版进行自动化部署的人员的观点（并继续这样做，因为没有完美的限制），这是针对OpenStack最新稳定发行版-Queens，以及一些创新和缺点的信息。 。

网络上没有关于Queens的资料（如果您从样本中排除了最近在温哥华举行的OpenStack峰会的官方文档和报告 ），那么云提供商和系统集成商的评论数量就可以用一只手指望。 毫不奇怪，其前身派克（Pike）的官方支持将再持续八个月，有数百名用户参与其中，并有详细记录的升级程序，看起来更适合实施。 我们的团队从一开始就一直密切关注皇后区的开发过程，其步伐远远超过了许多，并充满信心地将“新”产品投入生产。 那么兔子洞有多深？

（此后将广泛使用OpenStack术语；假定读者至少熟悉典型体系结构）

有用的功能


  1. 对我个人而言，新版本的一个不错的好处是nova-manage实用程序功能的扩展：现在，您可以从某些单元中删除主机（Cells v2）并将其转移到其他单元中！ Pike不得不编写单独的数据库查询，现在“开箱即用”即可使用。
  2. 为Keystone创建自定义角色（默认情况下为_member_）是从引导阶段“删除”的。 这样做的原因是对API v3的最终过渡，该版本具有其他形式的授权和身份验证机制，这也增加了基础结构的安全性（毕竟，用户角色还具有固定的ID ...）但是，这并不意味着根本不需要用户角色-早期或早期。您稍后必须创建它。
    预测：从此版本开始，不推荐使用Identity API v2； 他的支持很可能会在一年内完全停止（对Stein发布感到悲观）。
  3. Neutron l3-和dhcp-agent获得了自动故障转移的机会-网络和路由器从关闭的代理到活动代理的自动切换（重新分配）。 默认情况下，启用DVR HA功能（ [DEFAULT]/router_distributed和[DEFAULT]/l3_ha ）。 DVR / SNAT在单独的命名空间中分配。 创建路由器时，默认情况下会创建snat，并从内部子网中获取另一个IP地址：

    通过此捆绑包，您可以在SNAT服务发生故障的情况下，从当前快速切换到在另一个节点上运行的l3代理的备份路由器。
  4. Neutron vpn-agent的所有功能都转移给了l3-agent； 在他的配置中，您需要进行唯一的编辑：

     [agent]/extensions = vpnaas

    最后，在包含角色的情况下，vpn代理的存在不再干扰自动部署逻辑的构造（以前，vpn和l3代理是互斥的：如果放置一个包，则删除另一个包）。
  5. Glance-registry（用于与API v1中的数据库进行交互的代理）已被声明为过时的服务，现在您可以配置并且仅需要glance-api服务。 毫不奇怪，但是稍后会进行讨论。
  6. 妈妈咪呀！ 加热仪表板在Horizo​​n的单独包装中（插入面板）提供。 该插件进行了许多更改，但是最出乎意料的功能是...在生成模板的过程中拖放对象。 一次查看更容易：


  7. 在Cinder中增加了对卷多连接的支持-能够将单个磁盘连接到多个虚拟机。 到目前为止，仅针对该服务支持的有限数量的驱动程序实现了此功能：LVM，NetApp / SolidFire，Dell EMC ScaleIO和Oracle ZFSSA-实际上，这对于整个项目而言是非常重要的一步（该机制的实施花费了两年多的时间 ）。
    预测：对于Ceph RBD，尚未宣布对Cinder体积多附件的支持； 最有可能的是，预计不会早于一年（乐观地-在Stein版本中）。

烦人的错误


（在Ubuntu 16.04.4 LTS发行版（Xenial Xerus）上部署OpenStack Queens时发现了以下错误；有可能它们不会出现在其他Linux发行版上）

  1. 在Linux社区中，有一个“维护者”之类的东西-维护/维护/领导特定软件组件（在特定情况下为二进制包）的专家。 因此，Ubuntu维护者（Pike发行版中存在一个错误）再次为常规的时间序列数据库服务-Gnocchi提供了软件包。 通过apt将它们安装在Python 2.7环境中会“破坏”在libapache2-mod-wsgi下运行的一些相关服务：Keystone，Cinder，Nova Placement，Horizo​​n。 可悲的情况是，当您想使用一种将数据包传递到系统的方法时。 但是，对于Gnocchi，他们至少尝试编译软件包，对于Octavia，仅pip和git仍然存在。
  2. 我不假装说，但也许是相同的维护人员在创建nova-compute软件包方面有所帮助。 至少，这可以解释为什么将它们安装在系统上（内核组件116、119和124；软件包版本从17.0.1到17.0.4）时，安装程​​序“退出”并出现错误：

     Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet.

    事情就是这样：在安装过程中，运行了一个脚本，该脚本应该创建nova系统组和nova系统用户。 脚本因错误而失败，安装失败，并且变通办法被添加到自动化中：在安装软件包之前，请执行上述操作。 顺便说一句，此错误仍未关闭。
    UPD：在撰写本文的过程中，该错误最终得到确认，并设置了平均优先级。 在解决问题时（Nova程序包彼此之间的周期性依赖性），维护人员提出了另一种解决方法：首先安装nova-common程序包，然后安装nova-compute。 在不久的将来，我们可以期待软件包17.0.5的版本，而不会出现此缺点。
  3. 通过测试Neutron FWaaS服务的运行情况，结果发现，从分布式路由器中删除防火墙后，绝对不会发生任何事情。 防火墙从“联机”状态更改为永恒的“待删除”状态，您可以通过使用对数据库的查询或删除整个路由器来解决此问题（Pike发行版中存在此错误）。 目前的主要问题是该修复程序 （确实可以解决！）是几个月前提出的，但仍未发布到最新的稳定版本。
  4. 已经在对基础架构进行负载测试的阶段，发现“ neutron-openvswitch-agent EATING CPU AAAAAAA”-在空闲模式下，openvswitch-agent以100％的速率加载了一个处理器核心：

     $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s

    服务的开发人员尽快找到了解决问题的方法； 该修补程序在Neutron 12.0.1-0ubuntu1.1软件包版本中提供。

皇家法卡普


扰流板
我个人建立的The Most Epicfail Service奖项提名了Glance ，该奖项是我个人所能提名的。该奖项由我亲自设立，并在众多竞争对手中脱颖而出-记录不清，难以调试的服务-Selectate，Octavia和Watcher。 最终汇报不会早于Rocky的发布，但是，喜欢的人的位置将很难动摇。

在OpenStack Queens中，开发人员引入了一种下载图像的新方法-网络下载，该方法允许最终用户通过引用“上传”图像。 曾几何时，当Image API v1尚未被弃用并且未被API v2取代时，就存在此功能。 看来可能出了什么问题？


在glance-api服务配置中，默认情况下启用了两种图像加载方法（直接和通过引用）（ [DEFAULT]/enabled_import_methods ）。 为了实现测试该选件的简单目标，我关闭了其中一种方法，使服务超载，然后着急！

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple

修补了补丁之后，我再次使服务超载：

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'.

说真的，还是什么？ 配置中的选项获取了以下不足的形式：

 [DEFAULT]/enabled_import_methods = [glance-direct]

当然，我小心翼翼地打开了一个错误。 解决问题时，开发人员甚至发布了有关此已知问题的公告 ，并将其发布给项目的master分支。 发现该错误两个月后，该修补程序 “保留”了以后的版本； 幸运的皇后区所有者将不得不等待Glance版本16.0.2软件包。
一切顺利，一切顺利。

“不要丢下头，摇摆肌肉”


在部署自动化工作期间（还涉及配置和功能测试步骤），Queens被证明是强大的，没有过多的新功能，而且没有从任何地方伸出来的“拐杖”，为继任者树立了高标准。

但是，尽管皇后区是OpenStack的第十七个（！）版本，但多年来一直保持着普遍的趋势：“ 无法预见的直觉是无法预见的 ”。 我认为，这是Atlantida Project项目中的一句话，以最好的方式描述了与产品互动所产生的全部感觉。 一方面，具有基本设置的常规服务（Keystone，Glance，Swift，Cinder，Nova，Neutron，Horizo​​n）的部署经过长期调试，即使对于新手工程师也不会造成问题。 另一方面，在引入相对较年轻的服务时，上述“假期”开始了：在微薄的文档中根据需要对其进行整理，准备花几天的时间查看代码并坐在流行的Bug跟踪器上。

但是，所有这些痛苦仅仅是斯德哥尔摩综合症的副作用。 但实际上，开放式练习比任何逻辑游戏都更快地动摇大脑，以指数方式发展有用的技能，不断保持良好状态，当然也不会让您感到无聊。 乍一看，OpenStack绝对不是我的爱，而是白热化和昏厥，但现在绝对值得得到一点爱。 而且，如果您准备通过实现自己的需求（并使开放源代码世界变得更好一点）驱使控制台的黑屏几乎触碰一下，也许这就是您的方式。

Source: https://habr.com/ru/post/zh-CN415199/

More articles:


All Articles