Distributed Vault Installation

Distributed vaults enable the storage of binary content (vaulted files) in physically distributed locations. This can improve the overall performance of the information system and reduce the network bandwith used for transferring file content between the vault server and the client sites.

The objective of distributed vaults is that users/clients check in and retrieve files to/from a vault location that is near to their own location in terms of network infrastructure. A vault server within the LAN of the own subsidary is nearer than a vault server within the headquarter's LAN, even if this server is also accessible, however by a slower VPN-based connection. If users can be logically assigned to Sites, ice.NET distributed vaults find appropriate vault locations for individual users based on simple configuration rules. Assuming that teams located at a common site access "their" files more frequently than teams from other sites, the file transfer between different sites can be minimized.

The configuration of distributed vaults is explained by implementing the following example:

At the headquarter the application server and a vault server is installed. Additionaly the sites Germany and Poland are equipped with their own vault servers.

Application Server Configuration

To support the assignment of users to vault locations, the vault configuration parameters of the application server have been extended: 

<vault name="Vault.Distributed" protocolFactory="PDTec.IceNet.Domain.VaultServer.IceNetVaultProtocolFactory,PDTec.IceNet.Domain">
    <parameter name="BaseUrl"               value="http://intranet.corp.com/icevault/icevault.ashx" />
    <parameter name="BaseClientUrl"         value="http://intranet.corp.com/icevault/icevault.ashx" />
    <parameter name="AuthorizationMethod"   value="RSA" />
    <parameter name="PrivateKey"            file="..\IceVault_VaultServer.rsa" encrypted="false" />
    <parameter name="MaxRequestSize"        value="1024" />
    <parameter name="Sites.Count"           value="2" />
    <parameter name="Sites.1.GroupName"     value="Vault.Site.Germany" />
    <parameter name="Sites.1.BaseClientUrl" value="http://germany.corp.com/icevault/icevault.ashx" />
    <parameter name="Sites.2.GroupName"     value="Vault.Site.Poland" />
    <parameter name="Sites.2.BaseClientUrl" value="http://poland.corp.com/icevault/icevault.ashx" />
</vault>

In addition to the standard parameters for the IceVault protocol (BaseUrl, BaseClientUrl, AuthorizationMethod, PrivateKey, MaxRequestSize) parameters for the Site-assignment have been added. Sites.Count=2 indicates that two sites are defined, the Sites.1 and Sites.2 parameters define a GroupName and a BaseClientUrl for each site.

If a user is member of a group named GroupName, the application server uses the site's BaseClientUrl instead of the default BaseClientUrl to build an access URL for a file stored in the vault.

The member test is performed in the order of the number sequence. If the user is member of neither group, the default BaseClientUrl is used. With this technique, the best location can be calculated for each user.

Alternatively the parameters can be stored within the database. To enter the Sites parameters, the protocol type must be switched to Custom. The corresponding entries are displayed here:

Vault Server Configuration

As a consequence of the distribution, at any given point of time, not all files are physically available at all vault locations. To enable the objective of a single "logical" vault that can be transparently used over the whole network, two techniques can be applied:

  • Overnight replication of file content between the vault locations. This can use available network bandwith in idle periods to increase local availability of files in all sites. However, it does not ensure 100% availability of all files.
  • Online communication together with on-demand replication of files between the different vault servers. This technique requires additional configuration.

Vault Server at the headquarter

The headquarter's vault server (Location: Main) is configured to retrieve missing files from both subsidary servers: 

<vault name="Vault.Distributed" basePath="..\__vault" authorizationMethod="RSA" publicKeyFile="..\IceVault_VaultServer.rsapub">
    <distribution location="Main">
        <replicationSource baseUrl="http://germany.corp.com/icevault/icevault.ashx" />
        <replicationSource baseUrl="http://poland.corp.com/icevault/icevault.ashx" />
    </distribution>
</vault>

The distribution/@location entry "Main" is important to prevent endless loops caused by cycles in the replication chain. The replicationSource/@baseUrl point to the vault services at the Germany and Poland sites.

Vault Server at the German site

The German vault server (Location: Germany) is configured to retrieve missing files the headquarter: 

<vault name="Vault.Distributed" basePath="..\__vault" authorizationMethod="RSA" publicKeyFile="..\IceVault_VaultServer.rsapub">
    <distribution location="Germany">
        <replicationSource baseUrl="http://intranet.corp.com/icevault/icevault.ashx" />
    </distribution>
</vault>

Vault Server at the Polish site

The Polish vault server (Location: Poland) is configured to retrieve missing files the headquarter: 

<vault name="Vault.Distributed" basePath="..\__vault" authorizationMethod="RSA" publicKeyFile="..\IceVault_VaultServer.rsapub">
    <distribution location="Poland">
        <replicationSource baseUrl="http://intranet.corp.com/icevault/icevault.ashx" />
    </distribution>
</vault>

With this star-shaped replication structure (centered Headquarter, satellites Germany and Poland) any file can be retrieved from anywhere. If e.g. a file is checked in in the Polish vault server and requested from a user of the German site, the file content is transparently replicated from Poland to Main and subsequently to Germany. Due to the replication, further access from Germany to this file is served from the replicated local file.