Transcription

RedpaperNidhi NijhawanElastic Dynamic Caching with theIBM WebSphere DataPower XC10ApplianceThis IBM Redpaper publication provides an overview of the IBMWebSphere DataPower XC10 Appliance. It describes the problem for whichthe appliance provides a solution and the architecture and the placement of theXC10 in typical topologies. This paper also provides a comparison of the XC10and IBM WebSphere eXtreme Scale, which is a software-based offering fromIBM for caching needs.This chapter includes the following topics: Overview of the XC10Caching scenariosComparing the XC10 with WebSphere eXtreme ScaleIBM DataPower XC10 V2 additions Copyright IBM Corp. 2012. All rights reserved.ibm.com/redbooks1

Overview of the XC10Three-tier application topologies that consist of web server, application server,and database tiers are common today. As the load on an application grows,scaling to accommodate this increase is necessary. This scaling is traditionallyperformed at the web and application server tiers by increasing the number andsize of the servers, with load balancing mechanisms to manage the traffic to theservers. The proliferation of servers at the database tier is more complex due toconcerns for data integrity. Although you can scale the database server upthrough the use of additional hardware resources, eventually you will reach thephysical and cost limitations and the database becomes a bottleneck fortransaction processing.The XC10 is a powerful distributed cache that accelerates application access todata and services. The XC10 provides a solution for addressing the scalingneeds of applications and databases with elastic data grids that allow you toscale out transaction volumes quickly and easily, with minimally invasive changesto the application and architecture, as shown in Figure 1. This approach alsodrastically reduces reads and writes on the database, cutting back on time andresource-intensive calls that can create bottlenecks.Web Server TierApplication Server TierElastic Data GridDatabase TierIBM HTTP ServerWebSphereApplication ServerXC10 CachingApplianceDB2 UDBFigure 1 Positioning the XC10A data grid stores data in a grid style, as illustrated in Figure 2 on page 3, using alarge amount of loosely coupled cooperative caches to store data. The XC10 canhold one or more data grids. Each grid is associated with a specific application orset of applications.2Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

CollectiveIBM WebSphere DataPowerXC10Data Grid Cache that holds acollection of data fromone or more clients Physical hardware devicecapable of running one or moredata grids Set of IBM WebSphereDataPower XC10Appliances groupedtogether for scalability andmanagement purposesFigure 2 Data grids in the XC10The XC10 (shown in Figure 3 on page 4) is designed for simplified deploymentand hardened security at the caching tier of an enterprise applicationinfrastructure. It contains 240 GB of storage for grid capacity. If this capacity isnot enough, you can expand the grid by adding one or more appliances to theconfiguration, which creates a collective of appliances that host data. Thiscapability of grouping appliances allows you to increase cache capacity and datathroughput quickly and easily as your needs grow.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance3

Figure 3 XC10 applianceThe XC10 allows business applications to process billions of transactions per daywith efficiency and near-linear scalability. It allows you to take advantage of thevalue of existing infrastructure investments and to bring higher performance, faulttolerance, and scalability to common, distributed caching scenarios.With the XC10, you can experience the following benefits: Rapid drop-in use without code changesThe XC10 can be used in a broad range of Java and non-Java applicationenvironments where it can deliver a cost-effective, distributed caching solutionin support of data-oriented distributed caching. Accelerated time to valueInstallation, setup, and configuration time is quick, with ready to use commondata-oriented caching scenarios. Simplified management and administrationThe XC10 provides a simplified administrative and monitoring console toenable efficient configuration and management. Figure 4 on page 5 showsthe simple web GUI of the XC10.4Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

Figure 4 The XC10 web GUI Linear scalabilityScale out without limitations. The XC10 contains a 240 GB elastic data gridthat you can use to host data for business-critical applications. To add morememory to a data grid, you can add another appliance to your configuration,creating a collective of appliances that host data. Fault toleranceThe data in data grids is replicated automatically, which lowers the risk of dataloss.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance5

