Issues with XSAN...Anyone Care to comment?
1. I believe there is an obvious Bug with the XSAN Admin Application when setting up a 'client-only' (non-controller) via the GUI.
Scenario: After having established a functional dedicated Xserve G5 MetaData Controller as well as establishing a dedicated XServe G4 Backup MetaData Controller as members on a private GbEthernet Network, as well as connected to our Public LAN/Intranet, upon trying to add an additional host as a 'Client-Only' to the private GbEthernet XSAN network, the option to force the client to 'talk' to the SAN over the private network is not available to choose from. It is grayed out and non selectable. It defaults to our Public LAN/Intranet network which causes the volumes to disconnect erratically. I have tried setting the network ports in different priority settings and neither setting resolve the problem. The only way I see currently to force an intended 'client-only' connection is to change the setting to a 'Controller' and setting the Priority to 'LOW' and having it participate on the now selectable private GbEthernet network.
XSAN MDC Settings = Controller Priority 'HIGH' Public Ethernet: 172.16.1.81 Private Ethernet: 192.168.10.1
XSAN Backup MDC Settings = Controller Priority 'MEDIUM' Public Ethernet: 172.16.1.60 Private Ethernet: 192.168.10.2
XSAN Host Client Setting = Client (Grayed out option for popup menus to select private network address) Public Ethernet: 172.16.1.71 Private Ethernet: 192.168.10.3
There needs to be a way to bind the 'Client-Only' type XSAN host to the Private Network which there currently is not. Unless I am misinterpreting the configurations this is a severe problem that I have seen others make mention of on discussion boards, both on Apple's website as well as on sites that focus on this XSAN product.
2. I believe there is a definite oversight in the Admin GUI application when it comes to assigning LUNS to storage pools to create XSAN volumes. It does not disable used LUNS when a multi-SAN storage fabric exists.
Scenario: I have setup two separate independent SAN's that share the same Fiber Channel Switch Fabric. I have not setup any FC Switch Segmenting to isolate the Storage so both SAN's see all the LUNs available. I have two separate Private MetaData Networks to handle the MetaData traffic but I have discovered that when setting up a new volume through the XSAN Admin Application, if a LUN has already been used in a pre-existing Pool it is still available to select to add to a separate SAN's Storage Pool which can have instant impact or lead to instant data loss. This forces the System Administrator to manually keep track of each LUN used for each separate SAN. I believe this to be a bug. I would hope that the used LUN, regardless of the FC Switch Fabric not being segmented, to show in the XSAN Admin Application a status of a given LUN preferably 'used' or grayed out from the selectable RAW XRAID Storage back-end of selectable LUNS.
3. With a XSAN Volume created as an Project Archives repository that contains QuarkXpress files, If an end user accessing the storage via an AFP share from an Xserve front-end to the XSAN Volume on the back end, If that user opens a Quark file directly from the Server over the network and tries to save the file to overwrite or to a new location on the server the client as well as the server and MDC and Backup MDC will lock up and force the need to reboot to regain stability. This problem is an administrative nightmare.