Tutorial V1.4

From OneCMDB

Contents

Overview

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:

  • OneCMDB Core
  • OneCMDB GUI

The Core implements the business logic of configuration management and the GUI provides a web based interface to the core.
Image:OneCMDBoverview.jpg

OneCMDB Core

The Core implements the business logic of configuration management in OneCMDB.
Image:OneCMDBCore.jpg

Configuration Items

You enter data into the CMDB (Core) by creating configuration items (CI). A typical CI is a server in your datacenter. A more abstract CI is a service level agreement (SLA) with a customer. A CI may reference other CIs. A typical case for using a reference is that some data is used by many CIs, and by putting that data in its own CI and reference it, you maintain the data in a single place.

Image:OneCMDBCoreCis.jpg
Each CI has a set of attributes. The attributes stores the data of a CI. There are two categories of attributes:

  • identification attributes
  • user-defined attributes

Image:Ciattr.jpg

Identification attributes

The identification attributes always exists for a CI. As the name indicates we use the attributes to keep track of the CI. Identification attribute values you generally only modify when creating a CI.

Image:Ciattrident.jpg

  1. Id is a unique string that never change for a CI.
  2. Alias is used for identification when importing and exporting CIs, and in different menus in the GUI. Alias may not include special characters or whitespaces.
  3. Displayname is used by the GUI for short textual presentation of a CI and may include variables and whitespaces.
  4. Description is used by the GUI for long textual presentation of a CI.
  5. Template option is set for templates. A CI may serve as template for creating other CIs, see templates.
  6. Icon is used by the GUI for graphically presenting a CI. In case of a template, its icon is decorated with a small 'T'.


See OneCMDB GUI presentation of identification attributes.

User-defined attributes

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 Server CI:
Image:Ciattruserdef.jpg


See OneCMDB GUI presentation of user-defined attributes.

Attribute value types

When you create a new attribute you must set the type of value it will contain. There are two type-categories:

  • Built-in
  • Reference

Built-in are primitive types, e.g. string, integer, etc.
Image:Ciattrtypebuiltin.jpg

Reference is a pointer to another CI as described further down.
Image:Ciattrtyperef.jpg

Attribute value list

Both built-in and reference attribute values can be lists. For instance an attribute called "Ips" can contain a list of strings. An attribute called "Harddisks" can contain a list of references to harddisk CIs.

Image:Ciattrlist.jpg


See OneCMDB GUI presentation of creating a attribute value list.

References

A reference is a pointer to another CI. There are several reason 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 a global IP address only may be used by single server. Then store each IP address in its own CI and let each server point to the IP (CI) it uses. OneCMDB can now help you to detect when an IP address is used by several servers by counting references to the IP CI.

Also see attributes.

Initially, OneCMDB includes two types of references: uses and triggers. These are defined in the CMDB model file. You may define your own types of references. There are several reasons to define different types of CIs

  • 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, imagine that you say "only show me CIs with hardware dependencies" and the picture becomes much less complex.

Policies

Policies control how OneCMDB handle changes to CIs. There are three default policies:

  1. CiPolicy
  2. AttributePolicy
  3. EventPolicy

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.

CiPolicy

Controls modification to CIs, like create, delete, adding attribute etc.

AttributePolicy

Controls modification to attributes.

EventPolicy

User developed policy, meaning that a method in a java class will called.
This gives total freedom of what the policy can do.

PolicyTrigger

Is the glu that connects a number of policy's (CiPolicy, AttributePolicy and/or EventPolicy) to to a specific CI template. The policy will then be applied to the template CI and its descendent CIs.

In the current release PolicyTrigger's can only be assigned to templates not to instances. This will be reviewed in later releases.

Jobs and triggers

Jobs are external programs OneCMDB calls to perform various tasks. Input parameter to a job is stored in a CI. The output from a job can be fed back to new or existing CIs in the database.

Here are examples of existing jobs:

  • Automatic discovery of systems, which calls the external program Nmap
  • Export, which calls an internal Java program that creates an XML file of your data in the CMDB
  • Import, which calls an internal Java program that reads an XML file and inserts the data into the CMDB

Jobs are defined in the OneCMDB:s 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.

Change log

Every change you do to a CI is logged automatically. OneCMDB requires a Request For Change (RFC) to execute a change. In the change log you can see every change associated with a RFC id.

See OneCMDB GUI presentation of the change log.

Templates

A CI may serve as template when creating other CIs. A template CI has the template option set, see identification attributes.

Image:Template.jpg

There are several reasons to use 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 a bound between the template and the created CI even after the creation. 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

Inherit means that attributes in a template CI are copied to a new CI when it is created. Note that if you modify an existing CI the changes will propagate to all CIs based on it. As earlier mentioned, you control the exact behavior through configurable policies, see policies.

There are a few restrictions on how you can use inheritance:

  • A CI can only inherit from a template CI.
  • A CI can only inherit from one template CI.
  • A template CI can inherit from another template CI.

Please not that different wording exist when describing the Inheritance feature in manuals and GUIs. Sometimes we say based on, descendant or offspring. This will be corrected in coming releases.

Models

The model concept

The model defines the structure/metadata of the database, i.e. data that that populate the CMDB. A OneCMDB Model consists of two parts, built-in and user-defined CIs.

  • Built-in - certain CIs that OneCMDB needs in order to create a base for user-defined CIs. You can treat the built-in CIs as configuration parameters for OneCMDB that you in another system might have found in a configuration file.
  • User-defined - you can consider user-defined CIs as items related to your own data center environment, e.g. a server, a software, a document or a Service Level Agreement.


