Planning for Deployment

Before installation takes place it’s important to know exactly what the final deployment should look like. Planning your SmartIQ eployment includes determining the environments to be deployed – e.g. Development, Test, Production, etc. – and also how each environment is to be used, likely volumes and throughput requirements.

This section takes you through the more common deployment planning topics:

• Environments
• Architecture and Topology
• Scaling and High Availability
• Multi-Instance Environments

Environments

SmartIQ is most commonly deployed across at least three environments to reflect an organization’s development and testing regimes.

The following table defines some commonly used environments:

Each environment will have many unique qualities, including audience, business requirements, load expectations, backup and recovery schemes.

Architecture and Topology

The server components of SmartIQ can be deployed on a number of topology configurations, depending on how the target environment will be used. Each server used as part of an overall deployment will need to meet the minimum system requirements for that server, as outlined in System Requirements section System Requirements].

The following typologies are described below:

• Single Server Deployment
• Standard Two-Tier Deployment
• Standard Scale-Out Deployment
• Three-Tier Deployment

Single Server Deployment

Single server deployments consist of one server running the IIS and SQL Server, hosting both the SmartIQ web applications and the SmartIQ database. This is suitable for simple environments such as a local developer machine, or a development or test server for small teams.

Standard Two-Tier Deployment

This is the most common model, using a two-tier deployment topology where the SmartIQ web components are deployed on a web server and the database is deployed on a separate database server. This configuration is suitable for most environment types including development, testing, and small-medium staging/production environments.

Standard Scale-Out Deployment

For high volume environments, the web server tier can be scaled out across multiple physical or virtual machines, sometimes referred to as a server farm. A load balancer is installed to balance website traffic and make better use of server resources under load.

SmartIQ works with any load balancer that supports ASP.NET applications running within an IIS environment, such as Microsoft IIS Application Request Routing (ARR), F5 and other third-party load balancers.

It is also recommended for scale-out models to set up multiple databases in a failover cluster, ensuring highest possible availability of data.

Server High-Availability solutions, including:

• AlwaysOn Failover Cluster Instances
• AlwaysOn Availability Groups
• Database Mirroring
• Log Shipping

📘

Configuration

Microsoft provides comprehensive documentation on setup and configuration for load balancing with ARR and for SQL Server High-Availability Solutions. For other third-party load balancers, please refer to the documentation supplied by that vendor.
Deploying SmartIQ under Azure PaaS allows for leveraging the elasticity of the cloud, setting auto-scale rules, traffic manager and other mechanisms that allow the App to adjust required resources based on real-time demand.

Three-tier Deployment

Some environments require a three-tier deployment topology, e.g. to create additional separation between an external-facing DMZ and the internal network. In these scenarios, a Reverse Proxy is typically used as the external-facing tier, with the web server as the second tier and database server as the third tier.

The three-tier deployment can also be scaled out with load balancer and database failover cluster as described above.

Scaling and High Availability

SmartIQ has been built for scale and reliability, using standard approaches recommended y Microsoft for ASP.NET, IIS and SQL Server. Even fairly small server deployments under most circumstances will perform quite well serving a number of concurrent users. However, as with any server deployment, it’s important to consider scale and availability requirements early, and understand how to meet the current requirements now and adapt to meet future requirements.

When planning for scale and high availability, there are a number of factors to consider.

These include:

• How many users may be accessing the site during peak and off-peak times?
• Will the system be performing unattended background tasks, and will this affect peak / off-peak users?
• What type of workloads will the system be performing during peak and off-peak times? For example:
  • Form access and page navigation
  • Form submissions
  • Document generation
• How critical to the business are these workloads, and the performance and availability expectations? For example, an organization may deem that background document generation processes can tolerate more inconsistency in performance than highly visible customer facing forms.
• What costs are associated with scaling the environment? Take into account hardware, operating systems, database server licensing as well as additional configuration and maintenance efforts.
• While every environment and usage are different, the following general guidelines may be followed to help with planning a new deployment:
• Higher user loads increase consumption of memory.

📘

Note:

Each session will vary in size depending on the size and complexity of the forms in use.

It is possible to calculate either using a development environment to measure actual memory consumed per user and extrapolate based on expected user loads, or by using an estimate.

• Higher document generation and form submission rates increase the load on CPU and network.

As a rule of thumb, each form submission (including any document generate activity and delivery actions) will consume 100% of a processor core for the duration of the task. For example in a four-core processor environment, four concurrent submissions will not experience any performance degradation while any additional submissions will require the CPU to divide time between tasks extending the time to complete each one.

Vertical and Horizontal Scaling

SmartIQ supports both vertical and horizontal scaling. Vertical scaling involves increasing RAM and/or CPU cores available on each server, and horizontal scaling involves configuring additional servers in a farm with a load balancer. Note that SmartIQ supports both virtual and physical server environments.

In some cases, it is worth considering deploying a separate environment for background document generation tasks if they are likely to interfere with the anticipated volumes of interactive users

High Availability

High availability is achieved by adding redundancy to the system – specifically by deploying multiple IIS web servers with a load balancer, and multiple SQL Server databases using a technology such as SQL Server AlwaysOn failover clusters.

📘

Microsoft MSDN Documentation

For more information about scaling and high availability, refer to the Microsoft MSDN documentation for IIS and SQL Server.

Multi-Instance Environments

Under some circumstances, it may be necessary to install multiple instances of SmartIQ as part of the one environment, in particular where multiple instances of SmartIQ Produce or Manage require varying configurations for different audiences or purposes.

The most common example of this is allowing mixed authentication methods. For example, a Production environment may need to allow internal network users to access the system with Windows Authentication, while external users must access the system with Forms Authentication.
This approach typically involves configuring two instances of the SmartIQ web applications, both referring to a single instance of the SmartIQ database so that forms, rules, and content templates are shared between the two instances.

Restricted Hosting mode

In cloud environments, or certain multi-instance environments, it may be important that SmartIQ is not able to access files on the server filesystem. In these cases, the application may be configured to restrict access to local files.

🚧

Important

If Restricted Hosting Mode has been configured in cloud environments, Manage, Produce API as well as the REST and Webservice data extensions will no longer be able to use Windows authentication.

{
  "AppSettings":
    {
      "RestrictedHosting": "true"
    }
}

This will prevent local file reads (such as a CSV Data Source using an on-disk file for default data) and writes (such as the Save To Disk Action).