Accesser nodes?

The overview at the following page, http://www.cleversafe.org/dispersed-storage/infrastructure , makes a comment:

"Typically, one iSCSI Initiator connects to one iSCSI target."

Does the dsNet architecture actually require that there be a separate accesser node (iscsi target) per client (iscsi initiator)?  Or does this mainly provide the ability for horizontally scaling load and I/O for multiple clients into the grid depending on your application and client needs?

Thanks

Looking around some more I came up with another question, the answer of which might answer my question above...

Does each accesser only serve up a single vault per iscsi target?  Can the same vault be mounted on more than one client iscsi initiator? If so, it appears that the only client software is having an iscsi initiator, so in theory you could run a shared/clustered file system on top of the block device provided by the dsNet amongst all your clients using the iscsi LUNs that they are presented?

Does the dsNet architecture actually require that there be a separate accesser node (iscsi target) per client (iscsi initiator)?

Good question.  The dsNet architecture does not require a separate accesser (target) node per client, however that is a limitation of the 0.7.4 release.  We are focusing quite a bit of effort on the iSCSI target layers in order to remove that limitation and achieve standards compliance.

Does each accesser only serve up a single vault per
iscsi target?  Can the same vault be mounted on more than one client
iscsi initiator? If so, it appears that the only client software is
having an iscsi initiator, so in theory you could run a
shared/clustered file system on top of the block device provided by the
dsNet amongst all your clients using the iscsi LUNs that they are
presented?

That is another limitation in 0.7.4.  Architecturally, a single accesser can serve many clients accessing any vault on the grid.  Attaching to a single vault concurrently from multiple initiators is somewhat more difficult in a block device paradigm because of cache coherency.  If your vault has a single partition with a standard filesystem (ext3, NTFS, etc) you will need to mount it read-only on each client machine in order to allow concurrent access.  I don't have much experience with cluster filesystems, but that may be an option.  I'd be interested in doing some experimentation if you have one to recommend.

Previously gdhuse wrote:

Does the dsNet architecture actually require that there be a separate accesser node (iscsi target) per client (iscsi initiator)?

Good question.  The dsNet architecture does not require a separate accesser (target) node per client, however that is a limitation of the 0.7.4 release.  We are focusing quite a bit of effort on the iSCSI target layers in order to remove that limitation and achieve standards compliance.

Does each accesser only serve up a single vault per

iscsi target?  Can the same vault be mounted on more than one client

iscsi initiator? If so, it appears that the only client software is

having an iscsi initiator, so in theory you could run a

shared/clustered file system on top of the block device provided by the

dsNet amongst all your clients using the iscsi LUNs that they are

presented?

That is another limitation in 0.7.4.  Architecturally, a single accesser can serve many clients accessing any vault on the grid.  Attaching to a single vault concurrently from multiple initiators is somewhat more difficult in a block device paradigm because of cache coherency.  If your vault has a single partition with a standard filesystem (ext3, NTFS, etc) you will need to mount it read-only on each client machine in order to allow concurrent access.  I don't have much experience with cluster filesystems, but that may be an option.  I'd be interested in doing some experimentation if you have one to recommend.

It would be pretty trivial to test out GFS under CentOS 5 against the dsNet-backed iSCSI targets.  That would be where I would start if you have time and are interested in testing it out. 

Whenever I have time I fully intend to test out a full range of different things with the new Cleversafe software.

Previously mathrock wrote:

It would be pretty trivial to test out GFS under CentOS 5 against the dsNet-backed iSCSI targets.  That would be where I would start if you have time and are interested in testing it out. 

 

Whenever I have time I fully intend to test out a full range of different things with the new Cleversafe software.

Thanks!

If you face any difficulties whenever your start your test. Let us know if we an help.

Sarah.

How many slicers can be attached per accessers?

How to configure more then one accesser for more high availability?

-Thanks,

How many slicers can be attached per accessers?

An arbitrary number of SliceStors and Accessers can be combined to build a dsNet.  It would be possible to create a single vault that spans 16 SliceStors with a single Accesser, or 10 vaults that span 100 SliceStors and use 3 Accessers. 

How to configure more then one accesser for more high availability?

High availability targets can be achieved in iSCSI by exposing the same vault target on two or more Accessers and configuring your initiator to fail over if an Accesser becomes unavailable.  For example, the Microsoft iSCSI initiator has a MPIO fail-over mode on Win2k3+ that can be used with an arbitrary number of Accessers for each vault.

 Greg