aprib

Just check with your synology's manual if iSCSI is supported.
The NAS will be the iSCSI target and you will have to set it up / configure it there.
Your Windows machine will be using that iSCSI disk(s) on your NAS with the use of the iSCSI initiator application (which is available as standard from win7 onwards).
There are many howtos available on the net.

All the balancer options are well, in the Balancer settings page.  Open the UI, find the "Pool Options" button/menu thing (underneath the pie chart) and select "Balancers".
This lets you specify when they're triggered. And then there is the "balancers" tab, that lets you select which balancers are enabled, which order they're assigned, and you can definitely disable them.
 
As for advanced options:
http://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings
That includes instructions on how to configure the option, as well a brief descriptions on what each setting does.

There was an issue with the way that HyperV locked the files, that caused issues with DrivePool, and vice versa.
 
Please download the 2.1.0.503 Beta, as the issue should be fixed in that version.
https://stablebit.com/DrivePool/Download
 
 
And thank you for supporting out products!
We give support regardless of licensing status, but thanks!
 
If you have any issues after updating, then let us know and we'll see what we can do.
 
 
 
As for balancing/duplication, if you have real time duplciation enabled (default), then the files are written to both disks in parallel. And this should respect the balancing options.
And no, we don't use the same method as Storage Spaces. Storage Spaces uses a block based system, that sits below the file system. We sit on top of it, basically. So it's handled a lot differently.
Also, if you click on "Pool Options", there is a "Balancing" section, where you can control the balancing to a degree.

Very astute. You've just struck a very important aspect of disk I/O, it's called synchronization (by us programmers). Obviously, if such a thing were allowed then you would end up with file corruption.
 
StableBit DrivePool has a well defined locking model to prevent such things from happening (as does the rest of the Windows kernel), and frankly this is most of the work of writing a reliable pooling solution.

Well, if you have Real Time duplication enabled, then the writes are done in parallel. 
I beleive that the slower drive would slow down any transfer or access. So if this is an important consideration, then you may want to check out the Archive Optimizer optional Balancer, as this lets you specify feeder disks. These disks are written to first, and then later moved off of the pool.
 
For read access, if one disk is significantly slower, we'll read from just the faster disk, to speed up access. However, if they're close to the same speed, we'll use a technique called "Read Striping". It's basically what it sounds like. We read ahead from both disks, and cache the contents, to speed up access.
 
 
http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Performance%20Options

As far as duplicated file performance, here's how it works:
 
The Windows NT kernel is inherently asynchronous. In other words, performing an operation does not block the caller. You may have experienced this in other Windows applications, you click a button and then the whole Window freezes until some operation completes. This is not how the Windows kernel works (where our pooling is done). The original designers had the foresight to make the whole thing asynchronous. Which essentially means that nothing waits for something else to complete.

For example, if I need to read a file I issue a READ IRP (a command) to some driver (some code that someone else wrote). If the driver can't service the read request immediately it tells us "Ok, great! I'll get back to you when the read is complete. Do you have any other requests?". This is how everything works under the hood.

We take advantage of this and basically for duplicated files we issue multiple write requests in parallel. This means that the total time that it takes to complete the request is the turnaround time of the slowest drive.

...I am actually not certain that this can be achieved at all.
IMHO drivepool will build the pool on physical disks and only after that you can enable duplication on the pool.
In order to incorporate the NAS, I doubt that drivepool will allow you to build a pool with a network share in it.
The only way of using resources on the NAS, that I can think of, is using it as an iSCSI target and importing that iSCSI disk into your windows system with the iSCSI initiator.
Then drivepool should see it as a physical disk. However, that data will not be shared by the NAS in order to be seen by others.
 
What is your usecase behind that?
 
When using this for duplicating a virtual machine config and its virtual disks, I think there is a lot of risk that the duplicated copy of a virtual disk will be unusable.
This risk exists independent of the way on how you copy it (manually or by means of drivepool duplication with/without matching disks speeds)
The normal way of operating this, AFAIK is to create a VM-snapshot. When you are able to locate the snapshots in an other directory, you should be able to duplicate these safely
and use these to recreate the VM resume state later in case of a crash of the VM 

I don't think you should go that route and combine these two things.
 
It is however not uncommon to use an external datastore for hosting VM disks, like via NFS.
If your NAS is available at the time you need to run the VMs and if the NAS performance over wire is enough (with link aggregation and RAID on the NAS there are possibilities that are within the range of a consumer SSD)
you could for example use the iSCSI target method and exclusively move the VMs to the NAS...freeing up all two local disks in your RAID1 VM-datastore

Yeah, currently StableBit DrivePool does not support adding networked locations to the Pool. Only physical disks. The except to this may be iSCSI, as these show up as physical disks to Windows, and therefor to us.
 
As for VMWare, if performance is important, then you will be better off with RAID, I think.