Sign Up
  1. Znode
  2. Solution home
  3. Developer Documentation
  4. Reference Guides

Load Balancer Environment Set Up

TABLE OF CONTENTS


Introduction

Znode applications can be hosted in a load-balanced environment when required. In addition to universal load balancing steps, additional Znode application-specific guidelines are outlined in this article. This article assumes that the reader has knowledge of IIS, basic Windows Server Administration, load balancing configurations & terminologies.

It is recommended that the Znode Webstore, API, and Payment Applications be load balanced, as these are the applications that will have a probability of heavy user load. Most common usage scenarios do not require the Admin application to be load balanced, hence the Admin application has not been evaluated for a load-balanced environment. In the case of a heavy workload of the Scheduler configured in Znode, then it is recommended to have a separate API instance for the Znode Admin application(i.e. the API and Admin instance can be on the same server, where this API instance will not be the part of API load balancer).

Sample Illustration of Load Balanced Znode :



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

  1. Users may host multiple instances of Znode applications (API, web store, Admin, Payment API) on multiple nodes in a Load balancing environment.
  2. Create an independent domain for each one of them i.e. for API and web store. The main domain will be mapped with a Load Balancer.
  3. After cache eviction changes individual domains are not required.
  4. Add this domain for Admin and API(including main domain URL) in the Znode database, users can add a domain from Znode admin under Global Settings -> URL Management - Reference. Similarly, the web store main can be configured from the Znode Admin tool via the Store setting i.e. Store and Reps -> Stores -> Manage Store -> URLs Tab - Reference.
  5. IIS Site Machine Key - Make sure to set the same Validation/Encryption key in IIS for an API / web store application. This is the general setting that needs to be done when an application is deployed in a load balancer environment. Details are mentioned within the Znode web store and API sections.
  6. Session - The required SQL Server session settings need to be configured, for the Znode web store application hosted on the load balancer environment. Details are mentioned in the Znode web store sections.
  7. 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).
  8. Data Storage - Znode uses SQL Server, MongoDB, and 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. web store and admin web. config files would only have reference to Mongo Logging Connection String.
  9. 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 MongoDB 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, web store, Payment API).
  10. Web Store Theme / CMS Page Templates - If users have a load-balancing web store application, then “store themes, CSS, and CMS page templates” can not be uploaded through the Admin application. You’ll have to make it part of the users’ Web-Store application deployment or partial file/folder deployment, just to make sure the files are uploaded on all the nodes configured within the Load Balancer.
  11. 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 and Web-Store node URL need to be configured. 
    1. Note: Cache eviction changes are added in Znode 9.3.2 and Znode 9.6.4 or higher than Znode 9.6.4 version, so this setting below is not required in these versions.
    2. For Ex: The API and Web-Store application has 2 nodes having URLs like api1.yoursite.com, and webstore .yoursite.com. These node’s domains should be added to the ZnodeDomain database table(Refer to point no - 3).  See the screenshot below.
  12. Sitemap / Product feed files - This is currently not ready for a load-balanced environment. At this time, the sitemap file will not be accessible through the WebStore host.
  13. Znode Licensing for subdomains and multiple servers - For the “localhost” environment it will not have any licensing limit. But for the production/stage environment, customers would be required 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.
    Note: “Load Balancing Environment Details” section is not available in Znode 9.7 or higher version.

Tools Required for Load Balancing

  1. Windows servers.
  2. Znode License
  3. IIS Server 7.5 or above.
  4. .Net Framework 4.5 or above.
  5. New Relic account. (for monitoring the server’s CPU and memory).
  6. Jmeter 5.4 or above. (for executing the scripts).
  7. SQL Server 2012 or above.
  8. Aspstate database on the centralized location (for storing the session data - follow this link for reference).
  9. MongoDB 4.2 (Only If users are using MongoDB for Application Log Storage).
  10. ElasticSearch 5.5 or 7.6.2
    Note: The latest version in the Znode is .Net Framework 4.8

Load Balancing Znode Web Store

