Avanzando más nuestra serie de blogs de introducción, esta entrada mostrará como puedes escalar de forma dinámica tu cluster, y como Payara Server maneja la conmutación por fallas entre miembros del cluster.
La conmutación por fallas es la habilidad de continuar proporcionando acceso a nuestro sitio web o aplicación en el caso de que un servidor falle. Es una parte importante de un servicio que goza de alta disponibilidad, cuyo objetivo es minimizar los tiempos de inactividad a lo largo de tu infraestructura de servicios.
First quarter of 2018 will bring with it our long-awaited Payara 5, fresh out of Beta. Scheduled for a Q1 release (download the Release Candidate here), Payara 5 brings with it a host of improvements to Payara Server and Payara Micro. Bringing long-awaited upgrades to a raft of APIs, as well as a rethinking of the cluster concept, Payara 5 also brings us up to date with Eclipse MicroProfile 1.2 and the core functionality of GlassFish 5.
Previously in GlassFish and Payara Server, if you wanted to monitor the status of your application's MBeans, you would have to rely mostly on external programs to capture the data. In Payara Server 174, we integrated the JMX Monitoring service with our existing notification service, meaning that you can now remotely receive monitoring data via any of our notifiers, from email to Slack.
Taking our introductory series onwards, this blog will look at how you set up a simple Payara Server cluster on Windows using the native remote control protocol, DCOM. We will set up two instances on Windows 10, controlled by a third Domain Administration Server (DAS) instance on Windows 7 via DCOM, and cluster them together using Hazelcast. Finally, we will deploy our trusty clusterjsp application to demonstrate how the data is being shared across our instances.
Further developing our introductory blog series, this post will look at how you can dynamically scale your cluster, and how Payara Server handles failover between cluster members.
Failover is the ability to continue to provide access to your website or application in the event of a server failing. It is an important part of high availability hosting, which aims to minimise downtime across your server infrastructure.
By clustering our Payara Servers together and balancing traffic between them with Apache Web Server we keep the benefits of having our application accessible from a single URL and gain the resilience and expansion prospects from having our application deployed across multiple instances.
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.
This spring's silver lining, Payara Server 184.108.40.206, a highly cloud-focused release, is now available!
Focusing on enhancing Payara Server and Payara Micro's ease-of-use in cloud environments, we've brought in new features to make working with Docker more seamless and secure, native support for SaaS monitoring solutions and a huge increase in messaging capabilities for Payara Micro! Inside this quarter's release you will find 54 fewer bugs, a host of ecosystem and cloud improvements, and an update to match GlassFish 4.1.2. Carry on reading for a summary of this quarter's changes, or check out the full release notes for a complete list of changes.