Jason R McGee, Billy Newport, Brian Martin, Ann Black, Christopher Vignola and other members of the development team have joined together to provide insight into how WebSphere Extended Deployment (XD) can be utilized and how it can contribute to your business. They are the senior architecture team that worked together to design and deliver XD, and are driving the future direction of the XD product and technologies.

IBM WebSphere eXtreme Scale weekly podcast now live

WVE 6.1.0.3 brings vmware integration

• Integration support for VMWare ESX Server 3.5. Application Placement Controller can now make placement decisions with knowledge of how servers and nodes are associated with virtual and physical machines.
• The runtime controllers (Application Request Flow Manager, Application Placement Controller, Work Profiler, etc) understand and support vertically stacked WebSphere nodes on a physical machine.
• Application Request Flow Manager (ARFM) now supports memory overload protection.

Debugging memory leaks in WebSphere

Videos showing using ObjectGrid with ND 6.0.2 and RAD

Migrating from WebSphere ND to XD (Operations Optimizer)

ObjectGrid brings XTP and CEP together

XTP: Pat Helland, Square architectures and distributed transactions evolve

XTP needs square architectures. A square architecture is one where the right hand side gets wider as the left hand side gets wider. The whole architecture scales from left to right. This is necessary to maintain growing transaction rates with constant transaction times. All resources needed by the system must have a way to scale out.

Products such as ObjectGrid can provide a framework in which to host XTP applications. The applications run using a partitioned model. There is no two phase commit. Transactions span only a single partition. A partition provides a unit of scalable state management for the application. This state includes both relational data as well as messaging based data. ObjectGrid unifies both types to a single data model and API. Messages are data and vice versa, there is no distinction.

If a transaction needs to change data across partitions then it's done in multiple steps. The first step is a transaction on partition A. Partition A sends a message to partition B. This message is sent from A to B using single phase commit. B may receive the same message multiple times and B must be able to handle this. B processes the message asynchronously.

ObjectGrids job is to provide the infrastructure for hosting and placing the partitions, providing fault tolerance and data integrity and supporting the above architecture. The application developers role is to architecture the system as a set of partitions and write the business logic using a one transaction per partition model with messaging hooking up multiple partitions. The developer doesn't need to worry about the infrastructure needed to host the application; this is ObjectGrids job in this.

Pat Helland from Amazon wrote an excellent paper on this type of architecture. ObjectGrid is designed around and embraces this type of architecture when hosting XTP applications. Pat describes keyed entities. Transactions cannot span entities. Logical transactions spanning entities happen instead with a series of independent entity scoped transactions connected using idempotent messaging. This approach expressed in ObjectGrid terms has an entity equal to a partition. An entity is an object graph with a hashable root object. Applications route messages to the root object using a hashing approach. ObjectGrid provides relational management for the entities and a messaging mechanism for communication between partitions.

As companies move to a real time rather than a batch enterprise architecture then we'll see XTP start to spread from telco and financial companies today to more and more enterprises as they try to make their business models real time. This is necessary for companies to stay competitive. Waiting for batch jobs to complete etc was fine several years ago but won't help them be competitive moving forward. No one wants to wait. Everybody wants everything immediately. Conventional triangular architectures will not cope as companies move to this model. The front end of these applications will use square architectures and XTP patterns and middleware.

There will still be conventional back-ends for reporting hosting on data ware houses, at least until XTP data stores evolve to support distributed reporting etc. These back-ends will basically be asynchronous replicas of a subset of the state in the XTP system.

To summarize, as we move towards real time enterprises, XTP will start to take hold and applications will need to be designed around new architectures as described here in order to scale effectively, middleware will need to evolve to support these new architectures. These types of architecture and exactly why we’re building ObjectGrid.

Categories : [   ObjectGrid  |  XTP  ]

Aug 25 2007, 09:09:54 AM EDT Permalink

XD 6.1 Narrated Presentation

Messaging only APIs need to go, JPA needs to step up

Compute Grid versus DataGrids

Compute grid characteristics

A compute job is typically stateless. The job is split in to many parallel steps which are dispatched to a set of machines for processing. The jobs produce some form out output that may be aggregated. Typically, the time taken to fetch the data needed by a step is a very small relative to how long the data takes to be 'processed'. The various internet grid computing initiatives are excellent examples of this type of job. A step can usually be placed on any server with access to any resources needed by the job, affinity isn't typically needed. The process running the job step may be launched for each step (better isolation) or shared between subsequent steps (limited value unless starting the process is very expensive, i.e. an application server).

DataGrid characteristics

A data grid is similar but here the computation cost relative to data fetch cost is different. Fetching the data takes longer than the time to process the entry. So, a datagrid is fast because it has the data already loaded in the memory of a grid of servers. These servers may use replication to make this data 'persistent'. The data is usually automatically partitioned and placed on the servers comprising the grid. As servers are added and removed, the data may be redistributed to balance the data over the available servers in the grid.

The data is partitioned across the servers. Each piece of data/partition is hosted by one or more servers. The job logic is available within the container hosting the data. When a client submits a job for a particular piece of data then the job can be routed to a server/container with the data needed for the job and the result returned. Another model is that the job may require processing data matching a query/filter/predicate. Here, the job is multicast to all partitions. Each partition runs the query, and processes the results and returns them to the client. Either way, the client receives a list of results for the set of keys requested. This job may be run in parallel on all machines hosting relevant partitions.

Another pattern is the aggregation or reduction pattern (popularized by google). Here, the job consists of selecting a subset or all of the data and applying a predicate to it to reduce it to a single result. An example might be, calculate the sum of all entries, find the minimum value, find the best matching hotel property or the best matching web page. Each partition can run the predicate, and apply the predicate to all matching data. The reduced results from each partition and then aggregated again to provide to grid-wide result and this is returned to the client.

