Download - Innovation Within Reach

8/14/2019 Innovation Within Reach

1/6

Innovations within reach: Stretching the limits withelastic softwareSkill Level: Intermediate

Robert Wisniewski ([email protected])Technical EvangelistIBM

03 Mar 2010

New concepts and strategies require changes in vocabulary. With a move towardlower cost, highly flexible, cloud-friendly architectures, the concept of elasticity hasbeen established for an enterprise IT solution. This article explores a specificdefinition of elasticity by describing examples present in IBM WebSphere eXtremeScale, an elastic in-memory data grid.

Each installment of Innovations within reach features new information anddiscussions on topics related to emerging technologies, from both developer and

practitioner standpoints, plus behind-the-scenes looks at leading edge IBMWebSphere products.

Putting substance behind the buzz

One thing we have plenty of in the enterprise software industry are buzzwords.Overwhelming at times, buzzwords are necessary in order to expand the vocabularywe use to describe the solutions and tools available to solve an ever-evolving set ofbusiness problems. Without this expansion, many of these concepts would struggleto leave their infancy. One concept for which we have been attempting to champion

a very specific meaning is the use of the term elastic to describe an enterprisesolution.

It's easy to fall into the trap of using the idea of elasticity to make a point about theset goal for a given solution. In its simplest form, a solution might be elastic bysimply enabling more resources to be added or removed without bringing the systemoffline. For the sake of creating a higher and more useful standard, I'd like to

Stretching the limits with elastic software Copyright IBM Corporation 2010. All rights reserved. Page 1 of 6
mailto:[email protected]://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlmailto:[email protected]


2/6

propose a more ambitious goal of a specific definition.

