Friday Sep 25, 2009

How Does Sailfin (Sun GlassFish Communications Server) SIP Session Replication Module Select Replica Instances?

For scalable deployments of middleware with high availability, employing a session state persistence approach to persist session state to all instances in the cluster could be a sub-optimal solution. Replicating sessions to all instances in the cluster would result in significantly higher network traffic just for replicating state reducing bandwidth for growing application user requests. This approach of sharing sessions across all instances perhaps is suited for small clusters with limited number of concurrent requests.

One of the better approaches to use to secure scaling advantages is the approach of buddy replication. In this approach, each instance selects one (or more) other instance(s) in the cluster to replicate any and all of its sessions. This is a superior approach and in fact, works for fairly large deployments. There are factors to consider here, in terms of the overhead the replication subsystem will need to handle at the cost of performance particularly when large number of concurrent sessions are being processed and later expired. An overhead to consider is the need for instances to form ring-like replica partnerships based on a certain order in which buddies would be available and selected. When a buddy instance fails, there is the cost of re-adjusting and forming new buddy relationship with another surviving instance, and when the original buddy recovers, to re-adjust again to use this upcoming instance as a replica partner by one of the instances in the cluster. Think of this as a chain based ring with its links randomly being removed but with the consistent goal of retaining a connected chain ring with the overhead of relinking each time a link is removed or added or a new one added to the chain.

There is also cost to be considered (if such were the design approach), each time the cluster shape changes for dynamically changing/updating any cookie information pertaining to replica locations that could be sent back as part of the response headers to the LB - typically that cost should also be avoided through more efficient means.

In the case of GlassFish, we have fairly successfully used buddy replication with each instance having a single replica buddy. We use the approach of locating sessions in the cluster when a request is directed by the LB to any random instance when a failure of an instance that was processing requests occurs. This has worked well for reasonably large mission critical environments where the scalability and availability requirements are within the boundaries of this approach.

In Sailfin 2.0, scaling and reliability needs for telco applications is typically very high and we needed a scalable approach to ensure Sip Session Replication overhead sustained good performance with the added reliability and availability. We, therefore, used a consistent hashing algorithm to dynamically assign a replica instance for each new session. This we did by leveraging the consistent hashing mechanism that the Sailfin Converged Load Balancer (CLB) uses for proxying requests to a target instance using a BEKey. In the case of replication, the same logic of using a hashed key for the target instance assignment is taken a bit further.

For replica selection, for each new session, we pre-calculate the most likely target instance that the CLB would failover to, if the current target primary instance that would serve the session, were to fail in future. This gives us the instance to which, the current primary instance, should replicate to. This gave us significant benefits in that there were no client cookie updates required to include replica partner information dynamically. There was no readjustment of replica partnerships needed when a particular instance failed as the hashing algorithm would provide another instance to replicate to with just an API call. When the failed instance comes back into the cluster, the sessions that were owned by it in its prior incarnation that are unexpired, would migrate back to it to maintain a balanced set of sessions across the cluster. And the replica selection algorithm would assign the original failover instance for this primary, as the replication partner.

Since this is based on a hashed selection algorithm with predetermined failover target, replica selection is dynamic, and does not need the knowledge of a particular order of instances being ready in the cluster to point all sessions from another instance as a replication partner. And more importantly, as the failover occurs to the specifc instance where replica data is located, there is significantly less network overhead to locate any particular session in the cluster when a particular request within the session scope is sent to the CLB. This allows for more bandwidth being available for a larger number of user sessions to be served. This approach is thus superior to the buddy replication approach and helped us scale to higher throughput and sustain a larger number of long running sessions.

It must be emphasized here that system level, and application server level tuning, and sizing are essential to ensure sustained performance, scalability and reliability in addition to the improvements provided with the SSR replication scheme and other parts of the Sailfin v2 server (aka Sun GlassFish Communications Server 2.0) .

As always, we welcome your feedback and encourage you to try Sailfin and send us any inputs and questions you may have in this respect.

Sailfin Promoted Builds are available here : Sailfin Downloads


Thursday Sep 17, 2009

Project Shoal releases Shoal 1.1 Final Release

Project Shoal is announcing the release of Shoal 1.1 FCS today.  This is the third release after Shoal 1.0 and 1.0 Update Release. 

During the long time we have been working on this release, the Shoal team has accomplished many new features, and fixed many bugs providing significantly higher stability and reliability with the clustering core. A majority of the features and bug fixes were driven by the intense requirements coming out of the Telco grade application server from Project Sailfin (Sun GlassFish Communications Server) and Project GlassFish (Sun GlassFish Enterprise Server). 

