11 February 2020 Reading time: 1 minute

DCImanager 6 — the new server and data center equipment management panel. First encounter and comparison with version 5

Natalya Tsaryova

Natalya Tsaryova


On January 28, we have completed testing and launched the stable version of DCImanager 6 – our new panel for server and data center equipment management. The previous generation had been working for almost 10 years, so the update was significant. In this article, we will compare the two versions and tell you about the changes.
DCImanager is intended for managing servers, switches, physical and virtual networks, racks and locations. The panel automates sales of servers, monitors the equipment status and reports problems. It is used by infrastructure owners and hosting providers. There were many reasons to update the product, but the main was perhaps the existing constraints in architecture. Therefore, we will start with overview of architecture and then talk about other important updates.

There is a lot of material, and if you are not enthusiastic about a lengthy read, we invite you to have a look instead. You can run a demo (we will need your email to send access details to) or a trial version. Read more at .

We will compare the versions in the following order of aspects.
I. Conceptual differences:
II. Differences in task solving:
III. Plans for development of DCImanager 6.


The development of DCImanager 5 was gradual: clients had new tasks, they wrote to us asking us to automate them, and we did. Over 10 years, many new features were added to the panel.
Due to active and significant improvements, the architecture of the panel has become a monolith. Changes in one place could affect the entire functionality, while the implementation of some tasks was complex and required additional conditions.
To avoid such problems in the future, we decided to switch to microservice architecture in DCImanager 6. We have singled out statistics, switch management, IPMIproxy and many other things into independent services – about 20 in total. They are written in C++ or Python and packaged in dockers.
With transition to the new architecture, it became easier to add new features to the product. Each service is isolated, which means that it can be developed, deployed and scaled independently of others.
Isolation allowed the use of new technologies and programming languages. Some of the services already in operation are written in Python and Go (assistance with golang is provided by partner teams, thank you for that).

Not only has the general architecture changed, but also individual solutions. For example, the mechanism for performing time-consuming tasks.


In DCImanager 5 (as well as in other fifth generation ISPsystem products) this mechanism existed, but was not always used. Typically, tasks were simply performed in sequence and the user had to wait for them to complete. For example, the client would assign an IP address to the server and couldn't do anything for a while except looking at the preloader.


In DCImanager 6, we improved this mechanism: rewrote the architecture, added lock mechanisms, dependencies and much more. Now a time-consuming task is carried out in a separate process and does not block the panel operation.


Architectural differences are significant, but they are not visible from the outside. The interface is a totally different story – here the difference is immediately noticeable.
The DCImanager 5 interface has become both visually and technically obsolete. It looks out of date, user scripts do not seem to be thoroughly designed. In addition, there was no division into backend and frontend in development. The interface was described in XML files and processed by COREmanager framework through XSLT transformations.
DCImanager 5 home page
The interface of DCImanager 6 is different. We took into account the wishes of version 5 users: analyzed the tasks of the data center administrators and tried to make solving them simple and quick. From the technical point of view, a clear division into backend and frontend has appeared. User scenarios are thoroughly analyzed by UX-designers and implemented by front-end developers. Instead of outdated technologies, the modern Angular framework is used.
DCImanager 6 home page

Management of several data centers

Servers are not always located in one place. Often the infrastructure is geographically distributed: some servers in Ukraine, some in the United States. And sometimes one part is in one building and the other part is in the next one. In any case, it is convenient to control equipment in different places (locations) from one panel.
There were two ways to work with several data centers in DCImanager 5: buy a separate panel for each or use the location mechanism.
The first method was not very convenient – you had to pay for each panel panels and switch between them while working. The second way was better: the client would buy one panel and allocate a managing server for each location within the panel. It was possible to work from one interface, but it was not always possible to configure this mechanism. All servers in the location had to have access not only to the managing server, but also to the server with DCImanager 5, while the server with DCImanager had to have access to equipment at the location.
Location management in DCImanager 5
In DCImanager 6, the logic of the location mechanism has changed. Now not all equipment needs to have access to the server with the panel, actions are only performed through the managing server. In addition, you can now work with locations directly on the panel's main page: upload OS, diagnostics and recovery templates to the managing server, add hardware, track the number of free racks and units.
Configuring the location in DCImanager 6

Server configuration and management

The main task of the control panel is to automate routine operations. So that the administrator does not have to go from server to server, but can work remotely. So that you do not enter commands in the console, but can quickly perform the necessary operations in the interface. Both versions of DCImanager can manage this. The difference is in the interface.
In DCImanager 5, all servers were displayed in one list. To enable, disable or perform another action on the server, you had to select a line and click the button above the table. Basic server information was contained in the line and displayed as identical icons. It was intended to be visually intuitive, but eventually turned out to be not very convenient.
List of servers in DCImanager 5
In DCImanager 6, the list of servers has evolved and become more functional. Here you can also enable/disable the server, install the OS, run diagnostics and other operations. The order of data has changed, it is more convenient to perceive the information. In addition, it is now possible to configure server connections and monitor the status of these connections.
List of servers in DCImanager 6. If you click on a server in the list, extended information about it will be displayed: address, location, owner, OS, connections
From the list, you can go to extended server information (into the dashboard). There are two sections in the server dashboard so far: "Configuration" and "Statistics." In the configuration section, you can manage the server, edit the primary IP address and MAC address and perform other operations. The statistics displays graphs of traffic volume and network load. New sections are coming up soon: lists of IP addresses, connections and others.
Server dashboard in DCImanager 6. The menu with general settings, statistics and other sections is on the left

