中云内参（3）：关于云计算可用性的定性和定量研究(2)_机房360

摘要：云计算在被越来越多的个人和企业所采用, 但人们对于云计算服务在安全性, 可靠性和服务响应确定性方面的担忧也与日俱增. 虽然云服务提供商(Clouds Service Provider) 通常都会承诺SLA(Service Level Agreement)的可用性(Availability)范围等, 但许多云租户不理解可用性的内在复杂性, 因此在选择云平台时缺乏对风险进行评估的能力.

　　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天