For administrating your data center you only have to bother about the latter part, the user defined CIs. Only if you extend functionality in OneCMDB or build applications using OneCMDB the latter part, the built-in CIs may be of interest to you.

Model files

The model is declared in plain text with an XML syntax. Hence, if necessary it can be read and edited with any text editor. However, the idea is of course that it shall be managed from OneCMDB. The format of the model file is described in the Developer's manual.

A OneCMDB model can be described in one or several model files. It is for instance possible to maintain one model file with CI templates and another file with CI instances. For various reasons, we currently use one common model file named Model.xml.

When OneCMDB starts up it reads a file named Provider.xml. This XML file contains the name(s) of the model file(s) that shall be used. Currently it specifies the model file mentioned above.

The model file(s) are now read and interpreted by the system and the information is used to initially build the CMDB database and possibly populate it. Finally OneCMDB stores the name of all read model files in a built-in CI named OneCMDB Config. Each time OneCMDB starts up, the file list in this CI is compared with the file list in the Provider.xml file. I.e., only unread model files shall be read and interpreted. If a model file is read several times it is likely to cause unwanted effects in the database.

The above mechanism imply the following:

  • If you add a new model file to the system, and adds its file name in the Provider.xml file, this model file will be read next time you start OneCMDB. An example of when this can be useful is if you like to add structure or content to an existing database
  • If you remove a file name from the file list in the OneCMDB Config CI, this model file will be read (again) next time you start OneCMDB. This might be useful if you accidently have deleted for instance one or several templates.

Alternative models

OneCMDB currently includes two alternate CMDB models:

  • A Basic Model
    • This is a small, straight-forward, CMDB model and it includes a few Configuration Items for demonstration purposes
    • The demonstration data shows a dummy data center at a fictitous company named Acme, Inc
  • An Advanced Model
    • This is a more complex CMDB model, which can manage more advanced relations and dependencies
    • This model does not contain any CIs, i.e. demonstration data

The Basic Model is the default model in the current OneCMDB distribution. The model in use can easily be changed using the Model Replace Utility.

Through the OneCMDB GUI you may modify the chosen model to fit your data center. That is, modifying the structure of the CMDB is a configurational function provided by the user interface, not a programmatic customization of the application!

To simplify browsing of CI:s in the GUI we have "Folder" items in both models. The purpose of a Folder item is to list instances based on the same Template. Technically the folder is a CI with a pointer to every instance it lists.

Detailed description of the Basic Model.
Detailed description of the Advanced Model.

OneCMDB GUI

Use a standard web browser to access the OneCMDB GUI. See the User's manual for details. Before you can use OneCMDB you must authenticate yourself with a name and password in the GUI. Note also that the GUI session will time-out after some time of inactivity and you are then directed to the start page.

Modes

OneCMDB GUI has two modes, User and Designer mode. The major difference is that User mode does not show templates.

User mode

You switch to User mode by using the drop down menu in the upper-right corner of the GUI.

Image:Ss-usermode.jpg
In User mode you only see and manage instances, not templates.
The starting point is set to the instance Data Center.
A specific instance is not accessible unless you can browse to it from another instance. This means that you may have to switch to Designer mode to be able to access it.

Designer mode

You switch to Designer mode by using the drop down menu in the upper-right corner of the GUI.

Image:Ss-designermode.jpg In Designer mode you manage both templates and instances. All existing CIs are accessible via the ROOT template, visible at the top of the Template chain window.
The template structure is a tree. At the top you found the ROOT template and at the bottom instances.

Windows

The GUI has four Windows:

  1. Search
  2. History
  3. View/Edit
  4. Template chain




  • Use Search to find CIs in the database that have some properties that match the entered search string. The result is presented in the View/Edit window
  • History presents CIs you have visited. Items are listed in visited order and may show up several times in the window.
  • View/Edit shows the current CI. Press the Edit button to modify the attributes. Pointers to/from the current CI are represented as links.
  • Template Chain shows how templates are based on each other (inheritance). It is a tree structure with a single root CI, "the stamfader". Note, Template Chain is only visible in Designer mode.

The color orange highlights the current CI and edit or view state.

In the Single User Edition of OneCMDB you have two different roles. The User and Fesigner. These roles are separated on a GUI level. The Team edition will support a secure separation of users/roles.

Search

History

View/Edit

View/Edit has five sections. Not all sections are visable at the same time.
You can Expand/Collapse a section by pressing the small triangle to the left of a section text.

Image:Ss-expandcollapse-v11.jpg

Identification attributes

Graph

The graph is only available for instances in view mode, i.e. no graphs for templates or when editing.

User-defined attributes

The following image shows the OneCMDB GUI window for user-defined attributes. You can see user-defined attributes both in User and Designer mode, but Designer mode shows additional info per attribute:



You create a list attribute by setting occurrences to greater than 1 in the OneCMDB GUI, when creating an attribute. Here is an example:


References

This section only shows references to the CI. A reference from a CI is shown as an attribute under section Attributes.


Descendants

Change log

Template chain

The Template chain window shows which templates your current CI inherits its attributes from, all the way up to the ROOT template.



Customized GUI

You may customize the GUI. It is a standard implementation of a web application using style sheets, JSP, taglibs, etc.
You may also develop your own graphical user interface from scratch. Put your own web application (java servlet/jsp) on the web server or develop a stand-alone application that access OneCMDB core directly.

For detailed information about customizing or developing new GUIs see Developer's manual.

Community and support