Feature requests

[lohelle]

created a new topic as requested:

Feature requests:
- Vaai support -reclaim of space on dedupe devices when deleting files in VMFS, offload esxi hosts when cloning and svmotion

- Dedupe support for HA-devices

- Tool to "clean" target dedupe-device for unused dedupe blocks

- Change sync-channel NIC/IP for HA-targets - change ip, nic, mpio etc

- Sync channel bandwidth limit - possible to change with target online (easier than the priority slider in many cases)

- pause / resume on sync (HA)

- multi-lun support for HA-targets

- When resizing HA target, prefill with existing size

- Dedupe-device resize (same as for HA)

- auto-tiering (SSD/SAS/SATA)

- relocate device disk files, online if possible - Would be nice to move files to a temporary partition, recreate the RAID , then move the files back. All with the target online

- notify client when changes on target (when I add a lun on a Dell MD3220i, the LUN is visible on the ESX host without rescan of the iscsi adapter. I do not know if this is because vSphere has built in extended support for these types of targets)

***- RAM-disk on one of the HA-nodes. Recreated automaticly and synced after reboot. Not as secure as disks on both sides, but IO for reads would be EXTREME, and writes would be fast with proper writeback-cache for the other node.

*** =
I use SSD's on one node and SAS on the other. I use fixed paths in vSphere pointed at the SSD's. This way all hosts read with VERY high IOPS from the SSD-disks, and the shorts bursts of writes are usually handled by the cache on node 2. RAM-disks would be even faster than SSD for datastores that need HIGH IOPS.
I just bought 128GB DDR3 ECC REG memory for $1300 (8GB modules), so quite large RAM-disks would be within limits for most customers? My quad 8-core Opteron 6000 series server support 32 of these modules, and many other servers do.

[anton (staff)]

See my comments below after *** mark.

created a new topic as requested:

Feature requests:
- Vaai support -reclaim of space on dedupe devices when deleting files in VMFS, offload esxi hosts when cloning and svmotion

*** On the way. V6 will include both VAAI suport and automatic space de-allocation for dedupe and thin provisioning.

- Dedupe support for HA-devices

*** On the way. V6 will include it.

- Tool to "clean" target dedupe-device for unused dedupe blocks

*** On the way. V6 will include add-on to VSS service providers you're expected to run on client side. They will also "free" space.

- Change sync-channel NIC/IP for HA-targets - change ip, nic, mpio etc

*** You mean on the fly or what?

- Sync channel bandwidth limit - possible to change with target online (easier than the priority slider in many cases)

*** Do you mean sync channel bandwidth throttling?

- pause / resume on sync (HA)

*** OK

- multi-lun support for HA-targets

*** Already under way. V6 or post-V6 (not sure yet).

- When resizing HA target, prefill with existing size

*** What do you mean here?

- Dedupe-device resize (same as for HA)

*** Can only grow them via LUN increment. On the way (V6).

- auto-tiering (SSD/SAS/SATA)

*** On the way but pretty early. Post-V6.

- relocate device disk files, online if possible - Would be nice to move files to a temporary partition, recreate the RAID , then move the files back. All with the target online

*** That's what whole HA concept is for. Put device down, do what you do and re-sync.

- notify client when changes on target (when I add a lun on a Dell MD3220i, the LUN is visible on the ESX host without rescan of the iscsi adapter. I do not know if this is because vSphere has built in extended support for these types of targets)

*** We'll check is this possible for us...

***- RAM-disk on one of the HA-nodes. Recreated automaticly and synced after reboot. Not as secure as disks on both sides, but IO for reads would be EXTREME, and writes would be fast with proper writeback-cache for the other node.

*** You can create RAM disk now and just re-sync the thing from the very begining. As RAM should be small and fast not going to take a lot of time.

*** =
I use SSD's on one node and SAS on the other. I use fixed paths in vSphere pointed at the SSD's. This way all hosts read with VERY high IOPS from the SSD-disks, and the shorts bursts of writes are usually handled by the cache on node 2. RAM-disks would be even faster than SSD for datastores that need HIGH IOPS.
I just bought 128GB DDR3 ECC REG memory for $1300 (8GB modules), so quite large RAM-disks would be within limits for most customers? My quad 8-core Opteron 6000 series server support 32 of these modules, and many other servers do.

