main website home
  • About this blog

    This blog features updates, opinions, and technical notes from Caucho engineers about Caucho products, the enterprise Java industry, and PHP. Caucho Technology is the creator of the Resin Application Server and the Quercus PHP in Java engine. A leader in Java performance since 1998, Caucho is a Sun JavaEE licensee with over 9000 customers worldwide.
  • Tags

    ajaxworld bam candi cdi cloud cluster comet configuration deploy devoxx eclipse ejb embedded flash flex google app engine hessian hmtp ioc java ee 6 javaone javazone jms messaging newsletter nyjug osgi php pomegranate quercus resin resin 4.0 REST servlet sfjug silicon valley code camp spring testing training tssjs watchdog webbeans web profile websockets wordpress
  • Meta

    • Register
    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org
« Engineering update
Resin 4.0.0 Task List »

Resin 4.0 clustering

A major chunk of the work for Resin 4.0 is refactoring our clustering architecture and code to better support dynamic and virtual servers, now that that ISPs are more flexible about adding and removing servers to handle load spikes. As a major side benefit to this work, we expect to simplify deployment and management of single server sites, and also offer distributed and single caching services like JCache. This added flexibility requires a redesign of our clustered sessions and load balancing.

Resin 4.0 Clustering Architecture

Our goals for Resin 4.0 architecture include the following:

  • Keep single servers simple to configure and manage
  • Adding and remove dynamic servers allowed during runtime, at short notice for load and power management
  • Improve scalability and performance of distributed caches and sessions
  • Improve reliability with the triplicate-backup in the triad servers
  • Focus administration effort on the triad servers, other servers can come and go
  • Add remote deployment for both single server and clustered server configurations

The architecture we’ve chosen is a replicated hub-and-spoke model. The first three servers form a fully-connected and replicated hub (the “triad”). Following servers connect to all three triad servers, but do not normally connect to each other, avoiding the nxn scalability issue. Single and dual server configurations form a mini-hub, i.e. they are fully-connected and replicated, and are configured and used exactly the same as larger configurations.

Each “triad domain” is a triad of servers as the hub and additional servers as spokes, up to a total of 64. Sites larger than 64 will partition into multiple triad domains. Most communication like caching will remain in the triad domain, while shared information is communicated between the hubs.

Because all the critical data is stored on the triad-hub, the spoke-servers can be taken down for maintenance or disappear without affecting the reliability of the system. Because the triad-hub servers are critical, we recommend using a virtual server system so you can quickly replace a triad server during maintenance or system failure.

This entry was posted on Monday, January 12th, 2009 at 11:57 am and is filed under Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply

You must be logged in to post a comment.


Caucho Technology is proudly powered by WordPress and Quercus®
Entries (RSS) and Comments (RSS).

  • HOME |
  • CONTACT US |
  • DOCUMENTATION |
  • BLOG |
  • WIKI 4 |
  • WIKI 3 |
  • Resin: Java Application Server
Copyright (c) 1998-2012 Caucho Technology, Inc. All rights reserved.
caucho® , resin® and quercus® are registered trademarks of Caucho Technology, Inc.
resin® is a cloud optimized, java® application server that supports the java ee webprofile ®