|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
本帖最后由 embnn 于 2021-8-27 10:48 编辑 7 G6 a) z4 H% k& k, A
' X5 d7 ?" T( c' r" I一、Dependability & Security" g* j' {- I# e) \+ u
(1)Attribute——可用性(Availability)、依赖性(Reliability)、安全性(Safety)、机密性(Confidentiality)、整体性、可维护性; `8 R0 `) e- X
/ G% @5 M: X+ {* K- _3 J7 D(2)Threats——Faults、Error、Failures
4 O8 @# u0 n# ]% ~/ _! b( R* I0 p9 A) ^2 g- l+ d, @" A' @0 T4 A
(3)Means
. f! W" t' l. Y) v/ J+ R
; W! h! }3 m5 }! A+ Z% E r9 V① Fault Prevention
6 n; ]1 d& `$ n: m7 }2 p1 f" k* e! i6 p3 ^# i: I5 g4 Q& n
② Fault Tolerance3 V1 q& z$ v; X; H4 H
* [* k$ r) _# m' `3 `" f
③ Fault Remove/ N; p- b, A1 m+ z
( r" C$ s! g8 ]④ Fault Forecasting
. m7 X5 A; q: ] a
9 u Z6 j. D# n! W. }/ A, V. r3 A二、状态改变
. E. q9 b r0 Q0 l Activation Propagation Causation
7 u' Q( ?5 Y0 T
" g9 P: j, {6 P, [: N( X.......——Fault——————Errors——————Failures——————Fault.......
$ Q2 O4 A3 V- l1 O; p% ?) P. O8 u* C
三、单点故障和多点故障
) r& q8 G! d. O- w' h) V3 l; q, y1、单点故障(single point of failure)
, X- s0 b7 ?7 {7 Y1 J O(1)概念( l1 k* Y Z# w7 M9 h3 }
从英文字面上可以看到是单个点发生的故障,通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。) O k C1 @. [! |
/ s# I2 S/ d, D/ u+ n- g% R大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够4 f, O, a. u# h2 h
& F* D6 U0 `6 ~
(2)消除单点故障方法
! L9 a1 f; C1 C; w# L5 |2 i5 w& `7 r' p大体可以从以下几个方面来消除单点故障:. m6 h3 \0 J* X( p; r, n
" @4 l$ J0 M, |! H1 ^* e* S一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效地消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,随着架构的变化,定期审查系统潜在的单点也是有必要的。
9 O. |$ p0 H0 N2 E$ E. R9 l' d
, K* ] x# l5 Q6 l4 i) D7 K① 增加硬盘,做镜像。让出错的概率降低7 c4 f5 e7 s! S; j- w$ G
6 i1 o7 \' m0 E- V
② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。/ S( X; j6 L. l: U
8 F$ a* w: K/ c$ U- z" D- P! s③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。* m9 `1 W7 f9 a$ _% z2 k
1 R! ~9 y" a+ }& Z' `$ r& k/ W7 ~* e④ IDC 机房的单点。由于中国特色的“南北互通”,所以选择IDC机房的时候,一定要有冗余。
" t& ^2 V* C a0 p
- @# v8 B) e4 N2 N5 y% L⑤ 靠谱的DNS解析。. Z; ~0 [) x# y' k/ X. P0 m
9 d) v3 G9 R1 {& o" _$ S0 H" P(3)简单单点故障架构: ]: l/ v) v' P. v: Y3 y/ ~5 P
; Y4 o. \, T2 w* _- j5 a# U' d4 M* W7 Z. S8 j
若干台云服务器通过负载均衡对外提供服务,在另一台云服务器上安装了MySQL作为应用数据库,为了提高性能,在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中,缓存服务器和数据库都存在单点隐患,可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署,数据库是在ECS上安装MySQL,虽然也可以在另一台服务器上安装MySQL,配置主从,但是可靠性仍然依赖于云服务器,故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品,用户无需操心数据同步、主备切换等细节,使用更为方便。优化后的架构如下图所示:
% v" I, m- _6 s- s' l: _! w5 X& C( U* Z+ Y
0 P" P6 F4 |( M6 R' y! h
9 B9 j" i4 b: W2、多点故障! z- U6 x0 l: o: m
多个单点故障同时发生或者依次发生。! s+ G1 `$ S, G1 y* ]& X
! z: O* q$ \: k. O! K
' |4 \! f& i& o! [, k& ]3 V, `5 x) U2 y6 m3 j1 B! Z/ p% P
四、存储高可用
. b. _1 U7 {& ~存储高可用解决方案采用存储设备与管理设备冗余架构,任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成,保证业务系统的连续性。" d+ B* `/ [6 J
" ?+ D/ _* ~' Y
2 M2 k9 r; O! {( j
0 Q* Q1 p1 K' A8 r; o五、故障注入: u6 }% z, t7 C6 R! g
产品代码:故障处理代码——产品功能代码7 g) H9 w6 G7 n5 b/ K
' }! |1 ^9 W& V/ Y2 C9 GChaos Monkey
1 G- h5 K' e& P7 H k) \, [0 z% l0 H. o# ` s
Linux Fault-Injection8 b& \( ~ Q P. Z
( s. V" _% q- {$ t. }* b
将故障注入内置于产品是最有效的做法,使得产品具有可测性# N; {8 I0 X& @2 x8 |7 ~$ ?
- d9 n) [7 x F2 m/ Y
2 W' V/ T( Y. J
5 W+ q$ Y/ y2 F* X六、测试实战5 i( b3 b7 W; x" _3 t& J" ?' D
未知故障、已知场景(压力、稳定性、流控测试)
( x9 t* a8 o6 a5 ] Q/ C2 {" e已知故障、已知场景(故障注入)
# j7 s) e* F8 A8 e1 w已知故障、未知场景(故障注入)/ {9 F, _$ }3 ]1 p, c
未知故障、未知场景(可靠性预计于建模)
: _* t1 e" p0 T* T6 L1、故障模式库——为可靠性测试提供测试输入,定义了测试范围+ F. e% M( C& L, @1 C
% T- `( j9 H' t* G% \" s; L
2、可靠性测试评估基线
2 x p6 T* b% D/ e! Z( ^. k/ l; N
3、可靠性测试指导书
4 h+ D/ \- G& m$ }3 s/ ? @" P0 a. i& U3 w, C2 Y
4、评估产品的可靠性能力, { r: p% W9 t8 M0 }5 }
2 u: m- {4 s4 [6 O' A& D2 X. h5、长稳测试4 }/ r' a- k) V; k1 m
( a1 f+ ^: t1 j. {2 i2 V
2 x. K# g- H3 [- |4 T/ t* y. `* }' \+ \1 d; ~+ [' q6 u. Q
七、“几个9”
" Y6 F9 Q8 x4 V+ j" [产品的可靠性是指:产品在规定的条件下、在规定的时间内完成规定的功能的能力。0 e0 v1 d3 x6 l3 \" \+ Y$ C" ]2 Z
4 v! E$ F$ {& o7 N3 f
对电子产品而言,产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
8 g) Z9 P; W$ K! u0 n! T1 q% d5 t5 c* N1 h% R
4个9:
1 d1 {9 O4 O7 b! I, b9 y8 @$ j# j2 i! B' f
(1-99.99%)*365*24=0.876小时=52.6分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。5 a; w9 m0 J" {$ }9 X
. L+ T2 W$ D& }
5个9:
4 p. B; H' l) d, L5 F+ ]4 V# c) H5 m. z
(1-99.999%)*365*24*60=5.26分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
6 |. r+ `9 F& ^+ A# J
7 ^1 g: c' h$ j& e# m
" P: _) b' w: i1 S |
|