Caching scenariosThe scenarios that are described in this section illustrate common cases forusing the XC10. These scenarios show both how the scenario is implementedwith DataPower caching technology and the reason that the XC10 is thepreferred choice in each case.This section examines the following use cases for using the XC10 as a cachingsolution: Using the XC10 as a side cache Using the XC10 for HTTP session management Using the XC10 for elastic dynamic cachingUsing the XC10 as a side cacheIt is common for applications to make redundant calls, doing something over andover again on expensive back-end systems, often to access data that does notchange much (for example, user profiles). Applications that fit this description canbenefit from using a simple data grid in the XC10 as a side cache. In thisscenario, the application checks the cache every time that data is needed. If thevalue is not found (cache miss), the data is retrieved from the back-end databaseand inserted into the cache. The next time that the data is needed, it is retrievedfrom the cache.Simple data grids can be used with WebSphere Application Server or with astand-alone Java application. In both cases, the WebSphere eXtreme Scaleclient is installed on the Java virtual machine (JVM) to enable access to theXC10.The application uses the ObjectMap API to store key-value pairs of data inmemory, reducing expensive database queries. The keys can be any existingJava type, such as java.lang.String or Integer. The values can be anyserialized object type. Every time that data is needed, the simple data grid on theappliance is checked first. If the appliance does not have the data, the data isretrieved from the database and inserted into the simple data grid.As an example of this type of scenario, consider a shopping website wherepotential customers can view information about furniture items that are available.The information about each furniture item is stored in a database and is updatedon a regular basis with price changes, new pictures, and offers. These updatesare infrequent, but users viewing the site need to know about the status of thefurniture item availability.6Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

Accessing the database with every request has proven to be expensive in termsof response time. When the volume of requests is high, the database becomes abottleneck, reducing performance significantly. Use of the site and purchasesdropped as these problems grew. The application was modified to use the XC10as a simple cache. When a user requests information about a furniture item, thedata is retrieved from the database and is cached for future retrievals. Cachingthe data significantly improved performance and provided the opportunity forfuture growth.Figure 5 shows the web GUI that is used to configure a simple data grid in theXC10 appliance.Figure 5 Configuring a simple data grid in the XC10XC10 REST Gateway featureThe Representational State Transfer (REST) Gateway feature of XC10 enablesnon-Java clients to access simple data grids. It is supported on the XC10firmware V1.0.0.4 or later. This feature allows integration with the followingcomponents: IBM WebSphere DataPower XI50 appliances Microsoft .NET applications Clients that cannot host the IBM Object Request Broker (ORB)XC10 as a side cache for XI50Using the XC10 REST Gateway feature, you can integrate the elastic caching tierwith the IBM WebSphere DataPower Integration Appliance XI50. The DataPowerXI50 is a hardware appliance that provides enterprise service bus (ESB)features. Traditionally, the elastic caching tier is inserted between the applicationserver tier and the database tier. However, in a configuration that includes anXI50, the elastic caching tier acts as a side cache for the ESB.A simple data grid that is hosted on the XC10 functions as an service-orientedarchitecture (SOA) results cache for the ESB. In an SOA, all application requestspass through the ESB before they are routed to the application. Therefore, if theresult of an application request is retrieved from the elastic caching tier, theElastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance7

application processing and processing latency for that request are eliminated.The result is a significant decrease in the response time and a reduction in theapplication processing.As incoming client application requests are received, the XML proxy configuredon the XI50 inspects the URI, the XML body contents, or both to determinewhether the request meets the criteria for being cached, based on the cachingpolicy rules that are defined in the XI50. If the request is cacheable, the XMLproxy performs a standard side-cache operation. Using the REST-based HTTPGET method, the XML proxy determines whether the request is cached in thesimple data grid.If the HTTP GET returns an HTTP 404 NOT FOUND error, which means a cachemiss, the XML proxy allows the request to pass through the existing processingflow to the application that is hosted in the back-end systems. The XML proxythen caches the response as it flows back through the XML proxy to the clientapplication. The XML proxy uses the REST-based HTTP POST method to insertthe response into the side cache. If the incoming request is found in the cache,the result is retrieved from the cache, bypassing the back-end systems andremoving the latency that was introduced by the application and data layers.Figure 6 illustrates the use of the XC10 as a side cache for the XI50.XMLClien tApp lic ationsXMLProxyE xis tin gProces si ng Fl owREST G atewayG ri dG ri dXC10 Cac hing App lianceFigure 6 The XC10 as a side cache for the XI508Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 ApplianceBac k-endSys tems

