One of the critical time-savers and benefits of using VM or hypervisor technology is the ability to define one or more VM images. These machine images, also called VM templates, are preconfigured images of the OS, updates and patches, and any software applications. When a cloud customer orders a new VM, it can select from one or more VM templates, with each one offering a unique configuration, OS version, or pre-installed applications. Upon the automated provision- ing of each VM, the hypervisor copies the template and the OS is booted—all within seconds. The cloud system can normally boot dozens, if not hundreds, of new VMs within minutes of being ordered, which is a capability provided by automation within the cloud management system.
It is best to avoid having so many templates that their management becomes a burden. For every template you have, you must also manage that template going forward so that the latest OS version, patches, and applications are preloaded. If you have too many variations of the templates because every customer claims they are “unique,” you end up paying for the management of all these templates, either directly or through the cost of the hosted cloud service provider. Also understand that when you take on responsibility for each VM template, you own all future updates and new OS revisions for that VM until that OS is retired many years from now.
Another consideration is the use of templates and “recipe-based” application installation packages. Templates are fully configured images of a disk preconfigured with an OS and applications. An installation package approach means that you stick with a very basic template that contains the base OS to launch the VM, followed by a scripted installation process that installs all of the latest updates and most of the application software. Using this installation approach, you can have fewer templates, and whenever you want to change or update your cloud service offering, you simply change the scripts and application installation packages.
Fig – Virtualization + cloud attributes = cloud computing
Within each VM are virtual network interface cards (NICs). These virtual cards emulate physical NICs found in a physical server. The flexibility is tremendous in a VM environment, because you can have numerous virtual networks per VM, creating sub-networks for VMs to communicate with one another, all within the same physical server. You can create multilayer networks for front-end web application servers, middleware application servers, and back-end database servers, each with their own network subnet and each using virtualized NICs. Of course, some of the virtual NICs will need an external network address and connection to the real production network.
The key here is that you do not need to use physical network switches, routers, and load balancers to set up all of the networking, VLANs, and subnets you need. The virtual networking tools within the hypervi- sor can handle much of the work and be launched and configured in an automated fashion when a customer orders and starts a new VM. You can configure this level of automation on physical network hardware, but it is often risky and against traditional IT security policies.
Virtualization of storage is typically implemented by using a SAN or other hard- ware and software devices that present massive pools of storage through a unified storage management interface. When you configure and start a VM, the needed amount of storage is allocated from the existing pool of available storage logical unit numbers (LUNs) on the SAN. Storage is mapped to VMs over a SAN or network fabric or switch in most cases.
Storage needs, whether structured or unstructured, increase massively each year. To handle this data, there are two possible solutions: either store less data for less time, or keep increasing the storage. Many organizations are finally starting to realize that they cannot keep up with the amount of new data being created and are thus setting limits on what should be stored—and more important, evaluating whether we really need to keep aging data forever. For those organizations that cannot delete older data, due perhaps to compliance or legal reasons, storage technologies such as compression and de-duplication come into play.
The relationship between storage and cloud compute is clear. You cannot have cloud computing without storage, and currently, disk-based storage (or hard drives) is the primary method. Advancements in solid-state drives (SSDs) and memory-based storage will ultimately bring about the end of disk platters within storage systems. We will also see technologies such as memory resistors (or memristors, for short) potentially replace all existing storage devices. This storage technology is important both in terms of capacity and performance, but it would take an entire book to cover this development in great detail.
As for the importance of storage as it relates to cloud computing, the back- end storage system for a cloud service requires unique characteristics that might not normally be required of traditional server farms:
