...
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.
...
Firewall considerations
A single-node network doesn't require any firewall openings (beyond what's necessary to expose a web client), because there are no inter-node communications.
Cert considerations
A single-node network doesn't require any cert exchanges, because there are no inter-node communications.
Info |
---|
title | For SHRINE ACT Network |
---|
|
If you are part of the ACT network, do not attempt to set up a single, standalone node. Configure your SHRINE host to join the ACT hub of your tier as a remote site. |
Hub-and-spoke, single web client
Section |
---|
Column |
---|
|
|
Column |
---|
|
---|
This configuration creates a hub-and-spoke network with a single hub node H, and spoke nodes A, B, and C. A single web client is exposed at the hub; queries originate and terminate at the hub. The spoke nodes only respond to queries. |
|
Hub's shrine.conf
Code Block |
---|
shrine {
...
queryEntryPoint {
...
}
hub {
...
downstreamNodes {
"Node A" = "http://nodeA.example.com/shrine/rest/adapter/requests"
"Descriptive name for node B" = "http://nodeB.example.com/shrine/rest/adapter/requests"
"Human-readable name for node C (can be anything)" = "http://nodeC.example.com/shrine/rest/adapter/requests"
}
}
// NB: no adapter { } block
}
|
Here, we have a shrine.queryEntryPoint block (so that queries may originate at the hub), and a shrine.hub.downstreamNodes block, so the hub knows who to broadcast queries to. The hub does not have a shrine.adapter block, since it's not queryable.
Each spoke's shrine.conf
Code Block |
---|
shrine {
...
adapter {
...
}
}
|
...
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.
Cert considerations
A hub-and-spoke network requires cert exchanges between the hub and each spoke. If there are N spokes, N cert exchanges are necessary.
Fully-meshed, each node can originate queries (Deprecated)
Section |
---|
Column |
---|
|
|
Column |
---|
|
---|
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. The SHRINE team intends to stop supporting this topology in a future release. Do not create new fully meshed networks. |
|
shrine.conf
Assuming a 3-node netowrk with nodes A, B, and C:
...
Firewall considerations
A fully-meshed network requires bidirectional firewall openings between each pair of nodes. For N nodes, the number of bidirectional firewall openings required is (N^2 - N) / 2.
Cert considerations
A fully-meshed network requires cert exchanges between each pair of nodes. For N nodes, the number of cert exchanges required is (N^2 - N) / 2.
Hub-and-spoke, web clients at each spoke
Section |
---|
Column |
---|
|
|
Column | |
---|
This configuration creates a hub-and-spoke network with a single hub node H, and spoke nodes A, B, and C. A web client is exposed at each spoke. Each spoke also responds to all incoming queries by acting as an adapter.This configuration creates a hub-and-spoke network with a single hub node H, and spoke nodes A, B, and C, with corresponding reduction in Having a single hub node reduces the number of firewall openings and cert exchanges required compared to a fully-meshed network, while allowing spoke nodes to expose their own web clients for political, branding, or other purposes. |
|
Hub's shrine.conf
Code Block |
---|
shrine {
...
hub {
...
downstreamNodes {
"Node A" = "http://nodeA.example.com/shrine/rest/adapter/requests"
"Node B" = "http://nodeB.example.com/shrine/rest/adapter/requests"
"Node C" = "http://nodeC.example.com/shrine/rest/adapter/requests"
}
}
// NB: no adapter { } block
}
|
Here, we have a shrine.queryEntryPoint block (so that queries may originate at the hub), and a shrine.hub.downstreamNodes block, so the hub knows who to broadcast queries to. The hub does not have a shrine.adapter block, since it's not queryable.
Each spoke's shrine.conf
Code Block |
---|
shrine {
...
queryEntryPoint {
...
broadcasterServiceEndpoint {
url = "http://hub.example.com/shrine/rest/broadcaster/broadcast"
...
}
}
adapter {
...
}
}
|
...
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.
Cert considerations
A hub-and-spoke network requires cert exchanges between the hub and each spoke. If there are N spokes, N cert exchanges are necessary.