Using the XC10 for HTTP session managementThe HTTP session state management features that are provided by JavaPlatform, Enterprise Edition (Java EE) application servers are used by manyapplications. Session state management allows the application to maintain userinformation and the state of the user session for the period of a user’s interactionwith the application. When an application serving environment supports highavailability and failover, session state information must be available to allapplication servers. Typically, the application servers achieve high availability andfailover of session data by storing the state information in a shared database or inthe application server’s memory.When session data is stored in a shared database, scalability is limited by thedatabase server. The disk I/O operations are an expensive performance cost tothe application. When the transaction rate exceeds the capacity of the databaseserver, the database server must be scaled up.When session data is kept in memory, the session data is replicated betweenapplication servers to keep the data in sync. In this case, the limits to scalabilityvary depending on the replication scheme. Commonly, a simple scheme is usedin which each application server holds a copy of all user session data. In thisscheme, the total amount of state information cannot exceed the availablememory of any single application server. Memory-to-memory replicationschemes often trade consistency for performance, which means that in cases ofapplication server failure or user sessions being routed to multiple applicationservers, the user experience might be inconsistent and confusing.Installing the WebSphere eXtreme Scale Client in a WebSphere ApplicationServer configuration provides an extension beyond the database and in-memoryHTTP session management caching mechanisms to support XC10 sessionmanagement caching. With the XC10, session data is kept in the grid, providinghigh-speed access to the data from all application servers. If one server goesdown, the session can be continued on another server with the session data keptintact.The XC10 provides a quick and non-invasive option for handling HTTP sessionmanagement by minimizing the need for costly application changes. The XC10can provide a number of benefits, including higher qualities of service acrossscenarios that span application server cell boundaries and heterogeneousapplication server environments.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance9

You can create the cache using one of the following methods: Create the cache on the appliance, and then point WebSphere ApplicationServer to the cache. Create the cache on the appliance directly from the WebSphere ApplicationServer administrative console.As a practical example of this type of scenario, consider an insurance companythat provides many types of insurance, including life, health, home, auto, and soon. It has an Internet site that allows customers to get a price quote on auto orhome insurance. As potential customers use the site, they navigate through aseries of pages, enter information about the assets that they want to insure, andmake selections regarding coverage. This information is collected and stored bythe web application as session data to be used to create the price quote. At theend of the process, the user reviews the information and submits it forprocessing.In this scenario, user performance is critical, because users tend to becomefrustrated with slow movement between pages. Although the default in-memorysession management that was used by the application serving environmentworked, the replication that was required to keep the data synchronized foravailability purposes put a load on the application servers and causedperformance delays for the user. In addition, the accumulation of session datadue to the length of time that it took users to complete the application became aburden on the memory of the application servers.By moving this session data to a collective of XC10 appliances, several criticalimprovements occurred. The response times to the user became consistent andfaster. Memory is freed for executing the application rather than storing data.Synchronization of data between the application servers is no longer necessary,which reduced the load on the application servers. Reliability was also improved.The collective contained replicas of the data so that if an application server wentdown, the data was not lost with it. The remaining servers continued the sessionwithout losing the data.10Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

