IIS Farm and Application Request Routing



    Most recently, my colleagues wrote several articles about shared hosting based on Cloud Linux, and today I will tell you about Microsoft technologies that we use for Windows hosting services . We will talk about a bunch of IIS 8.5 and Application Request Routing (ARR).

    ARR is an extension for IIS that allows you to assemble multiple IIS servers into a single farm. It allows balancing the load of HTTP traffic, using routing rules, and can act as a caching Reverse Proxy server for offloading the main content delivery servers.
    ARR can distribute traffic in various ways:
    • Weighted round robin is the easiest type of balancing. Requests will be distributed among all servers in turn.
    • Weighted total traffic - requests will be distributed based on their size, and redirected to less busy nodes.
    • Least response time - the request will be sent to any server that responded before everyone else.
    • Sticky sessions - in this mode, all client requests within the session will be transmitted to the same server.

    Another very important feature is the ability to use URL filtering rules. Using regular expressions, you can redirect HTTP and HTTPS requests individually to different IIS farms.
    Inside the farm, the “pulse” of all nodes is constantly being checked. If the node "died", ARR will cease sending requests to it.
    Checking the nodes can be done in two ways:
    • Check the availability of the site located in the farm using a regular GET request. The survey takes place at a predetermined interval. Usually, a pre-deployed website with a technical name is used for this.
    • Monitoring live traffic to sites.

    The only difference between them is that in monitoring mode, ARR will not stop requests to farm nodes if they fail. And just make a note for the administrator, thus giving the possibility of manual control. And even when polling is enabled, the URL, in case the site is unavailable, it will be paused.
    ARR can be used not only for web hosting, but also for balancing the load on other services that operate over the HTTP protocol. An example of this, the publication of Exchange OWA (Outlook Web Access), is great for organizing mail access for a large number of clients.
    Starting with Windows Server 2012, it became possible to store all SSL certificates in one place accessible to all nodes. This greatly simplifies the operation of the entire farm. Now you don’t have to spend a lot of time installing and managing certificates.

    How does it work for us?

    Previously, we used single servers to provide Windows-based shared hosting. As they filled, new and new nodes appeared that were not united by a single configuration. Over time, this began to cause inconvenience to both customers and system administrators who had to service this entire zoo. An example is the OS update on a web server, which requires a reboot, and hence the suspension of all sites hosted on it.

    Now I will tell you about the minimum fault-tolerant configuration that is used at the heart of our shared hosting.



    All farm components are located in the cloud infrastructure, which already at the equipment level minimizes the possibility of failure. One of the most important components is data storage. load balancing makes no sense if user-generated content is inaccessible, corrupted, or worse, irretrievably lost. To solve this problem, the data is placed on a clustered file storage.
    In addition to customer sites, it also stores:
    • Common configuration files for IIS and ARR servers. This is one of the conditions of the farm.
    • Shared SSL certificate store. With IIS 8.0, there is no longer any need to install client certificates on each farm node, as in previous versions.

    As a result, it turns out that the entire configuration and user data are not stored on the web servers themselves. This greatly simplifies the configuration of servers, storage and backup of data. The farm of web servers and load balancers can be scaled horizontally with new nodes. For clients to access their content, a separate host has been organized, which acts as an FTP server and Web Deploy service. On our shared hosting, sites written in PHP and ASP.NET feel equally comfortable.

    Our clients manage hosting through a personal account . All tasks that the user submits for execution are queued and the orchestra is taken up. It is he who manages all the services of Windows hosting using PowerShell scripts.

    But there are also particularly demanding customers. We have something to offer them: geo-distributed farms. They are physically spaced across multiple data centers. Data replication occurs at the file storage level. DFS is great for this. Client data between data centers can be replicated both automatically and upon request. And since in addition to content the entire configuration of web servers is replicated, this is an additional bonus to reduce the administration costs of this entire economy.

    That's it for today, in the next article I will try to describe in detail how to make it all live in harmony and uninterruptedly fulfill my duties.

    Also popular now: