Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Achieve 100% Availability on WSO2 Product Deployments

DZone's Guide to

How to Achieve 100% Availability on WSO2 Product Deployments

These considerations will help you achieve and maintain availability in WSO2 deployments by handling outages, new services, and updates.

· DevOps Zone
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

WSO2 products come with several different components. These components can be configured through different configurations. Once the system is moved into production, it is quintessential that system needs to go through various updated and upgrades during its lifetime. There are 3 main configurations related to WSO2 products.

  • Database configurations

  • Server configurations

  • Implementation code

Any one or all of the above configuration components can be changed during an update/upgrade to the production system. In order to keep the system 100% available, we need to make sure that product update/upgrade processes do not impact the availability of the production system. We can identify different scenarios which can challenge the availability of the system. During these situations, users can follow the guidelines mentioned below so that system runs smoothly without any interruptions.

During Outage of Server(s)

  • We need to have redundancy (HA) in the system in terms of active/active mode. In a 2 node setup, if 1 node goes down, there must be a node which can hold the traffic for both nodes for some time. Users may get some slowness, but the system will be available. During the capacity planning of the system, we must make sure that at least 75% of the overall load can be handled by 1 active node.

  • If we have active/passive mode in a 2 node setup, each node should be capable of handling the load separately and passive node should be in hot-standby mode. Which means that passive node must keep on running even though it does not get traffic.

  • If an entire data center goes down, then we should have a Disaster Recovery (DR) in a separate data center with the same setup. This can be in a cold-standby mode since these type of outages are very rare. But if we go with cold standby, there will be a time window of service unavailability.

Adding a New Service (API)

  • Database sharing needs to be properly done through master-datasources.xml file and through registry sharing.

  • File system sharing needs to be done so that deployment is one time and other nodes will get the artifacts through file sharing.

  • Service deployments need to be done from one node (manager node) and other nodes need to be configured in read-only mode (to avoid conflicts).

  • Use passive node as manager node (If you have active/passive mode).

  • Once the services are deployed on all the nodes, do a test and expose the service (API) to the consumers.

Updating an Existing Service (Fixing a Bug)

  • Bring one additional passive node to the system with the existing version of services. This is in case if the active node goes down while updating the service on the first passive node (system will be 1 active/2 passive).

  • Disable the file sharing (rsync) on the passive node.

  • Deploy the patched version and carry out testing into this passive node.

  • Once the testing is passed, allow traffic into the passive node and stop traffic from the active node.

  • Enable file sharing and allow the active node to sync up with the patched version. If you don’t have file sharing, you need to manually deploy the service.

  • Carry out testing on other node, and once it is passed, allow traffic into the new node (if required).
    Remove the secondary passive node from the system (system will be 1 active/1 passive).

Applying a Patch to the Server (Needs a Restart)

  • Bring one additional passive node to the system with the existing version of services. This is in case if the active node goes down while applying the patch on the first passive node (system will be 1 active/2 passive).

  • Apply the patch on the first passive node and carry out testing.

  • Once the testing is done enable traffic into this node and remove traffic from the active node.

  • Apply the patch on the active node and carry out testing.

  • Once the testing is done, enable traffic into this node and remove traffic from previous node (or you can keep this node as active).

  • Remove the secondary passive node from the system (system will be 1 active/1 passive).

Doing a Version Upgrade to the Server

  • Bring one additional passive node to the system with the existing version of services. This is in case if the active node goes down while applying the patch on first passive node (system will be 1 active/2 passive).

  • Execute the migration scripts provided in WSO2 documentation to move the databases to the new version in passive node.

  • Deploy the artifacts in the new version in passive node.

  • Do a testing on this passive node and once testing is passed, expose traffic into this node.

  • Follow the same steps into the active node.

  • Once the testing is done, direct the traffic into this node (if required).

Instead of maintaining the production system through manual processes, WSO2 provides artifacts which can be used to automate the deployment and scalability of the production system through Docker and Kubernetes.

Deployment Automation

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
wso2 ,availability ,deployment automation ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}