Server management via IPMI in private networks

IP addresses from the private network are usually used to manage the server via IPMI: due to shortage of external IPv4 addresses and to protect access to IPMI with old firmware. Both versions of DCImanager support IPMI connection through proxying, only it works differently.
In DCImanager 5, the IPMI Proxy module was responsible for this task. It was using third-party software, so there was a risk of unauthorized access to the server. In addition, due to its architectural features, proxying created a load on the server and slowed down the entire panel. Problems were solved by installing IPMI proxy on a separate server, but this option did not suit everyone.
In DCImanager 6, the logic of working with IPMI has evolved. Now IPMI Proxy v2 service is responsible for connection to IPMI web-interfaces. It works with both internal and external IP addresses. You do not need a separate server to install it: thanks to the microservice architecture, the IPMI Proxy v2 module is isolated and does not affect the entire panel.
The module consists of client and server parts. The client part is installed on the server with the panel, the server part is installed on the managing server of the location to the equipment of which connection via IPMI is required.
Client part — scripts for IPMI management and interaction with DCImanager 6, noVNC-client, software for VNC-session TCP-traffic broadcasting.
Server part — scripts for IPMI services management, TigerVNC-server, Chromium browser for access to IPMI web-interface.
Configuring IPMI connection parameters in DCImanager 6

Switch management

Both panels can manage switches: change the speed and mode of ports, poll them, connect to the server, etc. The difference is in the interface and logic of work with the equipment.
In DCImanager 5, processing modules were used to work with switches. Over the years of the panel’s existence, many modules were developed. Users could write them themselves, but it was a difficult task because of the architecture and API, and the inability to upload the processing module through the interface. Clients came to us for help, we helped, but there was a problem with the testing. To test a processing module, you needed access to the equipment, and customers could not always provide it: for security reasons or simply because the equipment was being intensively used.
Switch ports list in DCImanager 5
In DCImanager 6, two types of processing modules are available so far: for Cisco switches and a universal processing module for SNMP protocol (which fits most switches). We will soon add a processing module for Juniper switches as well as a module to add new processing modules. It will allow administrators to write Python processing modules, then upload and check them through the interface.
Switch ports list in DCImanager 6

A separate service — Equipment service — is responsible for managing the switches. We decided to take it out of the main application for two reasons:

  • to reduce the load on the main application,
  • to seamlessly refine the existing features or add new features for working with equipment.

In addition to working with switches, the service tasks include gathering traffic statistics. At a later point, processing modules for other types of equipment (e.g. PDUs) and working with IPMI will move there.

Traffic statistics

In DCImanager 5, DCImanager itself was responsible for gathering statistics. Once every five minutes, the panel polled the switches and saved traffic data to a file, then processed it once per hour and saved it to the database, and once per day the data was aggregated and rewritten to the database. All these operations created extra load on DCImanager 5. The panel also drew the graphs itself.
Statistics in DCImanager 5. If there wasn't enough data, the graphs were "unattractive."
In DCImanager 6, gathering of traffic statistics has changed on the inside and outside. The equipment service is responsible for data collection. Every 5 minutes it receives the current status of the switch ports, as well as incoming and outgoing traffic on each port. The information is then sent to Graphite, where the aggregation of data for specific periods is pre-configured. Graphite is integrated with Grafana, which draws the graphs. These graphs are directly embedded in the DCImanager interface.
Attractive graphs in the new panel. Thanks to Grafana

IP addresses management

In both versions, handling IP addresses was set up through integration with IPmanager – another ISPsystem product. Only in the fifth generation, it had to be bought, installed and configured, while in the sixth version, IPmanager is built-in as a separate service.
What you can do with IP addresses:
  1. assign to servers manually or automatically,
  2. manage groups,
  3. add a pre-configured physical network,
  4. consolidate networks into pools,
  5. view the numbers of free and occupied IP addresses.

Automation of dedicated server sales

If you are a hosting provider, you are aware of problems with provisioning servers to the client: you need to find the right server, check it, install the OS, and so on. All of this takes time - both on the provider’s and client's side.
Both generations of DCImanager automate equipment setup and provisioning through integration with billing systems. Support for WHMCS, HostBill and BILLmanager is provided, and integration with other billing systems via API is possible.
In the sixth generation, the integration has undergone slight changes. Now you can order a server from a certain data center directly in the billing (in the previous version it was impossible). The user interface, where the client manages its equipment, has become more esthetic and convenient. API was improved.

Immediate plans

We have described the key differences between the two panels. The work on the new version of DCImanager continues. Here is a brief overview of what we will add to the panel shortly.
VLAN support is one of the most expected features of DCImanager 6. When it appears, administrators will be able to logically group the physical ports of the switch into a VLAN.
Customer switch processing modules. Administrators will be able to write, check and add processing modules for different types of hardware through the DCImanager 6 interface. The processing module can be checked in a special "sandbox" by establishing a connection to the switch and performing certain actions on the ports of the device.
Server status monitoring (CPU, RAM, HDD). The panel will display information about the CPU load, RAM status, available hard disk space and so on. And all this will be available in real time.
Notifications and event log. The event log records all actions in the panel. The notification system allows the administrator to be informed about changes in the status of entities or parameters of the equipment. For example, by setting up notifications in the statistics section, the administrator of the hosting provider will be able to receive notifications if the traffic on the client's server exceeds the tariff limitations.
Keep track of further updates in the product's Changelog. Please send us your requests related to product features to feedback@ispsystem.com. We will be happy to answer your questions in the comments below. Thank you for your time!