Group Communication behind the scenes(번역본)

원본 url

http://mysqlhighavailability.com/group-communication-behind-the-scenes/

Group communication behind the scenes

September 30, 2014UncategorizedLabs, MySQL, MySQL Group ReplicationTiago J.

Introduction

The multi master plugin for MySQL is here. MySQL Group Replication ensures virtually synchronous updates on any node in a group of MySQL servers, with conflict handling and failure detection. Distributed recovery is also in the package to ease the process of adding new nodes.

For a better understanding on how things work, we go under the hood in this post and you will have a better understanding about the communication layer functionality and implementation.

여기에서 MySQL를 위한 Multi-Master 플러그인을 소개한다. MySQL Group Replication은 경합 처리 및 장애 감지, 서버 그룹의 노드들 사이의 동시에 수정작업을 할 수 있는 구성이다. 분산된 복구 처리는 새로운 노드를 추가할 때 용이하게 사용하기 위한 패키지 중 하나이다. 멀티마스터 리플리케이션이 동작하는 방법에 대한 더 나은 이해를 위해 우리는 이 글을 작성했고, 사용자는 여기에서 통신 레이어 기능과 구현에 대해 좀 더 자세히 알 수 있을 것이다.

Group Communication concepts

Figure 1 – Plugin Architecture

As the architecture shown in Figure 1, Group Replication is a classic modular and layered piece of software and the bottom two layers comprise the communication module. But, it is not a regular point-to-point connection, as in classical Replication, but rather a different paradigm: Group Communication.

1번 그림을 보면, 그룹 리플리케이션은 예전부터 만들었던 모듈화된 소스 부분을 계층화해서 구성하였고, 하부의 2층은 통신 모듈을 포함한 것을 알 수 있다. 그러나, 그것은 일반적인 일반 리플리케이션과 같은 point-to-point 연결이 아니라 좀 다른 개념을 가지고 있다. 바로 그룹 커뮤니케이션이다. 

The Group Communication abstraction can be seen as a vast field of study about distributed interprocess communication, providing a set of primitives and services that allows the creation of reliable, dependent and highly available software. Apart from being an academic concept it is implemented, in the form of libraries and frameworks, and used thoroughly in the software industry.

추상화한 그룹통신은 신뢰가 가고 종속적이면서도 유용한 소프트웨어에 허용하는 서비스로 아직은 덜 발달된 분야로 분산간 통신에 대한 연구의 광대한 분야로 볼 수 있다. 학술 개념으로 시작했지만, 현재는 소프트웨어 업계에 라이브러리나 프레임워크로 구현되어 사용되고 있다.

Talking about the concepts, one of the cornerstones in Group Communication is the Group itself. It can be defined as a set of nodes that have the ability to communicate with each other. On top of this, one can build all sort of services and functionalities.

개념에 대해 이야기 하면, 그룹 커뮤니케이션의 초석 중의 하나는 바로 그룹 자체이다. 그룹은 서로 통신할 수 있는 능력을 가진 노드들의 집합이라 정의할 수 있다. 이들의 가장 상위에 모든 종류 하나의 서비스와 기능을 구성할 수 있다. 

In order to be aware of the groups members in any moment in time, we use a service named Group Membership. It builds itself using the Group definition and adding the notion of View, which can be defined as the state of the Group in a certain moment in time. If offers primitives that allow a node to Join and Leave a group, informing all the interested parties of that event. It also offers dynamic Group reconfiguration, in which failed members are automatically evicted from a Group.

언제라도 그룹의 멤버를 알아내기 위해, 우리는 그룹 멤버쉽이라고 하는 서비스를 사용한다. 특정 시점에 그룹안의 상태를 정의할 수 있게 view의 개념을 추가하고 그룹의 정의를 사용하여 구성한다. 그룹에서 노드가 추가되거나 삭제하는 것을 허용하게 하는 기능을 제공하는데, 그 기능은 해당 이벤트에 대한 이해당사자들에게 해당 내용을 알리는 작업을 한다. 또한, 다이나믹하게 그룹을 재설정할 수있게 해주는데, 그룹에 자동적으로 제거하는 것을 실패하는 것과 같은 상황에서 동적으로 재설정하게 제공한다.

