Before installation takes place it’s important to know exactly what the final deployment should look like. Planning your Infiniti deployment 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
Infiniti 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:
Local
Individual’s local computer or laptop, often a single machine deployment.
Development
Shared development area or sandbox.
Testing
Test area for functional, performance, Quality Assurance or User Acceptance Testing.
Staging/Pre-production
Mirror of production environment used to test releases in a production-like environment.
Production
Live production environment for end users.
Each environment will have many unique qualities, including audience, business requirements, load expectations, backup and recovery schemes.
The server components of Infiniti can be deployed in 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 deployments consist of one server running the IIS and SQL Server, hosting both the Infiniti web applications and the Infiniti database. This is suitable for simple environments such as a local developer machine, or a development or test server for small teams.
Single Server Topology
This is the most common model, using a two-tier deployment topology where the Infiniti 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 Two-Tier Topology
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.
Infiniti 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 Infiniti databases in a failover cluster, ensuring highest possible availability of data. Infiniti works with any of the SQL
Server High-Availability solutions, including:
- AlwaysOn Failover Cluster Instances
- AlwaysOn Availability Groups
- Database Mirroring
- Log Shipping
Standard Scale-Out Topology
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 Infiniti under Azure PaaS allows to leverage the elasticity of the cloud, allowing to set auto-scale rules, traffic manager and other mechanisms that allow the App to adjust required resources based on real-time demand.
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.
Three-tier Topology
The three-tier deployment can also be scaled out with load balancer and database failover cluster as described above.
Infiniti has been built for scale and reliability, using standard approaches recommended by 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:
Note that 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.
Infiniti 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 Infiniti 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 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.
Under some circumstances, it may be necessary to install multiple instances of Infiniti as part of the one environment, in particular where multiple instances of Infiniti 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 Infiniti web applications, both referring to a single instance of the Infiniti database so that forms, rules, and content templates are shared between the two instances.