咨询架构师可靠性设计的若干问题
Posted 新一代绿色数据中心
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了咨询架构师可靠性设计的若干问题相关的知识,希望对你有一定的参考价值。
缘起
冗余=容错?
?
N+X可靠性一定低于2N么?
基本概念
设计依据:
标准:、技术规范、最佳实践、专家团经验都只是实现目的(去罗马)的道路之一;你可以筚路蓝缕,也可以直接打个飞的士过去;就像孙悟空要去西天,虽然相距十万八千里,但也不过是一个筋斗云的距离。
关键是你的目的是什么?你要满足的实际需求是什么?你有什么样的能力、经验和本钱?
另一方面即使是企业标准,已经为企业量身定制了,但是企业的不同项目依然会有不同的特点,标准无法事无巨细,标准也无法列明所有特点和针对性措施,只能妥协和平均,即使把底线拉得很高,那不过是成本向质量的一次妥协。
即使已经是最佳实践,也只是适用某个细分行业或者某类特定客户群或者某个设计、建设、运行、销售管理团队,而无法生硬的照抄或者硬套。
知识并不是看到就属于你,而是要理解融会贯通般的掌握了,才真正属于你,否则和你作为吃瓜群众时,看过的新闻,吃过的瓜或者瓜子一样,最终并不能带来什么效益。
需求:你的需求,你的上司的需求,你的部门的需求,你的企业的需求,你的企业的客户的需求,你的企业的客户的客户的需求。当然并不是我们了解了终极需求,就能挟天子以令诸侯,哪些边界能突破哪些边界不能突破,这都需要依据你的本钱、能力、环境、目标、性格来决策。我们提供一张水温的需求图表来供大家参考这种需求递变和约束边界。
系统:一个系统既可以是数据中心一个整体,也可以是云计算系统下多个节点机房,还可以是某个数据中心中的某个子系统或者子模块。
系统由网+人组成,网由节点(设备、部件、模块)+路由构成。出于不同的目的和角度,人也可以视为网或者节点或者路由的某一个部分。
节点:设备、部件、模块或者子网与子系统,常见的如空调安装工程师、ups设备、制冷系统、设计团队、云服务一键切换系统等;
路由:路径、节点及网间链路或者子网与主网间链路,常见的如供电线路、冷却水循环管路、外电、外网、外水路由等。
节点与路由当研究对象和边界确定和切换后具有相互转化的可能。就像《》中提到的由于角度不同,同一个电路的电阻既可以看成电压负载的并联也可以看成电流负载的串联。
可靠性与架构:虽然很多节点和路由的可靠性数据较难以准确获得,但是不同架构间的可靠性对比和评估,往往还是只能采用可靠性的定性或者定量的计算来开展。
依据架构师的不同,往往会选择各异的节点和路由,并通过不同的连接方式将节点和路由进行架构,比如节点先和路由串联,再进行并联,组成相对独立的子网和系统,也有喜欢将节点并联、路由并联后,在进行串联,组成冗余可借用的子网和系统,当然也有兼收两种架构优缺点的居中架构。
真正的冗余必须与被冗余在节点或者路由或者系统层面上形成并联,否则将无法带来可靠性的提升而降格为假的冗余。
容错与冗余
规范的解释如下:
福哥观点:
冗余的目的是为了容错;
容错的手段/方法是通过冗余;
冗余=容错;
冗余无法容错就是假的冗余;
容错没有冗余就是假的容错;
那么是不是规范和大家开玩笑呢?当然也不是,大家的语境没有统一,讲目的(容错)的时候说的整体(系统),讲手段(冗余)的时候说的局部(设备/路由:组件、单元、模块、路径);
这样牛头不对马嘴自然会惹出很多困惑;
真正实现了什么东西(组件、单元、模块、路径或者包含其全部的整体系统)的冗余,那么必然能实现发生在被冗余部件/系统上的错误,这要求冗余X必须与N采用直接并联模型,否则无法实现任意X的损坏不影响系统正常运行;
当然也有没有实现的,那么只是多余部件/系统的堆砌而没有有机融合,比如空调N+1,结果备用空调没有供电/供水/没有在出现故障时自动/手动的按需开启。
在去年双十一的时候,福哥曾经写过一篇科普《》,在文中说到:
假的高效会影响可靠,而真的不会,只会提升系统可靠性。
假的高效:一堆所谓新节能设备和新节能技术的堆砌;枉顾安全和实际运行风险的节能优化策略;一个数字上的虚拟游戏。
反过来也是一样成立的:
假的高可靠会影响高效,而真的不会,只会提升系统效率。
假的高可靠:一堆高可靠设备、技术的简单堆砌;枉顾效率、环境和团队能力的拒绝变化的借口;一个责任上的推脱游戏。
我们无法想象一个经常出故障的设备/系统能在实际环境中保持所谓的高效,我们也无法想象一个低效的设备/系统能在实际受限的环境中保持所谓的可靠。
回想一下世界上第一台电脑eniac出现的时候,体重27吨,使用了18000只电子管,6000个开关,7000只电阻,10000只电容,50万条线,耗电量140千瓦,可进行5000次加法/秒运算。对比现在的普通笔记本,轻松百亿次运算,重量不足万分之一,耗电不足五百分之一,谁低效?谁可靠?
在数据中心中也一样,低效必然带来更大的散热需求,更复杂的结构,更多的成本与耗电,更不可靠。
即使ups输出达不到1,我们打9折,如果是9kw的机柜4个排一起
机柜你考虑怎么散热?
而这ups你是怎么待它的,你敢让他满载嘛?反正我是不敢。
有人或许会说2n的架构下负载率只有一半,但是当其供应不间断供冷的水泵或者风机负荷时呢?
在运行中保持高可靠又是如何拒绝低效的呢?监测效率,系统失效前往往首先会由高效运转转为低效运转,然后才是迟缓、故障、瘫痪。,表明大部分事故往往在之前都有大量征兆,大量失效系统在失效前都经过一个非常长的低效运行期。
N+X vs 2N
数学解释
当X>N,则N+X优于2N;
当X<N,则N+X<2N;
如果N+X与2N讨论的是同一个对象的时候。简单与复杂很多时候就出在不是同一个对象上。
实践解释
当然实际数据中心并不是这么简单的单一系统,其由复杂的多个系统相互嵌套综合构成,而每个子系统同样也是有多个孙系统相互嵌套综合构成,真是应了愚公的一句话,子子孙孙无穷尽也。
尤其是常规架构师经常忽略的设计团队、建设团队、运维团队这几张人力构成的子网/系统。
这也是为什么,有时候越简单的系统,可靠性看起来会更低,而实际实践中却更高的原因;
在可靠性的模型中,人力系统是串联在其他系统之上的,属于可靠性木桶的短板,系统越复杂,对于非,其短板将变得更短,而导致综合可靠性下降;
这仅仅是一个it负载的供电系统原理简单示意图
属于N+X?或者2N?或者还有人说叫DR?Δ2N?
从最后一级IT负载供电路由来看是2N;
从UPS、变压器来看是N+1,N=2;
从架构形式上看,变压器、ups、负载
采用先串联后并联的方式;
忽略不影响本次可靠性讨论逻辑的ups及线路损耗等问题,
上图称为A架构;
ups单系统容量由150下降为100,
那么这个系统B架构就变成了N+0了。
那么我们把这个图复制一遍,
也就是负载N由300变为600
ups、变压器由3套变为6套,
C架构:当ups单套容量为150时,
系统由N+1变为了N+2;
我要告诉你这是假的N+2;
D架构:当ups单套容量再增加为200时,
系统由N+2,变为了2N;
我要告诉你这是假的2N;
虽然每个环节,每个系统看起来都是2N;
但是如果坏了任意3台ups或者3台变压器或者3条变压器到ups的路由,
系统都将有至少1/6宕机;
如果坏了刚好是一个负载对应的2台ups或者2台变压器或者2条变压器到ups的路由
系统都将有1/6宕机;
是不是有点反直觉?在先串联后并联的更独立和简洁的架构模型下,
C与D的可靠性竟然是完全一样的。
虽然D比C从容量上来看多了33.3%
但是
一个负载对应的2台ups或者2台变压器或者2条变压器到ups的路由失效,
系统1/6失效
任意3台ups或者3台变压器或者3条变压器到ups的路由失效,
系统至少1/6失效
并没有比C可靠多少
当然如果设计预期不准确
实际上负载超过100,那么这种情况下
多花出去的投资是有意义的
降低了对于设计准确和容量预测的要求
主编寄语
没有与N并联的冗余X,是假的/过度冗余。
如果N+X与2N讨论的是同一个对象的时候
当X>N,则N+X优于2N;
当X<N,则N+X<2N;
冗余的目的是为了容错;
容错的手段/方法是通过冗余;
冗余与容错被割裂的唯一可能就是鸡同鸭讲,局部VS整体;
冗余无法容错就是假的冗余;
容错没有冗余就是假的容错;
是统一的,殊途同归的。
架构师进行可靠性设计时,应考虑制造、安装、设计、建设、运维等人力参与/主导的过程中,人力执行的可靠性问题。
就像如果我们给火星人设计一套非常智能的无人驾驶系统,只要脑意识表达出发和目的地就行或者只要按动飞船内的唯一按钮即可,但是火星人可能不知道那是按钮,或者就像原始人一样围着它崇拜,祭祀,几万年后才有幸运者进入启动。
好在虽然外语很多,我们大都还都是银河系的日地行星系的现代地球人,甚至都是业内专业人士。
欢迎登记会员资料,加入新一代绿色数据中心超人同桌俱乐部,成为俱乐部会员,享受更快捷高效的沟通与交流。
http://m.rrxiu.net/?v=3twz0u
更多福利正在陆续对登记会员开放,欢迎加入。感谢各位信任,会员资料将严格保密,仅限于授权用途使用。
近期文章
相关推荐
专栏简介
查看专栏文章方法:
通过向本号新一代绿色数据中心发送科普两字;
通过点本号新一代绿色数据中心菜单效-科普文章。
欢迎各位有意赞助、投稿、提问、建议的有缘者
将您的需求或者相关资讯发送至tmedcee@163.com或者在相关科普文章上直接留言,我们会酌情处理。
会刊订阅者可在页面上将希望了解、科普、咨询的技术话题留言即可。
愿善满天下
感谢关注新一代绿色数据中心;
欢迎联系我们tmedcee@163.com。
愿天道酬善,众生安乐!
以上是关于咨询架构师可靠性设计的若干问题的主要内容,如果未能解决你的问题,请参考以下文章
[ AWS - SAA ] 解决方案架构师之设计弹性架构 - 选择可靠的弹性存储(如何选择 SSD vs. HDD)
[ AWS - SAA ] 解决方案架构师之设计弹性架构 - 选择可靠的弹性存储(如何选择 SSD vs. HDD)