0% found this document useful (0 votes)
4 views15 pages

Cloud Computing Unit4

Virtualization technology is pivotal in enabling cloud computing and transforming enterprise data centers by allowing the creation of private cloud infrastructures. It involves the use of virtual machines (VMs) that provide users with the illusion of independent hardware systems, managed by a virtual machine monitor (VMM) or hypervisor. Key features include the ability to run multiple operating systems on the same physical hardware, elastic computing capabilities, and advanced functionalities like virtual machine migration for resource optimization.

Uploaded by

prudvi mudavath
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
0% found this document useful (0 votes)
4 views15 pages

Cloud Computing Unit4

Virtualization technology is pivotal in enabling cloud computing and transforming enterprise data centers by allowing the creation of private cloud infrastructures. It involves the use of virtual machines (VMs) that provide users with the illusion of independent hardware systems, managed by a virtual machine monitor (VMM) or hypervisor. Key features include the ability to run multiple operating systems on the same physical hardware, elastic computing capabilities, and advanced functionalities like virtual machine migration for resource optimization.

Uploaded by

prudvi mudavath
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
Virtualization technology Ifone had to choose a single technology that has been most influential in enabling the cloud computing paradigm, it would have to be virtualization. Aswe have seen earlier in Chapter 1, virtualization is not new, and dates back to the early mainframes as a means of sharing computing resources amongst users, Today, besides underpinning cloud computing platforms, virtualiza- tion is revolutionizing the way enterprise data centers are built and managed, paving the way for enterprises to deploy ‘private cloud’ infrastructure within their data centers. 8.1 VIRTUAL MACHINE TECHNOLOGY We begin with an overview of virtual machine technology: In. general, any means by which many different users are able simultaneously to interact with a computing system while each perceiving that they have an entire ‘virtual machine’ to themselves, is a form of virtualization. In this general sense, a traditional multiprogramming operating system, such as Linux, isalso a form of virtualization, since it allows each user process to access system resources oblivious of other processes. The abstraction provided to each process is the set of OS system calls and any hardware instructions accessible to user- level processes. Extensions, such as ‘user mode Linux’ [17] offer a more complete virtual abstraction where each user is not even aware of other user's Processes, and can login as an administrator, i.e. ‘root,’ to their own seemingly 89 Ua VIRTUALIZATION TECHNOLog, Private operating system, ‘Virtual private servers’ are another such abstraction (36). Ata higher level of abstraction are virtual machines based on igh-Lergy Tanguages, such as the Java virtual machine QVM) which itself runs és Operating system process but provides a system-independent abstraction of the machine to an application written in the Java language. Such abstractions which present an abstraction at the OS system call layer or higher, are called Process virtual machines. Some cloud platforms, such as Google's App Engine and Microsoft's Azure, also Provide a process virtual machine abstraction in the context of a web-based architecture. More commonly, however, the virtual machines we discussing virtualization in enterprises or for infrastructure clouds such as Amazon's EC2 are system virtual tachines that offer a complete hard. ware instruction set as the abstraction provided to users of different virtual machines. In this model many system virtual machine (VM) instances share the same physical hardware through a virtual machine monitor (VMM), also commonly referred to as a hypervisor. Each such system VM can run an inde- pendent operating system instance; thus the ‘same physical machine can have many instances of, say Linux and Windows, running on it simultaneously The system VM approach is preferred because it pr ‘ovides complete isolation between VMs as well as the highest possible flexibility, with each VM seeing a complete machine instruction set, } against which any applications for that architecture are guaranteed to run, Itis the virtual machine monitor that enables a physical machine to be virtualized into different VMs. Where does this software itself run? A host VMM is implemented as a process running on a host operating system that has been installed on the machine in the normal manner, Multiple guest operating systems can be installed on different VMs that each run as operating system processes under the supervision of the VMM. A native VMM, on the other hand, does not Tequire a host operating system, and runs directly on the physical machine (or more colloquially on ‘bare metal). In this sense, a native VMM can be viewed as a special type of operating system, since it Supports multiprogramming across different VMs, with its ‘system calls’ being hardware instructions! Figure 8.1 illustrates the difference between process virtual machines, host VMMs and native VMMs, Most commonly used VMMS, such as the open source Xen hypervisor as well as products from VMware are available in both hosted as well as native versions; for example the hosted Xen (HXen) project and VMware Workstation products are hosted ie whereas the more popularly used XenServer (or just Xen) and VMware E: Server products are native VMMs. usually refer to when 1 machine techolOBy Ey gb g Ae : . a Bel #/ Tells] (oi) [ell B] 122) eye} alla Guest OS Guestos} | & || || 8 ‘Virtual Machine Monitor Guest OS Guest OS (Host VMM) Virtual Machine Monitor ‘Operating sytem (Native VM) Hardware Hardware. ‘System Virtual Machines ‘System Virtual Machines (Host) (Native) Ficure 8.4. Virtual machines Jn the next section we shall briefly describe how system virtual machines areimplemented efficiently and how individual virtual machines actually run. gid System virtual machines A system virtual machine monitor needs to provide each virtual machine the illusion that it has access to a complete independent hardware system. through a full instruction set. In a sense, this is very similar to the need for a time-sharing operating system to provide different processes access to hardware resources in their allotted time intervals of execution. However, there are fundamental differences between the ‘virtual machine’ as perceived bya traditional operating system processes and a true system VM: 1, Processes under an operating system are allowed access to hardware “through system calls, whereas a system VMM needs to provide a full hardware instruction set for use by each virtual machine 2. Each system virtual machine needs to be able to runa full operating system, “While itself maintaining isolation with other virtual machines. "Going forward we will focus our discussion on native VMMs that run directly on the hardware, like an operating system; native VMMs are more efficient and therefore the ones used in practice within enterprises as well 4s cloud platforms. One way a native system VMM could work is by emu- ig instructions of the target instruction set and maintaining the state of a VIRTUALIZATION TECHN), Ogy different virtual machines at all levels of memory hierarch; isters etc.) indirectly in memory and switching between required, in a manner similar to how virtual memory ferent processes are maintained by an operating system. In cases wh, target hardware instruction set and actual machine architecture are ya emulation and indirection is unavoidable, and, understandably, tn However, in cases where the target instruction set is the same ag int" the actual hardware on which the native VMM is running, the VM al implemented more efficiently. ne An efficient native VMM attempts to run the instructions of each virtual machines natively on the hardware, and while doing so also mai the state of the machine at its proper location in the memory hierarc] much the same manner as an operating system runs process code Nati far as possible except when required. Let us first recall how an operating system runs a process: The Process state is first loaded into memory and registers, then the program counter is reset so that process code runs from thereon. The process runs until a timer event occurs, at which point the operating system switches the process and resets the timer via a special privileged instruction. The key to this mecha. nism is the presence of privileged instructions, such as resetting the timer interrupt, which cause a trap (a program generated interrupt) when mm in ‘user’ mode instead of ‘system’ mode. Thus, no user process can set the timer interrupt, since this instruction is privileged and always traps, in [Link] to the operating system. Thus, it should be possible to build a VMM in exactly the same manner as an operating system, by trapping the privileged instructions and running all others natively on the hardware. Clearly the privileged instructions them- selves need to be emulated, so that when an operating system running ina virtual machine attempts to, say, set the timer interrupt, it actually sets a virtual timer interrupt. Such a VMM, where only privileged instructions need to be emulated, is the most efficient native VMM possible, as formally proved in [45]. However, in reality it is not always possible to achieve this level of effi- ciency. There are some instruction sets (including the popular Intel 14-32, better known as x86) where some non-privileged instructions behave differ- ently depending on whether they are called in user mode orsystem mode. Such instruction sets implicitly assume that there will be only one operating syst¢™ (or equivalent) program that needs access to privileged instructions, a natu! assumption in the absence of virtualization. However, such instructions Pa a problem for virtual machines, in which the operating system is actually Y (includ, these as anq° "8 Page tables ae of is intain hy, in vely as a4 vitwal machine technology 93 mnning in user mode rather than system mode. Thus, it is necessary for the ait to also emulate such instructions in addition to all privileged instruc- tions. Newer editions of the x86 family have begun to include ‘hardware support’ for virtualization, where such anomalous behavior can be recti- fied by exploiting additional hardware features, tesulting in a more efficient implementation of virtualization: For example, Intel's VI-x (Vanderpool) technology includes a new VMX mode of operation. When VMX is enabled there is a new ‘oot’ mode of operation exclusively for use by the VMM; in non-root mode all standard modes of operation are available for the OS and applications, including a ‘system’ mode which is at a lower level of privilege than what the VMM enjoys. We do not discuss system virtual machines in more detail here, as the purpose of this discussion was to give some insight into the issues that are involved through a few examples; a detailed treatment can be found in [58]. 8.1.2 Virtual machines and elastic computing We have seen how virtual machine technology enables decoupling physical hardware from the virtual machines that run on them. Virtual machines can have different instruction sets from the physical hardware if needed. Even if the instruction sets are the same (which is needed for efficiency), the size and number of the physical resources seen by each virtual machine need not be the same as that of the physical machine, and in fact will usually be different. The VMM partitions the actual physical resources in time, such as with YO and network devices, or space, as with storage and memory. In the case of multiple CPUs, compute power can also be partitioned in time (using tradi- tional time slices), or in space, in which case each CPU is reserved for a subset » of virtual machines. The term ‘elastic computing’ has become popular when discussing cloud computing. The Amazon ‘elastic’ cloud computing platform makes extensive use of virtualization based on the Xen hypervisor. Reserving and booting 4 Server instance on the Amazon EC cloud provisions and starts a virtual machine on one of Amazon's servers. The configuration of the required virtual Machine can be chosen from a set of options (see Chapter 5). The user of the ‘virtual instance’ is unaware and oblivious to which physical server the stance has been booted on, as well as the resource characteristics of the Physical machine, An ‘elastic’ multi-server environment is one which is completely virtual- ed, with all hardware resources running under a set of cooperating virtual 94 VIRTUALIZATION TECHNo|, ay machine monitors and in which provisioning of virtual machines “ye automated and can be dynamically controlled according to demand’ "8 eral, any multi-server environment can be made ‘elastic’ using virtualiz, a in much the same manner as has been done in Amazon's cloud, and @”" what many enterprise virtualization projects attempt to do. The key gi°> factors in achieving such elasticity is the degree of automation that Bein achieved actoss multiple VMMs working together to maximize util " The scale of such operations is also important, which in the case of Amazon cloud runs into tens of thousands of servers, if not more. The larger the en’ the greater the potential for amortizing demand effciently actoss the avai capacity while also giving users an illusion of ‘infinite’ computing resources Technology to achieve elastic computing at scale is, today, largely pre, Prietary and in the hands of the major cloud providers. Some automated Provisioning technology is available in the public domain or commercially off the shelf (see Chapter 17), and is being used by many enterprises in their internal data center automation efforts. Apart from many startup companies, VMware's VirtualCentre product suite aims to provide this capability through its ‘VCloud’ architecture. We shall discuss the features of an elastic data center in more detail later in this chapter; first we cover virtual machine migration, which is a pre-requisite for many of these capabilities. ization, 8.1.3 Virtual machine migration Another feature that is crucial for advanced ‘elastic’ infrastructure capabilities is ‘in-flight migration of virtual machines, such as provided in VMware's VMo- tion product. This feature, which should also be considered a key component for ‘elasticity,’ enables a virtual machine running on one physical machine to be suspended, its state saved and transported to or accessed from another physical machine where it is resumes execution from exactly the same state. Virtual machine migration has been studied in the systems research com munity [49] as wellas in related areas such as grid computing [29]. Migrating virtual machine involves capturing and copying the entire state of the machine ata snapshot in time, including processor and memory state as well as all vit- tual hardware resources such as BIOS, devices or network MAC addresses: 9 principle, this also includes the entire disk space, including system and uset directories as well as swap space used for virtual memory operating syste" scheduling. Clearly, the complete state of a typical server is likely to be 4" large. In a closely networked multi-server environment, such as a cloud applications In enterprises 95 samen e may assume that some persistent storage can be easily accessed cent OP from different servers, such as through a storage area network metworked filesystems; thus a large part ofthe system disk, inelud- or sib ectries or software can easily be transferred to the new serve, ing this mechanism. Even so, the remaining state, which needs to include and memory apart from other hardware states, can still be gigabytes in igrating this efficiently still requires some careful design. fosseehow VMware's VMotion carries out in-flight migration ofa virtual pine between physical servers: VMotion waits until the virtual machine nd to be in a stable state, after which all changes to machine state start logged. VMotion then copies the contents of memory, as well as disk- ient data belonging to either the guest operating system or. applications, to the target server. This is the baseline copy; it is not the final copy because the virtual machine continues to run on the original server during this process. Next the yirtual machine is suspended and the last remaining changes in semoryandstatesince the baseline, which were being logged, are sent to the taget server, Where the final state is computed, following which the virtual machine is activated and resumes from its last state. jsfout §.2 VIRTUALIZATION APPLICATIONS IN ENTERPRISES Aniumber of enterprises are engaged in virtualization projects that aim to gadually relocate operating systems and applications running directly on physical machines to virtual machines. The motivation is to exploit the addi- tional VMM layer between hardware and systems software for introducing a number of new capabilities that can potentially ease the complexity and risk of managing large data centers. Here we outline some of the more compelling cases for using virtualization in large enterprises. 8.24 Security through virtualization Modern data centers are all necessarily connected to the world outside via the intemet and are thereby open to malicious attacks and intrusion. A number of techniques have been developed to secure these systems, such S'tewalls, proxy filters, tools for logging and monitoring system activity Intrusion detection systems. Each of these security solutions can be “S intly enhanced using virtualization, «ample, many intrusion detection systems (IDS) traditionally run on tkand operate by monitoring network traffic for suspicious behavior 38 VIRTUALIZATION TECHNO1 o, Gy by matching against a database of known attack patterns. Alternative], based systems run within each operating system instance where the bej.'°S" of each process is monitored to detect potentially suspicious activity sue Tepeated login attempts or accessing files that are normally not needeq ys ® Processes. Virtualization opens up the posstbility of building IDS capat* into the VMM itself, or atleast at the same layer, Le. above the networt > below the operating system. The Livewire and Terra research Projects a examples of such an approach [24, 25], which has the advantage of enayyo greater isolation of the IDS from the monitored hosts while retaining eg? Plete visibility into the host’ state. This approach also allows for comple mediation of interactions between the host software and the underlyi . i ing hard- ware, enabling a suspect VM to be easily isolated from the rest of the data center. Virtualization also provides the opportunity for more complete, user-group specific, low-level logging of system activities, which would be impossible op very difficult if many different user groups and applications were sharing the same operating system. This allows security incidents to be be more easily traced, and also better diagnosed by replaying the incident on a copy of the virtual machine. End-user system (desktop) virtualization is another application we cover below that also has an important security dimension. Using virtual machines on the desktop or mobile phones allows users to combine personal usage of these devices with more secure enterprise usage by isolating these two worlds; so a user logs into the appropriate virtual machine (personal or enter- prise), with both varieties possibly running simultaneously. Securing critical enterprise data, ensuring network isolation from intrusions and protection from viruses can be better ensured without compromising users’ activities in their personal pursuits using the same devices. In fact some organizations are contemplating not even considering laptops and mobile devices as cor- porate resources; instead users can be given the flexibility to buy whatever devices they wish and use client-side virtual machines to access enterprise applications and data. 8.2.2 Desktop virtualization and application streaming Large enterprises have tens ifnot hundreds of thousands of users, each having a desktop and/or one or more laptops and mobile phones that are used t aa nect to applications running in the enterprise's data center. Managing '¢8" tion applications In enterprises 97 ~ gp wetuallz such as for security patches or virus definitions is a major ean management task. Sophisticated tools, such as IBM's Tivoli are used to Tematethisprocessacrossaglbally distributed network ofusers. Managing application roll-outs across such am environment isa similarly complex task, especially in the case of fat-client applications such as most popular email clients and office productivity tools, as well some transaction processing or ness intelligence applications. Virtualization has been proposed as a possible means to improve the man- ageability of end-user devices in such large environments. Here there have been two different approaches. The first has been to deploy all end-client sys- temsas virtual machines on central data centers which are then accessed by ‘yemote desktop’ tools, such as Citrix Presentation Server, Windows Terminal Services (WTS), or VNC (Virtual Network Computer). At least theoreti- ally this is an interesting solution as it (a) eases management of updates by ‘centralizing’ all desktops (b) allows easier recovery from crashes by sim- ply. restarting a new VM (c) enables security checks and intrusion detection to be performed centrally and (d) with all user data being central, secures it as well as enables better data sharing and potential reduction of redundant storage use. However, this approach has never really become popular, pri- marily because of the need for continuous network connectivity, which in spite of the advances in corporate networks and public broadband penetra- tion, is still not ubiquitous and ‘always on.’ Additionally, this approach also ignores the significant computing power available on desktops, which when added up across an enterprise can be very costly to replicate in a central data center. “The second approach is called ‘application streaming.’ Instead of running applications on central virtual machines, application streaming envisages maintaining only virtual machine images centrally. An endpoint client, such as a desktop, runs a hypervisor that also downloads the virtual machine image from the server and launches it on the end point client. In this man- ner the processing power of the end point is fully exploited, a VM image can be cached for efficiency and only incrementally updated when needed, and finally user data, which can be large, need not be centrally maintained but mounted from the local disk as soon as the virtual machine boots. Such a solution is implemented, for example, in the XenApp product from Gitrix (incorporating technology from Appstream, which was acquired by Cittis). Application streaming additionally allows the isolation of personal and corporate spaces for security purposes as mentioned in the previous Section, aystem tes, a 98 VIRTUALIZATION TECHNOL 9, ey 8.2.3 Server consolidation The most common driver for virtualization in enterprise data centers h, to consolidate applications running on possibly tens of thousands of each significantly underutilized on the average, onto a smaller numb more efficiently used resources. The motivation is both efficiency as wey, reducing the complexity of managing the so-called ‘server sprawl.’ The abit; to run multiple virtual machines on the same physical resources is alsg 4. to achieving the high utilizations in cloud data centers. i Here we explore some implications and limits of consolidation through simplified model. Suppose we wish to consolidate applications running o° m physical servers of capacity c onto one physical server of capacity nc. We assume that virtual machines are either perfectly efficient, or any inefficien, has been built into the factor n. We focus on a few simple questions: (j) whether the single server should have n processors (or cores), or a clock speed n times that of each original server; (ii) how much smaller than m (the number of physical servers) can we make n while retaining acceptable performance; and finally (iii) what is the impact on power consumption and whether this changes the preferred strategy. Asimple model using basic queuing theory provides some insight: A server running at an efficiency of e can be thought of as a single server queuing system where, for whatever reason, either light load or inefficient software, the arrival rate of requests (instructions to be processed) is e times less than that which can be served by the server. In queuing theory terminology, ¢ = A/, where 2 is the arrival rate and ji the service rate. We define the average ‘normalized response time’ as the average time spentin the system T normalized by average time between requests, 1/2, asr = TA. (Note: response time is a good measure of performance for transactional workloads; however it may not be the right measure for batch processing.) Using standard queuing theory [7] we can compute ro, the normalized response time using m physical servers as aS been Serve (8.1) e for each of the original servers. Now consider consolidating these servers int one server with m processors, wherein the queue becomes one with m servers working at the same rate /4, servicing an arrival rate of mA. Queuing theory (8.2) is small for light loads.) If, on tis m times, faster, we once again Service rate my. Since e Temains in this case (r,) Temains the same a single server queue but with , the normalized response time i us sider the case where the single server onto which we consolidate is only n times faster than the original servers. In this case we (8.3) We can see that itis possible to use a server far less powerful than ite of the m original servers, as long as n/m remains Teasonably npared to ¢; and if indeed n >> me then the average normalized degrades only linearly by the factor of n/m. see that a simple queuing theory analysis yields some natural fet consolidation using virtualization. The theoretical maximum 1 tem s of a reduction in number of servers, is n/m = e, at which ystem becomes unresponsive, In practice it is Possible to get fairly se. ifn/m = e(1+<), then the average normalized response time In effect, whatever the initial inefficiency, one can decide on Average normalized response time and plan the consolidation 7 1us its to tive to bring into consideration another factor in this analysis, “Consumption, an issue which is becoming increasingly impor- et management. Power consumption of chips is related to the a chip operates, in particular power P grows as the square of ert puting Po can be found in (7). VIRTUALIZATION TECHNO) 0 v the voltage, i.e. P o V?. It is also a fact that higher clock Speeds requ; voltage, with almost a linear relationship between the two. Tht highe, that runs at a clock speed n times faster than a us, ‘base’ system, will cong. the power of the base system, whereas the n cot cn re system will consume” times the power, In fact this is one of the reasons for the shift 19 on "yn CPUs, with systems having four to eight cores per CPU being aa ne as of this writing, and CPUs with dozens of cores expected to be the n, the near future. Revisiting our queuing model, in the case of consolidation onto cessor/core server, instead of one that is n times fa average normalized response time, call it rp, as: OTe’ Place orm in ann pro. ster, we can compute the rp = me+ (84) Notice that the response time remains the same as Tp ie., when Pog is small. Thus the response time still de; independent of n, as compared to the faster clock sper in the case of heavy load, where the second term domi degradation in performance in the multi-processor ca to the m = n case, ie. (8.2). Thus there is a trade off, at least theoretically, between reducing power consumption by consolidating onto multi-processors or multi-core CPU sys- tems, versus improved performance on systems with faster clock speeds but at the cost of non-linear growth in power consumption per server. In practice this trade off is less significant since there are limits on how far clock speed can be increased, for both power as well as due to fundamental physical constraints. Lastly, apart from consolidation, it is important to note that indi- vidual applications implemented using multi-threaded application servers can also exploit multi-core architectures efficiently. Therefore, both enterprise as well as cloud data centers today rely almost exclusively on multi-core, multi-processor systems. in (8.2) for light loads, grades by a factor of m, ed case (8.1). However, nates, there is a marked se ifn < m, as compared 8.2.4 Automating Infrastructure management i en An important goal of enterprise virtualization projects is to reduce data ¢ is It n. ter management costs, especially people costs through greater aio be is important to recognize that while virtualization technology provide ee Z automate many activities, actually designing and putting into place 0h strategy is @ complex exercise that needs to be planned. Fur- rat Jevels ofautomation are possible, some easy to achieve through consolidation, while others are more complex, requiring more tools and technology as well as significant changes in operating even the organizational structure of the infrastructure wing of T. ; angisa possible roadmap for automation of infrastructure man- shincreasing sophistication in the use of virtualization technology wil 0- Virtual images: Packaging standard operating environments for a rent classes of application needs as virtual machines, thereby reduc- thestart-up time for development, testing and production deployment, “Be aking it easier to bring on board new projects and developers. This approach is not only easy to get started with, but offers significant reduc- jnfrastructure management costs and saves precious development time as well. Tovel 1 - Integrated provisioning: Integrated provisioning of new vir- servers along with provisioning their network and storage (SAN) “sesources, so that all these can be provisioned on a chosen physical server ‘by an administrator through a single interface. Tools are available that some of these capabilities (such as VMware's VirtualCenter inte- suite). In the majority of enterprises such tools are currently in process of being explored and prototyped; with only a few enterprises aving successfully deployed this level of automation on a large scale level — Elastic provisioning: Automatically deciding the physical server hich to provision a virtual machine given its resource requirements, ble capacity and projected demand; followed by bringing up the machine without any administrator intervention; rather users lication project managers) are able to provision virtual servers them- Thisis the automation level provided by Amazon EC2, for example. ofthis writing, and to our best knowledge, no large enterprise IT organi- tion has deployed this level of automation in their internal data center at egtee of scale, though many projects are under way, using commercial els or the open source Eucalyptus tool (see Chapter 17). 13 ~ Elastic operations: Automatically provisioning new virtual or migrating running virtual servers based on the need to do hich is established through automatic monitoring of the state of all Eats: 102 3 6Qy VIRTUALIZATION TECHNOLO, Y virtual physical resources, and which can arise for a number of x such as: 1. Load balancing, to improve response time of applications that explicitly request for, or appear to need more resources, and Hien. on their business criticality. Tding 2. Security, to quarantine a virtual machine that appears to have j, compromised or attacked. een 3. Collocation, to bring virtual machines that are communicatin each other physically closer together to improve performance, 4. Fault tolerance, to migrate applications from physical machines have indicated possible imminent failure or need for maintenance. 5. Fault recovery, to provision a new instance virtual machine and launch it with the required set of applications running in order to recover from the failure of the original instance, so as to restore the corresp business service as soon as possible. While tools such as VMotion provide the underlying capability to migrate virtual machines ‘in-flight,’ as we have described in the previous section, exploiting this capability to achieve this level of automation of opera. tions is really the holy grail for virtualization in enterprises, or even in infrastructure cloud platforms such as Amazon. €ason, 8 With that onding Virtualization projects in enterprises today are either at Level 0 or 1. Level 2 is available in Amazon EC2 in the cloud, whereas Level 3 automation has hardly ever been achieved in totality, at least with system virtual machines. EveninAmazonEC2, while monitoring andauto-scaling facilities are available, in-flight migration of virtual machinesis notavailable, atleastas of this writing. If, however, one considers process virtual machines, such as Google App Engine, or efficient software-as-a-service providers, one can argue that to a certain extent the appearance of Level 3 is provided, since an application deployed in sucha platform is essentially ‘always on,’ with the user not needing to be aware of any infrastructure management issues. Taking a process VM or even application virtualization (i.e. Dev 2.0) route may enable enterprises 0 provide pockets of services that can appear to achieve nearly Level 3 elastic automation, whereas achieving this degree of automation at a lower level of abstraction, such as system virtual machines is likely to be much harder t deploy at a large scale. Where to start? An enterprise virtualization strategy needs to systematically plan which classes of applications should be moved to a virtual environment as wellas whether and when the progression to increasing levels of automation should be attempted. Often the best place to start a virtualization exercise is EE ls —=—E—e 8.3 Pitfalls of virtualization 103 within the IT organization itself, with the ‘test and dev’ environments that are ‘used by developers in application development projects. Developers regularly require many of the capabilities enabled by virtualization, such as being able to manage project-specific sets of standard operating environments, re-create and re-start servers from a check pointed state during functional testing, or rovision servers of different capacities for performance testing. As an addi- tional benefit, having developers experience virtualization during application development also makes supporting applications in a virtualized production environment much easier. Finally, exactly the same argument holds for cloud computing as well; using a cloud data center for development is a useful first step before considering production applications in the cloud. §.3 PITFALLS OF VIRTUALIZATION As our discussion so far has revealed, virtualization is critical for cloud computing and also promises significant improvements within in-house data centers. At the same time it is important to be aware of some of the common pitfalls that come with virtualization: . Application deployments often replicate application server and database instances to ensure fault tolerance. Elastic provisioning results in two such replicas using virtual servers deployed on the same physical server. Thus if the physical server fails, both instances are lost, defeating the purpose of replication. We have mentioned that virtualization provides another layer at which intrusions can be detected and isolated, i.e., the VMM. Conversely how- ever, if the VMM itself is attacked, multiple virtual servers are affected. Thus some successful attacks can spread more rapidly in a virtualized environment than otherwise. Ifthe ‘server spraw!’ that motivated the building of a virtualized data center merely results in an equally complex ‘virtual machine sprawl the purpose has not been served, rather the situation may become even worse than ear- lier. The ease with which virtual servers and server images are provisioned and created can easily result in such situations if one is not careful. . Inprinciple a VMM can partition the CPU, memory and I/O bandwidth ofa physical server across virtual servers. However, it cannot ensure that these Tesourcesare made available to each virtual serverinasynchronized manner. Thus the fraction of hardware resources that a virtual server is actually able ~ toutilize may be less than what has been provisioned by the VMM. i » *

You might also like