Introduction

Znode application can be hosted in a Load Balanced environment. But apart from universal load-balancing steps, some Znode application-specific guidelines are listed in this document. This document assumes that the reader has knowledge of IIS, basic Windows Server Administration, load balancing configurations & terminologies.

Setting up Znode Platform on Load Balancers

Sample Illustration of Load Balanced Znode 

Description:

Typically Znode webstore Application, API & Payment API  application would be required to load balanced, as these are the sites that will have a probability of heavy user load. On the other hand, the Admin application would not require load balancing, hence the Admin application has not been evaluated for a load-balanced environment, and in case of the heavy workload of the Scheduler configured around the Znode, then it is recommended to have a separate API instance for the Znode Admin application(i.e. API & Admin instance can be on the same server, where this API instance will not be the part of API load balancer).

Znode In Load Balancer Environment

The following section covers some specific points for the Load Balancing Znode application.

1. You may host multiple instances of Znode applications (API or Webstore or Payment API) on multiple nodes in the Load balancing environment.
2. Create an independent domain for each one of them i.e. for API & Webstore. The main domain will be mapped with a Load balancer, and the individual domains can be configured with individual applications on the respective nodes. 
3. Add all these domains for Admin & API (including main domain and individual node domain URL) in the Znode database, you can add multiple domains from Znode admin under Global Settings -> URL Management - Reference. Similarly, the Webstore main & individual node domains can be configured from the Znode Admin tool via Store setting i.e. Store & Reps -> Stores -> Manage active Store -> Urls Tab - Reference.
4. IIS Site Machine Key - Make sure to set the same Validation/Encryption key in IIS for an API / Webstore Application. This is the general setting that needs to be done when an application is deployed on a load balancer environment. Details are mentioned within the Znode Webstore & API sections.
5. Session - The required SQL Server session settings need to be configured, for the Znode Webstore application hosted on a load balancer environment. Details are mentioned in the Znode Webstore sections.
6. Media Storage- Media storage will be required in a central location so that multiple instances of API applications can have access to them. Znode provides 2 options for storing media centrally, they are 
   1. 3rd Party Storage Services (Azure or Amazon S3)

7. Data Storage - Znode uses SQL Server, Mongo DB & Elastic Search for different kinds of data needs. Host them in a central location that is accessible to API, Admin, and Web Store application servers. These connection strings/URLs need to be configured into the API web. config file. Webstore & Admin web. config files would only have reference to Mongo Logging Connection String.

8. Application Logging - Suppose the Znode Application is hosted on the load balancer having multiple nodes, then file-based logging is not much help to access the logs. Znode recommends centralized logging using Mongo DB so that all the logs can be accessed with the Znode Admin application. These configurations would be required in all web.config files (Admin, API, Webstore). 

9. Webstore Theme / CMS Page Templates - If you are load balancing the WebStore application, then “store themes, CSS & CMS page templates” can not be uploaded through the Admin application. You’ll have to make it part of your webstore application deployment or partial file/folder deployment, just to make sure the files are uploaded on all the nodes configured within the Load Balancer.

10. Cache - Cache will be stored by individual instances. Currently, there is no option to store the cache in a central location. For individual node cache management on Load balancer environments, Znode provides the setting under Global Setting, where the API & webstore individual node URLs need to be configured, the main domain URL is not required. In case there are multiple node URLs based on the application type then those need to be saved by using the ‘~’ operator.
    For Ex: The API & Webstore application has 2 nodes having the URL like api1.yoursite.com, api2.yoursite.com, webstore1.yoursite.com & webstore2.yoursite.com, then these URLs can be saved like “api1.yoursite.com~api2.yoursite.com” within API LB Domain Names & “webstore1.yoursite.com~webstore2.yoursite.com” within the Webstore LB Domain Names respectively. These node's domains should be added to the ZnodeDomain database table(Refer to point no - 3). See the screenshot below.
    

11. Sitemap / Product feed files - This is currently not ready for load balanced environment. At this time, the sitemap file will not be accessible through the Webstore host.

12. Znode Licensing for subdomains & multiple servers - For the “localhost” environment it will not have any licensing limit. But for the production/stage environment, customers would require to have sent a subdomain licensing request to the Znode team. Based on the request, the Znode team will provide certificates and Znode Framework DLLs.

Load Balancing Znode Webstore

Illustration:

Suppose you have one instance of Webstore running and based on the load now you would like to distribute the load on 2 instances of Webstore. The above diagram illustrates this scenario and shows a typical load balancer setup.

You can use the following steps to set the Znode webstore behind the load balancer, as shown above:

Prerequisites/Assumptions:

1. The following steps assume that you have ONLY one instance of Znode Webstore running.
2. Make sure you have established the load balancer and have connected the required number of nodes to it.
3. Please make sure that the new node has the required software installed. For an independent Znode Webstore application, you would just require the following software:
   1. IIS 7.5 and above
   2. .Net Framework 4.5 and above
   3. Mongo DB 3.2 (Only If you are using Mongo DB for Application Log Storage), have this installed separately in a central location so that every node is able to connect to this.
   4. If you already have MongoDB setup on a central location, then you may skip this installation.
   5. Aspstate database on a centralized location, to store the session data. follow this link for reference

Note - Following steps are applicable for each new node you would add to your webstore load balancer. 

Step 1: Deploy the Znode Webstore application on new nodes:

1. Create a new Website in IIS (on the new node) for Webstore (e.g. store2.yourstore.com).
2. Publish/Deploy the Znode Webstore application on the new node’s IIS (e.g. store2.yourstore.com).
3. Please make sure your webstore’s web.config file is pointing to the correct API URL
   

Step 2: Domain mapping for Master (Load Balancer) and child nodes:

1. Typically, you would map your main domain (e.g. www.yourstore.com) with the Load Balancer for public access.
2. Define independent domains for child nodes (e.g. store1.yourstore.com and store2.yourstore.com), and map them in IIS websites along with the main domain, which you have deployed in IIS in step 1. Make sure your DNS entry is pointing to the correct node.
3. Make these domain entries in the Znode Admin portal under Store Management, follow this link for reference.
   1. This way Znode knows how many URLs/domains are associated with a particular store. You can have multiple domains pointed to the same store.

Step 3: Set IIS Site’s Machine Key:

1. When you are in a load-balanced environment, and if your application is using the .net framework’s encryption/decryption capabilities (For user PWD or any other data), the machine key used for it, must be the same for each request. And as we know the request may get routed to any of the webstore nodes, so to make it fail-safe we must use the same machine key across all webstore nodes. See the screenshot below:
   

Step 4: Session

Option 1 - SQL Server Session Storage:

1. Once you have set up your new webstore node, you would like your session to be stored centrally so that you do not have any negative impact on user sessions due to user requests being distributed into multiple nodes.
2. This mode is best used when the reliability of the data is fundamental to the stability of the application, as the database can be clustered for failure scenarios. The performance isn't as fast as InProc or StateServer, but the tradeoff is the higher level of reliability. 
3. It makes application state management reliable, as sessions will persist even if the service gets restarted (IIS or SQL).
4. Please change the session state entry in the web stores web.config file as seen below:
    
5. It allows us to use multiple “worker processors” in the IIS app pool as the session is not dependent on the application (w3wp) instance.
6. The downside is, it makes things quite slower compared to InProc sessions (At-least when compared to Znode instances. report here compare 2 tabs)
7. [Update] SQL Server session can be used with in-memory tables (TempDB), which are quite fast compared to persistent tables. The downside is that the session data will be lost in case of a server restart.

Option 2 - InProc session:

1. In process (InProc) will perform best because the session state memory is kept within the ASP.NET process. For Web applications hosted on a single server, applications in which the user is guaranteed to be redirected to the correct server, or when session state data is not critical (in the sense that it can be re-constructed or re-populated), this is the mode to choose.
2. Using an InProc session in LoadBalanced or WebGarden (Multiple worker processors in an IIS app pool) would require certain steps to be configured.
3. We may not be able to use multiple worker processors in the IIS app pool. As we won’t be able to control which request will be handled by which worker process. So we’ll have to keep it to 1.
4. You will need to add sticky session behavior in your Load Balancer. Where Load Balancer will send session-specific traffic on a particular web node. For e.g. All the requests coming from a particular session should always go to a particular node.
   Typically a Load Balancer can achieve this sticky behavior using the following options:
   1. The easiest form of Sticky Session (persistence) is based on the client's Source IP. By using ClientIP as the identifier, the load balancer will route all the requests coming from a particular ClientIP to a particular node in the web farm.  But the limitations are

      1. if there are multiple users coming from behind the same IP (For e.g. Multiple users from within an Organization’s network may have the same Static Network IP), which may create uneven load distribution among the nodes.

      2. If the user is coming from some dynamic Network IPs (For e.g. home networks or mobile networks), they may see glitches if their Network IP is changed during their working session, as it will send subsequent requests to some other node.

      3. Another option is Cookie based session stickiness: In this case, the Load Balancer will inject a cookie (e.g. ServerId=1025 or ServerId=1026, etc) in the response to the first request coming from a client. From the next request onward, the client will send that cookie back to the load balancer, based on this cookie value Load Balancer will send the request to a defined node for that value. https://www.thinknetsec.com/brocade-adx-persistence/

