网站建设完成阶段性总结报告,永州市城乡建设规划局网站,北京网站优化指导,禹城网站建设公司云计算平台中允许客户依据应用的负载进行云计算资源的弹性动态伸缩#xff08;理想的情况是实现一个用多少付费多少的模型#xff0c;最大限度地降低用户的运营成本#xff09; 在进行讨论之前#xff0c;先对几个名词进行定义 1#xff09;客户#xff1a;使用云服务的人… 云计算平台中允许客户依据应用的负载进行云计算资源的弹性动态伸缩理想的情况是实现一个用多少付费多少的模型最大限度地降低用户的运营成本 在进行讨论之前先对几个名词进行定义 1客户使用云服务的人在云上部署他的应用 2用户 使用部署在云上的应用的人 Auto-scaling的基础 云计算的一个关键特点是弹性伸缩但它是一把双刃剑因为它允许应用依据负载动态地申请和释放资源但是确定一个合适的资源量并不容器那么需要一个系统自动地依据负载来调整资源量尽可能得减少人工的干预。 资源的伸缩主要有两种 1垂直伸缩简单的说就是伸缩的时候以虚拟机为单位直接增加或减少虚拟机的数量 2水平伸缩对虚拟机的内部的资源如CPU、存储等进行伸缩 但大多数操作系统在水平扩容时都需要重新启动虚拟机因此很多云服务商都只提供垂直伸缩。 那怎么样来判断一个一个auto-scaling系统是否合格呢 1在客户应用的部署者和终端用户之间的Service Level Agreement (SLA)比如说满足一定的响应时间 2在云服务提供商和客户之间的SLA比如说满足云平台的一定的资源利用率 Auto-scaling的实现主要面临几个问题 1Under-provisioning即应用没有获得足够的资源来应对用户的请求不能满足SLA需要增加更多的资源 2Over-provisioning即应用在满足SLA后还有过多的资源客户付出了不必要的成本 3Oscillation当伸缩的动作执行的过快时可能会出现资源波动的现象刚刚扩容又缩容。可以伸缩后添加一个懒惰时间此时不进行任何伸缩扩容来避免波动 Auto-scalin系统一般包含四个部分 1Monitoring监控系统主要是获得系统和应用的状态信息 硬件信息 CPU利用率存储利用率网络接口 操作系统进程缺页CPU调度 负载均衡 请求访问队伍的长度当前对话的进程数量拒绝请求的数量 2Analysis: 分析监控系统的信息估计未来的资源使用情况和需求 reactive使用从监控系统获得的最后的系统值进行判断。不做任何预测仅仅当检测到系统负载变化时才会做出响应。难以应对突发的负载 proactive着重通过预测未来的需求来完成对资源的分配 3Planning 制定一个合适的资源伸缩计划 4Execution执行 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。为了实现这个目的就要构建输入与输出之间的模型它决定了输入如何影响输出的值。 常见的控制器有以下几种 1Fixed gain controllers固定增益控制器这类控制器比较简单在确定参数后参数在控制器运行时间内不变 2Adaptive controllers自适应控制器能够依据条件的变化在线自动调整参数适用于缓慢变化的负载环境不适用与突变的环境 3Model 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 )来表示其中KND是可选的 AInter-arrival time distribution到达时间间隔分布 B Service time distribution. 服务时间分布 常见的A和B的值有MDG M表示Markovian马尔可夫链它指的是一个泊松分布的过程它的特征是一个参数单位λ 表示每个时间单位到达的请求因此到达时间或者服务时间将服从指数分布 D表示为一个固定的值 G对应于具有已知参数的一般分布 CNumber of servers.服务器数量 KSystem capacity or queue length系统能力或队伍长度即系统最多能服务的用户数量 N Calling population 要求服务的总体 D Service discipline or priority order服务纪律或优先次序 先来先服务…… 队列模型通常被用在一些固定的系统结构中因为任何系统结构或者参数需求的变化都需要重新构建模型。此外队列模型是一个分析工具它还需要另外的一个组件来完成auto-scale。 总的来说排队论在设计一个通用的auto-scaling系统时可能并不是一个最好的选择。 5 timeseries analysis 时间序列是在一个固定的时间间隔(如每分钟)采集系统的性能指标如平均CPU负载。它得到的结果X包含一组w时间序列的长度个观察值 时间序列方法可以基于最新的q(滑动窗口值qw)预测未来的时间序列的值。时间序列分析技术尝试识别时间序列所遵循的模式然后使用这种模式来推断未来的价值。 时间序列模式可以用四种特性来描述趋势trend季节性seasonality周期性cyclical随机性randomness。系统性能指标总体的趋势上升或者下降的变化会在一个时间序列上重复出现例如日、周、月或季节。趋势主要表明系统性能指标的总体变化季节性和周期性分别决定在一个特定的时间点上短期和长期的峰值。 参考文章A Review of Auto-scaling Techniques for Elastic Applications in Cloud Environments转载于:https://www.cnblogs.com/yuxiaoba/p/9274717.html
