Obsolete:Cinder/FibreChannelSupport
- Launchpad Entry: CinderSpec
- Created: 15 Nov 2012
- Contributors: Gary Thunquest
Summary
Currently block storage volumes can be attached to hosts via iSCSI. This blueprint adds support for block storage attaching to hosts via Fibre Channel SANs as well. Support for Fibre Channel (FC) including Fibre Channel over Ethernet (FCoE) is planned.
iSCSI and FC will be able to be used simultaneously within the infrastructure, and adding FC can’t break existing iSCSI cinder volume drivers.
The scope of changes intended by this blueprint includes:
- Handling FC endpoint addressing (WWN’s vs. iqn’s + IP addresses), and allow FC endpoints to be passed through the system
- Reading of the host initiator WWNs
- Defining a new FibreChannelDriver superclass to facilitate the creation of Fibre Channel based cinder volume drivers
- Adding support for the nova host commands necessary to initialize a connection between a VM and a FC volume.
- Intending to implement for KVM only. Support for other hypervisors will be handled in subsequent blueprints.
FC support immediately raises the question of how FC SAN zoning will be performed. The scope of this blueprint does not include SAN zone management. A separate blueprint defining automated zone management is being submitted which will work together with this blueprint. This blueprint, however, does stand alone, in that FC SAN based deployments which require no zoning (open-zoned or pre-zoned SANs) can be fully supported with the changes defined in this blueprint.
Release Note
This feature supports Fibre Channel attached cinder volumes. Require a Fibre Channel cinder driver talking to a backend Fibre Channel array & SAN.
Rationale
FC support is required by enterprise data centers with Fibre Channel storage investments wanting to deploy private clouds using OpenStack.
User stories
To use:
- Infrastructure setup requires FC SAN connectivity between hosts and storage device(s)
- Backend cinder volume provider supporting FC storage attachment capability
User level volume operations (create/delete/snapshot/attach, etc.) will function the same for FC volumes as with iSCSI volumes.
It is intended that Cinder volume drivers supporting FC storage will publish a driver FC “capability” that will work with the Grizzly “volume types” facility to allow types to be defined to use FC vs. iSCSI if they choose.
Assumptions
Security – iSCSI volumes use CHAP security to control access to volumes from hosts. FC doesn’t have an equivalent mechanism. With FC, access control is provided though SAN zoning and LUN masking on the arrays. However, both of these mechanisms rely on trusted initiator WWNs. This design assumes initiator WWNs logging into the SAN are trusted.
