With PLOSSYS 5, SEAL Systems develops the next generation of its output management system. Although it is still possible to install PLOSSYS 5 locally (i.e., on-premise), the system has been designed from the beginning for operation in the cloud.
Instead of a monolithic system, PLOSSYS 5 runs in the cloud as a cluster of microservices that can be started or stopped depending on the current load. And, the system only uses as many resources as needed.
In this blog post, we present what this process looks like in practice – and how flexible your output management system could be in the future. As an example of a cloud environment, we have chosen a Kubernetes cluster based on Amazon Web Services (AWS). In addition, we could also have used other vendors and cluster managers, such as Azure or OpenShift. The combination chosen only allows us to demonstrate the advantages of this technology particularly well.
What we want to show in this post is a typical scenario for a small to medium-sized deployment of PLOSSYS 5: an operational database (fail-safe in compound operation with three DB instances), an instance of the log database, and a set of P5 microservices. This scenario is very suitable, for example, for SAP spool and Windows printing with up to 100,000 print jobs per day. We explain how the scenario is structured and show how the cluster technology combines reliability and economical use of resources.
The baseline is PLOSSYS 5, which we have prepared in the form of software containers for operation in the cloud cluster. For our cluster, we have set up four virtual machines on AWS, which are managed by Kubernetes as nodes and combined to form a cluster. A manager node takes care of monitoring, control, load balancing, configuration and the internal network. Three worker nodes operate the database cluster and provide the remaining computing power for the actual PLOSSYS 5 operation. The manager, in turn, ensures that this power is used optimally. The manager nodes are realized as a separate autoscale group: if the manager nodes should fail, AWS automatically restarts new manager nodes so that the cluster never fails completely.
SEAL Systems monitors cluster performance with Prometheus and creates dashboards with Graphana.
The following picture shows the state of the cluster with three nodes and two CPU cores and 16 GB RAM (6 cores and 48 GB RAM in total). There are 36 services active on the cluster, including databases, PLOSSYS services and monitoring. The services reserve 79% of the available CPU capacity and 16% of the available RAM. The actual load is very low (shown in the diagram on the left). Under load, the blue bars show the actual resource utilization in the cluster over time.
We use so-called spot instances for all cluster nodes on AWS. Amazon can shut down these virtual machines at any time with a minutes’ notice if resources are needed elsewhere.
On the other hand, the spot instances are drastically cheaper than permanently running virtual machines. This can be used as an advantage because cluster technology and microservices make PLOSSYS 5 independent of fixed virtual machines. If one of the spot instances is stopped, it simply falls out of the cluster. The cluster manager registers the lack of resources and services, boots a new virtual machine, integrates it into the cluster and automatically restarts the missing microservices.
In addition, PLOSSYS 5 also uses the same mechanism to ensure fail-safe operation in the cluster. The only difference between the failure of a virtual machine and the shutdown of a spot instance is the missing lead time. After a short time PLOSSYS 5 detects the failure of the virtual hardware even without pre-run and reacts by switching off a spot instance: a new VM is created, integrated and the missing services are restarted.
Similar to node failure, the cluster also reacts to increasing resource requirements under a heavy load. If more resources are required than the cluster can provide, autoscaling becomes active. The cluster manager then automatically boots additional worker instances to start additional services and absorb peak loads.
If the load drops again later (so that the cluster can manage with fewer worker instances), the manager gradually clears worker instances and automatically switches them off again. The figure shows the cluster in a state in which more services were started than the cluster can operate (recognizable by the number of requested CPU cores and the seven missing service instances, shown in red).
In this case, the Cluster Manager automatically starts additional worker instances with six additional cores and 36 GB RAM and integrates them into the cluster. In addition, this is where the requested additional services start. And, it is where the operation is normalized – and the load is again in the nominal range.
This situation can be seen in the following picture: The number of CPU cores in the cluster has increased to 12, the available memory has increased to 84 GB. A total of 83 services are active now.
The advantages of a cloud-native application (with a microservice architecture in cluster operation) are manifold. This makes it possible not only to automatically adjust the number of services required, but also the number of servers to the actual system load, thus saving direct costs.
Further savings result from the use of low-cost, volatile spot instances whose potential spontaneous failure is absorbed by Kubernetes. Reliability at service and server level is already part of PLOSSYS 5.
Furthermore, the constant renewal of the instances also eliminates the need of maintenance and care of the servers. Systems with outdated OS are automatically replaced by new systems with current OS over time. Most importantly, Kubernetes and Openshift can now be installed at almost any cloud provider. And, therefore, dependence on the cloud provider is also a thing of the past.
>*No newsletter, no email address transfer, contact by email only for this purpose.
Your email address will not be published. Required fields are marked *
* = Required field
* = Required field
* = Required field
* = Required field
Thomas Tikwinski is head of development in our Corporate Output Management Systems division. With 30 years’ experience in software engineering, he looks to technically solid, long-term viable solutions which can be used flexibly in diverse scenarios. He likes to spend his leisure time sailing or getting in some archery practice.
View All Events