I've been reading your book, "Storage Area Networks for Dummies", and I have a few questions:
1. Is any SAN disk or zone accessed by Windows unuseable by other operating systems?
2. Are there any other operating system access exclusions? Can MAC systems use SAN disks accessed by UNIX systems? Can VAX computers access storage used by UNIX systems?
3. A server ("A") attached to the SAN can expose the SAN storage as a shared drive so other servers on the LAN but not the SAN, can access it correct?
4. Can you say that access (from remote LAN servers) to the shared drive on "A" with the SAN behind it is faster than access to a shared drive on "A" that is a local disk? The LAN part is the same but what happens on server 'A" is different.
I hope you're enjoying the book!
Answer to question 1:
Normally, disk sharing within a pool of SAN based disks is not allowed especially between different operating systems. There are exceptions though, but they require software that has a higher level of intelligence. Clustering solutions allow the sharing of SAN disk resources by servers within the same cluster. Solutions like Microsoft Cluster Server(MSCS), Veritas Cluster Server(VCS), Sun Clusters, VMS Clusters, etc. allow sharing of disk resources since the software includes "lock-management" which acts like a traffic cop within the cluster for access to the same disk by each server.
There are also other solutions like SAN-based file systems that allow sharing of data between multiple operating systems connected to the SAN. An example of what's available is: Global File System (GFS), Central Version File System (CVFS), CXFS(SGI), SANergy (Tivoli Systems) and SAMFS (Sun). Veritas has a GFS, and Microsoft is working on one.
These file systems may either be symmetric or asymmetric in nature:
A symmetric file system allows any client to perform a file system operation on its own. GFS is an example.
An asymmetric file system client needs access to a metadata file manager (usually over IP) to request access for data located in the SAN. CVFS and CXFS and SANergy are an example.
So you would have to go out and buy this intelligent software to enable access to shared resources within the SAN.
Answer to question 2:
For MAC access to the SAN an HBA driver for the MAC would be needed. Many of the HBA vendors do not have drivers available for the MAC, unless the MAC is using OSX, which is a Unix variant. For sharing data between multiple operating systems, when block-based SCSI type access is not needed, NAS makes more sense than SAN. NAS allows any IP connected server that understands the CIFS or NFS protocols to share files over the IP network.
Answer to question 3:
Correct. Yup, uh huh…
Answer to question 4:
It depends. If your server "A" is using Ultra SCSI disks locally and your SAN scenario includes access to SAN disks through 1Gbit arbitrated loop host bus adapters to a single physical disk in the SAN, than NO, the local disk would be faster. If your server "A" is connected to a storage array using 2Gbit Fibre Channel switch to an array that has multiple physical disks configured as a RAID set, than the SAN disks would be faster. In either case, access speed to remote clients will depend more on the CPU speed of the server and the amount of server memory available to use as a cache for CIFS or NFS client requests.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in one of our .discussion forums.
Dig Deeper on SAN technology and arrays
Related Q&A from Christopher Poelker
SAN expert Chris Poelker discusses how to change the size of a LUN in a Microsoft cluster server environment. Continue Reading
SAN expert Chris Poelker compares connecting a SAN with wavelength cabling and dark fiber and discusses the pros and cons of each. Continue Reading
Storage expert Chris Poelker outlines WWN basics in order to answer the question: "Why do HBAs in a SAN have same base?" Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.