[pve-devel] RFC : new storage model for nexenta san implementation

Alexandre DERUMIER aderumier at odiso.com
Mon Feb 13 09:07:58 CET 2012


Hi,

As you know, I use proxmox mainly with iscsi direct lun access.

Current proxmox implementation works good, but it's very difficult to manage it with many luns, many paths and it's quite cpu intensive with multipath.

Currently, we can only use 1 target, with all luns in the target

so I have 500 luns,4 paths, so 2000 /dev/sdxx devices, on each hosts + 500 multipath /dev/dm-   (and you need also add -partx)


Problems:

- When host boot, it can take 10minutes to parse all drives.
- Multipath daemon need to check each devices, it can take 100% cpu of 1 core, cause a lot of ios on san, and can something lag/hang/freeze.
- If you delete a lun in the san, you need to manually delete all luns in the promox hosts (and it's really not easy)
- Sometime, deviceid can change. (if you rollback a snapshot, or you failover on another nexenta head node (multi san controller).


So i'm working on a new nexenta storage model:

- 1 target - 1 lun mapping
- login/logout to target when vm start/shutdown.  (so you have only the luns you really use on your hosts)
- create/delete lun volume from nexenta (through nexenta json api), like a local drive :)
- new conf file sample : virtio0 : nexenta:nexentavolumename,cache=off,...


I currently have done 80% of the work (need some cleanup), only with change Storage.pm, with a new storage->{type), so it doesn't break current iscsi type.

I see that openstack use same implementation

http://wiki.openstack.org/NexentaVolumeDriver


What do you think about it ?
Do you think I can push it for proxmox2 release ? (I think I'll finish it in 1 week, maybe 2)

-Alexandre




More information about the pve-devel mailing list