Since the read performance is pretty fantastic, I am forced to conclude the performance bottleneck is the design limitation of the synchronisation. I'd say it's a little early to say that for certainty but I know where you are coming from. I'm doing a lot of lab work at the moment and even with my ...

Agreed, which is why I have 2 x 10Gbe Sync channels, with crossover optics by Solarflare & Arista. Well I'd say you've got your sync network pretty sorted! If I've done my math right, the raw speed of 2 x 10GbE = 2,560MB/s? 20Gbit/s = 20 x 1024 x 1024 x 1024 bit/s = / 8 / 1024 / 1024 MB/s = 2,5...

Have you checked the disk errors? I'm just doing that - my lab PC is currently on the bench with all it's guts hanging out :-) I'm doing some low-level bench marks plus wiping the disks using Active KillDisk: http://www.killdisk.com The side effect of wiping the disks is that it writes to ever sing...

Metadata - defaults are OK. The more - the better, the less reliable. Thanks for the deduplication calculation. Very useful. I know it's probably been posted before :-) In terms of the metadata, are you saying there is no calculation and it's a preset amount per storage device? Because in the lab, ...

Thanks - will check those out. Have used Veeam in the past with XenServer. Nice products. Cheers, Rob.

I had a Dropbox wobble - fixed now. Link should work.

Cheers, Rob.

So if you're only "just" happy with the performance of your single node SAN, then you should also consider other ways to offset this overhead when switching to HA like SSD L2 caching, as much RAM as you can muster for write-back caching, bigger caches in the disk controller etc.

Two-node HA is always slower than single-node because of the extra overhead in transferring the data across the synchronisation network. The "I'm finished writing" acknowledgement can't be returned until both nodes have confirmed they have written the block. Which is why StarWind suggests ...

I know I've kind of wrapped my lab work here in with the OP problem so I'll break mine out into another topic. I'm also spending a bit of time double-checking the lab environment to make sure it's sound, like wiping the disks block by block to check for write-errors.

Cheers, Rob.

If you`ll assign sync and heartbeat on one physical NIC and it will fail, that will cause split brain issue, and I highly doubt that you need that. I know what split-brain is (common in Exchange DAGs) but not 100% sure why having multiple NICs prevents split brain? If what you mean is that it reduc...

I've had to kill the LSFS storage in my lab as in the scenario described above, it's never completed synchronisation. Worse - it's been creating 5GB files on the node that's been sync'd like they are going out of style! The source has about 40GB of 5GB files. The target mode had got to 500GB before ...

The replication manager option as shown in sshot-26 is missing from LSFS storage (see sshot-27). It's present on flat. It's main use is to check whether the sync and heartbeat networks are working.

Cheers, Rob.

The pros though are that it attempts to iron out the random write storm you get in a typical virtualisation environment whereby there are multiple VMs which may be writing sequentially but because they are all writing at once, arrive at the SAN in a random order. That said, this is a problem with an...

Two hours is more like it. LSFS will be near instant for new storage as it's thin provisioned, i.e. there's only a few blocks to mirror. With a 1TB flat disk, it has to mirror it all for new storage although I did post a workaround for that: create tiny 1MB disk first, let it sync and then expand - ...

Are you creating a thin-provisioned disk? If so that uses LSFS and that needs a reasonably large memory cache - and you haven't got enough RAM in your server. I asked yesterday for the calculation one needs to apply for LSFS metadata.

Could easily be something else

Cheers, Rob.