SyncDog SentinelSecure™ Architecture

The main function of SentinelSecure™ is to provide mobile application security through the use of secure containers. SentinelSecure™ allows your organization to control and manage how your people exchange relevant, time-critical information across tablets and wireless handheld devices. There are two different versions of SentinelSecure’s™ containerized solution:

SyncDog SentinelSecure™ is designed to handle the complexities of diverse, large-scale enterprise IT environments and offers several flexible deployment scenarios.

1. Single Relay: Most basic implementation of SentinelSecure™

This model contains a single relay server, and a single transport server. The SQL Server database exists on the transport server. (Click on diagrams to enlarge)

Click to view architecture

2. Dual Relay Implementation: Relay scalability and failover

Because of the highly dynamic state of the relay messages and the speed at which they are processed, relay message queues are not persisted across multiple servers. Relay scalability is achieved primarily by device-side policy. When a user provisions, part of the user policy and configuration package that is sent to the device will include a list of relays along with a connection priority value. When a device wants to initialize a connection to the server, it will attempt to connect to the highest priority relay first, and if it gets a valid response from the server allowing to connect and initialize, it will continue to use that relay for subsequent requests. If it does not get a valid response from the relay, or if the attempted connection was disallowed because the relay responds and says it is too busy to accept new connections, the device will try to connect to the next highest priority relay, and so on. This scenario requires relays to be performance aware, and to know when they are too busy to accept new connections.

Click to view architecture

3. Load balanced implementation: Configuring transport servers for balanced load and failover

Transport servers can be configured for load balancing and failover in two ways:

  1. As with the relay, a system administrator should be able to configure a static number of maximum connections that are allowed to be concurrently running on the transport servers.
  2. The servers should be self-monitoring to refuse connections based on RAM usage and constant CPU performance.

Once the failover thresholds have been crossed, the transport server would send a message to the relay telling the relay to pause queuing connections for it until it gets another message that allows it to respond to messages again. SyncDog SentinelSecure™ allows for the creation of a “transport server pool” in which three transport servers could all be pulling from the same relay.

Click to view architecture

4. Load balancing implementation with SQL synchronization

Whatever transport configuration is chosen by the system administrator, a current user and policy database must be shared between all the transport servers. Administrators would install a SQL Server cluster to which all the transport servers connect to interact with data. Data access and redundancy would be handled internally in SQL Server and would be abstracted away from SentinelSecure™ setup. All transport servers would simply connect to the cluster and retrieve their data.

Click to view architecture