In the world of web hosting, there is no shortage of tutorials and guides for hosting architectures. However, when it comes to applications based on Microsoft technology that require hosting in IIS, finding a decent, easy-to-follow architecture is surprisingly challenging. The goal is to provide a simple yet effective Windows hosting architecture that serves the purpose of medium-large-sized applications that require scalability and high availability. Depending on the number of users and scale of the application, the configuration can be hardware can be changed, but the architecture should remain the same.
To provide a clear and practical architecture that addresses the core components needed for a functional and reliable setup, the article is divided into 4 areas.
Network Configuration: To discuss how to set up a secure and efficient network infrastructure, including firewalls, load balancers, and DNS settings, to ensure smooth communication between servers and clients.
Web Server Setup: This section will focus on configuring a Windows-based web server (e.g., IIS – Internet Information Services) to host your applications, handle HTTP/HTTPS requests, and optimize performance.
Database Server: A robust hosting architecture requires a reliable database server. We’ll explore how to set up and manage a database server (e.g., Microsoft SQL Server) to store and retrieve data efficiently while ensuring security and scalability.
Backup and Data Recovery: No hosting architecture is complete without a solid backup strategy. We’ll walk through setting up automated backups, storing data securely, and implementing a recovery plan to minimize downtime in case of failures.
By the end of this article, you should have a clear understanding of how to build a simple yet effective Windows hosting architecture that meets your needs.
Network Configuration
A robust network infrastructure is the backbone of any hosting architecture. For a Windows-based hosting environment, ensuring high availability, security, and performance is critical. This is where a redundant pair of active/passive Cisco firewalls and a redundant pair of Layer 7 load balancers come into play. Redundancy is a key principle in designing a reliable hosting architecture. By implementing redundant pairs of firewalls and load balancers, you ensure that your network remains operational even in the event of hardware failures or unexpected issues. Let’s break down why these components are essential and how they contribute to a reliable hosting setup.
Redundant Pair of Active/Passive Cisco Firewalls
Firewalls are the first line of defense in any network, protecting your hosting environment from unauthorized access, malicious attacks, and data breaches. Yes, you can use a WAF or web application firewall for your application. Still, Hardware firewalls are physical devices that serve as a gatekeeper between the network and the external environment, managing traffic and providing security. For large-scale projects, it is better to use a proper firewall to ensure security.
Using a redundant pair of Cisco firewalls in an active/passive configuration ensures:
High Availability: If the active firewall fails, the passive firewall immediately takes over, ensuring uninterrupted protection and minimizing downtime.
Enhanced Security: Cisco firewalls are known for their advanced security features, including intrusion prevention systems (IPS), deep packet inspection, and VPN support, which safeguard your network from external threats.
Scalability: As your hosting needs grow, Cisco firewalls can handle increased traffic and adapt to more complex security requirements.
In an active/passive setup, one firewall actively manages traffic while the other remains on standby, ready to take over in case of a failure. This redundancy is crucial for maintaining uptime and ensuring business continuity.
Redundant Pair of Layer 7 Load Balancers
Load balancers are essential for distributing incoming traffic across multiple web servers, ensuring optimal performance and preventing server overload. Using a redundant pair of Layer 7 load balancers provides the following benefits:
Traffic Distribution: Layer 7 load balancers operate at the application layer, meaning they can make intelligent routing decisions based on content, such as URLs or cookies. This ensures that traffic is evenly distributed across your web servers, improving response times and user experience.
High Availability: Similar to the firewalls, a redundant pair of load balancers ensures that if one fails, the other can seamlessly take over, preventing service disruptions.
Health Monitoring: Layer 7 load balancers can monitor the health of your web servers and automatically route traffic away from any server that is down or underperforming.
SSL Offloading: By handling SSL/TLS termination at the load balancer level, you can reduce the computational load on your web servers, improving overall performance.
Web Server Setup
Once the network infrastructure is in place, the next critical component of your hosting architecture is the web server layer. For a scalable and high-performance Windows hosting environment, it’s recommended to use multiple web servers behind a load balancer. This setup ensures that your application can handle increasing traffic loads while maintaining high availability.
Load-Balanced Multiple Web Servers
Depending on your application load and requirement you can add from 2 to n number of the web server in this layer. You need to ensure that each web server is configured identically to maintain consistency in application behavior.
Here’s why this approach is beneficial:
Scalability: Adding more web servers allows you to scale horizontally, distributing the load across multiple machines. This ensures that your application can handle traffic spikes without performance degradation.
Fault Tolerance: If one web server fails, the load balancer will automatically route traffic to the remaining servers, ensuring uninterrupted service.
Performance Optimization: By distributing traffic evenly, you can reduce the load on individual servers, improving response times and overall user experience.
To implement this, configure your Layer 7 load balancer (discussed in the Network Configuration section) to distribute incoming HTTP/HTTPS requests across all available web servers.
IIS Synchronization for Code Deployment
One of the challenges of managing multiple web servers is ensuring that all servers have the same codebase and configuration. This is where IIS (Internet Information Services) synchronization comes into play. By synchronizing your web servers, you can ensure that any code or configuration changes made on one server are automatically replicated to the others. Here’s how to achieve this:
Shared Configuration: Use IIS’s shared configuration feature to store configuration files (e.g., applicationHost.config) in a central location, such as a network share or a cloud storage service. This ensures that all web servers use the same settings.
Web Deploy Tool: Microsoft’s Web Deploy Tool is a powerful utility that allows you to synchronize websites, applications, and content across multiple servers. When you release new code on one server, Web Deploy can automatically replicate the changes to all other servers in the farm.
Automated Scripts: For advanced setups, you can create scripts (e.g., using PowerShell) to automate the synchronization process. This ensures that code deployments are consistent and error-free.
Database Server
The database is the heart of any application, storing and managing critical data. For a robust Windows hosting architecture, it’s essential to ensure that your database layer is both performant and highly available. There are a few options that you can choose from like Failover cluster, database mirroring, log shipping etc. But two Microsoft SQL Server instances in a failover cluster configuration, provide better redundancy and minimize downtime in case of failures.
Why Use a Failover Cluster?
A failover cluster is a group of servers that work together to provide high availability for applications and services. In the context of Microsoft SQL Server, a failover cluster ensures that if one database server fails, the other server automatically takes over, ensuring uninterrupted access to your data. Here’s why this setup is crucial:
High Availability: By using two SQL Server instances in a failover cluster, you eliminate single points of failure. If the primary server goes down, the secondary server takes over seamlessly, minimizing downtime.
Data Integrity: Failover clusters ensure that your data remains consistent and accessible, even during hardware or software failures.
Scalability: This setup allows you to scale your database layer as your application grows, without compromising on reliability.
Alternative to Failover Cluster: SQL Server Always On Availability Groups
While a failover cluster is a robust solution for high availability, it may not be the best fit for every scenario. For example, setting up a failover cluster requires shared storage and can be complex to configure and maintain. If you’re looking for a more flexible or simpler alternative, SQL Server Always On Availability Groups is an excellent option.
Always On Availability Groups (AGs) are a high-availability and disaster recovery solution introduced in Microsoft SQL Server 2012. They provide database-level redundancy by allowing you to group multiple databases into a single availability group and replicate them across multiple SQL Server instances. Here’s why AGs are a great alternative:
Database-Level Redundancy: Unlike failover clusters, which operate at the instance level, AGs work at the database level. This means you can replicate specific databases rather than the entire SQL Server instance, providing more granular control.
No Shared Storage Required: AGs do not require shared storage, simplifying the infrastructure and reducing costs.
Readable Secondaries: Secondary replicas in an AG can be configured as read-only, allowing you to offload read operations (e.g., reporting or analytics) to the secondary server, improving performance.
Automatic or Manual Failover: AGs support both automatic and manual failover, giving you flexibility in how you manage high availability.
When to Choose Always On Availability Groups Over Failover Clustering
Granular Control: If you only need high availability for specific databases, AGs are a better choice.
Cost Efficiency: AGs eliminate the need for shared storage, reducing infrastructure costs.
Read-Only Workloads: If you want to offload read operations to secondary replicas, AGs provide this capability out of the box.
Other Alternatives
Database Mirroring: An older high-availability feature that provides database-level redundancy. However, it’s deprecated in favor of Always On Availability Groups.
Log Shipping: A simpler solution for disaster recovery, where transaction logs are periodically shipped and applied to a secondary server. While it’s not as robust as AGs or failover clustering, it’s easier to set up and maintain.
Comparison Table
| Feature | Failover Clustering | Database Mirroring | Log Shipping | Always On Availability Groups |
|---|---|---|---|---|
| Scope | Instance-level | Database-level | Database-level | Database-level |
| Failover | Automatic | Automatic/Manual | Manual | Automatic/Manual |
| Shared Storage | Required | Not required | Not required | Not required |
| Cost | High (Enterprise hardware) | Moderate | Low | High (Enterprise Edition) |
| Complexity | High | Moderate | Low | High |
| Readable Secondary | No | Yes (with limitations) | No | Yes |
| Deprecated | No | Yes (since SQL Server 2012) | No | No |
| Best Use Case | High availability | High availability | Disaster recovery | High availability + Disaster recovery |
Dedicated Storage Layer for Backup
No hosting architecture is complete without a reliable backup and recovery plan. Data loss can occur due to hardware failures, software bugs, human errors, or even cyberattacks. To safeguard your data, it’s essential to implement a dedicated storage layer for backups, coupled with a comprehensive backup strategy.
Why a Dedicated Backup Storage Layer?
A dedicated storage layer for backups ensures that your data is securely stored, easily recoverable, and protected from accidental deletion or corruption. Here’s why it’s critical:
Disaster Recovery: In the event of a catastrophic failure, backups allow you to restore your application and data quickly, minimizing downtime.
Compliance: Many industries require businesses to maintain backups for regulatory compliance.
Data Integrity: Regular backups ensure that you can recover from data corruption or accidental deletions.
It is important to Maintain at least three copies of your data (primary + two backups), store them on two different types of media, and keep one copy offsite or in the cloud. Periodically test of your backups are very important to ensure they can be restored successfully.
Using Commvault for Backup
Commvault is a powerful enterprise-grade backup and recovery solution that provides a unified platform for managing backups across on-premises, cloud, and hybrid environments. Here’s how to leverage Commvault for your backup strategy:
Centralized Management: Commvault provides a single interface to manage backups for your entire infrastructure, including databases, web servers, and file systems. You can define backup policies, schedules, and retention periods from a centralized console.
Incremental and Differential Backups:
Commvault supports incremental and differential backups, reducing the amount of data transferred and stored during each backup cycle. This saves storage space and minimizes backup windows.
Application-Aware Backups:
For Microsoft SQL Server, Commvault offers application-aware backups that ensure transaction consistency and enable point-in-time recovery.
Cloud Integration:
Commvault supports backing up data to cloud storage providers like AWS, Azure, and Google Cloud, providing flexibility and scalability.
Automated Recovery Testing:
Commvault allows you to automate recovery testing, ensuring that your backups are valid and can be restored when needed.
Alternative Backup Solutions
If Commvault is not an option, there are other reliable backup tools and strategies you can consider:
Veeam Backup & Replication: A popular backup solution for virtualized environments, Veeam offers features like instant VM recovery, application-aware backups, and cloud integration.
Microsoft Azure Backup: If your infrastructure is hosted on Azure, Azure Backup provides a seamless and scalable solution for backing up VMs, SQL Server, and file systems.
Here’s a quick recap of the architecture:
Redundant pair of Cisco ASAv firewalls (active/passive) for high availability and security. Redundant pair of Layer 7 load balancers to distribute traffic across web servers and ensure fault tolerance.
Multiple load-balanced web servers (e.g., IIS) to handle application traffic. IIS synchronization for seamless code deployment across servers.
Two Microsoft SQL Server instances configured in a failover cluster for high availability. Alternatively, SQL Server Always On Availability Groups for more granular control and flexibility.
Commvault Simpana Enterprise for centralized backup management and disaster recovery.
Below is a simplified diagram of the hosting architecture:
