Drivers for san-stored volumes.
The unique thing about a SAN is that we don’t expect that we can run the volume controller on the SAN hardware. We expect to access it over SSH or some API.
Bases: nova.volume.san.SanISCSIDriver
Executes commands relating to HP/Lefthand SAN ISCSI volumes.
We use the CLIQ interface, over SSH.
Rough overview of CLIQ commands used:
Createvolume : | (creates the volume) |
---|---|
Getvolumeinfo : | (to discover the IQN etc) |
Getclusterinfo : | |
(to discover the iSCSI target IP address) | |
Assignvolumechap : | |
(exports it with CHAP security) |
The ‘trick’ here is that the HP SAN enforces security by default, so normally a volume mount would need both to configure the SAN in the volume layer and do the mount on the compute layer. Multi-layer operations are not catered for at the moment in the nova architecture, so instead we share the volume using CHAP at volume creation time. Then the mount need only use those CHAP credentials, so can take place exclusively in the compute layer.
Creates a snapshot.
Creates a volume.
Creates a volume from a snapshot.
Deletes a volume.
Assigns the volume to a server.
Assign any created volume to a compute node/host so that it can be used from that host. HP VSA requires a volume to be assigned to a server.
This driver returns a driver_volume_type of ‘iscsi’. The format of the driver data is defined in _get_iscsi_properties. Example return value:
{
'driver_volume_type': 'iscsi'
'data': {
'target_discovered': True,
'target_iqn': 'iqn.2010-10.org.openstack:volume-00000001',
'target_portal': '127.0.0.0.1:3260',
'volume_id': 1,
}
}
Unassign the volume from the host.
Bases: nova.volume.driver.ISCSIDriver
Base class for SAN-style storage volumes
A SAN-style storage value is ‘different’ because the volume controller probably won’t run on it, so we need to access is over SSH or another remote protocol.
Returns an error if prerequisites aren’t met.
Exports the volume.
Synchronously recreates an export for a logical volume.
Removes an export for a logical volume.
Bases: nova.volume.san.SanISCSIDriver
Executes commands relating to Solaris-hosted ISCSI volumes.
Basic setup for a Solaris iSCSI server:
pkg install storage-server SUNWiscsit
svcadm enable stmf
svcadm enable -r svc:/network/iscsi/target:default
pfexec itadm create-tpg e1000g0 ${MYIP}
pfexec itadm create-target -t e1000g0
Then grant the user that will be logging on lots of permissions. I’m not sure exactly which though:
zfs allow justinsb create,mount,destroy rpool
usermod -P’File System Management’ justinsb
usermod -P’Primary Administrator’ justinsb
Also make sure you can login using san_login & san_password/san_private_key
Creates a volume.
Deletes a volume.
Synchronously recreates an export for a logical volume.
Removes an export for a logical volume.
Bases: nova.volume.san.SanISCSIDriver
Create volume on SolidFire device.
The account is where CHAP settings are derived from, volume is created and exported. Note that the new volume is immediately ready for use.
One caveat here is that an existing user account must be specified in the API call to create a new volume. We use a set algorithm to determine account info based on passed in nova volume object. First we check to see if the account already exists (and use it), or if it does not already exist, we’ll go ahead and create it.
For now, we’re just using very basic settings, QOS is turned off, 512 byte emulation is off etc. Will be looking at extensions for these things later, or this module can be hacked to suit needs.
Delete SolidFire Volume from device.
SolidFire allows multipe volumes with same name, volumeID is what’s guaranteed unique.
What we’ll do here is check volumes based on account. this should work because nova will increment its volume_id so we should always get the correct volume. This assumes that nova does not assign duplicate ID’s.