Powerful and cloud agnostic VM placement policies are an important topic of high relevance for us. Together with VMware, we commonly address this topic as part of the design partnership “developer cloud”. What do we mean with VM placement policies: Imagine a system able to provision your VMs to the optimal location based on the selection criteria you are providing. How could such a system look like?
Let’s name any kind of resource a “Qualified Resource Provider”, this can be any consumable resource with static and dynamic capabilities like free space, access time, redundancy, location, security features. All these capabilities are qualified and quantified by standardized tags that are all together defining the services that such a QRP is offering.
A “Qualified Resource Consumer” could be a multi-machine blueprint that is defining the minimum requirements for each of its parts for provisioning the entire service.
Consumer and provider are interacting in the following life cycle phases of the software defined assets:
A new blueprint gets designed. The blueprint architect is offered all the capabilities needed to define the requirements of the service to be created. In this phase the capabilities are not restricted to the supported ones of any concrete QRPs – it is a rather provider agnostic specification for a service. In a sophisticated implementation, however, it could be very helpful to have access to concrete asset catalogs of concrete service providers i.e. public clouds or the local catalog of a private cloud to leverage the specific USP of each provider, like specific database-capabilities or heterogenous/native libraries etc.
Publishing and importing phase
A blueprint with defined requirements gets published in any type of blueprint catalog from where it can be imported to any system that supports that blueprint orchestration. On importing a blueprint to any concrete combination of QRPs the blueprint should be validated against the registered capabilities of the target system. If a requirement cannot be met this must lead to an error message – maybe with the possibility to manually override certain settings or even adapt the blueprint.
A successfully imported blueprint can be selected for provisioning and should be adaptable in certain parameters. The UI needs to display valid parameter combinations that take into account the possible deployment targets of the systems. For a multi-machine blueprint this could even be a combination of multiple targets (i.e. private and public cloud resources). The QRP selection mechanism should be able to predict (or simulate) the outcome of the provisioning process – with the possibility of overriding manually – and highlight the factors that determine the eventual placement.
Upgrading or migration phase
A provisioned service shall be changed or migrated by changing the requirements of the underlying blueprint. This is constrained by the capabilities of the possible target QRPs. A proper UI is required to guide the user throughout this process.
Describing Requirements and Capabilities
Blueprints are defining all the components of the service to be provisioned is comprised including the QRP selection criteria. The criteria should be defined in a standardized and portable way (not dependent on a specific stack installation or vendor or any possible target) and should allow to distinct in optional and mandatory requirements or rules. All elements may be specified individually for all criteria that could be applied and there should be rules that must be applied also on aggregations or on the entire blueprint (i.e. all parts must be deployed in Switzerland).
Static capabilities are
- public/private cloud
- read/write speed of storage
- mirrored storage
- ITBC capabilities (DR, stretched clusters)
- License optimizations (MS SQL cluster)
- Network bandwidth
- Flexibility (register for account, need contract?)
- Regulatory requirements (encryption, location, auditability)
- Stages like development, integration, production
- Security zones like internet, extranet, intranet, web server zone, app server zone, database zone
Dynamic capabilities are
- Affinity, anti-affinity
- Usage-strategies: fill or distribute
- Available/used storage space,
- Available/used compute capacity
- Available/used IP addresses
Possible additional topics
The listed capabilities only focus on VMs (IaaS). For a future proof concept we should also include containers and PaaS.
The blueprint defines an eCommerce App and offers some options within its constraints.
The request defines a concrete provisioning request making a choice of the offered options and specifying a target environment.
Blueprint and request combined result in the effective deployment constraints that are defining the placement requirements to be met for the provisioning process.
The resource profile is a set of definitions of qualified resource providers as discussed at the beginning of the document whereas the resource pool is a concrete target environment composed of qualified resource providers.
With this the process of provisioning a predefined blueprint is well defined with the exception that we should take care that the UI form for creating the request should be enabled to narrow down the choices for the user per target environment. In the above example a blueprint that defines a MS SQL server should not be accepted already on assembling the request if there is no target environment offering the needed qualified resource provider. Request choices can be dependent on each other and should be validated as early as possible and reasonable error messages for a comfortable user navigation should be provided.
A simulation that only evaluates the deployment constraints to define the final placing without processing it could be very helpful. And tracking & logging on a very detailed level is crucial to enabling the users to help themselves when the system does not behave in the way they expect.
Recommended additional reading:
Thanks to Marco and Simon for reviewing this blog post and to Helen Michaud for the inspiring design partnership sessions.