在光纤通道结构上正确放置设备

Question

我们为我们的光纤通道结构准备了一对新的 8Gb 交换机。这是一件好事，因为我们的主数据中心的端口已经用完了，这将使我们能够在两个数据中心之间运行至少一个 8Gb ISL。

当光纤运行时，我们的两个数据中心相距约 3.2 公里。几年来，我们一直在获得稳定的 4Gb 服务，我非常希望它也能维持 8Gb。

我目前正在研究如何重新配置​​我们的结构以接受这些新交换机。由于几年前的成本决定，我们没有运行完全独立的双回路结构。完全冗余的成本被认为比不太可能的交换机故障停机时间更昂贵。那个决定是在我之前做出的，从那时起事情并没有太大改善。

我想借此机会使我们的结构在遇到交换机故障（或 FabricOS 升级）时更具弹性。

这是我正在考虑的布局图。蓝色项目是新的，红色项目是将被（重新）删除的现有链接。

_{（来源：sysadmin1138.net）}

红色箭头线是当前的 ISL 交换机链路，两个 ISL 都来自同一交换机。EVA6100 当前连接到两个具有 ISL 的 16/4 交换机。新交换机将允许我们在远程 DC 中拥有两个交换机，其中一些远程 ISL 正在迁移到新交换机。

这样做的好处是每台交换机与另一台交换机的距离不超过 2 跳，并且两个 EVA4400 之间的距离为 1 跳，这两个 EVA4400 将处于 EVA 复制关系。图表中的 EVA6100 是一个较旧的设备，最终将被替换，可能会被另一个 EVA4400 替换。

图表的下半部分是我们大多数服务器所在的位置，我对确切位置有些担忧。里面需要什么：

• 10 台 VMWare ESX4.1 主机
  • 访问EVA6100资源
• 一个故障转移群集（文件服务器群集）中的 4 个 Windows Server 2008 服务器
  • 访问EVA6100和远程EVA4400上的资源
• 第二个故障转移群集中的 2 个 Windows Server 2008 服务器（Blackboard 内容）
  • 访问EVA6100资源
• 2 个 MS-SQL 数据库服务器
  • 访问 EVA6100 上的资源，每晚 DB 导出到 EVA4400
• 1 个 LTO4 磁带库，带有 2 个 LTO4 磁带机。每个驱动器都有自己的光纤端口。
  • 备份服务器（不在此列表中）将它们假脱机

目前，在我们必须开始关闭虚拟机以腾出空间之前，ESX 集群最多可以容忍 3 台，也许是 4 台主机停机。令人高兴的是，一切都开启了 MPIO。

目前的 4Gb ISL 链接还没有达到我注意到的饱和状态。这可能会随着两个 EVA4400 的复制而改变，但至少其中一个 ISL 将是 8Gb。看看我从 EVA4400-A 中获得的性能，我非常肯定，即使有复制流量，我们也很难跨越 4Gb 线路。

4 节点文件服务集群可以在 SAN1SW4 上有两个节点，在 SAN1SW1 上有两个节点，因为这将使两个存储阵列相距一跳。

10 个 ESX 节点让我有些头疼。三个在 SAN1SW4 上，三个在 SAN1SW2 上，四个在 SAN1SW1 上是一个选项，我很想听听关于布局的其他意见。其中大多数都有双端口 FC 卡，所以我可以双运行几个节点。不是全部，但足以允许单个开关失败而不会杀死所有东西。

SAN1SW3 和 SAN1SW2 这两个 MS-SQL 盒子需要继续使用，因为它们需要靠近它们的主存储并且 db-export 性能不太重要。

LTO4 驱动器目前在 SW2 上，距离主流媒体有 2 跳，所以我已经知道它是如何工作的。那些可以保留在 SW2 和 SW3 上。

我不想让图表的下半部分成为全连接拓扑，因为这会将我们的可用端口数从 66 减少到 62，而 SAN1SW1 将是 25% 的 ISL。但如果强烈推荐我可以走那条路。

---

更新：一些可能有用的性能数据。我有它们，我只是指出它们对此类问题很有用。

上图中的 EVA4400-A 执行以下操作：

• 工作日期间：
  • 在文件服务器集群 ShadowCopy 快照（持续约 15-30 秒）期间，I/O 操作平均低于 1000，峰值达到 4500。
  • MB/s 通常保持在 10-30MB 范围内，在 ShadowCopies 期间峰值高达 70MB 和 200MB。
• 在夜间（备份）是真正快速踩踏板的时候：
  • I/O 操作平均约为 1500，在数据库备份期间峰值高达 5500。
  • MB/s 变化很大，但在几个小时内运行大约 100MB，并在 SQL 导出过程中以 300MB/s 的速度运行大约 15 分钟。

EVA6100 要忙得多，因为它是 ESX 集群、MSSQL 和整个 Exchange 2007 环境的所在地。

• 白天 I/O 操作平均约为 2000，频繁峰值高达 5000 左右（更多数据库进程），MB/s 平均在 20-50MB/s 之间。MB/s 峰值发生在文件服务集群上的 ShadowCopy 快照期间 (~240MB/s)，持续时间不到一分钟。
• 在夜间，从凌晨 1 点到凌晨 5 点运行的 Exchange Online Defrag 将 I/O 操作以 7800（接近使用此数量轴的随机访问的侧翼速度）和 70MB/s 的速度泵送到线路。

---

如果您有任何建议，我将不胜感激。

Answer 1

抱歉耽搁了。

看看你有什么以及你想要实现什么，我有一些想法，首先这是一张漂亮的照片......

• 现在似乎没有必要在站点之间使用 8Gbps 链接 - 原因是您受到远程 4400 上 4Gbps 端口的限制，您已经拥有稳定的 4Gbps 并且可用带宽远高于实际使用要求- 今天，将其中一个 24x8 交换机放在那里似乎是一种浪费。我会在远程站点使用两个 16x4Gb 交换机。
• 我很想使用新的 24x8 交换机作为您的主要“核心”交换机——您的大部分流量是从服务器到 6100，而新的盒子会快得多。通过这种方式，您应该会看到一些小的性能提升，因为新交换机具有更大的缓冲区和更低的延迟，而且您可以根据需要选择哪些服务器移动到 8Gb，换掉 6100 时也是如此（ 4600 具有原生 8Gb 端口，但这还不是官方的 ;))。
• 然后我们进入设计的一部分，我们有两个选择；保留或丢弃两个 16x4Gb '中间开关' - 纯粹基于端口数。基本上，如果您使用 24x8 交换机作为核心盒，您只有 3 个备用端口（因为您将 18 个用于 18 个服务器，加上 2 个到 6100 和一个 ISL 链接，等于使用了 21 个）。你可以将本地 4400 连接到 24x8 交换机，为您的磁带驱动器留出 1 个空闲端口，但您的空闲端口为零。我想做的是使用两个 16x4Gb 的“中间交换机”作为辅助本地交换机来处理本地 4400 和磁带驱动器，或者如果您愿意，也可以处理站点间 ISL 链接 - 尽管您将拥有端口如果您愿意，可以在 24x8Gb 交换机上免费使用，直接从那里执行此操作 - 我没有显示两者，因为它们非常相似。

所以这就是我的想法 - 有一些调整需要进行，但我的一般想法在那里 - 随时回来给我任何澄清。