This is Part II of the series "How to build a private IaaS cloud platform?", elaborating about the platform requirements to face when building a multipurpose Infrastructure as a Service platform.
In this post we are looking into the requirements the chosen virtualization technology has to fulfill.
See the Main Summary Post with links to the other sections (requirements analysis for OS, shared storage, virtualization, etc) here.
Part II: Virtualization
Requirements list:
- Virtualization performance penalty: Virtualisation technologies are often - and in some cases, legitimately - considered as performance bottlenecks. Emulating complete virtual machines is not easy to implement, mapping to physical devices, scheduling computing requests from virtual CPUs to physical strands, channeling I/O... The goal is of course to keep the performance loss minimal in a virtualized environment so that your IaaS platform can scale well.
- Livemigration between hosts: Physics is bound to have failures. Fault tolerance, power management and server maintainability, requires Virtual Machines to be migrateable in a live fashion, that is, without downtime from one physical host to another one. This must happen in a secure and automatable way.
- Dynamic reconfiguration: Of course one wants to adjust the resources of running VMs without downtime, like adding/growing virtual disks or network interfaces, assigning more CPUs/threads and/or RAM. This of course must happen in cooperation of the operating system running in the VM, that is, with OS awareness.
- Software license boundaries: This one isn't actually a technical requirement, but rather an organisational one. Providing VMs running - for example - an Oracle Database to your customers is a great idea - but customers tend to prefer to be charged only for licenses of the CPUs dedicated to their VMs and not for the whole server. Not all virtualisation technologies are approved license boundaries.
- Virtualisation costs: Of course the less costs come up for adding a virtualisation technology to your stack, the happier the management level will be.
Alright, we got this far. We have some important requirements to fulfill. Now let me introduce you to Oracle VM for SPARC (former LDoms) in case you were not familiar with them - and also, allow me to show you how they fulfill these requirements.
How OVM for SPARC fulfills these requirements:
- Avoiding virtualization performance penalty: OVM for SPARC, aka LDoms are not an emulating type virtualisation, but a partitioning type. The hypervisor actually runs in the firmware of the server. That is, on SPARC servers with the S3 CPU core (T4...) systemadministrators do not emulate servers/VMs but they carve up the physical serverhardware in separate partitions, all with native CPU and Memory dedication, and - depending on the configuration - even with physical I/O. That is, isolated Operating Systems installed in the separate LDoms run natively on the hardware. No virtualization performance loss.
Conclusion: With OVM for SPARC system engineers get the complete performance of the serverhardware, which makes it an ideal target for heavily virtualized environments, like IaaS cloud platforms. - Livemigration between physical hosts: Livemigration is of course taken for granted - but what makes this implementation special is rather the security of the migration and the integration of automatisms.
- LDoms have Secure Livemigration, because the traffic between the physical nodes is secured via encryption. Not only it is encrypted, but also encrypted with HW support, with the famous HW-cryptoengine of the SPARC S3 CPU cores.
- The livemigration feature can be integrated with Solaris Cluster, enabling LDoms to be part of a multipurpose HA-platform. Another option is to utilize EM Ops Center, the datacenter infrastructure management tool originating from Sun Microsystems, that can remotely manage different virtualization technologies, including LDoms with livemigration.
Conclusion: Security, HighAvailability and Managability distinguis LDoms for Infrastructure as a Service platforms.
- Dynamic reconfiguration: Systemadministrators can add (and remove) RAM, CPU, network interfaces, disks, PCI slots, cryptounits to running LDoms. The OS, of course must be able to handle inflight HW configuration changes, but Solaris did that since the '90s. Dynamic reconfiguration adds up to availability of running services immensely.
- Software license boundaries: LDoms are a license hard-partitioning approved virtualisation technology and can effectively limite the necessary number of licenses to the configured VMs. This enables platform administrators to easily implement license chargeback mechanisms for their customers.
- Virtualisation costs: Using LDoms does not need to be licensed. They are simply a feature of the Servers. If your goal is to minimize virtualization costs, here you go. Minimized to zero.
SUMMARY
LDoms fulfill the most common IaaS platform requirements for virtualization technologies with native Server performance, secure livemigration, dynamic reconfiguration, approved software license boundaries and zero virtualisation costs.
In the previous post we had a look into the requirements for servers for IaaS platforms, and how the SPARC-T Servers fulfill those.
In the next post we will look into the requirements for an Operating System of choice for IaaS platforms.
If questions arise, do not hesitate to comment.-- charlie