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

我们正在为我们的光纤通道架构获得一对新的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交换机直接从那里做,如果你愿意 – 我没有显示,因为他们真的非常相似。

所以这就是我的想法 – 有一些调整,但我的一般想法在那里 – 请随时回到我的任何澄清。