类似的，对于系统治理员来说，使用Brocade交换机需要使用专用的串行电缆，需要使用telnet和命名行接口。当建立 Brocade交换机时，系统治理员将会发现没有NAS应用中常用的简单的网络发现机制。

　　一旦所有的SilkWorm交换机被赋予合适的网络地址，可以使用 Brocade的WebTools软件，以可视化方式进行治理和监控， WebTools是驻留在单个交换机中的基于Java的Web应用程序。这些交换机可以通过以太网以out-of-band方式访问，或者通过基于光纤通道的IP协议以in-band方式访问，后者是通过具有以太网连接的主交换机进行的。

　　Brocade的 WebTools的文档中介绍了运行该应用程序需要支持Java的浏览器;正式的系统需求是在 Windows平台上运行Internet EXPlorer，在Solaris平台上使用Netscape Navigator浏览器。此时Java的老问题再次出现：编译一次，调试多次。所以当一些 Java applets在SuSE Linux 9.0的Mozilla 上运行出现故障时，我们并不感到惊异。幸运地是，虽然加载Java classes时速度较慢，我们可以在SuSE上使用Konqueror来运行。

　　我们使用了Brocade的WebTools软件的性能检测功能，来演示一下ISL干线合并(ISL trunking)的效果。在 Dell服务器上我们安装了一个LUN，其是由连接不同的交换机上的初始控制器来提供服务的。当我们使用64KB I/O来运行oblFileLoad时，峰值传输速度为188MBps(8个硬盘阵列)，当打开干线合并功能时，数据传输通过端口 6和7进行，这就形成了连接到nStor阵列的交换机的ISL干线合并，数据传输的平衡效果很好。

　　WebTools 提供了直观的界面，来治理整个架构和配置单个交换机的属性，诸如IP地址，交换机名称，简单网络治理协议(Simple Network Management Protocol，简称SNMP)设置。使用WebTools，治理员可以识别出连接到架构中的设备，升级交换机的固件，治理授权序列号，以便使用可选功能。

　　传统的SAN拓扑是每个交换机之间相互连接成网状结构，这样的安排可以使得在发送设备到目标设备之间传输数据时，在交换机之间的数据包的转跳数达到最小。

　　nStor的StorView可提供可一个直观的，易用的界面。所有系统组件中的重要状态信息可以轻易地获得，同时进行具体的治理和配置也是小菜一碟。

　　在SAN中配置ISL可以减少拆东墙补西墙的问题。系统治理员必须决定交换机中要保留多少用于数据连接的端口，以及多少端口用于连接其他交换机。这个决定定义了“注册比例”，即用于连接设备的总端口数同用于创建ISL所使用的总端口数之比。在一个8口交换机中，保留6个端口用于设备连接，2个端口用于ISL，其注册比例为3比1，这个数字被认为是性能良好的。

　　不幸的是，对于SAN来说，规则并不是显而易见的。在两个交换机之间简单地连接一组端口，并不能自动地把产生一个高带宽的逻辑连接。 多数数据传输在端口到端口的流动过程中将不可避免地降低速度，形成瓶颈。为了防止这种现象的发生，Brocade交换机中提供了可实现特定的干线合并的固件，以便在相邻的端口集合中实现负载平衡，以便形成单一的逻辑干线。这个能够提供负载平衡的干线合并功能，并不便宜。本案例中，Brocade交换机添加了合并功能，价格就增加了$3,800美元，使得交换机总体上的开销达到 $10,000美元。 (编者：该测评是在今年三月进行的，反映的是当时的市场价。)

　　一旦我们的架构开始工作了，就可转向存储阵列的配置。nStor系统的建立过程可以独立于SAN，以传统方式进行：用一根串行电缆连接，运行VT100终端仿真程序。更为有趣的是，nStor的基于主机的客户/服务器软件StorView，可以运行在 Linux和Windows两种平台上。

　　StorView服务器模块作为后台进程运行。其任务之一是在in-band (Fibre Channel)和out-of-band (LAN)连接方式下，使用multi-casting技术，来自动发现所有已经安装的nStor存储系统。为了同StorView GUI进行通信，服务器组件使用了Apache 2.0，我们把Apache 2.0安装在Windows服务器上。除非IIS正在监听端口 9292，否则Apache不会同现有的IIS发生冲突。结果是，治理员可在能够访问到nStor server的任何系统上运行StorViewde GUI。