Virtualized applications: An end to sluggish app performance

Hal Stern, CTO, Sun Services

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Web site reliability Electronic messaging growth Controlling server sprawl Sluggish applications

Hal Stern, CTO, Sun Services

Business problem: A financial services firm has based its identity management processes on a large, consolidated directory of user information. Each user - employees and customers - has multiple roles, and the directory includes application entitlement information on each. The directory maintains a "trust" model, in which it exerts authorization control for the firm's applications. It authenticates on a per-URL basis, meaning that every time a user accesses an application via a URL, the user is authenticated. (This ensures that applications accessed via bookmarks are authenticated on each access.)

For applications that run in the same data center as the directory, this works well; the directory need only send its authorization request across a local network, tapping the memory-resident cache on a local server. But add in two cross-country network hops, a few router or firewall transits from a far-flung remote user, and the firm's security enforcement has slowed to a crawl (the rate of a disk access per request). Users have begun to complain about the network's sluggish performance. IT administrators also have summarily blamed the network.

Traditional approach: Replicate the directory to each data center so each application need go no further than the local copy for authentication. Yet this approach introduces a number of operational risks. For starters, your directory server deployment has increased from one in one location to one or more per data center, each requiring security, availability and performance monitoring. You lose the flexibility to modify the directory when you are saddled with such a heavy foundation.

Plus, ensuring the consistency of all directories means watching network latency and transaction completion, and running consistency checks. Missed replication updates create confusion at best and regulation violations at worst. In the long run, replication actually slows down everything. Every time a record changes, this system generates network traffic while the directories synchronize - you have created latency (as you are now doing the equivalent of an N-phase commit over N data centers).

New data center approach: For this directory performance problem, think about the directory in virtual terms first and then map those terms to physical instances.

Specifically, separate the directory into subtrees, so that each subtree is closest (or co-resident) to the applications whose users consume that data most frequently. For instance, if most of your California users access Web-based applications through a Web server farm in the Los Angeles data center, then directory entries for those users should be located there. Each directory typically would have entitlements for all applications, but not for all of those application users.

When applications need to bind to the directory, steer these binding requests to the "best" directory instance using a directory router or a Layer 7 switch that can inspect Lightweight Directory Access Protocol requests. So rather than first building a data center and then networking it, look at your IT design as a large, Internet-like structure "inside" the data center, and then you can use more appropriate technologies to solve the routing problem. (Layer 7 switches are likely to become critical elements of the new data center, useful for routing Web services requests, partitioning databases or directories, or even sorting traffic by service to corral certain user loads.)