はじめに¶
The Shared File Systems service (manila) is intended to be ran on a single-node or across multiple nodes. The Shared File Systems service consists of four main services, which are similar to those of the Block Storage service:
manila-api
manila-scheduler
manila-share
manila-data
manila-api
The service that provides a stable RESTful API. The service authenticates and routes requests throughout the Shared Filesystem service. There is python-manilaclient to interact with the API. For more details on the Shared File Systems API, see the OpenStack Shared File Systems API.
manila-share
Responsible for managing Shared File Service devices, specifically the back-end devices.
manila-scheduler
Responsible for scheduling and routing requests to the appropriate
manila-share
service. It does that by picking one back-end while filtering all except one back-end.manila-data
This service is responsible for managing data operations which may take a long time to complete and block other services if not handled separately.
The Shared File Systems service uses an SQL-based central database that is shared by all Shared File Systems services in the system. It can use any SQL dialect supported by ORM SQLALchemy, but is tested only with MySQL and PostgreSQL data bases.
Using SQL, the Shared File Systems service is similar to other OpenStack services and can be used with any OpenStack deployment. For more details on the API, see the OpenStack Shared File Systems API description. For more details on the CLI usage and configuration, see Shared File Systems Cloud Administrative Guide.
On the image below you can see how different parts of the Shared File System service interact with each other.
Besides already described services you can see two other entities on the
image: python-manilaclient
and storage controller
.
python-manilaclient
Command line interface to interact with the Shared File Systems service via
manila-api
and also a Python module to interact programmatically with the Shared File Systems service.Storage controller
Typically a metal box with spinning disks, ethernet ports, and some kind of software that allows network clients to read and write files on the disks. There are also software-only storage controllers that run on arbitrary hardware, clustered controllers which may run allow a multiple physical devices to appear as a single storage controller, or purely virtual storage controllers.
A share is a remote, mountable file system. You can mount a share to and access a share from several hosts by several users at a time.
The Shared File Systems service can work with different network types: flat, VLAN, VXLAN, or GRE, and supports segmented networking. There are also different network plug-ins that provide a variety of integration approaches with the network services that are available with OpenStack.
There are a large number of share drivers created by different vendors which support different hardware storage solutions, for example, NetApp Clustered Data ONTAP (cDOT) Driver, Huawei NAS Driver or GlusterFS Driver. Each share driver is a Python class that can be set for a back end and run in the back end to manage share operations, some of which can be vendor-specific. The back end is an instance of the manila-share service.
Clients' configuration data for authentication and authorization can be stored by security services. Such protocols as LDAP, Kerberos, or Microsoft Active Directory authentication service can be configured and used.
Unless it is not explicitly changed in the policy.json
, either an
administrator or the tenant that owns a share are able to manage
access to the shares. Access management is done by
creating access rules with authentication through IP address, user, group, or
TLS certificates. Available authentication methods depend on which share
driver and security service you configure and use.
注釈
Different drivers support different access options depending on which shared file system protocol is used. Supported shared file system protocols are NFS, CIFS, GlusterFS, and HDFS. For example, the Generic (Block Storage as a back end) driver does not support user and certificate authentication methods. It also does not support any of the security services, such as LDAP, Kerberos, or Active Directory. For details of features supported by different drivers, see Manila share features support mapping.
As an administrator, you can create share types that enable the scheduler to filter back ends before you create a share. Share types have extra specifications that you can set for the scheduler to filter and weigh back ends so that an appropriate one is selected for a user that requests share creation. Shares and share types can be created as public or private. This level of visibility defines whether other tenants are able to see these objects and operate with them, or not. An administrator can add access to the private share types for specific users or tenants in the Identity service. Thus users which you have granted access can see available share types and create shares using them.
Permissions for API calls for different users and their roles are determined by policies like in other OpenStack services.
The Identity service can be used for authentication in the Shared File Systems service. See details of the Identity service security in Identity section.
一般的なセキュリティー情報¶
Similar to other OpenStack projects, the Shared File Systems service is registered with the Identity service, so you can find API endpoints of the share service v1 and v2 using manila endpoints command:
$ manila endpoints
+-------------+-----------------------------------------+
| manila | Value |
+-------------+-----------------------------------------+
| adminURL | http://172.18.198.55:8786/v1/20787a7b...|
| region | RegionOne |
| publicURL | http://172.18.198.55:8786/v1/20787a7b...|
| internalURL | http://172.18.198.55:8786/v1/20787a7b...|
| id | 82cc5535aa444632b64585f138cb9b61 |
+-------------+-----------------------------------------+
+-------------+-----------------------------------------+
| manilav2 | Value |
+-------------+-----------------------------------------+
| adminURL | http://172.18.198.55:8786/v2/20787a7b...|
| region | RegionOne |
| publicURL | http://172.18.198.55:8786/v2/20787a7b...|
| internalURL | http://172.18.198.55:8786/v2/20787a7b...|
| id | 2e8591bfcac4405fa7e5dc3fd61a2b85 |
+-------------+-----------------------------------------+
By default, the Shared File Systems API service listens only on the port
8786
with tcp6
type that supports both IPv4 and IPv6.
注釈
The port 8786
is the default port for the Shared File Systems service.
It may be changed to any other port, but this change should also be made
in the configuration file to option osapi_share_listen_port
which
defaults to 8786
.
In the /etc/manila/
directory you can find several configuration files:
api-paste.ini
manila.conf
policy.json
rootwrap.conf
rootwrap.d
./rootwrap.d:
share.filters
It is recommended that you configure the Shared File Systems service to run
under a non-root service account, and change file permissions so that only
the system administrator can modify them. The Shared File Systems service
expects that only administrators can write to configuration files and services
can only read them through their group membership in manila
group. Others
must not be able to read these files because the files contain admin passwords
for different services.
Apply checks Check-Shared-01: 設定ファイルのユーザー/グループの所有権が root/manila に設定されていますか? and Check-Shared-02: 設定ファイルに厳しいパーミッションが設定されていますか? from the checklist to verify that permissions are set properly.
注釈
The configuration for manila-rootwrap in file rootwrap.conf
and the
manila-rootwrap command filters for share nodes in file
rootwrap.d/share.filters
should be owned by, and only-writeable by, the
root user.
Tip
The manila configuration file manila.conf
may be placed anywhere.
The path /etc/manila/manila.conf
is expected by default.