Some of the highlights of this release are :

  • New event notification signal for JoinedAndReady members - applications using Shoal can call an API to report to other members that at the application level, the member is ready to begin operations - this distinguishes the member joining the group from the actual readiness of the application to start operations. 
  • New event notification signal for Group Leader changes - anytime a group leader leaves or fails, another group leader is selected and this signal allows Shoal GMS clients to be notified of this change to take any remedial actions. 
  • New health states Ready and AliveAndReady in the HealthMonitor member lifecycle state transitions to make it more closer to the finite state machine
  • Introduce capability to distinguish between group startup and individual instance startup in JOIN and JOINEDANDREADY notifications. Applications may benefit knowing whether only a single GMS member is starting vs all GMS members of the GROUP are starting at once.
  • Support for notifying failure within a specific threshold time when the failure is due to a network issue or a hardware end point failure. Blocking TCP health check connections would timeout in (default) 10 secs allowing for quicker detection of failure compared to default system settings for TCP Retransmission timeouts.
  • A new GMS Watchdog Failure Notification API to be used by external service management frameworks (i.e. like GlassFish NodeAgent) - This allows external monitoring processes to notify GMS when these external process detects a member process failure faster than GMS heartbeat based detection can assign failures. This feature allows for faster failure detection notifications than the heartbeat based unreachability algorithm can determine failure. The feature was driven by the fact that the GlassFish Node Agent would detect a member process loss faster than Shoal could detect through its heartbeats and restart the failed process, resulting in no failure notifications from Shoal GMS to its clients.  Full write up at document. Glassfish Issue 8308

This version of Shoal is already integrated into GlassFish v2.1.1 and Sailfin v2 both of which are upcoming releases slated for October 2009 end.  

Details of the release announcement are here :

https://shoal.dev.java.net/servlets/NewsItemView?newsItemID=7645

You can download Shoal 1.1 binaries and sources with Javadocs here : https://shoal.dev.java.net/downloadsindex.html

As always, we owe it to you all in the community and thank you for all the feedback and issues you have raised to help us improve. 

Thanks very much and hope to see your feedback continuing !

Sunday Jun 21, 2009

GlassFish Clustering: Meaning and impact of configuring attributes of group-management-service element ?

Based on a query from one of our field colleagues, I added an FAQ entry on the meaning of the group-management-service element attributes  and impact of changing the default values as this is not yet covered by our official documentation (it will be updated with this information soon).

These configurational attributes determine Shoal GMS's behavior with respect to Discovery and Health Monitoring of cluster instances in a GlassFish cluster. It is very useful and important to understand these underpinnings of GlassFish's runtime clustering engine.

Here's the FAQ entry :

http://wiki.glassfish.java.net/Wiki.jsp?page=FaqShoalGMSAttributesInDomainXML

Tuesday Oct 21, 2008

Economic woes resulting in slashed tech budgets? Sun's GlassFish+MySQL makes perfect sense

With signs of a global economic turmoil underway, the financial system is under severe stress with credits vanishing, and Government Departments, small and medium businesses, and large corporations are faced with potential budget cuts for technology spending. Case in point : http://www.msnbc.msn.com/id/27103082/

With Sun's open source "stack" and cost-effective support subscriptions, affected sectors of the economy can take advantage of standards based, high quality, open source software with the low cost support services from Sun. This is a good time to consider moving away from expensive proprietary software stacks to Sun's open source software.

Take the case of Sun's commercially supported GlassFish + MySQL offering, both rock solid products that come with features only available in high cost closed-source products. This offering provides you the opportunity to seamlessly move from expensive licenses to an annual support subscription based offering that will reduce your cost of ownership. For example, Unlimited deployment of GlassFish + MySQL starts at $65,000. GlassFish + MySQL constitutes a very compelling offering that will help you justify the move both on features and costs.

Contact Sun to find out how you can save significantly with this offering.

For more on the value proposition, read Arun's blog entry here.

Tuesday Aug 26, 2008

Shoal 1.1 bits updated for a new promoted build

The Shoal team has been busy addressing the needs of major projects such as Sailfin for a while now. It had been a while since we updated our promoted build for download with the latest and greatest fixes.

We have now promoted a new build for Shoal 1.1 and download bits are available here : https://shoal.dev.java.net/downloadsindex.html

The announcement has more details on what went into this promoted build : 08202008 Promoted Build Announcement

We would welcome your feedback, issue reports and enhancement requests to make Shoal more useful for you.

Do send us your feedback at the Shoal user mailing list.

Friday Apr 18, 2008

New Shoal Clustering Download Page

With a view to helping our users choose the right download, we have organized the Shoal downloads page on the lines of the GlassFish download page. The new download page is located here : https://shoal.dev.java.net/downloadsindex.html

This should make it easier for users to find Shoal bits and use them in their clustering applications.We are seeing increasing interest from users with different types of questions in the Shoal user mailing list ranging from newbie questions to very advanced ones. Keep'em coming folks.

We will be posting new promoted downloads  and releases through this download page. Let us know if you need specific improvements to be made.

 

Friday Jan 11, 2008