Another service relevant to Group Replication is the Total Order broadcast primitive. It allows for a node to send a message to a Group and ensure that, if one node receives the message, then all nodes receive it. It also guarantees that all messages arrive in the same order in all nodes that belong to a Group.

그룹리플리케이션의 또다른 과련 서비스는 Total Order broadcast 기능이다. 만약 하나의 노드가 메세지를 보내면 모든 노그가 그 메세지를 받게 되어있는 것으로 그룹안의 모든 노드들에 메세지를 보낼 수 있고, 그것을 보장하는 기능을 말한다. 또한, 그룹안의 모든 노드들이 받는 메세지의 순서도 같이 보장한다.

FIgure 2 – Typical Node workflow in a Group

A typical lifecycle of a node can be seen in Figure 2:

그림2에서 보여지는 노드의 주기는 다음과 같다.

1. A new Node calls join() in order to enter a group;

새 노드가 join()을 호출하여 순서대로 그룹에 들어간다. 

2. All members, including the new Node receive the Group’s new View.

모든 멤버들이 Group의 새로운 view를 받아 새로운 노드가 추가된것을 알았다.
It becomes Node 3 within the Group.

그리고 그 서버는 새로운 그룹의 노드로 3번 노드가 되었다. 

3. All nodes in the Group continue to exchange messages. Those messages will be delivered using Total Order Broadcast.

그룹안의 모든 노드들은 메세지를 주고 받는다. 이 메세지들은 Total Order Broadcast로 주고 받게 된다. 

4. Node 3 decides to leave the Group. It calls the leave() primitive.

3번 노드는 그룹에서 떠나기로 결정하고 leave() 함수를 호출한다.
Note: This could also happen due to Node 3 crash. Then it would not call leave(), but the View Membership would detect the failure and start this process automatically.

이와 같은 경우는 3번 노드에 문제가 발생했을 경우 일어날 수 있다. 하지만, leave()을 콜하지 못할 수도 있다. 그러나 View Membership에서 장애를 검출하고 자동적으로 leave()작업이 일어나게 하기도 한다.

5. All members receive the Group’s new View, without Node 3.

3번 노드가 없는 새로운 View가 그룹내의 모든 멤버들에게 전달된다. 

6. The process can start all over again.

이 과정은 모두 다시 시작될 수 있다.

Just to open the hood on Group Communication frameworks, the above services are mostly implemented using, in the communication layer, multicast or full network meshes and in the logical layer, software components such as failure detectors and consensus algorithms. The beauty lies in the combination of all these to provide middleware with such strong guarantees and above all, with a simple API.

그룹 커뮤니케이션 프레임웍을 구현하기 위해, 위의 서비스들은 커뮤니케이션 레이어나 전체 그물망 네트워크 안, 그리고 논리 레이어 안에서 사용할 수 있는 장애 검출, 컨센서스 알고리즘과 같인 소프트웨어 컴포넌트들을 사용하여 구현하였다. 이 모든 것들을 아름답게 구성하고 조합하여 제공하여 간단한 API와 작업에 해단 강력한 보장을 해주는 미들웨어를 제공한다.

These strong reliability properties will allow us to create a Distributed State Machine on top of it, that will serve as a base for implementing the algorithms described in [1].

이렇게 구성하여 구현된 강력한 기능을 이용하여 분산 상태에서 서버를 구성할 수 있게 된 것이다.

How was it designed and implemented?

We followed a top-down approach on this subject. A generic interface was created to serve the business logic layer. It has the obvious advantage of decoupling any external software that we use from the actual implementation. It will also allow us to benchmark individually each Group Communication framework with a single test platform in order to compare performance and limitations of different implementations.

