Providing VMware-based cloud resources with BILLmanager. Or how the new CloudLITE personal account appeared
This story is about how ISPsystem and the leading Russian cloud provider DataLine found each other at the WHD.global conference in Germany and what came of it. We told about the high adaptability of BILLmanager , and colleagues from DataLine needed a new personal account for their CloudLITE project. As a result, a month later DataLine asked us to adapt BILLmanager to provide cloud resources based on VMware.
We gladly set to work, and first of all, together with DataLine, we identified the shortcomings of their previous billing platform:
- The inability to independently change the payer from an individual to a legal entity. Very often, companies “try on” CloudLITE for their tasks on behalf of “physics” in order to optimize costs.
- Lack of flexibility in the pricing of services. Payment took place on the 1st day of each month, and if there was not enough money in the account for all 30/31 days, the provision of services was blocked. Daily debit was not.
- The lack of a mechanism to manage your VDS directly from billing. It was possible to perform the configuration only via vCloud Director, and its interface, in turn, scared users away with its complexity: the abundance of buttons and settings was confusing. As it turned out, most users do not need to finely configure their virtual machines, a generic enough pattern.
DataLine described all these points in great detail in the article about CloudLITE 2.0. We recommend reading.
')
After identifying the minuses of the former platform, a thorough examination of BILLmanager by DataLine specialists followed. During this work, we answered questions that arose and conducted webinars to make the study of our billing platform as comfortable as possible. As a result of the tests carried out by the partner, one of the best technical tasks in our practice was compiled. Then the TK was discussed and corrected. We carefully studied the document, revealed “subtle points” and offered more effective methods for solving them, based on our experience.
After approval of the TK, the general work plan became clear:
- Redo the BILLmanager interface in accordance with the company's corporate style and DataLine's wishes;
- Implement a new type of service, “Virtual Data Center,” and a simplified mechanism for managing its virtual machines;
- Write a handler to interact with the VMware vCloud API.
It remained only to establish the timing of the launch of the Minimal Viable Product. To do this, both parties put stamps-signatures under the dates, and the work began to boil.
Development process
Every Thursday we showed the customer the results of the week. On Friday, the project team worked through the comments, after which a video conference was held on the same day if necessary. In addition, DataLine employees at any time could go to the test bench and literally “on the fly” to observe how new features appear.
It should be noted that the description of noteworthy organizational issues and management decisions in the project draws on a separate and rather big habrapost. We are already killing material. And in this article I would like to talk about the most interesting and complex technical aspects of development.
The first key point is the creation of a virtual machine in the ACC from BILLmanager.
Algorithm
All actions are performed with VDC administrator rights.
1. On the billing side, VM creation is initiated.
You must fill the following fields:
1.1. VApp template;
1.2. Organization network (if at least one organization level network is created in the current VDC);
1.3. Name vApp (if there are created vApps, then it will be possible to specify an existing vApp);
1.4. VM name;
1.5. VM password;
1.6. Parameters VM (HDD, CPU, MEM). All parameters are governed by the values ​​specified within the vApp template.
2. A VM is created on the VMware vCloud API side.
2.1. Create a new vApp;
2.1.1. Install new vApp;
2.1.2. When specifying the network to which vApp is connected, we create a network of the vApp level;
2.1.3. We connect the VM to the network level vApp;
2.1.4. Get the list of VM's IP addresses (internal / external);
2.1.5. We get the name of the OS;
2.1.6. Apply VM parameters (HDD, CPU, MEM);
2.1.7. We give BILLmanager 5 the result of creating a VM (success / failure).
2.2. Adding VM to existing vApp;
2.2.1. We recompose the existing vApp;
2.2.2. Apply VM parameters (HDD, CPU, MEM);
2.2.3. We get the name of the OS;
2.2.4. Check if there is a vApp network connected to the organization’s network (if specified in BILLmanager 5). If there is no network, then create it.
We return to the level above, we continue to create vApp
2.1.8. We connect the VM to the network level vApp;
2.1.9. Get the list of VM's IP addresses (internal / external);
2.1.10. We give BILLmanager 5 the result of creating a VM (success / failure).
1. On the billing side, VM creation is initiated.
You must fill the following fields:
1.1. VApp template;
1.2. Organization network (if at least one organization level network is created in the current VDC);
1.3. Name vApp (if there are created vApps, then it will be possible to specify an existing vApp);
1.4. VM name;
1.5. VM password;
1.6. Parameters VM (HDD, CPU, MEM). All parameters are governed by the values ​​specified within the vApp template.
2. A VM is created on the VMware vCloud API side.
2.1. Create a new vApp;
2.1.1. Install new vApp;
2.1.2. When specifying the network to which vApp is connected, we create a network of the vApp level;
2.1.3. We connect the VM to the network level vApp;
2.1.4. Get the list of VM's IP addresses (internal / external);
2.1.5. We get the name of the OS;
2.1.6. Apply VM parameters (HDD, CPU, MEM);
2.1.7. We give BILLmanager 5 the result of creating a VM (success / failure).
2.2. Adding VM to existing vApp;
2.2.1. We recompose the existing vApp;
2.2.2. Apply VM parameters (HDD, CPU, MEM);
2.2.3. We get the name of the OS;
2.2.4. Check if there is a vApp network connected to the organization’s network (if specified in BILLmanager 5). If there is no network, then create it.
We return to the level above, we continue to create vApp
2.1.8. We connect the VM to the network level vApp;
2.1.9. Get the list of VM's IP addresses (internal / external);
2.1.10. We give BILLmanager 5 the result of creating a VM (success / failure).
The second one is bidirectional synchronization of virtual machine states between vCloud and the billing system, both in automatic and manual mode.
Details
During synchronization, statistics is collected from the ACC. We get such a “package”:
Decipher what is what.
All these values ​​are aggregated by BILLmanager.
- Synchronization of all virtual data centers occurs automatically every 30 minutes (there is a task in the scheduler);
- User VDC synchronization can be started manually by pressing the “Refresh” button in the virtual machines menu in the billing platform.
During synchronization, statistics is collected from the ACC. We get such a “package”:
<item id="2560" status="true" vdcid="9fdc0391-4a27-4a6c-9b9f-91137849c1da"> <net name="orgnet-ISP_TEST2">4b9de9ad-a4d1-44e5-a846-0143c380e854</net> <vapp id="vapp-ef6ed6d8-6538-440a-a91c-3dd5574c8787" name="qwe" status="8"> <vm id="vm-7e779303-8bb5-46c0-b4b9-8973bf4b18f5" name="qwe" status="8" ext_ip="92.242.45.21" int_ip="192.168.100.100" vapp_template="3dd2ee97-2f2d-465b-b5d4-2c4e0f07c225"> <os value="CentOS 4/5/6 (32-bit)"/> <password value="!R3!e3C7"/> <disc id="2000" reserved="10240"/> <cpu reserved="1"/> <mem reserved="1024"/> </vm> </vapp> </item> Decipher what is what.
1. <item id="2560" status="true" vdcid="9fdc0391-4a27-4a6c-9b9f-91137849c1da">...</item> 1.1. id – ID BILLmanager; 1.2. status – VDC; 1.3. vdcid – UUID -. 2. <net name="orgnet-ISP_TEST2">4b9de9ad-a4d1-44e5-a846-0143c380e854</net> 2.1. name – ; 2.2. – UUID. 3. <vapp id="vapp-ef6ed6d8-6538-440a-a91c-3dd5574c8787" name="qwe" status="8">...</vapp> 3.1. id – UUID vApp; 3.2. name – vApp; 3.3. status – vApp (6 - Process, 4 - Active, 3 - Suspended, 8 - Stopped). 4. <vm id="vm-7e779303-8bb5-46c0-b4b9-8973bf4b18f5" name="qwe" status="8" ext_ip="92.242.45.21" int_ip="192.168.100.100" vapp_template="3dd2ee97-2f2d-465b-b5d4-2c4e0f07c225">...</vm> 4.1. id – UUID ; 4.2. name – ; 4.3. status – . ; 4.4. ext_ip – IP ; 4.5. int_ip – IP ; 4.6. vapp_template – vApp Template ( ), . 5. : 5.1. <os value="CentOS 4/5/6 (32-bit)"/> – ; 5.2. <password value="!R3!e3C7"/> – ; 5.3. <disc id="2000" reserved="10240"/> – ID ; 5.4. <cpu reserved="1"/> – CPU; 5.5. <mem reserved="1024"/> – MEM . All these values ​​are aggregated by BILLmanager.
The third is access to the virtual machine web console just updated by VMware.
We felt like pioneers, because at that time no one but us had time to do this integration.
Source
When sending to the client, we substitute the following fields on this form:
"__VMNAME__" is the name of the virtual machine;
"__VMX__" - a link to the VMX file of the virtual machine;
"__HOST__" is the name of the host (or proxy server) through which the connection to the console is made;
"__PORT__" - port for connecting the console;
"__TICKET__" is the secret key for client authentication.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html> <head> <meta charset="utf-8"/> <title>vCloud WebConsole: __VMNAME__</title> <link rel="stylesheet" type="text/css" href="../manimg/wmks/css/css/wmks-all.css"/> <script type="text/javascript" src="https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.8.3.js"></script> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.js"></script> <script type="text/javascript" src="../manimg/wmks/wmks.min.js"></script> </head> <body style="overflow-x:hidden; overflow-y:hidden; padding:0; margin: 0;"> <div id="toolbar" style="position:relative; width:100%; height:5%;"> <table cellpadding="5" cellspacing="0" border="0" align="center"> <tr> <td> <input type="button" value="Send Ctrl+Alt+Del" onclick="wmks.sendKeyCodes([17,18,46])"/> </td> </tr> </table> </div> <div id="wmksContainer" style="position:relative; width:100%; height:95%;"/> <script> var wmks = WMKS.createWMKS("wmksContainer", { "VCDProxyHandshakeVmxPath": "__VMX__", "useVNCHandshake": false, "enableUint8Utf8": true, "rescale": true, "changeResolution": true, "useUnicodeKeyboardInput": true, "position": WMKS.CONST.Position.CENTER }); wmks.register(WMKS.CONST.Events.CONNECTION_STATE_CHANGE, function(event, data) { console.log("Connection state change : " + data.state); }); wmks.register(WMKS.CONST.Events.ERROR, function(event, data) { console.log("Connection error : " + data.error); }); wmks.connect("wss://__HOST__/__PORT__;__TICKET__"); </script> </body> </html> When sending to the client, we substitute the following fields on this form:
"__VMNAME__" is the name of the virtual machine;
"__VMX__" - a link to the VMX file of the virtual machine;
"__HOST__" is the name of the host (or proxy server) through which the connection to the console is made;
"__PORT__" - port for connecting the console;
"__TICKET__" is the secret key for client authentication.
Of course, not everything went smoothly: we often ran into errors in the cloud platform, and the implementation of some algorithms took longer than expected. There were moments when it was very difficult to decide what to do next. For example, the episode when, with the already ongoing beta testing of CloudLITE, the vCloud Director bug showed itself. Therefore, the creation of new virtual machines was impossible.
Essence: if you request through the API a list of IP addresses associated with the virtual data center, then a maximum of 128 will be returned, even if there are more. A detailed description, if anyone is interested, you can read here .
There were two options: search for workarounds or update Director. In the first case, the decision was cumbersome. In the second case, there was a considerable risk of server failures when rolling updates. In addition, we integrated BILLmanager with the old version; how everything will work with the new one is unknown. What to do?
As a result, it was decided to upgrade the cloud platform. Fortunately, the process went without any incidents, the billing platform also worked properly.
results
Thanks to the professionalism of our developers and the quick response of DataLine to the requests coming to them, we have solved the task of integrating with vCloud without delays. The release of the Minimal Viable Product took place at the originally established time. Whoever first guesses how many lines of code has been written — plus that in karma; “hit” is counted in a radius of 100 lines.
What we did:
- Intuitive personal account for customers, having a simplified control panel of virtual machines. It became possible to create, start, stop and delete a virtual machine; connect to it through the web console. If necessary, then change the number of processor cores, the amount of RAM, and also increase the virtual hard disk. Thus, in the overwhelming majority of cases, clients no longer need to access the bulky vCloud Director interface.
- Providing access to services while there are funds to pay for one day.
- The ability to self-change the payer from an individual to a legal entity.
DataLine appreciated the final result.
We did not stop at what we have achieved and standardize the handler interacting with vCloud. Now it is available for free in BILLmanager 5 Corporate for those who plan to provide cloud services based on this product from VMware. To enable this handler, go to “Integration” → “Service Handlers”, create a new one for the type of service you need by selecting the processing module “VMware vCloud Director”. Then, in the list of tariffs, select the desired one, click the “Processors” button and turn on the newly created one. Everything, interaction with the cloud platform will now be performed automatically.
Our future plans include the development of integration with other cloud solutions. Follow the news!
PS If you want to install BILLmanager - instructions on how to do this can be found here .
Source: https://habr.com/ru/post/309282/
All Articles