Posts tagged Clustering
In order to make a cluster of servers appear as one server, you need to introduce a load balancer. A load balancer will accept a request, and redirect it to one of the members of the cluster depending on a given configuration. A web server such as NGINX or Apache can act as this load balancer as well as a reverse proxy, which allows the web server to load balance requests across the cluster, act as a termination point for SSL connections to reduce strain on the cluster, as well as cache server content for quicker access. In this blog, we will set up NGINX as a reverse proxy and secure it using SSL.
Continuing our introductory blog series, this blog will demonstrate how to add load balancing capability to Apache Web Server and forward to our simple Payara Server cluster.
A load balancer can redirect requests to multiple instances, primarily for the purpose of distributing incoming requests between cluster members based on pre-determined rules. This could be a simple "round-robin" algorithm, where the workload is distributed to each instance in turn, or a weighted algorithm where requests are delivered based on a pre-determined weight for each cluster member.
Continuando con nuestra serie de blogs de introducción, este blog va a demostrar como añadir la capacidades de balanceo de carga a un Servidor Web Apache y asi re-enviar las peticiones HTTP a nuestro cluster de Payara Server.
Continuing our introductory blog series, this blog will demonstrate how to set up a simple Hazelcast cluster of two instances.
In contrast to a development environment, where a single server is enough to act as a "proof of concept", in production it is usually necessary to look at reliably hosting your application across multiple redundant hosts to guarantee a reliable service and allow for future scaling. With Payara Server, it is possible to easily create and add instances to clusters using Hazelcast, making configuration of a distributed application a breeze.
Continuando con nuestra serie de introducción, este blog va a demostrar como configurar un cluster sencillo de dos instancias mediante Hazelcast.
Kick-starting yet another year, we are pleased to announce our largest release yet - Payara Server 184.108.40.206. Building on a year's worth of updates and improvements, in this release, you can find 18 brand new features and over 60 new fixes and enhancements for Payara Server & Payara Micro! Given the size of the additions, look out for detailed blogs in the near future. For now, check out below for a summary of the changes in 171 release, and have a look at the full release notes.
Another quarter, another release! After an eventful 2016, November brings with it the final release of the year for Payara Server. This year, we've seen new services like Request Tracing and Health Check added, as well as the Slow SQL logger and SQL Trace Listeners. Revisiting the version of the documentation from 1 year ago and comparing the amount we have added since then is, frankly, astonishing!
Despite a bumper year for both new features and bug fixes, work continues apace! Below is a short summary of some of the things to look out for in a release that caps an incredible 12 months.
Any project, large or small, would ultimately like to follow industry best practices, such as continuous deployment. In order to support this, applications must be deployed early and often. This, in turn, triggers downtime and the users get affected by it because they could be logged out of the website, or worse, their work gets lost because the application's intermediate state is not saved - never mind the actual downtime during the application deployment process.
Rolling upgrades solve this problem in an efficient way!
Payara Micro is packed with most of the features and APIs that come with Payara Server Full Profile even though it doesn't entirely support whole Jakarta EE Full Profile. As an example, Payara Micro supports persistent EJB Timers, which are only required by the Jakarta EE Full Profile and not by the Web Profile. In Payara Micro, it's possible to use persistent EJB Timers, which are stored across your micro instances inside the distributed data grid as long as at least one instance in the data grid is up and running.