如何做容量规划

为了迎接中秋节及国庆节的到来,需要对线上服务器进行扩容,发现了一些问题,就顺手整理下如何做容量规划

容量规划

容量定义:资源所能支撑特定服务的能力
容量规划:资源管理
适用范围:同构集群

性能 && 容量

性能:决定一辆车能装什么东西
容量:决定需要多少量车

容量规划大致需要经过以下几个步骤
1.评测模型
2.应用依赖
3.趋势预测
4.容量管理

一 评测模型

1.设定服务指标(偏向性能方面)

在用户期望、业务需求、SLA三者之间平衡
具体的指标:计算速度、网页打开速度、响应时间、命中率、、SLA

2.设定容量指标(偏向物理层面)

扩容调整的方式:水平调整、垂直调整
垂直扩展的收益比较低,现在基本已经不考虑采用这种方式,主要还是水平调整。
水平调整基于AKF扩展立方又分为:

  • 1.横向复制:通过克隆进行扩展
  • 2.拆分不同的东西:用名词或是动词标示数据和服务,从而进行划分
  • 3.拆分相近的东西:通常拆分的是数据集,把数据划分到专用独立的数据片或是泳道

业务指标:UV,交易量,调用量,搜索量
水平容量指标:TPS,QPS,SESSION
垂直容量指标:CPU,内存,IO,网络,连接数

3.压测和监控

引流(复制请求):
1.测试效果受到集群实际流量限制
2.压测时间需要选择流量较大时候
3.不产生脏数据,适用范围灵活

模拟流量(模拟请求)
1.测试效果不受集群实际流量控制
2.压测时间灵活
3.可能产生脏数据,对get请求较为合适

4.容量计算

集群容量= 容量指标峰值/容量指标最大安全值

实际案例:
服务指标 : 交易关键URL响应时间 <=300ms
水平容量指标:TPS
系统健康约定如下
CPU : <=80%
IOPS : <=200
网络带宽 : 800Mbps
内存使用 : <=4G

例如线上集群单台服务指标RT值超过300ms,TPS=100
一个集群4台机器的话,那么集群的TPS就是 4*100 = 400
集群的最大TPS峰值是160。
集群容量 = (160/400)*100% = 40%

二 应用依赖

随着网站架构的变化,现在很难有单一部署的应用,大部分网站架构都是基于SOA的水平扩展。
那么在其中一个应用流量大涨的情况下,需要评估周边相关应用是否可以承载你扩容后的请求。

依赖分为两类
静态依赖:

  • 代码层 — 应用程序要
  • 配置层 — 运营配置项目

动态依赖:

  • 应用层 — 应用日志分析
  • 架构层 — 服务治理框架
  • 系统层 — 网络分析

三 趋势预测

根据以往的数据,在不同服务器阶段,能够承载的服务指标,大致预估未来增长的预期。

主要根据D-I-D原则
设计(Design)          — 按照现有容量的20倍进行设计。
实现(Implement) — 按照现有容量的3倍进行实现。
部署(Deploy)         — 按照现有容量的1.5倍进行部署

四 容量管理

主要体现在系统的监控上,系统架构比较重要的部分就是系统的监控。
上限水位  标准    下限水位
单机房 : 80%       70%      50%
双机房 :    55%       40%       30%
三机房 : 75%      60%       50%

这里还涉及到一个数据的分配,假设三机房。A机房将自己50%的数据备份到B机房,另外50%数据备份到C机房。保证在一个机房失败的情况下,可路由到其他机房!

一个好的容量管理平台

表现层:UI,API
应用层:报表管理、容量管理、趋势预测、压测管理
服务层:计算分析中心
组件层:数据采集中心、配置中心
数据层:集群依赖分析系统、监控系统

需要考虑的流量问题

  • 我提供的某个接口或者资源我只想被A应用访问
  • 我提供的某个接口或者资源我不想被B应用访问
  • 防止我的某个接口或者某种资源被过度访问
  • 防止我对某个接口或者某种资源的过度访问
  • 系统负载太高可以降级掉不重要的应用对我的调用
  • 依赖的非关键调用长时间没有响应可以对其进行降级

以上的所有问题都归结于:授权、限流、降低

服务的授权 :黑白名单
服务的限流 :SOA服务框架或是服务提供方
服务降级 :服务的调用端,或是在服务提供的客户端,返回一个空对象模式

以上三者可以都放在一个统一的客户端进行处理!

—————————————————————————————————————————————

案例:

一 新项目上线服务器的申请:

服务指标:
max time = 200ms
qps = 20000

计算:
单机能力 = 300qps
单机房部署的标准水位是 = 70%

300 * 70% * 服务器数量 = 20000

服务器数量 = 95.23809523809524

按照DID原则 : 服务器数量 = 142.85714285714286 即需要部署143台服务器!

二 若是已经上线项目的服务器调整,目前线上实际的QPS是200,单机房部署

单机能力 = 300qps
单机负荷 = 200qps ,线上目前的最大请求压力
集群能力 = 143 * 300 = 42900
集群负荷 = 200 * 143 = 28600

28600 * (28600 / 42900) * 143 = ( 42900 * 70% * 理论服务器数量)

理论服务器数量 = 90 台。

那么可以减去 143 -90 = 53台服务器。

计算的公式是: 集群负荷 * (集群实际水位) * 实际服务器数目 = ( 集群能力 * 标准水位 * 理论服务器数量)

—————————————————————————————————————————————

tips:

容量规划的一些名词:

qps的计算 : ( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
例如: 每天300w PV 的在单台机器上,这台机器需要多少QPS = ( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)

单机能力 = 单台服务器压测的阀值 qps(通过线下压测)
单机负荷 = 上线后单台机器最大qps(或是通过线下压测)
集群能力 = 单机能力 * 机器数(机器环境一致)
集群负荷 = 上线后集群最大QPS(单机负荷 * 服务器数量)

水位标准
单机房 : 70%
双机房 : 40%
三机房 : 60%

单个机房容量计算
单机水位 = (单机负荷/单机能力) * 100%
集群水位 = (集群负荷/集群能力) * 100%
理论机器数 = (实际机器数 * 集群负荷 * 集群水位) /(集群能力 * 水位标准)
机器增减 = 理论机器数 – 实际机器数 or 实际机器数 – 理论机器数

以上谈的都是简单的基于QPS的服务指标,实际线上规划时候还需要考虑:响应时间等其他因素!
参考资料:

1.http://wenku.it168.com/d_001180778.shtml
2.http://wenku.it168.com/d_000626871.shtml
3.http://product.china-pub.com/199567

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注