Figure 7 show the use of an XC10 collective for HTTP session management.WAS Clust er N odesHTT PClien tApp licationsH TTP Ses sion Da taXC10 Co llectiveBack-en dSyste msFigure 7 HTTP session management using an XC10 collectiveUsing the XC10 for elastic dynamic cachingWebSphere Application Server provides a dynamic cache service that allows thecontainer-level caching of the output of servlets, JavaServer Pages (JSP), webservices, and WebSphere Application Server commands into memory. Java EEapplications that are deployed in WebSphere Application Server also haveaccess to the dynamic cache through the Dynamic Cache API, which isinformally known as DynaCache. The dynamic cache service uses the defaultdynamic cache provider of WebSphere Application Server. The default providerstores the cached data in the JVM memory with the option of offloading cacheddata to disk in an overflow situation. The cached data is replicated among theother JVMs in the application server cluster.As an alternative, you can configure the XC10 as the dynamic cache provider forWebSphere Application Server (Figure 8 on page 12). By setting up thiscapability, you can enable applications that are written with the Dynamic CacheAPI or applications using container-level caching to use the features andperformance capabilities of the appliance, including replication over the network,high availability, scalability, and cache partitioning. The memory that was beingused for caching in application servers can now be used for other purposes. Thedata is cached and managed in the grid, rather than having the multipleredundant synchronized copies stored by the default dynamic cache provider.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance11

WAS Clus ter N odesClien tAp plic ation sElast icDynamicCac heG ri dGri dBack -en dSyst emsXC1 0 Coll ec tiveFigure 8 Elastic Dynamic Cache in XC10As a practical example of this type of scenario, consider a large airline that postsinformation about current and future flights on its website. The site is used bycustomers who are looking for available flight information, by passengerschecking to see whether flights are delayed or canceled, and by others checkingfor flight arrival information. Users can view a list of flights by date, select aspecific flight for more information, or select multiple flights for comparison.The flight information is stored in a database and is accessed by the webapplication that is deployed on WebSphere Application Server. Although theinformation about flights for the current day tends to change frequently, the datafor future flights is fairly static. The high volume of requests, however, puts asignificant load on the application servers, increasing response times andmaking the performance erratic.Presently, dynamic caching is used to store the data that is accessed frequentlybut that is changed infrequently, thus reducing the time and resources that arerequired to build the web pages. However, the data is stored in the JVM memory,reducing the amount of memory resources available to the application.By introducing a collective of XC10 appliances, the company can offload thememory and computing resources that are required to maintain the cache fromthe application servers, increasing both throughput and performance. The XC10provides a consistent, distributed cache for the airline enterprise application thatis running on WebSphere Application Server.12Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

Figure 9 shows that each record is stored once in the grid and shared by allclients.AppAppAppXC10 CollectiveFigure 9 Using an XC10 collective for dynamic cachingComparing the XC10 with WebSphere eXtreme ScaleThe IBM WebSphere caching family includes the following products: WebSphere eXtreme Scale (software) The XC10 appliance (hardware)Both products allow business applications to process billions of transactions perday with extreme efficiency and near-linear scalability. They are designed to workin heterogeneous environments across all leading application server platformsand virtualization environments.WebSphere eXtreme Scale operates as an in-memory grid that dynamicallyprocesses, partitions, replicates, and manages application data and businesslogic across hundreds of servers. It provides transactional integrity andtransparent failover to ensure high availability, high reliability, and consistentresponse times. WebSphere eXtreme Scale provides the technology to enhancebusiness applications by extending the data-caching concept with advancedfeatures.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance13

