容器化应用的服务可用性

我作为软件工程师的第一份工作是在阿灵顿高地（Arlington Heights, IL）的摩托罗拉公司。工作是关于蜂窝基站软件（cellular base station software ）开发，以前称作为跨无线协议状态管理（state management across different radio protocols）。对于电话软件，99.999%的服务可用性是必需具备的（例如每年只能有小于5.26分钟的故障宕机时间）。我在摩托罗拉和贝尔实验室的后续几年，学习了如何建立和运维高可用性系统。

在那个时代里（约为90年代中期），高可用性系统需要昂贵且复杂的硬件，并且每个组件都得有个随时可用的备份。现在事情则变得容易多了。可以使用各种常见的硬件主机来主从备份应用组件，建立高可用性的系统。此外，使用容器来部署和运维，我们还可以获得更快的系统恢复时间，如Kubernetes、Nirmata这样的智能缓冲、精致的容器管理工具能将系统恢复时间降低至几毫秒。

然而，一直保持不变的是设计合理的系统管理需求，这包括管理系统所有组件的状态更新。而且对于微服务应用来说，一个应用可能有多个服务组成，每一个服务可能有多个实例，实现可靠性和伸缩性的系统管理正变得越来越复杂，因为有很多不相关的组件需要来跟踪和管理！让我们来看一看如何使用Nirmata来解决这个复杂的挑战。

服务可用性

为了管理服务可用性，我们首先需要知道三件事：

• 哪个组件对服务来说至关重要

• 每个组件可能有哪些状态

• 如何定义和测量服务可用性

下图是Nirmata的部分领域实体（对象）图。如图所示，Nirmata收集和管理的信息既包含基础设施相关的对象（云供应商、主机、容器等），又包含软件应用对象（应用、服务等）。

建立一个优雅的状态模型需要及时更新每个对象的状态信息，同样重要的是需要对跨对象间的依赖和联系有深刻的理解。例如，由于主机重启导致某个服务不可用，那么这二者需要关联起来并进行上报。

这样的模型还能帮助我们区分严重问题与瞬间发生的故障。例如，某个容器的退出不会影响整个服务的可用性。实际上，服务编排引擎（orchestration engine）在多个服务实例上安排镜像滚动升级时，容器退出是正常的。

一旦我们知道了跟踪哪些实体，下一步就是定义和管理状态，及状态间的转换。在Nirmata，每个对象有两个主要状态和几个次要的过渡状态。主要状态有：

• 运维状态：这个状态代表对象当前是否可运维或者可以如何运维。例如“上线”、“下线”、“故障”组成了一个对象的可运维状态模型。

  
  

• 管理状态：这个状态是由用户或者管理员来管理的。例如，“关闭”、“暂停”是由用户触发的。

除了主要状态，每个对象可以有几个次要状态。这些状态是跟对象相关的，它们提供了更多的细节信息。例如，在Nirmata大多数管理的对象有“执行状态”，表示一个系统维护正在执行。

这里是一些在Nirmata中应用里服务有可操作状态：

• 正在运行：服务的所有实例健康并且正在运行

• 降级：服务的一些实例已经故障，或者正在执行某些操作

• 正在执行：服务的所有实例正在执行更改

• 故障：服务的所有实例已经产生故障

现在我们有了服务的状态模型，跟踪可用性就变得简单多了。在Nirmata，可用性是通过服务正在执行或降级时间占用总时间的比例来计算的。同样的方法也应用在应用级别的传播状态。未来版本，我们计划允许用户自己定义应用中每个服务如何被应用到整体的服务可用性计算中。

下面我们来看下Nirmata里的环境视图。每个环境可能有多个应用，每个应用都有自己的可用性，同时我们也可以看到该环境的整体可用性。

向下拉动，可以容易的看到特定应用的可用性。Nirmata还展示了应用的相关状态转换，并标识出应用的故障原因。

这里我们可以看到单个服务视图和它的状态变化：

总结

容器化微服务应用的可用性管理是复杂的，因为有很多项需要衡量和跟踪。而且，衡量系统可用性需要一个良好定义的状态模型。对象状态需要在跨物理设施和软件实体间可管理、可关联和可传播。

使用合适的系统管理平台，才有可能衡量、跟踪并报告服务、应用或者环境的可用性。运维人员通过聚焦于服务可用性，可轻易地实现“信噪分离”，只关注影响服务的问题。

作者： Jim Bugwadia

原文链接：
https://dzone.com/articles/service-availability-for-container-native-apps

翻译：姜俊厚

阅读推荐：

调查显示最常用的混合云是OpenStack+AWS

从Pike版本开始，OpenStack组件走上模块化易组合之路

投稿邮箱：[e-mail]