On Jan 18, 2010, at 1:39 PM, Scott Lawrence wrote: > On Mon, 2010-01-18 at 12:09 -0500, Marden P. Marshall wrote: >> I have been looking into ways in which to improve the dissemination of >> application configuration data. Specifically to make the >> configuration data available to the application in realtime and in a >> granular form, as opposed to the current bulk delivery mechanism, i.e. >> configuration files. There were attempts in the past to do this, >> utilizing proprietary provisioning protocols running over XML-RPC, but >> the results fell short of the intended goals. So now I am looking at >> a simpler and more direct approach, namely, to have the applications >> access the configuration data directly, via the configuration >> database. >> >> In order to achieve the objective of realtime and granular >> dissemination, the database would utilize the postgreSQL Listen / >> Notify mechanism, in conjunction with table modification triggers. >> The application would then subscribe, i.e. Listen, for relevant >> database tables modification notifications. In response to the >> received notifications, the application would then query the database >> directly for the updated configuration. No more waiting for >> configuration files to be created / replicated and no more application >> restarts. >> >> How the application accesses the database records would be based upon >> the specific needs of the application and the complexity of the >> associated configuration data, but would most likely be through simple >> SQL queries, O/R mapping middleware or some combination of both. For >> mission critical applications, a local configuration cache, in the >> form of a properties or XML file, could be maintained. This would >> allow the application to start up in the absence of database >> connectivity, an approach that is already employed by some >> applications. >> >> Any thoughts? > > Actually, I don't think that realtime and fine-grained access to most > configuration data is a good goal. While on the surface it may seem so, > I think it actually creates some serious management and system > architecture challenges that are best avoided. > > One of the core architectural principles that has guided most sipXecs > service development is that configuration data for services is both: > > 1. Distributed to the system on which the service runs so that the > service is to the greatest extent possible autonomous. > > 2. Stored on that system so that a service restart or even system > reboot does not require communication with the central > management database to resume service.
As I stated before, mission critical applications should maintain a local configuration cache, thus making them autonomous in the event that the database be unreachable. Another approach is to utilize database replication when deploying distributed systems. A more involved strategy, but one that brings other benefits to the table. > > Having services access the SQL database directly has some bad > properties: > > * It creates ambiguities or even inability to provide service when > access to the database is unavailable. This limits the ability > to distribute services on multiple systems, especially when > those systems are connected by less reliable WAN links. Again, service interruptions due to database unavailability is a non-issue. In addition, what is being proposed is more robust, due to the fact that only a subset of the configuration data, that which is relevant to the configuration change, need be communicated. > > * It creates potential performance bottlenecks. We've seen this > in the call-state/CDR system in the proxy (in which records are > written to a local database by each proxy, and those databases > are read by the central call resolver to create the CDRs); the > current high-load stress tests fail first in the CDR subsystem. There is no comparison between the throughput demands of a configuration database and that of CDR's. But should the postgreSQL service begin to fail due to heavy CDR database transactions, the Config Server will not be able to function anyway, making this argument moot. > > * It places a greater burden on the management software to > maintain an internally consistent and usable configuration in > the database at all times. By separating the database from the > configuration used by the services, we allow the management > software (and administrator) to directly control how and when > configuration data is propagated to the live services. A series > of changes can be made in the database which, when complete, > form a new and useful configuration without worrying about > whether or not any intermediate state consisting of just some of > those changes is disfunctional. Many reconfiguration operations > consist of multiple steps, and it's easy to create situations in > which step 1 will break things until step 2 is done; by > separating the distribution and activation of configuration data > from the storage in the database, we have an obvious direct way > to control when the service 'sees' a new configuration, and can > improve the odds that it is internally consistent. I suspect that there are not many such cases. I certainly know of none for the applications that I am involved with. But if there are cases where multiple configuration changes need to be performed as an atomic operation, then the Config Server must commit these changes to the database only once the change set is complete. Otherwise it risks leaving the database in an unstable state. And since the application is notified only after the database has been updated, it is guaranteed to only retrieve complete and valid configuration data. > sipXsupervisor enforces that the software version number matches a > configuration version number provided by sipXconfig before starting > anything (preventing new software being started with old data or the > other way around). I see this behavior being preserved regardless of how an application retrieves its configuration data. Also having an application retrieve it's configuration directly from the database is more efficient and will result in shorter update times due to the fact that once the Config Server has updated the database, the applications can immediately start without needing to wait for configuration files to be regenerated and replicated. -Mardy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
