Atom feed of this document
 

 Design and Operation

 Definitions
  • Backend: A term for a particular storage backend. This could be iSCSI, NFS, Netapp etc.

  • Backend-config: All the parameters required to connect to a specific backend. For e.g. For NFS, this would be the server, path, etc.

  • Flavor: This term is equivalent to volume "types". A user0friendly term to specify some notion of quality of service. For example, "gold" might mean that the volumes will use a backend where backups are possible. A flavor can be associated with multiple backends. The volume scheduler, with the help of the driver, will decide which backend will be used to create a volume of a particular flavor. Currently, the driver uses a simple "first-fit" policy, where the first backend that can successfully create this volume is the one that is used.

 Operation

The admin uses the the nova-manage command detailed below to add flavors and backends.

One or more nova-volume service instances will be deployed per availability zone. When an instance is started, it will create storage repositories (SRs) to connect to the backends available within that zone. All nova-volume instances within a zone can see all the available backends. These instances are completely symmetric and hence should be able to service any create_volume request within the zone.



loading table of contents...