Global Cache – Recap and new features IBM Integration Bus … - ESB01 - IIBv9 Global... · –...

Global Cache – Recap and new features

IBM Integration Bus v9

© 2014 IBM Corporation

James Hart and Simon Stone – IBM Integration Bus dev elopment

Agenda

� Functionality introduced in WMB v8.0.0.1

� New function released in WMB v8.0.0.2

� New function released in IIB v9

� Questions?


WebSphere eXtreme Scale Overview

� Elastic “In-Memory” Data Grid

� Virtualizes free memory within a grid of JVMs into a single logical space– Accessible as partitioned, key addressable map by a pplications and

subsystems

� Provides fault tolerance through replication – e.g. Primary/secondary stores with failover, voting etc…

© 2014 IBM Corporation 5

– e.g. Primary/secondary stores with failover, voting etc…

� Easy to Scale– Add more JVMs dynamically while it’s running withou t restart

� Available as component or standalone software and h ardware appliance– Foundational technology used “under the covers” in Message Broker

WebSphere eXtreme Scale basics – container servers

� An eXtreme Scale container server contains data sto red in the grid, with the data placed into the JVM heap memory.

� A container server does not contain a copy of all d ata in the grid– Unless it's the only container server in the grid!

� It will contain a subset of data stored in the grid – a mix of primary and replica shards.

– But a container server may contain just primary sha rds, or just replica shards.

© 2014 IBM Corporation5

shards.

WebSphere eXtreme Scale basics – catalog servers

� An eXtreme Scale catalog server does not contain an y data stored in the grid.

� The catalog server is responsible for managing the container servers in the grid, and the placement of primary and replica shards across those container servers – it “balances” the data across the grid.

� The catalog server monitors the container servers. If a container server goes down, then data from that container server (us ing replica shards from another container server) is “rebalanced” across the grid.


from another container server) is “rebalanced” across the grid.

� eXtreme Scale clients connect to the catalog server s, and obtain information on the container servers in order to fi nd out where data is stored in grid.

� The catalog server is important – if you lose the ca talog server, then you lose the entire grid.

� However to provide high availability, you can have multiple catalog servers in a single grid.

WMB Global Cache in A Nutshell

� WMB contains an embedded WebSphere eXtreme Scale gr id�WXS components are hosted within execution group pr ocesses

� It works out of the box, with default settings, wit h no configuration�You just have to switch it on!


� The default scope of one cache is across one Broker �Starts with multiple execution groups but easy to e xtend to multiple brokers

� Advanced configuration available �Execution group properties and Policy Profiles for more sophisticated

topologies

� MB developer has simple artefacts for working with the global cache�Unaware of the underlying technology (WXS) or topol ogy

Use case 1 - Storing state for integrations

� With a global cache, each broker can handle replies – even when the request was processed by another broker.

request


Global cache

REQUESTOR SYSTEM PROVIDER SYSTEM

response

Use case 2 - Caching infrequently changing data

� With a global cache, the number of clients can incr ease while maintaining a predictable response time for each client.


Topologies - Introduction

� Broker-wide topology specified using a cache policy � Default provides single broker embedded cache� 1 catalog server and up to 4 container servers

� The initial value is Disabled � No cache components run in any execution groups� Switch to Default and restart in order to enable ca che function

� Broker will generate sensible defaults for port ran ge and listener host name


� Broker will generate sensible defaults for port ran ge and listener host name� Can choose a convenient port range for use by cache components in given broker� Can specify listener host name: broker cache compon ents host name for binding

The Default Cache Topology

� Shows the cache components hosted in a 6-EG broker, using the default policy


Topologies Policy File

� Use a cache policy file to define a multi-broker gr id� Sample policy files are included in the product ins tall

� Policy file tells broker how to particpate in Globa l cache� Specify the policy file as the 'policy' property va lue on all brokers that are to

participate

� Example policy file: 2 broker global cache, single catalog server


� Example policy file: 2 broker global cache, single catalog server

Topologies – policy “none”

� None Policy� Switches off the broker level policy� Configure each execution group individually

� Example screenshot shows the execution group-level properties– Useful for fixing specific cache roles with specifi c execution groups.– You may wish to have dedicated catalog server execu tion groups.– Tip – start with “Default” or policy file, then swit ch to “None” and tweak the settings.


public class jcn extends MbJavaComputeNode {public void evaluate(MbMessageAssembly assembly) th rows

WMB Programming model – Java Example

New MbGlobalMap object. With static 'getter' acting as a factory.

Can also getMap() to get the default map.

Getter handles client connectivity to the grid.


public void evaluate(MbMessageAssembly assembly) th rows MbException {

...MbGlobalMap myMap = MbGlobalMap.getGlobalMap(“myMap ");...myMap.put(varKey, myValue);myMap.put(“aKey”, myValue);...myValue = (String)myMap.get(varKey);

}}

Data is PUT on the grid

Data is read from the grid

� Full Resource statistics and Activity log� Understand the state of the Cache and Cache Interac tions

Administrative Tools


� mqsicacheadmin command � Provide advanced information about the underlying W XS grid� Validate that all specified brokers are participati ng in a multi-broker grid� Check that the data is distributed evenly in underl ying cache elements� Use with the “-c showMapSizes” option to show the s ize of embedded cache� Use with the “-c clearGrid -m <mapname>” option to c lear data from cache

Agenda




� Questions?


Data Eviction

� New signature added to MbGlobalMap.getGlobalMap to allow the “time to live” to be set for data in the embedded global cach e.

MbGlobalMap evictMap = MbGlobalMap. getGlobalMap ("evicto" , new MbGlobalMapSessionPolicy(30));evictMap.put( "key" , "val" );

� Time to live is wrapped inside the MbGlobalMapSessi onPolicy object.


� Time to live is wrapped inside the MbGlobalMapSessi onPolicy object.

� Specify a value in seconds. The default value is 0, which means data never gets automatically removed.

� Data is evicted when the “time to live” period has el apsed, after the data is last updated.

� The time to live is an override, which applies to d ata put or updated in a given map, within a given instance of the message f low. The underlying map, and data already present in that map, are unaf fected.

Connectivity to external WebSphere eXtreme Scale grids

� In addition to the embedded global cache, introduced in v8.0.0.1 , you can now also work with external WXS grids.

� This includes XC10 appliances.

� Connections are configured using the WXSServer configurable service.

� Connect to multiple external grids, and


� Connect to multiple external grids, and the embedded global cache at the same time.

Configurable service for external grids

� Specify the catalog endpoints for your external grid, and the grid name.

� Optionally, if the grid requires user ID / pwd authorization, create a security identity and refer to it in the configurable service.

� For this example, the security identity is created by: mqsisetdbparms <broker> -n wxs::xc10id -u


mqsisetdbparms <broker> -n wxs::xc10id -u <userId> -p <pwd>

� Optionally point to a client override file.

Programming model for external grids

� New signature added for MbGlobalMap.getGlobalMap(St ring mapName, String configurableService).

� The resulting MbGlobalMap object then behaves exact ly the same as if you were working with the embedded global cache. All co nnectivity and session management is handled by the broker.


MbGlobalMap xc10Map = MbGlobalMap. getGlobalMap ("Test .LUT" ,"xc10Appliance" );xc10Map.put( "key" , "value" );

� Interactions with external grids are logged in Acti vity Log and Resource Statistics in the same way as for the embedded glob al cache.

SSL for external grids

� Transport Layer Security for external grids is buil t on existing concepts within WMB. Follow the same steps for PKI setup as for SSL elsewhere in the broker.

� New options at the Execution Group level specify whether that EG should use SSL-Supported for client connections to external WXS grids.

� Optionally specify the protocol to use, and a key


� Optionally specify the protocol to use, and a key alias, if more than one trusted key exists in the keystore.

� If clientsDefaultToSSL is selected, all connections from this EG will attempt to use Transport Layer Security.

� With this box ticked, connections can only be made from EGs that do not host catalog or container servers.

Agenda




� Questions?


Java object support

� In 8.0.0.x, only Java primitive types (bytes, numbe rs) and strings could be stored in the Global Cache.

� In 9.0.0.0, the Global Cache classloading mechanism is updated to allow users to use any existing Java classes with the Glo bal Cache, as long as they implement either the Serializable or Externaliza ble interfaces.


� The Java classes must be placed in the broker or ex ecution group level shared-classes directories, and made available to a ll brokers participating in the cache.

� Message flows can now share data with external appl ications when accessing external grids or XC10 appliances using e xisting Java classes.

� The Global Cache can now be combined with the JAXB functionality (introduced in 8.0.0.2). Users can convert message data into a Java object using JAXB, and then store that Java object in the Global Cache.

Multi-instance broker support

� In 8.0.0.x, Global Cache components – either catalog or container servers -cannot be hosted within a multi-instance broker.

� In 9.0.0.0, container servers can now be hosted wit hin a multi-instance broker. Multiple listener hosts can be provided in the Global Cache configuration to allow container servers to correct ly fail over as part of broker fail over.


broker fail over.

Agenda

� Recap of function available in WMBv8.0.0.1

� New function already available in WMBv8.0.0.2

� IIB v9 content

� Questions?


Global Cache – Recap and new features IBM Integration Bus … - ESB01 - IIBv9 Global... · –...

Documents

Transcript of Global Cache – Recap and new features IBM Integration Bus … - ESB01 - IIBv9 Global... · –...