우리는 이 주제를 top-down 방식으로 설명하고 있다. 일반적인 인터페이스는 비즈니스 로직 레이어를 제공하면서 생성된다. 이것은 우리가 실제 구현함에 있어서 추가적인 소프트웨어를 사용하지 않아도 되는 잇점이 있다. 또한 성능과 다른 구현의 한계를 비교하기 위해 개별적으로 하나의 테스트 플랫폼을 가지고 각 그룹 커뮤니케이션 프레임을 벤치마크 테스트를 할 수 있게 할 것이다. 

Without entering in too much detail, we gathered the common functionality from most implementations and together with our requirements, three interfaces were devised:

너무 많은 세부 사항은 입력하지 않고, 우리는 대부분의 구현 부분에서 공통 기능을 모았고, 그것으로 3가지 인터페이스를 제공하였다.

– A Control interface that will allow a node to manage its status within a group with primitives like Join, Leave and callbacks to View Membership information.

- Control interface : 그룹안의 상태 정보를 관리하여 보여주는 인터페이스 ( 그룹에 추가, 삭제, 멤버 정보를 전달해야 하는 기능등등)
– A Message interface that allows a node to send and receive messages.

- Message Interface : 각 노느들에 메세지를 전달하고 받게 해주는 인터페이스
– A Statistics interface to store and extract information about the Group and Messages.

- Statistics interface : 그룹과 메세지에 대한 정보를 저장하고 추출하는 인터페이스

We call this the Interface, as opposing to the actual implementation that we shall call Bindings. In this project, we did not implemented a full-fledged Group Communication Framework, but instead we decided to use an existing product that would suit our needs. That product is Corosync [2], and it will be the single Binding available in this first release.

우리가 인터페이스를 호출하는데 실제 바인딩으로 호출하는 것과는 다른 방식으로 호출한다. 이 프로젝트에서 우리는 본격적인 그룹 통신 프레임 워크를 구현하지 못했지만, 대신 우리는 우리의 요구에 맞게 것이다 기존 제품을 사용하기로 결정했다. 그것은 바로 corosync 라는 것이다. 그리고, 이것은 첫번째 릴리즈에서 하나의 바인딩을 사용할 수 있게 되어있다.

Corosync is a cluster engine that has in its base the usage of Group Communication. Its goal is to aid in the development of reliable and highly available application. Taking into account our requirements its a good first choice since:

Corosync는 그룹커뮤니케이션을 할 수 있게 지원하는 클러스터 엔진이다. 이것은 신뢰성과 가용성이 높은 응용 프로그램의 개발에 도움이 되게 하기 위해 개발되었다. 다음에 기술된 것 같은 우리의 요구사항을 처리할 수 있다. 

– If offers what we need in terms of functionality in its Closed Process Group communication model.

- 우리가 요구하는 폐쇄적인 그룹 커뮤니케이션 모델 안에서 필요한 기능을 제공합니다.
– It has a C API.

- C API를 제공합니다.

– It is proven and deployed solution, for instance, in Pacemaker and Apache Qpid.

- 이것은 이미 입증되어 배포되어있다. 예를 들어, Pacemaker and Apache Qpid 에서 배포되어 사용하고 있다.

Corosync binding implements all three sub-interfaces, adding on top of it some customizations, being the main one an algorithm in which all nodes execute an additional step by exchanging their status right after a View Membership change. In that step, they agree upon the next View and exchange generic data provided by the upper layers that use the binding implementation.

This binding implementation also provides all low-level statistics regarding the communication backbone extending the already known and proven Performance Schema interface. For more detail on that information follow the link to this post.

In order to install and configure Corosync and MySQL Group Replication, please follow the link to this blog post and try this exciting new feature.

references

[1] – Fernando Pedone, Rachid Guerraoui, and Andre Schiper. The database state machine approach, 1999.

[2] – Corosync – http://corosync.github.io/corosync/