comparing some of the http front-end options...this presentation is aimed at about the half-way...

Comparing Some of the HTTP Comparing Some of the HTTP Comparing Some of the HTTP Comparing Some of the HTTP

Front-End OptionsFront-End OptionsFront-End OptionsFront-End Options

IBM Americas Advanced Technical Support -- Washington Systems CenterGaithersburg, MD, USA

Don Bagwell

IBM Washington Systems Center301-240-3016

[email protected]

(This page intentionally left blank)

Objective/Agenda of Presentation

MVS System or LPAR

DMGR

CR SRA

Daemon

CR

Server_A

CR SR

Server_B

CR SR

Server_C

CR SR

Node Agent

CR

"HTTP Front-End Traffic Handler"

To explain and position some of the different ways you can "front-end" Websphere for handling HTTP requests

We'll explore five options:

z/OS Sysplex Distributor

HTTP Server + WebSphere Plugin

WebSphere Proxy Server

WebSphere XD On Demand Router

Combinations of the above

High-level Agenda:

Explain purpose of considering front-end at all

Explain the comparision criteria

Detail each optionWhat it is, how it works, strengths/weaknesses

Show how options can be blended together Technical temperature of this presentation ...

The purpose of this presentation is to introduce the concept of a "Front End" device for HTTP trafficand why it's needed and desired for a WebSphere for z/OS configuration. We'll explore severaldifferent IBM options. And we'll explain the evaluation criteria we'll use to compare one against theother.

PRS2663 - WebSphere for z/OS: Comparing Front-End HTTP Optionsibm.com/support/techdocs

Version Date: July 11, 20081© IBM Americas Advanced Technical SupportWashington Systems Center, Gaithersburg, MD

Technical Temperature Planned

Time won't permit us to turn the heat way up on this and go into a lot of technical detail. We're aiming to get essential concepts across:

Deep details of configuration, operations, management and performance

Marketing buzzword presentationJust having a little fun at the expense of our marketing friends ☺☺☺☺

This presentationImportant key concepts about HTTP handling out front of an application serving environment

Explanation of some of the comparison criteria we'll use

Some details of each of the five solutions we'll compare

A few charts on how they can be combined to blend the best of each

Truth is, this is a very technical area ... we could spend hours plumbing the depths of just one of the solutions. But we have one hour here.

WebSphere's HTTP listeners ...

This presentation is aimed at about the half-way point between a deep discussion of specific technicaldetails and a fluffier presentation. We'll aim to present the essential concepts and put on the table theimportant points about the comparison criteria and why they're important. We'll also have a few chartsshowing how the options can be blended with one another to achieve the best of each in a broaderarchitecture.

We're aiming at the middle-point because this topic is a very technically complex one. There is aremarkable depth of detail behind each one of the solutions we'll present. The objective isn't to get atall those details, but rather to present just enough so you can understand the different options, positionthem against one another, and make an informed decision.



Fact: Multiple HTTP Ports

The design of WebSphere -- all platforms -- calls for each application server to have its own HTTP listener ports

DMGR

CR SRA

Daemon

CR

Server_A

CR SR

Node Agent

CR

MVS Image

A

Daemon

CR

Node Agent

CR

Server_Ba

CR SR

Server_Bb

CR SR

MVS Image

B

Cluster

Even clustered servers employ separate portsThe port numbers may be the same (on different TCP stacks) but

they're still separate ports

You can point browser straight at the server port

But there are several disadvantages to this:Likely to require port specification on URL

No caching of static content

No ability to "load balance" between servers

No ability to "fail over" in event of server outage

Doesn't really exploit clustering

No use of DMZ

Okay for internal access, but not okay for production or external access

We'll explore basics of

these next

Some kind of "front end" device is typically needed

The first key point to get across is that with WebSphere Application Server, each server has its ownHTTP listener ports. That's true of WebSphere on z/OS and it's true for WebSphere on the distributedplatform. It's a trait that's part of the basic architecture, and it's common across all platforms.

Even clustered servers have separate HTTP listeners. They may very well be defined as possessing thesame port number values. But they're still separate.

Note:

It is true that you can point a browser straight at the HTTP port of an application server and get at anapplication running inside a WebSphere server. Many people do just this. But it has many downsides:

� The application server will very likely be defined with an HTTP port other than the browser's default port of 80.Therefore, it'll be necessary to specify the port on the URL. It works perfectly well, but it's not something you'dnormally expect an external customer to do. For internal testing it's great; but not for external customers.

� There's no caching of static content at all. That means that every time you request a piece of static content,the application server has to serve it up as if it was the first time. (This is different from browser caching --your browser may very likely cache the concent. We're speaking here of the server caching content.)

� If the application is in a cluster, then pointing your browser directly at the server will mean you only drive theapplication in one cluster member only. In other words, there's no way to "load balance" between clustermembers when the browser is going straight at the application server. Related to this is the notion of failover... there is no failover possible if the browser is going straight at a server's HTTP port.

� There's no use of a DMZ, which is something we'll explain in a bit.

This works perfectly well for internal access, but in the "real world" some kind of HTTP front-end deviceis going to be needed.



More Than Just Round-Robin

Imagine a device that simply round-robined requests between all the available backend servers:

DMGR

CR SRA

Daemon

CR

Server_A

CR SR

Node Agent

CR

MVS Image

A

Daemon

CR

Node Agent

CR

Server_Ba

CR SR

Server_Bb

CR SR

MVS Image

B

Cluster

But there's something missing here ... this works, but it's not enough, is it?

Apps may not be in every serverMay need to understand how to route app requests

Application or server may not be upMay need to undestand status of application or server

Server may not be able to accept new requestsServers may be too busy handling other things

Therefore, front-end devices need other features and functions ...

To help illustrate the point that HTTP front-end devices possess various capabilities beyond merelyround-robin distribution, imagine a device out front that did only that. Incoming requests were simplyforwarded on, each request being simply forwarded to the next server in line. This would be anexample of a very simple round-robin distribution.

This might work technically, but there are many shortcomings to this. Some things that are missingwould be:

� First, an application may not be deployed in every single server. You would not want a request forwarded to aserver in which the application wasn't running. That would result in an error. So it's clear that the device willneed at least an ability to understand the URL that's been received and how to route it.

� The application or the server itself may not be up, so the device should have some way to know this. Mostdevices have at least the ability to know whether the server itself is up; many have no idea about theapplication inside the server.

� A more subtle thing is whether the server designated as the target for the request has the ability to process therequest. The server may be too busy; a new request would simply be queued up and not worked on untilsome future time. Some devices determine this very crudely (simple ping and a timing of how long it takes toget a response); some use very sophisticated methods.

So the point is this: an effective front-end device will have to provide something more than simpleround-robin. So what are the things typically found in front-end devices? That's next.



Typical Features of Front-End Devices

A quick explanation of some typical features of front-end devices. Not all do each equally well ... hence our compare/contrast in this session.

