LightBlog
Contact at mumbai.academics@gmail.com or 8097636691/9323040215
Responsive Ads Here

Thursday, 22 February 2018

Going Back and Forth: Efficient Multi Deployment and Multi Snap Shotting on Clouds


Going Back and Forth: Efficient Multi

 Deployment and Multi Snap 

Shotting on Clouds

SYNOPSIS
Infrastructure as a Service (IaaS) cloud computing has transform the way we think of acquiring resources by introducing a simple change: allowing users to lease computational resources from the cloud provider’s datacenter for a short time by deploying virtual machines (VMs) on these resources. This new model raises new challenges in the design and development of IaaS middleware. One of those challenges is the need to deploy a large number (hundreds or
even thousands) of VM instances simultaneously. Once the VM instances are deployed, another challenge is to simultaneously take a snapshot of many images and transfer them to persistent storage to support management tasks, such as suspend-resume and migration. With datacenters growing rapidly and configurations becoming heterogeneous, it is important to enable efficient concurrent deployment and snapshotting that are at the same time hypervisor independent and ensure a maximum compatibility with different configurations. This paper addresses these challenges by proposing a virtual file system specifically optimized for virtual machine image storage. It is based on a lazy transfer scheme coupled with object versioning that handles snapshotting transparently in a hypervisor-independent fashion, ensuring high portability for different configurations.
INTRODUCTION:
The Infrastructure as a Service cloud computing has emerged as a viable alternative to the acquisition and management of physical resources. With IaaS, users can lease storage and computation time from large datacenters. Leasing of computation time is accomplished by allowing users to deploy virtual machines (VMs) on the datacenter’s resources. Since the user has complete control over the configuration of the VMs using on-demand deployments, IaaS leasing is equivalent to purchasing dedicated hardware but without the long-term commitment and cost. The on-demand nature of IaaS is critical to making such leases attractive, since it enables users to expand or shrink their resources according to their computational needs, by using external resources to complement their local resource base.
This problem is particularly acute for VM images used in scientific computing where image sizes are large. A typical deployment consists of hundreds or even thousands of such images. Conventional deployment techniques broadcast the images to the nodes before starting the VM instances, a process that can take tens of minutes to hours, not counting the time to boot the operating system itself.
EXISTING SYSTEM
The huge computational potential offered by large distributed systems is hindered by poor data sharing scalability.
We addressed several major requirements related to these challenges. One such requirement is the need to efficiently cope with massive unstructured data (organized as huge sequences of bytes - BLOBs that can grow to TB) in very large-scale distributed systems while maintaining a very high data throughput for highly concurrent, fine-grain data accesses.
The role of virtualization in Clouds is also emphasized by identifying it as a key component. Moreover, Clouds have been defined just as virtualized hardware and software plus the previous monitoring and provisioning technologies.
Cloud Computing is a “buzz word” around a wide variety of aspects such as deployment, load balancing, provisioning, and data and processing outsourcing.
DISADVANTAGE
To give an less performance and storage space. Network traffic consumption also very high due to non concentrating on application status.
It is not possible to build a scalable, high-performance distributed data-storage service that facilitates data sharing at large scale.
PROPOSED SYSTEM
A distributed virtual file system specifically optimized for both the multi deployment and multi snapshotting patterns. Since the patterns are complementary, we investigate them in conjunction. Our proposal offers a good balance between performance, storage space, and network traffic consumption, while handling snapshotting transparently and exposing standalone, raw image files (understood by most hypervisors) to the outside.
We introduce a series of design principles that optimize multi deployment and multi snapshotting patterns and describe how our design can be integrated with IaaS infrastructures.
We show how to realize these design principles by building a virtual file system that leverages versioning-based distributed storage services. To illustrate this point, we describe an implementation on top of Blob Seer, a versioning storage service specifically designed for high throughput under concurrency.
ADVANTAGE
A good balance between performance, storage space, and network traffic consumption, while handling snapshotting transparently and exposing standalone, raw image files
MODULES
•         Cloud infrastructure
•         Application state maintenance
•         Application access pattern
•         Aggregate the storage
•         Image mirroring
•         Striping the image
•         Optimize multi snapshotting
•         Zoom on mirroring
MODULE DESCRIPTION
CLOUD INFRASTRUCTURE
IaaS platforms are typically built on top of clusters made out of loosely-coupled commodity hardware that minimizes per unit cost and favors low power over maximum speed. Disk storage (cheap hard-drives with capacities in the order of several hundred GB) is attached to each machine, while the machines are interconnected with standard Ethernet links. The machines are configured with proper virtualization technology, in terms of both hardware and software, such that they are able to host the VMs. In order to provide persistent storage, a dedicated repository is deployed either as centralized or as distributed storage service running on dedicated storage nodes.
APPLICATION STATE MAINTENANCE
The VM deployment is defined at each moment in time by two main components: the state of each of the VM instances and the state of the communication channels between them (opened sockets, in-transit network packets, virtual topology, etc.). To saving the application state implies saving both the state of all VM instances and the state of all active communication channels among them. While several methods have been established in the virtualization community to capture the state of a running VM (CPU registers, RAM, state of devices, etc.), the issue of capturing the global state of the communication channels is difficult and still an open problem.
APPLICATION ACCESS PATTERN
A VM typically does not access the whole initial image. For example, it may never access some applications and utilities that are installed by default with the operating system. In order to model this aspect, it is useful to analyze the life-cycle of a VM instance, it will based on
Three phases. They are boot, application and shutdown.
AGGREGATE THE STORAGE
In most cloud deployments, the disks locally attached to the compute nodes are not exploited to their full potential. Most of the time, such disks are used to hold local copies of the images corresponding to the running VMs, as well as to provide temporary storage for them during their execution, which utilizes only a small fraction of the total disk size.
IMAGE MIRRORING
A new VM needs to be instantiated; the underlying VM image is presented to the hypervisor as a regular file accessible from the local disk. Read and write accesses to the file, however, are trapped and treated in a special fashion. A read that is issued on a fully or partially empty region in the file that has not been accessed before (by either a previous read or write) results in fetching the missing content remotely from the VM repository, mirroring it on the local disk and redirecting the read to the local copy. If the whole region is available locally, no remote read is performed. Writes, on the other hand, are always performed locally.
STRIPING THE IMAGE
Each VM image is split into small, equal-sized chunks that are evenly distributed among the local disks participating in the shared pool. When a read accesses a region of the image that is not available locally, the chunks that hold this region are determined and transferred in parallel from the remote disks that are responsible for storing them. Under concurrency, this scheme effectively enables the distribution of the I/O workload, because accesses to different parts of the image are served by different disks.
OPTIMIZE MULTISNAPSHOTTING
Saving a full VM image for each VM is not feasible in the context of multi snapshotting. Since only small parts of the VMs are modified, this would mean massive unnecessary duplication of data, leading not only to an explosion of utilized storage space but also to unacceptably high snapshotting time and network bandwidth utilization.
ZOOM ON MIRRORING
One important aspect of on-demand mirroring is the decision of how much to read from the repository when data is unavailable locally, in such way as to obtain a good access performance. A straightforward approach is to translate every read issued by the hypervisor in either a local or remote read, depending on whether the requested content is locally available. While this approach works, its performance is questionable. More specifically, many small remote read requests to the same chunk generate significant network traffic overhead (because of the extra networking information encapsulated with each request), as well as low throughput (because of the latencies of the requests that add up).
SOFTWARE HARDWARE REQUIREMENTS
HARDWARE REQUIREMENT
CPU type                      :    Intel Pentium 4
Clock speed                   :    3.0 GHz
Ram size                       :    512 MB
Hard disk capacity         :    40 GB
Monitor type                 :    15 Inch color monitor
Keyboard type               :     internet keyboard
SOFTWARE REQUIREMENT
Operating System:  Windows XP
Front End           :  JAVA
Back End                    :    SQL SERVER
Documentation    :    Ms-Office

No comments:

Post a Comment