*** Also nothing from our side to make it working.

[lohelle]

- Change sync-channel NIC/IP for HA-targets - change ip, nic, mpio etc

*** You mean on the fly or what?

Yes, I mean change that on the fly.

- Sync channel bandwidth limit - possible to change with target online (easier than the priority slider in many cases)

*** Do you mean sync channel bandwidth throttling?

Yes, bandwidth throttling in Mbits/s

- When resizing HA target, prefill with existing size

*** What do you mean here?

When I want to resize a HA target I'm prompted to enter new size. Maybe the existing size should be prefilled or at least shown.


And the RAM-disk + HA suggestion. I see no choice to use RAM-disk on one node. I ment using Starwind's RAM-disk as one node, automaticly syncing with the disk target on the other node after reboot.

[anton (staff)]

1) Not sure about changing this stuff on the fly as there are issues.

2) OK, B/W throttling is fine. We'll add this (control, now it's automatic).

3) OK, so size is GUI issue.

4) OK, RAM disk for HA is fine.

- Change sync-channel NIC/IP for HA-targets - change ip, nic, mpio etc

*** You mean on the fly or what?

Yes, I mean change that on the fly.

- Sync channel bandwidth limit - possible to change with target online (easier than the priority slider in many cases)

*** Do you mean sync channel bandwidth throttling?

Yes, bandwidth throttling in Mbits/s

- When resizing HA target, prefill with existing size

*** What do you mean here?

When I want to resize a HA target I'm prompted to enter new size. Maybe the existing size should be prefilled or at least shown.


And the RAM-disk + HA suggestion. I see no choice to use RAM-disk on one node. I ment using Starwind's RAM-disk as one node, automaticly syncing with the disk target on the other node after reboot.

[lohelle]

Thank you for the feedback!
I really like the new 5.8 features, so great work!

Really looking forward to the 6.0 release!

[anton (staff)]

Hope to see you on V6 beta fest before actual release

Thank you for the feedback!
I really like the new 5.8 features, so great work!

Really looking forward to the 6.0 release!

[lohelle]

I have a cool (I think) feature request now that 3-node HA is coming.
How about making it possible to use RAMDISK as one of the nodes? The partner device will need to be automaticly recreated after reboot then..

I could have a 60GB SSD on two nodes and a 60GB RAMDISK on the third, then use fixed path to the RAMDISK (10GbE) to have enormous IO potensial. If the node go down, one of the SSD's will take over. But then when the RAMDISK-node is up again (and synced), this path will be active again.

I have at least one database where this would be perfect (mostly reads).

If we have to use writeback-cache on the SSD-target of 60GB (to cache the entire target), this would require 60GB of extra RAM on both/all nodes.

[anton (staff)]

I don't see any stoppers here.We'll check what could be done and when. Thank you for your suggestion!

[Alex (staff)]

We have examined the scenario with 3 nodes and RAM disk, and we've got another idea.
You can set different cache sizes for two HA nodes. Cache modes must be equal, but cache sizes can vary.

So you can set up 64MB cache for one node and 60GB for the other node.
It can be done now by editing cache size value for the HA ndoe device in starwind.cfg file (restart service after editing the file).

Most likely we will add this feature to GUI wizard for HA in the next version of StarWind iSCSI SAN.

[lohelle]

OK! Great!

Btw, would it be possible to "force" the node with large cache to "read" the entire image. So that the intire target is cached as fast as possible?

[anton (staff)]

Yes, but it's not going to make any good to you unless you're doing mostly reads and not writes.

OK! Great!

Btw, would it be possible to "force" the node with large cache to "read" the entire image. So that the intire target is cached as fast as possible?

[lohelle]

Yepp! But it will help VERY MUCH on databases where applications is reading like crazy generating reports etc. :=)

[anton (staff)]

We'll do it!