［微课堂］OpenStack升级失败的“11宗罪”及其解决方案

［微课堂］OpenStack升级失败的“11宗罪”及其解决方案

2016 02 23 作者trystack

升级的注意事项，相信不少的运营人员都已烂熟于心。一次成功的OpenStack升级，也正需要周全的考虑以及细心的准备，以下可能有你踩过或也可能有你未注意到的坑，不妨一读，或许能帮助你实现OpenStack的完美升级。

升级一个OpenStack云已经成为了一项富有挑战性的任务，它需要选择正确的方式，谨慎的计划和精确的执行，以实现最少的停机时间。由于其复杂性，云运营人员在升级前，往往选择跳过一到多个版本。

在此课堂中，我们讨论了不同情况下的OpenStack升级，识别升级OpenStack的主要“陷阱”，并提供了避免这些陷阱的解决方案和最佳实践。

更新Vs升级


首先，我们应该定义下OpenStack的“更新”和“升级”之间的明确区别。在此课堂中，更新意味着对OpenStack组件及基础操作系统的bug修复和安全隐患修复的应用。通常，这些修复被认为是能够安全地进行就地更新，因为它并没有带来新的功能，也不会引起回滚。

与此同时，升级意味着升级到一个新的OpenStack稳定版本。一个OpenStack云由相互协作的若干分发式软件组件构成，以交付满足需求的云服务。初步来看，这些组件，包括操作系统依赖项，必须同时进行升级，这将使得升级任务变得更加复杂。好消息是OpenStack社区旨在保持组件APIs的兼容性，所以旧的API版本往往也会被保留和支持一段时间。然而，旧API总会被标记为不推荐的并会在之后的版本中移除。

计划一次OpenStack升级


这里有几个重要步骤，我们推荐在计划任何OpenStack升级时采取：

  1. 通篇详读OpenStack版本注释，以识别出潜在的版本间的不兼容性。
  2. 选择合适的方法升级OpenStack（详见下文）。
  3. 准备一个升级失败的回滚计划。
  4. 准备一个数据备份计划，至少，带有配置文件和数据库的备份。
  5. 依照特定服务的SLAs，定一个可接受的云停机时间，如果可能存在数据丢失，提醒你的用户，服务的中断时间。
  6. 使用与生产环境相同的测试环境，测试升级方法。

OpenStack的升级方法


  • 平行云：部署一个独立的OpenStack云并从升级前的云迁移所有资源到升级后的云上。这是最简单粗暴的方式。同时，它也有一个最简单的回滚程序。然而，它需要大量的硬件资源并导致很长的停机时间。
  • 滚动升级：以下2种方法会依次升级每个服务器上的每个组件，最终获得一个已升级的OpenStack云：
  • 就地升级：这个方法需要在升级时关闭相应服务，引起一定的停机时间，然而少于平行云的方法。
  • 并列式升级：从OpenStack Icehouse起，控制器已从计算节点上分离，所以你可以独立升级它们。通过这个方法，你可以部署一个已升级的控制器，并从旧控制器上转移所有的数据到新控制器上,再用新控制器无缝替代旧控制器。旧控制器原封不动，所以回滚也很容易完成。为了实现零停机时间，在HA模式中，你需要超过一个控制器。

升级中的陷阱和解决方案


1 人工升级很可能导致失败


在出现大量必须完成的人工的反复性任务时，升级常常会失败。你的云由包含了众多服务的众多节点构成。在每个节点上的服务和其他服务协作，指望复杂的人工升级并不是合理的选项。

解决方案:使用自动化升级。有非常多的配置管理工具，你可以使用工具Ansible,Chef或Puppet。

2 生产环境的升级可能失败


根本上，OpenStack云包含了自定义设置，且标准的升级程序通常并没有在配置文档中接受这些设置。你应该考虑到一次云升级可能失败，所以你需要在与生产环境一致的测试云上验证这次升级。测试云可以小于生产环境，但是它应该有相同的架构和配置。

非常重要的一点是，在你的安排中，采取了正确的自动化实施。（旧版本）部署和升级程序都应该被自动化，且都应处于配置管理的控制下。你应该能够将每个自定义设置恢复到原始的请求上。在升级生产级云前，升级程序和相应的自动化应通过以下标准方案进行正确地验证：
使用与部署生产级云相同的自动化脚本部署一个测试云。
对测试云应用升级脚本。
如果升级失败，对升级脚本进行必要的修复，并回到1.重新开始。
如果升级顺利完成，检验测试云。
如果验证失败了，对升级脚本进行必要的修复，并回到1.重新开始。
你可以使用OpenStack Rally1进行自动化验证。Rally检验场景可以包含标准场景或针对测试云的自定义场景。
1 https://wiki.openstack.org/wiki/Rally

3 云的性能可能降低


每个OpenStack版本带来了新的功能，也带来了新的bugs，但是更重要的是，所带来的新硬件配置需求。一个新OpenStack版本可能需要额外的或是更快的CPU，更多内存和硬盘空间。这正是数个OpenStack版本的实际情况，包括Liberty。社区在OpenStack优化中所付出的努力可能会降低这些要求，但是，你应该考虑到你的云性能可能会因为一次升级而降低。