Server_2a

CR SR

Cluster

Server_1

CR SR

Server_2b

CR SR

Server_3

CR SR

Load Balancing / Failover / Request DistributionAbility to distribute traffic between multiple servers hosting same application

Balancing may be simple to quite complex, based on known conditions

Caching / Edge ServingAbility to store frequently accessed static files "at the edge," taking load off the backend application servers

DMZ PresenceAbility to position device between two firewalls -- one firewall faces outside network, second faces inside network. Space between is "DMZ"

Session Awareness / Session Affinity RoutingAbility to route requests to server in which user's "session object" resides.

Advanced Autonomic FunctionsStart / stop backend servers based on workload presented

Queue requests until server back online

Let's explore these a bit more ...

WebSphere XD -- ODR

So here we'll explore some typical features of front-end HTTP devices.

This is not to say that this list encompasses all the features, or even that these are the mostimportant to all people. This is simply a list of what may be construed as some important ones.This list is what we'll use in this presentation to compare the various front-end options we'll explore.

Important:

We'll cover some of these in more detail over the next couple of charts, but for now let's quicklydescribe each:

� Load balancing / Failover / Request Distribution -- this is the ability to take the inbound traffic and intelligentlyroute it to the backend servers. This can be relatively simple to very complex.

� DMZ Presence -- DMZ stands for "Demilitarized Zone", which is a phrase applied to the space between twofirewalls placed between the secure internal network and the very unsecure Internet. We'll look at this in moredepth in a bit. The point here is that some devices live in the DMZ more easily than others.

� Caching / Edge Serving -- the ability to interpret a request and determine that the thing being requested hasbeen requested before and to serve it out of a cache rather than having it served up by the application itself.

� Session Awareness / Session Affinity Routing -- "session awareness" refers to the ability of the front-enddevice to understand that the application is making use of session objects in JVM memory. "Session routing"is the ability to make routing decisions based on that awareness. We'll cover what both are in a bit.

� Advanced Autonomic Functions -- the ability to not only be aware of the backend servers, but control them as

well. This is a relatively new thing embodied in the new Extended Development product, which we'll cover.

There's one we've left out intentionally -- security. That's an extremely broad topic, and one that's reallysomewhat separate from the topic of front-end HTTP traffic distribution.

Note:



Basics of Request Distribution

One of the very basic purposes of a front-end HTTP device is to accept requests and then "spray" them to the backend servers. But there's a few things going on behind that ...

Evaluate request and determine where request should go

only the most simple devices assume all backend

servers eligible to receive request

determine what the request is asking forTypically "context root" and "servlet request" (URI)

route to backend server hosting applicationBased on knowledge of backend environment, which may be "static knowledge" (manually configured) or "dynamic" (automatic detection)

If multiple instances of application: distribute using some algorithm

Simple round-robin

Static weighted distribution

Based on simple knowledge of backend capabilities

Based on sophisticated knowledge of backend

detect outage and cease routing thereSimple "hearbeat"

More sophisticated methods

Advanced: queue requests

Server_2a

CR SR

Cluster

Server_1

CR SR

Server_2b

CR SR

Server_3

CR SR

"HTTP Front-End

Traffic Handler"

Appl

A

Appl

B

Appl

B

Appl

C

Options we'll look at do these to varying degrees -- simple to sophisticated

Next: "DMZ Presence" ...

Let's start by exploring the fundamental purpose of front-end device: to route requests to the multiplebackend servers. There are two key things related to this:

1. The front-end device has to evaluate the request that was received and make a determinationwhere the request is to be sent. This is done by evaluating the URL and making a decision basedon knowledge of the backend environment. That knowledge of the backend environment may be"static" (manually configured table of where applications reside) or "dynamic" (some automaticallyupdated table of information on backend applications and their locations).

