Select the Riva Insight On-Premise Deployment Model

The primary challenge with deploying Riva Insight On-Premise is to handle high availability – especially in organizations that are not familiar with web technologies or do not host other scaled web-applications.

Three configurations are possible, in increasing order of availability, but only the third offers high availability.

• Single node,
• Two or more servers, and
• Multi-node cluster.

Single Node

The simplest configuration is of course a “single node” where both the web server and the connectors exist in a single instance of IIS. This same “single node” could also include multiple versions of Riva Insight to allow for UAT/QA if needed. For small deployments, this works well. For a “test / development” environment, this provides the most flexibility.

Two or More Servers

When working with two or more servers, each server is used for a different application release stage; for example DEV, UAT/QA, and PROD.

This configuration allows the non-production server to be managed during the day with less restrictive change management controls.

Multi-Node Cluster

For deployments that exceed 500 users or deployments where the Recovery Time Objective (RTO) must be near 0-hour, then a multi-node cluster may be the best option.

Scaling Out (more servers) rather than Up (faster servers) is our recommendation as it provides load balancing of the work and adds redundancy to the environment. 

If the only option is to have one server then we would recommend that additional worker processes be added to the Application Pools when 500 or more users will be access the server. However this configuration would lose the benefit of the high availability of a Multi-node, load balanced environment.

This is of course the most complex configuration, requiring much more network infrastructure and web technology skills. It is recommended to also include this configuration in a pre-production “QA / UAT” application stage for full Advanced Load Management (ALM); however, this could be skipped, depending on the application team requirements.

Riva itself does not provide a specific load balancer technology. The configuration can be either Active/Passive or Active/Active, depending on the load balancer technology used. 

• For Active/Passive, a standard heart-beat check on a VIP would work.

• For Active/Active, a “sticky” load balancer is required, either a simpler “Source IP” based option or a more advanced Layer 7 “Cookie” option.

• The storage replication is typically done by using Windows DFSR and is simply there to copy the IIS configuration and application files between the servers.

• As an alternative for storage replication, a third server can be used as a UNC share to host the files; however, this creates another single point of failure, unless the UNC path is highly available.

System requirements:

• System Requirements are determined by RTO (recovery time objective) / RPO (recovery point objective).

• As a general basic guideline, here are the suggested minimum requirements:

  • VM Windows Server 2016 or later,
  • 4 vCPU,
  • IIS,
  • ASP.NET 4.7.2 or 4.8
  • 8 GB of RAM, and
  • 60 GB of storage.
     

• If a load balancer is being used, it is suggested that it support sticky sessions either via source IP or HTTP Header/Cookies.

• Larger deployments: Two VMs, each with

  • Windows Server 2016 or later,
  • 4 vCPU,
  • IIS,
  • ASP.NET 4.7.2 or 4.8,
  • 8 GB of RAM, and
  • 60 GB + 100 GB of storage.