WebSphere Extreme Scale (WXS Components) – Operational readiness Considerations.

By Nitin Gaur Introduction: IBM WebSphere eXtreme Scale is specifically designed to help applications lower the load they place on back-end servers, increase availability and scalability, and provide the facilities for extreme transaction processing. A software layer between an application and its back-end resources, WebSphere eXtreme Scale accelerates applications by caching objects obtained from the back-end, providing a customizable, pluggable data fabric framework that allows applications to share data across a wide range of application scenarios. This paper attempts to serve as an operational readiness checklist and is designed for customers and IBM software services community, who are interested in implementing a highly available and scalable e-business infrastructure using the IBM WebSphere eXtreme Scale. Through WebSphere eXtreme Scale, customers can postpone or virtually eliminate costs associated with upgrading more expensive, heavily loaded back-end database and transactional systems, while meeting the high availability and scalability requirements for today’s environments. While not an exhaustive list, this paper includes primarily the infrastructure planning requirements of WXS environment.

Understanding WXS Components: From a broad environment perspective WXS has Three management entities: 1. Grid Servers: These are JVM that will contain grid container. Much like a typical description of a container in a J2EE™ context, grid containers essentially provide the grid application services such as security, transaction support, JNDI lookup service, remote connectivity, and so forth. The grid containers house shard distribution and placement, and enable easy manageability of the grid infrastructure. Much like other containers (Web and EJB™ container, for example), a grid container can also take advantage of the configuration service provided by the WebSphere Application Server infrastructure in a managed environment. 2. Grid Clients: Clients connect to a grid and are attached to the whole grid. Clients need to examine the key of application data to determine to which partition to route the request. Any entity that is attached to the grid with any kind of request becomes a client. The client directly accesses the partition that holds the data. The location information regarding the partition is provided by the catalog servers. 3. Catalog Servers: The catalog server is the engine that drives the grid operations. The catalog server maintains the healthy operation of grid servers and containers. The catalog server becomes the central nervous system of the grid operation by providing the following essential operation services: a. Location service to all the clients b. Health management of the grid itself c. Shard distribution and re-distribution d. Policy and rule enforcement e. High availability and group service

A JVM contains a runtime and a number of containers. Each partition has a primary shard and N replica shards. A grid container that resides in a JVM can host many ObjectGrid instances. Each map in the mapSet is defined by a BackingMap. 6. 2. One partition can host many BackingMaps.The client will begin its access to the grid by obtaining a routing table from the catalog servers. called a mapSet. This means that multiple ObjectGrids can be started on a single JVM. The JVM can be either an application server or a stand-alone JVM and can host many grid containers. A grid container can only host shards from one ObjectGrid. the client is provided with an up-to-date routing table by one of the grid servers. 5. or re-distribution of partitions due to a change in grid membership. A MapSet is a collection of maps that are typically used together. An ObjectGrid consists of a number of maps. This mechanism is maintained by an epoch time and version maintained with the routing table held by the client. . 1. or many ObjectGrid instances spread across many grid containers. 3. A mapSet is partitioned using a key. Many MapSets can exist in one ObjectGrid instance. usually one. An ObjectGrid consists of a number of partitions. 7. Each grid started has its own container within the JVM. 4. Those grid containers will host shards from the grid as determined by the catalog server. An ObjectGrid can host a set of grid containers. In the event of a JVM failure. Understanding the WXS component relationship: The above Data Model describes the relationship between the components in an eXtreme Scale environment. which enables the client to locate the primary partition shard and object.

The stand-alone deployment option differs from the WebSphere Network Deployment-managed option in that it lacks Java Enterprise Edition support and does not benefit from the management and monitoring environment that WebSphere Network Deployment provides. security and monitoring. Grid Server on WebSphere managed node: WebSphere eXtreme Scale fits perfectly into an environment managed by WebSphere Application Server Network Deployment. b. This will enable a core group of standalone catalog servers. Grid Server Hosting. provide a simple footprint and runtime for hosting grid containers and catalog servers. due to HA managers services and quorum requirements. b. Catalog servers hosting a. When WebSphere Application Server as runtime and grid container. since it is collocated with in the same server process. b. allowing all the services. a. One of these deployment options is installing WebSphere eXtreme Scale into a stand-alone Java2 Standard Edition environment (J2SE). may have licensing cost considerations. In this specific scenario. and the cache to be replicated across data centers. ObjectGrid will automatically detect the presence of these files when the application starts and will then automatically launch the ObjectGrid containers in the same process as the session manager. This is when the ObjectGrid servers are collocated in the same processes where the servlets run. Hosting Catalog servers on WebSphere managed node. presents similar benefits. It does. Catalog Server on WebSphere managed node: As mentioned before.xml and objectGridDeployment.WXS Infrastructure Planning Considerations: 1. simply place the supplied objectGrid. it may be imperative to host catalog servers on standalone JVMs. In a Zoned configuration. usually one catalog server per zone ( or data center) is a good start. Catalog Server on standalone Supported JVM : In some cases. such as transaction management. Grid Server on standalone Supported JVM: WebSphere eXtreme Scale has several flexible deployment options. The decision to host Grid Servers in a managed environment. Co-locating Grid client and server (Application and Grid container in same JVM): a. 3. While it may be economical to 2. Multi data Center Catalog Server support : Multi data center would imply a WXS zoned configuration. You can modify the objectGridDeployment. however.xml depending on which type of replication (synchronous or asynchronous) and how many replicas you want . the catalog servers.xml files into the META-INF directories of your WAR files. The catalog server is the engine that drives the grid operations. to be used by grid components. would be required to be hosted in stand alone JVMs. while providing features like ease of use and administration. while the grid servers may be hosted in WebSphere managed application servers. An example may include when using WXS enabled grid to cache HTTP session. across geographically disperse data centers. to that of hosting grid servers on WebSphere managed node. c. The WXS session manager can communicate directly to the local ObjectGrid instance.