2. In the event an application resides in more than one server, then the front-end device has todetermine which of the multiple targets the request is to be sent to. This could be something assimple as "round-robin" (next in the list), a modified round-robin (static weighting), or somethingmore sophisticated (such as what's done when WLM is used to determine which server is best ableto handle the request). Further, the front-end device should be able to know not to route requeststo servers where the request can't be handled. This can be done with a simple heartbeat check ofthe server itself, or using more sophisticated methods.

The various options we'll look at do these things in different ways, with varying degrees ofsophistication. But they all do these two basic things.



Role of a "DMZ"

A "DMZ" -- "DeMilitarized Zone" -- serves as a buffer between the Internet and the secure private network. A very common place to put a front-end device.

"Hole" opened in firewall to allow very limited protocols to limited IP addresses

and ports -- servers in DMZ

Limited to traffic from DMZ

servers only, limited to certain protocols, ports

www.mycorp.com

ports 80, 443

sysa.mycorp.com

ports: whatever

Unsecure network

Secure NetworkDMZ

The nature of the traffic coming from HTTP Device

(protocols, number of ports) will determine how "friendly" the device is to

a DMZ placement

z/OS can play in the DMZ, though people often opt for non-z/OS server there

The options we'll explore have differing degrees of "DMZ Friendliness"

The DMZ device does not need to be the same thing as the device that distributes requests ... can work in tandem with HTTP handler inside secure network ... often is a "blended" solution (more later)

Three points:

Next: caching and serving at the edge ...

The acronym DMZ stands for "Demilitarized Zone," and it's an informal term used to refer to the spacebetween two networking firewalls that are placed between the "secure network" and the "unsecure"network. Two firewalls are used rather than just one for this reason:

� The first firewall, the one between the unsecure and the DMZ, is very tightly controlled. It disallows all trafficexcept a very limited set of traffic destined for only devices located in the DMZ.

� The second firewall, the one between the DMZ and the secure network, is also tightly controlled. It only allowscertain traffic through, and often only traffic that's coming from a device (IP address) in the DMZ. Traffic fromthe unsecure network can't get to the secure network directly because two firewalls are working against that.

Front-end devices are typically placed in this DMZ because these front-end devices do not possessany sensitive data. They are exposed to controlled traffic from the unsecure network, but even thatcan have malicious content. Therefore, devices that aren't quite as sensitive as, say, a databaseserver, are placed out there. And sensitive devices (databases) are kept well secured behind thesecond firewall.

Another advantage of a DMZ is it allows the DNS (domain name server) to resolve to some generic hostname hosted in the DMZ and therefore mask (or hide) company specific IP hosts back in the securenetwork.

Note:

Three points:

� This picture is showing a PC in the DMZ, but please don't conclude that z/OS doesn't play in the DMZ. It canand does ... safely and securely. But for some the corporate direction is to not put z/OS out there. So here weshow a PC.



� The "DMZ Friendliness" of a device is related to the complexity of the traffic that flows between it and thebackend servers. The more complex, the more difficult it is to "open up" the second firewall securely. Themore openings in the firewall that are required, the greater the chance something will be mistakenly opened.

� The device in the DMZ does not need to be the HTTP front-end device. In fact, it may not be. Some otherdevice, such as a router or security access device, may be in the DMZ. The HTTP front-end device may verywell be entirely contained in the secure network. Or it may be out in the DMZ along with other devices. Thereare lots of different ways to configure this stuff. The key point here is that the DMZ device does notnecessarily have to be one of the HTTP handlers we'll discuss here. It may be, but doesn't have to be.

Next let's explore the concept of "edge serving" ...



Caching and Edge Serving

Most applications consist of a mixture of static content (fixed) and dynamic content (specific to the person or transaction)

It has been shown to improve throughput and reduce server cycles to move static content out of application server and to "the edge" -- closer to where users are. That "edge" can be the HTTP handler.

Main Point:

There are companies that sell this as a service -- the use of their server infrastructure so you can move your static content to them -- AkamaiTM is one example. Look for that next time you use web.

Server_1

CR SR

WebSphere for z/OS

DB2

"Akamai" is a trademark of Akamai Technologies, Inc

HTML, JPG, GIFStatic Content

Dynamic Content

First request served from backend, where it's cached by caching device. Other requests are then served out by caching device. [Proxy, ODR]

Application designed to assume static content is elsewhere; files are pushed out to edge device where they're served from there in all cases [HTTP Server, ISP]

Edge serving could be out

here too

Caching:

Edge Serving:

Next: session awareness and routing ...

Almost every application out there are comprised of content that is dynamically generated, meaningcontent that is specific to the user, or based on a specific inquiry such as a bank account, and contentthat is static such as things like common banners and generic HTML pages. Purely dynamic contentneeds to be served up each time, but static content provides the opportunity to cache the contentsomehwere else, relieving the application server from the burden of serving it up each time.

There's one very familiar form of caching away from the application server itself -- browser caching.We're all familiar with times when we expected to see one thing but saw instead something else. Onlywith a "browser refresh" do we see the new content. That's one example of caching. Here we'respeaking of another example: caching by some serving device other than the application server itself.

Note:

The reason people consider caching content at all is because it's been shown to dramatically improvethe overall performance of the system. There's little reason to force the application server to exerciselong code paths just to serve the same content over and over again. Further, to help offloadnetworking resources, it's been found to help performance to move the content away from theapplication server and to "the edge" of the network ... or, in other words, closer to the user.

And companies exist that provide this service for a fee. Akamai is one such company. They maintainservers around the world that hold and serve up content on behalf of others.

Note:

There are two basic flavors of this: caching and edge serving. The difference is somewhat subtle:

� Caching means the content is initially served up by the application server and stored dynamically bythe front-end server. The front end server recognizes the content as "cache-able" and stores it.Subsequent requests for that content are intercepted by the front-end device, which serves up the



content on behalf of the backend application server. The WebSphere Proxy Server and the OnDemand Router do this.

� Edge Serving is the practice of intentionally designing the application to host static contentsomewhere else. Here the URLs of the application are constructed in a way that content known tobe static will be served by the edge device while URLs for dynamic content are forwarded back tothe application server. The HTTP Server is an example of a device capable of doing edge servingof static content. ISPs such as Akamai are another.



Session Affinity Overview, Part 1

Some applications -- not all -- maintain information about a user between requests. This is done by creating "session objects" that contain the information.

HTTP is a "stateless" protocol, which means that each request is seen as "separate" from others.

Information is placed in the HTTP flow between browser and server to identify "Fred" -- by default a JSESSIONID cookie with a long hex string containing session ID and server IDNote: but not user's name, password or other personal information

Note: other routing methods -- URL rewrite and SSL ID value

Session Object

Application

JVM in WebSphere Server

"Fred"

Name: Fred

Account: 12345

Last Page: ABC

HTTP

So far so good ... but what happens when application is in a cluster?

Let's now look at something called "Session Affinity." This becomes an important topic whenapplications make use of "session objects," which are Java objects maintained in the JVM that containinformation about the user. Not all applications make use of session objects. But those that dointroduce the need to worry about maintaining "affinity" -- which is a fancy term which means "makingsure the user's requests get back to the same JVM where his session object resides."

Unlike other protocols, HTTP is "stateless," which means that a user's second request is notautomatically "tied" to a given server. So when session objects are employed by an application, itmeans it's important to make sure the user's requests get back to the same server. If there's only oneserver then there's not so much of a problem. But what about when an application resides in a clusterand therefore the session object may be in one but not all members of that cluster?

At a high level this is addressed by putting information into the HTTP flow after the session object iscreated so that the devices in the network can -- if they're designed to understand -- know where toroute the requests. This is done by default with a cookie, but other methods are available. (Thecookie, by the way, is only a semi-random string of hex characters -- it does not have the userid orpassword in it.)



Session Affinity Overview, Part 2

In a WebSphere cluster, the application runs in multiple servers at the same time. But session object will reside only where originally builtNote.

Appl Fred

WebSphere Server

Appl

WebSphere Server

"Fred"

Performance studies confirm that best thing to do is route Fred back to server

where session object resides

Cluster

Session Awareness: ability for HTTP Handler to know there's a session object created

Session Routing: ability to react to and route request to where session object is located

Notes:

It is possible to store object in relational database and fetch it back. Known as "persistence." DB read/write overhead.

It is possible to copy object JVM memory-to-memory. Known as "domain replication." Better, but still overhead.

Best is to route back to original server.

Combination of both offers failover advantages

"HTTP Front-End

Traffic Handler"

Multiple servant regions behind a controller is a different matter ... controller handles affinity there

automatically

The two go hand-in-hand, of course

Let's look at each option in a bit more depth ...

When WebSphere hosts an application in a cluster, it has a copy of the application in each servermember of the cluster. But each server member maintains a separate JVM, so any session objectscreated are created in whatever JVM the initial request is routed to. So in our example here, Fred'ssession object may exist in the top server but not the bottom server. If that happens, then it's reallyimportant that Fred's second request (and third, etc.) get back to that server.

As the bulleted notes indicate, there are various methods of copying session objects from one JVM toanother, and to store in DB2 and fetch it back. But the best performer is simply routing subsequentrequests back to the server where the object was originally created.

Note:

There are now two concepts to introduce, both very much related to one another:

� Session awareness -- which is the ability of the front-end HTTP handler to undertand that a sessionobject has been created.

� Session routing -- the ability to react to and properly route a request requiring affinity back ot theproper server.

Session awareness and routing is something most of the options we'll explore do, but not all do it. Andthose that do perform session routing handle it in two ways -- statically or dynamically.



Five Options We'll Explore

The five we'll explore, and the criteria we'll use to compare:It's important to understand there are a lot of different devices that can act as front end "request sprayers" -- software and hardware devices. We're not implying this is all that's available to you.


Part of z/OS Communication Server (z/OS TCP stack), it provides load balancing and a way for an IP address to be dynamically moved to another adapter in the event of failure (adapter, TCP stack or LPAR)

IBM HTTP Server or others, the Plugin is software supplied with WebSphere for the purpose of providing session affinity routing.


A function introduced in WebSphere Application Server V6, the proxy server is essentially an application server with function that makes it aware of application environment and provides routing, affinity and caching.

WebSphere Proxy Server

A function of WebSphere XD (Extended Deployment), think of this as a "supercharged Proxy" -- all the functions of the standard WebSphere Proxy Server plus greater integration with WLM, application server starting, request queuing and something called "storm drain avoidance"

XD On Demand Router

Combinations The above options blended to create a solution that combines the best of each

Load balancing capabilities Awareness of Environment

DMZ Friendliness Ability to Configure for HA

Caching / Edge Serving Platform Applicability

Affinity Routing First, Sysplex Distributor ...

Let us now look at the five HTTP front-end options we'll explore in this presentation:

� z/OS Sysplex Distributor -- a function of TCP, it is a very robust and intelligent load balancing system.

� HTTP Server + WebSphere Plugin -- what most of us are familiar with when it comes to routing WebSpherework.

� WebSphere Proxy Server -- something new in V6.0.2, this is really a beefed-up application server.

� WebSphere Extended Deployment On Demand Router -- something that comes with Extended Deployment (aseparate extention to WebSphere), this can be thought of as a beefed-up proxy server.

� Combinations of the above -- several of these solutions can be used in conjunction with one another to forman even more robust solution.

Rather than simply tell you about the various options, we'll also offer a comparison between them,using the things shown on the chart above as the comparison criteria.




Note: only the very basics are shown here ... there is a tremendous amount of detail behind the scenes; details network specialists understand

The first we'll look at is z/OS Sysplex Distributor. It's imporant to note that in the limited time we havehere we can't possibly go into every detail of Sysplex Distributor. It is a remarkably feature-richfunction. What we'll do here is provide the essentials.



Quick Overview of Sysplex Distributor

A feature of TCP since OS/390 V2R10, it provides a way to dynamically route traffic within a Parallel Sysplex evironment:

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

CF

"Hosting Stack"

DVIPA

192.168.1.1

DNS

www.mycorp.com = 192.168.1.1

???

DVIPA ...

Network

DNS relates host name of DVIPA advertised by Sysplex

Request is routed to TCP stack hosting DVIPADVIPA can move if needed -- next chart

Sysplex Distributor determines which stack to send request toReal time consultation with WLM, which advised on which hosting server can best meet goals

Request is routed across XCFVery fast coupling facility -- not full stack IP routing

Receiving TCP stack passes request up to server on specified port

Sysplex Distributor is a feature of TCP that comes with Communication Server, and has been a part ofthe TCP function since OS/390 V2R10. It's purpose is to provide a way to dynamically route IP traffic(not just HTTP) within a Parallel Sysplex environment, using the communication channels of theCoupling Facility (CF) to provide very-fast cross-system exchanges.

At a very high level, Sysplex Distributor works like this:

� Users in the outside world have no idea that Sysplex Distributor is at work. They simply point their browsers ata host name and rely upon the Domain Name Service (DNS) to resolve the host name to an IP address. Theaddress will be that of the adapter hosting a "Distributed Virtual IP Address" (DVIPA), which we'll explain morenext.

� The DVIPA is associated with a TCP stack running on an MVS image in the Sysplex. That TCP stack runscode that is aware of what TCP ports are bound where and how able the LPAR is to accept the traffic. (It usesWLM for that last part.) Sysplex Distributor then determines which LPAR to route the request to, based on theport requested and the number of images on which the port is bound. If the port is bound on only one,Sysplex Distributor routes it there; if it's bound in multiple places then Sysplex Distributor determines the bestplace to go (based on WLM metrics) and routes there.

� The coupling facility handles signalling among the Sysplex members. Actual data flows over the IP network,but that is optimized when flowing within the same physical machine and is thus very fast.

� The receiving TCP stack accepts the request and passes it up to the server on the specified port

A key part of this equation is the DVIPA, which is capable of moving to another MVS image in theSysplex. It's the DVIPA function that protects against losing the adapter and IP address known to theworld through the DNS.



DVIPA - Distributed Virtual IP Address

A feature of TCP since OS/390 V2R8, it provides a way for an IP address to automatically move if something fails:

Network

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

MVS Image

TCP/IP

A

Application

CF

"Hosting Stack"

DVIPA

192.168.1.1

"Hosting Stack"

DVIPA

192.168.1.1???

DNS

www.mycorp.com =

192.168.1.1

This picture is showing DVIPA and Sysplex Distributor working in concert

This can be failure of adapter on LPAR or failure of LPAR itself

No change as seen to "the outside world"The IP address of host name is the same; only the adapter hosting IP address changes

Sysplex Distributor function the same as shown on previous pageBut the "hosting stack" moves to the one defined as backup

Defining what ports to distribute ...

DVIPA is technically separate from Sysplex Distributor, but the function it provides is important enoughto include in this presentation alongside Sysplex Distributor. DVIPA has been a feature of TCP sinceOS/390 V2R8, so it pre-dates Sysplex Distributor by two releases. What it does is provide a way for anIP address to move between adapters in the event there's a failure.

The key to this is that the DNS is entirely unaware of the move -- the DNS continues to resolve thehost name to the IP address. What's changed is that the IP address moves from one physical adapterto another, either within the same LPAR or (as shown above) to a new system in the Sysplex. Users inthe world do not see the move.

What the picture above illustrates is DVIPA working in concert with Sysplex Distributor. In this caselet's assume that the LPAR in the upper left of the picture hosted the DVIPA and the SysplexDistributor "hosting stack" function. That LPAR suffers a failure. The other TCP stacks in the Sysplexbecome aware of the outage and immediately take over the Sysplex Distributor function and the DVIPAhosting responsibilities. Routing to the applications then continues, just as it did before.



VipaDistribute -- Defining Ports

In order for Sysplex Distributor to know that a given request is eligible for distribution, you must define the ports to TCPMore on this issue can be found in the WP100653 white paper on Techdocs

VipaDynamic

:

VipaDistribute 9.82.25.13 port 9080 9081 DESTIP ALL

:

ENDVipaDynamic

DVIPA on which incoming requests are received

Ports to be distributed. These would be the WebSphere HTTP ports

DESTIP ALL indicates which IP stacks in the Sysplex are candiates. "ALL" means just that.

If only one instance of port open -- traffic

routed there

If multiple (cluster), then traffic distributed

between them

Environment awareness ...

Two points:

If request doesn't come in on the DVIPA address, it won't get distributed. Pointing browser directly at the server HTTP port bypasses Sysplex Distributor

Depending on WebSphere design, more than just HTTP ports will be defined here

There's one last piece to this puzzle ... particularly as it relates to WebSphere Application Server. Weneed to tell Sysplex Distributor which ports to distribute. This is done with the "VipaDistribute" in theTCP profile member.

The format of the statement is really fairly simple:

� VipaDistribute -- is the keyword that tells Sysplex Distributor that what follows defines the ports to bedistributed

� The IP address -- this is the IP address assigned ot the DVIPA. It's possible to have multiple DVIPAs so it'snecessary to tell Sysplex Distributor which one.

� port -- another keyword

� Ports -- the list of ports to be distributed

� DESTIP ALL -- a keyword phrase that tells Sysplex Distributor that all TCP stacks in the Sysplex are eligiblefor receiving the distribution

It's possible you have more than two ports to define here. In fact, there are cases where you want todefine more than just the HTTP ports. You should look at the WP100653 white paper on Techdocs(www.ibm.com/support/techdocs) to see what that's all about. In a nutshell, Sysplex Distributor canplay a useful role in enabling the DMGR to be restartable on other MVS images; it can be useful for theDaemon ports, and it can be useful for the Node Agent ports as well.



Environment Awareness

Sysplex Distributor is very "environment aware" -- it relies on WLM to understand which eligible target is best to route to:

MVS Image

TCP/IP

Application

MVS Image

TCP/IP

Application

MVS Image

TCP/IP

Application

MVS Image

TCP/IP

Application

CF

???

WLM WLM

WLM WLM

WLM is aware of the of how each system is capable of meeting the defined goals

The metrics captured by WLM are fed back to the TCP stack hosting the distributor

When two or more TCP stacks are eligible for distribution, a real-time decision is made where to route the request

Two comments:

WLM awareness is at system and address space level; it has no knowledge of application state within a WebSphere address spaceSo it's possible if application down in server that SD will still route there

Sysplex Distributor is not "session aware" -- if session objects in use, SD will "break affinity"There's a way to place affinity device between SD and WebSphere ... more coming

Summary chart ...

One of the key things Sysplex Distributor provides is a high degree of environmental awareness; thatis, it is tightly integrated with WLM and is aware of the operating conditions on each of the systems inthe Sysplex. WLM metrics are fed back to the hosting stack and routing decisions are made based onthose metrics and the WLM goals that have been defined. When Sysplex Distributor has theopportunity to route a request to more than one location, it makes a real-time decision based on theinformation it has.

Now we come to a point where we can contrast this with other options, based on what SysplexDistributor can't do:

� It has no awareness of the state of the application within the application server. If the port isbound, it assumes there's something on the other side of that port to handle the request. That maynot be the case -- an application server can be up but the application in that server can be down.Sysplex Distributor has no awareness of that.

� Sysplex Distributor has no ability to do session routing. But that's not to say SD plays no role whensession objects are in play -- it is possible to use SD in concert with other options to provide robustload balancing and session routing. More on that later.



Comparison Criteria

Load balancing capabilities

Awareness of Environment

DMZ Friendliness

Ability to Configure for High Availability

Caching / Edge Serving

Platform Applicability

Affinity Routing

Very good -- dynamic based on WLM goals

Not really -- would require stretching Parallel Sysplex into DMZ

None

None

WLM aware, but not aware of J2EE application status inside WebSphere

Inherent in the design of Parallel Sysplex, DVIPA and Sysplex Distributor

z/OS only; Parallel Sysplex only

We'll have side-by-side comparisons of all the options

at end of presentation

Here's our first summary chart, assessing the capabilities of Sysplex Distributor against the criteria weestablished earlier. At the end of the presentation we'll have a side-by-side chart showing the relativecapabilities of each option.

The key thing about Sysplex Distributor is that it can't maintain session affinity. It's excellent at HA andenvironment awareness, but any affinity requirements will go unmet.



The WebSphere "Plugin"

Is something shipped with WebSphere. It's called a "plugin" because it runs inside an HTTP Server -- either on z/OS or off:IBM HTTP Server, or OEM such as Apache, IIS on distributed

WebSphere Plugin Code

IBM HTTP Server

z/OS


HTTP ServerIBM, Apache, IIS

Distributed

HTTP

HTTP

HTTP

HTTP

The plugin was originally delivered as a way to provide "session affinity routing" to Websphere clusters.

OR

How it works ...

The "WebSphere Plugin" is called that because it is code that is designed to run inside the HTTPserver as a "plugin." The Plugin code is shipped with WebSphere Application Server and it runs insidethe HTTP servers on z/OS and off, in IBM HTTP Servers and in several non-IBM HTTP Servers.

The Plugin was originally developed and shipped to provide a way to maintain session affinity back toclusters in a WebSphere runtime environment. There was no other tool capable of it at the time, anddeveloping a plugin to the HTTP server was a quick and effective way to accomplish the objective.



How it Works

There are two levels to this: 1) passing request to Plugin, 2) having Plugin know what to do with the request

