Manila/Kilo Network Changes
Contents
Introduction
This document is intended to outline the design changes around Manila networking in the Kilo release.
Use Cases
Simple lab config
A manila developer wants to write a driver for a new hardware platform. The hardware exists in a lab plugged into a network switch with no VLAN tagging. The developer has no management access on the switch or router and while he does have management access on the storage controller he doesn't have any physical access to modify cabling. The storage controller is configured with static IP addresses on its management and data interfaces. On the plus side, the developer had gotten the lab administrators to set aside a pool of IP addresses on the same subnet which he can use to create SVMs.
- Network: flat, single subnet, multiple SVMs
- Security: none
- Other considerations: none
POC installation at a customer site
A customer which already uses OpenStack with some commercial storage wants to experiment with Manila to learn about it and evaluate how useful it might be. The customer already owns several storage controllers but they are all in use either in production or in other proofs of concept or test projects in the eval lab. The customer has administrator access to and physical access to all of the revelant equipment but doesn't wish to disturb the existing environment just to do a quick POC. A storage controller will need to be shared, and the shared controller is cabled to a network switch with no VLAN tagging.
- Network: flat, single subnet, single SVM
- Security: none
- Other considerations: none
Enterprise private cloud
An IT department has built a moderately large private cloud to serve various business units in one company. The business units all know about eachother and rely one simple access control to protect data from prying eyes and accidental damage. The main motivation for building a cloud is the "aaS" model which allows IT to be more efficient and responsive. The company is a large user of NAS storage (on commercial storage controllers) and IT wants to roll out Manila in production to begin to offer NASaaS so its userbase can eventually stop using traditional NAS. The IT department has complete control of its network design, physically and logically. Because all of the "tenants" of the private cloud exist within one company a significant amount of infrastructure is shared, including Active Directory, LDAP, and Kerberos, and tenants are not firewalled off from eachother in any strict sense.
- Network: flat, multiple subnets, multiple SVMs
- Security: tenants should not be able to access shares of other tenants
- Other considerations: none
Public cloud
A company that offers cloud services to the public, based on OpenStack, would like to deploy Manila in production and begin to offer NASaaS to its customers alongside block and object storage. Tenants expect complete privacy for their data, both in motion and at rest. Some customers have VPN connections between their corporate offices and the cloud which their expect only their own VMs to be able to access.
- Network: segmented, multiple subnets, multiple SVMs
- Security: tenants should not be able to detect the existence of others tenants
- Other considerations: network segmentation may be VLAN, VXLAN, or GRE
Standalone installation for management of existing NAS
An IT department wishes to offer NASaaS to users but currently uses funky proprietary cloud software written by engineers with bad taste. They decide to use Manila but without the rest of the OpenStack. Commercial storage controllers are dedicated specifically for this purpose.
- Network: flat, multiple subnets, multiple SVMs
- Security: tenants should not be able to access shares of other tenants
- Other considerations: none
Automated test system
A manila developer would like to be able to quickly setup Manila inside a virtual environment for testing. Manila and all of the rest of OpenStack will run inside a single VM with network connectivity to the outside world provided by a virtual router. The storage controller to be tested is not virtualized and is shared with multiple test nodes. The developer has access to configure the storage controller but the VM where the tests are being run is in a different locale, connected only by IP to the storage controller.
- Network: flat, single subnet, single SVM
- Security: none
- Other considerations: none
Field demo
A developer wishes to install a complete OpenStack installation including Manila on his laptop to be able to demo it in the field while disconnected from the internet. Everything is virtualized.
- Network: flat, single subnet, multiple SVMs
- Security: none
- Other considerations: none
Design Changes
To accommodate the above use cases, the following changes to Manila will be neededː
Administrators should have a way to make a single share server usable by multiple tenants, and disable the creation of new share servers. This enables cases where share servers cannot be created by Manila either because of lack of access or lack of networking resources.
Open questionsː
- How will the share server get imported into Manila? Conf file options? A new admin API?
- Is there any point in allowing a mix of manila-created share servers with administrator create share servers?
Administrators should have a way to make a single share network usable by multiple tenants. This network is used to create new share servers when the tenant declines to specify a share network (acting as a "default share network").
Open questionsː
