过去为美国政府开发气象卫星时，曾经使用过一个称为故障模式和效果分析(FMEA：failure mode and effects analysis)的框架。该架构用来分析系统的潜在故障模式，并计算预期结果。
FMEA是一项非常复杂的工作，但是对于一个价值一百亿美元的卫星来讲是非常必要的。任何一个被疏忽的子系统中相对很小的故障都可能会导致整个卫星崩溃。
但是这和虚拟化技术和存储区域网络(SAN：Storage Area Network)的关系何在呢？因为当前的虚拟化技术异常地依赖集中化存储架构。动态迁移和vMotion都要求集中化SAN完成虚拟机的故障恢复和负载平衡。
SAN：虚拟基础架构的关键所在
由于这个需求的存在，几乎所有的虚拟工作环境都必须部署SAN基础架构，但是同时也增加了副作用和SAN可能出现故障带来的费用。为了说明这个观点，首先需要理清楚虚拟基础架构中每个组件间的相互关系。在每个组件和其所依赖的组件之间连线，直到找到所有组件的依赖关系，就可以看到画出了整个依赖关系树(最终的结果就和FMEA有点相似)。
可以看到所有的箭头最终都指向SAN基础架构。因此SAN基础架构的正常运行时间即使不是100%，也必须是非常接近100%。任何存储设备的宕机，尤其是扩展宕机，都会给整个虚拟化工作环境带来灾难性的失败，因为这样的情况出现会强迫所有的虚拟机、服务器和应用程序停机。
这是非常严重的情况，从混乱状态全部重启是非常困难的。在这些资源都不可用的情况下，服务器和应用程序之间相互关联的建立很可能需要一个非常耗时的启动过程。
存储设备厂商也意识到这个问题了。去年，日立公司宣布其日立高可用性管理器(Hitachi High Availability Manager)能够保证存储设备全时间运行。DataCore在其合作伙伴会议上宣布存储虚拟化软件也可以实现全时间正常运行。EMC、HP和Dell这些公司的高端解决方案也都可以提供零宕机时间选项或者是保证在特定SAN操作中保证零宕机时间。甚至基于软件的SAN厂商StarWind软件公司也通过active/active，两节点存储集群开发有存储复制功能的零宕机时间。
但是可以通过技术和技能的结合达到存储设备的100%可用，这需要SAN电源、磁盘驱动、存储连接、存储处理器的多个层面冗余，甚至存储节点的完全冗余(例如，HP的模式化存储解决方案)。给辅助、现场或者非现场SAN增加存储复件可以进一步保护数据。
最后一个问题是，虚拟工作环境可以接受的存储设备故障时间是多少？即使有可以接受的时间，肯定也不多。如果可能的话，最好设计多层面的冗余。另外，在购买SAN基础架构之前，最好咨询商家基础架构的弱点所在。一年之内，用户肯定不希望看到SAN故障导致整个计算基础架构瘫痪。
