Using the weighted passthru resource

In a situation where one server in an iRODS Zone has a public IP and another server in an iRODS Zone can only have a private IP, is it possible to configure the Zone to allow puts and gets to the public IP, but still keep replicas on both?


With the following configuration, one can control the priority of reads and writes to particular resources (and therefore, particular physical and network locations).

The weighted passthru resource can be used to manipulate the read/write votes of the children of a replication resource. One can then specifically direct an initial put to the public server and have the replication occur from server-to-server and not require a direct connection between the client and the private resource server.

Here are a series of commands confirming replica 0 (the first replica) is on the public resource.

First I create a replication resource, two unixfilesystem resources to simulate the storage vaults on the public and private servers, and two passthru resources. Note the weights on the public passthru multiply the votes from its child by 1.1x for both read and write and the private passthru multiply the votes from its child by 0.9x.

Then I wire together the hierarchy with the public and private sides as children of the replication resource:

This is the finished hierarchy:

I upload a single file into the replication resource:

I show that there are two replicas, with the first replica (numbered 0) on the public resource and the second replica (numbered 1) on the private resource:

Then, I change the context string of the public weighted passthru resource to *lose* the vote (by changing the weights to be less than the 0.9x still applied to the child of the private weighted passthru resource).

I put a new file:

And then confirm replica 0 (the first replica) of the new file is on the private resource and the second replica (numbered 1) is on the public resource:

The weighted passthru resource gives you fine-grained control over which children receive (and provide) dataObjects.

Also, note that nothing done here required stopping, or restarting any of the iRODS servers in the Zone. These context strings are read on every new instantiation of an Agent (on every connection). A change of the value is effective immediately, for all new connections to iRODS.

If you have an interesting use case, or this brings up new questions for you, please do not hesitate to get in touch. We’d love to hear what you’re doing.