From: Steve L. <ste...@hp...> - 2006-01-23 12:15:49
|
Ganesan, Kumaravel (STSD) wrote: > > - a thougt/proposal : > > App Server Clustering Component : > > In any large enterprise system , there may be muliple > application server that are used to handle load sharing and load > balancing. In this high availability context , the proposed component > can support the following features > > Distributed deployment of appserver components > To address load balancing in heterogenous app servers (what is the > Business need --- ?) > - it needs seemless deployment of applications (abstract > webserver ??) > - deploy on one node - deploy on all other node > - state replication across different servers > Runtime app.server node identification. > etc... > > That is an interesting thought. I believe we should steer clear of app server internal things (like state replication). Nobody should be deploying the same app across different back ends as one unified front end, as it is doomed to end up in a disaster of one sort of another. I don't even have fond memories of doing partial updates of a live system one node at a time, as there is a period when state is shared between two versions of your app, and there are potentially different behaviours of the app depending on where stuff gets routed. I do think something that rolls out an update to a set of boxes is important, and important its done fast, such as by copying the WAR/EAR files to the individual app servers' file systems, then, once every box is ready, flipping them over to the new release. You need to think a lot about rollback actions too: it may be ok for one node to fail to update (in which case it has to be taken out of the load balancing), but if more than one fail to update, then its emergency rollback time (which implies keeping an old copy of the previous app around). You need -good diagnosis of trouble -a component that is happy if a subset of the things it deploys is working, enough for the SLA to be met -reporting of trouble (i.e, even if you are within the SLA, its important to warn that some of the nodes are down). Maybe this comes for free if you make part of your state JMX visible. Another thing to think about is: JNDI access to smartfrog attributes from an EAR application EAR apps are built on the expectation that configuration is via JNDI URLs, offering access to some hierarchy of read-only or read-write state. This can be simple (tomcat's read only access to a configuration file), better (JBoss), or even access to a fully replicated LDAP server like ActiveDirectory. Could we have a JAR that offers read access to part of the smartfrog graph from anything hosted in an app server, just by it starting off with the right URL and having the right security permissions? That would let people use smartfrog as a configuration source, without knowing. It also lets things get at the data without running in the same JVM, which lets stuff in unsecured, unsigned JARs access the graph. This is important because you dont want to try and turn security on in an app server that was never designed for it -even hibernate refuses to work in with signed JARs (it tries to compile new classes into sealed packages). -steve |