[推论1 ] 云服务Availability的大小与(MTTR/MTBF)的比率成反比
从 AvailabilityT = MTBFT/(MTBFT + MTTRT), 我们很容易得到,
AvailabilityT = 1/(1 + MTTRT/MTBFT )
定义Mean Time Failure Ratio(MTFR)代表(MTTR/MTBF)的比率.
AvailabilityT= 1/(1+MTFRT)
显然, 错误失败的比率越大, 云服务的可用性就越小. 其关系曲线可以简单表示如下:
图4 MTFR与Availability的关系曲线
[推论2] 如果云服务的上线正常运行时间和下线时间是一个线性关系, 比率为a, 那么服务的可用性是一个常数
, 不随着采样周期T变化. 因此, SLA可以不考虑星期, 月或者年的影响.
假设, 其中a, b是常量, a为云服务上线正常运行时间和下线时间的比率.
由公式1可知:
由此可见, 在这种情况下, 云服务的可用性是一个常量, 和采样的周期无关.
图5 MTBF和MTTR是线性关系时的Availability
[推论3] 当一个云服务运行比较稳定的时候, 云服务故障恢复的时间越短, 云服务可用性越高.
当一个上线的云服务逐渐成熟, 能稳定的运行一个固定的时间, 才出现异常. 为简单起见, 假设MTBFT 是一个常量, 意味着:
可以看出, 当每次正常服务的时间是一个常量的时候, 故障发生时修复的速度越快, 时间越少, AvailabilityT 的值就越大. 因此云服务可用性就越高.
图6 MTTR与Availability的关系曲线
[案例讨论 ]
假设一个云服务提供商希望提供一可用性不低于某个范围值, 例如 99.9%或者99.99%等, 从而获得商业上的竞争优势.
*如果MTTR是可控的, 例如是可修护的(Repairable)部件, 具有一个修复时间上限常量. 例如,云计算数据中心内的软件模块, 操作系统或者数据库的补丁, 安全漏洞等, 上述的AvailabilityT = 1/(1 + MTTRT/MTBFT ) 可以简化为AvailabilityT = 1/(1 + /MTBFT ). 那么系统的可可用性就完全依赖于MTBF, 或者说, 在时间T内服务上线的平均时间. 此时作为云计算服务提供商可以通过拉大T的取样范围(例如月或者年)和/或提高云服务的稳定性, 从而提供最大的MTBF, 以符合所期望的系统Availability参数.
* 如果MTTR是不可控的, 例如是必须更换的(Replaced)部件, 如硬盘, 服务器硬件或者电源失效等, 这些意味着MTTR的时间分布不具备一个上限常量. 这种情况下云服务提供商应该通过加大容灾处理, 1+1硬件容错等手段来确保MTTR的收敛, 并在采样时间T方面采取保守策略, 例如(1) 对什么是不可用(UnAvailability)进行更严格的自定义, (2) 对可用性的等级采纳月, 季度或者年为单位的承诺.
[案例分析]
[例1] 一个云业务持续运行的MTBF是10,000小时, 但需要平均10个小时才能恢复正常运行,那么系统的可用性是多少?
Availability = 10,000/(10,000+10)=99.9%.
[例2] 如果要确保一个新的云业务的可用性是99.99%, 而且从内部测试可知平均运行时间大概可以保证10,000个小时才会发生错误, 那么IT运维部门必须保证在平均多长时间修复任何崩溃？
从AvailabilityT = 1/(1 + MTTRT/MTBFT ), 可以推导出
MTTRT = MTBFT * (1 -AvailabilityT) /AvailabilityT
因此, MTTRT= 10000*(1- 0.9999)/0.9999 = 1小时.
IT部门必须在60分钟之内修复系统恢复云服务的上线, 否则就无法达到给租户承诺的SLA.
[例3] 假设一个云业务必须保证99.999%的可用性, 如果从内部测试评估认为每次业务出错恢复的时间大概为12个小时左右. 那么对业务质量控制应该是什么? 必须保证多长时间业务正常运行?
从AvailabilityT = 1/(1 + MTTRT/MTBFT ), 可以推导出
MTBFT=(MTTRT * AvailabilityT )/(1 - AvailabilityT)
因此, MTBFT= (12* 0.99999)/(1 - 0.99999)
= 1,199,988小时 = 49,999.5天
=7,143星期=1786个月
=149年!!!!!!
这个业务必须能保证连续149年的无故障运行, 才能达到设计目标! 换言之, 5个9的设计目标是不现实的.
(To Be Continued)
[第一部分 参考文献]
