Liberty Profile and Liberty Collective:
Liberty is considered as another application server, and a polyglot runtime environment used as service container. As an application server, liberty is a smaller version of Websphere server which pluginifies all of the existing components. Liberty server is comparable with Tomcat server. However, don’t confuse liberty collective with liberty application server. Liberty has 2 main components:
- Liberty Server (Application server for java runtime)
- Liberty Collective (A polyglot runtime environment)
In this blog I am going to talk more about liberty collective and its components.
Liberty collectives is based on master slave architecture in which there is one or more controllers which manages the APIs with a couple of members who are the actual workers.
The application runs inside the worker named member server. The controller server is responsible for managing members, scaling, job allocation, updating load balancer, health, analytics, log management, and many more tasks.
The members are running on host machines which are OS machines could be virtual or physical. The collective hosts machines hosts members (worker processes). The worker process could be a docker container, java process, node.js process, python process, etc which suggests liberty being polyglot runtime environment.
Liberty suggests high availability for both members and controllers as well as load balancers which could be either DataPower or IHS (IBM HTTP Server which is Apache tomcat + WS plugin). The following picture shows the overall liberty architecture:
The controllers may be replicated and share their information with each other which makes them being highly available. A member ahas a freedom to choose one of the controllers to be managed by since they are all equivalent. If a controller dies, another controller can take all of the responsibilities of the dead controller and manage all of the members which were reporting to the first controller.
Members are also highly available since controller creates more than one member to do a certain job. If a member disappears from the network all of the request starts being routed to another member. The controller takes control of all of the members by receiving heartbeat from members in a short period of time (e.g., 1 min). Once controller finds a member is no longer available, the controller creates a new member on an available host.
- Dynamic Scaling and static scaling
- Dynamic routing
- Health and Analytics
- Log Analytics
Auto Scaling &Dynamic Routing:
Autoscaling is another feature of liberty in which controller monitors the load of each member. In this feature each member is responsible to send CPU and memory available for each member process to the controller. The controller monitors the amount of CPU and memory and decides whether or not a new member required. If a new member is required due to heavy load of the network or due to a crash to a member, the controller spins up a new member server by ssh into the member host which is already registered and available to the controller and get a new member server started on a new machine. The new member is also joined to the collective and controller updates the load balancer to load balance the traffic to the new member. In addition, the controller updates the load balancer (IHS) to load balance and not to route to the busy member servers. Controller uses an algorithm to route the traffic based on the load that each member is handling.
There are bunch of other services available in IBM cloud foundation such as App monitoring, and health analytics. For more info refer to IBM Application Performance management website.
Active-Active Vs. Active-inactive
Liberty collective default is active-active high availability. However, some customers need active-0inactive mode. Liberty can be configured in active-standby mode in which some nodes are in standby mode and are ready to come to the network if there is a need for the standby nodes. To read more about this mode, please go to Liberty Site.