Web Management Console¶
ScaleOut StateServer’s original web-based management console runs as a local web server on Linux systems. The console’s web server can be run on any host (i.e., any server that runs the StateServer service), and it can manage all other hosts on the same network subnet that are configured with the same management port.
The StateServer service must be running on either the local host for the management console to operate.
Unix systems also can be managed from a remote Windows system using the Windows Management Console, which is available in the Windows installation package.
Using the Management Console
After following the above installation steps, you can access the management console by browsing to the management console’s web site. The management console’s home page looks as follows:
If you have enabled the ScaleOut GeoServer option, the management console displays additional features for managing replication to remote stores. If you install the Remote Client option, the management console displays an additional feature for managing remote client access:
This display has two panes. The left hand pane, called the store list, contains a tree structure with two lists. The top list depicts the store with the Local Store icon and shows the host IP addresses corresponding to hosts associated with the store. These hosts have responded to a query from the management console. The right hand pane shows display tabs associated with the store or with a selected host. You can select the store’s tabs by left-clicking on the Local Store icon, and you can click the host tabs by left-clicking on one of the IP addresses shown in the list. By default, the store’s status tab is displayed in the right hand pane.
If the local host’s selected network interface cannot be found, the loopback IP address, 127.0.0.1, will be displayed for the local host. The network interface is selected by the settings of the net_interface and subnet_mask parameters in the soss_params.txt (see Configuration Parameters). The StateServer service will periodically poll for the selected network interface, and it will automatically restart and use the interface if it becomes available.
If the GeoServer option is enabled, the left hand pane adds a second list under the Remote Stores icon that depicts the list of remote stores to which objects may be replicated. The items in this list correspond to the names of the remote stores that have been added to local store’s client parameters file. You can display and manage the list of remote stores in the right hand pane by left-clicking on the Remote Store icon. You can also display and manage the configuration of individual remote stores in the right hand pane by left-clicking on the icon for a specific remote store.
The client parameters file for remote stores, soss_client_params.txt (see Configuration Parameters), is stored in ScaleOut StateServer’s installation directory on every host of the local store. Versioning information is kept in the file to ensure that all hosts always have the latest updates to the file. You should not directly edit this file; please use the management tools instead.
If the Remote Client option is enabled, the left hand pane adds a Client Configuration icon to represent the client’s configuration and connection status to the remote SOSS store.
The client parameters file (soss_client_params.txt, see Configuration Parameters), which contains configuration information for accessing a remote SOSS store, is stored in ScaleOut StateServer’s installation directory on the remote client. This file only contains information for the Remote Client option; it does not contain GeoServer configuration information, which is stored in the client parameters files at the remote store.
Once the remote client successfully connects to a host within the remote SOSS store, the management console displays this host in the Store List as the “local host.” All management operations then proceed as if the management console were locally connected to the host. Should the host become unavailable, the remote client will automatically attempt to reconnect to another host within the SOSS store using the gateway list in the client parameters file.
An optional icon in the left hand pane is the Group Management icon. This icon indicates whether the local host has connected to a group of peer hosts with whom it can build or join a store. It also allows the group list to be managed when multicast discovery is disabled. More details on group management are explained below.
The following sections provide a more in-depth look at the store list and the right hand pane’s tabs.
When the StateServer service starts, it must first connect to a group of hosts which will form a distributed store. If no other hosts initially are present, it can create its own group. A host group is identified by the management port specified in the host’s configuration. (See The Host Configuration Tab below.) If multicast is enabled in the host’s configuration, the host group is automatically discovered using the multicast IP address specified in the host’s configuration; all hosts within a group must use the same multicast IP address and port.
If multicast is disabled, the group of hosts can be manually specified by clicking on the Group Management icon in the store list; this brings up the Group Management configuration pane to the right of the store list:
The Group Host List is initially empty when no group IP addresses have previously been entered (or discovered through multicast). If no other group hosts exist, you can create a new group by pressing the Create button. This will place the local host’s IP address (used for its host id) in the group list and store it in the soss_params.txt file. Otherwise, you can specify one or more IP addresses of other hosts by entering them in the Add Group Host window and hitting the Add button after each IP address is entered. You can connect to this host group by hitting the Connect button. Once the local host has joined the group, the Group Management icon turns from the disconnected state to the active state:
All IP addresses entered into the local host’s group list (or detected by multicast discovery) are stored in its soss_params.txt file. Once the host joins a group, the group lists for all hosts are updated automatically to include the IP address for the newly joining host.
A host can be disconnected from a group (and then possibly join a different group) by hitting the Disconnect button in the Group Management pane.
ScaleOut StateServer automatically detects and recovers from network subnetting. If a group is partitioned by network subnetting, it will form two independent host groups. If the subnetting issue is subsequently corrected, the hosts will automatically detect that the two groups can be coalesced and will recover according to the split-brain recovery policy.
The Store List¶
The store list lets you quickly see which hosts are currently associated with the local store. It also displays a colored icon that shows the status of the store and of the hosts. The possible indications for the store’s status are:
|Active||The store has been created and is accepting access requests.|
|Not ready||The store has been created but is temporarily not accepting access requests (i.e., objects cannot be created, read, updated, or removed at this time) because one or more hosts are not ready. This situation usually occurs during failure recovery or dynamic load-balancing.|
|Inactive||The store has not yet been created because all hosts are inactive.|
|Unknown||The store’s state is unknown because the local host has not yet joined a host group.|
The possible indications for each host’s status are:
|Joining||The host has been activated and is joining the store.|
|Active||The host has been activated and has joined the store.|
|Leaving||The host was previously activated and is now leaving the store.|
|Isolated||The local host cannot perform queries and cannot interrogate remote hosts. The host may have a network outage.|
|Unknown||The remote host’s status is unknown. The local host may have experienced a network outage, or it may have failed.|
|Not ready||The host has been activated but is temporarily not ready due to failure recovery or dynamic load-balancing or memory exhaustion which has caused the StateServer service to start paging.|
|Inactive||The host is inactive and has not joined the store.|
|Disconnected||The host is not yet connected to a host group and cannot form a store.|
The management console automatically refreshes the store’s status indication and the list of hosts whenever the local service detects a status change and you have selected the Local Store icon.
If you select a specific host within the Store List, the status of other hosts and the Local Store icon will not be automatically refreshed. Be sure to select the Local Store icon to allow the management console to automatically refresh the store’s status.
The management console may temporarily indicate that a host has a not ready status due to heavy network traffic that prevents a timely response to the console’s status queries. This does not necessarily indicate a problem with the host itself, and the status indication usually clears after a few seconds. However, it can be an indication of an overloaded network, in which case steps should be taken to reduce the network load or increase the network’s bandwidth.
If a host remains in the not ready state for several minutes, the StateServer service will attempt an automatic restart to clear the condition. This could be an indication that the StateServer service is paging due to memory exhaustion. Be sure to check whether sufficient available physical memory exists for the service.
The Remote Stores icon in the store list has one of the following status indications:
|Active||One or more remote stores have started replication to a remote store.|
|Unknown||The status of replication to remote stores is unknown due to loss of communication to the local store.|
|Inactive||Replication to all remote stores is inactive.|
In addition, each remote store in the list of remote stores has the following possible status indications:
|Active||Replication to the remote store has been started and is running normally.|
|Unknown||Replication to the remote store has been started, but connectivity to the remote store has been lost.|
|Not ready||Replication to the remote store has been suspended due to insufficient memory in the local store.|
|Inactive||Replication to the remote store has not been started.|
The optional Client Configuration icon in the left hand pane has one of the following status indications:
|Connected||The remote client has connected to the remote SOSS store.|
|Unknown||The remote client has been configured, but connectivity to the remote store has been lost.|
|Not configured||The remote client has not yet been configured with at least one gateway address to reach a remote SOSS store.|
The Store Status Tab¶
The Store Status tab provides three buttons that simultaneously control all hosts in the store. In most cases, it is faster and more efficient to use these buttons than to individually control hosts from the Host Status tab. The Join All Hosts button joins all inactive hosts to the store, and the Leave All Hosts button causes all active hosts to leave the store. (You should not use these buttons while Join and Leave control operations on individual hosts are in progress.) Finally, the Restart All Hosts button immediately restarts the StateServer service on all hosts and permanently removes all stored objects.
The Store Status tab provides two additional buttons for managing all hosts in the store. The Clear Store button lets you clear the contents of the distributed store. This button removes all stored objects on all reachable hosts. You should not use this button if a host currently is experiencing a network outage. Otherwise, some objects may be left in the store, and these objects may not have replicas. The Test Store button verifies client access from all active hosts in the store. This command creates, reads, updates, and removes several objects so that all hosts in the distributed store are exercised. It reports the result of this test within several seconds.
The Test Store button should not be used when one or more hosts are joining or leaving the store or if some hosts are temporarily displaying the not ready status due to dynamic load balancing. During periods of dynamic load balancing, this command may not return success within the allowed timeout period to heavy network traffic. In this case, retry the command after a few minutes after load balancing completes.
In addition to providing the above control functions, the Store Status tab shows the store’s current status and the number of hosts that have joined the store. It also shows aggregate statistics for the store, including the number of stored objects, the memory consumed by the objects, and the approximate access rate for object create, read, update, and delete operations.
Statistics for replica objects, including the number of replica objects and the memory consumed for replica objects, are not shown in the Store Status and Store Hosts tabs. (As explained in the section Recovery from Failures, SOSS creates up to two additional replicas for each stored object.) For example, if ten objects of size 1 kilobyte (KB) each are created in a three-host store, these tabs show ten objects and 10KB total memory consumed by stored objects.
The Store Status tab also lets you specify the local store’s name for use in the GeoServer option’s pull access mode. Remote stores use this name to identify the local store. The name is stored in the soss_params.txt file as the geos_local_name parameter.
The local store’s name entered in this tab must be identical to the name used when configuring GeoServer at the remote store. Otherwise, the remote store will not be able to push updates to the local store as part of pull access mode.
The Store Hosts Tab¶
The Store Hosts tab shows a table of statistics for the store on a per host basis. The aggregate statistics are the same as those shown on the Store Status tab. The following figure shows an example of this tab:
The Host Status Tab¶
When you click on a host’s IP address in the left hand pane’s Store List, the Host Status tab for the selected host is displayed as shown below:
This tab shows the host’s status and its statistics. It also has three buttons for controlling the host. The Activation Control buttons control the service’s activation to join the store or de-activation to leave the store. They include:
- a Join button to activate the host and join the store if it is inactive (otherwise, this button is disabled) and
- a Leave button to de-activate the host and leave the store if it is active (otherwise, this button is disabled).
Each host requires several seconds to join the store. However, multiple hosts can simultaneously join, and all hosts can be joined at once using the Join All Hosts command on the Store menu. After a host joins, it automatically receives a portion of the storage load. Over a period of several seconds to approximately a minute (or more in some cases), the dynamic load balancer slowly migrates objects to a newly joined host. During dynamic load balancing, the store’s aggregate access throughput drops intermittently, and it is normal to experience higher response times for some objects. The length of time required for dynamic load balancing is proportional to the number of joining hosts and to the current number and size of stored objects.
Store hosts always leave the store one at a time unless the Leave All Hosts command is used to simultaneously stop all hosts in the store. Each host requires approximately a minute or more to leave the store. The host must first shed its storage load to other hosts, and other hosts must replace replicas stored on this host. During this rebalancing process, the aggregate access throughput may drop slightly, and it is normal to experience higher response times to some objects. The length of time required for rebalancing is proportional to the to the host’s number and size of stored objects.
It is important to allow a host to fully leave the store prior to shutting down the host or restarting the StateServer service. Otherwise, the host will abruptly leave the store, and other hosts will trigger recovery actions that further delay resumption of full storage throughput. In some cases, the distributed store can be destabilized, especially if multiple hosts are simultaneously stopped in this manner. Be sure to wait for the Leave command to fully complete (indicated by a red Inactive icon in the store list) prior to restarting the host.
The StateServer Service Restart button lets you stop and then restart the StateServer service. This button is useful to reload parameter values or to clear error conditions. After you press Restart once, the service will attempt to gracefully leave the store prior to restarting; this process may take several seconds. In some situations, it may be necessary to immediately restart the service. To do this, press the Restart button three times in sequence to force an immediate restart.
Do not restart more than one active host until recovery has been allowed to complete. The store’s recovery can require one or more minutes depending on the current storage load. Simultaneously restarting more than one host prior to awaiting complete recovery by the remaining hosts could cause data to be lost, and storage throughput could be affected for several minutes until recovery completes.
Restarting the StateServer service on the local host will temporarily interrupt management operations using the management console or the command-line control program.
The Host Configuration Tab¶
The Host Configuration tab lets you set the configuration parameters for a host for use with ScaleOut StateServer. This tab is displayed by default when the management console is started after the software is originally installed. It looks as follows:
The configuration parameters shown on this tab are described in detail in the section Configuration Parameters. You can commit your changes to the configuration parameters by pressing the Apply button, and you can cancel proposed changes by pressing the Cancel button. You can refresh the values shown on the tab by pressing the Refresh button. Note that the Apply and Cancel buttons are disabled until you actually make changes to the configuration parameters.
For your convenience, all available choices for the net_interface parameter are shown in a drop down list, and the current value is displayed as the selected item:
The displayed choices are based on the current setting for the subnet_mask parameter. For example, if subnet_mask is set to its default value of 255.255.255.0, all available class C subnets reported by the operating system are displayed. If you set subnet_mask to 255.255.255.255, all local IP addresses are displayed. (The service reports up to 254 IP addresses.) Initially, the network interface is shown as “not selected” unless only one interface is found, in which case the StateServer service uses that interface.
If the host’s IP address on the desired subnet is automatically supplied by DHCP, you should set subnet_mask to the subnet’s network mask, hit Apply, and then select a value for network_interface from the pull down list. In this case, whenever the StateServer service starts, it uses the first available local IP address reported by the operating system for that subnet. If you want ScaleOut StateServer to use a specific IP address, you should set subnet_mask to 255.255.255.255, hit Apply, and then choose one of the listed IP addresses for network_interface. Note that if this IP address becomes unavailable, the StateServer service will not be able to communicate with other hosts after it starts.
Once you select a network interface and hit the Apply button, the StateServer service restarts and selects an IP address for communications with other hosts based on the current settings for network_interface and subnet_mask. The selected IP address is shown as the host’s identifier.
If the host is active, all parameter changes are disabled. Changing the network interface, subnet mask, multicast IP address, server port, management port, or other parameters requires that the host be in an inactive state, and this will cause the host’s StateServer service to be restarted. As noted above, restarting the StateServer service on the local host will temporarily interrupt management operations using the management console or the command-line control program.
You can select whether this host will use multicast discovery to find other hosts in its host group, which together will form a distributed store. All hosts in a group must use the same management port value. If Use Multicast Discovery is enabled, you can change the default multicast address which the StateServer service uses for discovery. All hosts in a host group must use the same multicast address. If you uncheck this option, multicast will be disabled, and you can manually enter the IP addresses of other hosts in the group using the Group Management pane, as described above under Group Management.
This tab also shows the licensing information encoded in the license key that you enter, as described in the section Configuration Parameters. If an invalid license key is entered, the selected host’s StateServer service will be disabled so that it cannot be activated. You can update the licensing information by entering a license key and pressing the Apply button.
The Host Configuration tab also shows a section called Gateway Information for use with the ScaleOut GeoServer and Remote Client options:
This section lets you enter the gateway IP address and port for this host, as well as whether the host should require the use of secure connections for clients connecting to the gateway ports. As described under Configuration Parameters, the gateway address is used by the GeoServer option to let remote stores access this host within the local store to deliver inbound, replicated objects. It is also used by the Remote Client option to let remote clients connect to the SOSS store. Although this address need not conform to the host’s IP address as specified in the Local Store list, it must be reachable from remote hosts.
The gateway address is not used by other hosts within the local store to access this host. The list of gateway addresses for the local store is sent to a remote store (after the remote store initially connects) and used to access the local store over a secure communications network to deliver replicated data. By using multiple gateways to access the local store, data replication operates with the highest possible performance and availability.
Note that three options are provided for the behavior of the gateway address and are encoded in the parameters file:
By selecting Track host IP address in the pull-down list (encoded as 255.255.255.255 in the parameters file), you specify that this host should use its current IP address in the Local Store list as its gateway address. This lets the gateway address automatically change if it is dynamically updated by DHCP. Alternatively, you can enter a static IP address, which might be an external address that must be routed to this host by your firewall. Finally, you can disable the gateway address (encoded as 0 in the parameters file) to prevent this host from receiving replicated data. To maximize performance and availability of the local store for GeoServer replication and remote client access, you should avoid disabling the gateway address if possible.
The Host Configuration tab also shows you the licensed features that have been enabled by the license key entered for this host. It also shows the current version of the StateServer service for the host to which the management console is connected. This tab displays as follows:
In some cases, the value “(as licensed)”is displayed for a licensed feature. In this case, the licensed value for this feature is controlled by a specific license agreement with ScaleOut Software, Inc. Please refer to this license agreement for more information.
The Remote Stores Pane¶
If you have licensed the ScaleOut GeoServer option, the Remote Stores pane is displayed on the right hand side when you left-click on the Remote Stores icon in the Store list. This pane lets you add and remove remote stores, start and stop replication to all remote stores, and track the status of active replication:
The top of this pane shows a table of remote stores that have been added to the client parameters file. It also shows whether replication to these stores has been started and its current status. The above example shows two remote stores, London and Paris, for which replication is inactive. After replication has been started, a remote store moves from the inactive status to the active status. If communications with the remote store are lost because no gateway address is reachable, the management console will display the unknown status until the condition clears. If synchronization of all local objects to the remote store was requested, the table of stores will show the synchronization to be Pending until all local objects (at the start of replication) have been delivered to the remote store(s). Finally, the table of stores shows the aggregate replication rate (bytes per second) to each active remote store.
You can add a new remote store to the table and to the client parameters file by filling out the information in the Add Remote Store section of the pane and left-clicking on the Add button. (Partial entries can be cleared using the Clear button.) For example, to add the remote store Brussels to the current configuration, this section could be filled out as follows:
The remote store’s name is an arbitrary string of printable characters (except an embedded comma); it is used only by the local store to refer to the remote store. The gateway IP address and gateway server port must be reachable from the local store. This gateway address is used to establish communications with the remote store and begin replication of objects to the remote store. The Secure Connection checkbox must match the configuration of the remote store’s gateway configuration for accepting secure connections.
If the host on the remote store corresponding to the gateway address is not part of an active remote store, the local store will not be able to connect to the remote store. To avoid this problem, you can add more gateway addresses to the client parameters file using the Remote Site pane described below.
When pull access mode is used, the remote store’s name entered in this tab must be identical to the name used when configuring the geos_local_name parameter (in the Store Status tab) at the remote store. Otherwise, the local store will not be able to push updates to the remote store as part of pull access mode.
You can also configure the local store to replicate to a remote store hosted in Amazon Web Services. To do so, you will need the following information:
- The Access Key and Secret Key of a user associated with the account used to run the remote store. At minimum, this account must be granted the ec2.DescribeInstances permission
- The AWS region the remote store is running within, and
- The name of the remote store as identified in the remote store’s configuration.
Once you have this information, this section could be filled out as follows:
The table is automatically refreshed every few seconds. You can remove a remote store from the table and from the client parameters file by selecting it in the table and hitting the Remove button. This action will stop replication if it is active.
The Remote Stores pane includes buttons at the bottom of the pane in the Replication Control section to simultaneously control replication to all remote stores. Both the Start All and the Sync All buttons start replication to all remote stores. In addition, the Sync All button first replicates all local objects (which are subject to replication) to the remote store. This lets you synchronize the contents of an empty remote store to that for the local store prior to beginning ongoing replication of object updates. You can stop replication to all remote stores using the Stop All button.
Replication commands are simultaneously performed on all hosts in the local store.
The Remote Store Detail Pane¶
The Remote Store Detail pane lets you configure and control a specific remote store in the Store List. This pane is displayed when you left-click on the remote store’s icon in the list:
The top of the Remote Store Detail pane shows the remote store’s current status and statistics. You can test connectivity to the remote site by left-clicking on the Test button. This command will attempt to reach the remote store on one of its listed gateway addresses. If no gateway address is reachable, an error message will be reported.
The hosts at a remote site must have joined a store to be reachable from the local store. This ensures that the remote store can receive replicated objects.
Beneath the status display in the Replication Control section, the pane has buttons to control replication to the remote store. Both the Start and the Sync buttons start replication to the remote store. In addition, the Sync button first replicates all local objects (which are subject to replication) to the remote store. This lets you synchronize the contents of an empty remote store to that for the local store prior to beginning ongoing replication of object updates. You can stop replication to the remote stores using the Stop button.
Replication commands are simultaneously performed on all hosts in the local store.
The Remote Site pane also has a table of gateway addresses for the remote store in the Gateways section. This table lists all gateway addresses that have been entered and stored in the client parameters file. Gateway addresses are used to establish communications with the remote store and begin replication of objects to the remote store. (You enter an initial gateway address when you add a remote store to the client parameters file in the Remote Stores pane.)
This pane lets you add more gateway addresses to ensure that you can reliably establish communications with the remote store in case one or more hosts at the remote store are offline. There are two ways to do this. In the Add New Gateway section you can manually enter a gateway address for additional remote hosts in the remote store; press the Add button to add the gateway IP address and gateway server port. (Partial entries can be cleared using the Clear button.) The gateway IP address and gateway server port must be reachable from the local store.
A second and easier way to add gateway addresses to the client parameters file is to left-click on the Populate button in the Gateways section. This command will attempt to connect to the remote store and automatically retrieve the gateway addresses for all active hosts. This avoids the need for you to manually enter a long list of gateway addresses for a large remote store. You can periodically use this command to update the gateway list as the remote site’s configuration changes. You can also remove obsolete gateway addresses from the list by selecting them and pressing the Remove button.
The bottom section of the Remote Store Detail pane lets you configure replication for the remote site to automatically start when the local store becomes active. When you select the desired replication behavior, this information is stored in the client parameters file.
The Remote Client Configuration Pane¶
The Remote Client Configuration pane lets you configure the Remote Client option so that the local server can access a remote SOSS store. This pane is displayed when you left-click on the Client Configuration icon in the list. After installation of the Remote Client option and prior to configuration, the pane appears as follows. The remote client’s configuration status is shown as not configured. Note that the local store has an unknown status because no connection has yet been made to the SOSS store.
By default, the Remote Client Configuration pane’s Location setting is set to On-Premise. This lets you connect to the SOSS store by specifying gateway IP addresses. Alternatively, you can connect to a cloud-hosted store by selecting Cloud instead of On-Premise.
Connecting to an On-Premise SOSS Store¶
The Remote Client Configuration pane has a table of:term:gateway addresses <gateway address> for the remote store in the Gateways section. This table lists all gateway addresses that have been entered and stored in the client parameters file. Gateway addresses are used to establish communications with the remote SOSS store. To establish communications with the remote store, you can enter an initial gateway address in the Add New Gateway section; press the Add button to add the gateway IP address, gateway server port, and the remote store’s management port. The Secure Connection checkbox must match the configuration of the remote store’s gateway configuration for accepting secure connections. (Partial entries can be cleared using the Clear button.)
If the remote client can successfully connect to the remote SOSS store, the remote client’s configuration status automatically will change to connected, and the remote store’s host list will be displayed:
You can now manage the remote store in the same manner that you would manage a local SOSS store.
The Remote Client Configuration pane lets you add more gateway addresses to ensure that you can reliably establish communications with the remote store in case one or more hosts at the remote store are offline. There are two ways to do this. In the Add New Gateway section you can manually enter a gateway address for additional remote hosts in the remote store; press the Add button to add the gateway IP address and gateway server port. (Partial entries can be cleared using the Clear button.) The management port, gateway IP address, and gateway server port must be reachable from the local store.
If you change the management port when adding a new gateway, all gateways will be updated to reflect the new management port.
A second and easier way to add gateway addresses to the client parameters file is to left-click on the Populate button in the Gateways section. This command will attempt to connect to the remote store and automatically retrieve the gateway addresses for all hosts. This avoids the need for you to manually enter a long list of gateway addresses for a large remote store.
You can periodically use this command to update the gateway list as the remote site’s configuration changes. You can also remove obsolete gateway addresses from the list by selecting them and pressing the Remove button.
Connecting to a Cloud-Hosted Store¶
ScaleOut StateServer can be hosted in public clouds, such as Amazon Web Services, as described in the section Deploying SOSS in the Cloud. You can connect the SOSS management tools and remote clients to an AWS-hosted store by selecting Amazon Web Services in the Remote Client Configuration pane.
To connect to a cloud-hosted store, you will need the following information:
- The Access Key and Secret Key of a user associated with the account used to run the remote store. At minimum, this account must be granted the ec2.DescribeInstances permission,
- The AWS region the remote store is running within,
- The name of the remote store as identified in the remote store’s configuration, and
- Whether the remote store requires the use of secure connections.
Once you have this information, this section could be filled out as follows:
Also select whether the connection to the cloud-hosted store should use public or private IP addresses. In most cases, public IP addresses must be used. However, a client application or management tool may be hosted within the cloud environment and able to access the SOSS store using private IP addresses. This may help to minimize network transfer charges.
Click on the Add button to add access information for this store to the soss_client_params.txt file and to display the store in the Store List table.
You can then connect to the selected store to manage it with the SOSS management console by selecting the store in the Store List and clicking the Select as Active button. After several seconds, the connection will be established, and the tree list on the left will display the SOSS hosts in this store. At this point, you can manage the cloud-hosted store identically to an on-premise store:
This selection is also recorded in the soss_client_params.txt file and will automatically be used by client applications to connect to this cloud-hosted store.
You should copy the newly configured soss_client_params.txt file to all cloud-hosted client instances (or other client or management systems) which will connect to this store. When the client application starts up and makes API calls to SOSS, it will use the access information and store selection to connect to the cloud-hosted SOSS store.
You can repeat this process to add additional SOSS stores to the store list and record their access information to the soss_client_params.txt file.
You can switch between SOSS stores to manage multiple cloud-hosted stores by selecting a different active store and clicking the Select as Active button. These stores can be hosted by different cloud providers. Note that the active store is always recorded in the soss_client_params.txt file. Click the Deselect Active Store button will disconnect from the cloud-hosted store and attempt to connect to an on-premise store using gateway IP addresses, or revert to an unconfigured state if no on-premise gateways have been configured (or if the gateways are unreachable).
You can remove a cloud-hosted store from the Store List and the soss_client_params.txt file by selecting the store in the list and then clicking the Remove button.