One vault, several accessers

Hello,

where does the information about what data is in which slicestor reside? In slicestors or in accesser? Can I set up 2 accesser machines to access the same vault to balance the load on accesser?

Or should I create the second accesser and make new vault which uses the same slicestor machines. That way I don't have to set up additional slicestors, but I have different accesser machines and the load on each is not so big as it would be in case of only one accesser.

Does it make sense?

Thank you,

Kaspars.

The vault-to-slicestors mapping resides on the accesser, if the vault was created using this accesser. Other information such as codecs and IDA used to make the slices
resides in the vault descriptor, which is stored on the accesser as well.

You can make multiple vaults within the same accesser, or you can set up another accesser that uses the same set of slicestors to create new vaults. Since the slicestor addresses are stored in the vault descriptor, the different vaults on a particular accesser can also use different sets of slicestors.

Currently, a single vault cannot be accessed using different accessers, but in the future we may support this.

What happens if the accesser data which created a vault/slices is corrupted/destroyed?  Is the data lost forever?

The accesser contains critical vault data such as name to UUID mapping, vault descriptor and ACL, etc. You need the vault UUID and ACL to access the data on the slicestors. If you have this information (it is stored on each slicestor as well), it is possible to access this data, but you may have to write your own client.

We don't currently support scenarios where accesser data is lost, but in near future releases we will provide a accesser failover mechanism where if one accesser fails, another will be used seamlessly. Additionally, accessers in the future will not contain any vault information; it will be loaded from some central redundant bootstrapping servers, so failure in the acceser would not imply any data loss. 

what would be the relevant information that would need to be backed up in order to recreate an accesser if it failed, and is there a documented procedure for doing such a thing, in the case that the accesser system failed in some way?

without having multiple accessers being able to access the same vault, does that make the accesser a single point of failure, and going further, if the accesser fails, the data while not technically lost, is no longer available?

Yes, in the 1.0 software, the accesser is a single point of failure.

In order to make the accesser manually redundant, you can copy the /data directory from one accesser installation into another accesser installation. Unfortunately, we don't have any formal documented procedure to do this, because we don't currently support this. 

Let us know if you run into any trouble after copying the /data directory and using it from another accesser.

perhaps i am missing something, but there is no /data directory in the accesser installation.

would the 2 relevant directories be dsnet-accesser/{conf, output}?

i will try these directories and see what happens, but please let me know if i've picked the wrong ones.

Nick,

Sorry for the confusion. You're right, there's no /data directory in the open source zip build of the accesser. I think i was thinking of the rpm build.

So just backing up dsnet-accesser directory should be fine.