Pass to Plugin?

Webserver

Handle as standard HTTP traffic (HTML,

static content)

plugin-cfg.xml

Plugin Functionality

Plugin

This decision depends on platform:

z/OS - based on Service directive

in httpd.conf file

Distributed - web server reads plugin-cfg.xml

and determines what needs to be passed to plugin

Service of static content by web server is example

of "edge serving"

plugin-cfg.xml file

has information about backend servers and where to route each application request

The plugin-cfg.xml file is generated by WebSphere on

z/OS ... then can be used by webserver -- on or off z/OS(see PRS1467 on ibm.com/support/techdocs for more)

Session affinity routing ...

The plugin operates on a fairly simple concept:

� Inbound requests received by the HTTP server are evaluated to see if they're eligible for handlingby the plugin. Those that are to be handled by the plugin are passed to the plugin; those that areto be handled by the HTTP Server are not passed in. How this is accomplished is done in slightlydifferent ways, depending on whether the HTTP Server is on z/OS or on a distributed box. But theconcept is the same.

� Once the request is in the plugin, the plugin then evaluates what to do with the request. This isdone based on definitions coded in the primary plugin configuration file, called theplugin-cfg.xml file. This file has information about the servers and applications that are in the

backend WebSphere runtime environment.

Where does that file come from? The Deployment Manager has a function in its Admin Console togenerate it.

