You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


IDIEP-28
Author
Sponsor
Created

31-Oct-2018

Status

DRAFT


Motivation

The Apache Ignite cluster balance procedure with enabled persitence currently doesn't utilize network and storage device throughout to its full extent. The balance procedure processes cache data entries one by one which is not efficient enough for the cluster with enabled persistence.

Description

The Apache Ignite needs to support cache rebalancing as transferring partition files using zero copy algorithm based on an extension of communication SPI and Java NIO API.

Process overview

There are two participants in the process of balancing data: 

  1. demaner (receiver of partition files)
  2. supplier (sender of partition files)

The process of ordering cache groups for rebalance remains the same. 
The whole process is described in terms of rebalance single cache group:

  1. The GridDhtPreloaderAssignments created for cache group (type of Map<ClusterNode, GridDhtPartitionDemandMessage>)

CommunicationSpi

To benefit from zero file copy we must delegate the file transferring to FileChannel#transferTo(long, long, java.nio.channels.WritableByteChannel) because the fast path of transferTo method is only executed if the destination buffer inherits from an internal JDK class.

  • The CommunicationSpi needs to support pipe connections between two nodes;
    • The WritableByteChannel needs to be accesses on the supplier side;
    • The ReadableByteChannel needs to be read on the demander side;
  • The CommunicationListener  must be extended to respond on new incoming pipe connections;

Partition transmission

The cache partition file transfer over the network must be done using file chunks with validation of received piece of data on the demander side.

  • The new layer over the cache partition file must support direct using of FileChannel#transferTo method over the CommunicationSpi pipe connection;
  • The process must support transferring the cache patition file by chunks one by one;
  • The connection bandwidth of must have an ability to be limited at runtime;

Checkpoint on demand

Temp-WAL recovery

Risks and Assumptions

A few notes can be mentioned:

  • If operating system does not support zero copy, sending a file with FileChannel#transferTo might fail or yield worse performance.
    For example, sending a large file doesn't work well enough on Windows;
  • The ssl must be disabled to take an advantage of zero copy file transmission;

Discussion Links

// Links to discussions on the devlist, if applicable.

Reference Links

// Links to various reference documents, if applicable.

Tickets

// Links or report with relevant JIRA tickets.

  • No labels