All Things WebSphere
Concerns and issues relating to all versions of WebSphere Application ServerSunday, September 27, 2009
JPA L2 Caching Overview*
Thursday, September 24, 2009
How to configure Dynacache with eXtreme Scale
Complete the following actions to enable the WebSphere eXtreme Scale dynamic cache provider.
1. Install the WebSphere eXtreme Scale client or client and server on your WebSphere Application Server install root for the remote and the remaining topologies respectively. gotcha: On WebSphere zOS ONLY the WXS client install and the "remote" topologies are supported.
2. Designate the WebSphere eXtreme Scale dynamic cache provider as your cache provider.
Each cacheinstance can be individually configured to use eXtreme Scale. Dynacache is the default cache provider for a cache instance. Cache instances configured with eXtreme Scale can coexist with cache-instances configured with DRS in the WebSphere Application Server.A cache instance can be configured to use WXS in three ways:
--WebSphere Admin console
In WebSphereND 6.1.0.x. in order to use the ObjectGrid as a cache provider, customer
will need to set the JVM custom property "com.ibm.ws.cache.CacheConfig.cacheProviderName" to
"com.ibm.ws.objectgrid.dynacache.CacheProviderImpl".
In WebSphereND 7.0.x.x, Customer can configure the Dynacache Service to use the ObjectGrid Cache provider using the Dynacache service admin console panel.
--cacheinstances.properties file bundled in the enterprise application
Set the cacheProviderName property in the cacheinstances.properties file to "com.ibm.ws.objectgrid.dynacache.CacheProviderImpl"
For example line to be added for cache.instance.26
cache.instance.26.cacheProviderName = com.ibm.ws.objectgrid.dynacache.CacheProviderImpl
--Factory APIs in enterprise application code:
Properties p = new Properties();
==>p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
3. Configuration the cache instance for replication :
If you are only going to use local cache instances, no further configuration is required. Go to last step, and save your configuration changes. In a local cache the eXtreme Scale container is colocated with the WebSphere JVM, i.e. both share the same JVM heap.
-If you are going to use replicated caches you will need to do one of the three actions below depending on how you have created the cache instance.
- admin console
-- In WebSphereND 6.1.0.x create a custom property with name "com.ibm.ws.cache.CacheConfig.enableCacheReplication" and value "true".
-- In WebSphereND 7.0.x.x check the enableReplication checkbox when the CacheProvider selected is "ObjectGrid".
- cacheinstances.properties file bundled in the enterprise application
--Set the enableCacheReplication property in the cacheinstances.properties file to "true"
For example line to be added for cache.instance.26
cache.instance.26.enableCacheReplication = true
-Factory APIs in enterprise application code:
Properties p = new Properties();
p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
==>p.put(CacheConfig.ENABLE_CACHE_REPLICATION, "true");
DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
4. Configure the WXS replication topology and optionally the number of initial containers for the cache instance.
- admin console
-- In WebSphereND 6.1.0.x and 7.0.x.x create a custom property with name "com.ibm.websphere.xs.dynacache.topology"
and one of the following values in the Value field "embedded", "embedded_partitioned", and "remote". For details on these please see
http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsp?topic=/com.ibm.websphere.extremescale.over.doc/txsdyncache.html
.
-- If you specified embedded_partitioned configure the number of initial containers for the dynamic cache service.
In WebSphereND 6.1.0.x and 7.0.x.x create a custom property with name "com.ibm.websphere.xs.dynacache.num_initial_containers"
an integer that is equal to or slightly less than the total number of server instances that are accessing this distributed cache instance
in the Value field. For example, if a dynamic cache service is shared between grid members, then the variable should be set to
the number of grid members.
- cacheinstances.properties file bundled in the enterprise application
--Set the com.ibm.websphere.xs.dynacache.topology property in the cacheinstances.properties file to one
of "embedded", "embedded_partitioned", and "remote"
For example line to be added for cache.instance.26
cache.instance.26.enableCacheReplication = embedded
-- If you specified embedded_partitioned configure the number of initial containers for the dynamic cache service.
Set the com.ibm.websphere.xs.dynacache.num_initial_containers property in the cacheinstances.properties to
an integer that is equal to or slightly less than the total number of server instances that are accessing this distributed cache instance
in the Value field. For example, if a dynamic cache service is shared between grid members, then the variable should be set to
the number of grid members.
-Factory APIs in enterprise application code:
Properties p = new Properties();
p.put(CacheConfig.CACHE_PROVIDER_NAME, CacheConfig.CACHE_PROVIDER_OBJECT_GRID);
p.put(CacheConfig.ENABLE_CACHE_REPLICATION, "true");
==>p.put("com.ibm.websphere.xs.dynacache.topology", "embedded");
==>p.put("com.ibm.websphere.xs.dynacache.num_initial_containers", "3");
DistributedMap map1 = DistributedMapFactory.getMap("myMap", p);
DistributedMap map2 = DistributedObjectCacheFactory.getMap("myMap2", p);
5. Configure the eXtreme Scale catalog service grid.
When you are running a catalog service grid, you must set the catalog.services.cluster custom property for the catalog service endpoints.
To Start the catalog service process in a WebSphere Application Server environment see
http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/topic/com.ibm.websphere.extremescale.admin.doc/txscatalogstartwas.html
a. In the administrative console, click System administration > Cell > Custom properties > New.
b. Enter catalog.services.cluster the Name field, and the appropriate server_name:host_name:client_port:peer_port:listener_port value in the Value field.
server_name is the fully qualified name of the WebSphere process, such as the cell name, node name, or server name, of the server that hosts the catalog service.
Example cellA\node1\nodeagent
host_name is the name of the hosting server.
client_port is the port that is used for peer catalog grid communication.
peer_port is the port that is used for peer catalog grid communication.
listener_port is the listener port. This port must match the BOOTSTRAP_ADDRESS value that is defined in the server configuration.
Following is an example of a valid value: cellA\node1\nodeagent:host.local.domain:6600:6601:2809,cellA\node2\nodeagent:host.foreign.domain:6600:6601:2809
c. Click OK.
6. Save all your configuration changes and restart all the application servers configured for using eXtreme Scale.
7. Configure custom key objects.
When you are using custom objects as keys, the objects must implement the Serializable or Externalizable interface. When you are using the embedded or embedded partitioned topologies, you must place the objects on the shared library path, like you do if you are using the default dynamic cache provider. See the topic Using the DistributedMap and DistributedObjectCache interfaces for the dynamic cache for more information. If you are using the remote topology, you must place the custom key objects on the CLASSPATH for the standalone WebSphere eXtreme Scale containers. See the steps to start a container process in the WebSphere eXtreme Scale Version 7.0 Administration Guide for more information. This publication is available on the WebSphere eXtreme Scale library page.
8. Configure eXtreme Scale container servers.
The cached data is stored in WebSphere eXtreme Scale containers. These containers can run inside or outside of a WebSphere Application Server process. The eXtreme Scale provider automatically creates containers inside a WebSphere Application Server process when you are using embedded or embedded partitioned topologies for a cache instance. No further configuration is needed for these topologies.
When you are using the remote topology, you must start up stand-alone eXtreme Scale containers before you start the WebSphere Application Server instances that access the cache instance. See the steps to start stand-alone containers in the WebSphere eXtreme Scale Version 7.0 Administration Guide for more information. Make sure that all the containers for a specific dynamic cache service point to the same catalog service endpoints.
The dynacache-remoteobjectgrid. xml and dynacache-remote-definition.xml configuration files for the standalone eXtreme Scale Dynamic Cache provider containers are located in the install_root/customLibraries/ ObjectGrid/dynacache/etc directory if WebSphere eXtreme Scale is installed on top of the WebSphere Application Server product, or in the install_root/ObjectGrid/dynacache/etc directory if you are using a stand-alone version of WebSphere eXtreme Scale. Make copies of these files to edit and use when launching standalone containers for the eXtreme Scale dynamic cache provider. The value specified for the numIntitialContainers parameter in the dynacache-remote-deployment.xml file should be based on the number of container processes being run.
The following example illustrates a UNIX® command line entry that launches a standalone container for the WebSphere eXtreme Scale dynamic cache provider:
startOgServer.sh container1 -objectGridFile ../dynacache/etc/dynacache-remoteobjectgrid.xml -deploymentPolicyFile ../dynacache/etc/dynacache-remotedeployment.xml -catalogServiceEndpoints MyServer1.company.com:2809
gotcha: The set of container processes needs to have enough free memory to service all the dynamic cache instances configured to use the remote topology. Any WebSphere Application Server process that shares the same or equivalent values for catalog.services.cluster must use the same set of standalone containers. The number of containers and number of machines they reside on needs to be sized appropriately. See the topic Capacity planning and high availability in the WebSphere eXtreme Scale Version 7.0 Product Overview for additional details. This publication is available on the WebSphere eXtreme Scale library page. Please see the capacity planning section in the WXS Infocenter: http://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/topic/com.ibm.websphere.extremescale.over.doc/cxscapacityplan.html
9. VALIDATION:
If the cacheinstance was successfully configured to use eXtreme Scale you will see the following statement in the WebSphere Application Server SystemOut.log
DYNA1001I: WebSphere Dynamic cache instance named "{0}" initialized successfully using cache provider "{1}".
DYNA1071I: The cache provider \"{0}\" is being used.
If the configuration and initialization of the cacheinstance with eXtreme Scale FAILED Dynacache runtime will revert to the default Dynacache cache provider and you should expect to see the following messages in the SystemOut.log
DYNA1066E: Unable to initialize the cache provider \"{0}\". The Dynamic cache will be used to create the cache instance \"{1}\" instead of the configured cache provider.
Sunday, September 20, 2009
Dynacache marries WebSphere eXtreme Scale
1. Introduction
The dynamic cache engine is the default cache provider for the Dynacache APIs and frameworks. Starting WebSphere Application Server 7.0.0.5 and 6.1.0.27 Dynacache allows WebSphere eXtreme Scale to act as the core caching engine for Dynacache. You can configure the dynamic cache service to use WebSphere eXtreme Scale as your cache provider instead of the default dynamic cache engine. This provides customers the ability to leverage transactional support, improved scalability, high availability and other XTP features without making changes to their existing Dynacache caching code. See Infocenter. This capability can also be enabled on WAS service packs 6.1.0.23, 6.1.0.25 and 7.0.0.3 via APAR PK85622.
2. What is eXtreme Scale
WebSphere eXtreme Scale can operate as an in-memory database processing space, which you can use to provide in-line caching for a database back-end or to serve as a side-cache. In-line caching uses eXtreme Scale as the primary means for interacting with the data. When eXtreme Scale is used as a side-cache, the back-end is used in conjunction with the eXtreme Scale.
Data Sheet:http://tinyurl.com/lfq9qu
Wiki: http://tinyurl.com/krvpvp
Youtube Channel: http://tinyurl.com/m4ruko
3. Before you begin
Determine whether using WebSphere eXtreme Scale is beneficial to the applications running in your application servers. The WebSphere eXtreme Scale features significantly increase the distributed capabilities of WebSphere Dynacache beyond what is offered by the default dynamic cache engine and data replication service. With WebSphere eXtreme Scale, you can create caches that are truly distributed between multiple servers, rather than just replicated and synchronized between the servers. eXtreme Scale caches are transactional and highly available, ensuring that each server sees the same contents for the dynamic cache service. WebSphere eXtreme Scale offers a higher quality of service for cache replication than DRS. However, these advantages do not mean that the eXtreme Scale dynamic cache provider is the right choice for every application. Use the decision trees and feature comparison matrix provided in the WebSphere eXtreme Scale Version 7.0 Product Overview publication to determine if this technology is beneficial to your applications. This publication is available on the WebSphere eXtreme Scale library page. Determine the appropriate eXtreme Scale topology for your caching deployment by looking at the section on Topology types on http://tinyurl.com/mz2mo7
4. Why eXtreme Scale ?
WebSphere eXtreme Scale (WXS) is the strategic direction for caching with the WebSphere platform. WebSphere session memory to memory replication can also be configured with WebSphere eXtreme Scale. WXS can fulfills all the generic data and session caching needs of your application. Compelling use cases for using Dynacache with eXtreme Scale and the value add Dynacache provides to WXS is listed below:
- If you are currently spending a lot of money on expensive SAN or storage solutions for hosting the Dynacache disk cache then eXtreme Scale can help your applications leverage system memory instead of expensive SANs and offer better performance. All the cache data will be kept in memory in the WebSphere eXtreme Scale servers eliminating the need for a Dynacache disk cache .
- If you are having issues with performance of the Data Replication Service that is used by Dynacache to replicated data, eXtreme Scale can eliminate all those issue by virtue of providing a scalable replicated cache with a configurable number of replicas. Cache capacity can be increased by simply adding more WXS containers at runtime. WXS automatically redistributes the partitions as new containers are added to the grid.
- If you are existing customer of Dynacache that leverages Dynacache APIs and frameworks and want better caching qualities of service and control, using eXtreme Scale will provide the best of both worlds, i.e. excellent Dynacache plugins like servlet caching, webservices, command caching as well as the scalability of a world class in memory replicated cache. Switching from the default Dynacache provider to WXS need just configuration changes via the admin console or wsadmin. There are no changes to the Dynacache programming model.
- Designed and tested to work together. Dynacache and eXtreme Scale combined solution have gone through extensive functional, system, integration and performance testing.
- All runtime monitoring and administration of classic Dynacache with tools like the cache monitor and the Dynacache runtime mbean work when Dynacache runs on top of eXtreme Scale.
The intricate and gory details on HOW TO conifgure Dynacache with eXtreme Scale will follow in subsequent posts ...
Archives
December 2006 September 2008 January 2009 February 2009 March 2009 September 2009 October 2009 November 2009 December 2009 January 2010 February 2010 March 2010 April 2010 October 2010 January 2011 February 2011 April 2011 May 2011 June 2011 July 2011 August 2011 September 2011 October 2011 November 2011 December 2011 January 2012 February 2012 March 2012 April 2012 May 2012 June 2012 July 2012 August 2012 September 2012 October 2012 November 2012 January 2013 May 2013 June 2013 July 2013 September 2013 October 2013 June 2014 August 2014
Subscribe to Posts [Atom]