???

� The request is then sent back to the server. If a session object exists, then the request is sent tothe server where the session object resides.

How is that routing decision made? Let's see that next ...



How Affinity Routing Performed

<ServerCluster Name="Cluster_1">

<Server CloneID="BCED40CEE76AB3CA000001A80000000309521847" Name="Server_A">

<Transport Hostname="www.systema.com" Port="9080" Protocol="http"/> </Transport>

</Server>

<Server CloneID="BCED4CAD866CFF1C000001A80000000309521847" Name="Server_B"">

<Transport Hostname="www.systemb.com" Port="9081" Protocol="http"/> </Transport>

</Server>

</ServerCluster>

plugin-cfg.xml

Plugin Functionality

Plugin Appl Fred

www.systema.com"Fred"

Appl

www.systemb.com

9080

9081

CloneID="BCED40CEE7...

Simplified view of things

Server_A

Server_B

Server_A

Server_B

If no JSESSIONID (initial request, or no session objects), then round-robin

When session object created, a cookieNote flows back to browser. Future requests flow with cookie, telling Plugin where to route back to:

Note: other methods possible -- URL rewriting or SSL ID

What we'll show here is a glimpse into how the plugin-cfg.xml file is coded so the Plugin itself can

respond to the need to route based on session affinity. The key to understanding this is to understandwhat happens when an application builds a session object for a user. When that happens, the"session manager" component of WebSphere updates the HTTP header of the response flow andinserts a cookie -- by default a JSESSIONID cookie -- that contains a 40-character hex string thatrepresents the "unique ID" of the server in which the session object was created. That cookie flowsback to the browser.