application and grid in separate JVMs): a.xml files supplied in the session manager samples directory.xml defines the mechanics of grid deployment. This step assumes that your have augmented the application server profile/instance with WXS. 5. Unlike the topology discussed above the server process hosting the application is different from the server process hosting the JVMs. to the Object grid servers. This is due to concept of a catalog service quorum. c.e. i. Calculate the number of JVMs required from the partitioning configuration. Always more than one for high availability b. For example. which resides on the application server process.configured. c. which are the hosts to grid containers. standalone J2SE processes. if you have two partitions and each partition has one primary and one replica shard. A catalog service quorum is the minimum number of active catalog server members required for the grid system to operate correctly (that is. then you would need at least four JVMs as a starting point for a highly available grid. objectGridStandalone.xml and objectGridDeploymentStandAlone. the WXS session manager must be configured to communicate with the catalog servers and grid servers. Recommended prime number greater than 2.e. a good rule of thumb is to start with the number of partitions needed multiplied by the number of replica shards per partition. b. you should end up with 10 shards per partition. Isolating the application from the grid (i. b. ObjectGrid. 6. then it is advisable to launch the ObjectGrid containers using the objectGridStandAlone. The core functionality of the file remains. communicates to a remote ObjectGrid server processes. and objectGridDeploymentStandalone. It is important to plan the number of partitions you will need for both current capacity and future growth. This differentiation is to indicate that the HTTP session store is standalone and isolated. Once you have deployed your applications you cannot simply add partitions or scale using more JVMs. to accept membership registrations and changes to membership to ensure proper routing and shard placement). To use a remote. When deciding on the number of JVMs required for a grid. A good guideline to follow is that at the end of your planning horizon. This is beneficial for the application with either voluminous HTTP session traffic or relatively larger http session objects. Grid server sizing a. deadlock situations) can bring the grid container down. the grid container becomes more vulnerable. In effect the WXS session manager becomes the client. If the ObjectGrid servers are to be started in independent.xml. The session manager will then use an ObjectGrid client connection to communicate to the catalog server and the ObjectGrid servers. When the grid container is collocated with the enterprise application in the same application server. memory leaks. In this case the WXS session manager. This approach of ensuring the registration and . Issues in the application (for example.xml defines the grid for sessions. like objectGrid. wherever they reside. Catalog server sizing a. 4.

TCP/IP or both as the inbound transport that a server supports. The decision on the number of catalog servers depends on overall grid size.0. c. transportType property must be set to "SSL-Supported" in both the client and server security property files. In dynamic deployment topology.0. decide which set of SSL configuration settings you want to use for the inbound configuration. then any server communicating with this one must use SSL. Either case SSL is supported. If you specify SSLsupported. Transport Layer Security (TLS) or Secure Sockets Layer (SSL) is supported. the ORB protocol is used for client/server communications. Writes to the catalog service state are committed only when the majority of the catalog servers participate in the transaction. although with a different type of support. Supported Transport layer security: SSL Supported and SSL required are two supported transport Type. but this is not yet secured.5. then the server opens an SSL listener port only and all inbound requests are received using SSL. the communications on this protocol is kept local and only contains membership information. and TLSv1 are all considered SSL protocols. b. So. If you specify SSL-required. then the server opens both a TCP/IP and an SSL listener port and most inbound requests are received using SSL SSL Required : If you select SSL-required.5 is applied.1. Understanding which end points to secure : It is vital to understand different transports that ObjectGrid uses in different instances.1. d. WXS uses the ORB for client-server. However. Further the intra-zone (data center) grid servers use group services (HA manager construct) for server state information. SSLv2.5 use SSL-Supported or can use SSL-Required if 6.0. transportType support was added in 6. SSL required. .For Transport. this server can support either TCP/IP or SSL connections. and zones configuration. If set to "SSL-Required". but only server state data ( which included things like server. usually one catalog server per zone is a good start.1. If you specify TCP/IP. SSL Supported: If you select SSL-supported. server-catalog communications. Secure Transport (SSL) a. In a Zoned configuration. hostname and port information). One can choose to use Secure Sockets Layer (SSL). desired high availability.5. client-catalog. In addition to the ORB WXS the HAM/DCS/RMM stack for membership only by the containers. the container server will fail to initialize with an error message: "initial and forwarded IOR inaccessible". This is secure and was added support for SSL-Required in 6. Please note that prior to 6.0. server-server.1. 7.consistency of grid servers is achieved only when a quorum is established between catalog servers. This decision determines which key file and trust file are used for inbound connections to this server. as there is no application data shared. ORB transport security. the server only supports TCP/IP and cannot accept SSL connections. SSLv3. This should not be alarming to enterprise. If you specify SSL-supported or SSL-required.

c. JMXServicePort – if using JMX ports.props file. Various use of configurable grid features such as Memory threshold. These communication flow ensures grid data replication. client-catalog. Peer port: port used for peer catalog cluster communication iii. locking mechanism . The WXS ‘Grid’ tests would include testing the following: 1. To ensure communication flow between client-server. TCP and Firewall considerations : Please not that all the relevant ports would need to be considered while designing a WXS topology.props file.ogclient. WXS grid container failover and HA mechanism. Note: you can set the transportType property in the following client and server security configuration files: Client ( application . system and system integration testing. zone replication. Testing of the WXS Grid infrastcruture. 5. in relation to TCP transport and enterprise firewall while planning a WXS topology: i. iv.in Managed WAS env) : The transportType property in the security. 4. Listener port : Client’s need to know Catalog service JVMs listener end points. Testing the Infrastructure Testing Methodology : One of the primary purpose of testing is to uncover software defects and failures and subsequently correct them. server-server. prior to proceeding to integrations or system level testing. This approach will ensure that each component or module is verified prior to their interaction in a system as a whole. client to grid access. . and system integration tests verifies the integrated system is well aligned with core objectives of system requirements. batched update etc. Application accessing the Grid 2.props file or containerServer.ogserver. Any broad goals of testing include unit testing. The following ports would need to considered. Client port : port used for client catalog cluster communication ii. It is vital to understand that testing at each level to be completed. including the catalog servers and shard placement. The implication of such an approach assumes that ONLY the WXS features are tested independently while the application itself has been tested for component features. it is vital to isolate the application test from the WXS ‘Grid’ tests. • • • 8. servercatalog is vital to a smooth grid function. Integration and system integration testing would however include tests cases that include verification of interaction between the integrated components. depending on which file you use. integration testing. registering membership changes and subsequent re-routing of client due to membership changes. Container or Grid server or cache server: The transportType property in the containerServer. Catalog Server: The transportType property in the security. From extreme scale testing. WXS grid’s replication mechanism 3.props file. Each testing process has a specific goal and objectives.

0.3 provides a sample application called ‘xsadmin’. Besides the JMX based monitoring.1. These tools are only made available to facilitate WXS specific grid level monitoring and management. Loader update response time. Transaction response time g. and that is the GRID monitoring. in a standalone environment. beginning with WXS 6. Actual cache size e. Grid Monitoring – Includes monitoring around cache statistics. . WXS introduces another level of monitoring. resource usage and bottlenecks. the WebSphere Application Server provides a sophisticated performance monitoring infrastructure (PMI). When WXS is hosted in WebSphere managed environments. It is assumed that the infrastructure monitoring tools ( example IBM’s ITCAM and CA’s Wily Introscope) will still be employed to monitor the underlying application environment. However. It can be used to gather performance statistics of all components inside an application server. WXS. Infrastructure monitoring – Include Monitoring of the overall infrastructure health. grid replication and information on shard placements. i. The ObjectGrid APIs and MBeans are designed to allow for easy integration with third-party monitoring applications. JVM health and availability and so on. shard placement and map sizes in the WXS enabled grid. Cache hit rate f. Monitoring: Monitoring while important is a complex discussion topic. This nifty application will provide with ‘point-intime’ information on topology.e a. including the resource usage. Metrics provided include the following: d. cache entries and cache policy information. b. and many decision points around monitoring focus on “what to monitor?” Conceivably one can monitor many aspects of an enterprise application infrastructure.9. JConsole or MC4J are some examples of lightweight JMX consoles that can be used to quickly digest information about an ObjectGrid topology. Application Monitoring – Includes application performance. WebSphere eXtreme Scale takes advantage of this infrastructure to collect performance statistics relevant to the grid. which is completely optional. c.

redbooks. http://www.pdf 2.com/developerworks/wikis/display/objectgrid/Getting+started 3.com/redpieces/pdfs/sg247683. WebSphere Extreme Scale – Wiki – Users Guide. RedBook .http://www.Acknowledgement Robert Ringo – WebSphere WW Technical Sales Douglas Berg – WebSphere Extreme Scale Development Joshua Dettinger .devwebsphere.Users Guide to WebSphere Extreme Scale www.ibm. Billy Newports Blog .WebSphere Extreme Scale Development References: 1.com/ .ibm.

Sign up to vote on this title
UsefulNot useful