Figure 2: Compatible host-vault pair
 |
Hosts and vaults are always paired: a host or vault is unusable by itself. Adding new hosts and vaults to your system makes multiple processors and storage space available to your system. However, only compatible hosts and vaults can be paired. Figure 2, right, shows a compatible host-vault pair: the host and vault can "see" each other and can therefore pass objects between them, as the objects are activated and deactivated.
All Legion host objects must be paired with at least one compatible vault object in order to carry out Legion processes. There are several commands for adding, deleting, and viewing lists of acceptable hosts or vaults, but before you add a new host or vault to your system you must consider any possible compatibility problems. This is a critical point, since if a paired host object and vault object cannot communicate with each other, the Legion objects that they control will be unusable. In Figure 2, for instance, Host A can "see" Vault B, Host Object A manages Host A and Vault Object B manages space in Vault B. Host A is compatible with Vault B, so Host Object A can be paired with Vault Object B.
Figure 3: Common vault system
 |
This is not a concern in systems with a single shared vault (e.g., a networked file system, database system, tape drive, CD-rom, etc.), as in Figure 3, left. Here, any vault objects will represent space in the only available disk storage space (Vault A) accessible to Host 1, Host 2, and Host 3. If the user on Host 1 wishes to add Host 2 to her system, she can either pair the new host object with the BootstrapVault already in her current system or create a new vault object (on Vault A) to manage the new host object's persistent storage needs. Either way, there is no need to worry about non-compatible pairing.
Figure 4: Multi-host and multi-vault system
 |
On the other hand, if this same user wanted to add a new host from a foreign system (i.e., a system with a persistent storage space that is not accessible to her bootstrap host object), she would also need to create a new vault object in the foreign system and pair it with the new host object. Figure 4 (below) shows an example of this situation, with two different file systems and multiple hosts. Hosts 1-3 can see Vault A, and Hosts 4-6 can see Vault B. Again, if the user wanted to add a host from her own system she could either assign the new host object a currently existing BootstrapVault from Vault A or create a new vault object on Vault A without worrying about host-vault compatibility. But if she wants to add a host from the second system, say Host 4, she must pair it with a compatible vault object on Vault B (either by creating a new vault object with legion_startvault or by using one that has already been created and that she has permission to use).
Figure 5 (below) shows how this might work. The user's Legion system creates HostObject4 and VaultObjectB, which are objects that can represent and manage the user's Legion processes on Host 4 and Vault B. HostObject4 will manage the user's Legion work on Host 4, and VaultObjectB will manage persistent storage of any objects that HostObject4 creates or uses. Assuming that there are no conflicts in architecture, environment, etc., you can add a new host to your system with the legion_starthost command and the new host's DNS name and a new host object (representing new.host.DNS.name) will be created on the new host using the curent values of $LEGION and $LEGION_OPR from your current environment. If the new host has a different architecture or has different Legion environment variables, or if the user wishes to specify a different user id, the user can specify this with legion_starthost flags.
Figure 5: Adding new resources to a Legion system
 |
icon. 