我们正在为光纤通道结构购买一对新的8Gb交换机。这是一件好事，因为我们的主数据中心的端口用完了，这将使我们能够在两个数据中心之间至少运行一个8Gb ISL。
光纤运行时，我们的两个数据中心相距约3.2公里。几年来，我们一直在获得可靠的4Gb服务，我非常希望它也能够维持8Gb。
我目前正在研究如何重新配置我们的结构以接受这些新的交换机。由于成本决定，几年前，我们没有运行完全独立的双环结构。完全冗余的成本被认为比不大可能发生的交换机故障停机成本高。这个决定是在我的时间之前做出的，自那时以来，情况并没有太大改善。
我想借此机会使我们的结构在发生交换机故障（或FabricOS升级）时更具弹性。
这是我正在考虑的布局图。蓝色项目是新的，红色项目是将被（删除）的现有链接。
（来源：sysadmin1138.net）
红色箭头线是当前ISL交换机链接，两个ISL来自同一交换机。EVA6100当前已连接到具有ISL的两个16/4交换机。新的交换机将使我们能够在远程DC中拥有两个交换机，其中一些远程ISL正在迁移到新的交换机。
这样做的好处是，每个交换机与另一个交换机的跳数不超过2跳，而两个将以EVA复制关系的EVA4400彼此相距1跳。图表中的EVA6100是较旧的设备，最终可能会替换为另外的EVA4400。
图表的下半部分是我们大多数服务器所在的位置，我对确切的位置有所担忧。需要去那里：
- 10个VMWare ESX4.1主机
- 访问EVA6100上的资源
- 一个故障转移群集（文件服务器群集）中的4台Windows Server 2008服务器
- 访问EVA6100和远程EVA4400上的资源
- 第二个故障转移群集中的2台Windows Server 2008服务器（黑板内容）
- 访问EVA6100上的资源
- 2个MS-SQL数据库服务器
- 访问EVA6100上的资源，每晚DB导出到EVA4400
- 1个LTO4磁带库和2个LTO4磁带驱动器。每个驱动器都有自己的光纤端口。
- 备份服务器（不在此列表中）假脱机到它们
目前，ESX群集最多可以容忍3个（可能是4个）主机关闭，然后才必须开始关闭VM的空间。幸运的是，所有东西都已打开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将是25％的ISL。但是，如果强烈建议我走那条路。
更新：一些性能数字可能会有用。我有它们，我只是将它们隔开来解决此类问题。
上图中的EVA4400-A具有以下功能：
- 在工作日内：
- 在文件服务器群集ShadowCopy快照期间，I / O操作的平均次数低于1000，峰值达到4500次（持续约15-30秒）。
- MB / s通常保持在10-30MB的范围内，在ShadowCopies期间峰值可达到70MB和200MB。
- 在夜晚（备份）时，它的踏板速度很快：
- I / O操作平均约为1500，在数据库备份期间峰值可达5500。
- MB / s的变化很大，但在几个小时内可以运行约100MB，而在SQL导出过程中则以惊人的速度在约15分钟内运行300MB / s。
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的速度泵入生产线。
如果您有任何建议，我将不胜感激。
