Adrian K Asked: 2010-03-23 12:16:33 +0800 CST2010-03-23 12:16:33 +0800 CST 2010-03-23 12:16:33 +0800 CST SAN 典型 MTBF 772 我们在工作中的项目中使用 SAN，关于从技术上讲它是单点故障这一事实存在一些争议。似乎没有人有任何硬数据。 所讨论的 SAN 是单个物理盒，但具有内部冗余组件（抱歉 - 不确定 3 它具有什么级别的 RAID，但我可以找到）。 SAN 的典型 MTBF 是多少？PM 将其在项目风险登记册上记录为“相当普遍”——我从未听说过 SAN 出现故障，但我没有任何统计数据显示它的可能性有多大。 有没有人有任何有用的信息？ storage-area-network 4 个回答 Voted Chopper3 2010-03-23T12:26:07+08:002010-03-23T12:26:07+08:00 这真的一点也不常见，事实上我想说它几乎和整个房间断电一样常见 - 好像它们被正确配置和维护一样，断电是失去完整 SAN 盒的唯一真正方式。 也就是说，您需要确保它们由两个独立的 UPS 供电，具有双控制器、双开关、多种布线的光纤，并且您需要规划您的机架/阵列布局以应对整个机架的损耗。如果你这样做了，那么你就可以在没有第二个站点的情况下得到尽可能好的覆盖。 Best Answer icky3000 2010-03-23T13:43:22+08:002010-03-23T13:43:22+08:00 在不知道确切的 SAN 以及它是如何配置和管理的情况下，这个问题的任何答案都是猜测。我这么说有两个原因： 一些 SAN 比其他的更好。我们有一台古老的 EMC CX500，它已经生产了 7 年，没有出现过任何故障。我们的戴尔 MD3000i 一直有问题。你得到你所付出的。 即使是管理或配置不佳的最佳 SAN，正常运行时间也会很短。我见过一个愚蠢的管理员导致价值 200 万美元的 EMC Symmetrix 在一个月内失败了两次。在我们雇用他之前，它连续近四年没有出现任何问题。 jldugger 2010-03-23T12:59:14+08:002010-03-23T12:59:14+08:00 自今年年初以来，我们遇到了各种各样的麻烦，以至于“下一个可用的维护窗口”是 SAN 停机的委婉说法。如果你听销售，他们是各种可靠的。在实践中，您不具备在投入生产之前对 SAN 进行折磨测试的专业知识，因此在高需求时暴露您的配置问题取决于命运之箭。 与实际的磁盘驱动器和其他硬件相比，极其复杂的 SAN 软件或配置失败是一个未知数。这最终意味着您可以根据需要添加尽可能多的物理冗余，但由于它们都运行相同的损坏软件，您仍然会遇到单点故障。 也就是说，我们似乎运行得更顺畅了，因为我们把整个事情都拿下来了一个固件补丁。我们的 SAN 修复总结报告让我担心，SAN 仍然有太多神奇的想法。 damorg 2010-03-23T13:57:48+08:002010-03-23T13:57:48+08:00 正如其他人所指出的，正确配置和规范的存储后端（冗余控制器、电源、开关等）出现故障并不常见。我会认真地要求总理详细讨论将其列为共同风险的想法。 从技术上讲，将“单点故障”记录为风险评估的一部分总是值得的，但是对于 HA 配置中的完全冗余存储是否代表“单点故障”，需要进行认真的讨论。它可能会或可能不会取决于您的组织和应用程序。如果是单点故障，则还值得讨论整个数据中心服务丢失的故障场景（因为冗余的 HA SAN 不太可能完全失败，从而使其他所有设备都处于可用状态）。 处理这些场景非常昂贵……从冗余数据中心开始，以及诸如地理上延伸的结构、多个完全冗余的 SAN、存储部分的“实时复制”之类的东西。需要这些东西的场景和应用程序并不常见。 只是我个人的经验：我遇到了导致孤立问题的固件和控制器错误。在极少数情况下，我什至遇到了一个错误，导致主动-主动对中的一个控制器进行转储并触发故障转移。这并没有导致停机。 我听说过噩梦般的场景，例如控制器脑裂或其他导致整个阵列崩溃的情况，但这种情况很少见，而且永远不能确定这不是由于人为错误或配置错误造成的。（人为错误和配置错误是个大问题……我并不是要轻视它们……但它们不是与单个 SAN 相同意义上的“spofs”。）
这真的一点也不常见，事实上我想说它几乎和整个房间断电一样常见 - 好像它们被正确配置和维护一样，断电是失去完整 SAN 盒的唯一真正方式。
也就是说，您需要确保它们由两个独立的 UPS 供电，具有双控制器、双开关、多种布线的光纤，并且您需要规划您的机架/阵列布局以应对整个机架的损耗。如果你这样做了，那么你就可以在没有第二个站点的情况下得到尽可能好的覆盖。
在不知道确切的 SAN 以及它是如何配置和管理的情况下，这个问题的任何答案都是猜测。我这么说有两个原因：
一些 SAN 比其他的更好。我们有一台古老的 EMC CX500，它已经生产了 7 年，没有出现过任何故障。我们的戴尔 MD3000i 一直有问题。你得到你所付出的。
即使是管理或配置不佳的最佳 SAN，正常运行时间也会很短。我见过一个愚蠢的管理员导致价值 200 万美元的 EMC Symmetrix 在一个月内失败了两次。在我们雇用他之前，它连续近四年没有出现任何问题。
自今年年初以来，我们遇到了各种各样的麻烦，以至于“下一个可用的维护窗口”是 SAN 停机的委婉说法。如果你听销售，他们是各种可靠的。在实践中，您不具备在投入生产之前对 SAN 进行折磨测试的专业知识，因此在高需求时暴露您的配置问题取决于命运之箭。
与实际的磁盘驱动器和其他硬件相比，极其复杂的 SAN 软件或配置失败是一个未知数。这最终意味着您可以根据需要添加尽可能多的物理冗余，但由于它们都运行相同的损坏软件，您仍然会遇到单点故障。
也就是说，我们似乎运行得更顺畅了，因为我们把整个事情都拿下来了一个固件补丁。我们的 SAN 修复总结报告让我担心，SAN 仍然有太多神奇的想法。
正如其他人所指出的，正确配置和规范的存储后端（冗余控制器、电源、开关等）出现故障并不常见。我会认真地要求总理详细讨论将其列为共同风险的想法。
从技术上讲，将“单点故障”记录为风险评估的一部分总是值得的，但是对于 HA 配置中的完全冗余存储是否代表“单点故障”，需要进行认真的讨论。它可能会或可能不会取决于您的组织和应用程序。如果是单点故障，则还值得讨论整个数据中心服务丢失的故障场景（因为冗余的 HA SAN 不太可能完全失败，从而使其他所有设备都处于可用状态）。
处理这些场景非常昂贵……从冗余数据中心开始，以及诸如地理上延伸的结构、多个完全冗余的 SAN、存储部分的“实时复制”之类的东西。需要这些东西的场景和应用程序并不常见。
只是我个人的经验：我遇到了导致孤立问题的固件和控制器错误。在极少数情况下，我什至遇到了一个错误，导致主动-主动对中的一个控制器进行转储并触发故障转移。这并没有导致停机。
我听说过噩梦般的场景，例如控制器脑裂或其他导致整个阵列崩溃的情况，但这种情况很少见，而且永远不能确定这不是由于人为错误或配置错误造成的。（人为错误和配置错误是个大问题……我并不是要轻视它们……但它们不是与单个 SAN 相同意义上的“spofs”。）