VMware Tanzu GemFire Architecture
Tanzu GemFire Basics
Apache Geode is the data store within VMware Tanzu GemFire for VMs. A Tanzu GemFire service instance requires a small amount of administrative setup, and any app will use a limited portion of the API.
The Tanzu GemFire architectural model is a client-server model. The clients are apps or microservices, and the servers are a set of cluster servers maintained by a Tanzu GemFire service instance. The servers provide a low-latency, consistent, fault-tolerant data store within Tanzu GemFire.
The cluster holds data in key/value pairs. Each pair is called an entry. Entries are logically grouped into sets called regions. A region is a map (or dictionary) data structure.
The app (client) uses Tanzu GemFire as a cache. A cache lookup (read) is a get operation on a region. The cache operation of a cache write is a put operation on a region. The command-line interface, called gfsh, facilitates region administration. Use gfsh to create and destroy regions within the Tanzu GemFire service instance.
The App’s Location
A running app’s location affects how it communicates with the Tanzu GemFire service instance. Apps may run in one of three locations:
- In the services foundation where the Tanzu GemFire service instance runs. These apps require no extra communication support.
- In an app foundation, where a user-provided service instance proxies the communication to the Tanzu GemFire service instance. Communication with the Tanzu GemFire service instance requires a service gateway.
- Outside of any platform, where a platform is composed of any and all foundations. Communication with the Tanzu GemFire service instance requires a service gateway.
To use a service gateway, the operator must Configure a Service Gateway. The developer must Provide Optional Parameters when creating the Tanzu GemFire service instance. And, the app must be given and use properties that authenticate and authorize Communicating with a Service Instance through the service gateway.
Member Communication
When a client connects to the cluster, it first connects to a locator. The locator replies with the IP address of a server for it to talk to. The client then connects to that server.
When the client wants to read or write data, it sends a request directly to the server.
If the server doesn’t have the data locally, it fetches it from another server.