zoukankan      html  css  js  c++  java
  • 新型I/O架构引领存储之变(三)

    新型I/O架构引领存储之变(三)

    作者:廖恒

            超大规模数据中心TCO(总拥有成本)优化是还有一个重要驱动因素。

    “横向扩展”的概念基本上是在一个集群中採用一系列统一的硬件元件,将应用负载分解成具有同样处理功能的子任务,然后在基础的硬件元件上运行这些功能。通过复制统一的硬件元素。就可以为持续添加的应用负载如系统吞吐量、相关数据组大小等等差点儿全部与基础设施资源扩展相关的方方面面提供支持。横向扩展的架构得到了成功的广泛运用,攻克了万维网中大规模应用的很多问题。

            横向扩展的数据中心基础设施中最主要的硬件构件是server节点。为了提升系统效率,数据中心架构师通常相应用负载进行分析。找到适合该负荷需求的最佳server资源配置。这样的方法被称之为“砖块”模式,当中,砖块指的是具备一定资源设置的标准server配置。

    资源设置中则包含CPU的数量及种类、主存储器的大小、I/O控制器的种类、SSD/HDD的数目及种类和网络接口品种等等。

            因为一个数据中心内应用负载的多样性导致了资源设置迥然不同。通常须要多种“砖块”来与应用种类相匹配。数据中心的架构师竭力将砖块种类的数目控制在最小,力图降低设计、生产、部署与维护各种砖块的难度。下表中显示了Facebook所发布的用以匹配不同负荷的砖块种类。

    3  Facebookserver种类

    砖块模式的问题所在

            砖块模式已成为全球各大站点硬件架构的基石。事实证明,此模式在性能及容量扩展方面极为有效地满足全球范围内网络业务的需求。

    大数据中心的运营商也运用其庞大的购买力将“砖块”式server的价格降至最低。在非常大程度上,以上描写叙述的砖块模式在理论上的优势已经得到了充分实现。

            然而,进一步的分析显示。最低的server购买成本并不会直接转化为最低的TCO(整体拥有成本)。原因在于砖块模式的一个缺陷。砖块模式是基于这样一个如果,即应用的资源需求配置是静态的。故此能够部署对应的硬件砖块来匹配应用的资源需求配置。

             下图是砖块理论的一个直观图。图中运用一个多维空间来表示正交的资源种类,如CPU处理能力、主存储RAM容量、磁盘容量、磁盘IOPS、磁盘吞吐量及网络吞吐量等等。图中展示了一个简化的3D视图来诠释这一概念。在这个3D空间里。虚线盒代表了物理server的砖块资源设置,而实线盒代表了应用负载的资源需求。

    显而易见。为了让某项应用能在server砖块上执行,其资源需求就必须在各个维度都能纳入server的资源设置之中。

    换句话说。图中的实线盒必需要能放进虚线盒其中(作为一个子盒。如图所看到的)。基于这个理论,当砖块盒子与应用盒子能恰好匹配时,硬件基础设施提供的全部资源都得到了充分利用,因而不存在资源浪费。在此条件下,就实现了最低TCO。换句话说,当server的盒子是应用盒子的一个超集时。server盒子中多出来的额外空间就直接意味着浪费的资源。或者说是TCO浪费。

    因此。为了实现TCO最小化的终极目标,数据中心的架构师应该竭力缩小server盒子与应用盒子之间的差距。方法是将server的配置规定为恰好能与应用的资源需求设置相匹配。

     

    砖块理论

           当我们採用微粒化的时间分辨率(測量时间为一秒)来观察任一实际应用时,非常easy发现,砖块理论的缺陷就在于其关于资源设置为静态的如果。首先。如图5所看到的,资源需求在微小的时标(1秒測量时间)上动态浮动。相同。在同一个横向扩展集群中。跨越不同核心及不同server。资源需求也在动态变化着。即便在相对空暇的时间段内,也存在若干CPU热点,即在一个大集群中存在少量CPU可能会超载,造成某些用户应用性能下降。在微观层面,资源的利用率从CPUCPU,上一秒到下一秒都发生着随机的变化。

    该资源图突显了为云调配层提供任务或虚拟机搬移的能力,以求均衡地分配处理负荷(将任务从热点CPU移至空暇CPU)。眼下,server砖块的物理边缘导致的资源筒仓阻碍了任务/虚拟机的搬移。举例来讲。如果某个虚拟机的数据集存放在某个server砖块的本地SSD上,当这台server过忙时,无法将此任务转移至还有一台空暇server砖块上。由于存放于本地SSD上的数据集仅仅能由这个已然超载的server砖块上的热点CPU来訪问。

    在微细时标上的资源变化(以一秒測量期为例)能够看作是系统实现中固有的微观层面的现象(由于上述的资源筒仓问题),这与热动力学中观察到的随机粒子运用差强仿佛。

    解决该问题的办法在于改善系统设计。比方引进支持微细颗粒的资源搬移与动态捆绑的云硬件基础设施,以及更加高效的云资源调配层来控制负载分配和不同资源的映射。

    来源: http://dtrace.org/blogs/brendan/2011/12/18/visualizing-device-utilization/

    备注:此图展示了具有5000台虚拟CPU的实际在线执行的云计算环境(超过600台物理CPU. X:时间(超过60秒), Y: CPU ID, Z: CPU利用率 .

    5随时间变化的不同CPU上的资源利用率(60秒)

            进一步来看,假设採用较宽粒度的时间分辨率(比方,一整天,或者一整年)来观察数据中心的负载变化,能够观察到宏观层次的变化,通常与在相同一时候间段内变动不居的社会经济条件相关

    6是全球最大的购物站点淘宝统计的交易数据。描绘了寻常一天内女性购买穿着物件的模式。合乎情理之中。交易负载随着通常女性的日常生活模式而变化着。从夜间一点到凌晨七点,一般人卧床歇息的这段时间内交易极少。

    交易量在早餐时间后開始攀升,到10am达到峰值,接着整个白天保持稳定。到晚餐时小幅下降。然而,到了晚间。交易量在9PM11pm之间达到第二个峰值。由此图能够推论出淘宝的数据中心负载从高峰时段到空暇时段会有100倍的差异。峰值与均值比(及峰值与谷值比)的值巨大。意味着巨大的资源浪费。

    因为硬件基础设施必需要分配、部署来满足高峰时段的需求,这也意味着TCO的浪费。

    来源: 2012 淘宝网女性衣物购买模式分析报告

    http://www.199it.com/archives/71366.html

    图6 交易量(负载)随时间的变化(1天)

             如若观察数据中心负载一年内的变化,因为受到季节性因素对人类行为上的驱动,负载变化更为剧烈,因此会发现更为巨大的峰值与均值比。购物站点的交易量与节假日促销季(如圣诞节)直接关联并随之暴涨。

    去年,淘宝发明了众所周知的11-11光棍节(1111日)。挑起了淘宝商户之间的剧烈竞争,及其与其它B2C电商(京东、亚马迅)之间的大战。马云高明的营销手法即刻带来了20131111日线上消费350.19亿的历史最高交易记录。

    1111日的交易量是前一天的231%。毋庸讳言。此次活动为阿里巴巴集团带来了巨额利润。可是,也为站点的硬件及软件基础设施带来了一次高压測试——系统处理了3~10倍于往日的交易量,在高峰时刻,交易量轻松就达到了平时每分钟交易量的100~1000倍。 

       站点排名

    购物站点

    Nov 10销售量相比

    01

    TMall.com

    231%

    02

    360buy.com

    151%

    03

    Suning.com

    115%

    04

    Amazon.cn

    188%

    05

    Dangdang.com

    153

    来源: 2012 光棍节线上零售分析http://www.199it.com/archives/78354.html

    表4  2012年11月11日交易模式(光棍节)

            极高的峰值与均值比(不同量度下约10~100倍)突显了一点。即砖块模式受到了巨大挑战。原因在于为了满足峰值应用需求而部署的硬件资源不可避免会导致正常条件下极大的浪费(超过90%的浪费),甚至在低谷空暇时刻更大比例的资源浪费(99%的浪费)。这一资源的低效利用在微观及宏观层面均存在,成为是砖块横向扩展模式的本质“缺陷”。

    从积极的角度来看这项分析,则显而易见,在超大规模数据中心的基础设施领域,存在着TCO提升的巨大空间。(续)

     

  • 相关阅读:
    RK lvds TF卡修改屏参
    RK3288 recovery ota升级包
    RK G-sensor 测试
    framework 添加新资源
    AlarmManager 闹钟服务
    RK:SIM卡状态显示、隐藏设置搜索栏
    Microsoft 365 解决方案:解析Microsoft Teams的实时事件和Teams Meeting
    Microsoft 365 解决方案:解析Microsoft Teams 实时事件参与角色的职责
    Microsoft 365 解决方案:如何退出其他组织的Microsoft Teams?
    Microsoft Build 2020: Microsoft 365 list,智能信息跟踪应用程序
  • 原文地址:https://www.cnblogs.com/wgwyanfs/p/7219746.html
Copyright © 2011-2022 走看看