Now, when the user ("Fred" in this example) clicks something that results in a return flow toWebSphere, the browser will include the cookie in the HTTP header of the return. The Plugin is ableto read the presence of that cookie -- which is the key to the Plugin's ability to do session affinityrouting.

The plugin-cfg.xml file contains information about each server that's in the WebSphere runtime.

The XML file has information on each server's "unique ID," which is exactly what's included in theJSESSIONID cookie. The Plugin simply compares the contents of the cookie against the definitions inthe XML file and then routes the request to the server with the same unique ID. If no affinity cookie ispresent, then the Plugin simply round-robins to the next available server.

That's the basics. There's a great deal more detail behind all that, of course, but that gives you theessence of it.



Multiple Plugins Permitted

It's quite possible to configure multiple plugins and have both running ... they then act as peers. May use the same plugin-cfg.xml file.This done for high availability / avoid single point of failure

Quite possibly you do. This is where combinations of tools may be desired. We'll cover that later.

(Hint: Sysplex Distributor out front of Plugins on z/OS)


IBM HTTP Server


IBM HTTP Server

plugin-cfg.xml

???

Question pops up: do you then need

something out front of the dual Plugins?

Summary chart ...

A lot of people see the single Plugin and worry about "single point of failure." It turns out that it's quitepossible to configure up multiple HTTP Servers, each running the Plugin and each operating with thesame copy of the plugin-cfg.xml file. When configured that way, the two (or more) Plugins act as

peers to one another -- operating somewhat independently though from the same configuration source.There is no "automatic takover" capability or other sophisticated stuff, but it does eliminate the singlepoint of failure concern.

With two HTTP Servers it then becomes necessary to have something else out front handling therequests and then balancing between the two HTTP Servers. What might that be? Well, SysplexDistributor is a very good choice ... and we'll show an example of that later.



Comparison Criteria



DMZ Friendliness



Affinity Routing

Round robin or static weighting; no dynamic

Good -- forwards HTTP only to known ports (easier to configure firewalls)

If z/OS, can be non-Sysplex LPAR; if distributed can server fully in DMZ

Pretty good edge serving device. Memory caching of local content, but not content served up by backend application server.

Yes -- original purpose of Plugin

Plugin checks server availability, but not aware of status of application or whether its routing choice is good based on other activity on system

z/OS and distributed; IBM HTTP Server plus others (Apache, IIS, etc.)


Yes, configure multiple; they serve as peers

The summary chart for the HTTP Server with the Plugin. Key points:

� Primary purpose is session affinity routing

� Is a pretty good DMZ device

� Load balancing is fairly simplistic without much awareness of backend environment other thanwhether server is up.

� The HTTP Server -- particularly on z/OS -- does an excellent job of edge serving of static content.However, the Plugin is not able to cache content that is initially dynamic in nature like the Proxy andODR can.



WebSphere V6 Proxy Server



What Proxy Server Is

The "Proxy Server" is a special-function application server. It was introduced with V6.0.2 maintenance. It is a "WebSphere-aware" proxy, with knowledge of applications and their status.

Key points:

From address space perspective, looks/acts just like a normal application serverController and servant; JCL procs just like appserver; RACF profiles in support are exactly the same; naming convention issues the same; similar port structure but proxy has 2 more

It's part of a managed node structureSo there's a node agent that supports it

It is enabled with augmentProxyServer.sh

shell scriptFound in /profiles/default/bin directory

This updates the profile so Admin Console is then able to configure it.

In V6.1 shell script not needed; function part of product as delivered

It is configured through the Admin ConsoleUnder "Servers"

Similar to configuring standard AppServer

Once configured, there's more "Proxy Server" customization you then may do

DMGR

CR SR

Node Agent

CR

AppServer

CR SR

Node Agent

CR

Proxy Svr

CR

What's the value of configuring this?

The "Proxy Server" came out as new function in the V6.0.2 maintenance release. The intent was toprovide a server that was capable of being a more intelligent front-end "proxy" than HTTP Server +Plugin structure was capable of. To accomplish this, the designers of WebSphere piggybacked on thestandard control region structure and provide additional function that ran inside that control region. Sofrom an MVS perspective, the Proxy Server looks like a single control region structure.

The Proxy is not capable of supporting a servant region.Note:

A Proxy Server will always be part of a managed node, which means there will always be a Node Agentsupporting it. This factors into the Proxy not being very DMZ friendly because the node in which theProxy resides will have a lot of WebSphere management traffic flowing to and from it. Putting theProxy in the DMZ implies configuring the secure-side firewall to allow a lot more than merely HTTPtraffic.

The way the function is enabled is with a shell script that found in the /profiles/default/bin directory afterthe 6.0.2 maintenance is applied. This shell script updates the default profile so the Admin Console iscapable of understanding the new Proxy Server. This allows the Admin Console to create and managea Proxy Server. Configuring a Proxy Server is pretty much the same as configuring a standardapplication server.

There must be some reason to configure this ... what extra does the Proxy Server bring to the table?



What Proxy Server Provides

The Proxy Server is a step forward in the "On Demand Configuration" strategy ... Extended Deployment takes it further.(More on Extended Deployment when we talk about ODR)

Highlights:

Automatic discovery of applications in WebSphere cellOut of the box capability

No configuration XML file like the Plugin

No need to "regenerate" the Proxy's awareness with new apps like Plugin requires

WLM-assisted routingRouting is not simply round-robin but based on metrics supplied by WLM on z/OS

Session awareness and affinity routingOut of the box capability

Knows about status of application in individual cluster member servers

If "Domain Replication" is enabled (memory to memory copying of session objects), Proxy is aware of what objects are where, so proper affinity routing takes place automatically.

Static content and dynamic content object caching"Static" -- standard HTML or image files

"Dynamic" -- generated content by appserver; appserver coordinates with proxy about what to cache, how long to keep it cached, and when to refresh it.

Ability to route to other cells or to non-WebSphereOther cells -- requires configuring "core group bridges" to the other cells

Non-Websphere -- things like image servers, or other HTTP Servers

You get the picture -- a more dynamic, environment-aware frontend device

Note about DMZ friendliness...

