Hi, mayby I've misunderstood totally but if you look here -> http://imagevault.se/sv/dokumentation/Api-Dokumentation1/?page=configuration/load-balancing-configuration.html you can see you configure with physical paths which means you can point to a file share that all instances point at. 

If you mean sync by just "reading" from the file share to somewhere else, like AppData folder, that would work. 

Mayby I've missunderstood but if you think I got it right your second proposal would work. 

Hi, thank's for the reply.

We don't want to rely on one singel file server. If all webservers uses one file-server and the file-server goes down the entire web will stop working. Each webserver has it's own AppData folder then we plan to use DFS Replication to syncronise all the AppData folders in the Load-balanced environment.

The SQL will also be a cluster.

I haven't tested with ImageVault, but as far as I understood from experiments with CMS, as long as necessary records eventually show up in SQL server and then physical file on the local AppData folder Assets manager is happy. For SQL - are you planning to use passive cluster with witness server? What setup for SQL is planned?

Hi Valdis, 

I'm not the one configuring the servers so i don't really know how the server-guys setup the SQL-cluster.

However, visitors may hit time window when record is present in SQL, but file hasn't been synced yet. Should be short, but anyway. Visitors will get 404 back then.

We have run dfs and it works, the sync is often so fast that there are no problem with 404.

The important thing to think of is EPiServer search since you will have huge problem with that if you put it in a dfs folder since dfs seems to write in the files or access them in some way that makes Lucene to fail. What we have done is to put the search indexing on a separate site like you need to do if you run your site in Azure. 

This make EPiServer search a single point of failure but it is ok since we are only using it for search inside edit mode.

Another tip is to use udp and not tcp as the protocol for events. We are forced to use tcp and that sometime makes deployment take longer time because IIS locks the port tcp using.