为了积极主动地识别和解决性能问题，你需要执行标准检查程序并分析你的云：升级前及升级后。你应该能够识别出任何性能的降低，并为处在高负荷下的OpenStack服务添加额外的资源。你可以使用OpenStack Rally来自动地完成云标准检查和分析。

4 服务不正常关机可能导致云的非一致性状态


服务应完成它从消息队列中所接收到的所有请求，并提示消息队列停止发送新的请求到服务上。你应该从容地关闭OpenStack服务，并给它们足够多的时间来完成所有生效的请求并向消息队列报告它们不再有效。一次关闭一个服务，升级，启动，然后对下一个服务做同样的事情。

5 采用错误的顺序升级服务可能破坏云


你可能因在升级时的错误顺序，轻易地破坏云。升级推荐按以下的顺序进行：

  1. 升级OpenStack身份服务（KeyStone）
  2. 升级OpenStack镜像服务（Glance）
  3. 升级OoenStack计算服务（Nova）
  4. 升级OpenStack网络服务（Neutron）
  5. 升级OpenStack块存储服务（Cinder）
  6. 升级OpenStack dashboard(Horzion）
  7. 升级OpenStack 编排（Heat）

6 升级可能因陈旧或缺失的系统依赖项而失败


一个新OpenStack版本带来了新的系统依赖项，并要求升级当前系统依赖项的版本。如果一些系统依赖项没有被安装或是升级，已升级的OpenStack服务将因运行时间错误而不能开启或将被终止。

当升级OpenStack服务的时候，确保所有的依赖项已经被正确地升级了。通常这意味着所有的OpenStack组件是用正确定义和测试了依赖项的安装包（dep或rpm)所安装的。即使如此，由于特定的配置，升级安装包仍可能破坏部分服务。如果安装包管理器（yum或apt-get)要求你升级配置文件，推荐你选择拒绝。改为人工审查、更改配置文件和重启服务。

7 数据库降级已不被支持


几乎所有的OpenStack服务都支持数据库迁移。这意味着每个服务将会在（升级）开始时尝试升级其数据库。通常，自动化升级会由OpenStack稳定版本完整测试过，并可以安全的使用（如果需要人工升级，可以禁用自动升级）。与此同时，从Kilo版本开始，数据库降级已经不被支持。也就是说，唯一可靠的数据库回滚的方法是从备份中恢复数据库。

8 配置文件将不会被自动升级


每个OpenStack版本都会引起配置文件的改变。一些选项可能会被移除，重命名或是被移动到其他地方。新的选项会被添加默认值，这都可能会破坏你的云。通篇详读版本注释，以识别这些变更，并合理应用到你的配置文件中。举例：

  • 在Juno中，’identity_uri'选项应被用在'[keystone_authtoken]’部分而不再是所有服务的’auth_host’,’auth_post’,及’auth_protocol’。
  • 在Kilo中，使用libvirt1.2.2在线快照已在默认情况下被禁用。部署人员可以设置nova.conf中的’workarounds.disable_libvirt_livespanshot=True’以激活对在线快照的支持。
  • 在Liberty中，在nova.conf中设置’force_config_drive=always’已不再有效，改为使用True/False布尔值。

9 升级可能因新的，过时的或被移除的API而失败


如果你有自定义脚本或是其他软件使用OpenStack API，那么请提前做好升级失败的应对，因为一个新OpenStack版本会带来的新API版本并会将旧版（API）标记为过期的。

在最糟糕的场景中，API可能会从版本中移除。通篇详读版本注释，以识别这些变更，并合理应用到你的云中。举例：

  • 在Kilo中，对EC2 API的支持已经被废弃和移除。
  • 在Liberty中，负载均衡即服务－LBaaS V1 API已被标记为过期，并计划下一个版本中移除。进而使用LBaaS V2 API。

10 升级可能因过期或被移除的功能、插件和驱动而失败


如果你正在使用某厂商特定的插件，那么那么请提前做好升级失败的应对，因为在新OpenStack版中，这些功能或插件可能已过期甚至被移除。通篇详读版本注释，以识别这些变更，并合理应用到你的云中。举例：

  • 在Kilo中，KeyStone的XML支持已被移除。
  • 在Kilo和Liberty中，许多整体式厂商特定插件已从Neutron中移除。

11 升级可能因架构变更而失败


在一些案例中，你的云可能会依赖于一个旧版OpenStack的特定框架性功能，而它在新版本被更改或是废除。通篇详读版本注释，以识别这些变更，并合理应用到你的云中。举例：

  • 使用Python3代替Python2.6
  • 使用pymsql数据库驱动代替Python-MySQL
  • 使用统一的’openstack client’代替’keystone’,’glace’,等。
  • 在Liberty中，Ceilometer警报器因Aodh被废除
  • 在Kilo和Liberty中，Keystone项目废除了eventlet已更好地发挥带有WSGI extensions的独立web服务。

OpenStack升级的未来发展


为了更好地完成升级OpenStack这项有挑战性的任务，OpenStack社区已经在新版本采取了Big Tent模式。在Big Tent模式中，运营人员将能选择首选的组件和组件版本，然后渐进性地加入或升级模块，实现少量或零停机时间。

以上内容译自openstack superuser,由Stratoscale’s Blog首发。
转载请注明出处trystack公众号。

热门文章