Server Roles

In many cases all of the services can be provided by a single server running in your data center.  In this scenario log data is stored locally on the server and either a local or remote SQL Server can be used.  All of the server roles are hosted on one server and the Session Repository and Working Repository are on the same machine.  The SQL Server may be local or remote.

This is the default configuration and is suitable for most small and mid-scale deployments.

To add both redundancy and load balancing a second server can be added with each server hosting every role.

To support multiple servers it’s required to use one or more file shares for data storage.  To provide a completely redundant solution the file share and SQL Server would need to have their own appropriate redundancy scheme (such as Microsoft Cluster Server (MSCS) or SQL Always On).  You’ll also notice that you’ll need to provide your own reverse proxy to distribute load between the Loupe servers.  Loupe supports simple round-robin and other stateless load balancing.

To maximize system scalability it’s possible to separate out the various roles of the server to run on separate systems.  Depending on your redundancy and scalability requirements you can have any number of Web UI, Transport, and Analysis servers.  Live Stream Servers work in a fail-over fashion with one being active at a time.  Multiple Analysis servers will dynamically share load and tasks.  The Web UI and Transport servers can be load balanced and even have separate URL endpoints to conform to network security restrictions and improve performance.

It’s also possible to employ multiple storage servers and multiple database servers to distribute the load and storage space required, allowing a virtually unlimited amount of log data to be stored and managed.

Separate Web UI and Agent API Servers

In the following diagram, each role has been distributed across a load balanced pair of servers.  The Transport and Web UI servers need an external load balancer to distribute traffic between them.  The Analysis servers don’t require this as there is no direct access from clients to the analysis servers.

Static Content Servers

Loupe supports setting up instances that only serve static content for the web site.  These server instances will never open any database connections or process any dynamic data so they can be safely used with a CDN or other aggressive caching system.  Since they don't process any dynamic data there are no licensing requirements to use this feature (it is available for each edition and does not require the license be registered or any license be purchased).

You can extend any Loupe Server environment to retrieve session data from another environment by subscribing to it.  This allows a remote Loupe Server to gather data and a central Loupe Server to aggregate that information with information from other sources.  This can be particularly useful in secure environments to create a public Transport Server and keep the main Loupe Server inside a more secure network.

Remote servers can send all of their information to the remote Loupe Server environment while your secure environment retrieves all information from it.  This can be useful when:

• Network Security Restrictions Prevent Inbound Traffic: Remote applications send data to the remote Loupe Server who stores it until it is pulled from the internal Loupe Server.  All connections are established from the internal network to the external network, even working through standard HTTP proxies.
• Bandwidth is Limited: The connection between the Loupe Server environments pulls data at a predictable rate that can work over lower bandwidth connections without delaying data from the remote servers.
• Separation of Information: In some cases you may want to have one server for all Production activity and a separate one the development team uses where the development team wants all sessions but the Production teams only want to see some information.
• Extending the Loupe Service: If you want to do custom processing of your session data but not host the primary Loupe Server environment you can set up an Internal Server just to perform the custom analysis and integrate with your internal systems but have your teams operate solely from the remote instance.

In some cases you can't reasonably run the Loupe installation on each computer where you need to host Loupe.  For example, if you want to set up a server farm and are using auto-created VM's or other common infrastructure it's often not feasible to either run an installation each computer or even register a license.  Some components of Loupe - notably the web portions (but not the Analysis or Live Stream features) can be deployed in this way.

To do so, you need to first need to use one computer to set up your Loupe Enterprise installation. This computer will be used to define the initial clusters, servers, and other elements necessary for the environment to run.  Once you've completed this, you can create an XCopy-deployable version of the site by copying the relevant folders to the locations you need for each component of Loupe:

For the Web API and the Loupe Service:

1. Copy the entire Web.API folder from the Loupe Server installation directory (C:\Program Files (x86)\Gibraltar Software\Loupe) to the root of your web site.
2. To provide the static website from the same endpoint as the Web API, copy the Web.UI folder to a peer directory of the Web.API deployment location.
3. Create an App_Data folder within the root of the Web folder in your new copy.
4. Copy the server.config file from C:\ProgramData\Gibraltar\Configuration into the App_Data folder.
5. Contact Gibraltar Software for a deployable license file.  This prevents you from needing to run the licensing tool on each server.  Contact us at support@gibraltarsoftware.com.
6. Place the deployable license files (*.glo) into the App_Data folder.

If you know the exact names of the servers you will be deploying to, you can enter them in the cluster configuration using the Loupe Server Administration tool and you're ready to go.  In situations where the names are unknown - such as using Azure Web Sites - you need to change the configuration file to specify a substitute server name for the web site to use to look up its configuration.  To do this, add a serverName attribute to the multitenant element, like shown below:

<?xml version="1.0" encoding="utf-8"?>
<gibraltar>
  <multitenant serverName="YOUR COMMON SERVER NAME HERE" /> 
  <!-- Most of the configuration file omitted for brevity -->
</gibraltar>

Be sure the server name you enter is configured as a server in Loupe Server Administrator.  This is the name the web site will use to look up its configuration and determine what repositories it should host and other configuration items.

Server Administration