Cluster members are programs that connect to a Tanzu GemFire cluster. You configure members to belong to a single cluster, and you can optionally configure them to be clients or servers to members in other clusters, and to communicate with other clusters.
Cluster members (or simply “members”) connect to the Tanzu GemFire cluster when they create the Tanzu GemFire data cache. The members’ cluster is configured through Tanzu GemFire properties. See gemfire.properties and gfsecurity.properties (Tanzu GemFire Properties). Tanzu GemFire properties specify all necessary information for member startup, initialization, and communication.
Note: You cannot change a member’s properties while the member is connected to the cluster.
Use the properties to define:
- How to find and communicate with other members
- How to perform logging and statistics activities
- Which persistent configuration or
cache.xmlfile to use for cache and data region initialization
- Other options, including event conflation, how to handle network loss, and security settings
Every Tanzu GemFire process is a member of a cluster, even if the cluster is defined as standalone, with just one member. You can run an individual cluster in isolation or you can combine clusters for vertical and horizontal scaling. See Topology and Communication General Concepts.
- Peer-to-Peer Clusters. Members that define the same member discovery properties belong to the same cluster and are peers to one another.
- Client/Server Installations. The client/server topology uses relationships that you configure between members of multiple clusters. You configure some or all of the peers in one cluster to act as cache servers to clients connecting from outside the cluster. Each server can host many client processes, managing cache access for all in an efficient, vertically hierarchical cache configuration. You configure the client applications to connect to the servers, using a client cache configuration. Clients run as members of standalone Tanzu GemFire clusters, with no peers, so all data updates and requests go to the servers.
The multi-site topology uses relationships that you configure between members of multiple clusters. Through this configuration, you loosely couple two or more clusters for automated data distribution. This is usually done for sites at geographically separate locations. You configure a subset of peers in each cluster site with gateway senders and/or gateway receivers to manage events that are distributed between the sites.
In the context of a single cluster, unless otherwise specified, “remote member” refers to another member of the same cluster. In client/server and multi-site installations, “remote” generally refers to members in other clusters. For example, all servers are “remote” to the clients that connect to them. Each client runs standalone, with connections only to the server tier, so all servers and their other clients are “remote” to the individual client. All gateway receivers are “remote” to the gateway senders that connect to them from other clusters, and to those gateway senders’ peers.