`
`2013 IEEE 33rd International Conference on Distributed Computing Systems2013 IEEE 33rd International Conference on Distributed Computing Systems2013 IEEE 33rd International Conference on Distributed Computing Systems
`2013 IEEE 33rd International Conference on Distributed Computing Systems
`
`ImageElves: Rapid and Reliable System Updates in
`ImageElves: Rapid and Reliable System Updates in
`the Cloud
`the Cloud
`
`Deepak Jeswani, Akshat Verma, Praveen Jayachandran, Kamal Bhattacharya
`Deepak Jeswani, Akshat Verma, Praveen Jayachandran, Kamal Bhattacharya
`IBM Research - India.
`IBM Research - India.
`
`Abstract—Virtualization has significantly reduced the cost of
`Abstract—Virtualization has significantly reduced the cost of
`creating a new virtual machine and cheap storage allows VMs
`creating a new virtual machine and cheap storage allows VMs
`to be turned down when unused. This has led to a rapid
`to be turned down when unused. This has led to a rapid
`proliferation of virtual machine images, both active and dormant,
`proliferation of virtual machine images, both active and dormant,
`in the data center. System management technologies have not
`in the data center. System management technologies have not
`been able to keep pace with this growth and the management cost
`been able to keep pace with this growth and the management cost
`of keeping all virtual machines images, active as well as dormant,
`of keeping all virtual machines images, active as well as dormant,
`updated is significant. In this work, we present ImageElves, a
`updated is significant. In this work, we present ImageElves, a
`system to rapidly, reliably and automatically propagate updates
`system to rapidly, reliably and automatically propagate updates
`(e.g., patches, software installs, compliance checks) in a data
`(e.g., patches, software installs, compliance checks) in a data
`center. ImageElves analyses all target images and creates reliable
`center. ImageElves analyses all target images and creates reliable
`image patches using a very small number of online updates.
`image patches using a very small number of online updates.
`Traditionally, updates are applied by taking the application
`Traditionally, updates are applied by taking the application
`offline, applying updates, and then restoring the application, a
`offline, applying updates, and then restoring the application, a
`process that is unreliable and has an unpredictable downtime.
`process that is unreliable and has an unpredictable downtime.
`With ImageElves, we propose a two phase process. In the first
`With ImageElves, we propose a two phase process. In the first
`phase, images are analyzed to create an update signature and
`phase, images are analyzed to create an update signature and
`update manifest. In the second phase, downtime is taken and
`update manifest. In the second phase, downtime is taken and
`the manifest is applied offline on virtual images in a parallel,
`the manifest is applied offline on virtual images in a parallel,
`reliable and automated manner. This has two main advantages,
`reliable and automated manner. This has two main advantages,
`(i) spontaneously apply updates to already dormant VMs, and (ii)
`(i) spontaneously apply updates to already dormant VMs, and (ii)
`all updates following this process are guaranteed to work reliably
`all updates following this process are guaranteed to work reliably
`leading to reduced and predictable downtimes. ImageElves uses
`leading to reduced and predictable downtimes. ImageElves uses
`three key ideas: (i) a novel per-update profiling mechanism to
`three key ideas: (i) a novel per-update profiling mechanism to
`divide VMs into equivalence classes, (ii) a background logging
`divide VMs into equivalence classes, (ii) a background logging
`mechanism to convert updates on live instances into patches
`mechanism to convert updates on live instances into patches
`for dormant images, and (iii) a cross-difference mechanism to
`for dormant images, and (iii) a cross-difference mechanism to
`filter system-specific or random information (e.g., host name,
`filter system-specific or random information (e.g., host name,
`IP address), while creating equivalence classes. We evaluated
`IP address), while creating equivalence classes. We evaluated
`the ability of ImageElves to speed up mix of popular system
`the ability of ImageElves to speed up mix of popular system
`management activities and observed upto 80% smaller update
`management activities and observed upto 80% smaller update
`times for active instances and upto 90% reduction in update
`times for active instances and upto 90% reduction in update
`times for dormant instances.
`times for dormant instances.
`
`I. INTRODUCTION
`I. INTRODUCTION
`Virtualization has made it increasingly easy and less expen-
`Virtualization has made it increasingly easy and less expen-
`sive to create new virtual machine instances. There is evidence
`sive to create new virtual machine instances. There is evidence
`that instead of simply consolidating existing workloads into
`that instead of simply consolidating existing workloads into
`fewer servers, virtualization has led to an increase in the
`fewer servers, virtualization has led to an increase in the
`number of systems, now running as VMs [10]. There is
`number of systems, now running as VMs [10]. There is
`a proliferation of barely used VMs, as developers forget
`a proliferation of barely used VMs, as developers forget
`to return (or intentionally postpone, anticipating reuse) the
`to return (or intentionally postpone, anticipating reuse) the
`VMs they do not use to the resource pool at the end of a
`VMs they do not use to the resource pool at the end of a
`project. Unfortunately, system management technologies have
`project. Unfortunately, system management technologies have
`been unable to keep pace with this rapid proliferation, and
`been unable to keep pace with this rapid proliferation, and
`the management cost of keeping all virtual machine images
`the management cost of keeping all virtual machine images
`updated, both dormant and active, is significant. In a recent
`updated, both dormant and active, is significant. In a recent
`study, it was noted that more than 58% of virtual machine
`study, it was noted that more than 58% of virtual machine
`images in a university data center had not been used for over
`images in a university data center had not been used for over
`1.5 months. Nearly a quarter of the images in the university’s
`1.5 months. Nearly a quarter of the images in the university's
`data center as well as in EC2 were not updated for 2-3
`data center as well as in EC2 were not updated for 2-3
`months [21]. This can pose a significant security threat to
`months [21]. This can pose a significant security threat to
`the data center, as well as increasing the time for updating
`the data center, as well as increasing the time for updating
`
`these dormant images and getting them ‘ready’ when they are
`these dormant images and getting them `ready' when they are
`needed again.
`needed again.
`Due to resource sharing and I/O indirection, virtualization
`Due to resource sharing and I/O indirection, virtualization
`has also exacerbated the problem of system management,
`has also exacerbated the problem of system management,
`making it more expensive and time consuming to update
`making it more expensive and time consuming to update
`systems reliably. Anti-virus updates and operating system
`systems reliably. Anti-virus updates and operating system
`patches can result in increases in CPU utilization of the order
`patches can result in increases in CPU utilization of the order
`of 40% on a virtual machine – changes that would have a
`of 40% on a virtual machine — changes that would have a
`negligible impact on a physical system [10]. As any system
`negligible impact on a physical system [10]. As any system
`update is deemed unreliable, in order to deal with unforeseen
`update is deemed unreliable, in order to deal with unforeseen
`problems, traditionally, any changes or updates to a running
`problems, traditionally, any changes or updates to a running
`system are applied by taking the application offline for a
`system are applied by taking the application offline for a
`large enough change window, applying the updates while
`large enough change window, applying the updates while
`system administrators are on stand-by, and then restoring the
`system administrators are on stand-by, and then restoring the
`application. Often, the actual change window is significantly
`application. Often, the actual change window is significantly
`larger than the time required for the update [16]. In this work,
`larger than the time required for the update [16]. In this work,
`we propose ImageElves to rapidly, reliably, and automatically
`we propose ImageElves to rapidly, reliably, and automatically
`propagate system updates (e.g., patches, software installs,
`propagate system updates (e.g., patches, software installs,
`compliance checks) to dormant as well as live virtual machine
`compliance checks) to dormant as well as live virtual machine
`images in a data center.
`images in a data center.
`There are several tools available today that automate ap-
`There are several tools available today that automate ap-
`plication of patches and compliance checks for online virtual
`plication of patches and compliance checks for online virtual
`machines [6], [15], [8], [7], [16]. While these tools address
`machines [6], [15], [8], [7], [16]. While these tools address
`the scalability challenge, the patches themselves remain unre-
`the scalability challenge, the patches themselves remain unre-
`liable, and administrators need to fix any failed updates manu-
`liable, and administrators need to fix any failed updates manu-
`ally. Once a failed update is fixed manually, the administrator
`ally. Once a failed update is fixed manually, the administrator
`has to then ensure that the patch itself is fixed or create yet
`has to then ensure that the patch itself is fixed or create yet
`another patch that can then be fed to the tools for automatic
`another patch that can then be fed to the tools for automatic
`application on the VMs. Hence, these tools do not help reduce
`application on the VMs. Hence, these tools do not help reduce
`the total application downtime by much, as a large chunk
`the total application downtime by much, as a large chunk
`of the downtime is needed to manually fix any unforeseen
`of the downtime is needed to manually fix any unforeseen
`problems during the update process. Furthermore, these tools
`problems during the update process. Furthermore, these tools
`do not patch dormant VM images. Recently, a novel tool
`do not patch dormant VM images. Recently, a novel tool
`called N¨uwa was presented in [21] to patch dormant VMs.
`called Niiwa was presented in [21] to patch dormant VMs.
`The tool automatically rewrites a patch that is intended to be
`The tool automatically rewrites a patch that is intended to be
`applied on online VMs, to exclude or replace statements that
`applied on online VMs, to exclude or replace statements that
`require a running VM. This modified patch is then applied on
`require a running VM. This modified patch is then applied on
`the dormant VMs. Apart from being unable to handle online
`the dormant VMs. Apart from being unable to handle online
`VMs and the additional cost of rewriting patches, this tool
`VMs and the additional cost of rewriting patches, this tool
`has additional limitations in that the rewritten patches are not
`has additional limitations in that the rewritten patches are not
`guaranteed to succeed.
`guaranteed to succeed.
`Contribution: In this paper, we design a system called
`Contribution: In this paper, we design a system called
`ImageElves that can work for (i) both active and dormant
`ImageElves that can work for (i) both active and dormant
`instances, (ii) guarantees the reliability and time taken for
`instances, (ii) guarantees the reliability and time taken for
`an update, (iii) can handle all kinds of updates (without
`an update, (iii) can handle all kinds of updates (without
`source code), and (iv) scales with new types of updates.
`source code), and (iv) scales with new types of updates.
`ImageElves works by first identifying equivalent images and
`ImageElves works by first identifying equivalent images and
`then applying offline update manifests on equivalent images in
`then applying offline update manifests on equivalent images in
`
`
`
`1063-6927/13 $26.00 © 2013 IEEE1063-6927/13 $26.00 © 2013 IEEE1063-6927/13 $26.00 © 2013 IEEE
`1063-6927/13 $26.00 © 2013 IEEE
`
`
`DOI 10.1109/ICDCS.2013.33DOI 10.1109/ICDCS.2013.33DOI 10.1109/ICDCS.2013.33
`DOI 10.1109/ICDCS.2013.33
`
`
`
`269390390
`390
`
`IEEE
`®computer
`soaety
`WIZ, Inc. EXHIBIT - 1067
`WIZ, Inc. v. Orca Security LTD.
`
`WIZ, Inc. EXHIBIT - 1067
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`a reliable fashion. ImageElves uses three key ideas: (i) a novel
`a reliable fashion. ImageElves uses three key ideas: (i) a novel
`per-update profiling mechanism that partitions the VMs into
`per-update profiling mechanism that partitions the VMs into
`equivalence classes, (ii) a background light-weight logging
`equivalence classes, (ii) a background light-weight logging
`mechanism to convert updates on live instances into update
`mechanism to convert updates on live instances into update
`manifests for dormant instances, and (iii) a cross-difference
`manifests for dormant instances, and (iii) a cross-difference
`mechanism to identify random or system-specific information
`mechanism to identify random or system-specific information
`across VMs (such as hostname or IP address) while creat-
`across VMs (such as hostname or IP address) while creat-
`ing equivalence classes. Instances that belong to a common
`ing equivalence classes. Instances that belong to a common
`equivalence class are guaranteed to perform identically for the
`equivalence class are guaranteed to perform identically for the
`specified update. This reliability allows us to perform updates
`specified update. This reliability allows us to perform updates
`fully automatically and in parallel on all equivalent instances,
`fully automatically and in parallel on all equivalent instances,
`leading to significant reduction in update time and labor cost.
`leading to significant reduction in update time and labor cost.
`Further, it avoids expensive operating system and application
`Further, it avoids expensive operating system and application
`testing after update application,
`leading to shorter change
`testing after update application, leading to shorter change
`windows. We implemented ImageElves on a target system
`windows. We implemented ImageElves on a target system
`with 37 virtual machines and observed upto 80% reduction
`with 37 virtual machines and observed upto 80% reduction
`in update times for active instances and upto 90% reduction
`in update times for active instances and upto 90% reduction
`in update times for dormant instances.
`in update times for dormant instances.
`
`II. BACKGROUND AND MOTIVATION
`II. BACKGROUND AND MOTIVATION
`We first present a background on how servers are updated
`We first present a background on how servers are updated
`in production data centers.
`in production data centers.
`
`START
`
`.)
`
`I CHANGE WINDOW REQUEST
`9
`
`I SHUTDOWN APPLICATION I
`
`I
`
`I
`
`I APPLY UPDATE
`I OS HEALTHCHECK I
`I APPLICATION HEALTHCHECK I
`4
`I CLOSE CHANGE WINDOW
`
`I
`
`C
`
`STOP
`
`Fig. 1. Update Flow in Production Data Centers
`Fig. I. Update Flow in Production Data Centers
`
`A. Update Process on Production Servers
`A. Update Process on Production Servers
`Any update in a production environment is a change with the
`Any update in a production environment is a change with the
`potential to break the application in the environment. Hence,
`potential to break the application in the environment. Hence,
`updates are dealt with very carefully, using a change manage-
`updates are dealt with very carefully, using a change manage-
`ment process. Huang et al. present the change management
`ment process. Huang et al. present the change management
`process for patching in [6]. Even though the exact change
`process for patching in [6]. Even though the exact change
`management process differs across data centers as well as with
`management process differs across data centers as well as with
`the nature of updates, the essential steps remain the same.
`the nature of updates, the essential steps remain the same.
`We abstract a generic change management process for
`We abstract a generic change management process for
`various kinds of updates in Fig. 1. One may note the structural
`various kinds of updates in Fig. 1. One may note the structural
`similarity of this process with various documented change
`similarity of this process with various documented change
`management processes (e.g., [6]). The process starts with a
`management processes (e.g., [6]). The process starts with a
`request for a change window to perform the change. Once
`request for a change window to perform the change. Once
`the change window is granted, the application is shutdown at
`the change window is granted, the application is shutdown at
`the start of the window. The update is then applied on the
`the start of the window. The update is then applied on the
`target server. Once the update completes, testing is performed
`target server. Once the update completes, testing is performed
`to ensure that the update did not break the application. Testing
`to ensure that the update did not break the application. Testing
`consists of operating system health checks followed by health
`consists of operating system health checks followed by health
`checks for the application. If testing succeeds, the change
`checks for the application. If testing succeeds, the change
`window is closed. Otherwise, manual remediation is performed
`window is closed. Otherwise, manual remediation is performed
`followed by re-testing.
`followed by re-testing.
`
`270391391
`391
`
`APP
`CHANGE
`APPRDVED DOWN
`
`V
`
`„ fr
`
`
`
` DOWNTIME
`
`
`
`CHANGE
`REQUEST
`
`APP
`SHUTDOWN
`REUEST APPLY
`UPDATE
`Q
`
`UPDATE
`TIME
`
`TEST
`OS
`
`TEST
`APP
`
`CLOSE
`CHANGE
`
`Fig. 2. Timeline of an update
`Fig. 2. Timeline of an update
`
`We capture the steps on a timeline in Fig. 2. The most
`We capture the steps on a timeline in Fig. 2. The most
`important thing to observe here is that, even if the actual time
`important thing to observe here is that, even if the actual time
`taken for the update to be applied is small, the overall time
`taken for the update to be applied is small, the overall time
`taken from the request for a change window to a change close
`taken from the request for a change window to a change close
`is fairly large. Approval for a change window is manual and
`is fairly large. Approval for a change window is manual and
`takes time. More importantly, the actual change window is
`takes time. More importantly, the actual change window is
`often orders of magnitude larger than the update time [16].
`often orders of magnitude larger than the update time [16].
`This is because of the inherent unreliability of this change
`This is because of the inherent unreliability of this change
`process requiring expensive operating system and application
`process requiring expensive operating system and application
`tests. Coupled with a buffer time kept for manual remediation,
`tests. Coupled with a buffer time kept for manual remediation,
`the actual planned downtime is typically a few hours, even
`the actual planned downtime is typically a few hours, even
`if the actual update may take less than 10 mins. Further,
`if the actual update may take less than 10 mins. Further,
`every update has huge associated labour cost due to the testing
`every update has huge associated labour cost due to the testing
`performed after the update is completed.
`performed after the update is completed.
`The above process captures how an update is applied on
`The above process captures how an update is applied on
`one system. Frequently, updates need to be applied on almost
`one system. Frequently, updates need to be applied on almost
`all instances in a data center (e.g., an OS security patch)
`all instances in a data center (e.g., an OS security patch)
`or on very large number of instances (e.g., database or web
`or on very large number of instances (e.g., database or web
`server updates). Due to inherent risk in the update process,
`server updates). Due to inherent risk in the update process,
`administrators typically update only a few systems to start
`administrators typically update only a few systems to start
`with. Once the first few updates succeed, they try to update
`with. Once the first few updates succeed, they try to update
`more systems. Updating all relevant systems in the data center
`more systems. Updating all relevant systems in the data center
`often happen months after the update was available [4].
`often happen months after the update was available [4].
`In this work, we focus on system updates, which are
`In this work, we focus on system updates, which are
`common across a data center. Examples of such updates are
`common across a data center. Examples of such updates are
`security patches, compliance updates, installation and configu-
`security patches, compliance updates, installation and configu-
`ration of system management software, upgrades of operating
`ration of system management software, upgrades of operating
`systems and common middleware. The common denominator
`systems and common middleware. The common denominator
`for all these updates are that they are applied on a large
`for all these updates are that they are applied on a large
`number of systems. The core idea behind our work is to profile
`number of systems. The core idea behind our work is to profile
`these updates on very few instances and use that information
`these updates on very few instances and use that information
`to update majority of the instances in a reliable and low-
`to update majority of the instances in a reliable and low-
`cost manner. Application-specific updates like code upgrades,
`cost manner. Application-specific updates like code upgrades,
`which touch few instances only, are outside the scope of this
`which touch few instances only, are outside the scope of this
`work and should be handled using their regular update process.
`work and should be handled using their regular update process.
`B. VM Sprawl
`B. VM Sprawl
`Server virtualization leads to a reduction in the hardware
`Server virtualization leads to a reduction in the hardware
`footprint of the data center by consolidating multiple work-
`footprint of the data center by consolidating multiple work-
`loads as virtual machines on a shared physical server. This
`loads as virtual machines on a shared physical server. This
`leads to a reduction in data center infrastructure cost. However,
`leads to a reduction in data center infrastructure cost. However,
`system administration cost
`is proportional
`to the number
`system administration cost is proportional to the number
`of distinct managed servers (physical or virtual) in a data
`of distinct managed servers (physical or virtual) in a data
`center. Every virtual server runs an operating system and an
`center. Every virtual server runs an operating system and an
`application stack, which need to be administered. In fact, it
`application stack, which need to be administered. In fact, it
`has been observed that virtualization leads to an increase in
`has been observed that virtualization leads to an increase in
`the number of running systems in a data center [10].
`the number of running systems in a data center [10].
`An increase in the number of managed VMs in a virtualized
`An increase in the number of managed VMs in a virtualized
`data center is fairly easy to explain. Virtualization allows
`data center is fairly easy to explain. Virtualization allows
`virtual machines to be provisioned automatically in the order
`virtual machines to be provisioned automatically in the order
`
`