The XC10 appliance is designed for simplified deployment and hardened securityat the caching tier of the enterprise application infrastructure, adding elasticcaching functions that enable your business-critical applications to scale costeffectively with consistent performance. IBM WebSphere DataPower XC10 isdesigned for rapid, “drop-in” use in conjunction with WebSphere ApplicationServer and other WebSphere family products where it can deliver acost-effective, distributed caching solution in support of data-oriented, distributedcaching scenarios.Both WebSphere eXtreme Scale and the XC10 appliance provide distributedobject caching. However, the set of features that they offer differs. The XC10appliance stores cached data in the appliance, and WebSphere eXtreme Scalebuilds grids using JVMs. In addition, whereas the XC10 appliance is designed forthe three data-oriented caching solutions (dynamic cache, session management,and simple side cache), WebSphere eXtreme Scale supports these scenariosand offers additional flexibility for application-oriented caching and how the cacheis loaded, as illustrated in Figure 10.Data-OrientedSession managementElastic DynaCacheDataPower XC10 Appliance D rop -i n cac he sol uti ono ptimiz ed and hard enedfor dat a-orien teds cenarios H igh d ensi ty, low footp rin ti mproves dat ac entereffic ienc yW eb-side cachePetabyte analy ticsData bufferEv en t ProcessingWorldwide cacheIn-memory OL TPIn-memory SOAApplication-OrientedeXtreme Scale Ultim ate flexibi lit yac ros s a broad range ofcachi ng s cenarios In-memory cap abili tiesfo r appl ica tion-orient edscenariosElas tic c achi ng for lin ear sc alab ilit yHigh availabi lit y d ata rep lic ationSimpl ified m an agement , moni tori ng, an d admin ist rat ionFigure 10 The XC10 compared to WebSphere eXtreme Scale14Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

The following list compares the features of the XC10 and WebSphere eXtremeScale: Reporting and monitoringWebSphere eXtreme Scale includes implementations of metric accessadapters to improve integration with IBM Tivoli Monitoring or Hyperic HQ,enabling comprehensive insight into the operational behavior of businesssolutions.The XC10 includes a built-in console for ease of management and metrictracking. Simplified monitoring of the run time and health of the appliance (the XC10appliance only)The XC10 includes status widgets to report key metrics pertaining to yourtransaction load and memory. Two examples of the reported metrics arememory/disk usage and average response time. Real-time data and event mining (WebSphere eXtreme Scale only)When working with real-time data flows, the first challenge is filtering andorganizing the data so that the applications can use it. A partitionedWebSphere eXtreme Scale configuration can subscribe to events and applythem to partitioned data, thus supporting near-linear scalability anddeterministic latency for these applications. Map/reduce support (WebSphere eXtreme Scale only)WebSphere eXtreme Scale clients can invoke agents that run againstmassive amounts of data on multiple nodes in parallel. Clients can thenaggregate and further process the results that are stored in the grid by thenodes. WebSphere eXtreme Scale caches can potentially span thousands ofJVMs and support extremely large data sets.In addition, WebSphere eXtreme Scale includes efficient new algorithms toallow in-memory caches to grow elastically as the number of available JVMsor physical machines changes. Traditional distributed cache products useMap APIs as their primary programming model. WebSphere eXtreme Scaleoffers Map APIs and also allows graphs of objects to be easily pushed to thecache.WebSphere eXtreme Scale allows simple Java objects to be annotated anduses a simpler API to transparently allow these graphs to be fetched from thegrid and to push any changes made by the application back to the grid. Thisdesign significantly simplifies programming compared with the older JCacheor map-based APIs, improving the productivity of the application developersby allowing them to focus on the core business logic.Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance15