Both patterns are useful and both can utilize the power of the grid to process the data at extremely high speeds.

Compute grid or data grid, it depends..

So which one do you use. Clearly it depends on the cost of accessing the data versus processing the data. Longer processing times relative to data fetch costs mean a compute grid is more appropriate and vice versa. While not first in these spaces, WebSphere XD is clearly aiming at supporting both types of grids in farms of thousands of servers. ObjectGrid supports and will support DataGrids and Business grid supports compute grid type work loads. XD will be able to manage both types of job along with OLTP workloads and balance assigning resources to the tasks based on business priorities.

Categories : [   business  |  compute  |  grid  |  objectgrid  |  xd  ]

Dec 14 2006, 03:47:34 PM EST Permalink

Leveled provisioning architectures, keys to success

Level 1, thread/request provisioning

Here, a router or proxy or even a thread pool within an application server can make changes. This is the least costly way to meet goals and it has the fastest reaction time. The proxy will have a queue of outstanding requests and a set of targets that can accept those requests. It will first classify the requests in to something like high, medium and low priority. It will do something like a weighted round robin over the requests to ensure that the response times are met for the high priority requests. This could possibly starve out lower priority requests if need be. But, if a class of requests is not meeting the goal then improving its response time by starving the lesser goals is a really cheap way to meet the goal. The cost is simple adjusting weights on the dispatcher which is a very cheap action to take. What happens when you still can't meet the SLA and you have completely starved the lesser classes? Time to move up the provisioning tiers.

Level 2, application placement

Here, we know that an application (AppA) which services a particular request class cannot meet its goals. The placement controller looks at the set of nodes currently available and will change the mix of applications to have more of the AppA application running in the node group. This provides more CPUs for the application which should allow it to better meet its SLA. If this isn't enough then we may add more than one extra CPU to the mix. Obviously, this is more expensive than Level 1. We're stopping and starting JVMs here and this can take between one to two minutes before the JVM starts and then the JIT starts running and maybe after a few thousand requests can been processed by the new JVMs then it'll be up to speed. The reaction time of level 2 compared to level 1 is pretty significant. Changing weights in memory is millions of times cheaper than starting a JVM.

But, again, what happens when we have used all the machines to run AppA and we still can't meet the SLAs. Time to kick up to the next provisioning tier.

Level 3. Machine provisioning

We get here when the set of machines given to XD cannot meet the goals. We now need to integrate XD with products such as Tivilo Intelligent orchestrator(TIO) or Tivoli Provisioning Manager (TPM). These products can manage multiple farms of machines. Lets say farm A runs a Data Synapse compute farm. Farm B runs XD. Suppose TIO was told that farm B is more important than A. So, when XD says it cannot meet the goals then it tells TIO of this problem. TIO then makes it's decision to pull a machine from Farm A and give it to Farm B. This can be quite complicated. The Farm A intel box might be running Solaris and XD may be required to run on SUSE 10. TIO has to tear down the box and install SUSE and XD and then add the box to the XD node group. Obviously, this can take a while, maybe 30-45 minutes before the action has any impact on the performance of farm B. Virtualized hardware can help here significantly with the latency. If the box was running VMWare or XEN then we could tell XEN/VMWare to simply stop running the Solaris Data Synapse virtual machine and then start a pre build XD virtual machine. The operating system would take maybe five minutes to boot and then maybe another 5 minutes of XD to start running so ten minutes. The virtual machines would also significantly simplify configuring the TIO/TPM simply because the number of configurations is greatly reduced, i.e. we're running virtual hardware now so we only need one operating system image.

Summary

Obviously, provisioning is a fractal type architecture. It's the same sort of thing from a high level going on at each level but the details are different. What should be clear is that as we move up the levels, the ability of the system to react slows down. Level 1, we can handle pretty quickly, update a weight in memory and increase response. Level 2, we move out to two or more minute times before the change starts to help out. Level 3, we could be at as much as 45 minutes. WebSphere XD is an example of a level 1 and 2 provisioner. TIO and TPM are level 3 provisioners. Customer success with this technology depends on realizing these kinds of scenarios and understanding the chain of events. If you have applications that need to respond to 10x load increases within a second then you better stick with level 1. Level 2 and 3 will not be able to respond fast enough for that kind of goal. Conversely, if you have applications where load slowly ramps up over 15 minutes then a level 2 system will probably work well for you. Next, if you know on a certain day that your load doubles then a level 3 system can help automate that nicely by automatically changing the farm machine ratios using a simple calendar.

Categories : [   provisioning  |  virtualization  |  websphere  |  xd  ]

Oct 23 2006, 11:00:20 AM EDT Permalink

Virtualization, whats its good for and its limitations

• Governance
• The benefits of hardware virtualization
• The limitations of hardware virtualization

Is Oracle RAC a product of the past, a dinosaur?

New Article on developerWorks on Virtualization and Dynamic Middleware

Dynamic middleware and the six attributes of virtualized application serving environments

Jason McGee

Categories : [   dynamic  |  operations  |  virtualization  |  xd  ]

Sep 27 2006, 03:24:16 PM EDT Permalink

Scripting ObjectGrid with Jython (and wsadmin)

1) Copy the wsobjectgrid.jar into your WAS_HOME/lib (this is already present if you installed XD)

2) Launch wsadmin

3) Interact with the objectgrid (perhaps the most important part is the the "from com.ibm.websphere.objectgrid import *" to get the objectgrid classes into the Jython environment). Here is a sample typescript where I followed part of Billy's example in the Jython wsadmin shell:

-Brian

Categories : [   jython  |  objectgrid  |  wsadmin  ]

Sep 25 2006, 01:46:13 PM EDT Permalink