Since the inception of Springpath, one of our primary objectives has been to ensure we provide excellent data services while enabling IT admins to easily manage their infrastructure. Springpath’s data services enable IT admins to achieve new levels of storage efficiency and performance while simplifying operational burden by integrating into existing management frameworks for VMware and Openstack.
Let me start with some background: Snapshot is a read-only state of a VM at a particular point. Clone is copy of a VM which has its own new identity. They play a very important role in the ever-growing VDI, Test/Dev and other environments where IT is looking for agility to create and delete clones and snapshot virtual machines for backups
Some of the key design objectives to keep in mind when architecting a solution for clones and snapshots are:
- Ability to quickly create space efficient clones/snapshots without performance degradation. Ideally, performance should improve using common data caching for reads and ability to dedupe for writes
- Deletion should be fast and avoid additional overheads (free space management)
- Efficient space reporting across clones and snapshots – the number of shared blocks vs unique blocks – is critical, since it helps admins to manage storage efficiently and keep tabs on storage utilization
- Maintaining data consistency for virtual disks distributed across multiple nodes in the cluster
These objectives have been imbibed into the Springpath’s distributed filesystem.
In Springpath HALO architecture, any writes and update operations are logged to the SSD journal through extremely fast distributed key value store, which gets replicated across other servers in the cluster based on the number of replicas chosen to handle node/disk failures. At an opportune time the journal is de-staged to the actual capacity tier.
In some architectures, the journal is prematurely de-staged when snapshot/clone request arrives, thus increasing the response time. In Springpath’s architecture, creating a clone/snapshot is just a single write to the SSD and its mirrors. The file is check-pointed in memory once the request is logged to the SSD and does not require any premature de-staging of the data to the capacity tier.
At the filesystem level, taking a space efficient clone involves making sure that the blocks are shared between source and destination and does not involve a full copy. Many existing solutions use some variation of referencing counting to indicate if the block is shared or not. The reference counting comes with its own set of challenges and degrades the performance either at the time of creation, deletion or space calculations.
Given the unique nature of the Springpath’s log structured filesystem, no explicit recounting is required, thus allowing us to perform all the operations quickly and efficiently. Taking a clone or a snapshot simply involves copying the top level file pointer consuming just a few KBs, thus sharing all the blocks including metadata with the source. No special handling is needed for new writes to the source or the clone, the log structured filesystem uses redirect-on-write (ROW) for any new writes in the filesystem. All new write blocks, at customizable block sizes, are appended to the end, with old blocks being garbage collected using our cleaner process. Deletion of a snapshot or clone is done by removing the top level file entry. Multiple ￼background operations ensure that space utilization is balanced across the whole cluster for maximum resource utilization and there is no fragmentation over time with the deletion of clones/snapshots or (over)writing with new data.
ReadyClones with Springpath
Springpath Data platform supports creation and deletion of hundreds of VM clones within minutes, without impacting performance. The native clone integration enables IT admins to use both VMware’s standard customization as well as Springpath’s ability to customize batches of clones. Native clones of powered on VMs can be taken – a result of the platform’s native snapshot integration.
Snapshots at multiple levels of granularity
The seamless integration enables existing VM based solutions to take advantage of Springpath’s native snapshots – using a hypervisor snapshot manager. Snapshots can also be taken at folder level. Admins can set automatic schedules to take snapshots of VM or VMs folders at hourly, daily or weekly intervals – which is useful for local backups.
Springpath is VMware Ready and VAAI certified. The platform uses VAAI offload to support the native operations. For Openstack, we deliver rapid snapshots using Cinder and Nova integration.
To see these features in action, watch the demo: