Can multiple clients access a single iSCSI partition?
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Can multiple clients access a single iSCSI partition?
Hi. Just so you know, I am a complete newb; I just started working with servers and networks last week.
The problem I have been presented with is to find a way (or to assert that there is none, if indeed no way exists) for multiple clients to access a single iSCSI partition. Is there any way to do such a thing? So far I have been reading about GFS, but that is only about clustering servers. I believe--and correct me if I'm wrong--that the client side still will only allow one access at a time. Is installing a locking mechanism the only thing that needs to be done? If so, how would you go about doing that? If not, what needs to be done?
OK, so after a large amount of further reading, it seems that I can do what I said. Because we only have one server, we need to make a 1-node cluster of it using Red Hat Cluster Suite. Then, when creating the GFS file system, we need to specify lock_dlm as the locking protocol.
I have three new questions.
1) Will this actually work, i.e. will multiple clients be able to access the file system simultaneously?
2) What kind of overhead will be associated with this?
3) (related to previous question) Is there a more efficient way of implementing a solution to the original problem (multiple simultaneous client accesses to the same file system)?
When you say "access the file system" what do you mean?
Do you mean have multiple clients mount the partition? Or do you mean read/write files on the partition through some intermediary?
If the former, don't try it. No file system will handle it properly and you will corrupt data.
If the latter, then sure. In fact, this is done very very commonly. A server mounts the filesystem then shares it across a network with various client machines. All I/O passes through the server.
As for "one client at a time" vs "multiple clients" again I don't know what you mean. Multiple clients can access the same partition and even the same file at the same time. I/O is handled by the device and is reordered to maximize device efficiency. When you get down to it, the drive is only reading/writing one chunk of data at a time, so ultimately only one client at a time is accessing, but from a practical standpoint multiple clients have simultaneous access.
edit: The wikipedia definition of GFS suggests (but does not state) that GFS does permit simultaneous mounting of the FS by multiple clients. This makes the file locking mechanism rather important, and implies no local caching. I wonder if the performance of such a file system is better overall than a more conventional shared or distributed FS.
When I know which of the two I am trying to do, I'll get back to you ASAP. Until then, I'll just say that I think it's read/write files on the partition through an intermediary.
About your edit on GFS: http://www.redhat.com/magazine/018ap...s/tips_tricks/ states that "If more than one system needs to access the data on an iSCSI LUN, GFS [emphasis added], NFS, or Samba should be used to properly share the data." I took "systems" to mean "clients." Is this correct?
And what exactly does local caching mean?
Thanks for your patience, these must seem like incredibly elementary questions to you.
I am unfamiliar with GFS so won't comment definitively about it.
With respect to pretty much any other filesystem, the answer is a resounding "NO" - you can't do that.
Oh, multiple systems certainly CAN mount the same filesystem at the same time, but you are guaranteed data corruption, and very quickly. The usual procedure is to share the filesystem using NFS or SMB.
That redhat link suggests that GFS is another sharing protocol, like NFS or SMB. It does state quite clearly that multiple clients (systems) cannot simultaneously mount the same drive (LUN).
Just share the filesystem. The technology to do that is mature and fast.
The filesystem is already being shared using NFS; the thought was that GFS would make it faster. If GFS does not provide the ability to mount the filesystem on multiple clients, then what is the file locking mechanism for? (That question is only half-rhetorical.)
I guess what I need is someone who is familiar with GFS, but where/how can I find one of those?
And for my personal cultural edification, why is data corruption guaranteed in that situation? I thought that data corruption happened because when multiple systems have the same filesystem mounted, they don't know that another system may be editing a file, so all systems just assume they have exclusive read/write capability, and they write wherever they want, which almost always (but not 100% always) results in them writing to the same file at the same time and corrupting it.