【IT168 专稿】博科DCX Backbone交换机是博科不久前刚刚发布的光纤网络产品，2周前我们曾经发布过关于该产品评测文章的第一部分，参考：博科DCX Backbone交换机深入评测（一），本文接续上篇，继续分析关于博科DCX Backbone交换机的评测结果。

数据中心安全性

    我们整个数据中心的安全也是一个重要的问题。总的来说，如果数据中心内的结构越复杂，就容易受到攻击，或者出现内部问题。如果你希望将人为错误最小化，DCX OS也提供了一系列的方法来避免这些问题。比如说，你可以定义一个连接政策，来控制对存储目标、交换机、主机的访问。具体来说，该政策可以定义只有当某一设备的WWN被认证了之后，才允许连接到特定端口。这样就避免了很多潜在问题。

    下面的图表显示定义DCC政策的命令，该政策为133和134端口的设备定义了政策。

    该项功能看起来不错，但是你的数据中心如果包括了很多设备，那么手动一项一项的来设置端口政策，必然将耗费你大量的时间，而且可能导致疏忽等错误。这时，我们可以设置命令，来自动建立政策。一旦创建了政策，而且在DCC政策激活之后，那么采用不同WWN来连接的设备，就将引发一条错误信息，而且端口将被拒绝访问。

    DCX安全策略也并不是一成不变。显然，任何有权使用admin账户的人，如果有相应权限，都可以修改政策，但是系统还是可以提供简单的记录审核，来防止一些可能的破坏或者错误。

    说到安全和管理工具，OS的虚拟架构(Virtual Fabric)功能是一个非常好的设备连接政策补充。虚拟架构也不是一个新的功能，只是最近经常被部署在较大的、集成的DCX网络中。

大规模虚拟架构功能

    实际上，使用虚拟架构(Virtual Fabric)功能，你可以将物理结构分离到独立的管理域中，并且创建软件边界来对其邻居隐藏每个域。虚拟架构的另一个优点，在于管理域AD (administrative domains)是不间断的。比如说，你可以将已经存在的zone迁移到新的AD，也可以分配设备到多个AD。

    在大的集成环境，DCX可以为AD分配管理任务，这有重要的意义。因为DCX加速了独立域更新，限制了各种改变对AD的影响。

    我做了一个小例子：我拷贝了同一Zone到2个AD，然后为每个AD分配了不同的管理帐户。而后，我还制造了一些流量，我在连接到第一个域的主机上运行了IOmeter。下一步，为了模拟冲突配置，我以管理员账户联机第二个域，而后从Zone移除主机端口。之后，我转回了第一个域的主机：IOmeter还在运行，并没有受到并行域的影响。

    通过独立域共享设备，更可能发生在存储目标，而不是主机端口。不管怎样，那些重叠的域是相互无关联的，因为任何单一管理域中变化的影响都超不出自己的范围。

与McData的互操作性测试

    我评估DCX中的最后一项任务，比起别的评估可能很枯燥。这项评估是在于一台交换机连接到DCX，然后考察连接到该交换机的设备可用情况。通常，连接一台交换机到架构中，是一项很无聊的、可以预测结果的操作，但是我们的交换机是一台McData 6140，在本地模式下工作，这样，我们的评估就有了意义。

    因为McData用户都明白，本地模式交换机连接到博科架构，在博科并购McData之前是不可能的。在考察了它们的配合工作之后，我很高兴这种协作成了可能，至少McData 6140型号可以协作。但是，当连接到较早的设备时，还是有一些限制。例如，以往的协同模式现在很少使用，而被两种新模式替代：McData本地模式，和McData开放模式。另外，根据博科的说法，这两种模式只在连接设备运行Fabric OS 6 和 EOS 9.6.时可用。但即便有这些限制，McData的用户还是获得了很多便利。

总结：

    总的来说，DCX是一款非常强大的交换机。但是暂时我还不能对其价格高低做评估，因为新品还没有报价。不过估计报价肯定不会便宜。对于我而言，QoS 和 DCX最大的吸引力是加强了安全防范。一些新的DCX智能化功能未来会陆续出现，让我们共同期待。