Page History

This page discusses network topologies possible with SHRINE, and how to configure SHRINE nodes to achieve them. : 

In general, they're presented in order from simplest to more-most complex. Also note that this list is almost certainly not exhaustive. Table of ContentsmaxLevel3

Detailed information on SHRINE's config file format is here.

Single-node

This configuration creates a network of one: a single SHRINE node, backed by a single instance of i2b2, that accepts queries and exposes a web client. This is the configuration produced by SHRINE's install scripts when run against a stock i2b2 VM.

...

At each spoke, there should be no shrine.queryEntryPoint block (since queries do not originate at the spokes) and no shrine.hub block (since the spokes are not hubs). A shrine.adapter block is required, since the spokes are queryable.

Detailed information on SHRINE's config file format is here.

Firewall considerations

A hub-and-spoke network requires firewall openings to expose the hub's web client and to allow outbound HTTP requests from the hub to the spokes. For a network with N spokes, N unidirectional firewall openings are required.

...

This configuration creates a fully-meshed network where each node can initate queries. It is similar to the single-node-network outlined above, but at each node, all the other nodes are listed in shrine.hub.downstreamNodes. 

shrine.conf

Assuming a 3-node netowrk with nodes A, B, and C:

...

At each spoke, there should be a shrine.queryEntryPoint block that points to the hub (since each spoke originates queries, but routes them through the hub) and no shrine.hub block (since the spokes are not hubs). A shrine.adapter block is required, since the spokes are queryable.

Detailed information on SHRINE's config file format is here.

Firewall considerations

A hub-and-spoke network requires bidirectional firewall openings between the hub and all the spokes. For a network with N spokes, N bidirectional firewall openings are required.

...