Configuration Management Database (CMDB)
This is a single database designed to store configuration information and pass that information to interested parties.
Features
- Usually controls individual systems; server farms are defined as an implicit aggregation ( database on host1, application server on host2) rather than explicit cross-dependencies (application server depends on on database).
- A single place to view/manage system state.
- Often come with GUIs to make viewing the state of many machines possible.
- Transacted operations
- Can have a good security model.
Advantages
- One single place to save/view the state of a farm of machines.
- Assuming the database implements it, state rollback and backup/restore permits it.
Disadvantages
- Challenges of Scale and availability. The configuration database must be as available as the rest of the system.
- Some parts of a large system (for example, the routers) are not normally seamlessly integrated with CMDB systems.
- Initial Cost. This reduces their ubiquity, which stops applications being written for it. There are exceptions, such as in the telecomms world, where they are more common.
- Usually read-only by applications. The CMDB pushes out configuration, but does not accept information from the application recording dynamic state.
- A Single Point of Failure. Without replication, loss of the CMDB takes down the cluster.
SmartFrog support
SmartFrog is inherently distributed; there is no single database, merely a farm of machines that agree to co-operate and trust each other. There is thus no CMDB. However, SmartFrog can persist its state to a database with [WoodFrog]. Implementing a 'classic' CMDB is possible, albeit an activity left to the reader.