What makes CloudVolumes so unique?
CloudVolumes is shifting the paradigm of how virtual machines are managed and updated. With the click of a button, you can deliver any number of applications and any amount of data to any number of virtual machines within milliseconds or seconds. Updating applications and virtual machines is likewise just as simple. This is true even for large, multi-tier applications that are several gigabytes in size. Moreover, CloudVolumes will seamlessly integrate into your existing virtual infrastructure—there is no need to replace your storage, hypervisor, network, or virtual machines.
How is this achieved?
- Direct integration with virtual infrastructure and storage
- Shared volumes: Install once, use anywhere
- Applications delivered via CloudVolumes are indistinguishable from native applications
- Highly scalable architecture
With traditional management and deployment solutions, if an application is needed in ten different virtual machines, then it must be installed ten times. If an application needs to be updated, it is separately updated in each virtual machine. In essence, traditional solutions are failing to leverage the full potential of virtualization by doing the same task n times for n virtual machines.
With CloudVolumes, this is no longer necessary. We change this by turning an otherwise monolithic virtual machine where everything is tightly locked together into modular virtual machine where those components that can be shared or swapped in and out.
For sharable components, such as application binaries and read-only data, there is only one copy that all virtual machines can simultaneously share. This is achieved by leveraging a read-only volume that is concurrently attached to each virtual machine.
Parts of the virtual machine which are specific to that workload or user—per-VM configuration, customization, license keys, log files, and data—can remain within the virtual machine or be placed into a separate writable volume. A writable volume is optional, but there are several benefits to using a separate writable volume:
- All changes to the system covered by the writable volume’s policy are put onto the writable volume rather than the virtual machine’s base disk.
- For virtual desktops, having a user writable volume means the user isn’t tethered to a specific virtual machine—the user can log into any virtual machine and see all his/her applications and data. Essentially, this gives the ease of management and cost savings of non-persistent virtual machine but with the look-and-feel of a persistent virtual machine.
- For servers, having a server writable volume means that the specific virtual machine a workload is running in doesn’t matter. If the virtual machine crashes, the workload can quickly detached from the failed virtual machine and attached to another virtual machine. The second benefit is migration. A workload can be relocated to another cloud or datacenter without moving the entire virtual machine.
Direct integration with virtual infrastructure and storage
CloudVolumes enables all files, data, and applications used by more than one virtual machine to be placed into shared virtual volumes (i.e., VMDK files in the case of VMware) and CloudVolumes does the magic to make this shared data accessible to all virtual machines that need it in a way that is transparent to the virtual machine.
These volumes can be placed on any type of storage that the hypervisor supports (i.e., SAN accessed via Fibre Channel or iSCSI, NFS, locally attached storage, etc.). CloudVolumes Manager will place the shared volumes or writable volumes on any datastore of your choosing. CloudVolumes is not inline in the storage path, it operates as more of a broker—we attach or detach volumes from virtual machines in response to certain events that will be discussed in more detail later. Reads and writes are sent directly from the virtual machine (where the volumes appear as local disks) to the datastore’s underlying storage through the hypervisor.
This approach enables storage tiering. Shared volumes (which receive only read requests) can be placed on a datastore optimized for read operations. As an example, it would not be cost effective to put entire virtual machines on an SSD datastore because of the cost of SSD. However, because CloudVolumes requires only a single copy of applications and shared data, those shared volumes can be placed on an SSD datastore and provide better application performance with only a marginal increase in storage cost.
Shared volumes: Install once, use anywhere
CloudVolumes Manager is configured to work with an Active Directory domain (or any other LDAP-based directory service) and a VMware vCenter. Shared volumes are then assigned to a user, computer, or group.
A volume assigned to a computer will be attached when the computer turns on. As an example, SQL Server 2012 could be provisioned into a shared volume and assigned to an Active Directory group called “SQL Servers.” Whenever a new virtual machine is created or powered on that is a member of the SQL Servers group, CloudVolumes Manager will attach the shared SQL Server 2012 VMDK into that virtual machine.
A volume assigned to a user will be attached into the virtual machine the moment the user logs into the virtual machine, and detached the moment the user logs out of the virtual machine. As an example, Visual Studio 2012 could be assigned to the Developers group, and whenever a developer logs into a virtual desktop, the Visual Studio will be instantly attached to the virtual machine before the login has even completed. Users are unaware that the applications are being instantly delivered the moment they logged in, because it happens so quickly that it is attached prior to users seeing their desktop or start menu.
Applications delivered via CloudVolumes are indistinguishable from native applications
Through the magic of CloudVolumes, an application is installed or updated only and then shared across all virtual machines. Applications contained in shared volumes will behave the same as locally installed applications. The application and OS are both unaware that the application is shared virtual machines.
The files, data, registry settings, etc. are located the same place they would normally be. This is because, at the time the application was provisioned, it was provisioned in the same way an application is normally installed natively. CloudVolumes transparently put the application (and its dependencies if any were installed) into the sharable volume while it was in provisioning mode.
For example, as soon as a shared volume containing a default installation of SQL Server 2012 is attached to a virtual machine, it is automatically started and you can immediately start interacting with it. The files are located where they normally are: C:\Program Files\Microsoft SQL Server. Similarly, its registry keys are in the regular location (HKLM\SOFTWARE\Microsoft\Microsoft SQL Server), its Windows services are visible in the Services management console, etc.
One CloudVolumes Manager can easily serve 10,000 virtual machines which is as many virtual machines as one VMware vCenter support. The CloudVolumes Manager is a stateless web server that stores all of its session state and information into a shared database. So you can operate as many CloudVolumes Managers as you’d like for load balancing or high availability. If the database shared by all of the CloudVolumes Managers is put onto a SQL Server cluster, then there is no single point of failure.
The CloudVolumes Manager sits idle until either the IT administrators visits the management page using a web browser, or a CloudVolumes Agent located within a virtual machine contains the CloudVolumes Manager. The CloudVolumes Agent is installed into any virtual machine that you’d like CloudVolumes to manage, and it only contains the CloudVolumes Manager during power on, power off, user login, and user logout. Even if a new VM is being powered on or created every second, a single CloudVolumes Manager can handle the load because it translates to only one HTTP request per VM.
Once the CloudVolumes Agent contains the CloudVolumes Manager to report the VM power-on event, the CloudVolumes Manager checks its database to see if there are any volumes associated with that VM or a group that VM is a member of. If so, the CloudVolumes Manager communicates with the hypervisor to attach the volumes to the VM, and then its job is done and there is no further communication between the CloudVolumes Manager and Agent until the next logon, logoff, or poweroff event occurs.
Most of the magic happens within the virtual machine once the volume has been attached to the virtual machine. The CloudVolumes virtualization software within the virtual machine detects when a writable volume or shared volumes have been attached instantly overlays its contents on top of the virtual machine based on the volume’s policy. This operation is instant because no files are being transferred. When the application launches, the I/O is transparently redirected to the appropriate location so that the application and operating system work exactly as they normally do.
If the number of virtual machines supported per hypervisor (VM density) in your existing environment is bound by RAM or CPU, CloudVolumes will make the virtual machines and applications easier to manage, but it won’t likely improve your VM density. However if your VM density is bound by IOPS, CloudVolumes will likely enable you to increase your VM density by enabling you to put shared content on faster, read-optimized storage. Similarly, CloudVolumes shared volumes can be easily cached at the hypervisor level so that the I/O doesn’t leave the physical box. If the applications are shared and the VM’s base disks are shared (using linked clones or using “fast provisioning” in VMware vCloud), then most IOPS from the VMs can be serviced from the cache without ever reaching the shared storage.