Bug 1041699 - [RFE][cinder]: fencing and unfencing host from storage
Summary: [RFE][cinder]: fencing and unfencing host from storage
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/cind...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 18:42 UTC by RHOS Integration
Modified: 2015-03-19 17:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:09:39 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 18:42:00 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/fencing-and-unfencing.

Description:

 The goal is supporting HA for instances running above OpenStack, by enabling correct mitigation of a host failure.
Please note this proposal does not deal with the HA of Cinder itself, nor the volumes managed by Cinder.

 

When we get an indication that a host has failed, we may like to rebuild its instances on other hosts. Yet, getting a host failure indication does not necessarily guaranty that the host won't attempt to access the storage. An instance on the failed host might still try accessing the storage due to one of the following reasons. First, the failure might be a transient one. Second, the failure might be only partial, such that the control framework does not see the host, yet the host is still running and can access the storage. In such a case, rebuilding the instance on another host may lead to a conflict, where both instances are trying to access a same volume at the same time. Trying to cleanup or shut down the failed host might fail due to the transient or partial failure state. For some systems there is an option to turn off the power through an external device, yet such an option is not always available. Thus we would like to have the capability to prevent the host from accessing the storage by fencing it in the storage controller through a new fence_host method.

 

1) Fencing

Fence a host from storage would include preventing the host from accessing the volumes which were attached to it, as well as preventing its nova-compute to create new connections.

Fencing will be done with the following method:

def fence_host(self, context, host_name, connector)

The fencing will take care of

    Removing the host from the list of hosts permitted to access instances in the  storage driver
    Adding the host to a (new) list of hosts forbidden to create connections in Cinder

If the driver needs further information about the host, such as iSCSI initiator names or WWPNs, it would derive them out of the connector.

Synchronization would be addressed in order to prevent a race between an attempt to establish connection and the fence_host operation.  

 

2) Unfencing

After some time it may be desired to remove the host from the list of hosts forbidden to create connections in Cinder, e.g., after it is recovered and cleaned from the obsolete instances, or when the host is removed from the data center. This would be done through the following method:

def unfence_host(self, context, host_name)

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.