虚拟机（Visual Machine）的云平台的自动伸缩扩容（auto-scaling）技术

云计算平台中允许客户依据应用的负载进行云计算资源的弹性动态伸缩（理想的情况是实现一个用多少付费多少的模型，最大限度地降低用户的运营成本）

在进行讨论之前，先对几个名词进行定义

1）客户：使用云服务的人，在云上部署他的应用

2）用户： 使用部署在云上的应用的人

Auto-scaling的基础

云计算的一个关键特点是弹性伸缩，但它是一把双刃剑，因为它允许应用依据负载动态地申请和释放资源，但是确定一个合适的资源量并不容器，那么需要一个系统自动地依据负载来调整资源量（尽可能得减少人工的干预）。

资源的伸缩主要有两种：

1）垂直伸缩：简单的说就是伸缩的时候以虚拟机为单位，直接增加或减少虚拟机的数量

2）水平伸缩：对虚拟机的内部的资源（如CPU、存储等）进行伸缩

但大多数操作系统在水平扩容时都需要重新启动虚拟机，因此很多云服务商都只提供垂直伸缩。

那怎么样来判断一个一个auto-scaling系统是否合格呢：

1）在客户（应用的部署者）和终端用户之间的Service Level Agreement (SLA)，比如说满足一定的响应时间

2）在云服务提供商和客户之间的SLA，比如说满足云平台的一定的资源利用率

Auto-scaling的实现主要面临几个问题：

1）Under-provisioning：即应用没有获得足够的资源来应对用户的请求，不能满足SLA，需要增加更多的资源

2）Over-provisioning：即应用在满足SLA后还有过多的资源，客户付出了不必要的成本

3）Oscillation：当伸缩的动作执行的过快时，可能会出现资源波动的现象（刚刚扩容又缩容）。可以伸缩后添加一个懒惰时间（此时不进行任何伸缩扩容）来避免波动

Auto-scalin系统一般包含四个部分：

1）Monitoring：监控系统主要是获得系统和应用的状态信息

硬件信息： CPU利用率，存储利用率，网络接口

操作系统进程：缺页，CPU调度

负载均衡： 请求访问队伍的长度，当前对话的进程数量，拒绝请求的数量

2）Analysis: 分析监控系统的信息估计未来的资源使用情况和需求

　　　　　　     reactive：使用从监控系统获得的最后的系统值进行判断。不做任何预测，仅仅当检测到系统负载变化时才会做出响应。难以应对突发的负载

　　　　 proactive：着重通过预测未来的需求来完成对资源的分配

3）Planning： 制定一个合适的资源伸缩计划

4）Execution：执行

 Auto-scaling技术

        1  static threshold-based rule

　　　　云服务提供商大多仅仅使用基于阈值的规则提供 reactive的自动伸缩 。这种方法是预先设定一个阈值，当系统状态到达这个阈值时，就会触发自动伸缩的功能。

　　　　这种auto-scaling方法因其比较简单，这对于客户来说很有吸引力。但是它也有缺点：第一是为应用设定一个阈值需要对应用负载的趋势有一个很深的认识，第二在面对突发的负载时，这种方法的时效性比较低，反应比较慢

　　　　基于阈值的规则一般会设定最少两个规则，一个用来扩容，一个用来缩容，例如：

　　　　例子中x是系统状态的值，thrU是设置的上阈值，thrL是设置的下阈值，durU的时间是在遇到这种情况是多少秒内会触发，S是每次扩容的值，inU是这伸缩执行后多少时间内不进行任何伸缩（用于防止波动）

　　　　举一个简单例子是，当平均的CPU资源利用率超过70%的时间持续超过5分钟时，扩充两个虚拟机，并且在接下来的10分钟内不做任何伸缩

        2  control theory

　　　　控制变量u（例如 虚拟机的数量）目标系统的输入，受控变量y（如CPU负载）是目标系统的输出。　　　　

　　　　控制器通过调整控制变量u来保持受控变量y接近期望的值或者预先设定 的yref。为了实现这个目的，就要构建输入与输出之间的模型，它决定了输入如何影响输出的值。

　　　　常见的控制器有以下几种：

