Building a CMDB on the Resource Platform

CMDB is the foundation of automated operations. When implementing an operations platform, CMDB usually comes first: create asset models for every operations object you intend to manage, maintain the relationships between assets, then enter data or collect it automatically. OpsAny's workflow follows the same three steps: 【Resource onboarding】 → 【Resource management】 → 【Resource operations】 (bulk execution, monitoring, inspection, and so on).

Tip

Before you start, a serious note: CMDB (Configuration Management Database) is a database. I trust you would not casually drop tables or delete columns in your production database — so treat CMDB the same way.

Model management

The OpsAny Resource Platform ships with a rich set of built-in models. If they do not cover your needs, create a new model — preferably by cloning an existing one. If a model already has data entered, do not modify it casually.

Every attribute identifier is automatically prefixed with the model's unique identifier when saved, so identical attribute identifiers in different models stay globally unique. The attribute names suggested below can be changed, but the attribute identifiers must stay the same.

Basic concepts

Configuration Item (CI) is the fundamental concept of CMDB.

• CI model: each CI model is analogous to a database table. OpsAny calls it a model.
• CI model group: CI models can be grouped — for example, the database group holds MySQL, Redis, and MongoDB, while the host group holds virtual machines, physical machines, and cloud hosts.
• CI attribute: each CI consists of many attributes, analogous to a column in a database table. OpsAny calls them model attributes.
• CI attribute group: a CI's attributes can also be grouped — for example system attributes, physical attributes, management attributes.
• CI model relationships: CIs are related to each other — for example, a virtual machine runs on a physical machine, and a virtual machine has an owner. OpsAny abstracts two kinds of relationships: subordinate relationships and connection relationships.
• CI subordinate relationship: a special, constrained relationship definition between CIs — for example between a virtual machine and a physical machine, or a physical machine and a rack. Think of it as lineage in the human world. It describes relationships with no ambiguity. Built-in subordinate relationships cannot be modified.
• CI connection relationship: a general relationship describing every other, non-subordinate relationship — for example between an application and a person. There can be many connection relationships, so tags can group them, much like friends in the human world carry tags such as colleague, comrade-in-arms, or classmate.

Creating models

When the built-in models cannot meet production needs, create your own. Cloning is recommended: for example, clone the physical machine model for other physical device models, avoiding the tedium and mistakes of building from scratch.

Deleting models

Do not casually delete any built-in model. If you neither need nor want to see a model, use the "Hide" feature instead. Deleting a built-in model can make some system features unavailable.

Attribute recommendations

Follow best practices when creating models. Below is what the OpsAny delivery team has learned in projects.

1. The unique identifier you enter when creating an attribute is automatically prefixed with the model's unique identifier. The final identifier is:

model_identifier_attribute_identifier. So do not include the model identifier in your attribute identifier — it is added automatically.

1. We recommend giving every model a "Comment" field. The built-in models' "Comment" field has a fixed purpose — do not delete it!

2. Attribute name: 备注 (Comment) Attribute identifier: COMMENT

Physical device location attributes

Physical devices placed in racks can show their exact position in the Resource Platform's physical view. To display the device's U position in the rack correctly, add the following three fields to the model with exactly these identifiers:

• Attribute name: 起始U位 (Start U) Attribute identifier: START_U
• Attribute name: 占用U数 (Occupied U) Attribute identifier: OCCUPATION_U
• Attribute name: 上架位置 (Rack location) Attribute identifier: RANK_LOCATION

Relationship management

OpsAny has two kinds of resource relationships: subordinate and connection. Subordinate relationships express something like lineage — a parent-child relationship, or one with no ambiguity. A physical server must sit in a rack; but a switch and a server are not subordinate, because a switch can connect to servers and to other devices. Note: avoid subordinate relationships unless necessary, and never delete the default built-in relationships.

Subordinate relationships

Subordinate relationships on the OpsAny Resource Platform are also called parent-child relationships: a one-to-many directed relationship (a CI model has exactly one parent and can have many children), where the child is part of the parent. It is a strong hierarchical dependency between models — a server must be placed in a rack, and a rack must belong to an area of a data center. There is no ambiguity.

Use subordinate relationships sparingly. The built-in models of the OpsAny Resource Platform already cover most subordinate relationships — do not modify or delete them, and avoid adding new ones, especially when you are unsure.

Connection relationships

Connection relationships on the OpsAny Resource Platform are also called friend relationships: every strongly dependent non-subordinate relationship is a connection relationship (many-to-many and undirected — a CI model can relate to multiple CI models). Tags can distinguish different connection relationships.

Every middleware and database should have connection relationships with hosts (virtual machines, physical machines, cloud hosts), and their unique identifiers must be fixed as follows:

• Relationship name: 关联物理机 (Associated physical machine) Relationship identifier: IN_SERVER
• Relationship name: 关联虚拟机 (Associated virtual machine) Relationship identifier: IN_VIRTUAL_SERVER
• Relationship name: 关联云主机 (Associated cloud host) Relationship identifier: IN_CLOUD_SERVER

For example, the Redis model's connection relationships:

• Local side: relationship name 关联虚拟机 (Associated virtual machine) relationship identifier IN_VIRTUAL_SERVER
• Peer side: relationship name 运行Redis (Runs Redis) relationship identifier RUN_REDIS

All service-to-host relationships follow the best practice of RUN_XXX (the model's unique identifier), keeping the convention consistent.

Data entry

Manual entry

The OpsAny Resource Platform supports manual entry and Excel import, and you can also onboard directly in the Control Platform — after onboarding, data syncs automatically to the CMDB on the Resource Platform. The recommended order is to enter data first, then onboard.

Automatic asset collection

OpsAny Community Edition supports automatic asset collection. First create an asset collection plugin in the 【Control Platform】, then create a collection task in the 【Resource Platform】. See the documentation below.

• Asset collection plugin development

Editing relationships

Once resources are entered, manage their relationships: click a resource (name or unique identifier) to open its detail page, then click (Relationship Management) to maintain relationships.

Data analysis

OpsAny provides asset island analysis. An "island" is a resource that has relationships defined but is not configured with any — for example, a physical machine not associated with any rack. Island analysis shows which physical machines have no rack association.

Island analysis

The island analysis page supports scheduled and manual analysis. Scheduled analysis is usually recommended: analyze and summarize CMDB data daily, and fix issues promptly to keep CMDB data accurate and current.

Resource authorization

By default, users with the "Administrator" role see all resource data, while users with the "Regular user" role see none — hence resource authorization. Note that OpsAny separates "function authorization" from "resource authorization"; this loose coupling increases authorization precision.

Resource authorization

The Resource Platform's resource authorization page grants resources through authorization rules. Why rules rather than direct selection? Because in many cases authorization depends on characteristics of a resource, and rules are both more precise and far more flexible. For example, you can grant a user all hosts and databases associated with "Application A", or even grant a user every host whose operating system is "CentOS".

---