Step 5: Application logging configurations:

1. Suppose you have 3 nodes for Znode Webstore hosting, in this case using file logging will require you to go to each server to view the logs, which would not be a desirable situation. To have the logs in a central location, Znode provides the ability to log application errors in central Mongo DB. Follow this link for details. These configurations would be required in all Webstore nodes. At this moment, only Mongo Db logs can be seen from Admin Log Viewer.
2. Change the MongoDB connection string in the web stores web config file, as seen below:
   
3. Now enable the MongoDB logging instead of file logging, and change the following in the web.config file (Under <appSettings>) on all webstore nodes:
   

Limitation 

1. Webstore Theme/CSS & CMS Page Template upload through admin will not work:

   1. Webstore application serves all the MVC views from its own directory including all the associated CSS and JS files. So if you have a webstore application hosted on multiple servers (nodes), then it would require a copy of theme/CSS/js files on each of the servers. In such conditions, the “Upload” capability given through the Admin application will not work as of today.

   2. To handle this situation, you must make Theme/CSS/JS and CMS Page template files as part of your webstore application build deployment. Or for now, you may create an automated script that will copy these files on multiple nodes.

2. Webstore’s sitemap.xml:

   1. Currently, sitemaps are not generated for such a hosting environment, and it would require a fix. Till then, you may need to create your own Controller which can serve the sitemap files correctly.

The setup for the Znode Load balancer is now finished.

Load Balancing Znode API

Once you have followed the Znode Webstore Load Balancing points mentioned above, it will be easy now to host the Znode API application behind the load balancer.

Illustration:

Prerequisites/Assumptions:

1. The following steps assume that You have ONLY one instance of Znode API running.
2. Make sure you have established the load balancer and have connected the required number of nodes to it.
3. Please make sure the new node has the required software installed, For an independent Znode API application you would require the following software, software details here:
   1. IIS 7.5 and above
   2. .Net Framework 4.5 
   3. Data Store is hosted on a centralized server, which is accessible by all API nodes:
      1. Mongo DB 3.2
      2. ElasticSearch 5.5
      3. SQL Server 2012 or above

Step 1: Deploy Znode API application on new nodes:

1. Create a new Website in IIS (on the new node) for API (e.g. api2.yourstore.com).
2. Publish/Deploy Znode API application on new node’s IIS (e.g. api2.yourstore.com).
3. Please make sure your API application’s web. the config file should configure with SQL Server, Mongo DB & Elastic Search index settings which are hosted in a centralized location. 

Step 2: Domain mapping for Master (Load Balancer) and child nodes:

1. Typically, you would map your main domain (e.g. api.yourstore.com) with the Load Balancer for public access.
2. Define independent domains for child nodes (e.g. api1.yourstore.com and api2.yourstore.com), and map them in IIS websites, which you have deployed in IIS in step 1. Make sure your DNS entry is pointing to the correct node.
3. Make these domain entries in the Znode Admin portal under Global Settings - Url Management, follow this link for reference.

Step 3: Set IIS Site’s Machine Key:

1. When you are in a load-balanced environment, and if your application is using the .net framework’s encryption/decryption capabilities (For user PWD or any other data), the machine key used for it, must be the same for each request. And as we know the request may get routed to any of the API nodes, so to make it fail-safe we must use the same machine key across all API nodes. See the screenshot below:
   

Step 4: Application logging configurations:

