Process Structure¶
There are three processes that make up the Manila service:
manila-apiis a WSGI application that accepts and validates REST (JSON) requests from clients and routes them to other Manila processes as appropriate over AMQP.manila-schedulerdetermines which backend should serve as the destination for a share creation request. It maintains non-persistent state for pools and backends (e.g. available capacity, capabilities, and supported extra specs) that can be leveraged when making placement decisions. The algorithm utilized by the scheduler can be changed through Manila configuration.manila-shareaccepts requests from other Manila processes and serves as the operational container for Manila drivers. This process is multi-threaded and typically has one thread of execution per Manila backend as defined in the Manila configuration file.
Figure 6.1. Manila Processes Concept Diagram¶
Share Creation Workflow - With Share Servers¶
The following section walks through the steps that occur when a user requests the creation of a new share from Manila, and a backend is selected that uses share servers.
Figure 6.2. Manila Workflow - Share Creation with Share Servers¶
Client issues request to create share through invoking REST API (client may use
python-manilaclientCLI utility).The
manila-apiandmanila-schedulerprocesses perform the following tasks:manila-apiprocess validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-shareprocess takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-schedulerprocess takes message off of queue, generates candidate list of resource pools based on current state and requested share criteria (size, availability zone, share type (including extra specs)).manila-shareprocess reads response message frommanila-schedulerfrom queue; iterates through candidate list by invoking backend driver methods for corresponding pools until successful.
The share manager associated with the backend selected by the
manila-schedulercalls out to the network service associated with the backend (either the standalone plugin, Neutron, or Nova Network; defined through the appropriate stanza inmanila.conf) to get the required information (including share IP address, network segmentation ID, etc.).If selected by the scheduler, NetApp’s Manila driver creates requested share (and, if necessary, a share server) through interactions with storage subsystem (dependent on configuration and protocol).
manila-shareprocess creates share metadata and posts response message to AMQP queue.manila-apiprocess reads response message from queue and responds to client with share ID information.After a share is created and exported by the backend, client uses ID information to request updated share details and uses export information from response to mount share (using protocol-specific commands).
Share Creation Workflow - Without Share Servers¶
The following section walks through the steps that occur when a user requests the creation of a new share from Manila and a backend is selected that does not use share servers.
Figure 6.3. Manila Workflow - Share Creation without Share Servers¶
Client issues request to create share through invoking REST API (client may use
python-manilaclientCLI utility).The
manila-apiandmanila-schedulerprocesses perform the following tasks:manila-apiprocess validates request, user credentials; once validated, puts message onto AMQP queue for processing.manila-shareprocess takes message off of queue, sends message to manila-scheduler to determine which pool and backend to provision share into.manila-schedulerprocess takes message off of queue, generates candidate list of resource pools based on current state and requested share criteria (size, availability zone, share type (including extra specs)).manila-shareprocess reads response message frommanila-schedulerfrom queue; iterates through candidate list by invoking backend driver methods for corresponding pools until successful.
If selected by the scheduler, NetApp’s Manila driver creates requested share through interactions with storage subsystem (dependent on configuration and protocol).
Without the existence of a share server, NetApp’s Manila driver will export shares through the data LIFs that exist within the SVM that is scoped to the Manila backend.
manila-shareprocess creates share metadata and posts response message to AMQP queue.manila-apiprocess reads response message from queue and responds to client with share ID information.After a share is created and exported by the backend, client uses ID information to request updated share details and uses export information from response to mount share (using protocol-specific commands).
This document is licensed under Apache 2.0 license.