Clustering
Overview
GridGain cluster is a distributed system consisting of multiple nodes deployed on different machines and possibly different geographical locations. In this chapter, we discuss different roles nodes can play in a cluster and the different ways nodes can discover each other to form a cluster.
On start-up, a node can be assigned one of the two roles: server node or client node. Server nodes are the workhorses of the cluster — they participate in data caching, compute execution, stream processing, etc. Client nodes join the topology as regular nodes but they do not store data. Client nodes are used to stream data into the cluster and execute user queries.
To form a cluster, each node must be able to connect to all other nodes. To ensure that, a proper discovery mechanism must be configured.
In addition to client nodes, you can use Thin Clients to define and manipulate data in the cluster. GridGain provides thin clients for a variety of languages, such as java, .Net, C++, Node.JS, python, and PHP. Unlike regular client nodes, thin clients do not join the cluster topology (i.e. do not start a node); instead, they simply establish a socket connection to one of the cluster nodes and perform all operations via the binary protocol.
Servers and Clients
There are two types of nodes in a GridGain cluster: server nodes and client nodes. Server nodes participate in caching, compute execution, stream processing, etc. Native client nodes provide the ability to connect to the
servers remotely. GridGain native clients allow using the whole set of Ignite APIs, including near caching, transactions, compute, streaming, services, etc. from the client side.
By default, all GridGain nodes are started as server nodes, and the client mode needs to be explicitly enabled.
You can configure a node to be either a client or a server via the IgniteConfiguration.setClientMode(…) property.
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
...
<!-- Enable client mode. -->
<property name="clientMode" value="true"/>
...
</bean>IgniteConfiguration cfg = new IgniteConfiguration();
// Enable client mode.
cfg.setClientMode(true);
// Start Ignite in client mode.
Ignite ignite = Ignition.start(cfg);Alternatively, for convenience, you can also enable or disable the
client mode though the Ignition class to allow clients and servers to
reuse the same configuration.
Ignition.setClientMode(true);
// Start GridGain in the client mode.
Ignite ignite = Ignition.start();Ignition.ClientMode = true;
Ignition.Start();Thin Clients
A thin client is a lightweight GridGain client that connects to the cluster via a standard socket connection. It does not start in a JVM process (Java is not required at all), does not become a part of the cluster topology, never holds any data, and is not used as a destination of compute grid calculations. What it does is simply establish a socket connection to a standard GridGain node and perform all operations through that node.
For more information on thin clients, including code samples and usage examples, see the Thin Clients documentation.
Discovery Mechanisms
GridGain nodes can automatically discover each other and form a cluster. This allows you to scale out when needed without having to restart the whole cluster. Developers can also leverage GridGain’s hybrid cloud support that allows establishing connection between private and public clouds such as Amazon Web Services, providing them with the best of both worlds.
The GridGain discovery mechanism goes with two implementations intended for different usage scenarios:
-
TCP/IP Discovery is designed and optimized for 100s of nodes.
-
ZooKeeper Discovery that allows scaling GridGain clusters to 100s and 1000s of nodes preserving linear scalability and performance.
Communication SPI
CommunicationSpi provides basic plumbing to send and receive grid
messages and is utilized for all distributed grid operations, such as
task execution, monitoring data exchange, distributed event querying, and
others. GridGain provides TcpCommunicationSpi as the default
implementation of CommunicationSpi, that uses the TCP/IP to
communicate with other nodes.
To enable communication with other nodes, TcpCommunicationSpi adds
TcpCommunicationSpi.ATTR_ADDRS and TcpCommunicationSpi.ATTR_PORT
local node attributes. At start-up, this SPI tries to start listening to
the local port specified by the TcpCommunicationSpi.setLocalPort(int)
method. If the local port is occupied, then the SPI will automatically
increment the port number until it can successfully bind for listening.
The TcpCommunicationSpi.setLocalPortRange(int) configuration parameter
controls the maximum number of ports that the SPI will try before it
fails.
Below is an example of TcpCommunicationSpi configuration. Refer to the
TcpCommunicationSpi javadoc for the complete list of parameters.
<bean class="org.apache.ignite.configuration.IgniteConfiguration">
...
<property name="communicationSpi">
<bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
<!-- Override local port. -->
<property name="localPort" value="4321"/>
</bean>
</property>
...
</bean>TcpCommunicationSpi commSpi = new TcpCommunicationSpi();
// Override local port.
commSpi.setLocalPort(4321);
IgniteConfiguration cfg = new IgniteConfiguration();
// Override default communication SPI.
cfg.setCommunicationSpi(commSpi);
// Start grid.
Ignition.start(cfg);var cfg = new IgniteConfiguration {
CommunicationSpi = new TcpCommunicationSpi {
LocalPort = 1234
}
};
Ignition.Start(cfg);© 2020 GridGain Systems, Inc. All Rights Reserved. Privacy Policy | Legal Notices. GridGain® is a registered trademark of GridGain Systems, Inc.
Apache, Apache Ignite, the Apache feather and the Apache Ignite logo are either registered trademarks or trademarks of The Apache Software Foundation.