|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
一、Dependability & Security; Z2 L: i* `( n5 N- O, V0 z
(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性. p# y6 _+ M, O s% e
, u8 u; c/ }" U" s+ o7 V(2)Threats——Faults、Error、Failures
" V. J# m5 {" y% J) l3 \8 A6 Y( ^# x
(3)Means
) {8 I, s/ {) l S
- l+ G4 m; U8 u$ c" h5 o① Fault Prevention: R) {/ Y: H) s4 Y
! S' F% C5 y* V" S; X7 ~
② Fault Tolerance7 ?& |. }7 [( W% t; C) G& k7 p
- {# D) o% E! G4 d$ |) ?
③ Fault Remove
: C( ~2 |! i( D% H& g7 J- d, X
" O# o+ I1 X z④ Fault Forecasting2 A* x7 |" I+ r8 J& `
, i6 S: U# ^: p1 x% g' d
二、状态改变
* y( x2 |8 o7 i5 S7 F6 |8 v Activation Propagation Causation% m3 z' h" ^) P: u8 [: q$ ~8 z
( `3 V1 Q7 h+ m& p) J# A( Z" E.......——Fault——————Errors——————Failures——————Fault.......
7 F% D2 p! `' O7 X, |- U8 J; i: T1 U0 V( \! c. n
三、单点故障和多点故障1 S! R1 G" D+ h
1、单点故障（single point of failure）
4 m: r7 y! ^6 C9 R（1）概念
+ l. I2 T' ~2 U. b; ]1 Y从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。; o: t2 S2 d2 n% X8 H5 }3 g
/ v! H( j: U1 ~9 B, b: ]0 Z
大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够  1 t! o% V& O) N9 g
9 v* K9 }2 f+ j8 Y7 D（2）消除单点故障方法( O/ m) J1 C, q! x1 q
大体可以从以下几个方面来消除单点故障：
2 w' g; Q! w5 t. O0 E# O) e, ^
, a2 c5 f" U8 X4 O2 b+ j一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。0 G {6 L0 Z0 k3 |3 v
! L+ J4 h4 S6 _0 x* y① 增加硬盘，做镜像。让出错的概率降低
6 h/ `, F, ~1 S& z. m8 {& H$ @! i) j
② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
& n" c6 V. Y# l1 G& I4 I* H
& Q+ {" V/ r' y③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。3 s$ Z6 T/ {1 Q; j9 Z6 S1 K* G) b
/ u# O5 B; @: s; _" `2 p k+ _
④ IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。 B& N* v+ R4 V; G+ c5 I4 a
$ ?/ R- }+ P7 g
⑤ 靠谱的DNS解析。/ V! I4 o8 r$ i6 N
6 n) m2 y$ ~2 E' ]3 M+ u( `
（3）简单单点故障架构+ \( n5 @. A }8 \/ a
) p$ \* V2 g; y2 g' R
+ ?% t5 d4 _0 H( k/ Q- m; O
若干台云服务器通过负载均衡对外提供服务，在另一台云服务器上安装了MySQL作为应用数据库，为了提高性能，在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中，缓存服务器和数据库都存在单点隐患，可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署，数据库是在ECS上安装MySQL，虽然也可以在另一台服务器上安装MySQL，配置主从，但是可靠性仍然依赖于云服务器，故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品，用户无需操心数据同步、主备切换等细节，使用更为方便。优化后的架构如下图所示：
5 \+ M! m7 C0 |" r
* Q8 s5 T& ?# a
' o7 a6 N i) H2 P+ `: u# |9 T' z+ c7 V0 g' v# s c+ a
2、多点故障. v* r9 \* v& l# H4 u! U- f8 r, P% W
多个单点故障同时发生或者依次发生。
+ s7 r8 b9 S( Y2 K5 X6 n9 q
) B# b% Z& k; {; T+ ^! U: X% C$ Q& U2 _9 @- o
% b8 c, O8 t9 H! Y3 o
四、存储高可用
9 |1 x# V$ K, l存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。
1 G- y4 Z4 O) |2 `2 _: a9 Z
; J. A) k1 C }9 S8 ]( G- G) g5 f% j9 R1 E( Y/ y2 y
3 X3 V4 w; Z( E0 i% U
五、故障注入2 T! j. X+ R+ L! L/ H( ]8 j0 h
产品代码：故障处理代码——产品功能代码
}& O9 \( W; X9 Y( M1 i7 E1 |6 k2 r1 `# w, y5 j9 `- @1 v
Chaos Monkey0 [4 L4 r. {: I i7 V
% ]8 H; a$ T. V+ r
Linux Fault-Injection
& O1 x) [* [- D# t& H) l3 T
5 w+ O! g+ ]& D& [3 K: q将故障注入内置于产品是最有效的做法，使得产品具有可测性
% k4 m& `+ J5 O# w4 Q" A; i2 \: Q2 t, g2 E! _9 j9 Z
1 O8 Z+ q0 }9 d2 N
6 H5 T- S4 T# L( q8 n6 ?4 Z六、测试实战: F& f# F, |- `' o4 |
未知故障、已知场景（压力、稳定性、流控测试）2 M& n1 P/ y. ]$ {4 Y
已知故障、已知场景（故障注入）
. ]2 K2 s# ]- r- D( Q, w3 x已知故障、未知场景（故障注入）
" i# a+ i: T5 J2 q+ n) O" h未知故障、未知场景（可靠性预计于建模）
8 K' P- T/ Z H5 F' l
6 ^6 k. u6 D0 N4 v0 [% l1 j' g N
. n; j+ A/ x4 u% \8 A# L1、故障模式库——为可靠性测试提供测试输入，定义了测试范围 n8 U8 N1 g' i" b3 s
: O$ b |) G1 d8 |4 u g
2、可靠性测试评估基线
h/ s7 J1 c$ ]8 _
3 M' s8 T' s+ V3 h6 I* i# j- Z% {$ m3、可靠性测试指导书
0 r# d# D5 {+ v: s% i3 g- ], T4 _$ i9 V. ?' J. h& d
4、评估产品的可靠性能力8 M0 Z% a, e* c0 J5 \8 L
, h5 D; ~ _% v. r8 q! e5、长稳测试
( f7 M+ L3 d. A- L! E0 [* h
& g8 f! @4 J/ u7 l' k& u4 L! d5 h0 I4 o) n3 X/ u# H% O
7 C8 r. g! B3 `8 g8 F七、“几个9”
5 x' x8 S! K1 Y4 u4 l产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。# N, I+ X, P" r. G
3 A" L! E% e5 W
对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
0 R, P! z. j4 C, @
- T# D) ~- L5 [5 J4个9：8 |. ?2 K$ }( I$ L9 v+ r
3 Z w9 |- B; h7 k
(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
r8 R- {' ` a) b) c: _7 J, k7 F6 j W/ t' {8 h- C. K4 B
5个9：! o5 R; I3 K9 S2 g
& T! t7 A3 [& `5 G" G; z1 n1 S(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
# X3 m0 T T i
6 d3 I8 y6 j: q2 d: k. v
- a, a0 `( G6 ^, I |
|
/1 
发表于 2021-8-31 14:30
收藏
淘帖
支持！
反对！