IBM Bluemix Session Cache Service Migration Guide. V1.1 April 24, 2017

Transcription

1 IBM Bluemix Session Cache Service Migration Guide V1.1 April 24, 2017

2 Introduction IBM Bluemix Session Cache Service is planned to be deprecated in This document is to provide guidance for users on how to migrate their existing Session Cache Services to IBM WebSphere extreme Scale container service on Bluemix. IBM WebSphere extreme Scale container provides all features that the current Session Cache Service provides, additionally, the new container based service provides full features that IBM WebSphere extreme Scale product provides such as Simple Cache, Session Cache, Dyna Cache, REST Support and Server side plugins, usage/capacity monitoring, agents etc. User can manage their caching infrastructure; enable multiple tenants for leveraging the different caches. Monitor and dynamically update the caching capacity and manage security, integrate with other services via REST APIs etc. To learn more on ibm-websphere-extreme-scale image for Bluemix and IBM Websphere extreme Scale product, visit the following product links: emescale.doc/kc_welcome-xs.html Migration Plan Before you replace your existing Session Cache service with ibm-websphere-extremescale image on Bluemix, you need to ensure that IBM Bluemix container services are available on your Bluemix environment. You can find IBM Bluemix Containers by logging on to Bluemix console (e.g. ), and then click Catalog à Apps à Containers. You will see ibm-websphere-extreme-scale image displayed from the container image list. If your environment is under the dedicated or local Bluemix, you would need to order IBM Container services for your environment, since they are not under the base package of your dedicated/local Bluemix. To order IBM Container services for you dedicated/local Bluemix environment, contact your IBM representative.

3 ibm-websphere-extreme-scale container license information can be found from the following link: To plan for your deployment on your ibm-websphere-extreme-scale container services, you can use your current Session Cache or Data Cache service capacities as a reference, In a typical Data Cache and Session Cache services deployment on a dedicated or local Bluemix, a 50 GB of caching capacity + 1 replica are defined. With the Session Cache service migrated into a container based ibm-websphere-extremescale service, we recommend you set up one collective of ibm-websphere-extremescale servers with 2 members (containers) running. Each container has 64 GB RAM to be used for caching. Here is the topology may look like: WXS Cache Domain: (1 replica of cached entries): wxs1 container member #1 (64 GB RAM) wxs2 container member #2 (64 GB RAM) Note: 2 members of containers provide cache replication and failover capabilities. Additional members can be added to the domain when more cache capacity is needed by applications. Migration Preparation Before staring your migration, review the following ibm-websphere-extreme-scale container service Youtube videos and WXS client examples on GitHub. The following Youtube link shows you how to start up ibm-websphere-extreme-scale containers on Bluemix, and how to push/bind/stage your Bluemix applications to integrate with the WXS container service. More Bluemix application examples and instructions (e.g. Session, Simple and Dyna cache) can be found in the following Github link:

4 Migration Review the following checklist and ensure they are done before starting the migration: - Review Youtube videos (under the Migration Preparation section) - Verify container service is available on your Bluemix environment (see Migration Plan section) - Order your container service for your Bluemix environment if it is not yet available and ensure the container service feature is enabled on your Bluemix environment. - Verify you have IBM WebSphere extreme Scale license in order to use ibmwebsphere-extreme-scale image. Here is a quick guide on how to start up your migration. Note: since you will be moving to a new caching infrastructure from the current Session Cache service, you will lose your current cached entries and your Bluemix application would need to reload cached data after migrating to the new container based service 1. Follow Getting started guide to start two ibm-websphere-extreme-scale containers. For example: wxs1 and wxs2 2. Follow Using the extreme Scale dashboard youtube video to learn how to join wxs2 container into wxs1 container to create a caching domain, this is to build a 2-member domain to serve for cache for your Bluemix applications Create your Session grid from extreme Scale dashboard. See details from the following YouTube video: 4. Unbind the current session cache service from your Bluemix application 5. Since you need to pick up the latest Liberty buildpack which will support WXS caching containers as a custom service for liberty auto-configure, you need to repush your application by following the steps below: cf push SessionTestApp2 -p mysessionapp.war 6. Create a custom provider service for ibm-websphere-extreme-scale containers that you had just started

5 cf cups XSSession-ICS1 -p cups.json where XSSession-ICS1 is the name of the custom service you want to call for WXS container. Note: for session cache, it prefix with XSSession- as the name, for simple cache, it prefix with XSSimple- as the name, and for dyna cache, it prefix with XSDyna- as the name. cups.json file contains the WXS container information which will be used to create VCAP info for service binding in the later steps. cups.json file will look like the following: { "catalogendpoint": " :4809, :4809", "gridname": "SessionGrid", "username": "xsadmin", "password": "xsadmin4me!" } Note: catalogendpoint list floating public IPs assigned by ICS for both WXS containers (wxs1 and wxs2). The port (4809) is the XIO ports for the containers. gridname is the name of the grid that you want to migrate over from the old session cache service. username and password will be the user and password you created from step 3. This user is allowed to bind and run CRUD operations on this grid from your Bluemix applications. 7. Bind your Bluemix application to the XS custom service cf bind-service SessionTestApp2 XSSession-ICS1 8. Set Bluemix environment variables for both WXS containers on your application, this is to allow client application mapping your WXS container names with the floating public IPs assigned: cf set-env SessionTestApp2 HOSTSALIAS_wxs

6 cf set-env SessionTestApp2 HOSTSALIAS_wxs Restage your applications cf restage SessionTestApp2 10. Verify your applications from Bluemix that works with the caching containers. Now your Bluemix application had just reconfigured to work with WXS caching containers. 11. If all work as expected, delete your old Session Cache service instance from your Bluemix environment. 12. Learn how to run rolling upgrade and container image migration from this link: