.. _shared_file_systems_key_concepts: ============ Key concepts ============ Share ~~~~~ In the Shared File Systems service ``share`` is the fundamental resource unit allocated by the Shared File System service. It represents an allocation of a persistent, readable, and writable filesystem that can be accessed by OpenStack compute instances, or clients outside of OpenStack (depending on deployment configuration). .. note:: A ``share`` is an abstract storage object that may or may not directly map to a "share" concept from the underlying storage provider. Snapshot ~~~~~~~~ A ``snapshot`` is a point-in-time, read-only copy of a ``share``. ``Snapshots`` can be created from an existing ``share`` that is operational regardless of whether a client has mounted the file system. A ``snapshot`` can serve as the content source for a new ``share`` when the ``share`` is created with the create from snapshot option specified. Storage Pools ~~~~~~~~~~~~~ With the Kilo release of OpenStack, the Shared File Systems service has introduced the concept of ``storage pools``. The storage may present one or more logical storage resource pools from which the Shared File Systems service will select as a storage location when provisioning ``shares``. Share Type ~~~~~~~~~~ ``Share type`` is an abstract collection of criteria used to characterize ``shares``. They are most commonly used to create a hierarchy of functional capabilities that represent a tiered level of storage services; for example, a cloud administrator might define a premium ``share type`` that indicates a greater level of performance than a basic ``share type``, which would represent a best-effort level of performance. Share Access Rules ~~~~~~~~~~~~~~~~~~ ``Share access rules`` define which users can access a particular ``share``. For example, access rules can be declared for NFS shares by listing the valid IP networks (using CIDR notation) which should have access to the ``share``. Security Services ~~~~~~~~~~~~~~~~~ ``Security services`` are the concept in the Shared File Systems service that allow Finer-grained client access rules to be declared for authentication or authorization to access ``share`` content. External services including LDAP, Active Directory, Kerberos can be declared as resources that should be consulted when making an access decision to a particular ``share``. ``Shares`` can be associated to multiple security services but only one service per one type. Share Networks ~~~~~~~~~~~~~~ A ``share network`` is an object that defines a relationship between a tenant's network/subnet (as defined in an OpenStack network service (Neutron or Nova-network)) and the ``shares`` created by the same tenant; that is, a tenant may find it desirable to provision ``shares`` such that only instances connected to a particular OpenStack-defined network have access to the ``share``. Also, ``security services`` can be attached to ``share networks``, because most of auth protocols require some interaction with network services. Share Servers ~~~~~~~~~~~~~ A ``share server`` is a logical entity that hosts the shares that are created on a specific ``share network``. A ``share server`` may be a configuration object within the storage controller, or it may represent logical resources provisioned within an OpenStack deployment that are used to support the data path used to access ``shares``. ``Share servers`` interact with network services to determine the appropriate IP addresses on which to export ``shares`` according to the related ``share network``. The Shared File Systems service has a pluggable network model that allows ``share servers`` to work with different implementations of Network service.