When you planned your hosting business, you probably distinguished your hardware abilities by purpose. For example, one part of your machines will place a customer's webspaces, another part will store a customer's databases, and so on. So that autoprovisioning is used when the services are created and provisioned automatically after the customer's payment is approved and a subscription is activated.
How auto-provisioning works in CloudBlue Commerce:
- The customer goes to an online store and buys a hosting plan.
- The customer's order and the subsequent payment is processed and approved.
- CloudBlue Commerce is set the task of providing the resources included in the hosting plan, that is, allotting disk space, creating a database, activating a mail service, filling in DNS records and so on.
- CloudBlue Commerce starts to scan the network for the hardware nodes or VPSs which have the packages necessary to provide a service there. Let us imagine that the task is to provide a webspace. The webspace service needs the hardware node or VPS with the apache installed. CloudBlue Commerce finds four such hosts.
- One of them is not marked as ready to provide, leaving only three suitable options.
- Now CloudBlue Commerce selects the least loaded of them and creates the webspace there.
However, the apache service is installed not only on servers intended for storing customer's webspaces, but also installed on a UI server. So, CloudBlue Commerce can place a webspace there, if this host is considered the least loaded at that moment.
In the figure below, you can see how a webspace service can be improperly provided, if there are no attributes.
To avoid situations when the service is provisioned "in the wrong place", the attributes mechanism was developed. We "mark" the resource (more precisely, resource type) to be provided with a special label. The same label is marked on the hardware node or VPS where this resource must be placed.
The second scheme shows how provisioning works if we use the Attributes mechanism.
We also need attributes when we want to distinguish hosting services according to Quality of Service.
Let us assume that we have two server parks: the machines in the first park are very fast, reliable, capacious and expensive. The second park is less powerful but not so costly. So, we decide to create two hosting plans: for example, a "Gold Hosting Plan" and a "Silver Hosting Plan". The "Gold Hosting Plan" will be provisioned in the first park, the Silver in the second park.
To distinguish the servers according to our hosting plans we employ the same attribute mechanism.
We create two sets of resource types and two attributes: "gold" and "silver". Then, we mark the resources of the first set and the servers from the first park with the "gold" attribute. We then mark the resources of the second set and the machines of the second park (which is less powerful) with the "silver" attribute. After that, we create the "Gold" service template and include the resources marked with the "gold" attribute and do the same for the "Silver" service template.
The figure is an example of this scenario:
Here we can see that the resources marked only with the "gold" attribute are included into the "Gold Hosting Plan". These resources will be provisioned on powerful servers, because they are marked with the same attribute.
Essentially, attributes serve to "link" the resources with the hardware node or VPS this resource should be provisioned on.
Important: The same mechanism works with databases. If you have several database servers of the same type (MySQL or PostgreSQL) in the system, when a customer adds a new database, this database will be created on any of the servers so that the number of databases is equally distributed among the servers.