`

`of a few minutes. In comparison, provisioning a physical
`of a few minutes. In comparison, provisioning a physical
`server was a time-consuming activity, requiring multiple levels
`server was a time-consuming activity, requiring multiple levels
`of approval in a traditional data center. Further, since vir-
`of approval in a traditional data center. Further, since vir-
`tual machines can be created with fairly small sizes, users
`tual machines can be created with fairly small sizes, users
`request virtual machines indiscriminately. Finally, one can
`request virtual machines indiscriminately. Finally, one can
`shutdown virtual machines and free up any CPU or memory
`shutdown virtual machines and free up any CPU or memory
`resources used by the virtual machine. Since storage is fairly
`resources used by the virtual machine. Since storage is fairly
`inexpensive, this has led to users creating virtual machines
`inexpensive, this has led to users creating virtual machines
`indiscriminately and shutting them down, when not required.
`indiscriminately and shutting them down, when not required.
`In a recent survey, it was observed that more than 58% of the
`In a recent survey, it was observed that more than 58% of the
`VMs in a cloud were not used for the last 1.5 months [21].
`VMs in a cloud were not used for the last 1.5 months [21].
`The explosion of virtual machines (both active and dormant)
`The explosion of virtual machines (both active and dormant)
`in a virtualized data center has led to the problem of VM
`in a virtualized data center has led to the problem of VM
`Sprawl. VM sprawl poses significant challenge for system
`Sprawl. VM sprawl poses significant challenge for system
`administrators in a data center. Firstly, it increases the labour
`administrators in a data center. Firstly, it increases the labour
`cost of managing and updating the software components due
`cost of managing and updating the software components due
`to an increase in the number of managed instances. Secondly,
`to an increase in the number of managed instances. Secondly,
`since a large number of instances are dormant at a given point
`since a large number of instances are dormant at a given point
`in time, scheduled updates miss the dormant instances. Since
`in time, scheduled updates miss the dormant instances. Since
`the resources consumed by dormant instances are released
`the resources consumed by dormant instances are released
`to other active instances,
`it
`is not even possible to bring
`to other active instances, it is not even possible to bring
`up all dormant instances and update them periodically. This
`up all dormant instances and update them periodically. This
`combined with the inherent unreliability of system updates
`combined with the inherent unreliability of system updates
`exacerbates the situation for system administrators.
`exacerbates the situation for system administrators.
`In this work, we pursue the idea that VM sprawl can also be
`In this work, we pursue the idea that VM sprawl can also be
`leveraged to increase the inherent reliability of system updates.
`leveraged to increase the inherent reliability of system updates.
`The ease of cloning instances and the use of golden masters to
`The ease of cloning instances and the use of golden masters to
`provision instances in a virtualized data center often leads to
`provision instances in a virtualized data center often leads to
`a large number of virtual machines with the same system and
`a large number of virtual machines with the same system and
`middleware footprint (with possibly different applications and
`middleware footprint (with possibly different applications and
`data). Given an update, our key idea is to automatically profile
`data). Given an update, our key idea is to automatically profile
`the update and identify all instances that are semantically
`the update and identify all instances that are semantically
`equivalent for the update. Equivalent instances are guaranteed
`equivalent for the update. Equivalent instances are guaranteed
`to respond identically to an update, allowing updates to be
`to respond identically to an update, allowing updates to be
`applied reliably, automatically, and rapidly.
`applied reliably, automatically, and rapidly.
`
`III. ImageElves DESIGN
`III. ImageElves DESIGN
`
`We first present the goals of ImageElves and then describe
`We first present the goals of ImageElves and then describe
`the techniques that help us achieve these goals.
`the techniques that help us achieve these goals.
`
`A. Design Goals
`A. Design Goals
`∙ Reliable Update Process: One of the primary issues in
`Reliable Update Process: One of the primary issues in
`the current system update process is the lack of reliability.
`the current system update process is the lack of reliability.
`Since it is not clear if an update will succeed, many
`Since it is not clear if an update will succeed, many
`system management activities are still performed under
`system management activities are still performed under
`manual supervision. In case an update fails, the system
`manual supervision. In case an update fails, the system
`administrator decides to roll back the update cleanly
`administrator decides to roll back the update cleanly
`or perform remediation actions and retry the update. A
`or perform remediation actions and retry the update. A
`reliable update process is a pre-requisite for automation.
`reliable update process is a pre-requisite for automation.
`∙ Deterministic Update Duration: The lack of reliability
`Deterministic Update Duration: The lack of reliability
`of the system update process also reflects in long change
`of the system update process also reflects in long change
`windows. Even if an update completes in 5 mins in most
`windows. Even if an update completes in 5 mins in most
`cases, the change window requested by a system admin-
`cases, the change window requested by a system admin-
`istrator is proportional to the worst case update duration.
`istrator is proportional to the worst case update duration.
`Change windows in production systems often involve
`Change windows in production systems often involve
`application downtime or reduced application availability
`application downtime or reduced application availability
`(e.g., reduced cluster size). Hence, an important goal
`(e.g., reduced cluster size). Hence, an important goal
`
`for ImageElves is to ensure deterministic update times,
`for ImageElves is to ensure deterministic update times,
`leading to short change windows.
`leading to short change windows.
`∙ Reduced Update Duration: ImageElves also attempts to
`• Reduced Update Duration: ImageElves also attempts to
`reduce the update duration, leading to even shorter change
`reduce the update duration, leading to even shorter change
`windows.
`windows.
`∙ Update both Dormant and Active Instances: Virtual-
`• Update both Dormant and Active Instances: Virtual-
`ized data centers have a large number of dormant VMs
`ized data centers have a large number of dormant VMs
`along with the active instances. ImageElves attempts to
`along with the active instances. ImageElves attempts to
`ensure that both active and dormant instances are updated.
`ensure that both active and dormant instances are updated.
`∙ Reduced Labour Cost: One of the most
`important
`• Reduced Labour Cost: One of the most important
`business goals of ImageElves is to reduce the overall
`business goals of ImageElves is to reduce the overall
`labour cost for managing systems in large data centers.
`labour cost for managing systems in large data centers.
`∙ Content-Oblivious Updates: Automation of the update
`Content-Oblivious Updates: Automation of the update
`process should be oblivious to the specific commands
`process should be oblivious to the specific commands
`executed by the updates so as to be generic and applicable
`executed by the updates so as to be generic and applicable
`to all updates.
`to all updates.
`
`B. Design Overview
`B. Design Overview
`ImageElves introduces the following novel ideas to ensure
`ImageElves introduces the following novel ideas to ensure
`a reliable, automated and low cost system update process in
`a reliable, automated and low cost system update process in
`data centers.
`data centers.
`∙ Per-Update Equivalence Class Identification: ImageElves
`Per-Update Equivalence Class Identification: ImageElves
`creates a signature for each update and partitions all
`creates a signature for each update and partitions all
`relevant instances (online and offline) in a data center
`relevant instances (online and offline) in a data center
`into equivalence classes based on the signature. Signature
`into equivalence classes based on the signature. Signature
`consists of all files which may have a dependency on
`consists of all files which may have a depend