I'm currently working with Exablox and Veeam support with a slowness issue when concurrently reading and writing to an Exablox. Case # 01955120
I got told that for Exablox to talk to devs about the issue, I need to post in the forums.
"If you want to still inquire with the developers you can on our forums at veeam.com to discuss integration with Exablox."
So the current issue is if I backup to disk(Exablox), I get about 180-200MB/s. If I backup to tape from the Exablox I get about 100MB/s. If I do both at the same time, BOTH jobs drop to about 20MB/s ea. I've been told by Exablox that the drop in reads is expected but the drop in writes is not. Doing testing on the device itself only showed the writes drop to 150MB/s.
Veeam support are stating that because Exablox use the CIFS protocol, its the protocol itself causing the slowness, even though the gateway server isn't struggling with requests.
"After reviewing the the situation today and going over all the information provided this what I have. As discussed the Exablox OneBlox can only use the following protocols SMB or NFS, so in Veeam the repository was added as a CIFS share. SMB shares cannot host Veeam Data Mover Services. For this reason, data to the SMB share is written from the gateway server. By default, this role is performed by a backup proxy that is used by the job for data transport. The Veeam interface interacts with the gateway server using the data mover service from this point it implements CIFS to interact the storage interface. CIFS is a fairly old protocol it would be better if we could leverage a faster protocol like iSCSI or Fiber Channel. CIFS defines a series of commands used to pass information between networked computers. As seen parallel tasks are hampered with slow processing rates. Nothing is wrong with the configuration of your environment but to make this quicker you can consider scheduling your jobs to not overlap so that the performance is not affected or accept that the parallel read/write tasks will be slow."
The suggestion to reschedule jobs is due to having 3 backups to the Exablox and subsequent back to tape jobs immediately starting after the backup to disk is finished. I did have plans to move more backups jobs to the Exablox but for obviously reasons have put this on indefinite hold unless a solution for the performance can be found.