Talkback
E-mail
Printer Friendly
Reprints
Whatever you think of the naming convention Brocade follows, its QoS mechanism is a very simple and efficient way to set your applications in the proper pecking order and make the best use of the bandwidth available, however limited or abundant it may be.
|
SAN security
Naturally, a larger SAN installation -- such as the result of consolidating multiple fabrics with DCX -- is more vulnerable
than smaller environments to both trivial errors and security breaks. If you want to keep human errors to a minimum or are
concerned about the possibility of someone spoofing a WWN (worldwide name) to connect a rogue device to the network, the DCX's
Fabric OS offers a system of policies that can bring some additional protection.
For example, you can define policies to control the connection of storage targets, switches, and hosts, allowing access only when a device, identified by its WWN, is connected to a specific port.
This screen image shows the commands to define a DCC (Device Connection Control) policy for each of the two devices on ports 133 and 134 and to make those two policies active.
For a large installation, manually setting a policy for each port could be a long and tedious process, but for initial deployments, a similar command can automatically create a policy from an existing configuration that links each active port to the WWN of its connected device.
When a DCC policy is active, trying to connect a device with a different WWN will trigger an error message and access to the port will be denied.
The DCX security policies are not foolproof. Obviously anyone with access to an admin account with proper credentials can modify them, but the system offers an easy-to-audit log of possible violations, which can simplify monitoring and enforcement of those policies.
Strong fences
The Virtual Fabric feature of the Fabric OS is a perfect complement to device connection policies. Virtual Fabric is neither
a new nor mandatory feature, but its implementation becomes nearly indispensable in the large, consolidated networks built
on DCX.
In essence, with Virtual Fabric you can divide the physical fabric into isolated administrative domains (the analogy with Cisco's VSANs is too good to pass up), creating software borders that shelter each domain from its neighbors.
Another nice feature of Virtual Fabric is that the implementation of ADs (administrative domains) is granular and nondisruptive. For example, you can migrate all or part of an existing zone to a new AD and assign a device to multiple ADs.
In the large, consolidated environments that the DCX makes possible, the ability to assign separate administrative duties for an individual AD is also a great feature, because separation of duties facilitates independent domain updates and confines the impact of each change to that AD.
To prove that claim, I copied the same zone to two ADs, then assigned a different admin account to each. To create some traffic, I started Iometer on one host connected to the first domain. Next, to simulate a conflicting configuration change, I logged in as admin for the second domain and removed that host port from the zone.
Mario Apicella is senior analyst of the InfoWorld Test Center.
