|
|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
本帖最后由 embnn 于 2021-8-27 10:48 编辑
( |. d4 v. P3 [# U/ a; S5 c3 s6 W$ D8 a! r* Q H% d; o
一、Dependability & Security
+ b/ N5 j) Q& S3 X+ h(1)Attribute——可用性(Availability)、依赖性(Reliability)、安全性(Safety)、机密性(Confidentiality)、整体性、可维护性
' s- [$ P( S5 V
( V6 G$ Z% a" [. l& _(2)Threats——Faults、Error、Failures
Z. _& g4 R6 a. `# F3 I& v: L: M) E, @' r5 K c" O" c% \' v' `
(3)Means7 ?% Q6 X9 `# y( }
. J6 M6 P; N6 h+ L' A Z6 w
① Fault Prevention
/ N. a& K% Q7 a/ O4 f2 T9 y( @. ]
0 ~& ~# c2 ], W+ z② Fault Tolerance0 @7 V! B0 y. x4 J# j
7 e$ Q# X' W3 r) s
③ Fault Remove
6 t5 C& V; i% a8 r
q. g" X L" v# a④ Fault Forecasting
2 Z" H( V8 q8 S. p, q a5 q2 s4 I# H, t0 |' h* x- v' W8 F
二、状态改变
- B6 m4 M7 T, O$ d: f' n( F Activation Propagation Causation
1 Y0 x6 j! m% `4 X/ G$ v0 ]
9 {4 q) r# w+ E; S1 l.......——Fault——————Errors——————Failures——————Fault.......
6 q: u; v7 F1 W. `, s& K
, s4 x* i- t, {! F2 u" ]8 g三、单点故障和多点故障* z% k9 h& K j; ~1 `; }
1、单点故障(single point of failure)
: p5 S' J5 s2 C" @( V. ^: A- J(1)概念# f3 H Z2 f5 U! g9 a. I9 @
从英文字面上可以看到是单个点发生的故障,通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。) Y$ z( Q; s! c. d! B
7 @7 V; p9 q& B3 a' m- ^9 g
大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够1 T. }. l2 w5 q$ A. z4 \$ k- P1 u
, m ]7 _* {, g(2)消除单点故障方法( @: }0 r# h( \/ e6 ]* U" {7 R
大体可以从以下几个方面来消除单点故障:
8 d( u# I4 H3 b! a3 N& y- r1 g2 Q, E8 c) U
一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效地消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,随着架构的变化,定期审查系统潜在的单点也是有必要的。 V" D( k5 ^! W0 R; A9 w
0 ?) F4 V2 x( p" ~- B① 增加硬盘,做镜像。让出错的概率降低
& X I% A0 ]9 E1 i o
+ V3 `$ ~2 Q* _1 |② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
7 @$ y; ~. I: ^# u) T% Q
& e! h J% l+ |6 ?, a* Z' M③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。
3 S# R( n- m% r9 n4 s
, O/ F; e1 o& g, D④ IDC 机房的单点。由于中国特色的“南北互通”,所以选择IDC机房的时候,一定要有冗余。% d. F! ~' O0 ^1 E
0 ?1 I: n7 N9 Q8 W( C
⑤ 靠谱的DNS解析。$ {" `8 x; O- x. T1 J
* Y4 X8 p1 _8 I- t- A( I
(3)简单单点故障架构% H5 T8 x j' A2 D0 m
& J* @8 V; X* M7 I% M7 |) S9 @2 c: M, G
若干台云服务器通过负载均衡对外提供服务,在另一台云服务器上安装了MySQL作为应用数据库,为了提高性能,在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中,缓存服务器和数据库都存在单点隐患,可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署,数据库是在ECS上安装MySQL,虽然也可以在另一台服务器上安装MySQL,配置主从,但是可靠性仍然依赖于云服务器,故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品,用户无需操心数据同步、主备切换等细节,使用更为方便。优化后的架构如下图所示:# }% y3 A- u2 ?8 l/ g
: ^8 X! o+ I9 x1 ]8 v
/ q" c5 \0 v1 q/ q# U( `( o; H V3 o ?. z1 l
2、多点故障
- ]' z5 D! d: V1 C% X/ F8 Q' {多个单点故障同时发生或者依次发生。5 _( p' y9 N. I( O5 u, ^7 @% e
) Z, |9 b# k, o- E# ~. V, j3 q/ [
/ y, K7 |( C# w3 h
0 A: w$ R* W$ M, L6 s四、存储高可用4 D2 G+ W9 P- H5 X' `
存储高可用解决方案采用存储设备与管理设备冗余架构,任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成,保证业务系统的连续性。
0 `, X) Y' M! W* X1 |
1 t( @7 m' k) [( m# j3 P" _, \7 Z* ?8 }+ E, ~; N
( @* G/ f5 @7 L5 u% q7 W
五、故障注入9 x! [& ?6 A( P/ \6 F7 @& ^; C
产品代码:故障处理代码——产品功能代码
6 K3 [1 J5 @7 G- J2 |
% L6 f/ B" E8 l7 y x1 [+ q8 {Chaos Monkey% u% U) t7 J0 a& {1 c
5 n4 c. _- b5 ALinux Fault-Injection
6 U/ D* W: ]& m, V4 J9 J* k4 x
- ?' b, ?6 F( X2 G1 p! |" ?; m将故障注入内置于产品是最有效的做法,使得产品具有可测性' b3 g7 J( u# o4 x
2 X9 A7 p& {2 E. t x
1 V& A; |- J3 D. @/ k
# E9 r# r# f2 Z6 ^8 Q. f# ^
六、测试实战. O: p" Z4 X, o+ l$ h
未知故障、已知场景(压力、稳定性、流控测试)( p. F h' q3 R1 A: W
已知故障、已知场景(故障注入)
3 u$ O5 J T; |* L9 V, F. K) g! v已知故障、未知场景(故障注入)2 @0 [& a$ B9 X7 ?$ }, M
未知故障、未知场景(可靠性预计于建模)
/ Y. _! R: E d, V4 L% z8 U/ e; F1、故障模式库——为可靠性测试提供测试输入,定义了测试范围
, S( F! E3 E; n6 X; C
- x6 l6 X5 L2 i8 U w. H2、可靠性测试评估基线( t1 [* N' J( `, ?
9 R0 w# O6 K1 F1 ~! j; e
3、可靠性测试指导书0 @! U0 G* I( H; G7 ^6 _
& S. T, Y0 n2 Y1 e" r4、评估产品的可靠性能力
5 O: p& j$ @) a$ L. N& g& r$ d# U( f9 B8 ^: c& ?5 y
5、长稳测试
# c }$ b# ~5 W. p) k
' f5 a5 z- }" P% o/ j
! M6 j5 k- L! g
0 B; Q* K9 B' Q- a& D& O7 ]1 g七、“几个9”" j. O* j* x8 O! ^1 r
产品的可靠性是指:产品在规定的条件下、在规定的时间内完成规定的功能的能力。( M" ]# u5 h! L/ B: K9 E& \" x
* D$ n! z5 X: D: ^) c对电子产品而言,产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。 # [! [1 X. z4 _% ^
) [5 ?, Y% S& ] C4个9:
7 ]; q' ]2 p' {9 q, n
9 F3 W. ]. }* J. ~(1-99.99%)*365*24=0.876小时=52.6分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。5 P4 [9 w: j/ _2 X, q
9 d- U+ y' a* w! F2 r7 y. B
5个9:
5 m4 j! ?. p* U6 f! c4 c& l
- k! M. o5 C; s& A. ^(1-99.999%)*365*24*60=5.26分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。+ e5 r( [) A, ^3 k& `. z1 V& Y
6 S. L7 W! `' W z( }+ K; }
' N3 a: g1 S ` k6 o
|
|