OneCMDB Overview And Concepts
OneCMDB is a configuration management database (CMDB) for data centers. Configuration stored in the database can be hardware, software, services, customers, incidents, problems, RFCs, documents, etc. OneCMDB conforms to IT Management best practice declared by ITIL, IT Infrastructure Library.
OneCMDB is ready to use as is, but you may also develop your own applications to extend the functionality of OneCMDB. For example develop your own graphical user interface, add/modify business logic, interface external systems, etc.
Note the OneCMDB License for distribution of OneCMDB software and derivated work.
OneCMDB consists of two main parts:
- The OneCMDB Core
- The OneCMDB Desktop
You enter data into the CMDB by creating configuration items (CI). A typical CI is a server or software in your datacenter. A more abstract CI is a service level agreement (SLA) with a customer. A CI may point to (reference) other CIs, and a reference in OneCMDB can be of various types. By using references between CIs, the CMDB can describe how the CIs relate to each other and thus provide a context. Also, data used by many CIs can be stored in a CI of its own and all other CIs can reference this CI. Hence, the data is maintained in a single place.
Each CI has a set of attributes. The attributes stores the data of a CI. There are two categories of attributes:
- Internal attributes
- User-Defined attributes
The internal attributes always exist for a CI. They help to keep track of the CI.
Internal attribute values are generally only set when creating a CI, they are seldom modified.
- Id is a unique string that never change for a CI. It is generated by OneCMDB.
- Alias is used for identification of each individual CI when importing and exporting CIs, and in different menus in the GUI. Alias may not include special characters or whitespaces.
- Displayname is used by the GUI for short textual presentation of a CI and may include variables and whitespaces.
- Description is used by the GUI for long textual presentation of a CI.
- Template Option is set for templates. I.e., a Template is a CI with this flag set. The template Option is not always shown in the GUI.
- Icon is used by the GUI for graphically presenting a CI. In case of a template, its icon is decorated with a small 'T'.
To store your data in a CI you first need to add your own attributes to it. What attributes you need is completely up to you and what you need to store in the CMDB. Here is a simple example of a CI that describes a Server:
Attribute value types
When you create an attribute you must set the type of value it will contain. There are two type-categories:
Attribute value list
Both simple and complex attribute values can be lists. For instance an attribute called "Ip_addresses" can contain a list of strings. An attribute called "Harddisks" can contain a list of references to harddisk CIs.
A reference is a pointer to another CI. There are several reasons to use references:
- It is difficult to maintain data that is copied to many CIs. Instead, put the data in a single CI and let all other CIs reference it. If you like to modify the data you only have to update one CI in OneCMDB.
- You want to see who depends on a certain CI. Assume you want to shutdown a network switch, which computers will then be affected? Let the switch CI have references to all computers connected to it, you will then automatically get help from OneCMDB to list all servers depending on it.
- Detection of erroneous configuration in your datacenter. Assume that a global IP address only may be used by single server. Store each IP address in its own CI and let each server point to the IP address (CI) it uses. OneCMDB can now help you to detect when an IP address is used by several servers by counting references to each IP address CI.
OneCMDB can handle numerous of different reference types, for example Installed On and Depends On. The reference types are described in Templates, which in turn are defined in a OneCMDB Model File. You may of course define your own types of references. There are several reasons to define different types of references.
- Impact analysis, typically performed when handling requests for change (RFCs) or acting proactively to incidents. For example you want to differ between "this system is required for the service to work" and "this subsystem is useful for the service".
- Filtering dependencies. If you try to visualize the dependencies between a set of CIs you may find it difficult to interpret the picture due to its complexity. Then you can select to only show CIs with for instance hardware dependencies and the picture becomes much less complex.
PoliciesPolicies control how OneCMDB handle changes to CIs. There are three default policies:
A PolicyTrigger is used to apply the defined policies to specific CIs. Observe that you must restart OneCMDB to enable changes to a policy, just [Apply] is not enough.
Please note that it is currently not possible to define and manage Policies with the OneCMDB Desktop. If you like to use Policies you must manually edit such objects via the System View.
Controls modification to CIs, like create, delete, adding attribute etc.
Controls modification to attributes.
User developed policy, meaning that a method in a java class will called.
This gives total freedom of what the policy can do.
Is the glue that connects a number of policies (CiPolicy, AttributePolicy and/or EventPolicy) to
a specific CI Template.
The policy will then be applied to the Template CI and its children CIs.
In the current OneCMDB release PolicyTriggers can be assigned to templates but not to instances. This will be reviewed in later releases.
Jobs and triggers
Jobs are external programs OneCMDB calls to perform various tasks. Input parameters to a job are stored in a CI. The output from a job can be fed back to new or existing CIs in the database.
Jobs are defined in a OneCMDB model file. Hence, whether a job is available or not in OneCMDB depends on which data model is used.
Jobs can be triggered manually or scheduled.
Every single change in a CI is logged automatically by OneCMDB and stored in a Change Log. Each change is assigned a unique RFC-ID (Request for Change ID). When a number of changes in the CMDB are carried out at the same time they are assigned a common transaction ID (TX-ID).
There are several benefits with using templates:
- It simplifies creation of new CIs, simply because you don't have to start from scratch each time.
- It simplifies update of groups of CIs. There is an eternal bound between the template and the created CIs. For example, when you add a new attribute to a template the attribute will also be added to all existing CIs based on this template.
- It allows you to put restrictions on certain groups of CIs.
Inheritance means that attributes in a Template are copied to a new CI when it is created. It also means that a modification to a Template propagates to all CIs based on it. As earlier mentioned, the exact behavior is controlled through configurable policies.
There are some rules on how you can use inheritance:
- A CI can only inherit from a Template.
- A CI can only inherit from one Template.
- A Template can inherit from another Template.
Please note that different wording exist when describing the Inheritance feature in manuals and GUIs. Sometimes we say based on, sometimes descendant or offspring.
The model concept
OneCMDB uses Models to define the structure of the CMDB. Each Model can contain several parts, defining Templates, References, Instances (CIs) etc. You can import one or several Models depending of what the OneCMDB system shall do and what the CMDB shall contain. You can add Models on the fly with more CIs (data) or with new structure or functionality. You can also export Models, either as a backup or for re-use in other OneCMDB installations.
OneCMDB also have a number of Models with system related information and system configuration data. These models are automatically loaded and a user does not have to bother about them. Only if you extend functionality in OneCMDB or build applications using OneCMDB these models may be of interest to you.
Each model is declared in plain text with an XML syntax. Hence, if necessary it can be read and edited with any text editor. The idea is of course that it shall be managed from the OneCMDB Desktop. The format of the model file is described in the Developer's manual V2.0.
A OneCMDB model can be described in one or several model files. It is for instance possible to have one model file with Templates and another model file with Instances (CIs).
The OneCMDB distribution currently includes a Basic Model that we believe can be a good start in a CMDB project. The distribution also contains a model developed for use together with the NMAP discovery system and another one developed for use together with the Nagios network monitoring system.More information about the models are found in the Models section.