A Jgroups Configuration for Infinispan Distributed Cache

Masaryk University Faculty of Informatics JGgroups Configurator and Visualiser Master’s Thesis Bc. Michal Sorentíny Brno, Spring 2017 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Bc. Michal Sorentíny Advisor: RNDr. Adam Rambousek, Phd. i Acknowledgement I would like to thank to both of my advisors RNDr. Adam Rambousek, Phd. and Mgr. Radim Vansa for valuable feedback during all hard times I had writing this thesis. ii Abstract JGroups is a messaging toolkit for reliable multicast communication. The diploma thesis analyzes possibilities of convenient configuration and visualization of JGroups clusters and describes creating a configurator and visual probe tool with ability to retrieve or change current configuration, state and statistics of running cluster in a graphical user interface. iii Keywords JGroups, Java, Probe, Cluster, IP Multicast iv Contents 1 Introduction ............................1 2 Problem Analysis .........................2 2.1 Terminology ..........................2 2.1.1 Cluster . .2 2.1.2 Node . .2 2.1.3 IP multicasting . .3 2.1.4 JMX . .4 2.1.5 Network reliability . .4 2.2 Clustering applications ....................6 2.3 JGroups ............................7 2.3.1 Current configuration and visualization options8 3 Problem Definition ........................ 11 3.1 Stack Overflow research .................... 11 3.2 Use Cases ........................... 11 3.2.1 Use case 1 . 12 3.2.2 Use case 2 . 12 3.2.3 Use case 3 . 13 3.2.4 Use case 4 . 13 3.2.5 Use case 5 . 13 4 Possible Solutions ........................ 16 4.1 Using JChannel ........................ 16 4.2 Using JMX .......................... 17 4.3 Utilizing existing ProbeHandler implementations ...... 17 5 Justification of Selected Solution ................ 19 6 Description of the Solution ................... 22 6.1 Graphical User Interface ................... 22 Header field group . 22 Information tab . 22 Configuration tab . 22 Monitoring tab . 23 6.2 Controllers .......................... 23 6.2.1 ClusterExplorer interface . 23 JChannelClusterExplorer . 24 ProbeClusterExplorer . 25 6.2.2 ClusterBuilder interface . 25 v void updateProtocol(Address node, Protocol protocol) 25 6.3 Utility classes ......................... 26 6.3.1 ProtocolFactory . 26 7 Conclusion ............................. 31 7.1 Evaluation of the Results ................... 31 7.1.1 Development process . 31 Requirements . 31 Design . 31 Implementation . 32 Verification . 32 Maintenance . 32 7.1.2 Used tools . 33 7.1.3 Lessons learned . 33 7.2 Possible Further Improvements ................ 34 A JGroups configuration for Infinispan distributed cache .. 38 vi List of Figures 2.1 Cluster Architecture [12] 3 2.2 JMX architecture[6] 5 2.3 The JGroups architecture [2] 8 2.4 Example of graphical cluster visualization using Clusplot [4] 9 3.1 Stack Overflow questions 12 3.2 Stack Overflow related tags 14 3.3 Use case diagram 15 6.1 Class diagram 27 6.2 Information tab 28 6.3 Configuration tab 29 6.4 Monitoring tab 30 vii 1 Introduction High availability of cheap microprocessors, high-speed networks and increasing need of higher computing power gave foundations to computer clustering. With computer clustering we can connect multiple computers or programs so that they can act as a single system. This is widely used in high availability systems and distributed computing. This thesis is aimed at JGroups – an open source Java framework that enables user to simply implement clustering functionality in it’s software. Jgroups is a great tool, however it’s configuration can be quite cumbersome in some situations. There is no graphical user interface that would guide the user through the cluster configuration or pointed at problems in configuration. The resulting application is called Jgroups-conf 1. It is published under the MIT License2 on GitHub.3 Second chapter contains a glossary of used terms, a brief analysis of the given problem, current clustering options and introduces the JGroups framework. Third chapter, the Problem Definition will describe the current sit- uation of the problem and how does it affect the end users. It identi- fies the use cases for different roles of the users. In the fourth chapter three possible solutions are be described and analyzed. Fifth chapter will include the list of features and the justification of the selected solution for each of the features. It’s detailed description and analysis will be included in the sixth chapter with the list of methods and screen shots of the actual application. Seventh chapter concludes the achieved result, evaluates proce- dures how were the results achieved and suggests further improvements of the developed application. 1. Further referenced only as application 2. https://opensource.org/licenses/MIT 3. https://github.com/Myhall/JGroups-conf 1 2 Problem Analysis 2.1 Terminology To properly understand the problem we will first have a look at basic terms necessary to understand the topic. 2.1.1 Cluster Cluster or often known as clustering, a group of nodes that operate independently and work closely with each other to be governed by a master computer (master node, coordinator) and will be seen by the user as if the computer is connected a computer unit.[1] Clustering is the practice of connecting multiple processors or servers using a high-speed interconnect such as InfiniBandTM to cooperate on com- plex workloads as a single, unified computing resource.[[8] Cluster consists of a set of loosely or tightly connected nodes that work to- gether so that they can be viewed as a single system.[13] Today, clusters are widely used for research and development of science, engineering, commerce and industry applications that de- mand high performance computations. In addition, clusters encom- pass strengths such as high availability and scalability that motivate wide usage in nonsupercomputing applications as well, such as clusters working as web and database servers.[12] The typical architecture of a cluster is shown in figure 2.1. Terms cluster and group are interchangeable in further context. 2.1.2 Node The computer clustering approach usually (but not always) connects a number of readily available computing nodes (e.g. personal computers used as servers) via a fast local area network. The activities of the computing nodes are orchestrated by "clustering middleware", a software layer that sits atop the nodes and allows the users to treat the cluster as by and large one cohesive computing unit, e.g. via a single system image concept. [7] 2 2. Problem Analysis Figure 2.1: Cluster Architecture [12] Cluster node is a single participant of the cluster, can be either a single hardware computer, a virtual machine or even a single software application. The node term is interchangable with the term member. 2.1.3 IP multicasting IP multicasting is the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e., the datagram is not guaranteed to arrive intact at all members of the destination group or in the same order relative to other datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restric tion on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it.[5] 3 2. Problem Analysis 2.1.4 JMX The Java Management Extensions (JMX) API is a standard API for management and monitoring of resources such as applications, de- vices, services, and the Java virtual machine. The JMX technology was developed through the Java Community Process (JCP) as Java Speci- fication Request (JSR) 3, Java Management Extensions1, and JSR 160, JMX Remote API2. Typical uses of the JMX technology include: ∙ Consulting and changing application configuration ∙ Accumulating statistics about application behavior and mak- ing them available ∙ Notifying of state changes and erroneous conditions. The JMX API includes remote access, so a remote management program can interact with a running application for these purposes. Fundamental concept of JMX are Managed Beans, or MBeans. An MBean is a managed Java object, similar to a JavaBeans component, that follows the design patterns set forth in the JMX specification. An MBean can represent a device, an application, or any resource that needs to be managed. MBeans expose a management interface that consists of a set of readable or writable attributes (or both), a set of invokable operations and a self-description.[11] The architecture of JMX is displayed in figure 2.1.4. 2.1.5 Network reliability As a reliable network protocol is considered a protocol that provides features for ensuring reliability in delivery of the data to the intended recipients. Main reliability properties are: ∙ Acknowledgment - user is notified if the delivery fails (nega- tive acknowledgment) or after receiving every packet (positive acknowledgement) ∙ Delivery guarantee - protocol guarantees data delivery to intended recipients 1. JSR 3: https://www.jcp.org/en/jsr/detail?id=3 2. JSR 160: https://www.jcp.org/en/jsr/detail?id=160 4 2. Problem Analysis Figure 2.2: JMX architecture[6] ∙ Last copy recall - as long as at least a single copy of a message remains available at any of the recipients, every other recipient that does not fail eventually also receives a copy ∙ Atomicity is stronger than the last copy recall.

Load more