VDO can be deployed in a variety of ways to provide deduplicated storage for both block and file access and for both local and remote storage. Because VDO exposes its deduplicated storage as a standard Linux block device, it can be used with standard file systems, iSCSI and FC target drivers, or as unified storage.
As a simple example, the entirety of the VDO storage target can be exported as an iSCSI Target to remote iSCSI initiators.
Figure 29.3. Deduplicated Block Storage Target
If file access is desired instead, file systems can be created on top of VDO and exposed to NFS or CIFS users via either the Linux NFS server or Samba.
Figure 29.4. Deduplicated NAS
More feature-rich systems may make further use of LVM to provide multiple LUNs that are all backed by the same deduplicated storage pool. In Figure 29.5, “Deduplicated Unified Storage”
, the VDO target is registered as a physical volume so that it can be managed by LVM. Multiple logical volumes (
) are created out of the deduplicated storage pool. In this way, VDO can support multiprotocol unified block/file access to the underlying deduplicated storage pool.
Figure 29.5. Deduplicated Unified Storage
Deduplicated unified storage design allows for multiple file systems to collectively use the same deduplication domain through the LVM tools. Also, file systems can take advantage of LVM snapshot, copy-on-write, and shrink or grow features, all on top of VDO.
Data security is critical today. More and more companies have internal policies regarding data encryption. Linux Device Mapper mechanisms such as DM-Crypt are compatible with VDO. Encrypting VDO volumes will help ensure data security, and any file systems above VDO still gain the deduplication feature for disk optimization. Note that applying encryption above VDO results in little if any data deduplication; encryption renders duplicate blocks different before VDO can deduplicate them.
Figure 29.6. Using VDO with Encryption