Client/grid with near cache (WebSphere eXtreme Scale only)Having the data in memory is a proven step to higher performance. Whendealing with large volumes of data, applications can perform even better. AJVM can have a local WebSphere eXtreme Scale grid, which sits in front of aremote grid serving as a “near cache” for a subset of the data, allowing aclient to use a large remote cache to offload back-end processing or toaccelerate access to cached results.The near cache is in the same JVM as the application and provides local,in-process access to data. It contains a subset of all the data in the grid and ischecked first when a record is requested. If the record is not in the nearcache, the record is retrieved from the grid and put into the near cache. Theresponse time is reduced the next time that the same record is accessed. Thefaster response times for the records that you access often lead to fasterresponse time for the user. The near cache is also updated when data writesto the grid. Applications can use the distributed locking services that areprovided by the remote grid to coordinate access to shared data acrossclients. Accelerated Time to Value (the XC10 appliance only)The XC10 reduces the time that is necessary for installation, setup, andconfiguration, with “drop-in” use for the HTTP session replication andWebSphere Application Server dynamic cache service. Simplified management and administration (the XC10 appliance only)The XC10 offers a built-in, simplified administrative and monitoring console toenable the efficient setup, configuration, and management of the applianceand transaction load within your data center. Write-through caching (WebSphere eXtreme Scale only)Write-through caching immediately propagates all changes from thein-memory cache to the back-end database as part of the transaction. Thismethod results in longer response times but guarantees all changes arepersisted to the back-end database. This approach also providessynchronization between the cache and the back-end system. This caching isvaluable in situations where the data must be hardened to the back-end datastore for the transactions to be considered complete. Write-behind caching (WebSphere eXtreme Scale only)Write-behind caching batches data updates, sending them to the back-enddata store at a configured interval. This caching improves transactionresponse times, because they no longer need to deal with the back-end datastore in a synchronous fashion. This approach reduces the load on the datastore and shields the application from back-end outages. The grid holds theupdates in memory in a fault-tolerant manner until the back end comes backonline.16Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance

Java Persistence API (JPA) loaders (WebSphere eXtreme Scale only)Loaders are needed to read and write data from the data store when usingthe WebSphere caching family product as an in-memory cache. Starting withWebSphere eXtreme Scale V6.1.0.3, there are two built-in loaders thatinteract with JPA providers to map relational data to the WebSphere eXtremeScale maps: the JPLoader and JPAEntityLoader. The JPALoader is used forcaches that store Plain Old Java Objects (POJOs), and the JPAEntityLoaderis used for caches that store WebSphere eXtreme Scale entities. Theseloaders reduce the burden on the application programmer. Multimaster replication (WebSphere eXtreme Scale V7.1 only)This feature allows you to host a grid in multiple locations that connectthrough user-defined links. Each grid is fully independent and runs its owncatalog service. The locations need to have the same grid that is defined withthe same number of partitions and map/template definitions.You can create a link between two locations and, from that point forward,WebSphere eXtreme Scale attempts to make both locations identical. If youcreate a link between a location with data and another empty location,WebSphere eXtreme Scale copies the data from the non-empty location tothe empty location automatically. These replication links are bidirectional.Changes made on either side of the link are propagated to the other side. Inaddition to the simple topology of two locations, more complex topologies canbe constructed.IBM DataPower XC10 V2 additionsThe following features are available in the IBM DataPower XC10 V2: REST Gateway Simple Network Management Protocol (SNMP) monitoring support Integration with other products:––––WebSphere CommerceWebSphere PortalWebSphere Enterprise Service BusXI50 (XC10 appliance as a side cache for XI50)Elastic Dynamic Caching with the IBM WebSphere DataPower XC10 Appliance17

REST GatewayThe 1.0.0.4. release of the WebSphere DataPower XC10 firmware introduces aREST Gateway that provides non-Java-based clients access to simple data gridsusing a set of HTTP-based operations. This new feature expands the range ofclients capable of utilizing the XC10 appliance for elastic caching to any clientwith HTTP capabilities, including PHP and .NET clients. Using the RESTGateway feature, the XC10 can be used as an SOA results side cache for theWebSphere DataPower Integration Appliance XI50. Using the XC10’s simpledata grid as a side cache for an XI50 can significantly reduce the load on theback-end systems by eliminating redundant requests to the back-end systems,improve the response time to the clients, and increase the total systemthroughput.SNMP monitoringSimple Network Management Protocol is commonly known as SNMP. SNMP is aUser Datagram Protocol (UDP)-based network protocol that is commonly used tocommunicate with hardware devices on a computer network. SNMP provides amechanism for monitoring hardware

size of the servers, with load balancing mechanisms to manage the traffic to the servers. The proliferation of servers at the database tier is more complex due to concerns for data integrity. Although you can scale the database server up . with DataPower