The ScaleOut GeoServer option lets you quickly and efficiently replicate (push) cached data to a remote server farm for immediate access after a site-wide failure. It also lets applications transparently access (pull) and synchronize data across a set of geographically separated stores.
![[Note]](../common/images/admon/note.png) |
Note |
|---|---|
|
For details on the GeoServer Option’s theory of operation, please see the section GeoServer Option. For details on using the APIs to access remote objects, consult the Named Cache documentation for .NET, Java, or C++. |
Push Access Mode
Using push access mode, this option can be configured on each SOSS store to replicate object changes to a remote store, including:
- new objects that are created on the local SOSS store,
- objects that are updated on the store, and
- objects that are removed from the store. Objects created using the APIs optionally can be tagged to not be replicated. ASP.NET session objects are always replicated to remote stores.
In push access mode, the GeoServer option is configured to replicate objects from a local SOSS store to a remote SOSS store. It enables object replication in one direction only. If the GeoServer option is also licensed on a remote SOSS store, it can be separately configured to replicate objects to the local store. For example, to configure GeoServer to replicate objects bi-directionally between sites A and B, it must be configured on site A to replicate objects to site B and then configured on site B to replicate objects to site A.
|
Note |
|---|---|
|
The GeoServer option does not support cascading data replication, for example replicating objects from site A to B and then forwarding site A’s objects to site C. To replicate objects from site A to sites B and C, configure site A to replicate objects directly to both sites B and C. |
Once push access mode has been configured, all objects in the store will be subject to replication by default; every create, update, and delete operation performed on an object will be sent across the WAN connection to the remote datacenter(s) in order to keep objects in the stores synchronized. In addition, local read operations to objects with timeout values will cause messages to be periodically sent across the WAN in an efficient manner that minimizes WAN bandwidth. This keeps object timeouts synchronized at the remote store.
Pull Access Mode
Using pull access mode, objects are only transmitted across a WAN to remote datacenters as the objects are requested. Furthermore, the frequency that remote sites refresh their copies (called proxies) of an object can be adjusted by setting up a coherency policy that controls how out-of-date a replicated object may become before it is refreshed in a remote datacenter. A loose coherency policy can result in reduced bandwidth usage between sites when compared to push replication, since fewer updates are sent across the link between datacenters. Ownership of an object also can migrate from datacenter to datacenter. The datacenter that contains the master copy of an object relinquishes its ownership if an application in a remote datacenter acquires a lock on a proxy of the object.
In pull access mode, the GeoServer option is configured to access objects on a local SOSS store from a remote SOSS store. It also pushes updates made on a proxy object within a local store to the master copy on a remote store. If the GeoServer option is also licensed on a remote SOSS store, it can be separately configured to access objects at the remote store from the local store. For example, to configure GeoServer to access objects bi-directionally between sites A and B, it must be configured on site A to access objects residing on site B and then configured on site B to access objects residing on site A. Because the mastership of an object can migrate from store to store, it is highly recommended that GeoServer pull replication to be configured in both directions. When more than two stores are combined using pull mode, each store should be configured to access all other stores.
Once pull replication has been configured, access to remote objects occurs when a local access to an object fails to find the object in the local store. The set of remote stores to be checked for the object and the order in which they are checked can be specified separately for each object namespace using the Named Cache APIs. Unless a locking read access or lock request is performed (see below), the original object (called the master) remains at the remote store and a proxy is created at the local store which initiated the access. Subsequent accesses at the local store are then directed to the local proxy object. Hence reads do not consume WAN bandwidth. However, updates and deletes are pushed across the WAN and update the master.
Each stored object can be configured to allow or disallow remote access and to specify a policy (called the coherency policy) by which changes to a master object are propagated to remote proxy objects. This policy determines how often WAN bandwidth is consumed to update the proxy objects. The Named Cache APIs provide multiple coherency policies.
If a locking read or lock request is performed on an object, this operation is always directed to the master object, which may reside at a remote store. If the master object is found remotely, it migrates to the requesting store and is replaced by a proxy object at the remote store. This ensures that exactly one master object resides across all participating stores, and it enables updates to this object to be synchronized across the stores.
Configuration Steps
To configure the GeoServer option for data replication from a local site to a remote site, please follow these steps:
- Ensure that a secure, reliable, and fast network exists to the remote site. The network must be fast enough to handle the expected replication traffic so that excess memory is not consumed on the local store to buffer outbound requests. The available bandwidth should match or exceed the local store’s aggregate access rate.
- If pull access mode is to be used, set the local store’s name using the Management Console.
-
On the remote SOSS store, configure a unique gateway IP address and gateway server port on all SOSS hosts. The IP address/port pair must be reachable from the local store using a TCP connection, and this pair must map to the SOSS server port on the remote host.
Note The gateway IP address may be on a different subnet from that used for the remote store’s network interface. Also, if a router is used at the remote store and port mapping is employed, the gateway port may not match the SOSS server port’s value.
-
On the local SOSS store, add a remote store to the GeoServer configuration using either the SOSS management console Management Console or the geos.exe command-line program (see Command-line Control Programs). To add a remote store, you enter one of the remote store’s gateway addresses in order to establish communications with the remote store. You can also optionally add additional gateway addresses for other SOSS hosts in the remote store in case one or more hosts are offline. Also select the access mode (push or pull).
Note The GeoServer configuration for remote stores is recorded in the client parameters file, soss_client_params.txt (see Configuration Parameters), which 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.
- Ensure that the remote store has been made active by joining all hosts.
-
Test communications with the remote store by using the Test command in SOSS Console or geos.exe.
Note The remote store must be active to test communications. However, the local store may be inactive.
-
If communication with the remote store is successful, you can use the Populate command to download the gateway addresses from all active hosts on the remote store and save them in the local store’s client parameters file. This ensures that you can establish communications with the remote store if any of these gateway addresses respond. (Gateway addresses for offline hosts are ignored during replication.)
Note You should periodically re-run the Populate command if new hosts are added to the remote store.
Note Gateway addresses are permanently stored in the client parameters file. If you know that a gateway address is no longer used at the remote store, you should remove it from the local store’s client parameters file using the management tools.
- Ensure that the local store has been made active by joining all hosts.
- If the push access mode is to be used, start replication of object updates to the remote store using either the Start or Sync command. The Start command begins ongoing replication of object updates, and the Sync command first replicates all locally stored objects before beginning replication of object updates.
- If pull access mode is to be used, start remote access of objects from the remote store using the Start command.
- If push access mode is used, verify that replication is proceeding normally by examining the replication status using the SOSS Console or geos.exe.
