The ConfD CDB (Configuration Database) is designed modular and easily replaceable. For most use cases, the built-in CDB is used, but other databases can be plugged-in, or even some simple storage in flat files could be built. As CDB implements transactions and multiple datastores, i.e. running, candidate, and operational, the level of integration with another database management system can vary from just the operational datastore to replacing all three CDB datastores with or without transaction support.
If you are implementing NETCONF, transaction and candidate support is likely desired.
ConfD Datastores
----------------
+-----------+ +-----------+ +-----------+
| Startup | | Candidate | | Running |
+-----------+ +-----------+ +-----------+
Each datastore is a full copy of the configuration
Each datastore can be mapped to CDB or external database
Running can be split across CDB and several databases
5 combinations (S+Rro, S+R, R, R+C, Rro+C)
+---------------+
| Operational |
+---------------+
Operational data store
Store status, performance or application data
The API for integrating your DMS with ConfD with full support for configuration data and transactions is described below in the “transaction state + external database API” picture:
+-------+
| START |
+-------+
| init()
|
v
get_elem() +------+ finish()
------> | READ | --------------------> START
+------+
^ |
trans_unlock() | | trans_lock()
| v
get_elem() +----------+ finish()
------> | VALIDATE | -----------------> START
+----------+
| write_start()
|
v
set_elem() +-------+ finish()
-------> | WRITE | -------------------> START
create() remove() +-------+
| prepare()
|
v
+----------+ commit() +-----------+
| PREPARED | -----------> | COMMITTED |
+----------+ +-----------+
| abort() |
| |finish()
v |
+---------+ v
| ABORTED | START
+---------+
| finish()
|
v
START
With the addition of optional get_* and set_* calls for improved performance.
Example integrations comes with the ConfD example set and are described in the ConfD user guide.
For operational data, i.e. status information, the applications themselves register as data providers most of the time. There is usually no point in storing this kind of potentially rapidly changing data in a database. The values are simply computed when an operator wants to see them. For certain types of operational data, e.g. performance and alarm data, it may make sense to store this in a database. The CDB Database has a separate Operational Datastore available for this purpose, should you wish to use it.
There are users of ConfD that has replaced the CDB, with their own database management. Note that most of them have done so to preserve their legacy applications, not for performance reasons. So far, on the few occasions when CDB did not live up to the performance expectations, it has been for the use case where the operational data store in CDB has been used to collect massive amounts of statistics and monitor data. Here, for example PostgreSQL has been used to store operational data, while CDB has been used to store configuration data in running and candidate datastores.
For transactional configuration data, CDB has so far been proven performant enough… When you enable NETCONF using ConfD and e.g. for legacy reasons want to store configuration data in your own database management system, if you implement candidate commit with NETCONF, you can still use CDB for the candidate datastore, while your database management implements the running datastore part.
The key features of CDB are:
Transactions: the data store and the ConfD transaction engine are
tightly connected to enable NETCONF and network wide transactions. This
removes the burden from application developers to understand and implement transactional integrity.
Persistent embedded in-memory database with optimized performance for hierarchical data. The in-memory model makes all validation, CLI tab-completion etc. execute quickly. The CDB journals are stored to disk.
Automatic schema management: the embedded data store removes all traditional work around databases. CDB uses YANG as native schema language, so the schema management is transparent. Nor is there any need for run-time configuration or administration of the database.
Schema upgrade/downgrade: the schema (YANG model) can be changed in run- time. CDB will automatically manage migrating the existing stored data. In case of conflicting schema and instance data, upgrade hooks can be registered.
Subscription-based programming model: programmers can subscribe to changes to CDB and react upon those. This in contrast to stub-based approaches. It also enables easy addition of logic.
High-availability: CDB can run in high-availability mode, where hot-standby nodes are replicated from the master node.
Support for candidate and running data stores
Fast and light-weight: CDB is optimized for embedded applications, the foot-print is small and response times are quick.