Storage

The installation requirements to storage vary depending on a storage strategy that you plan to deploy. In this document, you can find information on how to implement the following storage solutions: 

• Centralized Storage (SAN)
• Integrated Storage (OnApp Storage)
• SolidFire Storage
• StorPool Storage

On this page:

Centralized Storage (SAN)
Integrated Storage (OnApp Storage)
SolidFire Integration
StorPool Integration

See also: 

Integrated Storage
Servers

Centralized Storage (SAN)

The primary storage is critical to your cloud and your SAN has a huge impact on the performance of the whole platform. OnApp offers you a lot of flexibility in your primary storage technology. OnApp supports each solution that is capable of presenting a block device to compute resources. This could be, for example, FiberChannel, SCSI or SAS HBA, iSCSI or ATAoE, or a InfiniBand HCA controller, since all of them present the block device directly. OnApp does not support services such as NFS for primary storage, because they preset a filesystem and not the block device.

Beyond a type of the block device, there are three main things to consider in your SAN design: the host, fabric, and storage components. You need to think about each very carefully and pay particular attention to performance, stability, and throughput when designing your SAN.

Fabric Components - Network Fabric Between Compute Resources and SANs

You need to think about redundancy and whether you need to design a fault tolerant switching mesh to coincide with your multipath configurations at the host and SAN ends. You should also think about future growth: as you add more compute resources and SANs to the cloud, you need to be able to grow the physical connectivity without downtime on the Storage Network.

Host Components - Compute Resource Connectivity to Storage Network

You need to make sure that your Ethernet or HBA drivers are stable in this release. We recommend that you test this thoroughly before handing over to OnApp to deploy your cloud on your infrastructure. You also need to think about the throughput and whether the connectivity on compute resources will be suitable for the virtual servers they will be running. A bottleneck here will cause major performance issues. Consider adding multiple HBAs or NICs if you plan to run a redundant switching mesh (see the Fabric section) as bonding or multipath will be required, unless the redundancy is built into the physical switch chassis (for example, failover backplanes).

Storage Components - SAN Chassis, Controllers, and Disk Trays

You need to take into consideration physical capacity that is required to build a storage of a necessary size. This gives you a good idea on the size of disks you will be adding into the array and the RAID level you will choose. As a general rule, more spindles in the array will give you better performance: you should avoid using a small number of large disks or you will start to see I/O bottlenecks as you make an increasing use of the storage in future. You should also think about the physical storage hardware and whether you will use SATA, SAS or SSD. This will have a great impact on the I/O capabilities of the array.

It's also a good idea to consider RAID levels carefully and look into the advantages and disadvantages of each. We recommend RAID10. Although you will lose 50% of your capacity. you will see good performance for both read and write, which is important for primary storage. RAID10 will also give you much better redundancy on the array.

Controller caching is another issue to consider. You should always aim to have both read and write caching. If you are looking at write caching, you should also look at battery backups for the write cache. Some controllers also support SSD caching which can be a great advantage. As with the host components, you should also take your HBA and Ethernet connectivity into consideration to ensure you have both the redundancy and throughput required for your cloud infrastructure.

Integrated Storage (OnApp Storage)

OnApp Storage is a distributed block storage system that allows you to build a highly scalable and resilient SAN using local disks in compute resources. With OnApp Storage, you create a virtual data store that spans multiple physical drives in compute resources, with RAID-like replication and striping across drives. The SAN is fully integrated into the compute resource platform and the platform is completely decentralized. There is no single point of failure: for example, if a compute resource fails, the SAN reorganizes itself and automatically recovers the data. 

The following requirements are recommended for Integrated Storage implementation:

• Integrated Storage can group together any number of drives across any compute resource. We strongly recommend at least two drives per compute resource to enable redundant datastore configurations.
• SSD drives are recommended for best performance.
• At least one dedicated NIC assigned per compute resource for the storage network (SAN).
• Multiple NICs bonded or 10GBit/s Ethernet are recommended).

• MTU on storage NIC: 9000 is recommended.

• IGMP snooping must be disabled on a storage switch for a storage network.
  
  

SolidFire Integration

OnApp is integrated with the SolidFire storage management system. With the SolidFire integration, it is possible to use the SF SAN directly within the OnApp cloud and manage the SolidFire cluster via the SolidFire API. To be able to use SolidFire in the cloud, you need to install the SolidFire storage system first.

You can perform the following options with SolidFire:

• Use SolidFire SAN in the OnApp сloud. 
• Allocate dedicated LUNs from the SF cluster per virtual server disk, when creating a virtual server. 
  LUN is created per each virtual server disk, with a separate LUN per swap disk.
• Manage SolidFire LUNs automatically via API.
• Create virtual servers without a swap disk.
• Implement backups / snapshots using SF CloneVolume method.

There is a disk dependency between OnApp and SolidFire. When a new disk is created on the OnApp side, a new LUN  is created automatically on the SolidFire side, using the CreateVolume API call. The LUNs on the SolidFire are managed automatically via SolidFire API. Inasmuch a SolidFire data store has two interfaces: OnApp and SolidFire. You have to specify two IP addresses when creating a SolidFire Data Store.

To be able to use the SolidFire volume, you have to enable export to this device (a compute resource or data store). To do that, you need to send an account username and initiator password to the  iscsi_ip address. You will be able to use this device after the authorization.

The following options are not available for SolidFire:

• It is not possible to migrate SolidFire disks as SF virtualizes the storage layer.

• SolidFire does not support live disk resize. To resize a disk, you need to shut down a virtual server first and use the CloneVolume functionality to increase the disk size. After the disk resize operation is complete, the original volume is replaced with the new one and deleted, and the virtual server is booted.

StorPool Integration

OnApp provides and maintains integration with StorPool, whereas each VS disk becomes a separate volume in the StorPool storage system. 

OnApp with StorPool can be deployed in two modes - hyperconverged and standalone. 

• In ‘hyperconverged’ mode, StorPool storage servers are running on the OnApp hypervisors (Compute Resources) to pool the disks together to make a datastore that will be managed in its entirety by StorPool.
• In ‘standalone’ mode, StorPool storage servers are deployed on dedicated servers. In this case, StorPool block device drivers still need to be installed on the OnApp hypervisors and backup nodes, so they are able to access the StorPool storage and consume volumes.

With the StorPool integration, it is possible to get control over each individual volume, in terms of monitoring and data placement. To be able to use StorPool in the cloud, you need to install the StorPool storage system first. For details, refer to StorPool section of our documentation.