CMS - Configuration management service based on MongoDb

Author: Su, Ralph

 

Abstract

Configuration management database (CMDB) is commonly used to store the management items inside an organization/company. CMDB typically designed as a centralized database access points. 

As CMDB of eBay cloud service, CMS is a configuration management service built on top of MongoDb. It provides rest service, and with its own query language. CMS now stores eBay marketplaces configuration items range from asset/network to application service topologies. With peak request of 10millions request per day, CMS now serves as a reliable infrastructure service for eBay cloud service. 

In this article, we present the architecture consideration and design of CMS.

Architecture Consideration

Why MongoDb?

Compare to most of current CMDB which built on relational database, CMS choose MongoDb as its background database. There are a couple of pros & cons

Pros

1. CMS design target is to store configuration items, which means its data size would be capable to store in memory, which could fit to the MongoDb best usage.

2. CMS designed to serve the more read requests than write requests. Combine with #1, mongo could provide easily maintained read scalability through its replica set deployment. 

3. CMS not designed to provide RDB’s strong transaction. Instead, to ensure data consistency, CMS provides MVCC (multi version concurrency control) on object level. 

4. CMDB require schema change/evolution frequently (compare to typically RDB migration). MongoDB’s schema less document design make it feasible as CMDB option.

Cons

1. MongoDB is a schema-less document storage. Although configuration items need flexible schema, they are not schema-less. Solution: CMS provide metadata definition to help the schema definition.

2. No transaction. Solution: CMS implements own MVCC on top of mongo.

3. Mongo provide only single collection query based on key/value. Solution: CMS provide its own query language to support query join.

CMS as a CMDB, why there are repositories/metadata concept which is not a typical CMDB scope?

As a software product, CMS is designed as configuration management service based on its core component of metadata management, entity management, and query services. This design makes CMS not only a product that could serve the requirement of CMDB. And it also makes CMS a more general persistent service to provide user flexible metadata define, and store data inside CMS according his/her metadata definition.

Design

CMS is a metadata-driven system. Metadata definition describes how data is stored and fetch in CMS.

<<CMS Arch - Digram>>

Metadata module

Metadata is the “table” definition for data stored in CMS. This module is simple and intuitive; it read/store the metadata definition from/to backend database. The main concept of metadata module is the metaclass and relationship; it also provides the definition of indexes, which is used in query service to improve the database query performance. All the metadata information is cached in the memory using a simple write-through cache.

Entity management module and data access module

The entity management module provides the CRUD operation on CMS runtime data. A runtime data (called entity) is a json structure stored in background database while intercepted by the metadata definition. This module control the data storage strategy; provide MVCC check; provide data relationship check (strong reference and dangling check); default value handling; access control; A typical visitor pattern is used here to process the data.

Data Storage

A couple of storage strategy has been taken into consideration.

Data distribution

“Every repository would have a mongo database as its storage.”

1. All data in same collection