单点故障

今天我们来说说单点故障，综合各方观点，百花齐放。

一、 单点故障

一方面

用户现状：核心系统的应用服务器已经采用双机热备。大部分用户当前情况就是双机（两台应用服务器做双机集群）单柜（共享一台服务器）用户面临的问题：
过于注重保护服务器，忽略了更为重要的存储设备。虽然应用服务器采用了双机模式，但却共享一台存储设备，一旦存储设备故障将导致系统的整体瘫痪。数据只有一份，一旦存放数据的存储设备存储介质损坏将导致非常严重的损失。

单点值相关设备只有一台，比如说存储，如果坏了数据就丢了，同时客服业务也停顿了。

我们的HA方案就是做高可用存储集群，这样一台存储坏了另一台上有一摸一样的数据且会自动切换到好的存储上来，不存在单点故障。

另一方面
引用冯大辉在消除小型 Web 站点单点故障(Single Point of Failure)中说到的

说起单点故障(Single Point of Failure，SPOF)，倒是可以想起电影 《2012》中，一把焊枪把齿轮卡住，从而导致整个舱门无法关闭，进而整个引擎无法发动。这是个有点生动的例子–如此庞大的一个系统，居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability)，这是致命的事情。

大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 :)

大体可以从以下几个方面来消除单点故障：
一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。

• 增加硬盘，做镜像。让出错的概率降低
• 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
• SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。
• IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。
• 靠谱的DNS解析
• 等等

单点故障解释

二、简单单点故障架构

一个常见的应用架构如图1所示，若干台云服务器通过负载均衡对外提供服务，在另一台云服务器上安装了MySQL作为应用数据库，为了提高性能，在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中，缓存服务器和数据库都存在单点隐患，可以考虑主从备份的设计。

缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署，数据库是在ECS上安装MySQL，虽然也可以在另一台服务器上安装MySQL，配置主从，但是可靠性仍然依赖于云服务器，故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品，用户无需操心数据同步、主备切换等细节，使用更为方便。优化后的架构如图2所示。

阿里云单点故障架构

三、什么是存储高可用

存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。

故障切换完全自动完成，保证业务系统的连续性。

参考