在光纤通道结构上正确放置设备
我们正在为我们的光纤通道架构获得一对新的8Gb交换机。 这是一件好事，因为我们的主要数据中心的端口已经用完了，而且至less可以让我们在两个数据中心之间运行至less一个8Gb ISL。
我们的两个数据中心距离光纤运行约3.2公里。 几年来，我们已经获得了稳定的4Gb服务，并且我也抱有很高的期望，能够支持8Gb。
我目前正在弄清楚如何重新configuration我们的结构来接受这些新的交换机。 由于几年前的成本决定，我们没有运行完全独立的双环路结构。 完全冗余的成本被认为比交换机故障的不太可能的停机时间更昂贵。 那个决定是在我的时代之前做出的，从那以后事情没有多大改善。
面对交换机故障（或FabricOS升级），我想借此机会使我们的结构更具弹性。
以下是我正在考虑的布局图。 蓝色的项目是新的，红色的项目是现有的链接，将（重新）移动。
FibreChannel digram http://sysadmin1138.net/images/fabric-option.png
红色箭头线是当前的ISL交换机链路，两个ISL来自同一个交换机。 EVA6100目前连接到两个具有ISL的16/4交换机。 新的交换机将允许我们在远程DC中有两个交换机，其中一个远程ISL正在移动到新交换机。
这样做的好处是，每台交换机与另一台交换机的距离不超过2跳，两个EVA-复制关系的EVA4400之间相距1跳。 图表中的EVA6100是一个较旧的设备，最终会被replace，可能还有另外一台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个带有2个LTO4磁带机的LTO4磁带库。 每个驱动器都有自己的光纤端口。
- 备份服务器（不在此列表中）后台处理
目前，ESX集群可以容忍多达3个，也许4个主机closures，然后再开始closures虚拟机。 令人高兴的是，一切都有MPIO打开。
目前的4Gb ISL链路还没有接近饱和，我注意到了。 这可能会改变两个EVA4400的复制，但至less有一个ISL将是8Gb。 看看我从EVA4400-AI中获得的性能，我很确定，即使有复制stream量，我们也很难跨越4Gb线路。
4节点文件服务集群在SAN1SW4上可以有两个节点，在SAN1SW1上可以有两个节点，因为这会使两个存储arrays都跳一跳。
10个ESX节点我有点头疼。 在SAN1SW4上有三个，在SAN1SW2上有三个，在SAN1SW1上有四个，是一种select，我很乐意听到关于布局的其他意见。 其中大部分都具有双端口FC卡，所以我可以双重运行几个节点。 不是所有的 ，但足以让一个单一的交换机失败，而不是所有的一切。
两个MS-SQL盒子需要在SAN1SW3和SAN1SW2上，因为它们需要靠近主存储器，而db-export性能不那么重要。
LTO4驱动器目前位于SW2上，距离其主拖缆2跳，所以我已经知道这是如何工作的。 那些可以留在SW2和SW3。
我不希望将图表的下半部分作为完全连接的拓扑，因为这会将我们的可用端口数从66减less到62，而SAN1SW1将是25％的ISL。 但如果强烈build议我可以走这条路。
更新：可能会有用的一些性能数字。 我有他们，我只是间隔，他们是有用的这种问题。
上图中的EVA4400-A具有以下function：
- 在工作date间：
- 在文件服务器群集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 /秒之间。 在文件服务群集上的ShadowCopy快照（〜240MB / s）期间发生峰值MB / s，并持续不到一分钟。
- 在夜间，Exchange Online Defrag从凌晨1点运行到凌晨5点，将I / O Ops输出到7800（接近侧面速度，随机访问主轴数量）和70MB / s。
我将不胜感激您的任何build议。
抱歉耽搁了。
看看你有什么和你想达到什么，我有几个想法，这是一个很好的图片第一…
- 现在在站点之间使用8Gbps链路似乎毫无意义 – 原因是受限于远程4400上的4Gbps端口，您已经有了稳定的4Gbps，而且可用带宽远高于实际使用要求 – 今天，把24×8交换机之一放在那里似乎是一种浪费。 我会在远程站点使用两个16x4Gb交换机。
- 我很想用新的24×8交换机作为主要的“核心”交换机 – 大部分stream量是从服务器到6100的，而新的盒子会快得多。 这种方式，你应该看到一些小的性能增益，因为新的交换机具有更大的缓冲区和更低的延迟，此外，你可以select哪些服务器移动到8Gb，如果你喜欢，当换出6100时4600有原生的8Gb端口，但这还不是正式的））。
- 然后，我们进入devise的一部分，我们有两个select; 保留或丢弃两个16x4Gb“中间交换机” – 纯粹基于端口数量。 基本上，如果您使用24×8交换机作为核心盒，您只有3个备用端口（18个服务器使用18个，另外2个使用6100和1个ISL链路，等于21个使用）。 您可以将本地4400连接到24×8交换机，从而为您的磁带机留下1个空闲端口，但这会给您留下零空闲端口。 我试图做的是使用两个16x4Gb的中间交换机作为辅助本地交换机来处理本地4400和磁带驱动器，或者可能的话处理站点间的ISL链路，如果你愿意的话 – 虽然你将有端口免费的24x8Gb交换机直接从那里做，如果你愿意 – 我没有显示，因为他们真的非常相似。
所以这就是我的想法 – 有一些调整，但我的一般想法在那里 – 请随时回到我的任何澄清。