Suppose the user has one instance of a web store running and based on the load now the user would like to distribute the load on 2 instances of the web store. The below diagram illustrates this scenario and shows a typical load balancer setup.

Users can use the following steps to set the Znode web store behind the load balancer, as shown below:


Prerequisites/Assumptions:

  1. The following steps assume that users have only one instance of the Znode web store running.
  2. Make sure users 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 independent Znode Web-Store applications users would just require the following software:
    1. IIS Server 7.5 or above
    2. .Net Framework 4.8 or above
    3. Mongo DB 4.2
    4. Aspstate database 
    5. Elastic Search 5.5 / 7.6 / 7.16.2
      Note: The latest version in the Znode is .Net Framework 4.8 and as per Znode releases user need to upgrade the elastic search versions.

The following steps are applicable for each new node user would add to his web store load balancer:

Step 1 Deploy Znode web store application on new nodes:

  1. Create a new Website in IIS (on the new node) for the web-store (e.g. store2.yourstore.com).
  2. Publish/Deploy the Znode web store application on the new node’s IIS (e.g. store2.yourstore.com).
  3. Please make sure the web-store web.config file is pointing to the correct API URL
     
  4. Also, make sure the web store ElasticSearch key and Api’s ElasticSearch key are pointing to the correct port.
     
  5. Cache Eviction changes are added in the Znode 9.3.2 release and Znode 9.6.4 or higher than Znode 9.6.4 so make sure the below keys should be available in this specific version.
     

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

  1. Typically, the user would map his main domain (e.g. www.yourstore.com) with the Load Balancer for public access.
  2. After cache eviction changes individual domains are not required.
  3. Make these domain entries in the Znode Admin portal under Store Management, follow this link for reference.
  4. This way Znode knows how many URLs/domains are associated with a particular store. Users can have multiple domains pointed to the same store.

Step 3 IIS Site’s Machine Key:

When users are in a load-balanced environment, and if the user’s 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 users know the request may get a route to any of the web store nodes, so to make it the fail-safe user must use the same machine key across all web store nodes. See the screenshot below:
 


Step 4 Session:

SQL Server Session Storage:

  1. Once users have set up the user’s new web store node, the user would like the user’s session to be stored centrally, so that users 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. 
    1. It makes application state management reliable, as sessions will persist even if the service gets restarted (IIS or SQL).
    2. Please change the session state entry in the web store web.config file as seen below:
      1. It allows us to use multiple “worker processors” in the IIS app pool as the session is not dependent on the application (w3wp) instance.
      2. The downside is, it makes things quite slower compared to InProc sessions (At-least when compared in Znode instances. report here compare 2 tabs).

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.
    1. Users may not be able to use multiple worker processors in the IIS app pool. A user won’t be able to control which request will be handled by which worker process. So we’ll have to keep it to 1.
    2. The user will need to add sticky session behavior in the user’s 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.
      1. Typically a Load Balancer can achieve this sticky behavior using the following options:
      2. 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 Client-IP 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 the user has 3 nodes for Znode web store hosting, in this case using file logging will require the user 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 MongoDB. Follow this link for details. These configurations would be required in all web store nodes. At this moment, only MongoDB logs can be seen from the Admin Log Viewer.
  2. Change MongoDB connection string in web store web.config file, as seen below:

Load Balancing Znode API

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


Prerequisites/Assumptions:

The following steps assume that the user has only one instance of Znode API running.

  1. Make sure users have established the load balancer and have connected the required number of nodes to it.
  2. Please make sure the new node has the required software installed, For independent Znode API applications users would require the following software, software details here:

    1. IIS 7.5 or above

    2. .Net Framework 4.8

    3. Data Store is hosted on a centralized server, which is accessible by all API nodes:

      1. Mongo DB 4.2

      2. ElasticSearch 5.5 or 7.6.2

      3. SQL Server 2012 or above


