What is a web farm?
In a nutshell, a web farm is a group of two or more web servers that host multiple instances of a single app (i.e GrandNode). Long story short you will use web farm when during the high load, you will be forced to distribute requests to different nodes of your application to keep the site up and running. You will use Load Balancer and Web Farm configuration to handle that.
On the internet, a web server farm, or simply web farm, may refer to an application, i.e online store that uses two or more servers to handle customers' requests. Especially during high load periods like Black Friday, seasonal promotions.
A properly configured web farm improves a lot of factors:
- Reliability/Availability:
- Capacity/Performance
- Scalability
- Maintainability
A web farm is a group of two or more web servers (or nodes) that host multiple instances of an app. When requests from users arrive to a web farm, a load balancer distributes the requests to the web farm's nodes. Web farms improve:
- Reliability/availability: When one or more nodes fail, the load balancer can route requests to other functioning nodes to continue processing requests.
- Capacity/performance: Multiple nodes can process more requests than a single server. The load balancer balances the workload by distributing requests to the nodes.
- Scalability: When more or less capacity is required, the number of active nodes can be increased or decreased to match the workload. Web farm platform technologies, such as Azure App Service, can automatically add or remove nodes at the request of the system administrator or automatically without human intervention.
- Maintainability: Nodes of a web farm can rely on a set of shared services, which results in easier system management. For example, the nodes of a web farm can rely upon a single database server and a common network location for static resources, such as images and downloadable files.
This topic describes configuration and dependencies for ASP.NET core apps hosted in a web farm that relies upon shared resources.
How to configure Redis Pub/Sub in GrandNode?
Redis Pub/Sub configuration in GrandNode is straightforward. Everything ends on the appsettings.json configuration. Before the start, you should configure the Redis Pub/Sub server.
When you complete the Redis configuration, you should jump into the App_Data/appsettings.json file and fill all necessary fields:
///Enable the Publish/Subscribe messaging with Redis to manage memory cache on every server
"RedisPubSubEnabled": false,
"RedisPubSubConnectionString": "127.0.0.1:6379,allowAdmin=true",
"RedisPubSubChannel": "channel",
"PersistKeysToRedis": false,
"PersistKeysToRedisUrl": "127.0.0.1:6379,allowAdmin=true,defaultDatabase=1",
How to configure RabbitMQ in GrandNode?
Similar to the Redis configuration, it’s a very simple process. As you should be familiar with Redis/RabbitMQ, we won’t cover the installation process.
Messaging enables software applications to connect and scale. Applications can connect to each other, as components of a larger application, or to user devices and data. Messaging is asynchronous, decoupling applications by separating sending and receiving data.
With tens of thousands of users, RabbitMQ is one of the most popular open-source message brokers. RabbitMQ is a messaging broker - an intermediary for messaging. It gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.
Download RabbitMQ and install it, you can use their documentation and get started tutorial - https://www.rabbitmq.com/download.html
After that, edit the appsettings.json file that can be found in the App_Data directory and find the following section:
//Enable RabbitMq
"RabbitEnabled": false,
"RabbitCachePubSubEnabled": false,
"RabbitHostName": "localhost",
"RabbitVirtualHost": "/",
"RabbitUsername": "guest",
"RabbitPassword": "guest",
//must be unique for each instance
"RabbitCacheReceiveEndpoint": "grandnode",
Provide all necessary fields and then restart your app. Everything should work.
Please note, that in the case of both services - Redis and RabbitMQ - if you use web farm architecture, you have to keep the appsettings.json file consistent on every single server.
Multi Tenancy & Web Farm & MongoDB Replication
GrandNode’s multi-tenancy allows you to run your own SaaS eCommerce business on it. However, every SaaS platform requires high-performance and efficient hosting. Even at the beginning, we have to be sure that we are trustworthy for customers.
To provide the highest performance we should consider using Load Balancer and MongoDB Replica Sets.
MongoDB Replica Sets
Via MongoDB Documentation page: „A MongoDB replica set ensures replication is enforced by providing data redundancy and high availability over more than one MongoDB server.”
If a MongoDB deployment lacked a replica set, that means all data would be present in exactly one server. In case the main server fails, then all data would be lost - but not when a replica set is enabled. Therefore, we can immediately see the importance of having a replica set for a MongoDB deployment.
In addition to fault tolerance, replica sets can also provide extra read operations capacity for the MongoDB cluster, directing clients to the additional servers, subsequently reducing the overall load of the cluster.
Replica sets can also be beneficial for distributed applications due to the data locality they offer so that faster and parallel read operations happen to the replica sets instead of having to go through one main server.
Source: https://www.mongodb.com/
Example of the basic web farm architecture for Multi-Tenant SaaS eCommerce platform based on GrandNode
Above you can find a simple diagram, which presents how we see the ideal architecture for multi-tenant GrandNode. From our point of view, this approach gives you the most flexible and the most efficient way to handle multi-tenancy in GrandNode.
RabbitMQ or Redis Pub/Sub should be configured on an independent server, similarly to Scheduled tasks.
Keeping scheduled tasks on the independent machine is very crucial for the whole infrastructure. First of all, you shouldn't burden the store's machine with regularly performed tasks. Furthermore, if you will run them on a few different servers, you may notice inconsistency and you will send the same email twice or something similar.
There is also another important thing, you should keep the appsettings.json file the same on every machine. And it's crucial.
How to configure GrandNode scheduled tasks?
You need to know that when you are configuring a web farm for GrandNode, and creating a new machine for scheduled tasks, you need to do something else. Navigate to your main store and in the System -> Schedule Tasks, edit all running tasks.
Fill in the "Name of the machine" field. It will be used to specify which machine manages the scheduled tasks.