Before you deploy Quantum, it is useful to understand the different components that make up the solution and how those components interact with each other and with other OpenStack services.
Quantum is a standalone service, just like other OpenStack services such as Nova, Glance, Keystone, and Horizon. Like those services, a deployment of Quantum often involves deploying several processes on a variety of hosts.
The main process of the Quantum Service is
quantum-server
, which is a
Python daemon that exposes the Quantum API and passes
user requests to the configured Quantum plugin for
additional processing. Typically, the plugin requires
access to a database for persistent storage, similar
to other OpenStack services.
If your deployment uses a controller host to run centralized OpenStack Nova components, you can deploy Quantum on that same host. However, Quantum is entirely standalone and can be deployed on its own server as well. Quantum also includes additional agents that might be required depending on your deployment:
plugin agent (
quantum-*-agent
). Runs on each hypervisor to perform local vswitch configuration. Agent to be run depends on which plugin you are using, as some plugins do not require an agent.dhcp agent (
quantum-dhcp-agent
). Provides DHCP services to tenant networks. This agent is the same across all plugins.l3 agent
(quantum-l3-agent
). Provides L3/NAT forwarding to provide external network access for VMs on tenant networks. This agent is the same across all plugins.
These agents interact with the main quantum-server process in the following ways:
Through RPC. For example, rabbitmq or qpid.
Through the standard Quantum API.
Quantum relies on the OpenStack Identity Project (Keystone) for authentication and authorization of all API request.
OpenStack Nova interacts with Quantum through calls to its standard API. As part of creating a VM, nova-compute communicates with the Quantum API to plug each virtual NIC on the VM into a particular Quantum network.
Horizon has basic integration with the Quantum API, allowing tenants to create networks and subnets through the GUI, and specify the set of networks that a VM should connect to when it is launched. See the Horizon Administrator Guide.