As you may recall from previous blog posts, Riverbed Steelfusion is an interesting way to provide the performance of a local VMware environment to a remote office whilst also keeping the data replicated back to a central data centre (or even to a cloud environment).<\/p>\n
This is done by presenting out storage from the data centre, via a Steelfusion Core (in the data centre), across your WAN connection to a Steelfusion Edge device.\u00a0 This storage is then presented as local storage to the virtual environment that is running on the Steelfusion Edge device.\u00a0 There are other types of configuration for the Steelfusion environment but that then doesn’t have as much appeal, in my eyes.<\/p>\n
Anyway, recently we stumbled across a situation where we were seeing extremely large latency (especially with write latency) on the IBM Storwize v7000 storage which was being used for the presented storage in Steelfusion.\u00a0 When I’m saying extremely high latency, we’re talking about latency figures in the 1000ms range.\u00a0 This is obviously not good when any data that is modified at the remote office needs to write back to the data centre to be fully committed.\u00a0 With high latency like this, there is a strong possibility that a lot of this data will not be able to be committed and the amount of uncommitted data will increase.<\/p>\n
After investigating this issue with Riverbed, we stumbled onto an issue that had been seen with an Equalogic SAN firmware where uncommitted data would increase significantly.\u00a0 After careful consideration of the potential impact of the following commands, we implemented them onto two presented LUNs.\u00a0 To our delight, this resulted in an immediate drop in the latency on those LUNs.\u00a0 After implementing the changes across all of the LUNs, we were happy to say that the latency returned to a normal level again.<\/p>\n
The commands in question need to be run on the Steelfusion Core and need to be run for each presented LUN.\u00a0 Please note that these commands worked in our environment and are provided for information only.\u00a0 You should always raise a call with Riverbed or one of their partners to investigate this further before implementing.<\/p>\n
<\/p>\n
To enable the fix (Disable ordered task tag):<\/strong><\/p>\n or<\/p>\n <\/p>\nstorage lun modify serial <lun serial> serialize-write enable<\/pre>\n
storage lun modify alias <lun alias> serlialize-write enable<\/pre>\n