The Proxy Server was the first step in the development of a more "On Demand" type configurationstrategy. The Extended Deployment product takes it even further. Highlights of the Proxy Server areprovided on the chart. The key is what's highlighted in yellow -- the Proxy Server is a far more awareof its environment than is the HTTP Server with the Plugin.



DMZ Friendliness

Because the Proxy Server is part of a managed node, the communication flows between it and rest of cell are varied and complex ... lots of ports, lots of protocols:

DMGR

CR SR

Node Agent

CR

AppServer

CR SR

Node Agent

CR

Proxy Svr

CR SR

Cell boundary

Configuring firewall to allow all this traffic and still be certain of security is a challenge

Not impossible, but something most firewall administrators wish to avoid

General undestanding: Proxy is not very

DMZ-friendly ... today

Solution: use it in combination ...

Well understood requirement to address that.

Look for improvements

over time

One of the Proxy Server's shortcomings is that it's not very DMZ friendly. This is because the ProxyServer is part of a managed node, and as such there is a fair amount of WebSphere managementtraffic that flows back and forth. To open up the firewall on the back side of the DMZ would entailopening up more ports and protocols than merely HTTP. It's not impossible, but it's something mostsecurity administrators would be wary of.

This "DMZ unfriendliness" is a well-understood shortcoming and there are active efforts underwayto address it. Look for improvements over time. Please do not consider it to be a insurmountableissue ... it's just a question of time.

Important!

What if you really like the function of the Proxy but don't want to put it in the DMZ. What can you do?Use it in combination with other things ...



Combination Configurations

Proxy can be used with other front-end devices -- blend DMZ friendliness of one with dynamic nature of Proxy:

We'll explore other variations on blended approaches in separate section

DMGR

CR SR

Node Agent

CR

AppServer

CR SR

Node Agent

CR

Proxy Svr

CR SR

Cell boundary

Other HTTP Handler

(i.e. Plugin)

Unsecure network

Secure Network

DMZ

Summary chart ...

Get all the benefits of Proxy despite DMZ

unfriendliness

There's nothing that says that some other front-end device can't feed the Proxy Server. So you coulduse something else out in the DMZ, such as the HTTP Server and the Plugin, or perhaps some IPforwarding device, to feed the Proxy Server in the secure network. The intra-cell management trafficthat occurs there would be entirely within the secure network, so worries about poking holes in theDMZ firewall don't apply.

Yes, doing this introduces additional handling and code path. It comes down to weighing those "costs"against the benefits of the network design where a DMZ is employed.



Comparison Criteria



DMZ Friendliness



Affinity Routing

Very good -- dynamic based on WLM goals

Not really at present -- full range of WebSphere ports; implies stretching WebSphere cell out into DMZ. To be addressed in future enhancements.

Capable of caching content served up by backend application servers.

Yes

WLM aware and aware of WebSphere server and application status

WebSphere only; can be on a distributed box but that implies definition of core group bridges (complexity)



Summary chart. Key points:

� Much more dynamic and much more aware.

� Better caching capabilities

� Better environmental awareness.



WebSphere XD

On Demand Router



WebSphere Extended Deployment

First, a quick overview of what WebSphere Extended Deployment is and what features it offers. Then we'll talk about the ODR.

WebSphere Application Server V6 for z/OS

WebSphere Extended Deployment Extended Deployment is function added to WebSphere:

Separate FMID, separate license, separate SMP/E install

Utilities run to integrate XD into WebSphere for z/OS configurationAdditional symlinks added to configuration to link to XD HFS

Quick summary of key features and functions:

On Demand Router -- see that next

Dynamic clustersXD can start/stop servers based on workload presented

Long running application supportA form of "J2EE batch" to run applications that are more batch than OLTP

Application editions and versioningA way to roll in new code updates in a more controlled fashion

Application partitioningA way to split up applications so portion of presented work done on one server, rest done on other servers

Object cachingDesigned to reduce non-productive data source calls

Repository checkpointsA way to "undo" a configuration change and fall back to a known-good configuration

The ODR ...

Reason why XD is separate. Not all people need all this function.

First, let's explore what WebSphere "Extended Deployment" is: it is a separate set of function that isadded to WebSphere Application Server to "extend" (hence the name) the functionality of WebSphere.The product comes packaged as a separate FMID, requires a separate license, and involves aseparate SMP/E installation from WebSphere Application Server. There is a simple set of utilitiesthat's run to "augment" an existing WebSphere configuration to recognize and use the XD functionality.

Why separate packaging like this? Because IBM recognized not everyone would have need for thisadvanced functionality. It is an optional "add on" to WebSphere.

???

The chart provides a quick bullet list of the things XD provides. For our purposes we'll be discussingthe "On Demand Router," which can be thought of as like an enhanced Proxy Server. But even thatdescription doesn't do justice to the function of the ODR.



On Demand Router

In one sense it's very similar to the Proxy Server. But it's really a superset of the Proxy functionality:

Trading

Acct Mgt

e-mail Statement

C P RClassify Prioritize

and Flow Control

Load Balance

and Route

On Demand Router (ODR)

CR SR

AppServer

CR SR

AppServer

CR SR

AppServer

WLM metrics

TC classification

Similar to Proxy:Looks like an application server (CR, SR, etc.)

Part of cell, managed node

Out of the box auto-detect of apps, session routing, WLM-aware load balancing

Different:Far more integrated into autonomic design of Extended Deployment

Ability classify and prioritize, queue requests, start/stop servers, intelligently manage mixed workloads

Summary chart ...= function above/beyond Proxy

The On Demand Router is a super-set of the function found in the Proxy Server. It has everything theProxy Server has an more.

In one sense it's like the Proxy Server in that it has a structure like an application server, which acontroller region and some number of servant regions. It's part of a managed node, so it is supportedby a Node Agent. And like the Proxy Server, the initial configuration is relatively simple and providessome very good basic functionality, such as the auto-detection of applications in the backend servers,automatic session routing, and awareness of the environment based on WLM metrics.

But the ODR is designed to provide more ... it is designed to treat inbound traffic as potentiallysegmented by priority. That's merely a reflection of reality, where traffic commonly is of differingpriorties. What the ODR can do -- with the proper post-installation configuration; in other words, this iswhere you must customize it -- is the ODR can classify the inbound work and place the work indifferent queues. It can then prioritize based on your customization, and flow the work to the backendservers in priority order.

There are sophisticated algorithms to make sure low priority work doesn't get "lost" behind high prioritytraffic.

Note:

A final thing the ODR can do is flow Transaction Class information back to WLM. In other words, theODR can make the classification and alert WLM to classification of specific workload. In summary,what the ODR provides is an advanced function front-end prioritization and classification engine forinbound work.



Comparison Criteria



DMZ Friendliness



Affinity Routing

Excellent

Yes

Excellent



Not really at present -- full range of WebSphere ports; implies stretching WebSphere cell out into DMZ. To be addressed in future enhancements.

