Object-Storage vs Block-Storage Comparison in OpenStack Folsom version

Object Storage Capabilities

• OpenStack provides redundant, scalable object storage using clusters of standardized servers capable of storing petabytes of data
• Object Storage is not a traditional file system, but rather a distributed storage system for static data such as virtual machine images, photo storage, email storage, backups and archives. Having no central "brain" or master point of control provides greater scalability, redundancy and durability.
• Objects and files are written to multiple disk drives spread throughout servers in the data center, with the OpenStack software responsible for ensuring data replication and integrity across the cluster.
• Storage clusters scale horizontally simply by adding new servers. Should a server or hard drive fail, OpenStack replicates its content from other active nodes to new locations in the cluster. Because OpenStack uses software logic to ensure data replication and distribution across different devices, inexpensive commodity hard drives and servers can be used in lieu of more expensive equipment.

Block Storage Capabilities

• OpenStack provides persistent block level storage devices for use with OpenStack compute instances.
• The block storage system manages the creation / attaching / detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs.
• In addition to using simple Linux server storage, it has unified storage support for numerous storage platforms including Ceph, NetApp, Nexenta, SolidFire, and Zadara.
• Block storage is appropriate for performance sensitive scenarios such as database storage, expandable file systems, or providing a server with access to raw block level storage.
• Snapshot management provides powerful functionality for backing up data stored on block storage volumes. Snapshots can be restored or used to create a new block storage volume.

而Rackspace所提供的Cloud Block Storage服務，就是利用OpenStack去打造的。

Reference:

[1] Amazon Elastic Block Storage, http://aws.amazon.com/ebs/
[2] Rackspace  Block Store, http://www.rackspace.com/cloud/block-storage/

XCP / Citrix Xenserver Volume Drivers on OpenStack

PS: Cinder是由Folsom版本開始從原本的nova-volume這部分去進行抽離的子專案

XenAPINFS

XenAPINFS is a Block Storage (Cinder) driver which is using an NFS share through XenAPI's Storage Manager to store virtual disk images and exposing those virtual disks as volumes.

XenAPINFS不能直接存取NFS，只能透過XenAPI Storage Manager來存取NFS。
( This driver is not accessing the NFS share directly, it is only accessing the share through XenAPI Storage Manager. )

This driver should be considered as a reference implementation for using XenAPI's storage manager in OpenStack ( present in XenServer and XCP).

配置方式

1. Local:
   推薦的做法，這樣的話可以使用qemu-img，但必須在當作Storage Controller上的XCP/Xenserver host上開啟一台PV guest VM安裝 cinder + XenAPINFS driver
2. Remote:
   不需要使用PV guest VM，直接拿XCP/Xenserver當作Storage Controller。但這樣的話只能用VDI格式的VHD。

Source Code:

1. Grizzly cinder, https://github.com/openstack/cinder/blob/stable/grizzly/cinder/volume/drivers/xenapi/sm.py

XenAPI Storage Manager Volume Driver ( only in Folsom version, 在grizzly版中似乎已經移除 )

The Xen Storage Manager Volume driver (xensm) is a XenAPI hypervisor specific volume driver

Source Code:

nova,
https://github.com/openstack/nova/blob/stable/folsom/nova/volume/xensm.py
cinder,
https://github.com/openstack/cinder/blob/stable/folsom/cinder/volume/xensm.py

功用:

1. provide basic storage functionality, including volume creation and destruction, on a number of different storage back-ends.
2. It also enables the capability of using more sophisticated storage back-ends for operations like cloning/snapshots, etc.

The list below shows some of the storage plugins already supported in Citrix XenServer and Xen Cloud Platform (XCP):

1. NFS VHD: 
   Storage repository (SR) plugin which stores disks as Virtual Hard Disk (VHD) files on a remote Network File System (NFS).
   
   
2. Local VHD on LVM: 
   SR plugin which represents disks as VHD disks on Logical Volumes (LVM) within a locally-attached Volume Group.
   
   
3. HBA LUN-per-VDI driver: 
   SR plugin which represents Logical Units (LUs) as Virtual Disk Images (VDIs) sourced by host bus adapters (HBAs). E.g. hardware-based iSCSI or FC support.
   
   
4. NetApp: 
   SR driver for mapping of LUNs to VDIs on a NETAPP server, providing use of fast snapshot and clone features on the filer.
   
   
5. LVHD over FC: 
   SR plugin which represents disks as VHDs on Logical Volumes within a Volume Group created on an HBA LUN. E.g. hardware-based iSCSI or FC support.
   
   
6. iSCSI: 
   Base ISCSI SR driver, provides a LUN-per-VDI. Does not support creation of VDIs but accesses existing LUNs on a target.
   
   
7. LVHD over iSCSI: 
   SR plugin which represents disks as Logical Volumes within a Volume Group created on an iSCSI LUN.
   
   
8. EqualLogic: 
   SR driver for mapping of LUNs to VDIs on a EQUALLOGIC array group, providing use of fast snapshot and clone features on the array.