我们正在为光纤通道结构购买一对新的 8Gb 交换机。这是件好事，因为我们的主要数据中心的端口已经用完了，这将使我们在两个数据中心之间至少运行一条 8Gb ISL。
我们的两个数据中心在光纤铺设时相距约 3.2 公里。几年来，我们一直享受着稳定的 4Gb 服务，我非常希望它也能维持 8Gb。
我目前正在研究如何重新配置我们的架构以接受这些新交换机。由于几年前的成本决策，我们不是运行完全独立的双环结构。完全冗余的成本被认为比交换机故障导致的停机时间更昂贵。这个决定是在我上任之前做出的，从那时起情况就没有太大改善。
我想借此机会让我们的结构在交换机故障（或 FabricOS 升级）时更具弹性。
这是我所设想的布局图。蓝色项目是新的，红色项目是将被（重新）移除的现有链接。
（来源：系统管理员1138.net）
红色箭头线是当前 ISL 交换机链路，两个 ISL 都来自同一交换机。EVA6100 当前连接到两个具有 ISL 的 16/4 交换机。新交换机将允许我们在远程 DC 中拥有两个交换机，其中一个长距离 ISL 正在移动到新交换机。
这样做的好处是，每个交换机与另一个交换机之间的跳数不超过 2，而两个 EVA4400（将处于 EVA 复制关系）之间的跳数为 1。图表中的 EVA6100 是较旧的设备，最终将被替换，可能还会被另一个 EVA4400 替换。
图表的下半部分是我们大多数服务器所在的位置，我对确切的放置位置有些担心。需要在其中输入的内容：
- 10 台 VMWare ESX4.1 主机
- 访问 EVA6100 上的资源
- 一个故障转移群集（文件服务器群集）中的 4 台 Windows Server 2008 服务器
- 访问 EVA6100 和远程 EVA4400 上的资源
- 第二个故障转移群集中的 2 个 Windows Server 2008 服务器（Blackboard 内容）
- 访问 EVA6100 上的资源
- 2 个 MS-SQL 数据库服务器
- 访问 EVA6100 上的资源，并将夜间数据库导出到 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 卡，所以我可以同时运行几个节点。不是所有的人但足以让一个开关发生故障而不会毁掉所有东西。
两个 MS-SQL 盒需要运行在 SAN1SW3 和 SAN1SW2 上，因为它们需要靠近其主存储，并且 db-export 性能不太重要。
LTO4 驱动器目前位于 SW2 上，距离其主流驱动器有 2 个跳数，因此我已经知道它是如何工作的。它们可以保留在 SW2 和 SW3 上。
我不希望将图表的下半部分设为全连接拓扑，因为这会将可用端口数从 66 个减少到 62 个，并且 SAN1SW1 会占 ISL 的 25%。但如果强烈建议这样做，我可以采用这种方式。
更新：一些性能数据可能会有用。我有它们，我只是觉得它们对这类问题有用。
上图中的 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 Ops 以 7800（接近此数量主轴的随机访问的最快速度）和 70MB/s 的速度输送到生产线。
我将非常感激您的任何建议。
答案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 交换机上有可用的端口，如果您愿意的话，可以直接从那里执行此操作 - 我没有展示两者，因为它们非常相似。
这就是我的想法 - 虽然有些地方需要调整，但我的总体想法是这样的 - 如果有任何疑问，请随时向我咨询。