Cutting edge research on ways to build flexible, scalable, highly-available, distributed systems has been motivated by the observation that many of the complex systems involved in maintaining the living body require no conscious interaction. We don't have to think about how to digest food or heal a cut, for example. Such unconscious systems are called autonomic, because they act autonomously, as if they have their own intelligence.

According to IBM, ("Autonomic Computing Concepts", IBM publication G325-6904-00) an autonomic system must display the following characteristics:

• Self-Configuring
  An autonomic system must be able to adapt immediately to a change in its environment, reconfiguring itself on the fly
• Self-Healing
  It must detect improper events and work around them. Typical day-to-day failures and breaks should not disrupt operations.
• Self-Optimizing
  It should be to efficiently optimize its use of the resources at its disposal.
• Self-Protecting
  Finally, it should be able to detect and foil attempts at intrusion, as well as protecting itself from entering unreliable states like bandwidth overload.

While much of the research on autonomic computing is, properly, very forward-looking, some of the concepts can be applied now. System developers can design-in the basic elements of autonomic data management, ensuring that all the components of the system have enough intelligence to behave correctly under a variety of situations. This is not a blue-sky appeal to fringe ideas of machine intelligence. Rather it is the simple requirement that devices should be able to know their own resources, be able to make local decisions based on their best understanding of their role and how to achieve their goals, and be able to cooperate with other components to achieve shared goals. Autonomy is not a characteristic of a single application or component, but rather of the system as a hole. Various elements of the system may contribute different functions to create a system that behaves autonomously.

An autonomic data management system eliminates the task of managing the complex control data flows in the RNC. It is as if the data takes care of itself.

Autonomic Data Management Components
An autonomic data management system is not a single element, but rather a suite of components that operate together. The key elements are: a local data management system, a high availability system, and asynchronous data distribution. All of these components need to support the development of systems that are self-configuring, self-healing, self-configuring and self-protecting.

Local Data Manager
At the core of any autonomic data management system is a relational database management system (RDBMS). The RDBMS has become a critical component in almost all enterprise software, but is only recently that it has also become an available solution for network elements like RNCs. This is because the classical RDBMS, represented by products like Oracle and IBM's DB/2, were designed for the large, central, tightly controlled corporate data center. It has required the development of a new generation of streamlined, light-weight RDBMS to extend their reach to the network infrastructure device.

Software developers prize the RDBMS because it:

• improves time to market,
• delivers flexible application architecture,
• controls multi-user access to data,
• supports transactions that guarantee data integrity,
• provides full data recovery after node failure.

While the classical enterprise RDBMS is notorious for the amount of on-going management it requires, the autonomic data manager must be self-managing. It must protect the data by coordinating access several concurrent applications making complex data changes, ensuring no loss of data integrity or consistency. It must heal itself automatically from the most basic of failures--board reboot--without any data loss or corruption.

High Availability
Because hardware inevitably fails, an autonomic data management system must be able to self-configure around the hardware failure and heal itself after the hardware is repaired. The autonomic data management system is responsible for ensuring that state of the system survives the hardware failure. The state of a system is defined by its state variables, which in an autonomic data management system are stored in the local RDBMS. So a key to service availability is redundant databases running in a hot standby configuration on redundant hardware.

"Hot standby" means that the two RDBMS are up and running at the same time on the two redundant cards, and that their databases are transactionally identical at all times. Under these circumstances, if one of the redundant boards fails or is taken down for maintenance, the other is fully capable of supporting the applications that are running with no delay caused by reloading the data or booting an RDBMS.

The autonomic data management system is responsible for protecting the integrity of the system by maintaining identity between the two copies of the database. It must detect that one of the pair is unavailable and self-configure into a stand-alone mode. When the hardware is repaired or replaced, the autonomic data management system must heal itself by creating a new RDBMS instance and copying the database from the surviving RDBMS in order to return to the fault-tolerant state.

Data Distribution
In a complex environment like the RNC, data must not only be locally managed, but also moved to where it needs to be. As a simple example, when a new line card is inserted into an RNC, it needs to announce itself to the chassis controller and self-configure for the environment. The controller, in turn, needs to report the new configuration to the EMS. In addition, cards collect their own performance statistics andmust report these to the chassis controller which can aggregate them and report the aggregated results to the EMS.

Like local data management, data distribution must also be autonomous. Application developers should not have to worry about where the data has to go, but rather just write it to the local data store and assume that the system will self-optimize by moving the data to where it needs to be. The autonomic platform must ensure that its data is transmitted reliably, securely, and recoverably to its correct destination.

In the RNC, and in most other applications, data is managed in a hierarchical manner: the EMS controls the system, the chassis controller manages the chassis, and the line cards control their own data. This architecture lends itself to a data distribution technique based on master and replicas. In this context a master is the "copy of record" for a given piece of data. The RDBMS controlling the master copy has full authority over the integrity, security and reliability of its data. Replicas are local copies of master data, under the control of the local data manager. Replicas may be modified locally but the results are not authorized until approved at the master.

A replica configures itself by subscribing to a publication of the master data. The master protects the system by ensuring that the would-be replica has permission to see the view it is requesting, and if so provides the requested subset of its data. The replica can maintain its currency by requesting refreshes periodically from the master. It can also send to the master a report of actions it has taken against its local copy of the data. If the master validates these changes, they become part of the permanent record of the system. If the master does not approve the changes, it protects the integrity of the system by over-riding the local changes and restoring the replica to a valid state.