GlassFish Hidden Nugget: Automatic Distributed Transaction Recovery Service

GlassFish v2 and v2 ur1 releases (and later) have support for transaction recovery (both manual and automated) in the sense that incomplete transactions at the time of an instance failure can be committed either manually or automatically.

Part of the new feature set in the cluster profile is a little known feature called Automated Distributed Transaction Recovery that comes out of Project Shoal's support for it. 

Essentially, Automatic Distributed Transaction Recovery in GlassFish works as follows :

Consider the following :

  • a cluster of three instances : instance1, instance2, and instance3
  • Two XA resources used by each GlassFish instance
  • a transaction starts on instance 1,
  • Transaction Manager on instance1 asks resource X to pre-commit,
  • Transaction Manager on instance1 asks resource Y to pre-commit,
  • Transaction Manager on instance1 asks resource X to do a commit,

Now, instance1 crashes

The Transaction Service component in one of the surviving members, instance2 and instance3, gets a notification signal that a failure recovery operation needs to be performed for a instance1. This signal from Shoal is called FailureRecoverySignal.

This notification signal comes to the Transaction Service component in only one particular selected instance as a result of a selection algorithm run in Shoal's GMS component that takes advantage of the identically ordered cluster view provided to it by the underlying group communication provider (default provider is Jxta).

The Transaction Service component in this instance, say instance2, would now go into its autorecovery block. It starts by waiting for a designated time (default to 60 seconds) to allow for the failed instance1 to start back up.

If instance1 is starting up, its own Transaction Service component would do self recovery to complete phase 1 transactions.

In instance2, after the wait timeout occurs, the transaction service component would now see if instance1 is part of the group view and if not try to acquire a lock for the failed instance's transaction logs through Shoal's FailureRecoverySignal and if successful (indicating that the failed instance did not startup), acquire the transaction log and start recovery of transactions i.e complete the commit operations for the pre-commit transactions. If the acquisition of the lock fails, then it gives up, and checks that the failed instance did startup through Shoal's group view and logs this fact.


If, during the recovery operations  being performed by instance2, the failed instance1 starts up, the transaction service component in this instance would first check with Shoal if a recovery operation is in progress for its resources by any other instance in the group and if yes, it waits for the recovery operations to be completed and then completes startup. This ability to check for such recovery operations in progress is through a related Shoal feature called Failure Fencing[1].  If there are no recovery operations in progress, then the startup proceeds with a self recovery which recovers any incomplete transactions in instance1's logs.

Now during recovery of instance1's transaction logs, instance2 fails, then the fact that this instance was in the process of recovering for instance1 is known to the remaining members of the group (i.e. instance3) through the failure fencing recovery state recorded in Shoal's Distributed State Cache. As a result, when instance3's transaction service gets the failure recovery signal, not only does it get it for instance2's failure, but also for instance1. This facility covers for cases where cascading failures or multiple failures occur.

Note that, for the automatic distrbuted transaction recovery to work, access to the transaction logs for all instances in the cluster for
purposes of auto recovery requires that the logs be mounted on a shared/mirrored disk[2].


[1] More on Shoal's Automated Delegated Recovery Selection
[2] Distributed Transaction Recovery

 

 

 

Saturday Dec 08, 2007

Excellent Article on Shoal by non-Sun authors

Just came across this excellent introductory article on Shoal clustering framework on Java.net which I believe is to be published on upcoming Tuesday going by the date posted (12/11/2007).

Noticeably, this is an article by authors that we, at the Shoal community, have not yet corresponded with. This is great news as it lets us know that there is a quiet adoption of this framework. The article lucidly explains salient aspects of Shoal's clustering approach and how easy it is to integrate it into your application/infrastructure. 

We hope this will make it even easier for users to adopt this technology.

Do send us your questions at the Shoal users mailing list.


Tuesday Mar 27, 2007

Article on Introducing PetStore 2.0

Blueprints team members Inderjeet Singh, Mark Basler and Sean Brydon recently teamed up with Sun staff writer Dana Nourie  for an article Introducing the Java PetStore 2.0 Application.

There is a lot of interest among Java developers to learn how next generation dynamic web technologies such as Ajax can be put to use in Java EE applications that deploy in an enterprise setting. The article has been very popular and generated many thousands of hits since publication a couple of weeks ago. The PetStore Blueprint application's value proposition to developers is to show how one can use Web 2.0 technologies with end-to-end Java EE apps. 

The Blueprints project provides many such learning artifacts. A great way to learn more in this space is the Blueprints Solutions Catalog which is now hosted live with a view app at our web application developers' page. The viewer app is itself a Web 2.0 app and provides content organized into useful categories.  See more Web 2.0 samples here.

The Blueprints apps have been tested with various releases and builds of GlassFish. The Java EE SDK includes Blueprints apps so that is the easiest way to get both the GlassFish application server and the above applications in one download.


 

About

Shreedhar Ganapathy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today