1. Suppose you have 3 nodes for Znode Api hosting, in this case using file logging will require you to go to each server to view the logs, which would not be a desirable situation. To have the logs in a central location, Znode provides the ability to log application errors in central Mongo DB. Follow this link for details. These configurations would be required in all API nodes. At this moment, only Mongo Db logs can be seen from Admin Log Viewer.
2. Change MongoDB connection string in API’s web config file, as seen below:

Step 5: Scheduler Configuration:

1. Znode API required the Scheduler configuration for scheduled jobs in the Application. By default, this setup is available within the API Application -> Data -> Scheduler folder, and the same path has been utilized by Znode API.
2. In the Load balancer environment, these Scheduler details can be placed within the shared location, which will get accessed by all the nodes available. 
3. In case these Scheduler details are placed on a shared location, then change the SchedulerPath settings in API’s web config file, as seen below:
   

Step 6: License Configuration:

1. Znode API requires valid License certificates. And in the Load Balancer environment, there may be multiple instances available for the Znode API, it will not be possible to install the certificate on each instance.
2. When the Znode APIs are required to host on a Load Balancer environment, then these License certificates should be part of your API application deployment or partial file deployment.
3. For the production/stage environment, customers would require to have sent a subdomain licensing request to the Znode team. Based on the request, the Znode team will provide certificates and Znode Framework DLLs. 

Znode Setup on Load Balancer Example

The Proposed setup of Znode on Load Balancer, where API & Webstore application is on Load Balancer having two nodes each, and Znode Admin application with its own API setup.

Considering the Znode application has configured with two portals/stores, then the public domain setup based on application type is mentioned below:

Admin App         -> admin.yoursite.com

Admin-API App         -> admin-api.yoursite.com

API App(LB)         -> api.yoursite.com

Webstore App(LB)     -> store1.yoursite.com, store2.yoursite.com

Illustration:

Znode API LB Nodes Configuration:

Znode API LB Setup has two nodes with the main domain i.e. “api.yoursite.com” & its individual domain like “API-node1.mysite.com” & “API-node2.mysite.com”. 

 In this case, the main domain is configured on the API Load balancer, and individual domains are configured on the respective nodes. 

The main domain can be accessed from the internet, whereas the individual domain will get accessed within the private network so that the individual domain gets accessed from the Znode Admin & its API application.

The IIS Bindings for the respective Znode API nodes are -

API Node -1: api.mysite.com & api-node1.mysite.com

API Node -2: api.mysite.com & api-node2.mysite.com

Znode Webstore LB Nodes Configuration:

Znode Webstore LB Setup has two nodes with the main domain like “store1.yoursite.com”, “store2.yoursite.com” & its individual domain like “store-node1.yoursite.com” & “store-node2.yoursite.com”. 

 In this case, the main domain is configured on the Webstore Load balancer, and individual domains are configured on the respective nodes. 

The main domains can be accessed from the internet, whereas the individual domain will get accessed within the private network so that the individual domain gets access from the Znode Admin & its API application as well as from the API LB Nodes.

The IIS Bindings for the respective Znode Webstore nodes are -

Webstore Node -1: store1.yoursite.com, store2.yoursite.com & store-node1.yoursite.com

Webstore Node -2: store1.yoursite.com, store2.yoursite.com & store-node2.yoursite.com

Znode Admin Configuration:

Znode Admin Setup will be an individual one, as the Znode Admin application is not evaluated on the LB environment. 

The Znode Admin application can consume the API hosted on the LB environment, but in case there is a heavy workload of the Scheduler configured around Znode, then it is recommended to have the individual API for the Admin application. The domains for Admin & its own API application are “admin.yoursite.com” & “admin-api.yoursite.com”

The Znode Admin can be accessed from the Internet or it can be restricted to private networks depending upon the configuration. The Admin application & its API required access to all the main domains and individual domains configured in the LB environment. 

The IIS Bindings for the respective Znode Admin & its API is -

Admin App: admin.yoursite.com

Admin-API App: admin-api.yoursite.com

Important Note:- In the webstore, if the issue occurs like the CSS and JS is not loading, all document requests show a 500 error in the console, and SQL session mode is being used for session management then due to an access issue of the SQL session server this issue could occur. Change to Inproc session mode and check the sites once whether the sides are loading correctly or not. Later correct the access issue of the SQL session and use it.