Each installment of Innovations within reach features new information and discussions on topics related to emerging technologies, from both developer and practitioner standpoints, plus behind-the-scenes looks at leading edge IBM® WebSphere® products.
Resistance is futile
The IBM WebSphere DataPower XC10 Appliance is designed to be the drop-in caching tier for your IBM WebSphere Application Server infrastructure. Unveiled at IBM’s IMPACT conference in early May 2010, the XC10 appliance is a combination of the robust DataPower hardware appliance platform and IBM's state of the art distributed caching technology. And, like the IBM WebSphere CloudBurst™ Appliance, it is also purple, so how could you not want one?
The XC10 appliance has only been generally available since the end of June, and so this article is meant to help acquaint you with its impressive overall capabilities by answering some of the most frequently asked questions about the product. The top ten things that you might want to know most about the XC10 appliance are:
1. What is an XC10 appliance?
The WebSphere DataPower XC10 Appliance is an elastic caching solution in a box. Each XC10 appliance has 160GB of hardened memory. By design, it is easy to install, configure, and manage.
The XC10 appliance provides a quick and easy way to integrate a caching tier into your enterprise infrastructure. The data caching tier is inserted behind the application server tier. The purpose of the data caching tier is to provide scalable, fault tolerant, coherent data grids for your application server tier. Data grids are the containers used to store cacheable application data. The XC10 appliance can store multiple data grids. A grouping of XC10 appliances is called a collective. When a collective contains more than one XC10 appliance, one or more replicas of the data grids are created and distributed across a collective. Any change to a data grid is persisted across all of the replicas of that data grid. As XC10 appliances are added or removed from the collective, the data grids and replicas are automatically redistributed across the collective. The monitoring, management, and placement of data grids and replicas is key to the reliability and scalability of an elastic data grid.
2. What can the XC10 appliance do for me?
It’s all about the cache. WebSphere Application Server (along with other WebSphere products) supports both dynamic cache based optimizations and HTTP session persistence for performance enhancement, scalability, and high availability. In particular, the XC10 appliance further enhances these particular optimizations by offloading the application server cache memory requirements and disk usage for dynamic cache and HTTP session persistence. In addition, applications using the IBM WebSphere eXtreme Scale ObjectMap APIs can utilize the XC10 appliance data cache to store serializable objects.
The XC10 supports three types of data grids:
- Simple data grids store simple key-value pairs.
- Session data grids store HTTP session management data.
- Dynamic cache grids store cacheable objects from applications that utilize the WebSphere dynamic cache APIs or container-based caching.
3. Why would I want or need an XC10 appliance?
The short answer is because the XC10 appliance saves you money.
In a traditional application server environment, cache memory is contained within each application server instance. The cache occupies the same addressable memory space as the applications. Therefore, there is a limit to cache size. If the cache occupies too much memory, it can actually degrade the performance of the application. Because cache is contained within an application server instance, if you have several application server instances configured in a cluster, then each one contains a cache and these caches will eventually all contain the same copies of the cached application data. The copies of the data are determined to be fresh or stale based on communication of invalidation messages. The greater the number of server instances, the greater amount of invalidation chatter is required to keep the cached data fresh among the server instances. Additionally, high-speed disks or databases (or both) are typically required to increase the size of the cache, or for high availability.
The introduction of an elastic data grid into your enterprise infrastructure can dramatically reduce the memory footprint required for each application server instance. In a virtualized environment, this memory could be used to support additional virtualized servers, thus improving the utilization of the physical hardware. Data grids provide a single coherent cache shared by all of the application server instances in a cluster. Therefore, the data is always fresh because all of the application instances see the same single copy in the cache. This removes all of the invalidation chatter in traditional clustered application server architecture and can result in higher transactional performance. Since the primary characteristics of a data grid are scalability and high availability, high-speed disks and databases used exclusively for persistence are no longer needed in most cases. For simple grids, however, a database is still required for primary storage. Additionally, because elastic data grids scale in a linear fashion, there is virtually no limit to their size.
With a group of XC10 appliances, you can easily build very large data grids. The larger the data grid, the more cacheable data you can store, thus significantly reducing costly redundant transactions because the requested data is most likely already in the very large data grid.
In summary, elastic data grids improve hardware utilization, reduce costly redundant transactions, and eliminate the need for a high speed disk and database used for persistence. Altogether, these improvements can result in significant cost savings.
4. Do I need to install code to use the XC10 appliance?
Yes, you will need to download the (free) WebSphere eXtreme Scale client from the IBM Support Portal. You can either install the client standalone or it can be embedded for integration with WebSphere Application Server. The standalone installation supports only simple data grids. The embedded installation is required for HTTP session data grid and dynamic cache data grid support. (The embedded installation also supports simple grids.)
If you choose the embedded installation, you must augment your existing WebSphere Application Server profiles once the installation has successfully completed. Following profile augmentation, you will then be able to choose the XC10 appliance as an option for HTTP session data grid configuration or dynamic cache data grid configuration in the WebSphere Application Server administrative console.
5. Do I need to write any code to use the XC10 appliance?
You do not need to write any additional code for HTTP session caching or for dynamic cache support using the XC10 appliance.
For HTTP session caching, you simply configure your application to use the XC10 appliance using the WebSphere Application Server administration console.
For dynamic cache support, if your application already leverages the dynamic cache using the dynamic cache APIs, or you use container-level dynamic cache support in WebSphere Application Server, no additional code is required. In order to configure WebSphere Application Server to use the XC10 appliance as the dynamic cache provider, you must first specify a catalog service running on the appliance by creating a catalog service domain in your WebSphere Application Server. Then, to create the data grid on your appliance, you either run the provided dynaCfgToAppliance script or manually create the data grid using the XC10 appliance browser-based user interface. You will need to define the XC10 appliance as the dynamic cache provider using the WebSphere Application Server administrative console, configure the replication settings, and finally add a topology custom property for the cache instance you want to modify.
For simple data grids, whether using the standalone client or embedded WebSphere Application Server client, you must add code to your application that uses the WebSphere eXtreme Scale ObjectMap APIs to perform simple create, retrieve, update, and delete (CRUD) operations on the simple data grid.
6. What if I need a bigger cache?
After you have realized the benefits of adding a data grid to your infrastructure by deploying a WebSphere DataPower XC10 Appliance, you will probably want to add another appliance for scalability and high availability. The beauty of an elastic data grid is that it scales in a linear fashion. Therefore, by adding another appliance, you grow your data grid capacity by another 160GB. Whenever you need more capacity, simply add another appliance. If you need more servers to support a higher access load, you grow your grid over multiple appliances.
To deploy an additional XC10 appliance, you must add it to a collective. The process of adding another appliance into a collective -- appropriately termed "assimilation" -- will wipe out any existing data grids on the assimilated appliance. To complete the assimilation, the members of the collective will evenly redistribute the data grids and create replicas across the updated collective. In a collective, any update or change to a data grid is persisted across all other appliances in the collective containing replicas for that data grid. (If you are familiar with the "Star Trek" television series, then the terms collective and assimilation might also be familiar to you. Whether it's a coincidence or not that these same terms are used to describe XC10 appliance concepts, the analogies between the two are valid.)
7. How does an XC10 appliance fit into a highly available architecture?
High availability is fundamental to the architecture and design of data grid technology. Of course, from a hardware perspective, you must have more than one XC10 appliance to avoid having a single point of failure. By creating a collective of more than one XC10 appliance, data grid replication is automatically enabled.
Data grid replication is the critical component to the self-healing nature of elastic data grids. For each primary data grid, a replica data grid is created on an appliance that does not contain the primary data grid. If there is a failure on the appliance that contains the primary data grid, the replica data grid is promoted to primary data grid. A new replica is automatically created on another available appliance in the collective. In a failover situation, primary and replica data grids are automatically redistributed across the remaining appliances in the collective.
The critical component of the collective responsible for high availability failover is the catalog server. The catalog server keeps track of the location of all of the primary and replica grids in the collective. A catalog server runs on each appliance in the collective with a limit of three catalog servers per collective. The catalog service is the communication between catalog servers. The catalog servers coordinate the placement of the primary and replica grids across the collective.
For finer granularity in defining your data grid a high availability architecture, each appliance in a collective can be associated with a physical location, called a zone. Zones can represent physical rack location, room number, data center location, and so on. Therefore, it is possible to associate groups of XC10 appliances in a collective with specific locations for high availability reasons, such as power grid failover, network failover, or data center failover. For high availability best practices, a collective should span several zones.
Zones help the catalog service determine placement of data grids such that primary and replica data grids are placed in different zones. If a failure occurs in one zone, the replicas in the working zones are promoted to primaries and new replicas are created on other appliances in the collective in the other working zones. When the failed zone comes back online, the primary and replica data grids are redistributed among all of the available zones by the catalog service to maximize high availability.
8. Is the XC10 appliance secure?
The XC10 appliance is absolutely secure on several levels. It is built on the hardened, tamper-proof DataPower platform. If someone tries to open the appliance and triggers the internal intrusion detection switch, the XC10 appliance cannot be powered back on until it is sent back to IBM to be reset. The XC10 appliance is not a general-purpose computing platform. It provides no access to the operating system thru a command shell, nor does it provide any way to upload and execute user code or user scripts. You can only upload signed trusted firmware updates to the XC10 appliance. Finally, the XC10 appliance provides fine-grained user and user group permissions for administrative tasks and data grid security. When data grid security is enabled, only authorized users can access data in the data grid. The XC10 appliance also supports integration with a Lightweight Directory Access Protocol (LDAP) directory for user authentication.
9. How do I manage the appliance?
The XC10 appliance is managed using a browser-based user interface. From the user interface, you can:
- Manage user interface security.
- Manage users and groups.
- Configure date and time settings.
- Configure e-mail delivery of user password resets.
- Configure the appliance network settings.
- Create and manage collectives and zones.
- Manage and secure data grids.
- Update appliance firmware.
- Shut down or restart the appliance.
10. How do I know what is going on within the appliance?
In addition to performing administrative tasks, the XC10 appliance user interface provides the ability to monitor both the progress of administrative tasks and performance of your data grids. This information helps you to determine the overall capacity and performance of your XC10 appliance.
By selecting Data grid overview in the XC10 appliance administrative console, you can get a high level view of:
- Used and available capacity on the appliance or collective.
- Top five data grids by average transaction time.
- Top five data grids by average throughput in transactions per second.
- Used capacity over time.
- Average throughput over time.
- Average transaction time over time.
You can also select an overview of individual data grids, which provides similar information to the data grid overview but for a specific data grid. For further details about a specific data grid, you can select Data grid detail reports with which you can get both data grid and map details.
The WebSphere DataPower XC10 Appliance is a quick, easy, and cost-effective way to add an elastic data caching tier to enhance your application infrastructure. Additionally, the XC10 appliance easily integrates with your WebSphere products. It can offload the memory and high-speed disk requirements for dynamic cache support, eliminate the need for database storage for HTTP session state persistence, and reduce redundant transactions. These optimizations can result in higher transactional performance, better hardware utilization, and lower memory footprint, altogether adding up to potentially significant cost savings.
- IBM WebSphere DataPower XC10 Appliance product information
- IBM WebSphere DataPower XC10 Appliance Information Center
- Video: IBM WebSphere DataPower XC10 Appliance Session Management
- Video: IBM WebSphere DataPower XC10 Appliance Monitoring
- IBM developerWorks WebSphere
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.