Manila/Networking

Manila

This is a page about networking for Manila (OpenStack Shared File Systems)

Overview of Choices

There are many options for how to create your network configuration in OpenStack and with Manila. Below are some examples of choices an administrator needs to make and what kind of impact thay have.

L2 vs L3 connectivity

• L2 - share servers have network interface created on a tenant-owned subnet
  • Direct access to storage by VMs on the same subnet
  • Requires network segmentation setup (VLAN, VXLAN)
  • Requires a driver capable of creating share-servers for each tenant
  • Can potentially cause broadcast domains to span racks or the whole datacenter
• L3 - share servers only accessible across a router
  • Works with any driver
  • Works with controllers that don't support the SVM/share-server concept
  • Limits broadcast domains
  • Requires virtual or physical router
  • For creation of share-servers, manila needs to take IPs from existing subnets, and in some cases create new subnets/routers

Share servers

• Created per tenant
  • Private network
    • Most secure
    • Works with generic driver, and some hardware-based drivers
  • Public network
    • Still provides high level of security
    • Accomodates storage controllers that don't understand vlans/vxlans
    • Acommodates lab configurations with physical switches not controlled by the developer
• Common
  • Security enforced by the storage controller rather than the network
  • Manila doesn't need to manage any network resources

Network management

• Neutron
  • Most capable, many features: flat, VLAN, VXLAN, GRE, etc
  • Not widely deployed by end users
  • This is where the manila project started
• Nova-net
  • Support both flat and VLAN based networking
  • Widely used
• Other Plugins
  • Minimize dependencies on external components
  • Simple plugin for development/test, not for production
  • Possible for end user customized plugins

Plans

Our top level goal is to provide flexibility to administrators so they can use Manila in their environment no matter what other choices they've made. The tradeoff is how to do that without overwhelming them with complexity.

For Icehouse and Juno, we stuck with a relatively narrow set of optionsː Neutron only, always create a share server for every tenant, and prefer L2 networking over L3. These choices were made because they provide maximum security and work well in a public cloud type environment.

The problem we face is that developers often can't recreate the complex network configuration that exist in public clouds in their development labs, and users who want to experiment with Manila face a high bar to setup a basic configuration.

For Kilo we need to expand the set of choices to make developer's lives easier and to make a simple proof-of-concept style deployment less difficult to achieve.