Steps to setup the API node:


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 the user’s API application’s web.config file should be configured with SQL Server, MongoDB, and Elasticsearch index settings which are hosted in a centralized location. 

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

  1. Typically, the user would map the user’s main domain (e.g. api.yourstore.com) with the Load Balancer for public access.
  2. After cache eviction changes individual domains are not required.
  3. Make these domain entries in the Znode Admin portal under Global Settings - Url Management, follow this link for reference.

Step 3 Connection string setup:

  1. Make sure to set up a connection string with proper credentials.


Step 4 Set IIS Site’s Machine Key:

When users are in a load-balanced environment, and if the user’s 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 users know the request may get a route to any of the API nodes, so to make it fail-safe user must use the same machine key across all API nodes.

See the screenshot below:


Step 5 Application logging configurations:

  1. Suppose users have 3 nodes for Znode API hosting, in this case using file logging will require the user 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 MongoDB. Follow this link for details. These configurations would be required in all API nodes. At this moment, only MongoDB logs can be seen from the Admin Log Viewer.
  2. Change MongoDB connection string in API’s web.config file, as seen below:
     
  3. Also, make sure the web store ElasticSearch key and Api’s ElasticSearch key are pointing to the correct port.
     
  4. Avalara changes are available in Znode 9.6.6 version, so for Znode 9.6.6 required below 2 keys.

Step 6 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:
  4. Hangfire is available from Znode 9.6.5 release or higher, make sure to configure the below keys for the hangfire setup.



Step 7 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 a Load Balancer environment, then these License certificates should be part of the User’s API application deployment or partial file deployment.
  3. For the production/stage environment, customers would be required 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 and web store application are 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

API App: api.yoursite.com

Payment API App: paymentapi.yoursite.com

Web Store App: store1.yoursite.com, store2.yoursite.com



Znode API LB Nodes Configuration:

Znode API LB Setup has two nodes with the domain i.e. “api.yoursite.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 and its API application.


The IIS Bindings for the respective Znode API nodes are:

API Node -1: api.yoursite.com

API Node -2: api.yoursite.com

Note: After cache eviction changes individual domains are not required.

Znode Payment API LB Nodes Configuration:

Znode Payment API LB Setup has two nodes with the domain i.e. “paymentapi.yoursite.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 and its API application.

The IIS Bindings for the respective Znode Payment API nodes are:

Payment API Node -1: paymentapi.yoursite.com 

Payment API Node -2: paymentapi.yoursite.com 

Make sure to enter the correct credentials in the connection string section.


Payment Application Configurations:

  1. Change the web node, API node, and admin node in the Payment API web.config inside the CORS_Domains key.
     
  2. Change MongoDB connection string in Payment API’s web.config file, as seen below:

Znode Web Store LB Nodes Configuration:

Znode web store LB Setup has two nodes with the main domain like “store1.yoursite.com”, “store2.yoursite.com” and its domain like “store-node.yoursite.com”. 


In this case, the main domain is configured on the web store 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 and its API application as well as from the API LB Nodes.

The IIS Bindings for the respective Znode web store nodes are:

Web store Node -1: store1.yoursite.com, store2.yoursite.com, and store-node.yoursite.com

Web store Node -2: store1.yoursite.com, store2.yoursite.com, and store-node.yoursite.com


Znode Admin Configuration:

Znode Admin Setup will be accessing the same API node as the web store. 

The Znode Admin application can consume the API hosted on the LB environment, The domain for Admin i.e “admin.yoursite.com”.


The Znode Admin can be accessed from the Internet or it can be restricted to private networks depending upon the configuration. 


The IIS Bindings for the respective Znode Admin and its API is:

Admin App: admin.yoursite.com

API App: api.yoursite.com


Log’s Configuration:

The below setting will help to set up logs as per the user’s requirement, so make sure to set up the proper log setting in the Znode Admin, Znode Webstore, Znode API, and Znode Payment API inside the log4net.config file.

The below root section will allow the user to set up the specific logs as per his requirement.








Important Note:

In case the SQL Session mode is used for session management, the webstore may also have the issues like CSS & Javascript not loading, and the sites showing the 500 error in the console. Then make sure to check the respective SQL privileged access for the SQL session database used for the session management.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.

Reference Guides