Personal tools
You are here: Home Forums-old Dispersed Storage Users Feasibility of a public dsNet?
Document Actions

Feasibility of a public dsNet?

Up to Dispersed Storage Users

Feasibility of a public dsNet?

Posted by Ryan Michael at August 24. 2008

This may be a different problem that Cleversafe isn't really designed to address, but is there any possibility of creating a public dsNet along the lines of Wuala?  Cleversafe seems to provide exactly what I'm looking for, but I work for a small office and we're not in a position to maintain dispersed slicestors.


 


-Ryan


Re: Feasibility of a public dsNet?

Posted by ivolvovski at August 26. 2008

Ryan,


There is really no need to create completely geographically dispersed dsNet. It is feasible to create ALL slices even on a single host if you'd like to do so. In this case your SliceStores should listen on different ports. Even though it is not really the intended production mode and many useful properties of storage would be missed as the result, it is a practical option to try software on a limited scale. 


In fact we have also an option to run the whole dsNet in a single JVM and that's what we use this option for testing. But hopefully you don't need to go that far.


 


Ilya


Re: Feasibility of a public dsNet?

Posted by Ryan Michael at August 27. 2008

I considered that (a local net), and if I can't find a better solution may end up implementing it.  My situation is that I'd like to use the desktop machines we already have as a distributed data store.  From my reading, it looks like there are performance issues and size constraints involved with using the same machine as both accessor and store.  I'd also really like to have some distributed storage in case the building burns down or something.


I'm also looking at implementing AFP, but it has the same geographic distribution problem.


 


-Ryan


Re: Feasibility of a public dsNet?

Posted by ivolvovski at August 29. 2008

You are quite right, there is a performance penalty when running accesser and store on the same machine. So it is definitely not a preferred way because our software uses IO buffers very extensively which in this case would be allocated on the same box for both applications and result in starvation on OS level. Our QA even reported that in some instances it could freeze a machine.


For any serious deployment rules for choosing accesser and stores machines to achieve reasonable performance should be: accesser is CPU intensive and memory rich, but does not need much storage; SliceStore doesn't consume a lot of CPU but needs faster storage.


You raised an important question, we would have to publish hardware/software guidelines for open source deployment. This question doesn't arise in our commercial offering as we sell well tuned appliances. The good news is that they run the same software.


Ilya


 


Powered by Ploneboard