A data grid is a storage unit that can be
created to hold objects for a specific application or set of applications.
A collective groups appliances together for scalability
and management purposes. A zone defines a physical location
for your appliance and are used to determine the placement of the
data in your cache.
Appliance topology
Both collectives and zones
are associated with one or more
WebSphere® DataPower® XC10 Appliances. Each appliance
can be a member of one collective and one zone. Each appliance hosts
multiple data grids, which hold the cache data.
Figure 1. Collectives
and zones topology
Important: Two appliances are required to make your
data grid highly available.
Collectives and multimaster replication
Multimaster replication is a technique for ensuring continuous
availability across multiple deployment environments. Multimaster
topologies can be implemented in the
WebSphere DataPower XC10 Appliances by creating multiple
collectives and linking them. When you define a collective, the following
information is shared among the appliances in the collective:
data grids, monitoring information,
collective and zone members, and users. When you update any of this
information, your changes are persisted to all of the other appliances
in the collective. The
catalog service enables the communication
between appliances. The catalog service is a group of catalog servers.
Each appliance in the collective runs a catalog server, with a limit
of three catalog servers for each collective. If you have more than
three appliances in a collective, the catalog service runs on the
first three appliances that were added to the collective. If you remove
an appliance with a catalog server from the collective or an appliance
with a catalog server becomes unavailable, the next appliance that
you add to the collective runs a catalog server. The catalog server
does not fail over to other appliances.
To add an appliance to a
collective, add the host name and secret key for the appliance to
the collective configuration panel in another appliance. You can create
this configuration from any appliance in the collective, because the
collective membership is persisted among the collective members.
Appliances
can only be in one collective. You cannot add an appliance that is
already in a collective to a different collective. You also cannot
join two collectives into a single collective. To join appliances
from separate collectives, you must remove each appliance from its
respective collective, making each appliance stand alone. You can
then create a new collective that includes all of the appliances.
While
you can use a collective to make most configuration changes, you must
log in to a given appliance to change the settings on the and panels.
Zones
Zones are associated with a physical
location of the appliance, such as a city or rack location in a lab.
Zones help the catalog service to define where the data in your data grids is stored. For example,
if the primary information for your data grid is stored in a given
zone, then the replica data is stored in an appliance that is in a
different zone. With this configuration, failover can occur from the
primary to a replica if the appliance that holds the data grid primary fails.
Data grids
Data grids hold the objects for
your applications. By caching objects, you can increase the performance
of your application. There are three types of
data grids:
- Simple data grid
- Simple data grids hold
data in key-value pairs. For example, you can store the results of
a database query in a simple data grid.
You use the ObjectMap API to implement a simple data grid. The ObjectMap API works
similarly to Java™ Maps.
- Session data grid
- If you are using WebSphere Application Server sessions,
you can configure your application to use a session data grid on the appliance for
session management data. You can configure your application to use
a session data grid when you
are installing a new application. You can also update your existing
application or server settings to use the session data grid on the appliance.
- Dynamic cache data grid
- You can use a dynamic cache data grid on the appliance to store
data from your WebSphere Application Server dynamic
cache. You can enable applications that are written with the Dynamic
Cache API or applications that use container-level caching, such as
servlets, to use the appliance as the cache provider. As a result,
less memory is used by your application servers. All the cache data
is offloaded to the appliance and is no longer stored in application
server memory.
Data grid replicas
You can define a target
number of replicas for a given data grid.
Replicas are created when you have at least two appliances in your
collective. If you have one appliance, no replicas are created. If
you have n number of appliances in your collective,
the maximum number of replicas is n-1, because
one appliance hosts the primary data grid. If your target number of
replicas is higher than the current n-1, more replicas
can be placed when you add appliances to the collective. Consider
setting the number of replicas to the highest number of replicas you
might want in the future. Editing the replica settings requires the
data grids to be cleared, so set the value with consideration to the
future number of replicas. As new appliances join the collective,
additional replicas are created. Primary and replica data grids are
evenly distributed, or striped, across all of the appliances in the
collective. As new appliances join the collective, rebalancing occurs
to distribute the primary and replica data grids.
Replicas
can be synchronous replicas or asynchronous replicas. Synchronous
replicas receive updates as part of the transaction on the primary data grid. Asynchronous replicas
are updated after the transaction on the primary data grid is committed. Synchronous
replicas guarantee data consistency, but can increase the response
time of a request when compared with an asynchronous replica. Asynchronous
replicas do not have the same guarantee in data consistency, but can
make your transactions complete faster. A data grid has one asynchronous
replica by default. A placement algorithm controls where the replicas
are located.
Maps
Maps are the data structures that contain
the data for the data grid in key-value pairs. A single data grid
can have multiple maps that reside on the data grids and data grid
replicas.
You can create additional maps in
the data grid by having your client application connect to a specifically-named
map. A dynamic map is automatically created.
Collective links
A single
collective should not span an unreliable network because false positive
failure detections might occur. However, you might still want to replicate
data grid data across appliances that have unreliable network connectivity.
Some common scenarios where you might want to use this type of topology
follow:
- Disaster recovery between data centers where one collective is
active and the other is used for backup
- Geographically distributed data centers where all collectives
are active for geographically close clients.
After you connect two collectives, any data grids that have the
same names are asynchronously replicated between the collectives.
These data grids must have the same number of replicas in each collective,
and must have the same dynamic map configurations.