Capable of caching content served up by backend application servers

WebSphere only; can be on a distributed box but that implies definition of core group bridges (complexity)

Similar words used here as ProxyBut ODR and XD addresses issues well

beyond merely HTTP handling

Here is the summary chart for the ODR, and as you can see the words on the page are similar to thoseoffered for the Proxy Server. But the big yellow blurb warns us not to think that the ODR and Proxy arethe same thing -- the ODR is much more. What the chart above is doing is evaluating the ODR as afront-end device against the criteria we established earlier. And based on that criteria, the ODR issimilar to the Proxy.



Combinations

In this section we'll illustrate a few examples of how the options we've looked at can be done incombination with one another.



Distributed Box in DMZ

If an objective is to keep zSeries out of the DMZ and put only DMZ-friendly devices out there, then you can do the following:

WebSphere for z/OS

WebSphere Plugin

(Distributed)

Other IP Sprayer

WebSphere Plugin

(Distributed)

WebSphere Plugin

(Distributed)

WebSphere for z/OS

Or some other IP handler

Key here is that if you have a directive to keep

mainframe out of the DMZ, you have many

options

Including options we've not discussed here, such as Tivoli Access Manager or

other edge devices.

Sysplex Distributor ...

Some have as an objective the requirement to have only distributed (non-z/OS) boxes out in the DMZ.If that's the case, then the easiest thing would be to place a distributed box HTTP Server with theplugin out in the DMZ, and configuring the secure-network firewall to allow only traffic from that devicethrough. And if there's a concern about a "single point of failure" with the Plugin box, you canconfigure up multiple such boxes, acting as peers, and have some other form of load-balancing IPsprayer out front of that.

What about configuring a Proxy Server or ODR on a distributed box, but part of the same WebSpherecell as the z/OS platform? That would be an example of a "heterogeneous" cell. That's technicallypossible, but it involves configuring an advanced function known as a "core group bridge," and it wouldinvolve configuring the firewall to allow a good deal of WebSphere management traffic. It's feasible, butnot as easy as what's illustrated above.

Note:



Front-Ending with Sysplex Distributor

It's important to understand that on z/OS, it's possible to use Sysplex Distributor out front of the other options to provide high availability:

Sysplex Distributor

(DVIPA)

DMZ Device

Plugin, Proxy or

ODR

Plugin, Proxy or

ODR

CR SR

AppServer

CR SR

AppServer

CR SR

AppServer

Key points:

z/OS function entirely within secure network

Still possible to make use of distributed edge devices in DMZ to feed Sysplex Distributor

Configure multiple Plugin, Proxy or ODR for high availability

Dynamic load balancing by Sysplex Distributor

Session affinity offered by Plugin, Proxy or ODR preserved

Final side-by-side comparision chart ...

We've alluded to this combination several times before ... the use of Sysplex Distributor out front ofmultiple z/OS-based Plugins, Proxies or ODRs. This would keep all the z/OS function entirely behindthe secure network firewall, it would still allow the use of some distributed box out in the DMZ, it wouldtake advantage of Sysplex Distributor's environment-awareness for intelligent load balancing betweenthe devices, and any session affinity requirements would be preserved because the last thing to handlethe traffic would be devices capable of affinity routing.



Side-by-Side Comparison



DMZ Friendliness

High Availability



Affinity Routing

Advanced Features

HTTP + P

lugin

WebSphere

Pro

xy

XD ODR

Sysplex

Distributo

r

"Simplicity / Low-overhead"

Note: somewhat subjectiveRelative rankings open to discussion and debate; notes explain some of the ratings

1

2

3

4

5

6

Here is the side-by-side comparison chart we promised earlier. It uses the same evaluation criterialdown the left side of the chart as was used before. The four options we've discussed are across thetop. The number of stars indicates the relative strength of the option for the particular criteria; one starbeing "relatively weak" and four stars being "relatively strong."

There is ample opportunity for debate about the number of stars given for some option. This chart issomewhat subjective.

Warning:

The numbered blocks point to explanations offered here to explain why a certain rating was given.

1. The ODR was given the high rating for "load balancing capabilities" simply because it has the abilityto classify and prioritize work. It also has balancing capabilities not discussed in this presentation.It truly is a very powerful piece of functionality.

2. The Proxy and ODR have been deemed "DMZ un-friendly" here, but as stated in the charts this is apoint-in-time thing. It is something that is understood to be an issue and will be addressed overtime.

3. Some might wonder why Sysplex Distributor is not equal to or better than the Proxy or ODR for"awareness of environment." I made the Proxy and ODR relatively better than Sysplex Distributorsimply because Sysplex Distributor has no awareness of the state of the application within theapplication server; only the status of the application server address space itself. I gave the ODRthe highest rating because it's not only being fed WLM metrics (like Sysplex Distributor and Proxy),but it's also capable of detecting things like backend data store outages. (It doesn't directly detecta DB2 outage, for example, but algorithms within the ODR deduce such things and avoid sendingwork to servers where backend outages have occurred.)



4. I gave Sysplex Distributor the highest rating for "High Availability" because it's a function that's sodeeply part of the Parallel Sysplex environment. It's proven and it's simply part of the knownadvantages of Parallel Sysplex. The other options can be made highly available by way ofconfiguring multiples of the server, but in general the way to really make them HA is to use SysplexDistributor along with the multiple instances.

5. For "Platform Applicability" I gave the nod to the HTTP Server and Plugin because that runs onpretty much every platform, and in HTTP servers that aren't IBM's. Sysplex Distributor is onlyapplicable to z/OS (and only to a Parallel Sysplex), so that got only one star.

6. "Simplicity / Low Overhead" is a new criteria introduced on this chart only. It is a terribly subjectiveevaluation and will no doubt elicit all sorts of argument. Here I gave the nod to Sysplex Distributoreven though there are literally reams of books dedicated to configuring and exploiting SysplexDistributor. It is rated the highest primarily because it comes with z/OS Communication Server andis highly optimized. The Proxy and ODR are the lowest rated because in terms of raw throughput itprobably (I have no performance studies to fall back on) does not pump the requests as fast aswould Sysplex Distributor. But then again, when the ODR is configured to do all the classificationand prioritization, it's doing a whole lot more than Sysplex Distributor is doing.



For More Information ...

Sysplex DistributorPRS789 presentation on ibm.com/support/techdocs

Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 3SG24-7171 on ibm.com/redbooks

TCP/IP in a SysplexSG24-5235 on ibm.com/redbooks

WebSphere HTTP PluginPRS1467 presentation on ibm.com/support/techdocs

XD white paper

WP100735 white paper on ibm.com/support/techdocs

InfoCenterhttp://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp

This presentation has only skimmed the surface of these front-end handler options. For any serioususe of them you'll need to go deeper. This chart shows where you can get more information.



End of PRS2663



comparing some of the http front-end options...this presentation is aimed at about the half-way...

Documents