Service activation algorithm


Server configuration

If the tariff supports the selection of server parts, the server configuration is based on resource values.

  • if the available configuration in BILLmanager differs from the current configuration in DCImanager, the tariff is not available for order;
  • if the available configuration in BILLmanager is up to date, but the configuration in DCImanager has been modified, the tariff will be available for order. DCImanager will create a task to purchase new spare parts. After the task is executed, a new server will be activated in DCImanager. A service activation task is created manually in BILLmanager. After the staff member processes the task, the service will be activated. 

List of available servers 

List of available server configurations is built. The billing system connects to DCImanager and gets the list of all servers. Available servers are those meeting all of the following conditions:

  • The server has no owner.
  • The server domain name is free.ds.
  • No issues with equipment (the hwproblem checkbox in xml).
  • Option "Protect server" is disabled (the forcelock checkbox in xml).

Configuration of the server ordered by the client is compared with the configuration of all available servers. Once the system finds the appropriate server configuration, server preparation is started.

Otherwise, the similar server is found and server assembly task is created.

Server preparation 

The process of server preparation by DCImanager is as follows:

  1. The administrator which is the user used for DCImanager integration is set as the server owner. Please note that if there is an error on one of the following steps, the server owner will not be altered. It guarantees that the server with the issue will not be pulled again for one of the future orders.
  2. The system changes the server domain name to the one specified by the client or generated automatically by the billing system.
  3. If the server is off, it will be turned on. The timeout for the start is 30 minutes.
  4. The operating system is installed. Windows installation timeout is 200 minutes, while for Linux it equals to 140 minutes.
  5. The server owner is changed. The new owner is your client's account in DCImanager. The account is created by the billing system.

If server preparation is successful, BILLmanager will change the service status to Active, and your client will receive the service activation email.

If one of the above stages has ended up with an error, then another applicable and available server will be pulled, and the procedure would be repeated. If there are no other applicable and available servers left, then the server with the closest configuration would be chosen and server assembly task created.

Finding a server with a similar configuration 

The algorithm is to find a server with the configuration closest to the one ordered by the customer. Once such a server is found, your specialist responsible for server assembly will receive a new task. The task contains server description and the list of parts that have to be changed to meet the client's configuration.

Algorithm of server search for server assembly is the following:

  1. Search for server with applicable CPU. Available servers with applicable CPU are chosen first.
  2. Search for servers with applicable platform among all empty servers. If there are no available servers with the right CPU, the system looks for clean servers i.e. servers that have no CPU yet and checks whether the platform is compatible with CPU in the order.
  3. Search for any server with the applicable platform. The system looks for servers with other CPU but the right platform.

The system chooses a server with the minimum difference from the required configuration. Servers that differ in hard drives solely are always in priority.

The administrator which is the user used for DCImanager integration is set as the server owner and assembly task is created.

If there is still no equipment found, the system will create a task to procure the required equipment.

Note:

Tasks for equipment procurement can only be created if your DCImanager has the active Inventory module.

The task for server assembly 

Assembly task accepted by one of the employees:

The Server tab specifies the rack and server (label) IDs which is to be reconfigured.

Tabs Install and Pull contain the list of equipment to be pulled and/or installed to the server to make it fit the client's configuration.

The option "Available server" impacts actions to be performed upon task completion:

  • If this option is active, it would mean that there is a new server with the appropriate configuration. Server reserved for assembly will be returned to DCImanager (server owner is changed), then the system would look for available server and start its preparation.
  • If this option is disabled, it would mean that the employee has finished the assembly work. In order to make sure that now the server configuration fits the required configuration, DCImanager starts server diagnostics. It displays the updated server configuration and checks whether it fits the client's order. If it fits, the server is prepared; otherwise, the new assembly task is opened.

Task for server procurement 

If the server for assembly is not found, the employees responsible for equipment procurement will receive a new procurement task.

Missing part search algorithm

  1. The system counts the number of CPU of the required type available in stock. If this number is lower than required for the configuration, DCImanager will create a new task for purchasing enough CPUs. It tries to find a server with the appropriate platform for these CPUs.
  2. If the server with the right platform is found, it will be attached to the service; the administrator becomes the owner of the server.
  3. If the server with the right platform is not found, information about the necessity to buy the right platforms is added to the task.

This is how the procurement task looks:

Tab "New devices" contains information about equipment to be purchased.

Option "Available server" impacts actions to be performed upon task completion:

Search for server with an appropriate platform  

Let's imagine that a client has ordered a configuration with two CPUs Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz.

During server search, CPU name, and platform name are converted into the standard form:

  • CPU name. The part between "CPU" and "@" is extracted from the CPU name, symbols "-" and "_" are replaced with the symbol " " (space): E3 1230 v3. The middle part is deleted and number os CPUs is added before the name: 2E3v3.
  • Platform name. Part before the first space is extracted from the platform name e.g. "2_E3_v3 Blade"): 2_e3_v3. Symbols "_" and "x" are deleted: 2E3v3.

Letter case is not taken into account when CPU and platform names are compared.

In the end, the server with the platform "2_E3_v3 Blade" can be used for assembly of the configuration with two CPUs "Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz".

Search for CPU in stock

Let's consider the situation when a client has ordered a configuration with two CPUs "Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz".

During the stock search, CPU name in configuration and CPU name in stock are converted into the standard form:

  • Configuration CPU name. The part between "CPU" and "@" is extracted, symbols "-" and "_" are deleted: E31230v3.
  • Stock CPU name. The first right part before space is extracted, symbols "-" and "_" are deleted, e.g. for "CPU Xeon E3-1230V3": E31230V3.

Letter case is not taken into account when two names are compared.

In the end, "Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz" and "CPU Xeon E3-1230V3" are the same CPU.

Synchronization


DCImanager processing module checks the service status from time to time and verifies matching of certain service parameters.

Status synchronization

When status synchronization is selected, the system selects the list of all services in the billing platform, which are connected to DCImanager module, and compares service status in BILLmanager and server status in DCImanager.

If BILLmanager has the active service while the corresponding server is disabled in DCImanager, then the billing system would turn the server on. If the service in BILLmanager is suspended, while the server in DCImanager is active, then it would turn the server off.

Status synchronization is performed on a daily basis.

Parameter check

In this case, the ID field is used to check the correspondence between the service in BILLmanager and the server in DCImanager. It checks whether the value of the ID field on the server edit form (Products/Services  Dedicated server → button Edit) matches the Id field in DCImanager in the section Servers.

BILLmanager checks ID presence for all active services periodically. If the ID is missing for the server in the billing system, it creates an alert to BILLmanager administrator.

It also checks the match between the main IP address specified for the service in BILLmanager and the main IP address of the server in DCImanager. If there is no match, it creates an alert to BILLmanager administrator.

Cron task processing.syncserver.cron  is responsible for data synchronization.

Statistics collection


The DCImanager module supports the collection of statistics with a few resources. Statistics is always collected for the previous day

Cron task statdaily.cron is responsible for statistics.

Logs


Log of interaction between DCImanager and the billing system is recorded in the file  '/usr/local/mgr5/var/pmdcimgr.log'.

You can identify certain operations in the log by using the following records:

'processing/pmdcimgr --runningoperation <current operation code> --command open' — service opening

'processing/pmdcimgr --runningoperation <current operation code>  --command close — service closing

'processing/pmdcimgr --command sync_server --module <processing module code>' — data synchronization

'processing/pmdcimgr --command stat --module <processing module code>' — statistics collection 

'processing/pmdcimgr --command fixip  --module <processing module code>' — synchronization of IP-address lists