　　　　　　1）Fixed gain controllers（固定增益控制器）：这类控制器比较简单，在确定参数后，参数在控制器运行时间内不变

　　　　　　2）Adaptive controllers（自适应控制器）：能够依据条件的变化在线自动调整参数，适用于缓慢变化的负载环境，不适用与突变的环境

3）Model predictive controllers （模型预测控制器）：基于模型和当前的输出预测系统未来的行为

控制论的效率取决于控制器的种类和目标系统的动态变化，构建一个可靠的映射输入和输出变量的模型并不容易

        3  reinforcement  learning

　　　　加强学习的方法无需任何先验的知识，就能够为每一个应用状态设计一个最优的伸缩策略。它着重学习机构（例如，auto-scaler）和它的环境（例如应用）之间的直接交互

　　　　　其中α是学习率(learning rate)，γ 是贴现因子（discount factor）

　　　　加强学习的方法主要有几个缺点：

　　　　　　1）初始的性能很差并且需要很长的训练时间

　　　　　　　　比较好的解决方法是在前期先用其他的代替方法来控制auto-scaling的系统，同时加强学习的模型也进行训练，待训练好时再使用加强学习 模型控制系统

2）需要很大的状态空间，在最简单的形式中，查找表用于为每一个可能的状态动作对存储一个单独的值，这些状态是成指数级增长的，所以当查找表很大时，每一次访问都可能需要很长的时间

　　　　　　　　用查找表来表示Q函数并不高效，可以使用其他非线性的函数（如 neural networks, CMACs (Cerebellar Model Articulation Controllers), regression trees, support vector machines）

　　　　　　3）最佳模型的适应性比较差，加强学习方法能够很好地解决相对缓和的变化，但是对于突发的负载变化表现并不好，因为它需要寻找新的最佳策略

        4  queuing theory

　　　　　　排队论可以用来估计系统的性能指标(例如队伍的长度、请求的平均等待时间），可以分为简单的队列模型和复杂的队列网络

　　　　　　排队论的基础机构如上图所示，请求到达系统后将入队，直到它们执行完才出队。

　　　　　　在一个标准的auto-scaling系统中，一个队伍可由A/B/C/K/N/D(如：例如： M/M/1/ ∞/ ∞/FIFO )来表示，其中K，N，D是可选的

　　　　　　　　A：Inter-arrival time distribution（到达时间间隔分布）

　　　　　　　　B： Service time distribution. （服务时间分布）

　　　　　　　　　　　　常见的A和B的值有：M，D，G

M：表示Markovian（马尔可夫链），它指的是一个泊松分布的过程，它的特征是一个参数单位λ （表示每个时间单位到达的请求），因此到达时间或者服务时间将服从指数分布

D：表示为一个固定的值

G：对应于具有已知参数的一般分布

　　　　　　　   C：Number of servers.（服务器数量）

　　　   　  K：System capacity or queue length（系统能力或队伍长度）：即系统最多能服务的用户数量

N： Calling population （要求服务的总体）　　

　　　　　　D： Service discipline or priority order（服务纪律或优先次序）： 先来先服务……

　　　　　   队列模型通常被用在一些固定的系统结构中，因为任何系统结构或者参数需求的变化都需要重新构建模型。此外队列模型是一个分析工具，它还需要另外的一个组件来完成auto-scale。

总的来说排队论在设计一个通用的auto-scaling系统时可能并不是一个最好的选择。

        5  timeseries analysis

　　　　时间序列是在一个固定的时间间隔(如每分钟)采集系统的性能指标（如平均CPU负载）。它得到的结果X包含一组w（时间序列的长度）个观察值

时间序列方法可以基于最新的q(滑动窗口值，q<=w)预测未来的时间序列的值。时间序列分析技术尝试识别时间序列所遵循的模式，然后使用这种模式来推断未来的价值。

时间序列模式可以用四种特性来描述：趋势（trend），季节性（seasonality），周期性（cyclical），随机性（randomness）。系统性能指标总体的趋势（上升或者下降）的变化会在一个时间序列上重复出现（例如，日、周、月或季节）。趋势主要表明系统性能指标的总体变化，季节性和周期性分别决定在一个特定的时间点上短期和长期的峰值。

　　　　

参考文章：A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments