|
|
EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
一、Dependability & Security k3 `) }/ N8 f0 x
(1)Attribute——可用性(Availability)、依赖性(Reliability)、安全性(Safety)、机密性(Confidentiality)、整体性、可维护性, \' h7 P4 ~: J$ E( E3 O. a' s
7 c5 W# n) A. f e9 |4 W* f3 `* |
(2)Threats——Faults、Error、Failures
% d A, q6 z h' L7 Y5 A9 Z) x- `) s5 ?: t4 h7 l+ V
(3)Means$ o- D. c$ X- N& L$ M% ?' U
) L/ d$ W4 t& R( H! Y. J# g% b① Fault Prevention
3 Z7 k/ G, F0 T; m1 q, V7 s( |6 i0 U: @/ R; U" H: ?* Q% K) @
② Fault Tolerance3 x7 q" P) Q+ ^
# K2 Z! x+ k* c. u' {5 k6 w③ Fault Remove: D' w7 N9 L* q1 s* S! c) l
! ~* g/ t$ E1 `9 G④ Fault Forecasting
2 y% Q- v$ X( c8 o& H. j) U: I5 s' I; W
二、状态改变 H; w3 R$ L* R3 A7 }
Activation Propagation Causation& A% b$ Q* [) ~2 {. j; {4 _
/ W x: s$ B% ^.......——Fault——————Errors——————Failures——————Fault.......5 c( E3 U; w3 q8 S) c, ?
K! `2 c, a, d" ^三、单点故障和多点故障
+ L2 Z6 F8 A! {( T: o8 N0 C2 b1、单点故障(single point of failure)
+ Y: W5 L! f% u. }! t' a(1)概念7 a M6 k/ D% B5 F
从英文字面上可以看到是单个点发生的故障,通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。2 D+ X% Q# N# |8 }3 v$ x5 ~7 K
' d- Z" Q/ j; A! x
大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 ! A+ w' x: s m& J
/ _3 `; E7 g7 @6 `8 H& E0 n
(2)消除单点故障方法
! k& w& X" c& A; ] H9 J+ W6 x) i大体可以从以下几个方面来消除单点故障:
G( w) N( }, P9 R7 \' x( y' p& a! f3 l5 y9 P% |- A) C+ Q5 t
一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效地消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,随着架构的变化,定期审查系统潜在的单点也是有必要的。/ T8 I4 s% S9 i( L3 e7 p# q! {/ K
; r7 r$ {5 f* t& W
① 增加硬盘,做镜像。让出错的概率降低
' k, [5 E/ c& q
: ?- x l% r, b8 \3 m② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
* r8 l: V9 J+ p- _' v/ x' }
) H9 @# x8 r: I; o③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。
9 B5 B! H1 j1 }! S
@& h: m5 x" q6 V/ |④ IDC 机房的单点。由于中国特色的“南北互通”,所以选择IDC机房的时候,一定要有冗余。
: K! n; H3 n/ ], m! Z; g } k' x; o! F$ i; m" P
⑤ 靠谱的DNS解析。
; |7 ~/ T) r d8 \% q' U2 }( t
( a' b4 M( }9 R(3)简单单点故障架构! m w6 Y! i0 n
7 ]9 u# i3 G& ~2 p! e/ c
/ I4 h8 {4 w4 G6 n/ `若干台云服务器通过负载均衡对外提供服务,在另一台云服务器上安装了MySQL作为应用数据库,为了提高性能,在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中,缓存服务器和数据库都存在单点隐患,可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署,数据库是在ECS上安装MySQL,虽然也可以在另一台服务器上安装MySQL,配置主从,但是可靠性仍然依赖于云服务器,故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品,用户无需操心数据同步、主备切换等细节,使用更为方便。优化后的架构如下图所示:+ Z+ w( P0 `# f, F+ z# H8 K9 Q
$ U+ c( E- v" ?* I, d }7 r- J
7 R5 h7 @8 Y. a# @; w
2 `# _ ]- ?& C" h, ?; ]2、多点故障
$ P# _! a1 U6 A- h' B0 h! X多个单点故障同时发生或者依次发生。5 B$ d* H4 A" z: M
" n! C. b% G% B. W* G
4 I8 S9 m7 j' ~+ ?- K9 g% M
* j0 c* }8 I* B9 |* ~" y; j' C% `$ b
四、存储高可用
( O8 h7 \1 [' H) F& l* E; b* K+ |' G存储高可用解决方案采用存储设备与管理设备冗余架构,任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成,保证业务系统的连续性。
, y! h! w Q; a* X4 `. J6 B1 M, P
( _4 Q' _' b5 k, W
9 {# F- W+ W5 x) b
" P* |5 Y. @& n8 B9 y0 o5 P五、故障注入
1 ~* m b4 ?. i1 m6 t% I: @产品代码:故障处理代码——产品功能代码3 S2 L) e9 Q1 A4 P6 j$ X
# m5 Z5 V5 o/ ^
Chaos Monkey* x2 M% R5 z/ x8 i# o: j& h
+ \. N/ g/ \- S
Linux Fault-Injection
: o, Q7 U! M9 ]9 }* \6 I H# O! E3 R8 j
将故障注入内置于产品是最有效的做法,使得产品具有可测性
% }7 s# d9 _' j! ~# D$ b+ k, l6 e/ Z0 a/ r) x0 I. f' }: g& F
3 n" g! N* n6 k4 ^* s) x+ Y$ H D& d7 z' b
六、测试实战
6 P+ z$ }0 T/ q1 G6 S9 {/ z未知故障、已知场景(压力、稳定性、流控测试), ? d$ j' l1 a3 o7 T2 x7 w
已知故障、已知场景(故障注入)
+ L9 d) N; g: [: w8 t7 c( `已知故障、未知场景(故障注入)2 A/ O( o7 W6 ~0 q0 i
未知故障、未知场景(可靠性预计于建模)1 o3 s% p5 i5 E/ ]/ Z; E8 g
+ I1 N0 ~) f+ ^: Q
/ w: C8 E. e, |" Z. L2 G
1、故障模式库——为可靠性测试提供测试输入,定义了测试范围
/ E, R# U; L, H2 i5 E6 }0 W
2 M {7 G( D+ M/ {- w2、可靠性测试评估基线# E: }) F! R6 A9 \' ?
5 m% B& r$ \5 [! E9 f3、可靠性测试指导书
6 Y \/ L0 L A; Q) y' m7 M% U$ b9 T8 B/ I3 D" }* F+ [5 A
4、评估产品的可靠性能力
* D/ u% s; l- y* ?8 A9 Y6 r5 i+ r6 H8 L: C; K) m7 z/ ^
5、长稳测试
+ n. |% y9 y- R7 l* \0 u
1 `& g. x3 u) G+ C: F" S3 h
+ Z7 x% R+ @; x8 m" |0 b! |" t- K6 n- u, c" f3 X
七、“几个9”
: h2 f3 t5 B1 B) b: i产品的可靠性是指:产品在规定的条件下、在规定的时间内完成规定的功能的能力。/ ?' P, Y# t$ V, |3 ^0 A
& d: Q1 { {; X2 P
对电子产品而言,产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。 & y4 m5 Q. n2 E! r3 o
+ Q% }9 q2 T) _! l. w& `
4个9:/ |9 P" P# c" S6 `5 A8 l
4 y8 J% l$ Y9 M- [) e- g(1-99.99%)*365*24=0.876小时=52.6分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
+ K3 ?6 o# S! |# I% Z1 P" s
& {9 ^( K7 ^* `. X. F5个9:- E1 a$ d, U! t8 o
4 L4 m& B* ~* R$ z(1-99.999%)*365*24*60=5.26分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
3 w. W, r( B! u) H! P9 _8 A, ^/ k
* h& S/ C1 ]4 R$ f3 e% W0 ]- v8 b |
|