最近手头项目接近尾声,希望花些时间陆续把以往设计经验分享出来,当然,这仅仅是来自我个人的经验。

  我会尽量舍弃些宏观概念,包括项目潜在效益,成本保护等等,因为我觉得那只不过是sales 该掌握的。

  SAN最佳的设计:

首先,我们应该是知道SAN的工作原理,整个SAN架构中个角色的定义,及工作原理,这些是基础的部分,但也是最关键的,如果缺少对角色工作原理的理解,往往会延长故障的修复时间,设计的优化及性能的发挥。

   简单来说,一个项目往往涉及到很多的集成商,哪怕承包给某一个集成商,也可能会存在很多不同的原厂设备,当一个问题出现时,我们需要迅速排除,是SAN switch问题?存储阵列的问题?还是应用主机的问题?所以,哪怕仅仅是SAN系统中某个设备厂家,对周边设备工作原理的了解,也是至关重要的。

   利用免费的互联网资源,获得这些知识,是再好不过了。


保持最简单:

在规划的结构中,复杂的设计结构往往是智能的,但也会带来更多的故障隐患,所以在每个设计中,我通常会偏向,特意的打造一个孤岛。

比如:在原有的系统中,往往会存在SAN switch,客户也是希望设备统统接入switch进行统一管理,随着角色越来越多的接入,switch 故障影响的范围会逐渐扩大。当然我知道会有冗余机制解决这个问题。

如果一个用于容错的组件(无论主动还是被动),已经发生问题,而我们的Admin通常会在下次巡检的过程中发现此问题,而在巡检还未开始另一个组件也出现了问题,那么我们的麻烦就来了。通常处于技术限制,成本限制,我们过多的高可用集中的单独故障上。

因此,在以往的设计中,如果存储阵列的端口够用,我通常会直连在应用服务器上,跨过其它设备角色,当然备用端口也是需要的,用在今后的扩展,可接在SAN switch上面。如果是在一套高可用的构架中,保持最简单的设计也是通用的。


隔离很重要:

SAN构架中,任何依赖于某个单点设备运行的角色,我们都应该将它隔离出来,避免因为这个单点设备故障,带来的全局影响。

SAN架构中,脱离公共网络,避免非专业人员进行访问,然后为多个授权的Admin设置访问策略。

如果系统部署在一个单独数据中心(一个房间内),我们尽可能用机架隔离每个设备。如果部署在楼层之间,我们尽可能用楼层来隔离每个设备。果是位于两个区域数据中心,那么我们就用区域隔离(在技术允许范围内)。

配置UPS,避免相同设备接入同一个电路中。

监督与通知:

通常在高可用的架构中,故障会自动切换,但是为了避免跟多问题,我们需要设置更多的策略,让Admin及时得到通知。

知识同步:

确保每个Admin对系统了解的信息都是最新的,这些信息包括最新的升级,及最近一次的更改。

(关于此篇我已写完,但不包括再次更新)