最近手头项目接近尾声，希望花些时间陆续把以往设计经验分享出来，当然，这仅仅是来自我个人的经验。
我会尽量舍弃些宏观概念，包括项目潜在效益，成本保护等等，因为我觉得那只不过是sales 该掌握的。
SAN最佳的设计：
首先，我们应该是知道SAN的工作原理，整个SAN架构中个角色的定义，及工作原理，这些是基础的部分，但也是最关键的，如果缺少对角色工作原理的理解，往往会延长故障的修复时间，设计的优化及性能的发挥。
简单来说，一个项目往往涉及到很多的集成商，哪怕承包给某一个集成商，也可能会存在很多不同的原厂设备，当一个问题出现时，我们需要迅速排除，是SAN switch问题？存储阵列的问题？还是应用主机的问题？所以，哪怕仅仅是SAN系统中某个设备厂家，对周边设备工作原理的了解，也是至关重要的。
利用免费的互联网资源，获得这些知识，是再好不过了。
保持最简单：
在规划的结构中，复杂的设计结构往往是智能的，但也会带来更多的故障隐患，所以在每个设计中，我通常会偏向，特意的打造一个孤岛。
比如：在原有的系统中，往往会存在SAN switch，客户也是希望设备统统接入switch进行统一管理，随着角色越来越多的接入，switch 故障影响的范围会逐渐扩大。当然我知道会有冗余机制解决这个问题。
如果一个用于容错的组件（无论主动还是被动），已经发生问题，而我们的Admin通常会在下次巡检的过程中发现此问题，而在巡检还未开始另一个组件也出现了问题，那么我们的麻烦就来了。通常处于技术限制，成本限制，我们过多的高可用集中的单独故障上。
因此，在以往的设计中，如果存储阵列的端口够用，我通常会直连在应用服务器上，跨过其它设备角色，当然备用端口也是需要的，用在今后的扩展，可接在SAN switch上面。如果是在一套高可用的构架中，保持最简单的设计也是通用的。
隔离很重要：
SAN构架中，任何依赖于某个单点设备运行的角色，我们都应该将它隔离出来，避免因为这个单点设备故障，带来的全局影响。
SAN架构中，脱离公共网络，避免非专业人员进行访问，然后为多个授权的Admin设置访问策略。
如果系统部署在一个单独数据中心（一个房间内），我们尽可能用机架隔离每个设备。如果部署在楼层之间，我们尽可能用楼层来隔离每个设备。果是位于两个区域数据中心，那么我们就用区域隔离（在技术允许范围内）。
配置UPS，避免相同设备接入同一个电路中。
监督与通知：
通常在高可用的架构中，故障会自动切换，但是为了避免跟多问题，我们需要设置更多的策略，让Admin及时得到通知。
知识同步：
确保每个Admin对系统了解的信息都是最新的，这些信息包括最新的升级，及最近一次的更改。
（关于此篇我已写完，但不包括再次更新）