关于SAN 的设计-最佳的设计

   最近手头项目接近尾声，但愿花些时间陆续把以往设计经验分享出来，固然，这仅仅是来自我我的的经验。

  我会尽可能舍弃些宏观概念，包括项目潜在效益，成本保护等等，由于我以为那只不过是sales 该掌握的。

  SAN最佳的设计：

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

   简单来讲，一个项目每每涉及到不少的集成商，哪怕承包给某一个集成商，也可能会存在不少不一样的原厂设备，当一个问题出现时，咱们须要迅速排除，是SAN switch问题？存储阵列的问题？仍是应用主机的问题？因此，哪怕仅仅是SAN系统中某个设备厂家，对周边设备工做原理的了解，也是相当重要的。

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

保持最简单：

在规划的结构中，复杂的设计结构每每是智能的，但也会带来更多的故障隐患，因此在每一个设计中，我一般会偏向，特地的打造一个孤岛。

好比：在原有的系统中，每每会存在SAN switch，客户也是但愿设备通通接入switch进行统一管理，随着角色愈来愈多的接入，switch 故障影响的范围会逐渐扩大。固然我知道会有冗余机制解决这个问题。

若是一个用于容错的组件（不管主动仍是被动），已经发生问题，而咱们的Admin一般会在下次巡检的过程当中发现此问题，而在巡检还未开始另外一个组件也出现了问题，那么咱们的麻烦就来了。一般处于技术限制，成本限制，咱们过多的高可用集中的单独故障上。

所以，在以往的设计中，若是存储阵列的端口够用，我一般会直连在应用服务器上，跨过其它设备角色，固然备用端口也是须要的，用在从此的扩展，可接在SAN switch上面。若是是在一套高可用的构架中，保持最简单的设计也是通用的。

隔离很重要：

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

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

若是系统部署在一个单独数据中心（一个房间内），咱们尽量用机架隔离每一个设备。若是部署在楼层之间，咱们尽量用楼层来隔离每一个设备。果是位于两个区域数据中心，那么咱们就用区域隔离（在技术容许范围内）。

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

监督与通知：

一般在高可用的架构中，故障会自动切换，可是为了不跟多问题，咱们须要设置更多的策略，让Admin及时获得通知。

知识同步：

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

（关于此篇我已写完，但不包括再次更新）