The ScaleOut GeoServer option’s push access mode replicates object updates to a maximum of eight remote SOSS stores. Object updates include:
- newly created objects,
- updates to existing objects, and
- requests to remove existing objects. Objects created using the APIs optionally can be tagged to not be replicated. ASP.NET session objects are always replicated to remote stores.
Objects are automatically created on the remote site if necessary. Requests to remove non-existing objects are silently ignored. All object attributes, including timeouts, LRU behavior, and dependency relationships are replicated to the remote site. However, object timeouts are reset to their initial value upon arrival at a remote site.
Object replication is unidirectional. The GeoServer option is configured to send objects to a remote SOSS store. In order to receive updates from the remote farm, the GeoServer option must be configured on the remote store to send object updates to the local store.
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. Objects sent to a remote site are tagged to disallow further replication upon their arrival at the remote site. To replicate objects from site A to sites B and C, configure site A to replicate objects directly to both sites B and C. Details on configuring the GeoServer option can be found in the section Configuring the GeoServer Option.
Scalable, Highly Available Replication
Unlike most replication solutions, GeoServer uses scalable and highly available connections that take full advantage of all servers in each farm. To maximize performance and availability, all servers within both the local and remote StateServer farms participate in data replication, as shown in the following diagram:
As servers are added or removed at each farm, GeoServer automatically reconfigures its network connections to maintain the best possible replication performance without the need for manual intervention.
When replication to a remote store is started, all local hosts are notified to begin replication. Each local host first establishes a TCP connection to one of the gateway addresses stored in the client parameters file for the remote store (see Configuration Parameters). By storing multiple gateway addresses in the parameters file, you can ensure that the initial connection is successful, even if one or more remote hosts are offline. Note that you should have configured the gateway addresses to use a secure communications channel.
Once a connection is established, the local SOSS hosts automatically download a list of the gateway addresses for all hosts in the active store. In addition, they download load-balancing information that is used to direct object updates most efficiently to individual hosts in the remote store. This information is automatically updated whenever a membership or load-balancing change occurs at the remote store.
All local SOSS hosts next establish TCP connections to every host in the remote store and then begin forwarding object updates to the remote store. Since all local hosts participate in handling local object updates, they can concurrently replicate these updates to the remote store. This maximizes both the throughput and scalability of data replication. Likewise, it helps ensure that data replication is not interrupted if a host in either the local or remote store should fail.
If the communications link to a remote store fails or if all hosts in the remote store fail, object replication pauses, and the local store signals an Unknown status. Each host in the local store repeatedly attempts to reconnect to all known gateway addresses for the remote store. Object replication automatically resumes once the TCP connections are re-established.
Memory Usage
To avoid adding latency to local access requests, object replication completes asynchronously with respect to local updates. For each object update to be replicated, a descriptor of approximately 320 bytes (not including object metadata) is enqueued in memory within the local StateServer service. (For efficiency, object data is not copied to the replication request queues.) If the rate of object replication is lower than the rate of local object updates or if the remote store cannot be reached, an increasing amount of memory will be consumed within the local SOSS store to buffer these outbound descriptors.
The local SOSS store automatically stops enqueuing replication requests and flushes all enqueued descriptors if the memory consumed for all stored objects and descriptors reaches a specified threshold on any host. This threshold can be set using the repl_threshold configuration parameter (see Configuration Parameters). In this situation, some replication requests will be permanently lost, and the remote store will not receive all objects from the local store. It is important to use a highly reliable and fast communication link to the remote store to avoid interrupting replication and losing object updates.