Elasticity in a system or component of a system (I'll use software as an example,since I work with IBM WebSphere eXtreme Scale every day) implies three specificdegrees of freedom:

Scaling with no reasonable limitation

Fault tolerance and self-healing

Administrative simplicity.

Now, before you label these as buzzwords or empty concepts, allow me to put somesubstance behind these ideas.

Scaling with no reasonable limitation

We shouldn't expect much controversy regarding the idea that an elastic system canbe scaled up and down without a significant effect on the availability of the systemduring these operations. However, I believe we should also expect that the systemitself not place any real restriction on a reasonable scale-up scenario. By this, Imean that the infrastructure itself should be architected to enable the continuedgrowth of the system and make the new resources available with little or nooverhead. This implies the possibility of true linear scaling.

We've addressed the concept of elasticity within WebSphere eXtreme Scale byconsidering the effects of extremely large grids on every aspect of the product. A fewexamples can illustrate this nicely:

First, the architecture of the grid membership infrastructure itself iscomponentized into smaller soluble and containable problems of scale.Rather than wrangling thousands of servers into a single core group, thecatalog service (an administrative process which handles the structure ofthe grid) divides the members into groups of 20. Each of these individualgroups then runs a membership view algorithm involving heart-beating,which has a proven track record and shares function with IBMWebSphere Application Server. An elected "leader" of this smaller groupkeeps the catalog service up to date on the status of the group, whichthen only needs to stay in contact with 1/20th of the total members of the

grid.

Another example is the client interactions with the grid itself. One questionthat comes up often is the possible bottleneck that a single administrativeprocess provides, such as the catalog service. Catalog services can beduplicated and clustered, as well, but that's simply for redundancy. Thetruth is that a single catalog service can actually handle the needs of anearly unlimited number of clients because those clients interact with the

developerWorks ibm.com/developerWorks

Stretching the limits with elastic softwarePage 2 of 6 Copyright IBM Corporation 2010. All rights reserved.
http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtml


3/6

catalog service only once to bootstrap into the grid. In that interaction, thecatalog service returns information about the grid, including a completerouting map defining the location of all grid partitions and the associatedkey space for each. After this, the clients interact directly with thepartitions and even keep this routing table up to date through subchannel

interactions during the normal transaction process. The catalog service isthen free to focus its attention on simply managing the balance andmembership of the grid as resources are added and removed.

With approaches like these, we've been able to effectively scale a grid to anarbitrarily large size. In the lab, we've achieved a 1,500 container grid with no realdifference in perceived performance. After that, we simply ran out of time to gofurther, but there is no specific or reasonable limitation to this scaling. This is animportant factor to truly considering a solution to be elastic.

It's important to know that this doesn't imply that EVERY deployment of an elasticinfrastructure will provide the overall application with linear scaling as resources are

added. There are still considerations regarding the logic and business beingconducted within that infrastructure, and whether or not they employ scalableextreme transaction processing fundamentals. In this regard, the enterpriseapplication itself must also have elastic characteristics. An elastic infrastructureshould, however, provide the plumbing to effectively achieve these goals.

Fault tolerance and self-healing

If you're going to expect a deployer to trust your solution to scale indefinitely, youmust also tolerate the events that occur with greater probability and frequency as asystem grows, such as the addition or loss of nodes due to maintenance or fault,

network faults and changes, and so on. With more resources comes a greaterchance for failure, and an elastic system must be able to overcome these failures ina predictable and efficient manner, while again returning to a state of fault tolerance,if possible.

Continuing with our WebSphere eXtreme Scale data grid example, as you grow togrids of hundreds or thousands of container processes, the loss or maintenance ofone of those processes is more and more probable. Through replication -- which is acore competency of WebSphere eXtreme Scale and similar in-memory data gridofferings -- these events can be tolerated. Not only that, but since the placement andmigration of the data is completely transparent behind the "black box" of the

WebSphere eXtreme Scale client APIs, a new replica is automatically created andfault tolerance is achieved again.

Elasticity needs to have this conceptual addendum in order to be truly useful asdeployments grow and become more complex.

Administrative simplicity

ibm.com/developerWorks developerWorks



4/6

Specialized needs regarding the administration and maintenance of a system can besubtle when considering the meaning of an elastic infrastructure. However, similar tothe requirement of fault tolerance as systems grow and become more complex, youmust also consider the ability of the deployer to perform common administrativetasks.

The key concept here is that the configuration and maintenance of each node shouldbe either identical or very minimally different. You shouldn't expect the deployer toprovide a list of all member machines or processes for the system to operate. Thereshould be some level of automatic discovery and management based on a commonset of configuration artifacts.

In the case of WebSphere eXtreme Scale, the approach is fairly straightforward.Configuration information focuses on the structure and characteristics of the griditself, not on any details of the specific member processes. For example, youconfigure how many partitions to split the data into, and how those partitions shouldbe replicated. Given this information, WebSphere eXtreme Scale maps that to theavailable grid members and enforces the policies set forth in the configuration. Theexact same set of configuration artifacts are provided to each grid member whenstarted, and the details of that member's place in the grid's world is managed anddetermined automatically.

This philosophy is carried down throughout the administration and maintenancespectrum, with each interaction designed to separate the details of the physical gridfrom the logical structure of the grid constructs.

We can find many more examples of this, such as the decoupling of replicaplacement through the use of the zone abstraction, or the ability to upgrade the

actual grid code level without bringing the grid itself offline. The key concept is thatadministrative tasks should have a constant complexity as the system scalesoutwards, or at least as close to constant as possible. From this, you can see hownicely elastic software and elastic hardware (that is, virtualization and clouddeployments) can dovetail to provide a new level of freedom to enterprise solutions.

In praise of buzzwords

It's probably safe to say that even our most pervasive foundational technologieswithin computing started out as some sort of buzzword. We simply need to strive to

define meaning and useful purpose when adding a new concept or goal set to ourvocabulary. In this way, I think it's clear that elasticity in enterprise solutions can be avaluable concept when clearly defined and thought through to logical conclusions.We have consistently tried to relate concrete and useful meaning when we talkabout WebSphere eXtreme Scale as an elastic data grid, and will strive to continueto do so as we apply these concepts to other solutions that are designed to createtruly flexible infrastructures.




5/6

ibm.com/developerWorks developerWorks



6/6

Resources

Learn

WebSphere eXtreme Scale product information

WebSphere eXtreme Scale Information Center

IBM developerWorks WebSphere

Get products and technologies

IBM developerWorks WebSphere eXtreme Scale trial download

Discuss

WebSphere eXtreme Scale XTP Development Community

About the author

Robert Wisniewski

Robert Wisniewski is a Software Engineer specializing in performance andscalability. He has previously worked on WebSphere Applications Serverperformance for 7 years focusing on all areas of the product from EJB/JPA toautonomic computing and benchmark design. His current position as TechnicalEvangelist refocuses this experience on customer scenarios and the application ofXTP strategies in the real world.


http://www-01.ibm.com/software/webservers/appserv/extremescale/?S_TACT=105AGX01&S_CMP=LPhttp://www-01.ibm.com/software/webservers/appserv/extremescale/library/index.htmlhttp://www.ibm.com/developerworks/websphere/http://www.ibm.com/developerworks/downloads/ws/wsdg/http://www-01.ibm.com/software/webservers/appserv/extremescale/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www-01.ibm.com/software/webservers/appserv/extremescale/http://www.ibm.com/developerworks/downloads/ws/wsdg/http://www.ibm.com/developerworks/websphere/http://www-01.ibm.com/software/webservers/appserv/extremescale/library/index.htmlhttp://www-01.ibm.com/software/webservers/appserv/extremescale/?S_TACT=105AGX01&S_CMP=LP

Download - Innovation Within Reach

Top Related