Integrated Storage

Integrated Storage functionality allows the cloud admin to build a highly scalable and resilient SAN storage target for virtual server storage using local disks in Compute resources. Using the Integrated Storage, you can create a virtual data store in OnApp Cloud 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: each node is capable of making decisions about data synchronization and load balancing, and communicates directly with other nodes to move content around dynamically without depending on any centralized controller. There is no single point of failure: for example, if a Compute resource fails, the SAN reorganizes itself and automatically recovers the data. The OnApp Integrated Storage makes exclusive use of CloudBoot to provision Compute resources, so Compute resources must be booted via CloudBoot in order to enable the integrated SAN functionality. For details, refer to the CloudBoot Compute resources section.

Known Limitations and Restrictions

  • You can use integrated storage on XEN and KVM cloudbooted Compute resources only. Vmware Compute resources are not supported for IS.
  • Currently it is not possible to utilize bonded NICs for the CloudBoot management/boot interface.
  • To start using integrated storage, you must have a Manage OnApp Storage permission enabled for your user role. Also, you have to enable the integrated storage in the system configuration manually (Settings > Configuration > OnApp Storage). Visit Configuration Settings chapter for more details.
  • Integrated Storage supports PCI devices that have drivers compatible with the Linux kernel versions we use.
  • Some customers may experience MAC address flapping across ports because the switch does not support the balance-rr mode. In this case, we recommend to  set up separated VLANS per each bond pair for that switch.
  • If an IS data store is created with overcommit (overcommit is not equal to none) and a backend node in the data store runs out of space, the storage controller which manages the backend node will become unavailable and vdisk paths will become degraded. Enabling overcommit and running out of physical space is a bad condition and should always be avoided. It is strongly recommended that you create data store with overcommit = none for production purposes.

For the detailed information on the following topics, refer to the Integrated Storage Guide: